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