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

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

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

From: Ron Bergman (rbergma@hitachi-hkis.com)
Date: Thu Mar 02 2000 - 12:51:13 EST

  • Next message: Hugo Parra: "IPP> RE: Help - Naming problems in SLP 'service:printer'"

    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@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
    >
    > >>> "McDonald, Ira" <imcdonald@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@germany.sun.com]
    > Sent: Tuesday, February 29, 2000 2:26 AM
    > To: McDonald, Ira
    > Cc: 'Erik.Guttman@germany.sun.com'; 'srvloc@srvloc.org'; 'ipp@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



    This archive was generated by hypermail 2b29 : Thu Mar 02 2000 - 12:48:33 EST