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 21C251299EE for ; Tue, 29 Nov 2016 05:09:37 -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=bdPqs3FA; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=iBg6E8lh 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 0TSE661-lFaC for ; Tue, 29 Nov 2016 05:09:35 -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 267821299F9 for ; Tue, 29 Nov 2016 05:09:25 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D5B6B2081D; Tue, 29 Nov 2016 08:09:21 -0500 (EST) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Tue, 29 Nov 2016 08:09:21 -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=dnLOqLGzOAE3cYU834NGnM3l+0 E=; b=bdPqs3FADN9iJyddbgYxxvDopUkdHc8KN/S9pUaTOeZbfLAsz8D8OwtOgT gIH4Vy2+ia+ZVsi05AmAHr7wjHddNNbD6eu3fLoFhhwC1Fuw8loY6S5krvXKElZO RTnA/4k5OIbct6S59CN1bAItgUktcPe8NmrN0700NUEwNZk0A= 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=dn LOqLGzOAE3cYU834NGnM3l+0E=; b=iBg6E8lhEhg70tvti8J6/etB60Q4yft3qW wfiiQMZFoAgFeH7NfTYkwWy21eCUS3LCL7xPR3G6i1hn4xgcegJEUtt2nUVRmr+L g1pY177sqOthbmPhllcOPFwL9hM83KZxlJEri4HlRH1oX6/J3DG+SyztYLlG0BMl KTUshGeys= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id AF19E5A67D; Tue, 29 Nov 2016 08:09:21 -0500 (EST) Message-Id: <1480424961.3484823.802399049.16AD2DC8@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="_----------=_148042496134848234" X-Mailer: MessagingEngine.com Webmail Interface - ajax-89a52833 Date: Tue, 29 Nov 2016 13:09:21 +0000 References: <1480417219.3456208.802284185.4E1FFAE0@webmail.messagingengine.com> In-Reply-To: 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 13:09:37 -0000 This is a multi-part message in MIME format. --_----------=_148042496134848234 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Christer, On Tue, Nov 29, 2016, at 12:34 PM, Christer Holmberg wrote: > Hi Alexey, >=20 > Thanks for your reply! It clarifies my issues. >=20 > 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=E2=80=99s 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. Best Regards, Alexey > Regards, >=20 > Christer >=20 >=20 > *From: *Alexey Melnikov *Date: *Tuesday 29 > November 2016 at 14:00 *To: *Christer Holmberg > , "gen-art@ietf.org" art@ietf.org> *Cc: *"draft-ietf-appsawg-file- > scheme.all@tools.ietf.org" scheme.all@tools.ietf.org> *Subject: *Re: Gen-ART review of draft-ietf-ap= psawg-file-scheme- > 14 >=20 >=20 > Hi Christer, > Thank you for your comments. >=20 > 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=9Cupdate= s the >> file URI scheme defined in RFC 1738=E2=80=9D. >=20 > This is not really useful, because RFC 1738 was already obsoleted (but > file URI definition was never update). >=20 >>=20 >> Q2: Related to Q1, in RFC 1738 the =E2=80=9Cfile=E2=80=9D scheme is defi= ned as a URL, >> but in the draft it is defined as a URI. What is the reason for >> that? >=20 > 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 >>=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 clear 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 = needed, 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 N= ormative >> since the draft is normatively (I assume) updating the RFC? > No (as per above). >>=20 >> Editorial Issues: None >=20 >=20 --_----------=_148042496134848234 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Christer,

On Tue, Nov 29, 2016, at 12:34 PM, Christer Holmberg wrote:
Hi Alexey,

Thanks for your reply! It clarifies my issues.

However, for other outsiders like me, I think it wou= ld 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 3= 986. Because, as an outsider, it=E2=80=99s really difficult for me to figure that out, and e.g., determine what/if I need to read RFC 1738 etc. Also, t= he text should not only cover the technical changes (<= span class=3D"font" style=3D"font-family:Calibri, sans-serif">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= .

Best Regards,
Alexey

Regards,

Christer


From: Alexey Melnikov <aamelnikov@fastmail.fm>
Date: Tues= day 29 November 2016 at 14:00
To: Christer Holmberg <christer.holmberg@ericsson.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ie= tf-appsawg-file-scheme.all@tools.ietf.org" <draft-ietf-appsawg-file-scheme= .all@tools.ietf.org>
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 back= ground on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/t= rac/wiki/GenArtfaq>

Document:        &n= bsp;            = ;  draft-ietf-appsawg-file-scheme-14.txt
Reviewer:               =           Christer Holmberg
Review Date:             &nbs= p;     29 November 2016
IETF LC End Date:           6 Dece= mber 2016
IETF Telechat Date:        N/A

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.

Major Issues: None

Minor Issues:

The Abstract text says:

   "This document specifies the "file" Uniform Re= source Identifier (URI) scheme, replacing the definition in RFC 1738.=E2=80= =9D

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 alread= y obsoleted (but file URI definition was never update).


Q2: Related to Q1, in RFC 1738 the =E2=80=9Cfile=E2=80=9D s= cheme 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 m= ore 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 usag= e scope updated etc? The second
       paragraph says something, but it= is unclear whether it=E2=80=99s related to the actual update, or whether i= t 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 =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 upd= ated.

Q4: Related to Q3, the text says that things are backward c= ompatible in =E2=80=9Cmost situations=E2=80=9D. I think a little more text = is needed, and e.g., examples of non-backward compatibility.<= /span>

Q5: I see that RFC 1738 is only a Informative Reference. So= meone can correct me if I=E2=80=99m wrong, but doesn=E2=80=99t it have to b= e Normative since the draft is normatively (I assume) updating the RFC?
No (as per above).

Editorial Issues: None



--_----------=_148042496134848234--