Return-Path: X-Original-To: gen-art@ietfa.amsl.com Delivered-To: gen-art@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32FF1293F4 for ; Tue, 29 Nov 2016 03:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastmail.fm header.b=lft9RImW; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=uAxozIxS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fv8mTdDB7FH for ; Tue, 29 Nov 2016 03:00:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98EBE1293E0 for ; Tue, 29 Nov 2016 03:00:20 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 152A8206F2; Tue, 29 Nov 2016 06:00:20 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 29 Nov 2016 06:00:20 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=DXCGB/SH4PzMlUh4V4Hou7Rzcn o=; b=lft9RImWE1MKjIp9a1Q/BmAJroFpsoukXZmjseIbd+1IA5Bbue8s8WNDbQ Lomo43q68mGICgYgzKYmEfM0o0w2Xyw8N6z9Skr8u4C1ihDONyRuGKdpr+26dGSu aBCws8ed6LncPDzI9F22cuKBZBk9MTXzdsLtMaIV68XdJi1oc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=DX CGB/SH4PzMlUh4V4Hou7Rzcno=; b=uAxozIxSq93Ck8n6lP5vomUenpxjeM9uCp aQ/Py9GFHPpfs/y5rQKZTvjx9iTEzV3NPvXvwgwnuKAGbTuJLHg7xWX1IrtQ/T7H jSIJZPkkl8hczSnAbkcpvxl6ew4cZdrDDRlpoKlf1XtUnlf6ZNH0xKf8oRWBGr89 V2sKb9UWY= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E13125A67D; Tue, 29 Nov 2016 06:00:19 -0500 (EST) Message-Id: <1480417219.3456208.802284185.4E1FFAE0@webmail.messagingengine.com> From: Alexey Melnikov To: Christer Holmberg , gen-art@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_148041721934562080" X-Mailer: MessagingEngine.com Webmail Interface - ajax-89a52833 In-Reply-To: Date: Tue, 29 Nov 2016 11:00:19 +0000 References: Archived-At: Cc: draft-ietf-appsawg-file-scheme.all@tools.ietf.org Subject: Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-file-scheme-14 X-BeenThere: gen-art@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "GEN-ART: General Area Review Team" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2016 11:00:22 -0000 This is a multi-part message in MIME format. --_----------=_148041721934562080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Christer, Thank you for your comments. On Tue, Nov 29, 2016, at 10:34 AM, Christer Holmberg wrote: >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > >=20 > 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 >=20 > Summary: I don=E2=80=99t 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. >=20 > Major Issues: None >=20 > Minor Issues: >=20 > The Abstract text says: >=20 > "This document specifies the "file" Uniform Resource Identifier > (URI) scheme, replacing the definition in RFC 1738.=E2=80=9D >=20 > Q1: I suggest that the text should say that the document =E2=80=9Cupdates= the > file URI scheme defined in RFC 1738=E2=80=9D. This is not really useful, because RFC 1738 was already obsoleted (but file URI definition was never update). >=20 > Q2: Related to Q1, in RFC 1738 the =E2=80=9Cfile=E2=80=9D scheme is defin= ed 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. >=20 > 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=E2=80=99s > 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. >=20 > The Acknowledgements section says that the draft is =E2=80=9Cderived=E2= =80=9D from RFC > 1739. What does =E2=80=9Cderived=E2=80=9D mean? I think there should be c= lear and > explicit text about exactly what is updated. >=20 > Q4: Related to Q3, the text says that things are backward compatible > in =E2=80=9Cmost situations=E2=80=9D. I think a little more text is n= eeded, and > e.g., examples of non-backward compatibility. >=20 > Q5: I see that RFC 1738 is only a Informative Reference. Someone can > correct me if I=E2=80=99m wrong, but doesn=E2=80=99t it have to be No= rmative since > the draft is normatively (I assume) updating the RFC? No (as per above). >=20 > Editorial Issues: None --_----------=_148041721934562080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
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 G= en-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/Ge= nArtfaq>

Document:          &= nbsp;            dra= ft-ietf-appsawg-file-scheme-14.txt
Reviewer:                 &nbs= p;       Christer Holmberg
Review Date:                 &= nbsp; 29 November 2016
IETF LC End Date:           6 December 2016
IETF Telechat Date:        N/A

Summary: I don=E2=80=99t have any major comments regarding the technic= al content of the draft. However, as seen in my comments below, I fail to s= ee exactly how RFC 1738 is updated.

Major Issues: None

Minor Issues:

The Abstract text says:

   "This document specifies the "file" Uniform Resource Iden= tifier (URI) scheme, replacing the definition in RFC 1738.=E2=80=9D

Q1: I suggest that the text should say that the document =E2=80=9Cupda= tes the file URI scheme defined in RFC 1738=E2=80=9D.

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 =E2=80=9Cfile=E2=80=9D scheme is de= fined 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 qualit= ies. Thus the term URL should not be used.


Q3: Related to Q1, it is unclear exactly what parts of the RFC 1738 sc= heme is updated. For example, is the syntax updated, is the usage scope upd= ated etc? The second
       paragraph says something, but it is unclear= whether it=E2=80=99s related to the actual update, or whether it just prov= ides some information regarding the usage
       of the scheme.
Everything is updated. The original RFC doesn't need to b= e read.

The Acknowledgements section says that the draft is =E2=80=9Cderived= =E2=80=9D from RFC 1739. What does =E2=80=9Cderived=E2=80=9D mean? I think = there should be clear and explicit text about exactly what is updated.
<= /div>

Q4: Related to Q3, the text says that things are backward compatible i= n =E2=80=9Cmost situations=E2=80=9D. 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 c= orrect me if I=E2=80=99m wrong, but doesn=E2=80=99t it have to be Normative= since the draft is normatively (I assume) updating the RFC?
No (as per above).

Editorial Issues: None

--_----------=_148041721934562080--