I've edited the IPPFAX Protocol spec D0.3 version with editorial changes to
make it more like our other IPP documents and PWG standards. The -rev
versions have the revisions. In fixing the case and use of apostrophes, I
didn't keep revision marks on, so that the document with revision marks is
more readable than it would otherwise be. I've down loaded it at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-04-rev.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-04-rev.doc
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-04.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-04.doc
There are 23 issues that I found, which I'd like to go over at the IPP FAX
telecon, Wednesday, May 30, 10-12 noon PDT (see previous mail). The issues
are embedded in the document and I've extracted them here, in hopes that
some folks would like to discuss any and all of them on the mailing list
before the telecon:
ISSUE 01: Ok that I added the Validate-Job step, since Validate-Job is
REQUIRED for an IPPFAX Receiver to support?
ISSUE 02: Wouldn't "ippfax-version" (integer(0:MAX)) make a better Printer
Description attribute name for the "ippfax-receiver (integer(0:MAX)),
especially since we already have an "ippfax-receiver-identify (name(MAX))
Printer Description attribute?
ISSUE 03: Why not REQUIRE an IPPFAX Sender to validate that the Receiver is
an IPPFAX Receiver? Otherwise, the Sending User isn't guaranteed reliable
exchange.
ISSUE 04: When the IPP Printer isn't an IPPFAX Printer (either doesn't
support the "ippfax-receiver" attribute or returns a 0 value, why not
REQUIRE the Sender to query the Sending User as to whether to abandon the
exchange or do it in Degraded Mode? Currently, the Sender can do whatever
it wants without the Sending User being involved.
ISSUE 05: Can a Receiver support a remote administrator changing the value
of the ippfax-receiver (integer(0:MAX)) Printer Description attribute using
the Set-Printer-Attributes operation or should we define two OPTIONAL
operations to set the level to 0 or back to its supported level?
ISSUE 06: If we want two operations, should they be new operations or a new
operation attribute for the existing OPTIONAL Disable-Printer and
Enable-Printer operations?
ISSUE 07: The UIF format is identified using the MIME type:
'application/vnd.pwg-UIF' ( Or should we use 'image/tiff; application=uif'
or 'image/tiff; application=faxbw or 'image/tiff; application=faxcolor'
instead?).
ISSUE 08: 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?
ISSUE 09: 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?
ISSUE 10: We need to define which Print-Job operation attributes and Job
Template attributes are required for the Receiver to support.
ISSUE 11: MUST the Sender inform the Sending User that the Document as been
received successfully?
ISSUE 12: Why not REQUIRE the Sender to support Get-Notifications and
subscribing to at least the 'job-complete' event?
ISSUE 13: Ok to allow a Receiver to support a subset ('job-progress' and
'job-complete') of the REQUIRED events that IPP Notification requires?
ISSUE 14: Ok to allow a Receiver to subset the REQUIRED operations of the
IPP Notification specification and not support: Create-Job-Subscriptions,
Create-Printer-Subscriptions, Get-Subscription-Attributes,
Get-Subscription-Attributes, Renew-Subscription, or Cancel-Subscription,
even though the IPP Notification spec requires them?
ISSUE 15: Should we forbid a Receiver to support the additional IPP
Notification operations: Create-Job-Subscriptions,
Create-Printer-Subscriptions, Get-Subscription-Attributes,
Get-Subscription-Attributes, Renew-Subscription, or Cancel-Subscription?
ISSUE 16: Why are we requiring that the Sender put the identity at top of
every page? Isn't that more stringent than PSTN FAX and Internet FAX? I
thought that a Sender could do that, but that putting it on the first page
was sufficient?
ISSUE 17: Why do we have this ippfax-return-uri which is the URI of the
Receiver? Any IPP client MUST always put this same URI into the
"printer-uri" (uri) operation attribute of the Print-Job operation which the
IPP/1.1 Printer MUST copy to the "job-printer-uri" Job Description
attribute. So I suggest we delete the "ippfax-return-uri" (uri) operation
and Job Description attribute.
ISSUE 18: MUST a Receiver support this restricted form of the Cancel-Job
operation or MAY it omit support all together?
ISSUE 19: MUST a Receiver support this restricted form of the
Get-Job-Attributes operation or MAY it omit support all together?
ISSUE 20: MUST a Receiver support this restricted form of the Get-Jobs
operation or MAY it omit support all together?
ISSUE 21: Which IPP/1.1 status code to use when the IPP Printer is
configured to only accept IPPFAX operations and reject other IPP operations:
client-error-forbidden (0x0401) or client-error-not-authorized (0x0403)?
Here are their IPP/1.1 descriptions;
13.1.4.2 client-error-forbidden (0x0401)
The IPP object understood the request, but is refusing to fulfill it.
Additional authentication information or authorization credentials will not
help and the request SHOULD NOT be repeated. This status code is commonly
used when the IPP object does not wish to reveal exactly why the request has
been refused or when no other response is applicable.
13.1.4.4 client-error-not-authorized (0x0403)
The requester is not authorized to perform the request. Additional
authentication information or authorization credentials will not help and
the request SHOULD NOT be repeated. This status code is used when the IPP
object wishes to reveal that the authentication information is
understandable, however, the requester is explicitly not authorized to
perform the request. This status codes reveals more information than
"client-error-forbidden" and "client-error-not-authenticated".
ISSUE 22: Why not use the existing IPP/1.1 status code:
client-error-not-authenticated (0x0402) for when the client doesn't include
a certificate? Here is the complete IPP/1.1 description:
13.1.4.3 client-error-not-authenticated (0x0402)
The request requires user authentication. The IPP client may repeat the
request with suitable authentication information. If the request already
included authentication information, then this status code indicates that
authorization has been refused for those credentials. If this response
contains the same challenge as the prior response, and the user agent has
already attempted authentication at least once, then the response message
may contain relevant diagnostic information. This status codes reveals more
information than "client-error-forbidden".
ISSUE 23: Do the conformance tables look ok?
Thanks,
Tom
-----Original Message-----
From: gsonger@netreon.com [mailto:gsonger@netreon.com]
Sent: Tuesday, May 01, 2001 14:08
To: ifx@pwg.org
Subject: IFX> ifx spec
Hi!
At the last meeting we had so much fun with the UIF spec that we didn't get
to
the IFX spec.
In an effort to stay on schedule, I would like to solicit comments on the
DL,
rather than wait till Toronto.
Comments on the IFX spec? (Tom, I know you have at least one :)
Gail
This archive was generated by hypermail 2b29 : Fri May 25 2001 - 05:00:23 EDT