So if SPACE is an ok delimiter within a value as in Erik's example, I would
suggest that we could combine the two ordered IPP printer attributes:
printer-uri-supported (1setOf uri)
uri-security-supported (1setOf type2 keyword)
by putting the URI first separated by a SPACE followed by the security
keyword, then a comma to separate each (unordered) valued. (We need to
check to see whether URIs can include a SPACE or not. If they can, then we
should just put the keyword first).
We are proposing some additional security keywords so that we don't need to
add a security parameter to the URI. Here is the new (proposed) list for
the IPP Model document (which we will confirm at our IPP meeting 11/11/98):
'none': There are no secure communication channel protocols in use for
the given URI.
'daa': [DAA] authentication will be requested by the IPP Printer.
'tls': TLS 1.0 [TLS] is the secure communications channel protocol in
use for the given URI.
'tls-daa': TLS 1.0 [TLS] is the secure communications channel protocol in
use for the given URI.
In addition, [DAA] authentication will be requested by the IPP
printer.
'ssl3': SSL3 is the secure communications channel protocol in use for the
given URI.
(Note that SSL3 is proprietary, not a standard IETF protocol).
'ssl3-daa': SSL3 is the secure communications channel protocol in use for
the given URI.
In addition, [DAA] authentication will be requested by the IPP
Printer.
(Note that SSL3 is proprietary, not a standard IETF protocol).
So the SLP attribute that combines these two IPP Printer attributes could
be:
uri-and-security-supported = STRING M
# IPP 'printer-uri-supported' and 'uri-security-supported'
# The list of URI supported by this printer with each URI value followed
by
# one of the security keywords separated by one SPACE character.
# Example values: http://foo none, http://bar tls, http://baz tls-daa
# IPP security keywords include:
# none, daa, tls, tls-daa, ssl3, ssl3-daa
I suspect that it is better to keep the 'none' keyword, so that clients
could do searches for 'none' when looking for channels without security,
rather than saying that if there was no second field, there was no security.
BTW, we made ISO DPA attributes unordered, in order to follow the X.500
directory attribute semantics, but regretted the added complexity it caused
when we did have a very few attributes that required ordered values. Oh
well.
Tom Hastings
>-----Original Message-----
>From: James Kempf [mailto:James.Kempf at Eng.Sun.COM]
>Sent: Thursday, November 05, 1998 11:13
>To: Angelo.Caruso at usa.xerox.com; Pete.StPierre at Eng.Sun.COM;
>imcdonal at eso.mc.xerox.com; mikael.pahmp at axis.com; srvloc at srvloc.org>Cc: ipp at pwg.org>Subject: RE: IPP> Re: SLP Printer Service Template
>>>>>>>The underlying IPP Printer object attributes 'printer-uri-supported'
>>and 'uri-security-supported' are (and MUST be) ordered lists.
>>If SLP purists insist that we can have no ordered lists as
>>values of a 'printer:' attribute, then we have a serious problem.
>>>>>>The specification in draft-ietf-svrloc-service-scheme-12.txt that
>multivalued attributes are an unordered set is consistent with
>other directory servies, such as LDAP. Here is what RFC 2251
>(LDAP v3 protocol)
>says about multivalued attributes:
>>4.1.8:
> Each attribute value is distinct in the set (no duplicates). The
> order of attribute values within the vals set is undefined and
> implementation-dependent, and MUST NOT be relied upon.
>>Since we are striving for maximum interoperability with LDAP,
>attributes
>in SLP must be unordered as well.
>>There are a couple possibilities for maintaining an ordered set. One
>is to explicitly attach a number to the attribute value that indicates
>its precedence in the set. For example:
>> printer-uri-supported = 1 http://foo, 3 http://bar, 2 http://baz>>Clients would naturally have to be aware of the syntactic
>convention, and
>if the attribute is ever used in a query, then the query would have
>to be formulated with wildcards in the proper place to generate the
>desired result.
>>The other possibility is to not make the attribute be multivalued, and
>instead impose a syntactic convention that makes it be a
>formatted list,
>for example:
>> printer-uri-supported = http://foo\2chttp://baz\2chttp://bar>>where the comma has been escaped to indicate that it is part of the
>attribute and not a list element. Again, clients would need to parse
>the list on input, and queries would need to arrange for wildcards
>in the right place to obtain the desired result.
>> jak
>