Ira,
Your proposal looks very good, with no obvious problems.
Let's go with it!
Ron Bergman
Hitachi Koki Imaging Solutions, Inc.
"McDonald, Ira" wrote:
> [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< >
> uri=lpr://abc.com/pq< sec=none< auth=none< >
>> Note that I downcased your keywords (URI, SEC, AUTH) to make
> them standard IPP keywords. 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 '>').
>> 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 next
> 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
>> >>> "McDonald, Ira" <imcdonald at sharplabs.com> 02/29/00 02:38PM >>>
> Hi Erik,
>> Thanks very much for clear direction. I'll make a serious effort
> to get the revised SLP 'service:printer' schema out before the
> I-D cutoff on 10 March (for the Adelaide IETF plenary).
>> I labelled the last one 'v1.0' in the template source. Should
> I label the revision 'v1.1' in the template source? Or should we
> try to just publish the fixup as 'v1.0'?
>> Best Regards,
> - Ira McDonald (consulting architect at Sharp Labs America)
> (co-editor of SLP 'service:printer' template)
> High North Inc
>> -----Original Message-----
> From: Erik Guttman [mailto:Erik.Guttman at germany.sun.com]
> Sent: Tuesday, February 29, 2000 2:26 AM
> To: McDonald, Ira
> Cc: 'Erik.Guttman at germany.sun.com'; 'srvloc at srvloc.org'; 'ipp at pwg.org'
> Subject: Re: Help - Naming problems in SLP 'service:printer'
>> >
> > Many of the SLP 'service:printer' attributes (largely taken from the
> > IPP Model) lack a proper scope prefix 'printer-'. This forces us to add
> > those prefixes when translating to an LDAP schema.
> >
> > Tom Hastings (editor of IPP Model) just asked me to write to you and ask
> > if we can (once more) update the SLP 'service:printer' template and add
> > the proper 'printer-' prefixes, to make the translation cleaner and any
> > blind mapping (by an SLP-DA to an LDAP directory server) safe. Some of
> > the numerous currently 'unsafe' attribute names include:
> >
> > uri-authentication-supported
> > uri-security-supported
> > media-supported
> > color-supported
> > sides-supported
> >
> > Has IANA already registered <draft-ietf-svrloc-printer-scheme-05.txt>?
>>ftp://ftp.isi.edu/in-notes/iana/assignments/svrloc-templates> still lacks the registrations. I sent them to IANA in December!
>> > If I turn out a revised I-D within the next 10 days, can we send that to
> > IANA instead?
>> Go ahead.
>> Even if the template version 1.0 goes into the repository, we can submit
> the new draft as template version 1.1. No problem.
>> I intend to talk to some members of the IESG soon about how to escalate
> interaction with IANA so the template registry will get started.
>> > Tom Hastings and I are very concerned about polluting the LDAP flat
> > attribute namespace with names like 'uri-security-supported' and
> > 'media-supported' without proper 'printer-' prefixes.
> >
>> Understood.
>> Erik