Hi, >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.
I am fine with ³replace² :) Regards, Christer > >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 protected] | CRICOS No 00213J >________________________________ >From: Christer Holmberg <[email protected]> >Sent: 30 November 2016 20:26:54 >To: Alexey Melnikov; [email protected] >Cc: [email protected] >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 protected]<mailto:[email protected]>> >Date: Tuesday 29 November 2016 at 14:00 >To: Christer Holmberg ><[email protected]<mailto:[email protected]>>, >"[email protected]<mailto:[email protected]>" ><[email protected]<mailto:[email protected]>> >Cc: >"[email protected]<mailto:draft-ietf-appsa >[email protected]>" ><[email protected]<mailto:draft-ietf-appsa >[email protected]>> >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 > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
