IFX Mail Archive: IFX> Attempt to close on the two Notificat

IFX> Attempt to close on the two Notification specs at the face to fac e meetings

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Aug 23 2002 - 22:54:28 EDT

  • Next message: McDonald, Ira: "RE: IFX> Attempt to close on the two Notification specs at the fa ce to fac e meetings"

    The IPP WG Last Call period closed July 31 on the two IPP Notification specs
    that are required for IPP Notification:

    (1) IPP Event Notifications and Subscriptions
    <draft-ietf-ipp-not-spec-09.txt>
    (2) The 'ippget' Delivery Method for Event Notifications
    <draft-ietf-ipp-notify-get-07.txt>

    and Carl-Uno declared that (1) was approved, since there were no comments
    and that (2) achieved consensus to drop the redirection mechanism entirely
    from the IPPGET document.

    However, we have continued discussion about the merits and problems of the
    redirection mechanism because Harry Lewis has been the main objector to
    removing the redirection mechanism from IPPGET. As a result I have not yet
    produced a new version of the document and Carl-Uno has not forwarded either
    of the documents to Ned Freed, our Area Director.

    If we keep redirection in, there are still two changes to the document
    needed:

    1. Add a client conformance requirement to re-try the Get-Notifications if
    Printer returns the "redirect-uri" attribute and the
    'redirection-other-site' (0x0300) status code. Otherwise, we don't get
    interoperability with all clients if the Printer returns a redirection.

    2. It has been suggested that there is an issue about client caching of the
    redirection URI (though I don't see why, since the Printer wants the client
    to always use the Notification Server). HTTP has something about client
    caching and the IETF will probably comment on IPPGET client caching, further
    delaying our document. Bob has suggested that the client SHOULD NOT cache
    the redirection-uri. The current draft section 10.2 has a sentence that
    suggests that the client MUST cache the redirection URI:

      "10.2 redirection-other-site (0x0300)

      This status code means that the Printer doesn't perform that
      Get-Notifications operation and that the "redirect-uri" operation
    attribute
      (see section 5.2.3) in the response contains the uri that the Notification
      Recipient MUST use for performing the Get-Notifications operation. If the
      client issues subsequent Get-Notifications operations, it MUST use the
    value
      of the "redirect-uri" operation attribute returned by the Printer as the
      target of the operation."

    The justification for the redirection mechanism is to off load the support
    of the IPPGET Delivery Method from a Printer to a Notification Server that
    could be used by multiple Printers. Do we really know how hard it is for a
    Printer to support IPPGET itself? After all, it is just a polling method
    that the client uses.

    Since the IPPFAX protocol is using the IPPGET, perhaps some implementors
    have some real experience with IPPGET. How hard is it to do in the Printer
    itself? Would it help a Printer implementation, if it could offload IPPGET
    support?

    Therefore, Carl-Uno and I ask the IPPFAX WG to consider at its face-to-face
    IPPFAX WG meeting on Monday AM Aug 26 whether there is sufficient
    justification for going against the IPP WG Last Call consensus to delete the
    redirection mechanism. And then to bring a recommendation to the PWG
    Plenary Tuesday AM Aug 27 (with possible more discussion of people not
    involved in IPPFAX)?

    The technical discussion has revealed the following points:

    1. The HTTP redirection mechanism can't be used for IPPGET to have a
    Notification Server handle the Get-Notifications request for the Printer,
    since HTTP redirect would redirect all IPP requests, not just the IPPGET
    request.

    2. There are several ways that the Notification Server can determine for
    which Printer the redirected IPPGET request is for, without needing to add
    anything more to the Get-Notifications request or response. So supporting
    redirection in the Printer does seem to hang together.

    3. What are we going to say about client caching of the redirect-uri?

    4. Support by a Printer of a Notification Server is purely an implementation
    matter and doesn't affect the IPPGET interface, as long as the client always
    honors the redirection returned by the Printer.

    Process considerations:

    Could we delete the redirection mechanism for now from IPPGET? Get our RFC
    published as a Proposed standard. Implement IPPGET and do interoperability
    testing. See if the burden in the Printer of supporting the IPPGET method
    justifies offloading it to a Notification Server using the redirect
    mechanism. If the implementation experience shows that its not much of a
    burden in the Printer we made the right decision to delete redirection. If
    implementation experience shows that having a Notification Server is
    important to off-load the Printer's support of the IPPGET method, then add
    the redirection back into the IPPGET spec before progressing the document to
    a Draft standard. Perhaps in the meantime, IBM can also implement the
    Notification Server and see if it is really a win and that the extra
    administrative effort is worth the benefit to simplifying the Printer
    implementation.

    Comments?

    Tom

    -----Original Message-----
    From: Carl [mailto:carl@manros.com]
    Sent: Wednesday, July 31, 2002 21:09
    To: ipp@pwg.org
    Cc: Tom Hastings
    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

    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
    >
    >
    >



    This archive was generated by hypermail 2b29 : Fri Aug 23 2002 - 22:55:34 EDT