Thank you Ira for expounding on my original proposal. I've added a few comments/questions to you message below.
-Hugo
>>> "McDonald, Ira" <imcdonald at 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 at novell.com]
> Sent: Wednesday, March 01, 2000 10:12 AM
> To: ipp at pwg.org; srvloc at 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
>