IPP Mail Archive: RE: IPP> DRV - Last Call from PWG meeting

IPP Mail Archive: RE: IPP> DRV - Last Call from PWG meeting

RE: IPP> DRV - Last Call from PWG meeting on "Internet Printing P rotocol ( IPP): Printer Installation Extension" closing on March 26, 2001

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Thu Mar 22 2001 - 19:28:11 EST

  • Next message: Michael Sweet: "Re: IPP> MED - Media Standardized Names Draft D0.4 down-loaded"

    I have another comment and some comments on comments 1-3 from the PWG
    meeting (see TH>):

    4. In section 4 Conformance, add subsection headings:

    4.1 Printer Conformance Requirements
    4.2 Client Conformance Requirements

    Then in 4.1, item 5, it is not clear how many methods a Printer MUST
    support. I suggest that only one method is sufficient, so add "at least one
    method for", so it reads:

        6. SHOULD support at least one method for the downloading of Client
    Print Support Files that have been digitally signed as described in section
    9.

    -----Original Message-----
    From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
    Sent: Thursday, March 22, 2001 15:09
    To: 'IETF-IPP'
    Subject: IPP> DRV - Last Call from PWG meeting on "Internet Printing
    Protocol ( IPP): Printer Installation Extension" 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): Printer Installation Extension" 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 1 - "client-print-support-files-supported" attribute fields, in
    the "digital-signature" entry, there can be other signature values, so
    change "Valid values are:" to "Valid value include:" to give:

    One REQUIRED LOWER-CASE 'keyword' string identifying the mechanism used to
    ensure the integrity and authenticity of this set of Client Print Support
    Files. Valid values include: 'smime', 'pgp', 'dss', and 'xmldsig' which are
    defined in [RFC2634], [RFC1991], [dss], and [xmldsig], respectively. In
    addition, the special keyword value: 'none' is valid.

    TH> There are many other fields, where additional value can be registered
    and they all have the phrase "Valid values are". I suggest that we use the
    terminology from RFC 2911, which is:

      Standard values are: ...

    Also we should add a statement to Table 1 that says that additional values
    may be registered with IANA following the procedures in section 7.

    In section 7, we need to say that additional fields values may be registered
    with IANA following the procedures for attributes in RFC 2911 and additional
    values for defined fields may be registered with IANA following the
    procedures for attribute values in RFC 2911.

    2. In 3.3.1 Get-Client-Print-Support-Files Request, Target:, the word
    "security regime" is not defined, change "security regime" to "security
    scheme" to give:

    The "printer-uri" (uri) operation attribute which is the target for this
    operation as described in [RFC2911], section 3.1.5. The client MUST use the
    URI value as the target of this operation that the Printer returns in the
    "uri" field (see Table 1) in the Get-Printer-Attributes response.
    Furthermore, the client MUST use the appropriate authorization and security
    scheme for this URI as indicated by the Printer's "printer-uri-supported",
    "uri-authentication-supported" and "uri-security-supported" attributes (see
    [RFC2911] sections 4.4.1, 4.4.2, and 4.4.3). Only if the URI returned in
    the "uri" field matches the URI that the client used for the
    Get-Printer-Attributes request MAY the client use the same HTTP connection.
    The 'ipp' URL matching rules are defined in [ipp-url] and do not include the
    query part.

    TH> The term "scheme" would be being overloaded here, since it doesn't mean
    URL scheme. Instead, I suggest the "security regime" be changed to the
    terminology we use in section 8 of RFC 2911, which is "security mechanism".

    3. In Table 1 - "client-print-support-files-supported" attribute fields, in
    the "cpu-type" entry, there are trademark, so add the following disclaimer
    at the end of the document:

    Trademarks
            Trademarks within this document are the property of their owners.

    TH> I agree.

    Thanks,
    Tom

    -----Original Message-----
    From: Manros, Carl-Uno B [mailto:cmanros@cp10.es.xerox.com]
    Sent: Friday, March 09, 2001 16:24
    To: 'IETF-IPP'
    Subject: IPP> ADM - IPP WG Last Call for "Internet Printing Protocol
    (IPP): Pri nter Installation Extension" closing on March 26, 2001

    All,

    This is a working group Last Call for the "Internet Printing Protocol (IPP):
    Printer Installation Extension". A version of this documents has been
    forwarded to the Internet Draft directory as <draft-ietf-ipp-install-02.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):
    Printer Installation Extension", 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 thoroughly discussed since
    mid 2000, and I believe that we now have working group consensus on its
    adequacy.

    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): Printer
    Installation
                              Extension
            Author(s) : H. Parra, T. Tronson, T. Hastings
            Filename : draft-ietf-ipp-install-02.txt
            Pages : 25
            Date : 02-Mar-01
            
    Various client platforms require that some setting up take place at
    the workstation before the client can properly submit jobs to a
    specific printer. This setup process is sometimes referred to as
    printer installation.

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-ietf-ipp-install-02.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-install-02.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-install-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

    ---
    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 - 19:29:22 EST