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