Attendees: Ira McDonald, Gail Songer, Marty Joel, John Pulera, Tom Hastings
I'm sending this to the IPP DL as well, since the agreements include some of
the important relationships between IPP and IPPFAX.
We reviewed the 5 issues in the IPPFAX Protocol spec
(ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-08.pdf)
and came to the following agreements. Any comments on these agreements
should be sent to the mailing list:
1. Page 8, section 1.3 Namespaces Used:
ISSUE 01: Why can't all of the "ippfax-xxx" attributes defined in this
document be supported OPTIONALLY by an IPP Printer as IPP extensions to the
IPP Protocol as well? This would allow IPP to support UIF document format
and profiles, along with vCard, and provide a simple way for an anonymous
user mode. If so, shouldn't we remove the "ippfax-" prefix from all these
attributes in this document, since they wouldn't be restricted to IPPFAX?
From the TOC, these attributes are:
4.2 ippfax-uif-profile-requested (type2 keyword) operation attribute
5.6 ippfax-uif-profiles-supported (1setOf type2 keyword) Printer
Description attribute
5.7 ippfax-uif-profile-capabilities (1setOf text(MAX)) Printer Description
attribute
5.8 ippfax-auto-notify (boolean) Printer Description attribute
6.1 ippfax-sending-user-vcard (text(MAX)) operation/Job Description
attribute
6.2 ippfax-receiving-user-vcard (text(MAX)) operation/Job Description
attribute
6.3 ippfax-sender-uri (uri) operation/Job Description attribute
7.2.1.2 ippfax-uif-profiles (1setOf type2 keyword) Job Creation operation
attribute
AGREED> That all of these IPPFAX attributes will have the "ippfax-" prefix
removed and the spec clarified that these attributes MAY also be supported
by an IPP Printer as OPTIONAL IPP extensions. Using IPP will be the way
that a Printer can support UIF without having to use TLS.
2. Page 18, section 6.2 ipp-versions-supported:
ISSUE 02: OK that the IPP/1.1 "version-number" parameter that contains the
IPPFAX version number is compared with the (existing) IPP/1.1
"ipp-versions-supported" Printer Description attributes that contains the
IPPFAX version number (rather than defining a new
"ippfax-versions-supported" Printer Description attribute and not using the
"ipp-versions-supported" attribute)?
AGREED> We need both of the "ipp-versions-supported" and
"ippfax-versions-supported" Printer Description attributes, since IPPFAX/1.0
might use IPP/1.1 or a future IPP/1.2 or IPP/2.0, and/or IPPFAX/1.2 might
use IPP/1.1, etc. Then the client can validate that the Printer is a
Receiver by simply checking for the "ippfax-versions-supported", rather than
the more complicated examination of the values of the
"printer-uri-supported" and doing a URL comparison (which is complicated,
including port numbers, case conversion, etc.)
We didn't discuss whether to reinstate the ippfax-version-number (type2
keyword) Operation attribute or to overload the "version-number" parameter
to be for IPP or IPPFAX depending on the URL. However, using the same
reasoning that it is important to know which versions of IPP a Receiver
supports for the IPPFAX protocol, it is important to know which version of
IPP the client is using for its IPPFAX request. Therefore, we should go
back to the "ippfax-version-number" Operation attribute as in Draft D7.
Then the presence of the "ippfax-version-number" in the request indicates
that it is IPPFAX, not IPP.
The Print Service uses its existing IPP code for validating the IPP version
number and then uses additional code to validate the IPPFAX version number.
Then the Print System can determine that the request is IPPFAX, not IPP, by
looking for the "ippfax-version-number" operation attribute, instead of
examining the "printer-uri" operation attribute. This means that the
validation of an IPPFAX request by the Printer is the same as for IPP (since
RFC 2911 doesn't require that the Printer validate the "printer-uri"
operation attribute).
If there are any objections to reinstating the "ippfax-version-number"
operation attribute to go along with the "ippfax-versions-supported" Printer
Description attribute, please send comment to the email list.
3. Page 27, Table 7:
Repeat of ISSUE 01
AGREED> We would make all the columns that show RFC 2911 conformance be
lower case, to clarify that those words are NOT re-stating the conformance
for an IPP Printer. Also the "ippfax-" attributes that are being changed to
remove the "ippfax-" prefix, will become "may" for the "IPP/1.1 Printer
supports" column.
4. Page 29, Section 9.2, Job Template Attributes, Table 8:
ISSUE 03: The Sender supply and the Receiver support columns have a lot of
"MUST NOT". Instead of not allowing these attributes at all, how about a
MAY but restricted to the obvious default values, i.e., "number-up"=1,
"job-priority"=50, "insert-sheet"='none', x-image-shift=0, etc. Otherwise,
there is some interworking problems with a client or forwarding Printers
that supports both IPP and IPPFAX and supplies these attributes with their
obvious default values (instead of omitted them).
AGREED> We agreed that the "MUST NOT" Job Template attributes MAY be
supported, but only with the single obvious value that will be in the IPPFAX
spec.
5. Page 40, section 11.2 uri-authentication-supported, Table 13:
ISSUE 04: We agreed at the October meeting to make 'none' be "MAY support
and MAY use" for a Receiver. However, a better way to get public access, is
to use IPP with UIF and vCard exchange. See ISSUE 01 which suggests that
IPPFAX attributes be OPTIONAL IPP attributes as well. Then 'none' could go
back to MUST NOT.
AGREED> We agreed that when the Printer uses TLS, it is OK for the Printer
to be configured to support the 'none' for Client Authentication, so Table
13 'none' row stays as "MAY support and MAY use", but Table 15 'none' should
be changed from MAY to MUST NOT.
FUTURE> We discussed that there is a need to add a 'kerberos' keyword for
use in IPP and IPPFAX in the "uri-security-supported" attribute (Table 15,
not Table 13). There are systems that use Kerberos, instead of TLS, for a
security protocol. That should be done for both IPP and IPPFAX separately
from the IPPFAX spec.
6. Page 42, section 11.4 Using IPPFAX with TLS:
ISSUE 05: OK that we deleted the "ippfax-sending-user-certificate-uri (uri)
operation/Job Description attribute? The client MUST pass the certificate,
whether by value or by reference in the TLS record layer.
AGREED> Yes, unless the Printer supports the 'none' for Client
Authentication, in which case the client doesn't pass a certificate at all.
7. Page 42, section 11.5 Access Control:
ISSUE 04 (repeated): Why not use IPP, instead of IPPFAX for anonymous user
access, if we agree to allow all IPPFAX attributes as OPTIONAL extensions to
IPP as well?
AGREED> The "public mode" in section 11.5, probably means on the Internet
without the client needing a certificate. So our agreement to allow 'none'
in Table 13 for Client Authentication ("uri-authentication-supported")
allows this so-called "public mode".
8. Other agreements
a. Clarify that this version of the spec is for IPPFAX/1.0, not just IPPFAX.
b. We'll add an informative appendix that lists any differences from IPP to
help implementers that are supporting both. The differences are mainly
changes in conformance requirements.
c. Section 11.1 Privacy, 2nd paragraph, change:
The Receiver MAY have a TLS certificate.
to:
The Receiver MUST have a TLS certificate.
d. In the tables which say NEED NOT, should say MAY, which means the same
thing and is shorter and less confusing.
Send any comments to the mailing lists.
I'll produce an updated version the beginning of the new year.
Tom
This archive was generated by hypermail 2b29 : Wed Dec 19 2001 - 20:44:46 EST