Last Call Review of draft-mcdonald-ipps-uri-scheme-16
review-mcdonald-ipps-uri-scheme-16-genart-lc-sparks-2014-12-01-00

  
  
    I am the assigned Gen-ART reviewer for this draft. For background on
    


    Gen-ART, please see the FAQ at
    







<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

.
    





Please resolve these comments along with any other Last Call comments
    


    you may receive.
    





    Document:
    draft-mcdonald-ipps-uri-scheme-16


    Reviewer:
    Robert Sparks


    Review Date:
    21-Nov-2014


    IETF LC End Date:
    25-Nov-2014


    IESG Telechat date: 4-Dec-2014
    





    Summary: Almost ready, but has nits that should be addressed before
    publication as a Proposed Standard





    Nits/editorial comments:
    





    First: (For Barry as sponsoring AD and shepherd):





    I think you might want to say more about how this and the related
    PWG documents are being handled cross-organization.





    An RFC that normatively updates a document under some other
    organization's change control is an unusual thing. Usually there are
    parallel documents coordinating this. Is there such a parallel PWG
    doc this time?





    Why aren't there RFC variants of the PWG docs (we've republished
    other organization's documents in the RFC series before...)





    Second: The 6 step construction in section 3 is a little odd. Why
    aren't steps 3-5 collapsed into one step that says "go do what
    https: says to do"? Split this way, especially with the repeated
    guidance in the security considerations section pointing somewhat
    loosely to 7320 and 5246 for things that "can be used to address
    this threat" looks like an opportunity for someone to get creative
    with how they check the certificate supplied by the server against
    the name in the URI. If you don't want anything but what happens in
    https to happen, I think it needs to be more clearly stated.
    Otherwise, doesn't this go off into RFC 6125 territory?





    Lastly (and much smaller nits):





    There are several callouts from the text that look like references
    that are not represented in the references section.


    ID nits complains about all of these, and should make them easy to
    find and fix.


    For example (from section 1.2):







  2) Some existing IPP Client and IPP Printer implementations of HTTP
      Upgrade [RFC 2717] do not perform upgrade at the beginning of





    This reference is oddly constructed - please check early with the
    RFC Editor on whether they


    will take this, or want something a little different.







[HTTP1.1]     HTTP/1.1.  See [RFC7230], [RFC7231], [RFC7232],
              [RFC7233], [RFC7234], and [RFC7235].  





    This line is wrong, and is causing idnits to complain once where it
    shouldn't.


    (The thing in the [] should be RFC7235, not 4):







   [RFC7234]  Fielding, R., and J. Reschke, "Hypertext Transfer Protocol
              (HTTP/1.1):  Authentication", RFC 7235, June 2014.