IPP Mail Archive: IPP> NOT - Last Call comments from PWG mee

IPP Mail Archive: IPP> NOT - Last Call comments from PWG mee

IPP> NOT - Last Call comments from PWG meeting on "IPP: The 'ippget' N otification Delivery Method for Event Notifications" closing on March 26, 2001

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Mar 22 2001 - 18:30:50 EST

  • Next message: Hastings, Tom N: "IPP> NOT - Last Call comments from the PWG meeting on "IPP: The 'indp' Delivery Method for Event Notifications and Protocol/1.0" closing on Mar ch 26, 2001"

    I've extracted the edits that Don made at the IPP WG meeting in Tampa so
    that the mailing list can see them regarding the "Internet Printing Protocol
    (IPP): The 'ippget' Notification Delivery Method for Event Notifications"
    out for IPP WG Last Call closing on March 26, 2001. These comments are
    being treated as Last Call comments. Send any comments on these comments to
    the entire mailing list.

    1. In Table 2 - Attributes in Event Notification Content, When the '*' was
    added to the MUST for printer-current-time why was it not a double asterisk
    added to notify-user-data and a triple asterisk added to the others below

    2. In section 6.2.1 notify-recipient-uri (uri), end of section, call out a
    reference to Section 9 here which is the new section entitled "The IPPGET
    URL Scheme".

    3. In section 9.4 The IPPGET URL Scheme Character Encoding, change "host
    name or host address part" to "scheme and host or host address part". Also
    change 'path' to 'abs_path' to give:

    The 'ippget' URL scheme defined in this document is based on the ABNF for
    the URI Generic Syntax [RFC2396] and further updated by [RFC2732] and
    [RFC2373] (for IPv6 addresses in URLs). The 'ippget' URL scheme is
    case-insensitive in the scheme and host or host address part; however, the
    'abs_path' part is case-sensitive, as in [RFC2396]. Code points outside
    [US-ASCII] MUST be hex escaped by the mechanism specified in [RFC2396].

    4. End of section 9.5.1 IPPGET URL Examples, MORE EXPLANATION OF THE
    ALTERNATIVE URL FORMS (or a pointer to where it is explained) AND WHY TO USE

    5. In section 9.5.2 IPPGET URL Comparisons, SIMPLER EXPLANATION?

    6. In section 11.2 Conformance for IPP Clients, why is the following
    required for clients:

       4. MUST convert the associated 'ipp' URLs to their corresponding 'http'
    URL forms according to the rules in section 5 "IPP URL Scheme" in [RFC2910].

    -----Original Message-----
    From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
    Sent: Friday, March 09, 2001 16:23
    To: 'IETF-IPP'
    Subject: IPP> ADM - IPP WG Last Call for "Internet Printing Protocol
    (IPP): The 'ippget' Notification Delivery Method for Event
    Notifications" closing o n March 26, 2001


    This is a working group Last Call for the "Internet Printing Protocol (IPP):
    The 'ippget' Notification Delivery Method for Event Notifications". A
    version of this documents has been forwarded to the Internet Draft directory
    as <draft-ietf-ipp-notify-get-02.txt>

    PDF and Word versions of the drafts are also posted at the ietf-ipp web


    The Last Call notice follows:

    This is a formal request for final comments within the IETF IPP working
    group for one document. The document is "Internet Printing Protocol (IPP):
    The 'ippget' Notification Delivery Method for Event Notifications", which is
    being proposed for forwarding on to the IESG for consideration as Standards
    Track RFC.
    This is a working group product, which has been discussed since early 2001,
    and I believe that we now have working group consensus on its adequacy.

    The document is revision of an earlier draft that was sent to the IESG last

    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

    Last Calls are for a minimum of 2 weeks. The period for working group
    comments will close on Monday, 26 March, 2001 (US Pacific time reference),
    to allow review during the upcoming IETF50 Meeting.

    The relevant document is:

            Title : Internet Printing Protocol (IPP): The 'ippget'
                              Delivery Method for Event Notifications
            Author(s) : R. Herriot, C. Kugler, H. Lewis
            Filename : draft-ietf-ipp-notify-get-02.txt
            Pages : 30
            Date : 07-Mar-01
    The notification extension document [ipp-ntfy] defines operations that a
    client can perform in order to create Subscription Objects in a Printer
    and carry out other operations on them. A Subscription Object represents
    a Subscription abstraction. 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 Delivery Method (i.e., protocol).

    The notification extension document [ipp-ntfy] specifies that each
    Delivery Method is defined in another document. This document is one
    such document, and it specifies the 'ippget' delivery method.

    A URL for this Internet-Draft is:

    Internet-Drafts are also available by anonymous FTP. Login with the username
    "anonymous" and a password of your e-mail address. After logging in,
    type "cd internet-drafts" and then
            "get draft-ietf-ipp-notify-get-02.txt".

    A list of Internet-Drafts directories can be found in
    or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

    Internet-Drafts can also be obtained by e-mail.

    Send a message to:
    In the body type:
            "FILE /internet-drafts/draft-ietf-ipp-notify-get-02.txt".
    NOTE: The mail server at ietf.org can return the document in
            MIME-encoded form by using the "mpack" utility. To use this
            feature, insert the command "ENCODING mime" before the "FILE"
            command. To decode the response(s), you will need "munpack" or
            a MIME-compliant mail reader. Different MIME-compliant mail readers
            exhibit different behavior, especially when dealing with
            "multipart" MIME messages (i.e. documents which have been split
            up into multiple messages), so check your local documentation on
            how to manipulate these messages.

    Carl-Uno Manros
    Chair of IETF IPP WG

    Carl-Uno Manros
    Manager, Print Services
    Xerox Architecture Center - Xerox Corporation
    701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
    Phone +1-310-333 8273, Fax +1-310-333 5514
    Email: manros@cp10.es.xerox.com 

    This archive was generated by hypermail 2b29 : Thu Mar 22 2001 - 18:32:07 EST