From the minutes of the February 9-10, 2000 IPP WG meeting, we have:
A new "multi-attribute" will be defined as a collection containing
the parallel attributes printer uri supported/uri security supported/uri
authentication supported.
Subsequent discussion caused the group to reject the agreement above
[because it would not work in SLP/LDAP directories].
Tom, Henrik, and Bob agreed to take the issue offline and work on
developing a recommended solution to this issue.
Here is our proposal:
Details of the IPP extension Proposal
-------------------------------------
Since the meeting, Ira and Hugo have come up with a proposal for LDAP and
SLP directories that uses ">" to separate components within one value. We
support this approach for LDAP and SLP directories.
So here is our proposal for an IPP extension that uses 'collection' rather
than Ira's LDAP/SLP syntax directly for IPP, but which is directly mappable
to LDAP and SLP directories (by separating the member attributes with ">".
We keep the three existing attributes (the 3 musketeers), but clearly define
them as READ-ONLY:
"printer-uri-supported" (uri)
"uri-authentication-supported" (type2 keyword)
"uri-security-supported" (type2 keyword)
If an implementation wants to support setting these attributes using the
Set-Printer-Attributes operation, the implementation MUST support a new
single read/write Printer Description attribute:
"printer-xri-supported: (1setOf collection)
which has the following member attributes:
"printer-xri-supported-uri" (uri)
"printer-xri-supported-authentication" (1setOf type2 keyword)
"printer-xri-supported-security" (1setOf type2 keyword)
Each value of the "printer-xri-supported-uri" member attribute MUST be
unique.
Setting this new attribute also sets the values of the three existing
attributes as a defined side effect.
The definition of the new attribute goes into the "Job and Printer Set
Operations" specification that we want to start an IPP WG Last Call on this
week.
In order to align with Ira's "printer-xri-supported" attribute for SLP and
LDPA, where the authentication and security can be multi-valued, we've made
the authentication and security member attributes multi-valued.
When performing a Set-Printer-Attributes operation, if there are multiple
values for the "printer-xri-supported-authentication" and/or
"printer-xri-supported-security" member attributes, the Printer sets the
corresponding three READ-ONLY attributes with all possible combinations of
values. For example, the IPP representation for Ira's SLP and LDAP example
(modified for suitability in an IPP document):
> printer-xri-supported =
> uri=ipp://abc.com/p1< sec=tls,digest< auth=basic< >
> uri=http://abc.com/pq< sec=none< auth=none< >
would be to set the IPP "printer-xri-supported" Printer Description
attribute as follows:
"printer-xri-supported =
{ "printer-xri-supported-uri" = ipp://abc.com/p1
"printer-xri-supported-security" = tls, digest -- 2 keyword values
"printer-xri-supported-authentication" = basic -- 1 keyword value
},
{ "printer-xri-supported-uri" = http://abc.com/pq
"printer-xri-supported-security" = none -- 1 keyword value
"printer-xri-supported-authentication" = none -- 1 keyword value
}
would lead to 3 parallel values of the corresponding IPP/1.1 parallel
attributes:
"printer-uri-supported" = { ipp://abc.com/p1, ipp://abc.com/p1,
http://abc.com/pq }
"uri-authentication-supported" = { basic, basic, none }
"uri-security-supported" = { tls, digest, none }
Had the IPP security had 3 values and the IPP authentication had 2 values,
then there would have been 7 (2*3 + 1) parallel values, 6 with the same IPP
URI and 1 with the HTTP URI.
MINOR ISSUE:
Do we want to shorten the IPP member attribute names? As short as the SLP?
or keep them as English words, so that the localization folks have a chance
of making some good translations?
Member name alternative 1 (same as LDAP, SLP):
"printer-xri-supported =
{ "uri" = ipp://abc.com/p1
"sec" = tls, digest -- 2 keyword values
"auth" = basic -- 1 keyword value
},
{ "uri" = http://abc.com/pq
"sec" = none -- 1 keyword value
"auth" = none -- 1 keyword value
}
Member name alternative 2 (English words or acronyms):
"printer-xri-supported =
{ "uri" = ipp://abc.com/p1
"security" = tls, digest -- 2 keyword values
"authentication" = basic -- 1 keyword value
},
{ "uri" = http://abc.com/pq
"security" = none -- 1 keyword value
"authentication" = none -- 1 keyword value
}
We'd like to discuss this proposal at the IPP Telecon, this Wednesday, 10-12
PST. If there is general agreement, then I'll update the "Job and Printer
Set Operations" spec one more time before this Thursday, and make another
I-D, so we can start the IPP WG Last Call. So if there are any other
comments on the "Job and Printer Set Operations documents, posted last week,
it would be good to see them on the mailing list before Wednesday's telecon.
The spec is available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/draft-ietf-ipp-job-printer-set-ops-00.
txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000301.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000301.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000301.txt
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000301-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-job-printer-set-ops-000301-rev.pdf
Comments?
Tom
This archive was generated by hypermail 2b29 : Mon Mar 06 2000 - 20:05:57 EST