IPP> Re: SLP Printer Service Template

IPP> Re: SLP Printer Service Template

IPP> Re: SLP Printer Service Template

Robert Herriot robert.herriot at Eng.Sun.COM
Fri Nov 6 15:54:57 EST 1998


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


More information about the Ipp mailing list