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

RE: IPP> [URGENT] RE: Help - Naming problems in SLP 'service:prin ter'

From: Paul Moore (pmoore@peerless.com)
Date: Wed Mar 01 2000 - 17:28:27 EST

  • Next message: McDonald, Ira: "RE: IPP> New Web Pages"

    Now is the time to think about using collections or stuctures - we should bite
    the bullet and just do it. This is a clear example of where it is needed.
    Creating structured strings is out of character with the remaoinder of the IPP
    protoocl (I.e. no string parsing).

    In this case a 'supported-connections' (or whatever you want to call it) would
    be

    connection1:
         uri=ipp://server1/printer1
         authentication=Digest
         ssl=optional

    connection2:
         uri=ipp://server1/printer1
         authentication=basic
         ssl=required

    .. note that this is not a proposal for an exact scheme for URI rather a cal to
    address the current weakness in the core encoding

    "McDonald, Ira" <imcdonald@sharplabs.com> on 03/01/2000 01:15:44 PM

    To: "'Hugo Parra'" <HPARRA@novell.com>, ipp@pwg.org, srvloc@srvloc.org
    cc: (bcc: Paul Moore/AUCO/US)

    Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP 'service:prin ter'

    [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 : Wed Mar 01 2000 - 17:34:50 EST