I've finally down-loaded the IFX spec to the URLs advertised in the agenda
for next Wednesday's telecon. Ira, John, Gail, and I have discussed/raised
some issues. It has 20 issues embedded in it which I have also extracted
into this mail message. Most of these issues are new. So the IFX document
isn't quite ready for PWG Last Call.
Please send any comments on these issues or other issues to the DL before
the telecon.
John down-loaded the UIF spec last Wednesday. It is nearly ready for PWG
Last Call.
Tom
The 20 ISSUES in the IFX Protocol document:
ISSUE 01: Are all the attribute names ok? Check the TOC to see all the
names together.
ISSUE 02: Should we add all of the Job Template attributes which MUST be
subsetted for IPP FAX?
ISSUE 03: OK that the Sender needs to make two Get-Printer-Attributes
requests in order to determine both the IPP and IPPFAX document formats
supported?
ISSUE 04: OK to add UIF Profile T (JBIG2) which is only an I-D?
ISSUE 05: Should we change the attribute syntax of the
"printer-uif-profile-capabilities" (octetString32k) Printer Description
attribute to be multi-valued text, i.e., 1setOf text(MAX)? At the last IPP
FAX telecon on May 30, this issue was re-raised. From reading the CONNEG
RFCs, the same *white space* rules are used between tokens as for email.
Thus, we could represent CONNEG strings as 1setOf text, where each text
value contains one or more CONNEG tokens. When combining a 1setOf text into
a CONNEG string, the parser would insert some *white space" between each
value.
Note: each token doesn't have to be a separate text value (though it can
be).
Alternatively, we could just simply chunk the CONNEG value at arbitrary
places between each text value.
The advantage of using existing IPP data types, instead of inventing a new
data type, is that existing gateways can be used. Remember that a number of
initial IPP implementations were just gateways to existing printing systems.
ISSUE 06: The use of "identity" meaning vCard in the
"ippfax-sending-user-identity" attribute name is quite different from its
use in Kerberos and other network single login technologies. Should we
change the name to something like "ippfax-sending-user-vcard"?
ISSUE 07: Ok to change the attribute syntax of the
"ippfax-sending-user-identity" operation attribute from octetString32k(MAX)
to text(MAX), since the value is a vCard string and 1023 characters seem
plenty? Then this attribute would get through IPP/1.1 Gateways.
ISSUE 08: Or should we make the attribute syntax of the
"ippfax-sending-user-identity" operation attribute be multi-valued, i.e.,
1setOf text(MAX)? Then this attribute would get through IPP/1.1 Gateways
and not be limited to length.
ISSUE 09: The use of "identity" meaning vCard in the
"ippfax-receiving-user-identity" attribute name is quite different from its
use in Kerberos and other network single login technologies. Should we
change the name to something like "ippfax-receiving-user-vcard"?
ISSUE 10: Ok to change the attribute syntax of the
"ippfax-receiving-user-identity" operation attribute from
octetString32k(MAX) to text(MAX), since the value is a vCard string and 1023
characters seem plenty? Then this attribute would get through IPP/1.1
Gateways.
ISSUE 11: Or should we make the attribute syntax of the
"ippfax-receiving-user-identity" operation attribute be multi-valued, i.e.,
1setOf text(MAX)? Then this attribute would get through IPP/1.1 Gateways
and not be limited to length.
ISSUE 12: Is 'client-error-forbidden' status code the proper status code to
return for an IPP Job submitted to a Receiver that is configured only to
accept IPPFAX Jobs, i.e., the value of the Receiver's
"ippfax-jobs-supported" contains only the 'ippfax-authenticated' value?
ISSUE 13: SHOULD be using a client URL by preference and NOT a MAC address
(generally totally unknown to an IPP client application). In any case the
IEEE and IETF don't approve the use of MAC address for identifiers anymore
except in EUI-64 format (an IEEE standard), which is the basis for canonical
IPv6 self-configured global addresses. Ira will look up the RFC references
later, if you want EUI-64
ISSUE 14: The ippfax-receiver-identity (name(MAX)) Printer Description
attribute is bad design. The "printer-uri-supported" is EXACTLY what
"ippfax-receiver-identity" is supposed to be without all this unsuitable
discussion about MAC addresses. So can we get rid of the
ippfax-receiver-identity (name(MAX)) Printer Description attribute and
REQUIRE the Sender to query the "printer-uri-supported" Printer Description
attribute instead?
ISSUE 15: OK that we are using the 'ipp:' scheme for both IPP and IPPFAX
protocols?
ISSUE 16: OK that we are forced to use the same default port for IPPFAX as
for IPP? So if a Receiver is configured to only receive IPPFAX Jobs from
outside its firewall, but receive IPP Jobs from inside its firewall, one or
the other will be forced to supply an explicit (different) port?
ISSUE 17: Is this the last use of the new octetString32k attribute syntax?
Can we change it to an existing data type or 1setOf octetString(MAX), i.e.,
chunk the data, so that it can be passed through existing IPP Gateways?
ISSUE 18: Can we get rid of the new 'octetString32k' attribute syntax and
use existing IPP/1.1 attribute syntaxes, so that existing IPP systems can be
used as gateways?
ISSUE 19: Do the conformance tables look ok?
ISSUE 20: Is this vCard example accurate? The phone number format seem
wrong.
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Thursday, June 21, 2001 11:19
To: IPP FAX DL (E-mail)
Cc: McIntyre, Lloyd; Buckley, Robert R
Subject: IFX> IPP FAX telecon agenda, Wed, June 27, 10-12 PDT (1-3 EDT)
The IPP FAX telecon that we scheduled at the May 30 telecon is coming up in
a week. We think that the two IPP FAX document are pretty close to being
finished. If you haven't read them recently, this would be a good time. We
are ready for PWG Last Call on them. We will decide at next week's telecon,
whether to start PWG Last Call (ending after the August 1 Toronto meeting)
or wait for the Toronto meeting to decide to start the PWG Last Call.
John has posted and announced the UIF spec yesterday and I'll post and
announce the IFX spec later today or tomorrow at the URLs indicated below.
Here is the dial-in information:
Time: Wednesday, June 27, 2001 10:00 - 12:00 PST (1:00 - 3:00 EST)
Phone: 1-712-271-0568 (8*534-6413 for Xerox folks)
Passcode: 52863#
The agenda is:
1. Review John Pulera's updated UIF spec with changes highlighted:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05-edit.doc>
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05-edit.pdf>
clean:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05.doc>
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-05.pdf>
2. Review the updated IFX spec (its, not there yet, so I'll post in a day or
so and announce).
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05-rev.doc>
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05-rev.pdf>
clean:
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05.doc>
<ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-05.pdf>
3. Are the documents ready to start PWG Last Call?
Should we start PWG Last Call on the documents (ending at the end of the
Toronto August 1 meeting) or wait for the Toronto meeting to decide to start
the PWG Last Call?
4. Next meeting and/or telecon
Unless we can't finish reviewing the two documents in the two hours, no
further telecons before the PWG meeting are planned. The next face-to-face
IPP FAX WG meeting will be in Toronto, Wednesday, August 1, after the PWG
plenary.
Thanks,
Tom
P.S. If you want to refresh your memory on what we agreed to at the two
previous telecons (May 30 and June 6) see the mail messages on 6/1/01 and
6/6/01, respectively.
If you want to refresh your memory on what we agreed on in Portland,
April 25, the IPP FAX minutes are available at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0104-minutes.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/minutes/IPPFAX-0104-minutes.doc
This archive was generated by hypermail 2b29 : Fri Jun 22 2001 - 22:53:33 EDT