Gen-art LC review: draft-mcdonald-ipps-uri-scheme-16

[Robert Sparks <[e-mail]>]

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.