IPP Mail Archive: RE: IPP> Re: SLP Printer Service Template

IPP Mail Archive: RE: IPP> Re: SLP Printer Service Template

RE: IPP> Re: SLP Printer Service Template

Hastings, Tom N (hastings@cp10.es.xerox.com)
Fri, 6 Nov 1998 14:35:46 -0800

Ira is off the next until 16-Nov.=A0 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.
=A0
Seems like a night mare for the Administrator to make sure that all =
such
entries are updated when any changed.=A0 Also updating several SLP =
entries
into a single LDPA would be problematic.=A0 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.
=A0
Because SLP doesn't have ordered values, we have to fix =
resolution-supported
as well, anyway.=A0 We can't leave it as comma separated list.=A0=20
=A0
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.=A0 Then =
we'd
make the resolution attribute single-valued string with the > =
separating
each ordered value within the single string value.=A0=A0 The > is =
suggestive of
order as well.
=A0
So change resolution-supported from:
resolution-supported =3D 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 =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