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

Re: IPP> Re: SLP Printer Service Template

Robert Herriot (robert.herriot@Eng.Sun.COM)
Fri, 06 Nov 1998 12:54:57 -0800

--=====================_73831273==_.ALT
Content-Type: text/plain; charset="us-ascii"

I think we looking for the solution to a problem, that on closer
examination, doesn't exist.

That is, a printer template should contain uri-security-supported, but not
printer-uri-supported. If I am correct, then there is no problem of parallel
attributes to solve.

A printer template should not have the printer-uri-supported attribute in it
for two reasons:
1) a printer entry represents an association with a single printer-uri, not
a
collection of printer-uri's.
2) if a printer entry contains a printer-uri, such as in
printer-uri-supported,
then it links to other directory entries and admin becomes very
difficult
if a printer uri changes. SLP is presumably not aware of such links.

So the simple solution is that each printer entry in an SLP DA has a
uri-security-supported attribute whose values are for the associated
printer-uri only. Thus a printer whose 'name' attribute is 'foo' may have
two DA entries, each with a different associated printer-uri and different
uri-security-supported values.

Bob Herriot

At 04:01 AM 11/6/98 , Erik Guttman wrote:
>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
>

--=====================_73831273==_.ALT
Content-Type: text/html; charset="us-ascii"

I think we looking for the solution to a problem, that on closer
examination, doesn't exist.

That is, a printer template should contain uri-security-supported, but not
printer-uri-supported. If I am correct, then there is no problem of parallel
attributes to solve.


A printer template should not have the printer-uri-supported attribute in it
for two reasons:
   1) a printer entry represents an association with a single printer-uri, not a
        collection of printer-uri's.
   2) if a printer entry contains a printer-uri, such as in printer-uri-supported,
       then it links to other directory entries and admin becomes very difficult
       if a printer uri changes.  SLP is presumably not aware of such links.

So the simple solution is that each printer entry in an SLP DA has a
uri-security-supported attribute whose values are for the associated
printer-uri only. Thus a printer whose 'name' attribute is 'foo' may have
two DA entries, each with a different associated printer-uri and different
uri-security-supported values.

Bob Herriot



At 04:01 AM 11/6/98 , Erik Guttman wrote:
>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
>

--=====================_73831273==_.ALT--