Skip to main content

Last Call Review of draft-ietf-appsawg-file-scheme-14

Request Review of draft-ietf-appsawg-file-scheme
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-12-06
Requested 2016-11-23
Authors Matthew Kerwin
I-D last updated 2016-12-08
Completed reviews Genart Last Call review of -14 by Christer Holmberg (diff)
Secdir Last Call review of -14 by Barry Leiba (diff)
Opsdir Last Call review of -14 by Tianran Zhou (diff)
Assignment Reviewer Christer Holmberg
State Completed
Request Last Call review on draft-ietf-appsawg-file-scheme by General Area Review Team (Gen-ART) Assigned
Reviewed revision 14 (document currently at 16)
Result Almost ready
Completed 2016-12-08
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at <>

Document:                       draft-ietf-appsawg-file-scheme-14.txt
Reviewer:                         Christer Holmberg
Review Date:                   29 November 2016
IETF LC End Date:           6 December 2016
IETF Telechat Date:        N/A

Summary: I don’t have any major comments regarding the technical content of the
draft. However, as seen in my comments below, I fail to see exactly how RFC
1738 is updated.

Major Issues: None

Minor Issues:

The Abstract text says:

   "This document specifies the "file" Uniform Resource Identifier (URI)
   scheme, replacing the definition in RFC 1738.”

Q1: I suggest that the text should say that the document “updates the file URI
scheme defined in RFC 1738”.

Q2: Related to Q1, in RFC 1738 the “file” scheme is defined as a URL, but in
the draft it is defined as a URI. What is the reason for that?

Q3: Related to Q1, it is unclear exactly what parts of the RFC 1738 scheme is
updated. For example, is the syntax updated, is the usage scope updated etc?
The second
       paragraph says something, but it is unclear whether it’s related to the
       actual update, or whether it just provides some information regarding
       the usage of the scheme. The Acknowledgements section says that the
       draft is “derived” from RFC 1739. What does “derived” mean? I think
       there should be clear and explicit text about exactly what is updated.

Q4: Related to Q3, the text says that things are backward compatible in “most
situations”. I think a little more text is needed, and e.g., examples of
non-backward compatibility.

Q5: I see that RFC 1738 is only a Informative Reference. Someone can correct me
if I’m wrong, but doesn’t it have to be Normative since the draft is
normatively (I assume) updating the RFC?

Editorial Issues: None