IPP> Re: SLP Printer Service Template

IPP> Re: SLP Printer Service Template

IPP> Re: SLP Printer Service Template

Erik Guttman Erik.Guttman at Sun.COM
Fri Nov 6 07:01:11 EST 1998

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.


More information about the Ipp mailing list