attachment-0001

<html> 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: <a href="http://foo/" eudora="autourl">http://foo</a> none, <a href="http://bar/" eudora="autourl">http://bar</a> tls, <a href="http://baz/" eudora="autourl">http://baz</a> 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=<a href="http://foo/" eudora="autourl">http://foo</a> none,<a href="http://bar/" eudora="autourl">http://bar</a> tls,<a href="http://baz/" eudora="autourl">http://baz</a> 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 > </html>