# 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 =3D 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].
=A0
For example, 300>600>dpi=A0 would mean 300 dots per inch cross feed, =
600 dots
per inch along feed.
=A0
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 =3D 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 ('>')
=A0
uri-security-supported =3D 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
=A0
Comments?
Tom
-----Original Message-----
From: Robert Herriot [mailto:robert.herriot@Eng.Sun.COM]
Sent: Friday, November 06, 1998 12:55
To: Erik.Guttman@Sun.COM; Hastings, Tom N
Cc: James Kempf; Angelo.Caruso@usa.xerox.com; =
Pete.StPierre@Eng.Sun.COM;
imcdonal@eso.mc.xerox.com; mikael.pahmp@axis.com; srvloc@srvloc.org;
ipp@pwg.org
Subject: Re: IPP> Re: SLP Printer Service Template
I think we looking for the solution to a problem, that on closer=20
examination, doesn't exist.
That is, a printer template should contain uri-security-supported, but =
not=20
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:
=A0=A0 1) a printer entry represents an association with a single =
printer-uri,
not a=20
=A0=A0=A0=A0=A0=A0=A0 collection of printer-uri's.
=A0=A0 2) if a printer entry contains a printer-uri, such as in
printer-uri-supported,=20
=A0=A0=A0=A0=A0=A0 then it links to other directory entries and admin =
becomes very
difficult=20
=A0=A0=A0=A0=A0=A0 if a printer uri changes.=A0 SLP is presumably not =
aware of such links.
So the simple solution is that each printer entry in an SLP DA has a=20
uri-security-supported attribute whose values are for the associated=20
printer-uri only. Thus a printer whose 'name' attribute is 'foo' may =
have=20
two DA entries, each with a different associated printer-uri and =
different=20
uri-security-supported values.
Bob Herriot
At 04:01 AM 11/6/98 , Erik Guttman wrote:
>Hastings, Tom N wrote:
>>=20
>> 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:
>>=20
>>=A0=A0=A0 printer-uri-supported (1setOf uri)
>>=A0=A0=A0 uri-security-supported (1setOf type2 keyword)
>>=20
>
>SPACE is an OK character for values.=A0 The only caveat is that SLP =
search
>filter semantics are identical to those in LDAPv3 search filters:=A0 =
Spaces
>are folded to a single space for the sake of equivalence testing.
>
>> uri-and-security-supported =3D STRING M
>>=A0=A0=A0=A0 # IPP 'printer-uri-supported' and =
'uri-security-supported'
>>=A0=A0=A0=A0 # The list of URI supported by this printer with each =
URI value
followed
>> by
>>=A0=A0=A0=A0 # one of the security keywords separated by one SPACE =
character.
>>=A0=A0=A0=A0 # Example values: <http://foo/> http://foo none, =
<http://bar/>
http://bar tls, <http://baz/> http://baz tls-daa
>>=A0=A0=A0=A0 # IPP security keywords include:
>>=A0=A0=A0=A0 # none, daa, tls, tls-daa, ssl3, ssl3-daa
>>=20
>
>For example, if I were to register a service (following your example)
>with the following attributes:
>
>=A0 (uri-security-supported=3D <http://foo/> http://foo none, =
<http://bar/>
http://bar tls, <http://baz/> http://baz tls-daa)
>
>I could then successfully match with the filters:
>
>=A0 (uri-security-supported=3Dhttp* none)
>=A0 (uri-security-supported=3Dhttp*=A0=A0=A0=A0 tls)
>
>Both of these are looking for http based URLs which support a =
particular
>security type.=A0 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.=A0 This is particularly useful for a nomadic user in an =
environment
>where they have no security configuration.
>
>Erik
>=20