The IPPGET spec that was sent to the IETF last Friday, 7/20, has 7 issues
that have been raised since then. I've collected them into a single note
and sent them to the IPP FAX DL (ifx@pwg.org) for their IPPFAX WG meeting in
Toronto, August 1. IPPFAX REQUIRES support of IPPGET. However, the IPPGET
spec is an IPP document, so discussion of it should go on the IPP DL. So
here are the 7 issues.
If you have a comment think about whether or not to start a new thread. If
the comment is just about one issue, I suggest a new thread.
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.
Tom
This archive was generated by hypermail 2b29 : Fri Jul 27 2001 - 20:49:39 EDT