Subject: Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-file-scheme-14

From: Matthew Kerwin <[email-masked]>
Date: Wed, 7 Dec 2016 02:08:44 +0000

Hi Christer,

Thanks for the review, it dovetails nicely with other feedback I've received.

Elsewhere this text has been suggested for the abstract:

> This document provides a full specification of
> the "file" Uniform Resource Identifier (URI) scheme, replacing the
> very brief definition in Section 3.10 of RFC 1738.

Does that go some way to resolve the ambiguity there? It doesn't use the words "update" or "obsolete" but it seems to me that it says what it needs to.

The acknowledgements section has also been flagged, and I will work on updating that.

The remaining chunky bit of feedback I'm yet to address is about what non-backwards compatible changes are being made. I'll have to redo a bit of research to address this, to make sure I don't inadvertently lie, but it's definitely been taken on board. I'm hoping to say something along the lines of: "it aims to be backwards compatible except where incremental changes are inherited from specifications published since RFC 1738." That's pretty much what it says in Appendix A.

Cheers
--
Matthew Kerwin  |  Queensland University of Technology  |  [email-masked]  |  CRICOS No 00213J
________________________________
From: Christer Holmberg <[email-masked]>
Sent: 30 November 2016 20:26:54
To: Alexey Melnikov; [email-masked]
Cc: [email-masked]
Subject: Re: Gen-ART review of draft-ietf-appsawg-file-scheme-14

Hi,

>>Thanks for your reply! It clarifies my issues.
>>
>>However, for other outsiders like me, I think it would be really good to add some text about that in the draft. Explicitly say that the draft updates RFC 1738 by obsoleting the files URL scheme, defines a new URI scheme based on the procedures in RFC 3986. Because, as an outsider, it’s really difficult
>>for me to figure that out, and e.g., determine what/if I need to read RFC 1738 etc. Also, the text should not only cover the technical changes (syntax
>>etc), but also if there are changes regarding the usage etc.
>
>I think this is fair. I will let the editor come up with some proposal.

Thanks! I also suggest to remove the “derived” text from the Acknowledgements. Of course, the authors of RFC 1738 can still be acknowledged :)

Regards,

Christer

From: Alexey Melnikov <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 29 November 2016 at 14:00
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Gen-ART review of draft-ietf-appsawg-file-scheme-14

Hi Christer,
Thank you for your comments.

On Tue, Nov 29, 2016, at 10:34 AM, Christer Holmberg 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>

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”.

This is not really useful, because RFC 1738 was already obsoleted (but file URI definition was never update).

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?

The term URL (Uniform Resource Locator) was replaced by a more generic URI (Uniform Resource Identifier). Historically, some URIs were "locators" and some were "names", but more recently a lot of URIs exhibit both qualities. Thus the term URL should not be used.

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.
Everything is updated. The original RFC doesn't need to be read.

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?
No (as per above).

Editorial Issues: None

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Dec 2016 06:23:12 +0000

Hi,

>Does that go some way to resolve the ambiguity there? It doesn't use the
>words "update" or "obsolete" but it seems to me that it says what it
>needs to.

I am fine with ³replace² :)

Regards,

Christer

>The remaining chunky bit of feedback I'm yet to address is about what
>non-backwards compatible changes are being made. I'll have to redo a bit
>of research to address this, to make sure I don't inadvertently lie, but
>it's definitely been taken on board. I'm hoping to say something along
>the lines of: "it aims to be backwards compatible except where
>incremental changes are inherited from specifications published since RFC
>1738." That's pretty much what it says in Appendix A.
>
>Cheers
>--
>Matthew Kerwin  |  Queensland University of Technology  |
>[email-masked]  |  CRICOS No 00213J
>>>However, for other outsiders like me, I think it would be really good
>>>to add some text about that in the draft. Explicitly say that the draft
>>>updates RFC 1738 by obsoleting the files URL scheme, defines a new URI
>>>scheme based on the procedures in RFC 3986. Because, as an outsider,
>>>it¹s really difficult
>>>for me to figure that out, and e.g., determine what/if I need to read
>>>RFC 1738 etc. Also, the text should not only cover the technical
>>>changes (syntax
>Thanks! I also suggest to remove the ³derived² text from the
>Acknowledgements. Of course, the authors of RFC 1738 can still be
>acknowledged :)
>
>Regards,
>
>Christer
>
>
>
>From: Alexey Melnikov
><[email-masked]<mailto:[email-masked]>>
>To: Christer Holmberg
><[email-masked]<mailto:[email-masked]>>,
>"[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>Cc: 
>"[email-masked]<mailto:draft-ietf-appsa
>[email-masked]>"
><[email-masked]<mailto:draft-ietf-appsa
>[email-masked]>>
>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>
>
>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?
>
>The term URL (Uniform Resource Locator) was replaced by a more generic
>URI (Uniform Resource Identifier). Historically, some URIs were
>"locators" and some were "names", but more recently a lot of URIs exhibit
>both qualities. Thus the term URL should not be used.
>
>
>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?
>No (as per above).
>
>Editorial Issues: None
>
>
>

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 13 Dec 2016 23:27:43 +0000

Hi,

From: Christer Holmberg [mailto:[email-masked]] 
Sent: Wednesday, 7 December 2016 16:23
>>> This document provides a full specification of the "file" Uniform 
>>> Resource Identifier (URI) scheme, replacing the very brief definition 
>>> in Section 3.10 of RFC 1738.
>>
>>Does that go some way to resolve the ambiguity there? It doesn't use 
>>the words "update" or "obsolete" but it seems to me that it says what 
>>it needs to.
>

I've published version 15, could you please have a look and see if it
addresses your questions?  The pertinent changes are:

* The abstract now says basically what I quoted above.  I think the
rewording resolves most of your original questions about what is being
updated and how.

* There is some text in the introduction around the exceptions to
"compatible with most existing usages."  Basically it points to the very
loose description in RFC1738, and the gradual tightening of specs since then
which "file:" otherwise avoided.  There's also a pointer to Appendix A
"Differences from Previous Specifications".

* The acknowledgements section has been rewritten, and now has no formal
callbacks to the previous RFCs or drafts.

Cheers

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Dec 2016 15:26:16 +0200

Christer, thank you for the review and I very much agree with your comments. Thanks Matthew and others for addressing the issue.

Jari

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Dec 2016 20:09:59 +0000

Hi Matthew,

Sorry for the late response.

I had a look at version -15 (and also -16), and I am ok with the changes.

Thanks!

Regards,

Christer

-----Original Message-----
From: Matthew Kerwin [mailto:[email-masked]] 
Sent: 14 December 2016 01:28
To: Christer Holmberg <[email-masked]>; Alexey Melnikov
<[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: Gen-ART review of draft-ietf-appsawg-file-scheme-14

Hi,

Cheers