IPP FAX folks,
We've been discussing the IPPGET Event Notification Delivery Method on the
IPP DL. The IPPGET Delivery Method is the REQUIRED Delivery Method for
IPPFAX. During implementation of IPPFAX, several problems have been found
in the IPPGET spec, so the IPP WG has agreed to revise it, even though it
had passed IPP WG Last Call (last Fall) and is in the IESG queue. So this
new draft addresses these problems. I suspect that we will have at least
one more draft beside this one, before we are ready to repeat the WG Last
Call.
In case you are only subscribed to the IPP FAX DL (ifx@pwg.org), here is the
announcement of the updated IPPGET Delivery Method document which will soon
be announced as an Internet-Draft. If you have comments, please send them
to the ifx DL. I'll forward them to the IPP DL. If you want to be involved
in the resulting discussions, you may want to join the IPP DL (ipp@pwg.org).
We have found in annoying to those who are subscribed to both DLs, to carry
on lengthy discussions by copying multiple DLs. The instructions for
joining the IPP DL are (copied from the IPPGET document):
IPP Web Page: http://www.pwg.org/ipp/
IPP Mailing List: ipp@pwg.org
To subscribe to the ipp mailing list, send the following email:
1) send it to majordomo@pwg.org
2) leave the subject line blank
3) put the following two lines in the message body:
subscribe ipp
end
Implementers of this specification document are encouraged to join the IPP
Mailing List in order to participate in any discussions of clarification
issues and review of registration proposals for additional attributes and
values. In order to reduce spam the mailing list rejects mail from
non-subscribers, so you must subscribe to the mailing list in order to send
a question or comment to the mailing list.
Thanks,
Tom Hastings
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Friday, July 20, 2001 15:46
To: ipp (E-mail)
Subject: IPP> Updated IPPGET Delivery Method document posted.
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.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717-rev.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.pdf
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.doc
ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-get-010717.txt
ftp://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.
This archive was generated by hypermail 2b29 : Mon Jul 23 2001 - 15:49:55 EDT