IPP Mail Archive: RE: IPP> [URGENT] RE: Help - Naming proble

RE: IPP> [URGENT] RE: Help - Naming problems in SLP 'service:printer'

From: Hugo Parra (HPARRA@novell.com)
Date: Wed Mar 01 2000 - 17:14:12 EST

  • Next message: Paul Moore: "RE: IPP> [URGENT] RE: Help - Naming problems in SLP 'service:prin ter'"

    Thank you Ira for expounding on my original proposal. I've added a few comments/questions to you message below.

    -Hugo

    >>> "McDonald, Ira" <imcdonald@sharplabs.com> 03/01/00 02:15PM >>>
    > [URGENT - decision needed within 3 days]
    >
    > Hi Hugo,
    >
    > You make good points below. Tom Hastings and I have been
    > noticing the same problem ('lockstep' nature of the three
    > underlying IPP attributes) in the Set-Printer-Attributes
    > new proposed IPP operation (e.g, what if you only set one
    > of the three and now they have an unequal number of member
    > values - oof!).
    >
    > Since changing the names of most of the attributes in the
    > SLP 'service:printer:' to prefix them with 'printer-' (to
    > allow clean translation to LDAP and other flat namespace
    > directory protocols) is NOT a backward compatible change,
    > the next template version will have to be 'v2.0' anyway.
    >
    > So, I hereby propose a new base syntax in IPP and a slight
    > revision of your example below. Remember that since commas
    > are legal in the body of URI, we still need to use the '>'
    > delimiter in SLP to separate a list of URI. And since ';'
    > is legal in the body of URI, we ALSO need to use some
    > special character to separate parts (see example below).
    > I propose to use '<' (these characters are 'safe' because
    > they are 'delimiters' in RFC 2396, i.e., they stop URI
    > parsing).
    >
    > A new base syntax in IPP called 'xri' (Extended Resource ID),
    > as in the following example (lines folded for email length):
    >
    > printer-xri-supported =
    > uri=ipp://abc.com/p1< sec=tls;ssl3< auth=basic< >

    [HParra] The ';' between 'tls' and 'ssl3' in the 'sec=' section above should be a ','

    > uri=lpr://abc.com/pq< sec=none< auth=none< >

    [HParra] We're not mandating any given order for the sections within a single value, right?

    >
    > Note that I downcased your keywords (URI, SEC, AUTH) to make
    > them standard IPP keywords.

    [HParra] Good.

    > There are two Extended Resource
    > IDs listed in the above SLP template attribute example. In
    > IPP, which explicitly supports multivalued attributes in the
    > encoding (without comma or other delimiter), the first XRI
    > (ipp:) would be value one and the second XRI (lpr:) would be
    > value two (and they would not contain '>').

    [HParra] You think this is better than defining these attributes as members of the a collection? Maybe it is more flexible and maps better to the SLP representation. What about LDAP?

    >
    > We can't undo all the IPP products that already shipped with
    > these three parallel ordered attributes, but we *can* decide
    > they were a mistake and disambiguate them by *adding* the new
    > synthesis attribute 'printer-xri-supported' and making the
    > old separate attributes 'read-only' for 'Set-Printer-Attributes'
    > operations.
    >
    > We need to make this decision ALMOST IMMEDIATELY, so that
    > I can get a new I-D out for 'service:printer:' before Friday Friday (10 March)
    >
    > Cheers,
    > - Ira McDonald (consulting architect at Sharp Labs America)
    > High North
    >
    > -----Original Message-----
    > From: Hugo Parra [mailto:HPARRA@novell.com]
    > Sent: Wednesday, March 01, 2000 10:12 AM
    > To: ipp@pwg.org; srvloc@srvloc.org
    > Subject: IPP> RE: Help - Naming problems in SLP 'service:printer'
    >
    >
    > Hi all,
    >
    > I realize this is the eleventh hour (if not a little later) to bring this up
    > again, but I think it's important.
    >
    > I'm convinced IPP made a serious mistake in defining the
    > "printer-uri-supported", "uri-authentication-supported" and
    > uri-security-supported" as parallel attributes. We've already gotten a
    > glimpse of the challenge it will be to keep them in sync under all
    > circumstances.
    >
    > One of the arguments for their current definition was that it would
    > facilitate extensions. We reasoned that if a new dimension were ever needed
    > (a good assumption by the way, v1.1 already added
    > "uri-authentication-supported" and "uri-compression-supported" has been
    > discussed), all we would have to do is add another parallel attribute to the
    > set. In actuality, this illustrates how broken the model is. It negates
    > interoperability between systems that support even slightly different
    > parallel sets. An additional, though less serious, problem is that it can
    > cause an unwieldy number of permutations as more
    > security/authentication/etc. combination become possible.
    >
    > Now we're going to compound the problem by defining an SLP template and LDAP
    > *abstract* scheme for printers that has the same horrendous problem! I
    > propose that we use a different model, one that does away with parallel
    > attributes. If it's too late to fix IPP (and I'm not really sure it is), at
    > least let's fix the SLP and LDAP representation.
    >
    > I'd like to propose defining a multi-valued attribute of syntax STRING by
    > the name "printer-uri-supported-information" (or something like it) that
    > replaces "printer-uri-supported", "uri-authentication-supported" and
    > "uri-security-supported". Each value for this attribute must be populated
    > as follows:
    >
    > "URI=ipp://abc.com/p1; SEC=tls,ssl; AUTH=basic;"
    >
    > Multiple values for a section should be allowed as long as they're valid
    > with all other combinations possible from the other sections included in the
    > same string. If they're not, then a new value should be created. Consumers
    > of this attribute are required to ignore section KEYs they don't recognize
    > and assume <no-value> for KEYs that don't appear.
    >
    > This representation enables very powerful extensibility and gets out of the
    > business of updating the IPP model, SLP template, and LDAP schema every time
    > a change is needed.
    >
    > -Hugo
    >



    This archive was generated by hypermail 2b29 : Wed Mar 01 2000 - 17:20:31 EST