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:prin ter'

From: McDonald, Ira (imcdonald@sharplabs.com)
Date: Thu Mar 02 2000 - 12:25:39 EST

  • Next message: McDonald, Ira: "IPP> RE: Comments on the SNMP Notifications Document"

    Hi Tom,

    My typo. The correct separator between values of an
    attribute (in this case hidden within a structured
    attribute) is ',' (comma), as in:

        uri=ipp://foo.com/p1< sec=tls,ssl3< >

    Remember, the '>' still does have an ordering meaning
    in our SLP/LDAP string syntax for the complex 'resolution'
    attribute (x, y, and units), but that's a separate use.

    Thanks for your good comments, all.

    - Ira

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, March 02, 2000 9:14 AM
    To: Hugo Parra; ipp@pwg.org; imcdonald@sharplabs.com; srvloc@srvloc.org
    Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
    'service:prin ter'

    Ira and Hugo,

    I think that using > to separate attributes and < to separate sets of
    attributes is a fine approach for SLP and LDAP. If we don't require the
    components to be in a particular order (Hugo's comment), and don't require
    all members to be present, then I believe that this syntax maps one to one
    with our collection syntax:

      The "," separates values of an attribute
      The ">" separates attributes in a set
             (same as separates attributes in a collection value)
      The "<" separates sets of attributes
             (same as separates each collection value)

      This means that in the future, if we have a collection attribute that
    needs to be added to the directory, we will be able to do it with this
    syntax in the directory.

    So we need to clarify that, while we are using the > character, it doesn't
    imply an ordering any more. The original approach with parallel attributes
    did require that > meant ordered.

    Also we need to clarify what is the separator character between multiple
    values. It is ";" or ","? Hugo suggests ",".

    Whether we "fix" IPP to replace or augment the three parallel attributes
    with a single collection attribute is a completely separate question and
    need not get decided on this short schedule. Lets just go ahead with this
    syntax proposal for LDAP and SLP directory whether we fix IPP or not.



    -----Original Message-----
    From: Hugo Parra [mailto:HPARRA@novell.com]
    Sent: Wednesday, March 01, 2000 14:14
    To: ipp@pwg.org; imcdonald@sharplabs.com; srvloc@srvloc.org
    Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP

    Thank you Ira for expounding on my original proposal. I've added a few
    comments/questions to you message below.


    >>> "McDonald, Ira" <imcdonald@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
    > 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
    > 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
    > (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
    > 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
    > 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
    > *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),
    > 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
    > same string. If they're not, then a new value should be created.
    > 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
    > business of updating the IPP model, SLP template, and LDAP schema every
    > a change is needed.
    > -Hugo

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