Ira is off the next until 16-Nov. He just happened to call and thinks that
there are several problems with having multiple printer entries for the same
printer that different only in uri and security scheme.
Seems like a night mare for the Administrator to make sure that all such
entries are updated when any changed. Also updating several SLP entries
into a single LDPA would be problematic. Finally, as we get other protocol
stacks added to the printer schema, it would be best to maintain a single
entry in the SLP directory with just additional attributes to describe the
additional protocol stacks, not have to keep duplicating directory entries.
Because SLP doesn't have ordered values, we have to fix resolution-supported
as well, anyway. We can't leave it as comma separated list.
Since RFC 2396 reserves <> as delimiters, so they can't be in URIs unless
escaped, we could use > to separate values in any ordered list. Then we'd
make the resolution attribute single-valued string with the > separating
each ordered value within the single string value. The > is suggestive of
order as well.
So change resolution-supported from:
resolution-supported = STRING L M O
# IPP 'printer-resolution-supported'
# The possible resolutions in which documents may be
# printed by this printer (in sets of three values).
# A string representation of 3 comma (',') separated integers
# where each integer itself is represented as a string.
# The 3 integers represent in order: 1) a cross feed
# direction resolution (positive integer value), 2) a feed
# direction resolution (positive integer value), and 3)
# a units value. In the latter case, a '3' indicates
# dots per inch and a '4' indicates dots per centimeter.
# These values are derived from the Printer MIB [6].
TH26>>>>
ISSUE: Why not use some more user friendly code than "3" and "4", such as
'dpi' and 'dpcm'? Then applications might just display them as text?
to:
resolution-supported = STRING L O
# IPP 'printer-resolution-supported'
# The possible resolutions in which documents may be
# printed by this printer (in sets of three values).
# A string representation of 3 greater-than ('>') separated integers
# where each integer itself is represented as a string.
# The 3 integers represent in order: 1) a cross feed
# direction resolution (positive integer value), 2) a feed
# direction resolution (positive integer value), and 3)
# a units value. In the latter case, a 'dpi' indicates
# dots per inch and a 'dpcm' indicates dots per centimeter.
# These values are derived from the Printer MIB [6].
For example, 300>600>dpi would mean 300 dots per inch cross feed, 600 dots
per inch along feed.
Then we can go back to parallel uri-supported and uri-security-supported
ordered attributes as well using the > to separate each value within the
single string value:
uri-supported = STRING L O
# IPP 'printer-uri-supported'
# The ordered list of URI supported by this printer,
# correlated with the 'uri-security-supported' attribute.
# Each value is separated by greater-than ('>')
uri-security-supported = STRING L O
none
# IPP 'uri-security-supported'
# The ordered list of security supported for each URI
# listed in the 'uri-supported' attribute for this printer.
# TLS is one example. URIs that do not support a security
# mechanism should specify 'none'.
# Each value is separated by greater-than ('>')
none, daa, tls, tls-daa, ssl3, ssl3-daa
Comments?
Tom
-----Original Message-----
From: Robert Herriot [mailto:robert.herriot at Eng.Sun.COM]
Sent: Friday, November 06, 1998 12:55
To: Erik.Guttman at Sun.COM; Hastings, Tom N
Cc: James Kempf; Angelo.Caruso at usa.xerox.com; Pete.StPierre at Eng.Sun.COM;
imcdonal at eso.mc.xerox.com; mikael.pahmp at axis.com; srvloc at srvloc.org;
ipp at pwg.org
Subject: Re: IPP> Re: SLP Printer Service Template
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/> http://foo none, <http://bar/>
http://bar tls, <http://baz/> 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/> http://foo none, <http://bar/>
http://bar tls, <http://baz/> 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
>