This mail note supersedes the previous ones on suggested IPPFAX WG agenda
for the Toronto meeting. This mail note lists each document to be reviewed.
I've included the issues that are included in each document and the ones
that have come up on the mailing list this past week. I have not been able
to update the IPPGET spec with the discussion that we have had this week
after last Friday's IETF deadline (7/20). So the IPPGET spec that was sent
to the IETF last Friday and announced on Monday (7/23) should be used.
As I said before, there are three IPP FAX documents that could be covered at
the IPP FAX WG meeting. In the past, we have only been able to cover one
such document in a full day and for this meeting the PWG plenary takes up
some of the time. The IPPFAX WG will need to decide whether to focus on one
document and which one, or try to go through the issues that are raised
explicitly in each document. I suggest the latter approach.
The UIF spec has 5 issues and is in good shape.
The IFX spec has 41 issues and needs real review.
The IPPGET spec is in pretty good shape with 7 issues.
The documents are:
1. UIF spec version D0.6, John Pulera posted Wednesday, 7/25 at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06-edit.pdf
2. IFX (IPP FAX Protocol) spec version D0.6, I posted today, 7/27:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf
3. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), I posted
Monday, 7/23, at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf
4. Drafts TIFF-FX Extension 1 and Schema Extension 1
Lloyd McIntyre called our attention to last Monday, 7/23. As soon as it is
approved we can add a Profile T (JBIG2) to our UIF document. Here it is
important to send any comments to the Internet FAX DL (<ietf-fax@imc.org>)
as well as the IPP FAX DL (<ifx@pwg.org). However, sending comments can be
and should be sent individually, but needs to be done before August 4 for
the IETF meeting.
5. Look at the schedule
I'll not be attending, though Marty Joel and John Pulera will. Also Peter
Zehler will be attending from Xerox and is very familiar with IPP. John
Pulera will take care of the UIF spec. I'd be glad to help update the IFX
and IPPGET specs, but someone needs to take good notes. If someone could
answer each issue in this mail note as agreed by the group, plus whatever
else is agreed, that would be a simple way to take notes.
Here are the explicit issues in each document or that have been raised on
the mailing list this week:
1. UIF spec version D0.6, John Pulera posted Wednesday, 7/25 at:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/uif-spec-06-edit.pdf
UIF ISSUE 1. Should the capabilities discovery portion of this spec be
removed and placed into a specification that deals solely with how IPPFAX
uses capabilities discovery? Advantages: other applications interested in
using UIF simply as a data format can do so (no prohibitive excess baggage).
UIF ISSUE 2. Should we break UIF Profile C into two profiles-one to
represent a baseline grayscale configuration and the other to represent a
baseline color configuration? This way, a greater number of device
capabilities configurations would be allowed without requiring an
implementation of CONNEG. (The same could apply to UIF Profile L)
UIF ISSUE 3. Should we add the CONNEG tag "profile" and tag values
"uif-s", "uif-f", "uif-c", etc., to represent the incremental differences
between minimum capabilities strings listed in sections 4.1.2.1 through
4.1.2.5? This would cut down on the length of the CONNEG strings, especially
for the composite UIF profile M) and would make it immediately apparent from
a human's perspective any OPTIONAL features that are advertised.
Define "profile=uif-s" to mean
(& (image-file-structure=TIFF-minimal)
(MRC-mode=0)
(image-coding=MH)
(color=Binary)
(dpi=[200,300,600])
(dpi-xyratio=1) )
Define "profile=uif-f" to mean
(& (image-file-structure=TIFF-limited-uif)
(MRC-mode=0)
(image-coding=MMR)
(color=Binary)
(dpi=[200,300,600])
(dpi-xyratio=1) )
Define "profile=uif-j" to mean
(& (image-file-structure=TIFF-limited-uif)
(MRC-mode=0)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(color=Binary)
(JBIG-stripe-size=128)
(dpi=[200,300,600])
(dpi-xyratio=1) )
Define "profile=uif-c" to mean
(& (image-file-structure=TIFF-limited-uif)
(MRC-mode=0)
(color=full)
(image-coding=JPEG)
(image-coding-constraint=JPEG-T4E)
(color-subsampling="4:1:1")
(color-levels<=16777216)
(color-space=CIELAB)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(CIELAB-a-min>=-85)
(CIELAB-a-max<=85)
(CIELAB-b-min>=-75)
(CIELAB-b-max<=125)
(dpi=[200,300])
(dpi-xyratio=1) )
Define "profile=uif-l" to mean
(& (image-file-structure=TIFF-limited-uif)
(MRC-mode=0)
(color=grey)
(image-coding=JBIG)
(image-coding-constraint=JBIG-T43)
(JBIG-stripe-size=128)
(image-interleave=stripe)
(color-space=CIELAB)
(color-levels<=256)
(color-illuminant=D50)
(CIELAB-L-min>=0)
(CIELAB-L-max<=100)
(dpi=[200,300])
(dpi-xyratio=1) )
Then, for example, we can rewrite the minimum capabilities string
for UIF Profile M shown in Section 4.1.2.6 as
(| (profile=[uif-s,uif-c])
(& (image-file-structure=TIFF-MRC-limited)
(MRC-mode=1)
(MRC-max-stripe-size<=256)
(profile=[uif-s,uif-c])
(dpi=[200,300]) ) )
As another example, if we would like to advertise a Receiver that
can support UIF Profiles S, F, J with optional resolution of 1200 dpi for
the black & white profiles and optional resolution of 600dpi for the color
profile, we can say
(| (& (profile=[uif-s,uif-f])
(dpi=[200,300,600,1200]) )
(& (profile=uif-c)
(dpi=[200,300,600]) ) )
UIF Issue 4. (not in the document; see section 5.1.1) Should we change the
MIME media registration to be simply a single value for the application
parameter and add a new 'profile' parameter which is multi-valued to
indicate the profiles that are in the document?
So for a document that contains C and F on separate pages, instead of:
image/tiff; application=uif-cf
we'd have:
image/tiff; application=uif; profile=uif-c,uif-f
and for a document that contains MRC with C, L, and S, instead of:
image/tiff; application=uif-mcls
we'd have (in any order):
image/tiff; application=uif; profile=uif-c,uif-l,uif-m,uif-s
UIF ISSUE 5. (not in the document; see table 15) Profile M only lists 200**
and 300** for background and foreground layers and doesn't mention the
binary mask layer at all. We need to add the binary mask layer back in. OK
to add 400** as a REQUIRED value for all three uses? MRC requires that the
mask layer be an integral multiple (1, 2,3, ...) of the resolutions for the
background and foreground layers. If we don't add 400** as a REQUIRED
resolution, the mask layer would have to be the same as the background and
foreground layers (200 or 300) unless an OPTIONAL resolution were used.
2. IFX spec version D0.6, I posted today, 7/27:
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf
ftp://ftp.pwg.org/pub/pwg/QUALDOCS/ifx-spec-06.pdf
All of these issues are in the document:
ISSUE 01: We did a lot of name changing at the telecon. Are these
attribute names ok now? Check the TOC to see all the names together.
ISSUE 02: I'm not completely happy with the organization of the document.
Each attribute has its own section, so it appears in the TOC. Also I've
tried to put the corresponding "xxx-supported" right next to the "xxx"
attribute description, but in a separate section. However, several
operation attributes appear more than once: "ippfax-semantics",
"ippfax-profiles", and "document-format". Any suggestions or is this OK?
ISSUE 03: OK that we are using the 'ipp:' scheme for both IPP and IPPFAX
protocols?
ISSUE 04: Can 'http' scheme be used in the "printer-uri" target attribute?
Will 'http' be more likely to be configured to get through firewalls? What
can a standards track RFC say about this since IPP/1.1 REQUIRES the use of
the 'ipp' scheme?
ISSUE 05: 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 06: If an IPPFAX Receiver is configured for IPP only, should it still
accept an IPPFAX job, rather than rejecting it, but perform it with IPP
semantics? That is what an IPP/1.1 Printer would do that doesn't know about
the IPPFAX spec and the IPP Sender won't make this mistake, since it MUST
query to determine if the Receiver is currently accepting IPPFAX requests.
ISSUE 07: OK to add the new 'client-error-missing-required-attribute'
status code? The existing 'client-error-bad-request' status code isn't
sufficient, since we want to return the missing attribute rather than
indicate something wrong with what was submitted. Also the existing
'client-error-forbidden' is too mysterious, since it suggests an
authorization and/or authentication problem. In the past, missing REQUIRED
attributes are developer errors, so that the 'client-error-bad-request' was
sufficient. But this error can happen to a customer who has turned off IPP
(or the implementation only supports IPPFAX semantics). This new status
code can be used for other cases where 'client-error-bad-request' is used.
ISSUE 08: How does coloring work when more than one UIF Profile is
specified?
ISSUE 09: Should we REQUIRE the Receiver to color attributes with the
"ippfax-uif-profiles" supplied by the Sender in a Get-Printer-Attributes
operation? If yes, should we REQUIRE the Sender to supply the
"ippfax-uif-profiles" attribute in the Get-Printer-Attributes?
ISSUE 10: Should we REQUIRE the Receiver to color attributes with the
"document-format" supplied by the Sender in a Get-Printer-Attributes
operation? If yes, should we REQUIRE the Sender to supply the
"document-format" attribute in the Get-Printer-Attributes?
ISSUE 11: OK to REQUIRE the Sender to query the "ippfax-versions-supported"
Printer Description attribute, or is using Validate-Job sufficient if we
change it from SHOULD to MUST? An IPP/1.1 Printer would return success,
with the "ippfax-semantics" operation attribute in the Unsupported Group
which the Sender could check for. What about an IPPFAX Receiver that is
configured only for 'ipp'?
ISSUE 12: OK to REQUIRE the Sender to query the
"ippfax-semantics-supported" Printer Description attribute, or is using
Validate-Job sufficient if we change it from SHOULD to MUST? An IPP/1.1
Printer would return success, with the "ippfax-semantics" operation
attribute in the Unsupported Group which the Sender could check for. What
about an IPPFAX Receiver that is configured only for 'ipp'?
ISSUE 13: Need to add some more UIF Profiles for color versus gray scale
for C and L Profiles (same issue for UIF spec).
ISSUE 14: OK that we got 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 15: are these additional capabilities restricted to the OPTIONAL
capabilities in the UIF Profile according to the UIF spec ([14]), or MAY
they include other capabilities as well?
ISSUE 16: Should the UIF specification [14] add registered UIF Profile tags
so that the entire minimum string becomes a single named token. Lloyd
McIntyre thought this would be a good idea in order to shorten the strings
and make the processing easier by the Sender.
ISSUE 17: Should we add the new "ippfax-uif-profile" operation attribute to
the Get-Printer-Attributes operation and then REQUIRE the Receiver to
perform attribute coloring for the "ippfax-uif-profile" operation attribute?
Then the Sender could determine the resolutions supported for a particular
UIF Profile without having to do the CONNEG stuff?
ISSUE 18: What restrictions on the vCard content do we need to make? vCard
can have image, logos, sound!
ISSUE 19: Denial of service problem: a Sender could bog down a Receiver Job
with a huge amount of data which the Receiver is supposed to copy to the Job
object
ISSUE 20: What restrictions on the vCard content do we need to make? vCard
can have image, logos, sound!
ISSUE 21: Denial of service problem: a Sender could bog down a Receiver Job
with a huge amount of data which the Receiver is supposed to copy to the Job
object
ISSUE 22: Did we agree to delete the ippfax-sender-uri (uri) operation/Job
Description attribute in favor of depending on TLS authentication?
ISSUE 23: 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 24: Or should the spec be changed to REQUIRE the Sender to use
Validate-Job? Currently the spec only RECOMMENDS using Validate-Job and
REQUIRES that the Sender query a number of Printer Description attributes in
order to submit a job the Receiver will accept.
ISSUE 25 (for UIF document; see UIF ISSUE #4): Need to add the multi-valued
profile parameter with 'uif-x' values to the image/tiff MIME Media Type
registration and only have a single 'uif' value for the 'application'
parameter (instead of 'uif-s', 'uif-c', 'uif-l', etc.).
ISSUE 26: OK to REQUIRE the Sender to supply the "ippfax-uif-profiles" of
the document being sent? What if the Sender didn't create the document?
ISSUE 27: Need to fill in the TBD entries to indicate the IPPFAX semantics
for the Job Template attributes.
ISSUE 28: Are the entries in the Operations Conformance Table 6 correct?
ISSUE 29: What does the 'tel' scheme do for IPPFAX?
ISSUE 30: OK that we got 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 31: Is the description of this new
'client-error-missing-required-attribute' (0x0419) status code sufficient?
ISSUE 32: Do the conformance requirements look ok?
Need to register the new attributes and the new status code. Text TBD.
ISSUE 33: Need version 3.0 of vCard, since it is an RFC, while version 2.1
is not.
ISSUE 34: Is this example accurate? The phone number format seem wrong.
ISSUE 35 (repeat): What vCard restrictions? No pictures, no logos, no
sound?
ISSUE 36: What other Receiver attributes should go in the Generic Directory
Schema for an IPPFAX Receiver?
ISSUE 37: OK that it is of abstract type printer?
ISSUE 38: Should the concrete type be 'IPP' (since the 'ipp' scheme is
being used), or 'IPPFAX' to differentiate it from an IPP Printer?
ISSUE 39: Is the conformance right?
ISSUE 40: Should we add authors to PWG standards like we do IETF RFCs?
ISSUE 41: Should we add participants to PWG standards like we do IETF RFCs?
3. IPPGET Delivery Method (<draft-ietf-ipp-notify-get-04.txt>), I posted
Monday, 7/23, at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf
ISSUE 01 (see section 12): Should we use application/multiplexed
(draft-herriot-application-multiplexed-03.txt) which can chunk mime types
using content lengths, instead of multi-part/related, which uses boundary
strings?
ISSUE 02: For Event Wait Mode, OK to make each successive response after
the first a complete IPP response, instead of just the Event Notification
Attributes Groups?
Then each response looks like a complete response with its own status code.
Also complete responses might be necessary on some other transport. Also we
can move the "notify-interval" attribute back to the Operation Attributes
Group where it belongs, since it applies to all events being returned in
that response.
ISSUE 03: OK to clarify that the Per-Job Subscription Object and the
associated Job object MUST persist after the job completes (job completed,
canceled, or aborted) in the Job Retention or Job History phases (see
[RFC2911] section 4.3.7.2)?
Otherwise, a Notification Recipient that is polling would not get the Event
Notification, if it polled after the job completed, but before the Event
Lease Time expired.
ISSUE 04: OK to clarify that a client or a Printer MAY disconnect the
underlying transport connect for any operation, including the Event No Wait
Get-Notifications operation and the Event Wait Get-Notifications operation
when the Printer isn't willing to honor the initial request or reneges in a
later response?
So a client could keep the connection open for multiple Event No Wait
Get-Notifications. Before a Printer disconnects it needs to wait enough
time to make sure that any IPP response has had time to get back to the
client before disconnecting, otherwise the client might not see the
response.
ISSUE 05: OK to add 'successful-ok-events-complete' status code for a
Get-Notifications response whether Event No Wait or Event Wait mode?
Here is more detail:
The Printer MUST return the 'successful-ok-events-complete' status code to
indicate when this return is the last return for all Subscription objects
that match the request, whether or not there are Event Notifications being
returned. This condition occurs for Event Wait Mode Notification Recipients
waiting for responses when the Subscription Object is: (1) canceled with a
Cancel-Subscription operation, (2) deleted when the Per-Printer Subscription
lease time expires, or (3) when the 'job-completed' event occurs for a
Per-Job Subscription. This condition also occurs for a Get-Notifications
request that a Notification Recipient makes after the job completes, but
before the Event Lease Time expires.
Here is a complete table of combinations of "notify-wait", "status-code",
"notify-interval", and Event Notification Attributes Groups for
Get-Notification initial (Wait and No Wait) Responses and subsequent Event
Wait Mode Responses (which may be staying in Wait Mode or may be requesting
the Notification Recipient to leave Wait Mode):
Event
client sends: Printer returns: Notification
"notify-wait" "status-code" "notify-get-interval" Attribute Groups
------------- ------------- --------------------- ----------------
1.'false'/omitted 'successful-ok' MUST return N maybe
2.'false'/omitted 'not-found' MUST NOT MUST NOT
3.'false'/omitted 'busy' MUST return N MUST NOT
4.'false'/omitted 'events-complete' MUST NOT 'job-completed'
5. 'true' 'not-found' MUST NOT MUST NOT
6. 'true' 'busy' MUST return N MUST NOT
7. 'true' 'successful-ok' MUST NOT MUST
8. 'true' 'successful-ok' MUST return N maybe
9. 'true' 'events-complete' MUST NOT 'job-completed'
or maybe other
Explanation:
1-4: client requests Event No Wait
5-9: client request Event No Wait
2,5: Subscription object not found, or was canceled earlier; client should
NOT try again.
3,6: server busy, tells client to try later; client should try again in N
seconds.
4: client polled after job completed, but before Event Lease Time expired,
and got the 'job-completed' event, so the client shouldn't bother trying
again; client should NOT try again later.
7: Printer returns one or more Event Notifications and is ok to stay in
Event Wait Mode; the client waits for more.
8: Printer wants to leave Event Wait mode. Can happen on the first
response (with events) or happen on a subsequent response with or without
Event Notifications; the client should try again in N seconds.
9. Printer either (1) returns 'job-completed' event or (2) the Subscription
Object was canceled by either a Cancel-Job or a Per-Printer Subscription
expired without being renewed. For case (1), at least one event MUST be
returned, while for case (2), it is unlikely that any Events are returned;
the client should NOT try again.
ISSUE 06: Section 12 says: "The Printer MAY chunk the responses, but this
has no significance to the IPP semantics." Is this sufficient, or is
HTTP/1.1 chunking REQUIRED in order to support the multi-part/related MIME
type?
ISSUE 07: For Event No Wait mode, should we add a way for the Notification
Recipient to have the Printer filter out returning Event Notifications that
the Notification Recipient has already received in order to reduce the
duplicates (that will usually happen, else events will be lost)? Or should
we just depend on most usage using Event Wait Mode, so that there aren't
duplicates? It has been suggested on the mailing list that the Notification
Recipient could supply pairs of the "notify-sequence-number" and
"subscription-id" and the Printer would only return events with a higher
sequence number.
4. Drafts TIFF-FX Extension 1 and Schema Extension 1
Lloyd McIntyre called our attention to last Monday, 7/23. As soon as it is
approved we can add a Profile T (JBIG2) to our UIF document. Here it is
important to send any comments to the Internet FAX DL (<ietf-fax@imc.org>)
as well as the IPP FAX DL (<ifx@pwg.org). However, sending comments can be
and should be done individually, but needs to be done before August 4 for
the IETF meeting. Are there any comments from the WG to be sent?
5. Review Schedule for these documents (all were supposed to be complete by
June 2001 and the Bakeoff was supposed to be September 2001, January 2002
was revised specification from the Bake Off and a possible Implementer's
Guide was supposed to be finished January 2002.
Tom
This archive was generated by hypermail 2b29 : Fri Jul 27 2001 - 20:22:11 EDT