Keith,

Based on a series of phone conferences and discussions on the IPP DL,
including the phone conference in which you and Patrick Fältström 
participated, and intermediate drafts from the editors, here is the 
complete WG response to your earlier comments on the IPP drafts.

The full set of IPP documents now includes:

- Design Goals for an Internet Printing Protocol [IPP-REQ] (informational)
- Rationale for the Structure and Model and Protocol for the Internet
     Printing Protocol [IPP-RAT] (informational)
- Internet Printing Protocol/1.0: Model and Semantics [IPP MOD]
- Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
- Mapping between LPD and IPP Protocols [IPP LPD] (informational)

Please note that we changed the names on two of the documents

- We changed the name of the Requirements document to: 
  "Design Goals for an Internet Printing Protocol"

- We changed the name of the Protocol document to:
  "Internet Printing Protocol/1.0: Encoding and Transport"

The latter change had been suggested in the WG, as it better reflects
the actual content of that document.

The editors have also taken the opportunity to fix a number of minor
inconsistencies and have added a few clarifications in response to
comments back from implementors, since the earlier drafts were published
in January 1998. We do not think that any of these minor changes will 
require further review from your side.

We now have complete WG consensus for these revised IPP drafts. 
I hope that you are also satisfied with the resolutions to your comments.

On behalf of the IETF IPP WG,

Carl-Uno Manros

-----

Here follows the detailed response to your earlier comments
===========================================================

WG responses are indicated by starting the paragraph off with 
"WG>".

--

At long last I've completed my review of the IPP documents.
My comments follow.

Please note that we're still waiting for the TLS document
to clear (sigh)... things that depend on TLS can't go
through until TLS is finished.  Last I heard they were waiting
on resolution of some patent issues and/or an X.509 profile
that allowed use of UTF-8 in printable strings.  (yeech)

WG> Last we heard was that the PKIX drafts are out for Last
Call in the WG. The latest draft is now out as an I-D.

I apologize for this haven taken so long.

Keith

summary:

Basically I think the protocols are mostly sound, though the 
documents need some editorial cleanup.  There are some minor 
technical tweaks here and there.

The biggest change that I think is needed, is that IPP's use
of HTTP doesn't allow a firewall to distinguish between IPP
traffic and ordinary HTTP traffic.  Also, IPP's insistence on
using port 80 could conflict with ordinary use of that port, in 
those cases where the IPP server was not designed to "plug in" to
the HTTP server.  For these reasons, I suggest that a separate
port be allocated for IPP, and an "ipp" URL defined which defaults
to the IPP port rather than port 80.  An alternative would be to
have IPP use the PRINT method rather than POST, but to me the
separate port seems cleaner and more likely to be compatible 
with firewalls.  One could still use IPP on port 80, by using 
the port override notation: ipp://hostname:80/etc.

WG> As discussed in the phone conference with you, the WG has 
accepted the proposal to define a Well Known Port for IPP.
IANA has already allocated port 631 for that purpose, which
is reflected in the Internet Printing Protocol/1.0: Encoding 
and Transport draft. After study, the WG decided that 
introducing a separate "ipp:" scheme would bring more problems 
than it solves, and does not really add anything else than
some potential marketing value. E.g. adding an extra parameter 
for security would have made the scheme different from "http:",
and would have led to difficulties to map HTTP URLs back to 
IPP URLs. Use of a PRINT method did not find sufficient
support by the WG and was dropped as a solution.

Note that we now have in effect a policy of not allocating
separate ports for with/without TLS.  (I've asked the security 
ADs in IESG to review this policy, but I think it will be upheld.)  
Someone has an internet-draft which attempts to define a way
to negotiate TLS in-band over HTTP; you might want to look at that.

WG> The IPP solution does not assume one or the other. IPP allows
for several URLs to be defined for the same printer object, with
different associated security protocols. This is quite flexible
and does not make any assumptions about the exact scheme used in 
the URLs, or whether they are indeed identical URLs. This also
allows for the use of existing non-standard schemes like "https:" 
as interim solutions, until TLS becomes more accessible in the 
market place.

Similarly, using the "s" suffix on the URI type to indicate TLS/
is considered by many to be a Bad Idea; if it's necessary to specify
a particular authentication and/or encryption type, it should 
probably be done using a URI parameter.  (and it should probably 
be more flexible than just ";security=tls")

WG> See earlier comment. We have removed all instances of "https:",
except as a possible (non-standard) value for security schemes.
We do not consider it appropriate for this WG to add new
parameters to the "http:" URL scheme.

Detailed comments follow; I apologize for mixing the purely
editorial (most of the comments) with the technical issues,
and thus making this unnecessarily tedious to read for anyone 
other than the authors.  but this way, I get to cross this off 
my list today!

general:

1. In addition to the keywords defined in RFC 2119, the documents 
use a number of upper case terms like SHALL, SHALL NOT, NEED NOT,
etc.  If these terms are in upper case because they have special 
meanings, those meanings need to be defined somewhere, and each
document that uses those terms needs to have a prominent notice
(i.e. near the beginning of the document) pointing to those 
definitions.  If the terms have their normal meanings (which
from my reading seems to be the case), they should be spelled in 
lower case, unless there is some reason to emphasize a particular
use of a term.

WG> In reading RFC 2119, we found that these terms are often 
capitalized and uses that in RFC 2119 itself. We have removed
the capitalization in a number of cases, where the words do
not have a special meaning.

On the other hand, it appears that SHALL etc. are sometimes used 
when one of the words in RFC 2119 would do just as well.  It would
be better to keep consistent technology unless there's a good 
reason not to do so. 

WG> We have changed all SHALLs to MUSTs to make it more consistent,
and changed MANDATORY to REQURIED to align with RFC 2119.

Note that the keywords in RFC 2119 are generally used to indicate
implementation choices that would affect compliance with a standard,
or very occasionally, requirements for operation of the service 
(as in "SMTP servers MUST accept mail addressed to Postmaster")   
Other uses of "MUST", "SHOULD", etc. should generally use lower 
case letters.  For instance, the IPP design goals "MUST" be
satisfied in IPP/1.0...this is not a requirement on implementation,
and should be spelled "must".

WG> We have removed the capitalization in a number of cases, where 
the words are not a conformance requirement.

Finally, if you need to use one of these upper cased keywords
with "not", it should be "MUST NOT" or "SHALL NOT", rather
than "MUST not" or SHALL not  (or even "SHALL also not")
to have one word upper cased and the other not, is confusing.

WG> Has been done.

2. there appear to be a number of artifacts in the plain text 
versions of the documents, which may have resulted from 
conversion to text from some other format.  For instance, tables
are poorly formatted in the text version, I saw at least one 
instance of overprinting, and there appear to be missing pieces
of text here and there.  

Since the plain text versions are considered authoritative, they
need to be carefully proofread.  

WG> We believe that this has now all been corrected. 

draft-ietf-ipp-rat-02.txt:

1. the last paragraph (9) of section 4 may need tweaking depending
on whether IPP is revised to use a different default port than
HTTP< or if it's revised to use PRINT instead of POST.

WG> Text has been updated to reflect the new IPP port.

2. section 7 is actually missing the copyright notice; it only
contains the license.

WG> This has been corrected.

draft-ietf-ipp-req-01.txt:

1. Even though the IPP WG was told to write a requirements document,
some IESG folks have pushed back on using the word "requirements"
in a document title.  My guess is that the title should be changed
to something like "Design Goals for an Internet Printing Protocol".
Either that, or many of the "requirements" need more justification
to convince the reader that they're obviously requirements and 
not merely goals.

WG> We changed the title of the document, although we are still
using the term "requirements", when discussing some of the details
within the document.

2. Section 1: It's not clear how or why a web browser is part of a 
complete Internet Printing system.

WG> We have improved the text on this and explained that it is 
optional.

3. Section 2.1.4: it's not clear why a user needs to have the ability
to submit a print job by reference.

WG> We added text explaining it saves the user to first download a 
large document to the desktop from a repository in a server, and
then have to send the same data to the printer.

4. Section 2.2: change "the user may only see his own jobs" to
"the user might only be able to see his own jobs".

WG> The wording has been fixed.

5. Section 3, third paragraph, last sentence.  Seems like
"must properly handle this methodology" should be "must properly
handle either methodology".

WG> The wording has been fixed.

6. Section 3.1, first paragraph.  "Whenever possible, IPP ought
to make use of ..." should perhaps be "Whenever reasonable,..."

WG> The wording has been fixed.

7. 3.1, second paragraph.  "printing environments describes"...
should be "printing environments described";

"document to be printed may all exist"  should be
"document to be printed may each exist" ;

"protection are much stronger" should be
"protection may be much stronger" 

WG> The wording has been fixed.

8. 3.3, first paragraph.  "shall be extensible by several
means that facilitates interoperability and prevents"...
should be "facilitate" and "prevent"

WG> The wording has been fixed.

9. section 3.3: the structure of the bulleted list is confusing;
some of the bullets should apparently be subordinate to the others.

4th bullet: needs a space between "attributes" and "and"

WG> This has been fixed.

10. section 4.2.  there are significant security risks associated
with driver installation; I don't see any discussion of those risks.

WG> Although we mention downloading of drivers in our scenarios,
this is really part of the overall printing infrastructure, which
we consider to be out of scope for the IPP protocol. We have
stated that we do not discuss these security aspects.

11. section 7.  there appears to be overprinting in the 
acknowledgements section (at least, enscript didn't handle it right)

WG> This has been corrected.

12. the document seems to assume that users will download a driver
to talk to a particular printer; there's no requirement that users
be able to talk to printers -- even in reduced functionality
mode -- without downloading a driver.  this would seem to constrain
the cross-platform portability of the standard, as well as introducing
security risks.  (which is not to say that IPP itself has problems
with this ... I think it's okay .. but the assumption that everyone
who wants to talk to a printer can download and install a driver
is not a valid one...it's too windows centric)

WG> Editorial. Downloading drivers is common today, but there
are other ways. The fact that we have an optional URL reference 
that can point to a page with drivers is a clear user requirement.
The actual downloading would then usually happen over FTP (initiated
by a web browser).

13. section 9.23.  do we have permission to use Kinko's and Sir Speedy's
names/trademarks?  If not, should probably substitute generic names.

WG> We have changed this to other names.

14. document is missing a security considerations section at the end.
it can refer to section 4.1 but should also mention security problems
related to downloading drivers.

WG> See earlier comments.

draft-ietf-ipp-model-09.txt:

1. Section 2.4:  should refer to TLS, not SSL3.  Also, the
"https" URL prefix is nonstandard.

WG> We have taken out all references to SSL3 and https, 
except in the security schemes, where SSL3 is still a
non-standard option.

2. at the end of section 3.1.3, this is misstated:
if the URL type allows a port number and one is specified, 
that port number must be used.  if no port number is specified,
the default port must be used.  (if the URL type doesn't
allow a port number and one is specified anyway, it's arguably
a parse error on the URL and the whole operation should fail)

WG> We are in effect using "http:" so port number specification 
is allowed, but we have changed the text to reflect your comment.

3. section 3.1.4.1, last paragraph:

"object SHALL NOT change either of these attributes and SHALL
except them as if they were valid."  it's not clear (to me)
what this means: doesn't this put the printer in a position
where it cannot report errors in the natural language?
I understand not allowing the printer to change the request,
but shouldn't this be an error condition, and if so, how should
it be reported?

WG> This has been reworded.

4. section 3.2.1.2, under "Group 3: Job Object Attributes"

"Printer object always uses is" should be
"Printer object always uses its"

WG> This has been fixed.

5. section 4.1.1

it's not clear to me why, if anything defined as 'text' is also
allowed to use 'textWithLanguage' syntax, that there are separate
syntaxes for text vs. textWithLanguage.  Why not either do:

text = textWithLanguage | textUsingImplicitLanguage

and just call everything 'text' from then on out?
(which would be a purely editorial simplification)

or just elimiate the implicit language form altogether?
(which would be a protocol simplification)

WG> The WG has accepted your first proposal and documented it
in the revised draft. This change does not require any on-the-wire
protocol change.

6. 4.1.2, 5th paragraph

"SHALL accept, support, and return both the 'text' and 'textWithLanguage'

reads as if objects are requried to *return* both syntaxes
for every text attribute...not one or the other.

WG> This has been reworded.

7. section 4.1.8.  

if you must refer to https, please refer to it as non-standard.

WG> Is now referred to as non-standard.

8. section 4.1.9

what does it mean to restrict the use of utf-8 to iso 10646?
why do you want to impose such a restriction?

WG> This restriction is in UTC-8 itself. We have reworded and 
changed reference to UTF-8 in RFC 2279.

9. section 4.1.11

'mimeMediaType' is too short, especially given that it contains
the parameters also.  127 octets would be marginal.  255 would
be a lot better.  (is there a reason to use 2**n-1?)

WG> We have increased this to 255.

10.  section 4.2.7

does the page-ranges count page images rather than docuemnt
page numbers (say in eps or pdf?)

WG> We have done some rewording to reflect that we mean page images.

11. section 4.3.1

despite widespread use of "https" etc, the URI "access method" 
shouldn't be used to indicate the presense or lack of "security"; 
when necessary to specify a particular security technology  in
a URI, that should be a done with a paramter (e.g. ";auth-type=digest").

WG> We have taken out reference to "https". See earlier comments.
"Digest" is requested by the HTTP server side (only case where it 
makes sense in IPP, and has to be supported by all HTTP clients, 
hence no need for a URI parameter.

12. section 4.3.7

for the case where there is an IPP front-end to some other kind
of printer queue, and it's not possible for the front-end
to determine whether the job is 'completed' according to the
IPP definition, what status should it report when the job
is finished as best as can be determined?

it seems like 'completed' is the right thing to do here,
but this would be inconsistent with the definition.

WG> Use "unknown" out-of-band value. We have added to that effect.

13. section 4.4.2

the example makes it appear as if "password-printer" is a magic
string in a URL, which indicates that a printer is to use 
basic or digest authenticaiton

WG> Text and example reworded to remove that impression.

14. section 4.4.24

cleartext passwords are no longer allowed in URLs

WG> We have taken out the FTP details and put in reference RFC 1738 
and RFC 2316.

15. section 5.1, last paragraph

"Clients may choose to ignore any parameters that it does not understand"
should be "...that they do not understand".

WG> This has been fixed.

16. section 5.4

Conforming clients MUST (not SHOULD) support TLS access.

WG> After discussion with you in the phone conference, we want to
keep this as is. Apart from the fact that TLS implementations are not yet 
readily available, there are several scenarios, e.g. with small handhelds
where the TLS code would be more than the IPP code, in which a product
would not be marketable with the TLS feature added.

17. section 6.1

If I'm not mistaken, it's inappropriate for the IPP RFC to actually
name the experts.  

WG> We have checked this with IANA. The ADs appoint a suitable expert.
Text changeed to reflect this.

Nor do I think it's okay to have PWG "specify a replacement 
[expert] at any time", because PWG isn't responsible to IETF in any way.

WG> We have checked this with IANA. We have taken out any references to 
PWG and recommended that an AD appointed designated expert is used.

Nor do I think it's okay to give PWG control over the keywoard/enum
value space.  IANA can delegate to PWG, but IANA should have ultimate
authority.

WG> We have checked this with IANA. We have taken out any references to 
PWG and recommended that an AD appointed designated expert is used.

This section needs to be reviewed by IANA.

WG> The whole section has been revised to reflect consultations with 
IANA. A new section 12 has also been added, based on recommendation 
from IANA.


draft-ietf-ipp-protocol-05.txt:

1.  Section 3.2.  

I probably haven't grokked how these are used, but are there enough 
attribute tags and value tags to have room for future expansion?

WG> A new escape tag has been added to allow extension to 4 bytes.

2.  Section 3.9  

some text appears to be missing

WG> This has been fixed.

3. section 3.11

The table in the text version is illegible.  

WG> This has been fixed.

4. section 4

IPP needs its own default port and url scheme.  Support for port 80
should be optional.

WG> We have defined 631 as the Well Known Port for IPP. It is
explained that port 80 is still the HTTP default port. 

5. section 4.1

table is difficult to read

WG> This has been cleaned up.

6. section 4.2

it looks like there might be missing information in the 
accept-language row of the table.

WG> This has been fixed.

7. section 5

IPP needs its own port; support for port 80 should be optional.

WG> We have defined 631 as the Well Known Port for IPP. It is
explained that port 80 is still the HTTP default port. 

draft-ietf-ipp-lpd-ipp-map-03.txt

1. section 4.3

table is difficult to read in the text version

WG> This has been fixed.

2. section 7

change title to "Security Considerations".  yes, some folks are picky
about this.

WG> This has been fixed.