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

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

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

Hugo Parra HPARRA at novell.com
Wed Mar 1 17:14:12 EST 2000


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

-Hugo

>>> "McDonald, Ira" <imcdonald at 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 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
>



More information about the Ipp mailing list