Hastings, Tom N wrote:
>> 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)
>
SPACE is an OK character for values. The only caveat is that SLP search
filter semantics are identical to those in LDAPv3 search filters: Spaces
are folded to a single space for the sake of equivalence testing.
> 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
>
For example, if I were to register a service (following your example)
with the following attributes:
(uri-security-supported=http://foo none,http://bar tls,http://baz tls-daa)
I could then successfully match with the filters:
(uri-security-supported=http* none)
(uri-security-supported=http* tls)
Both of these are looking for http based URLs which support a particular
security type. The example shows that internal spaces are irrelevant
in the request.
> 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.
I agree. This is particularly useful for a nomadic user in an environment
where they have no security configuration.
Erik