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
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/ipp/attachments/19981106/79c9df72/attachment-0001.html