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

From: "Paul Moore" <[email-masked]>
Date: Wed, 1 Mar 2000 14:28:27 -0800

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" <[email-masked]> on 03/01/2000 01:15:44 PM

To:   "'Hugo Parra'" <[email-masked]>, [email-masked], [email-masked]
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:[email-masked]]
Sent: Wednesday, March 01, 2000 10:12 AM
To: [email-masked]; [email-masked]
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" <[email-masked]> 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:[email-masked]]
Sent: Tuesday, February 29, 2000 2:26 AM
To: McDonald, Ira
Cc: [email-masked]'; [email-masked]'; [email-masked]'
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

---

From: "Hastings, Tom N" <[email-masked]>
Date: Thu, 2 Mar 2000 09:13:53 -0800

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.

Comments?

Tom

-----Original Message-----
From: Hugo Parra [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 14:14
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
'service:printer'

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

-Hugo

>>> "McDonald, Ira" <[email-masked]> 03/01/00 02:15PM >>>

[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? 

> them standard IPP keywords.

[HParra] Good.

>  There are two Extended Resource

[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?

> I can get a new I-D out for 'service:printer:' before Friday Friday (10
March)

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 2 Mar 2000 09:19:55 -0800

[Sorry for earlier empty reply - sticky mouse]

Hi Paul,

We could certainly use 'collection' to hold the values in
'application/ipp' encoding (that is, the URI and zero
or more of their associated metaparameters for security,
authentication, etc.).

But in SLP, LDAP, and a lot of other directory interfaces,
we need a simple string encoding (see the Subject of
this message).

In the SLP and LDAP encoding of the three original
parallel attributes, we already use the '>' (greater
than) as the URL delimiter (per RFC 2396 and advice
from Larry Masinter).

If we use 'collection' syntax in 'application/ipp',
the new combined attribute (now a collection) won't
be accessible to IPP/1.0 and IPP/1.1 existing software
(some of which IS extensible for new attributes with
simple datatypes).  Thus, I was thinking of simple
multi-valued strings (an actual new 'xri' syntax isn't
strictly necessary for the IPP encoding), for better
interworking.

Cheers,
- Ira McDonald

-----Original Message-----
From: Paul Moore [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 2:28 PM
To: McDonald, Ira
Cc: 'Hugo Parra'; [email-masked]; [email-masked]
Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
'service:prin ter'

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:

connection2:

.. 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

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

Hi Hugo,

printer-xri-supported =

Cheers,

-----Original Message-----
From: Hugo Parra [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 10:12 AM
To: [email-masked]; [email-masked]
Subject: IPP> RE: Help - Naming problems in SLP 'service:printer'

Hi all,

-Hugo

Hi Erik,

Best Regards,

-----Original Message-----
From: Erik Guttman [mailto:[email-masked]]
Sent: Tuesday, February 29, 2000 2:26 AM
To: McDonald, Ira
Cc: [email-masked]'; [email-masked]'; [email-masked]'
Subject: Re: Help - Naming problems in SLP 'service:printer'

Go ahead.

Understood.

Erik

---

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 2 Mar 2000 09:25:39 -0800

Hi Tom,

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

printer-xri-supported=
    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.

Cheers,
- Ira 

-----Original Message-----
From: Hastings, Tom N [mailto:[email-masked]]
Sent: Thursday, March 02, 2000 9:14 AM
To: Hugo Parra; [email-masked]; [email-masked]; [email-masked]
Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
'service:prin ter'

Ira and Hugo,

Comments?

Tom

-----Original Message-----
From: Hugo Parra [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 14:14
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
'service:printer'

-Hugo

[HParra] Good.

March)

---

From: "Hastings, Tom N" <[email-masked]>
Date: Fri, 3 Mar 2000 11:48:49 -0800

Ira,

You used the phrase:

> revision of your example below.  

Did you mean to propose adding a new IPP attribute syntax to IPP Model and
Semantics document?

A minor comment:  Need to clarify whether the < is needed after the last
value, or is < just a separator?  In other words, is < needed if there is
only one set of values?

Tom

-----Original Message-----
From: Hastings, Tom N [mailto:[email-masked]]
Sent: Thursday, March 02, 2000 09:14
To: Hugo Parra; [email-masked]; [email-masked]; [email-masked]
Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
'service:prin ter'

Ira and Hugo,

Comments?

Tom

-----Original Message-----
From: Hugo Parra [mailto:[email-masked]]
Sent: Wednesday, March 01, 2000 14:14
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: IPP> [URGENT] RE: Help - Naming problems in SLP
'service:printer'

-Hugo

[HParra] Good.

March)