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

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

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

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

  • Next message: Hastings, Tom N: "IPP> URL - Last Call comments from the PWG meeting on "IPP: IPP URL S cheme" closing on March 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 'indp' Delivery Method for Event Notifications and Protocol/1.0"
    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 section 5.2.1 notify-recipient-uri (uri), Should we call out a
    reference to Section 12 here which is the "12 INDP URL Scheme" section?

    2. In section 11.1 Conformance Requirements for Printers, need to explain
    "why" for this conformance requirement #7:

       7. MUST convert INDP URLs to their corresponding HTTP URL forms by the
    same rules used to convert IPP URLs to their corresponding HTTP URL forms
    (see section 5 'IPP URL Scheme' in [RFC2910]).

    3. In section 12.5.2 INDP URL Comparisons, we suggest a simpler explanation
    of the comparison algorithm:

       When comparing two IPP URLs to decide if they match or not, an IPP
       Client SHOULD use a case-sensitive octet-by-octet comparison of the
       entire URLs, with these exceptions:
       
       - A port that is empty or not given is equivalent to the well-known
         port for that IPP URL (port 631);
       
       - Comparisons of host names MUST be case-insensitive;
       
       - Comparisons of scheme names MUST be case-insensitive;
       
       - An empty 'abs_path' is equivalent to an 'abs_path' of "/".
       
       Characters other than those in the "reserved" and "unsafe" sets (see
       [RFC-2396] and [RFC-2732]) are equivalent to their ""%" HEX HEX"
       encoding. For example, the following three URIs are equivalent:
       
           ipp://abc.com:631/~smith/printer
           ipp://ABC.com/%7Esmith/printer
           ipp://ABC.com:/%7esmith/printer

    Would this be more clear? "All of the URL up to the 'abs_path' MUST be
    case-insensitive. The 'abs_path' SHOULD be case-sensitive."

    Thanks,
    Tom

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

    All,

    This is a working group Last Call for the "Internet Printing Protocol (IPP):
    The 'indp' Delivery Method for Event Notifications and Protocol/1.0
    ". A version of this documents has been forwarded to the Internet
    Draft directory as <draft-ietf-ipp-indp-method-04.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 one document. The document is "Internet Printing Protocol
    (IPP): The 'indp' Delivery Method for Event Notifications and Protocol/1.0",
    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
    year.

    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 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 INDP
    Notification
                              Delivery Method and Protocol/1.0
            Author(s) : H. Parra, T. Hastings
            Filename : draft-ietf-ipp-indp-method-04.txt
            Pages : 31
            Date : 07-Mar-01
            
    The IPP 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. 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).

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-ipp-indp-method-04.txt

    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-indp-method-04.txt".

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

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

    Send a message to:
            mailserv@ietf.org.
    In the body type:
            "FILE /internet-drafts/draft-ietf-ipp-indp-method-04.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

    ------
    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:56:02 EST