attachment-0001

But many of the comments (to delete) were in response to the posting of a mistaken notion that the notification redirect was redundant (and in conflict) with HTTP redirect. I'm the least likely process bigot but I have to wonder about the crooked path of this Newton's walk! ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- <table width=100%> <tr valign=top> <td> <td>"Carl" <carl@manros.com> Sent by: owner-ipp@pwg.org 07/31/2002 10:08 PM <td>                To:        <ipp@pwg.org>         cc:        "Tom Hastings" <hastings@cp10.es.xerox.com>         Subject:        RE: IPP> ADM - IPP Working Group Last Call for "(IPP): Event Notifications and Subscriptions" and  "(IPP): The 'ippget'Delivery Method for Event Notifications " by July 31, 2002        </table> <tt>All, By the end of the comment period today we have had discussions about the desirability to keep an IPP application level redirect feature or to delete it before sending the draft back to the Area Director and the IESG for further progression as standards track RFCs. It seems clear that a majority would prefer to simplify things and delete the redirect feature (even if it is optional and there is some claim that it would be easy to implement). With only one member of the WG hesitant about the removal, I declare that we have rough consensus on getting rid of the feature, and I am hereby asking the editor to remove it and produce yet another draft for sending to the IESG. Will not have any further WG Last Call on that version as it seems to be a straightforward editing task. I will be on a trip to Europe until August 13. I will send the new version to the IESG when I return. Carl-Uno Manros Chair of IETF IPP WG 10701 S Eastern Ave #1117 Henderson, NV 89052, USA Tel +1-702-617-9414 Fax +1-702-617-9417 Mob +1-702-525-0727 Email carl@manros.com > -----Original Message----- > From: owner-ipp@pwg.org [mailto:owner-ipp@pwg.org]On Behalf Of Carl > Sent: Saturday, July 13, 2002 1:37 PM > To: ipp@pwg.org > Subject: IPP> ADM - IPP Working Group Last Call for "(IPP): Event > Notifications and Subscriptions" and "(IPP): The 'ippget'Delivery Method > for Event Notifications " by July 31, 2002 > > > All, > > This is a working group Last Call for the "Internet Printing > Protocol (IPP): > Event Notifications and Subscriptions" and the "Internet Printing Protocol > (IPP): The 'ippget'Delivery Method for Event Notifications". > Versions of these documents have been forwarded to the Internet > Draft directory as <draft-ietf-ipp-not-spec-09.txt> and > <draft-ietf-ipp-notify-get-07.txt>. > > PDF and Word versions of the drafts are also posted at the ietf-ipp web > site: > >           ftp://ftp.pwg.org/pub/pwg/ipp/ > > The Last Call notice follows: > > This is a formal request for final comments within the IETF IPP > Working Group for two documents. "Internet Printing Protocol (IPP): > Event Notifications and Subscriptions" and the "Internet Printing Protocol > (IPP): The 'ippget' Delivery Method for Event Notifications", which have > earlier been forwarded to the IESG for consideration as Standards Track > RFCs. These are IPP Working Group products, which have been thoroughly > discussed since mid 1998. The latest revisions are the result of feedback > from our Area Director Ned Freed and Working Group discussions earlier > this year. The most significant change is that the 'ippget' > delivery method > is now mandated for all implementations of the IPP Event Notifications, > while additional delivery methods can be used as an option. > > The purpose of a working group Last Call is in the style of "speak now or > forever hold your peace" in case there are fundamental objections, which > have not gotten previous or adequate discussion, or minor errors > which need > correction. > > Last Calls are for a minimum of 2 weeks. The period for the Working Group > comments will close on July 31, 2002(US Pacific time reference). > > The relevant documents are: > >                  Title                                  : Internet Printing Protocol (IPP): IPP Event >                           Notifications and Subscriptions >                  Author(s)                 : R. Herriot, T. Hastings >                  Filename                 : draft-ietf-ipp-not-spec-09.txt >                  Pages                                  : 101 >                  Date                                  : 03-Jul-02 > > This document describes an OPTIONAL extension to the Internet > Printing Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910). > This extension allows a client to subscribe to printing related > Events.  Subscriptions are modeled as Subscription Objects.  The > Subscription Object specifies that when one of the specified Events > occurs, the Printer sends an asynchronous Event Notification to the > specified Notification Recipient via the specified Push or Pull > Delivery Method (i.e., protocol). > A client associates Subscription Objects with a particular Job by > performing the Create-Job-Subscriptions operation or by submitting a > Job with subscription information.  A client associates Subscription > Objects with the Printer by performing a Create-Printer-Subscriptions > operation.  Four other operations are defined for Subscription > Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew- > Subscription, and Cancel-Subscription. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipp-not-spec-09.txt > > ----- > >                  Title                                  : Internet Printing Protocol (IPP): The 'ippget' >                           Delivery Method for Event Notifications >                  Author(s)                 : R. Herriot, T. Hastings >                  Filename                 : draft-ietf-ipp-notify-get-07.txt >                  Pages                                  : 37 >                  Date                                  : 03-Jul-02 > > This document describes an extension to the Internet Printing > Protocol/1.1: Model and Semantics (RFC 2911, RFC 2910).  This > document specifies the 'ippget' Delivery Method for use with the > 'Internet Printing Protocol (IPP): Event Notifications and > Subscriptions' specification.  When IPP Notification [ipp-ntfy] is > supported, the Delivery Method defined in this document is the > REQUIRED Delivery Method for clients and Printers to support.  They > MAY support additional Delivery Methods. > The 'ippget' Delivery Method is a Pull Delivery Method.  When an > Event occurs, the Printer saves the Event Notification for a period > of time called the Event Life.  The Notification Recipient fetches > (pulls) Event Notifications using the Get-Notifications operation. > If the Notification Recipient has selected the Event Wait Mode option > to wait for additional Event Notifications, the Printer continues to > return Event Notifications to the Notification Recipient as Get- > Notification responses as Events occur using the connection > originated by the Notification Recipient. > Either the Notification Recipient or the Printer can terminate Event > Wait Mode without closing the connection. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipp-notify-get-07.txt > > Sincerely, > > Carl-Uno Manros > Chair of the IETF IPP WG > > 10701 S Eastern Ave #1117 > Henderson, NV 89052, USA > Tel +1-702-617-9414 > Fax +1-702-617-9417 > Mob +1-310-251-7103 > Email carl@manros.com > > > </tt>