Gen-art telechat review: draft-mcdonald-ipps-uri-scheme-17

[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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-mcdonald-ipps-uri-scheme-17
Reviewer: Robert Sparks
Review Date: 2-Dec-2014
IETF LC End Date: past
IESG Telechat date: 4-Dec-2014

Summary: Almost ready, but with nits that need to be addressed

Jari/IESG: Please see my question about updating documents that are in 
other organization's change control below.

Authors:

version 17 improves several aspects over 16, but there are still 
reference issues reported by idnits.
The most important ones to fix are the Missing Reference issues it calls 
out.

>    == Missing Reference: 'MEDIAREG' is mentioned on line 829, but not defined
>
>    == Missing Reference: 'RFC2818' is mentioned on line 862, but not defined
>
>    == Missing Reference: 'RFC2616' is mentioned on line 955, but not defined
>
>    ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231,
>       RFC 7232, RFC 7233, RFC 7234, RFC 7235)
>
>    == Missing Reference: 'RFC2246' is mentioned on line 1082, but not defined
>
>    ** Obsolete undefined reference: RFC 2246 (Obsoleted by RFC 4346)
>
>    == Missing Reference: 'RFC4346' is mentioned on line 1082, but not defined
>
>    ** Obsolete undefined reference: RFC 4346 (Obsoleted by RFC 5246)
>
>    -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII'
>
>    -- Obsolete informational reference (is this intentional?): RFC 2566
>       (Obsoleted by RFC 2911)




On 11/21/14 3:55 PM, Robert Sparks wrote:
> 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.
>
>
>
>
>
>
>