IPP> ADM - Keith Moore's IESG Comments

IPP> ADM - Keith Moore's IESG Comments

Carl-Uno Manros manros at cp10.es.xerox.com
Tue Jun 2 15:32:19 EDT 1998


<fontfamily><param>Times New Roman</param><bigger>As preparation for
tomorrow's phone conference, I have made 


a stab at writing down my comments against Keith's list.


I have tried to express the views of the WG rather than my


personal ones, but I am prepared to stand corrected if I got some


things wrong. I already had a phone conference with the editors


yesteray and they will start updating the drafts with all the things


considered to be "Edititorial" in my comments. Roger deBry will 


take over the editing of the Rationale document, as I assume


that Steve Zilles will not be available to us.




My comments start with CM> and follow each issue listed.




We will work further on this list in the phone conference tomorrow.




My intension is to get the revised drafts back to Keith within the


next two weeks. As stated in another message, these fixes are part of 


the IESG process and can be done quickly, unless we run into
disagreements 


about them.




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 PKIK for the hold-up. I am pursuing that


at present.




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.




CM> I sent out a question to the HTTP WG DL about


the adviceabilty of introducing a new URL scheme and to


allocate a new default port number to IPP. Not to my surprise,


responses so far from the HTTP experts were that allocating


a new port wold not cause too much of a problem, but most


everybody strongly adviced against a new URL scheme.




CM> The alternative proposal to use PRINT instead of


POST seems more acceptable and causes less problems.




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> I do not think we care about this one. Our latest solution


does not dictate one or the other. As for considering a new I-Ds 


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> Again, we do not really care, we will do what the security 


groups decide - if they ever make a decision.




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.




CM> It seems doubtful that Keith has actually read RFC 2119, which 


states that these terms are often capitalized and uses that in RFC2119


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, once the 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 save the user to first download a large


document that sits on a repository in a 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> 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




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> Editorial




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 should take out all references to SSL3


and https.




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> Check if this an inconsistency in the document




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> Editorial, as long as we do not make changes


that are visable in the protocol.




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




7. section 4.1.8.  




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




CM> Editorial, remove reference to https




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> Tom Hastings to check.




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> Any objections to increase the length?




10.  section 4.2.7




does the page-ranges count page images rather than docuemnt


page numbers (say in eps or pdf?)




CM> Needs clarification.




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> This is either a misunderstanding from Keith, or we have


expressed things poorly. We do not have that dependency.




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> We need to figure out what the right reply is.




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> Needs some rewording and maybe change example.




14. section 4.4.24




cleartext passwords are no longer allowed in URLs




CM> So what? We do not have a problem with that, or?




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> Which TLS? See earlier comments. Seems controversial proposal.




17. section 6.1




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


name the experts.  




CM> Editorial




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.




CM> Tom Hastings to check with 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> I hope so.




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> If we introduce a new default port for IPP, I think that support


for 80 will still be required.




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> If we introduce a new default port for IPP, I think that support


for 80 will still be required.




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


</bigger></fontfamily>


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 at cp10.es.xerox.com



More information about the Ipp mailing list