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
--=====================_73831273==_.ALT--
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
>