Attendees: Gail Songer, Peter Zehler, Ira McDonald, John Pulera, Tom
Hastings
Regrets: Bill Wagner, Harry Lewis
On the telecon today we reviewed the Draft D0.4, May 24, 2001 "IPP FAX
Protocol" document:
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
Tom Hastings will update the IFX document with these agreements and the ones
from last weeks telecon. John Pulera will update the UIF document with the
agreements from last week. John and Tom will proof read each others work
with Ira's help. Then publish the updated documents for a telecon the end
of June.
The agreements are preceded by TH>:
ISSUE 01: Ok that I added the Validate-Job step, since Validate-Job is
REQUIRED for an IPPFAX Receiver to support?
TH> Yes
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?
TH> Rename to "ippfax-versions-supported" (1setOf type2 keyword). Structure
the keyword as with IPP version, namely major.minor, and append either
'unauthorized' or 'authorized'. The former corresponds to what we agreed to
as 'uif-only' last week. Also have a 'none' value which means that the
Printer behaves as a normal IPP Printer. So the standard keyword values
are:
'1.0.unauthorized' - UIF only
'1.0.authorized' - includes authorization
'none' - normal IPP behavior
Also define a "ippfax-version" operation attribute to Get-Printer-Attributes
with the same values which "colors" the responses to such attributes as
"copies-supported", "document-formats-supported", etc.
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.
TH> Agreed.
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.
TH> Agreed (for the renamed "ippfax-versions-supported")
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?
TH> Yes, a Receiver MAY support a remote administrator using
Set-Printer-Attributes to change the (current) versions supported to get
different behavior, such as making the Receiver be an IPPFAX only printer
and not a regular IPP Printer. Don't define new operations. Enable-Printer
and Disable-Printer affect IPPFAX jobs as well.
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?
TH> Moot.
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?).
TH> We agreed same as last week to use the 'image/tiff; application=faxbw or
'image/tiff; application=faxcolor' MIME media types.
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?
TH> Raise on the mailing list to use '1setOf text(MAX)'. Each value
represents a text token with white space between values. Need to read VCARD
spec to see what separates "lines".
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?
TH> Raise on the mailing list to use '1setOf text(MAX)'. Each CONNEG value
represents a text token with white space between values. This aligns with
CONNEG semantics.
ISSUE 10: We need to define which Print-Job operation attributes and Job
Template attributes are required for the Receiver to support.
TH> All the operation attributes that IPP/1.1 requires are required for IPP
FAX.
The "media" and "resolution" Job Template attributes are required for IPP
FAX. If the "resolution" differs from that in the TIFF/FX data, then the
TIFF/FX data wins. The "resolution-supported" Printer attribute MUST
indicate the resolutions supported in any profile AND profile S MUST support
all of them (other profiles NEED NOT).
The "copies-supported" attribute, if supported, MUST only support the value
1 for:
'1.0.unauthorized' - UIF only
'1.0.authorized' - includes authorization
Any other Job Template attribute MAY be supported by an IPPFAX Receiver.
ISSUE 11: MUST the Sender inform the Sending User that the Document as been
received successfully?
TH> yes.
ISSUE 12: Why not REQUIRE the Sender to support Get-Notifications and
subscribing to at least the 'job-complete' event?
TH> Agreed, but MUST support all of the IPP Notification REQUIRED events,
which are:
'none', 'printer-state-change', 'printer-stopped', 'job-state-change',
'job-created', and 'job-completed'.
ISSUE 13: Ok to allow a Receiver to support a subset ('job-progress' and
'job-complete') of the REQUIRED events that IPP Notification requires?
TH> Disagreed; MUST support all of the IPP Notification REQUIRED events,
which are:
'none', 'printer-state-change', 'printer-stopped', 'job-state-change',
'job-created', and 'job-completed'.
ISSUE 14: Ok to allow a Receiver to subset the REQUIRED operations of the
IPP Notification specification and not support: Create-Job-Subscriptions
(OPTIONAL),
Create-Printer-Subscriptions, Get-Subscription-Attributes,
Get-Subscriptions, Renew-Subscription, or Cancel-Subscription,
even though the IPP Notification spec requires them?
TH> Agreed.
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?
TH> No.
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?
TH> Because its required for PSTN FAX. So delete this issue.
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.
TH> Agreed. Delete "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?
TH> It MUST either support the restricted form (administrators only) or NOT
support Cancel-Job on IPPFAX jobs at all.
ISSUE 19: MUST a Receiver support this restricted form of the
Get-Job-Attributes operation or MAY it omit support all together?
TH> The attributes that Get-Job-Attributes returns should be policy, not
part of the protocol spec, so delete and mention that which attributes are
returned depends on policy and implementation.
ISSUE 20: MUST a Receiver support this restricted form of the Get-Jobs
operation or MAY it omit support all together?
TH> Same.
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".
TH> Use client-error-not-authorized (0x0403) instead.
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".
TH> Agreed to use client-error-not-authorized (0x0403) instead of adding a
new status code which divides the cases.
ISSUE 23: Do the conformance tables look ok?
TH> Leave as an issue for broader review.
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 : Wed Jun 06 2001 - 22:11:21 EDT