Based on two phone conferences and discussions on the IPP and HTTP DLs,
here is our first stab at answering your comments.
It is abundantly clear that in particular your proposals for the "ipp"
scheme and mandating TLS for all IPP clients are NOT finding support in the
WG.
We will continue the discussion on the DL, but would like to set up a phone
conference with you next week to discuss the HTTP and TLS comments with you
directly.
I have inserted our comments, based on the WG input so far, starting with
CM> in your original text below.
The editors are already at work to fix all the minor and editorial things.
NOTE: I would appreciate if those WG members who feel that their voices
have not been heard in these preliminary responses express their views
quickly on the IPP DL. I realize that a couple of MS people have expressed
strong views on using PRINT instead of POST (no surprise there), but that
still seems to be more of a minority view so far. If you are a PRINT method
supporter, please speak up now!
Carl-Uno
-----
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)
CM> I have sent out a question to the TLS WG DL asking about status.
They are currently blaming PKIX for the hold-up.
We will keep chasing the responsible....
I apologize for this haven taken so long.
CM> Right.
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.
CM> I sent out a question to the HTTP WG DL about
the adviceability of introducing a new URL scheme and to
allocate a new default port number to IPP. The responses so
far from the HTTP experts were that allocating a new port would
not cause too much of a problem, but most everybody strongly
adviced against a new URL scheme.
CM> A majority in he IPP WG does not see a strong need to change
ANYTHING regarding HTTP in the current drafts. You need to give
us better arguments for the suggested change - the once you give
us have been extensively discussed earlier and rejected.
The current IPP solution has now been implemented by several
companies and found to work fine. We need very strong reasons to
change something that actually works to something that might NOT.
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.
CM> The IPP solution does not assume one or the other.
As for considering a new security I-D that is far from the standards
track - forget it!
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")
CM> We do not really care, we will do what the security
groups decide - if they ever make a decision. The IPP solution
allows either or. We are not in the business of defining new
URI parameters for HTTP.
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!
CM> We are happy to hear SOMETHING from you.
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.
CM> It seems that you have not actually read RFC 2119, which
states that these terms are often capitalized and uses that in
RFC 2119 itself.
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.
CM> Editorial
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".
CM> Editorial
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.
CM> Editorial
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.
CM> Editorial
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.
CM> Editorial, only if a new HTTP solution is decided.
2. section 7 is actually missing the copyright notice; it only
contains the license.
CM> Editorial
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.
CM> Editorial
2. Section 1: It's not clear how or why a web browser is part of a
complete Internet Printing system.
CM> Editorial
3. Section 2.1.4: it's not clear why a user needs to have the ability
to submit a print job by reference.
CM> Add text explaining it saves the user to first download a large
document that sits on a repository in a server, including a web server.
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".
CM> Editorial
5. Section 3, third paragraph, last sentence. Seems like
"must properly handle this methodology" should be "must properly
handle either methodology".
CM> Editorial
6. Section 3.1, first paragraph. "Whenever possible, IPP ought
to make use of ..." should perhaps be "Whenever reasonable,..."
CM> Editorial
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"
CM> Editorial
8. 3.3, first paragraph. "shall be extensible by several
means that facilitates interoperability and prevents"...
should be "facilitate" and "prevent"
CM> Editorial
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"
CM> Editorial
10. section 4.2. there are significant security risks associated
with driver installation; I don't see any discussion of those risks.
CM> We will consider adding new text - although driver installation is
really outside the scope of IPP v1.0.
11. section 7. there appears to be overprinting in the
acknowledgements section (at least, enscript didn't handle it right)
CM> Editorial
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)
CM> Editorial. Downloading drivers is common today, but there
are other ways. All we need to say is that there must be some way
of producing a PDL. The fact that we have an optional URL reference
that can point to a page with drivers is a clear user requirement.
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.
CM> Change to generic 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.
CM> Editorial
draft-ietf-ipp-model-09.txt:
1. Section 2.4: should refer to TLS, not SSL3. Also, the
"https" URL prefix is nonstandard.
CM> Editorial, we will take out all references to SSL3 and https,
except in the security schemes, where SSL3 is still an 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)
CM> Editorial.
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?
CM> Will be 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"
CM> Editorial
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)
CM> Accept first proposal. We do not want to make protocol
changes at this stage.
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.
CM> Editorial, needs rewording.
7. section 4.1.8.
if you must refer to https, please refer to it as non-standard.
CM> Editorial, add comment.
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?
CM> This restriction is in UTC-8 itself. Reword and change
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?)
CM> Increase to 255.
10. section 4.2.7
does the page-ranges count page images rather than docuemnt
page numbers (say in eps or pdf?)
CM> Needs rewording. Should be 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").
CM> We do not have that dependency. We will improve the text.
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.
CM> Use "unknown" value. Add note 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
CM> Reword and change example.
14. section 4.4.24
cleartext passwords are no longer allowed in URLs
CM> Take out the FTP details, 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".
CM> Editorial
16. section 5.4
Conforming clients MUST (not SHOULD) support TLS access.
CM> Controversial proposal, as TLS not yet exists neither as
standard nor product. Not even Alphas for TLS yet around, while IPP
already in Betas. The security folks did not get their act together.
17. section 6.1
If I'm not mistaken, it's inappropriate for the IPP RFC to actually
name the experts.
CM> We will check with IANA.
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.
CM> It could be responsible to IANA if IANA so decides.
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.
CM> Check with IANA.
This section needs to be reviewed by 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?
CM> There is lots of room for expansion. We will explain how.
2. Section 3.9
some text appears to be missing
CM> Editorial
3. section 3.11
The table in the text version is illegible.
CM> Editorial
4. section 4
IPP needs its own default port and url scheme. Support for port 80
should be optional.
CM> Not agreed. Strong opposition to define new URL scheme.
IPP was designed to run on top of HTTP that has port 80 as default.
We could potentially allocate a new alternate port that COULD
be used by firewall administrators IF they want to distinguish IPP
traffic from other HTTP traffic.
5. section 4.1
table is difficult to read
CM> Editorial
6. section 4.2
it looks like there might be missing information in the
accept-language row of the table.
CM> Editorial
7. section 5
IPP needs its own port; support for port 80 should be optional.
CM> IPP was designed to run on top of HTTP that has port 80 as default.
We could potentially allocate a new alternate port that COULD
be used by firewall administrators IF they want to distinguish IPP
traffic from other HTTP traffic.
draft-ietf-ipp-lpd-ipp-map-03.txt
1. section 4.3
table is difficult to read in the text version
CM> Editorial
2. section 7
change title to "Security Considerations". yes, some folks are picky
about this.
CM> Editorial
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - 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