IPP Mail Archive: IPP> Last Call comment to remove redirect

IPP Mail Archive: IPP> Last Call comment to remove redirect

IPP> Last Call comment to remove redirect URL and status code from IPP GET

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Wed Jul 17 2002 - 21:21:01 EDT

  • Next message: Hastings, Tom N: "RE: IPP> Errata in RFC 2911: "Internet Printing Protocol/1.1: Mod el and Semantics""

    Ira McDonald and I were talking about the IPPGET which has a "redirect-uri"
    operation attribute that MAY be returned in a Get-Notifications response
    when the 'redirection-other-site' status code returned. Here is all of the
    text in the document that deals with redirection:

    5.2 Get-Notifications Response

    redirection-other-site: The Printer does not handle this operation and
    requests the Notification Recipient to perform the operation again with the
    uri specified by the "redirect-uri" Operation Attribute in the response.
    See section 10.2.

    5.2.3 redirect-uri (uri)

    The value of this attribute is the uri that the Notification Recipient MUST
    use for a subsequent Get-Notifications operation. The Printer MAY support
    this attribute. This attribute MUST be returned in the Operation Attributes
    Group if and only if the Printer returns the 'redirection-other-site' status
    code (see section 10.2).

    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.

    12.1 Printer Conformance

    8. MUST support the "redirection-other-site" status code defined 10.2,
    if it redirects Get-Notifications operations;

    Presumably a client MUST support the 'redirection-other-side' status code if
    it ever is returned by a Printer in a Get-Notifications response, though
    section 12.2 Client Conformance doesn't mention this.

    We suggest that we delete all of the above text from the IPPGET spec, so
    that there is no redirect status code and no "redirect-uri" operation
    attribute for the following reasons:

    1. The HTTP Layer already has redirect for all operations, not just
    Get-Notifications. Introducing a competing redirection mechanism into the
    application layer seems a mistake. What happens if they both occur?

    2. Redirection has a number of problems for Get-Notifications, in that if a
    Printer is using a Notification Server to return events, along with other
    Printers, then getting job attributes from the Job object on a job event
    means that the job-ids for each of the Printers have to be allocated in a
    non-conflicting way for each of the Printers. Or alternatively, the Printer
    needs to return not only a "redirect-uri", but also possibly a new-job-id,
    if the job id has changed.

    3. If we ever wanted to put IPP semantics on another transport, we can
    decide then whether to introduce the redirection concept into IPP
    application layer for all operations (and fix the problems listed above) or
    use the transport's redirect mechanism.

    4. Removing this redirect mechanism makes it simpler for a client using
    Get-Notifications, since the client won't have to deal with it. And since
    IPPGET is proposed to be the REQUIRED notification method, simplifying
    IPPGET for clients is a good idea.

    Comments?

    Tom

    -----Original Message-----
    From: Carl [mailto:carl@manros.com]
    Sent: Saturday, July 13, 2002 13:37
    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 : Wed Jul 17 2002 - 21:21:48 EDT