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

Christer Holmberg <> Wed, 30 November 2016 10:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5128812963F for <>; Wed, 30 Nov 2016 02:27:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ttHw9DtskAem for <>; Wed, 30 Nov 2016 02:26:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E67F129642 for <>; Wed, 30 Nov 2016 02:26:57 -0800 (PST)
X-AuditID: c1b4fb25-adbff70000007ee2-5b-583ea96eb340
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D8.D6.32482.E69AE385; Wed, 30 Nov 2016 11:26:55 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0319.002; Wed, 30 Nov 2016 11:26:54 +0100
From: Christer Holmberg <>
To: Alexey Melnikov <>, "" <>
Thread-Topic: Gen-ART review of draft-ietf-appsawg-file-scheme-14
Thread-Index: AQHSSiwdHMurdzVghEWp7tWnuH9XBKDvum+AgAAtkID///Z+gIABeCoA
Date: Wed, 30 Nov 2016 10:26:54 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D464779E13DC0christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2K7k27+SrsIg5lHrSz2vz/EZLHgoIrF 1VefWRyYPXaeOsDmsWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBl7Ll0jq1g4kbGisUHjrM0 MP6ezdjFyMkhIWAisfb1b2YQW0hgHaPE7112XYxcQPZiRok7D36xdTFycLAJWEh0/9MGqRER CJXYuesnWD2zQK7EzGN3WUFsYQEHieZb3xkhahwl3u5vZoGw3SQmHH/KBmKzCKhKXLm1HKyG V8BaYlrrOTaIXT8ZJa5c+ccOkuAUCJB4O/USWAOjgJjE91NrmCCWiUvcejKfCeJoAYkle84z Q9iiEi8f/2MFuVNUQE9izf0wiLCSxI8Nl1ggWhMkGqZdYYHYKyhxcuYTlgmMorOQTJ2FpGwW kjKIuIHE+3PzmSFsbYllC19D2foSG7+cZYSwrSU+3OhmRFazgJFjFaNocWpxUm66kbFealFm cnFxfp5eXmrJJkZgbB7c8lt1B+PlN46HGAU4GJV4eD9Mt40QYk0sK67MPcQowcGsJMIrtsIu Qog3JbGyKrUoP76oNCe1+BCjNAeLkjiv2cr74UIC6YklqdmpqQWpRTBZJg5OqQbG4DaH6K6o 5GeNuwrsd/vqye30Ol3xx7k18Nx+lQf6b25p2vhv23NeQrw3cTP75Dkdczc1neJ5c0c/ZrOS F1dbuULfqRKBrvWfr9dVnBS4fumEbYLnN+k9a1gmuj6zfXjs00HBK++0/3Z+umR58/rEWd2G yT0BDrIZOW0PQ+2fZ6udfz5zQrusEktxRqKhFnNRcSIAoshedskCAAA=
Archived-At: <>
Cc: "" <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-appsawg-file-scheme-14
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: Wed, 30 Nov 2016 10:27:00 -0000


>>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 :)



From: Alexey Melnikov <<>>
Date: Tuesday 29 November 2016 at 14:00
To: Christer Holmberg <<>>, "<>" <<>>
Cc: "<>" <<>>
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 <>

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