IPP Mail Archive: IPP> ADM - IPP/1.1 MOD, PRO, IIG down load

IPP Mail Archive: IPP> ADM - IPP/1.1 MOD, PRO, IIG down load

IPP> ADM - IPP/1.1 MOD, PRO, IIG down loaded

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Fri Jun 16 2000 - 02:02:41 EDT

  • Next message: Hastings, Tom N: "RE: IPP> About notification [answers to your questions]"

    The Internet-Drafts for IPP/1.1 have been announced by the IETF secretariat.
    They were updated with the fixes that our area director, Ned Freed,
    requested (see below). The various formats are available at:

    ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/draft-ietf-ipp-model-v11-07.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-000522.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-000522.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-000522.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-000522-rev.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11-000522-rev.pdf

    ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/draft-ietf-ipp-protocol-v11-06.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-000530.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-000530.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-000530.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-000530-rev.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_PRO/ipp-pro-000530-rev.pdf

    ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/draft-ietf-ipp-implementers-guide-v11-
    01.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/ipp-implementers-guide-000530.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/ipp-implementers-guide-000530.pdf
    ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/ipp-implementers-guide-000530.txt
    ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/ipp-implementers-guide-000530-rev.doc
    ftp://ftp.pwg.org/pub/pwg/ipp/new_IIG/ipp-implementers-guide-000530-rev.pdf

    I copied them to the PWG FTP site using FTP Explorer for the first time. So
    please tell me if there are any problems. This is a neat shareware program
    available for $30 at www.ftpx.com after a 30-day free trial. It provides a
    Windows Explorer interface to any FTP site and is great for storing multiple
    files and/or retrieving multiple files. Long files names and sorting by
    name, date, type, is supported, just like Explorer. Its great! Also a very
    good graphic help file.

    Tom and Bob

    Attachment: Ned Freed's comment's and our responses

    -----Original Message-----
    From: ned.freed@innosoft.com [mailto:ned.freed@innosoft.com]
    Sent: Sunday, May 21, 2000 11:39
    To: Manros, Carl-Uno B
    Cc: ned.freed@innosoft.com; Manros, Carl-Uno B; Patrik Fältström; Bob
    Herriot; Tom Hastings
    Subject: RE: ADM - IPP Working Group Last Call for "Internet Printing
    Prot ocol (IPP): Job and Printer Set Operations" closing on May 12,
    20000

    > This is very welcome news, please let us know what things you want to get
    > fixed and we will address them right away.

    OK, I've attached the list below. You'll see that quite a few are simply
    typographical. I originally felt that all of them could wait and be
    handled as RFC Editor notes but I've received some pushback today on this.
    So
    I've gone through the list and marked the ones I feel really need to be
    addressed sooner with [*]. The rest can wait if that helps any.

                                    Ned

    Model document:

    Table of contents. There are missing spaces between section numbers and
    section names.

    TH> Fixed.

    Section 2.4. The discussion of URIs seems rather dated. It isn't clear
    that URNs, even if widely adopted, are going to replace URLs, especially
    for transient things like jobs. And AFAIK URNs are the only other "flavor"
    of URI besides URLs that are presently on the table. I would suggest simply
    removing this material. [*]

    TH> Deleted the outdated sentence.

    Section 3.1.4.1. I'd suggest moving the reference to Section 4.1.8 closer
    to the top of this section. It's important that people realize where these
    language names come from sooner rather than later.

    TH> Done.

    Section 4.1.9. I think arbitrary MIME parameters besides charset need to be
    allowed here. [*]

    TH> Clarified so that any IANA MIME registered parameters can be used.

    Section 4.1.9. I'm very uncomfortable with the auto-sensing facility
    described
    here in its present form. One way to deal with this would be to provide a
    way
    for the server to return the sensed type to the client, but I don't think
    this presently exists. [*]

    TH> Added a RECOMMENDATION that Printers indicate on the job start page that
    auto-sensing was performed and what document-format was determined. Ned
    agreed with this solution.

    Section 4.4.32. GZIP references RFC 1952 which is fine, but why doesn't
    deflate reference RFC 1951?

    TH> Fixed.

    Section 4.4.32. Need a specific reference for "UNIX compress". Too much
    incompatible software out there... There's probably an appropriate reference
    in
    the HTTP stuff somewhere, or failing that in PPP.

    TH> Fixed: RFC1977 V. Schryver, "PPP BSD Compression Protocol", RFC 1977,
    August 1996.

    Section 8. The phrase "Since the security levels or the specific threats
    that
    any given IPP system administrator may be concerned with cannot be
    anticipated," seems backwards to me. Specifically, the issue here is that it
    is
    impossible to anticipate the security needs for an arbitrary setup. But "any
    given" implies a known setup, in which case the security issues are known or
    can be derived. Please change "any given" to "arbitrary" or something
    similar.

    TH> Fixed.

    Protocol document:

    Table of contents. There are missing spaces between section numbers and
    section names.

    TH> Fixed.

    The introduction should make it clear that the version numbers of IPP and
    HTTP aren't linked -- it's a natural assumption given that they are
    presently the same. [*]

    TH> Fixed.

    Section 3.1. I found this section to be quite confusing. I think it would
    help a lot to explain how the layering of attributes-tag value-tag
    name-length
    name value-length value works at the outset. Maybe if you showed the
    value-tag name-length ... stuff in your first piece of ASCII art.

    TH> Section 3.1 was re-written to remove the confusion and to make it clear
    that there is no layering.

    That's it!

    Ned



    This archive was generated by hypermail 2b29 : Fri Jun 16 2000 - 02:10:46 EDT