IPP Mail Archive: Re: IPP> Re: SLP Printer Service Template

IPP Mail Archive: Re: IPP> Re: SLP Printer Service Template

Re: IPP> Re: SLP Printer Service Template

Erik Guttman (Erik.Guttman@Sun.COM)
Fri, 06 Nov 1998 13:01:11 +0100

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