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