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