Aha the good old POST vs PRINT issue.
REQUIRING a different port number would be wrong. We dont preclude this
however (we have tested our implementations with non port 80 IPP agents).
As you kow MS proposed using PRINT instead of POST.
> -----Original Message-----
> From: Keith Moore [SMTP:moore at cs.utk.edu]
> Sent: Friday, May 29, 1998 1:30 PM
> To: ipp at pwg.org> Cc: moore at cs.utk.edu> Subject: IPP> review of IPP documents
>> 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)
>> 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.>> 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.
>> 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")
>> 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.
>> 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.
>> 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".
>> 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.
>> 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.
>>> 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.
>> 2. section 7 is actually missing the copyright notice; it only
> contains the license.
>> 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.
>> 2. Section 1: It's not clear how or why a web browser is part of a
> complete Internet Printing system.
>> 3. Section 2.1.4: it's not clear why a user needs to have the ability
> to submit a print job by reference.
>> 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".
>> 5. Section 3, third paragraph, last sentence. Seems like
> "must properly handle this methodology" should be "must properly
> handle either methodology".
>> 6. Section 3.1, first paragraph. "Whenever possible, IPP ought
> to make use of ..." should perhaps be "Whenever reasonable,..."
>> 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"
>> 8. 3.3, first paragraph. "shall be extensible by several
> means that facilitates interoperability and prevents"...
> should be "facilitate" and "prevent"
>> 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"
>> 10. section 4.2. there are significant security risks associated
> with driver installation; I don't see any discussion of those risks.
>> 11. section 7. there appears to be overprinting in the
> acknowledgements section (at least, enscript didn't handle it right)
>> 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)
>> 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.
>> 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.
>> draft-ietf-ipp-model-09.txt:
>> 1. Section 2.4: should refer to TLS, not SSL3. Also, the
> "https" URL prefix is nonstandard.
>> 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)
>> 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?
>> 4. section 3.2.1.2, under "Group 3: Job Object Attributes"
>> "Printer object always uses is" should be
> "Printer object always uses its"
>> 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)
>> 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.
>> 7. section 4.1.8.
>> if you must refer to https, please refer to it 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?
>> 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?)
>> 10. section 4.2.7
>> does the page-ranges count page images rather than docuemnt
> page numbers (say in eps or pdf?)
>> 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").
>> 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.
>> 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
>> 14. section 4.4.24
>> cleartext passwords are no longer allowed in URLs
>> 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".
>> 16. section 5.4
>> Conforming clients MUST (not SHOULD) support TLS access.
>> 17. section 6.1
>> If I'm not mistaken, it's inappropriate for the IPP RFC to actually
> name the experts.
>> 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.
>> 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.
>> 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?
>> 2. Section 3.9
>> some text appears to be missing
>> 3. section 3.11
>> The table in the text version is illegible.
>> 4. section 4
>> IPP needs its own default port and url scheme. Support for port 80
> should be optional.
>> 5. section 4.1
>> table is difficult to read
>> 6. section 4.2
>> it looks like there might be missing information in the
> accept-language row of the table.
>> 7. section 5
>> IPP needs its own port; support for port 80 should be optional.
>>> draft-ietf-ipp-lpd-ipp-map-03.txt
>> 1. section 4.3
>> table is difficult to read in the text version
>> 2. section 7
>> change title to "Security Considerations". yes, some folks are picky
> about this.
>