IFX Mail Archive: IFX> ISSUE: Is IPPFAX protocol with IPPGET

IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct mechanism?

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Sun Jan 19 2003 - 20:24:54 EST

  • Next message: Dennis Carney: "Re: IFX> ISSUE: Is IPPFAX protocol with IPPGET going to use the re-direct mechanism?"

    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.



    This archive was generated by hypermail 2b29 : Sun Jan 19 2003 - 20:25:37 EST