attachment-0001

Tom, consensus at the f2f is that redirect is in play for IPP FAX. In otherwords, it will be mandatory for the client to support. Reasoning is that there are no existing IPP FAX clients in existence, today so this requirement will not break existing clients (as it would have in the general IPPGET submission to the IETF. ---------------------------------------------- Harry Lewis IBM Printing Systems ---------------------------------------------- <table width=100%> <tr valign=top> <td> <td>"Hastings, Tom N" <hastings@cp10.es.xerox.com> Sent by: owner-ifx@pwg.org 01/20/2003 02:29 PM <td>                To:        Dennis Carney/Boulder/IBM@IBMUS, "Hastings, Tom N" <hastings@cp10.es.xerox.com>         cc:        ifx@pwg.org         Subject:        RE: IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the r        e-direct mechanism?</table> <tt>Dennis, Yes, an IPPFAX Sender would be required to support redirection, IF an IPP Sender has to conform to all of the requirements of IPPGET.  The overhead for an IPPFAX Sender is minimal.  It just has to look for the status code that says the Printer is redirecting Get-Notification requests to a Server, in which case the Sender just tries the Get-Notifications again at the new URL. On the other hand, since the IPPFAX protocol has removed REQUIRED operations from IPP, such as Cancel-Job, it would be possible for the IPPFAX Protocol spec to rule out the REQUIRED redirection from IPPGET.  Hence, my issue. Tom -----Original Message----- From: Dennis Carney [mailto:dcarney@us.ibm.com] Sent: Monday, January 20, 2003 07:03 To: Hastings, Tom N Cc: ifx@pwg.org Subject: Re: IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct mechanism? Tom, The way the spec is written, it seems that an IPPFAX Sender would be required to support redirection in any case. The spec says (section 2.1):   Statement (sic) of the form "the IPP Client MUST ..." apply if the   client supports the IPPGET Event Delivery Method, since this extension   is REQUIRED if the client supports the IPPGET Delivery Method. This is more an issue with the spec than with IPPFAX, but isn't it illegal/impossible to add required extensions? Dennis                      "Hastings, Tom N"                      <hastings@cp10.es        To:       ifx@pwg.org                      .xerox.com>              cc:                      Sent by:                 Subject:  IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct   mechanism?                              owner-ifx@pwg.org                      01/19/03 06:24 PM Here is an issue I sent out on October 11, but there has been no answer. ISSUE 05: for the IPPFAX WG, which is REQUIRING support of IPPGET Delivery Method:  Is redirection an option of an IPPFAX Receiver?  If yes, then the IPPFAX Sender MUST support redirection as specified in this document. The spec which has the redirect mechanism in it is: [not-srv],  "Distributed Notification Service and IPPGET Client Behavior", Hastings, T., Lewis, H., and I. McDonald, October 10, 2002, work in progress, ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-dist-not-service-021010.pdf Thanks, Tom -----Original Message----- From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com] Sent: Friday, October 11, 2002 15:14 To: ipp@pwg.org Cc: ifx@pwg.org Subject: IFX> NOT - New PWG IPP Distributed Notification Service and IPPGET Client Behavior available Ira McDonald, Bob Herriot, Harry Lewis, Carl Kugler, and I have made a number of passes over the new PWG draft standard 5100.6-D0.1.  Its entitled: "IPP Distributed Notification Service and IPPGET Client Behavior".  It has the redirection mechanism that was removed from the IETF IPPGET Delivery Method spec.  The conformance requirements for IPPGET clients is unchanged in this document from what they were in the IETF IPPGET draft.  We think the redirection mechanism is still very sound from a security point of view, but we're being cautious by moving it to this PWG spec, while we send the IETF IPPGET and Base Notification spec drafts forward to the IESG. ISSUE for the IPPFAX WG, which is REQUIRING support of IPPGET Delivery Method:  Is redirection an option of an IPPFAX Receiver?  If yes, then the IPPFAX Sender MUST support redirection as specified in this document. The files are available at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-dist-not-service-021010.pdf ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-dist-not-service-021010.doc Here is the Abstract: Abstract: This document specifies an OPTIONAL IPP Distributed Notification Service for use with the "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" specification (ipp-ntfy).  This IPP Distributed Notification Service enables multiple trusted IPP Printers to off-load IPP Event Notification Delivery to a shared Notification Server for any Event Delivery Method.  The Notification Server (instead of the Printer) deals with the burden of delivering Event Notifications.  For the IPPGET Delivery Method (get-method), the Notification Server, rather than the IPP Printer, takes over the burden of keeping a large number of long duration connections open for outstanding Get-Notifications operations. This document also specifies additional REQUIRED behavior for any client supporting the IPPGET Delivery Method. Conformance:  This extension is REQUIRED for all IPP clients that support the IPPGET Event Notification Delivery Method.  This extension is OPTIONAL for IPP Printers that support the IPPGET or any other Event Notification Delivery Method. Ira McDonald has written a companion spec for the protocol between the Printer and the Notification Server which we will post shortly as another PWG Draft.  Its entitled: "Distributed Notification Service - Printer to Notification Protocol (PNSP).  We briefly considered combining them, but didn't because using PNSP isn't required in order to redirect the Get-Notifications request.  Also having too many conformant interfaces in a single document becomes too cumbersome to understand which statements apply to which interface. Here are the Changes from the redirection in the original IPPGET Delivery Method [get-method]: 17.1         Changes from [get-method] to make version 0.1             1.          Invented the title:  "The Printer Working Group Standard for Internet Printing Protocol (IPP): Distributed Notification Service and IPPGET Client Behavior"             2.          Removed this redirection functionality from the IETF IPPGET [get-method] specification and put it in this document.             3.          Section 2.2: Defined "IPPGET Client", "Notification Server", and "Distributed Notification Service" terms.             4.          Clarified that this specification is the Interface between an IPP Client and a Distributed Notification Service, in case the IPP Printer exercises the option of using a Notification Server to deliver Event Notifications.             5.          Section 5.3: Maintained the client requirement to support the redirection for any client that supports the IPPGET Event Delivery Method (see [get-method]).  In other words, any client that supports the Get-Notifications operation is required to support the redirection in case the Printer exercises this option.             6.          Clarified that this Notification Server may deliver Event Notifications for any Push Delivery Method and for the IPPGET Pull Delivery Method.             7.          Section 4.1: Added the "printer-notify-server-uri" (1setOf uri) Printer Description attribute so that the Printer could be configured for none ('no-value' out-of-band value), one, or more than one Notification Server.             8.          Sections 5.2 and 6.1: Clarified that the "redirect-uri" (uri) operation attribute and the 'redirection-other-site' status code are for use with the Get-Notifications operation response only, but could be used by operations defined in the future or existing operations if the IPP protocol minor version number incremented.             9.          Section 5.1: Clarified that the Printer MAY return the "redirect-uri" (uri) operation attribute depending on any implementation-defined reasons which could be dynamically varying.  Gave examples, such as on the number of open channels and the authorization of the user.             10.         Section 7.3: Added conformance requirements for a Notification Server, acting in combination with a Printer, to provide a Distributed Notification Service.             11.         Section 15:  Added the Informative Appendix that describes PNSP. </tt>