I've incorporated most of the comments and agreements on the mailing list
for the ippget Delivery Method. The updated documents are available at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.docftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.txtftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/draft-ietf-ipp-notify-get-04.txt
The .pdf version have line numbers. The -rev shown the revisions from the
previous version. Here is the Abstract:
Abstract
This document describes an extension to the Internet Printing
Protocol/1.0 (IPP) [RFC2566, RFC2565] and IPP/1.1 [RFC2911, RFC2910]. This
document specifies the 'ippget' Delivery Method for use with the "IPP Event
Notifications and Subscriptions" specification [ipp-ntfy]. When IPP
Notification [ipp-ntfy] is supported, the Delivery Method defined in this
document is one of the RECOMMENDED Delivery Methods for Printers to support.
The 'ippget' Delivery Method is a 'pull' Delivery Method with
aspects of a 'push' method as well. That is, when an Event occurs, the
Printer saves the Event Notification for a period of time called the Event
Notification Lease Time. The Notification Recipient fetches (pulls) Event
Notifications using the Get-Notifications operation. If the Notification
Recipient has selected the option to wait for additional Event
Notifications, the Printer continues to return (similar to push) Event
Notifications to the Notification Recipient as Get-Notification responses as
Events occur. This push aspect is not a true 'push', since the Printer does
not open the connect, but rather continues to return responses as Events
occur using the connection originated by the Notification Recipient.
Please send comments on the document to the mailing list. Although the
ippget spec did pass IPP WG Last Call last Fall, we are re-opening it, due
to implementation experience, especially with IPPFAX.
The IPPFAX WG is meeting, August 1, in Toronto. Since they have agreed that
ippget is the one REQUIRED Delivery Method, perhaps they can also discuss
ippget at the face to face meeting. However, please continue the good
discussion on the mailing list to see if we can get closure on the mailing
list.
I just made the IETF cutoff for Internet-Drafts for the upcoming IETF
meeting in London, August 6-10. So we may be able to get some feedback from
IETF folks too.
There are still some issues about exactly how multi-part/related is used
with Event Wait Mode in multiple Get-Notifications responses to a single
Get-Notifications request. We need to write out a complete example, after
we agree on how to do it, and include that as an appendix to the document.
ISSUE 1: Do we add an in-band end-of-segment tag to indicate the end of a
batch of Event Notifications that occur together (that would correspond to
one application/ipp part under the multi-part/related type).
ISSUE 2: Do we want to consider using Bob Herriot's new
application/multiplexed which uses lengths for chunking in the data, instead
of using multi-part/related which uses boundary strings?
See
http://search.ietf.org/internet-drafts/draft-herriot-application-multiplexed
-03.txt
Here are the changes from the previous draft:
1. Change the terminology in IPPGET not to use "push", since the term
"push" outside of IPP Notification means create the connection as well as
send. In IPPGET use the term "wait mode" instead.
2. Clarify that a Printer that supports the IPPGET Delivery Method,
MUST use HTTP chunking (HTTP/1.1 required feature) in the Get-Notifications
response if it keeps the connection open, i.e., honors the client's request
for "wait mode".
3. Clarify that "using the Get-Jobs model for returning multiple groups
of attributes" means that the Printer returns the 'end-of-attributes' (0x03)
tag exactly once at the end of the last Get-Notifications Response to
indicate that there are no more events that will come because the
Subscription Object(s) have all been cancelled/deleted.
4. Use multi-part/related for a Get-Notifications Response for Event
Wait Mode. Each batch of Event Notifications will be separate
application/ipp MIME type under the multi-part/related, but only the last
one ends with the 'end-of-attributes' (0x03) tag.
5. REQUIRE URI matching rules for ippget scheme (for example, the
scheme name and host name are case insensitive).
6. REQUIRE that a Printer MUST return the "notify-recipient-uri" value
exactly as submitted by the Subscribing Client (no case conversion or other
changes).
7. Reduce the length of the "notify-recipient-uri" attribute for ippget
to 255 octets (since this doesn't really specify a resource and an
implementation may want to keep a canonical form copy as well).
8. In order to improve the searching efficiency of all the Subscription
Objects on a Get-Notifications and to allow the client to be certain of
getting events from only one Subscription object, allow the client to supply
the "notify-subscription-id", the "notify-recipient-uri" or both operation
attributes. When the client supplies the "notify-subscription-id", the
Printer only returns events associated with that Subscription Object. The
Printer MUST support both operation attributes and MUST reject a request
which has neither and return the 'client-error-bad-request' status code. If
only the "notify-subscription-id" is supplied, the Printer MUST check that
the identified Subscription object's "notify-recipient-uri" attribute
matches the 'ippget' scheme (case insensitive).
9. Change the "notify-get-interval" (integer(0:MAX)) attribute so that
the Printer always returns it by itself in a separate Event Notifications
Attribute Group, instead of being returned in the Operation Attributes
Group. The Printer MUST return it if and only if (1) it is too busy and is
rejecting the request, (2) the client didn't ask for Event Wait Mode, or (3)
the Printer wants to leave Event Wait Mode on the first or any subsequent
response.
10. Do not generalize Get-Notifications for use with indp or mailto
Delivery Methods. REQUIRE the Printer to reject the Get-Notifications
Request if the scheme is not 'ippget'. But allow a future Delivery Method
Document to use the Get-Notifications operation if polling makes sense for
that Delivery Method
11. Don't change the Get-Notifications operation name and keep it in the
ippget spec.
12. Change the sense of the Get-Notifications "notify-no-wait" (boolean)
operation attribute to a positive "notify-wait" (boolean), so that omitted
and 'false' mean the easier non-wait operation.
13. Rename "notify-ippget-redirect" (uri) to "redirect-uri" (uri), so
that it could in principle be used for other operations.
14. Rename "suggested-ask-again-time-interval" (integer(0:MAX)) to
"notify-get-interval", to shorten it, and indicate that it is for
notification, but only events returned by the Get-Notifications operation.
15. Rename "begin-to-expire-time-interval" (integer(0:MAX)) to
"ippget-event-time-to-live", to shorten it somewhat, use recognized terms
for this concept, and indicate that it is for events, but only ippget
events.
16. Clarify that for Subscriptions that contain Job events, that the
Subscription Object that has the ippget scheme MUST stay around for the
"ippget-event-time-to-live" value and so MUST the corresponding Job object,
so that the Notification Recipient can query the Job after receiving the
'job-completed' Event Notification. (For the other Delivery Methods, the
usual Job History mechanism can be used to retain the Job objects after the
job completion, so that the Notification Recipient can query the Job object
after receiving the 'job-completed' Event Notification.)
17. Clarify that the Cancel-Subscriptions operation does not need to
keep the Subscription object after the request, no matter what kind of
Delivery Method it contains. Therefore, any events associated with the
Subscription object MUST NOT be returned by the Get-Notifications operation
after the Cancel-Subscription operation for that Subscription Object.