Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt

Sean Leonard <> Sun, 15 May 2016 10:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1595B12D152; Sun, 15 May 2016 03:16:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E_Qc8fk_Hjn0; Sun, 15 May 2016 03:16:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 70F5712D13C; Sun, 15 May 2016 03:16:47 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4D5EE509B5; Sun, 15 May 2016 06:16:46 -0400 (EDT)
References: <>
From: Sean Leonard <>
Message-ID: <>
Date: Sun, 15 May 2016 03:15:52 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 May 2016 10:16:49 -0000

On 5/14/2016 10:15 PM, wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the ART Area General Applications Working Group of the IETF.
>          Title           : The file URI Scheme
>          Author          : Matthew Kerwin
> 	Filename        : draft-ietf-appsawg-file-scheme-09.txt
> 	Pages           : 18
> 	Date            : 2016-05-14

Did a full review; looks very good. Nice work!

The References section lists several references to MSDN articles.

Shorter MSDN article URLs are of the form:{ARTICLEID}

Such as:

I suggest simplifying the links, and updating the dates. Note that some 
library articles have dates; others do not. For example, [MS-DTYP] is 
most recently dated October 16, 2015, revision 30.0, according to its 
changelog at article ID cc230273.

In Appendix C, a discussion of Win32 Namespaces is given, but then it 
says "This specification does not define a mechanism for translating 
namespaced paths to or from file URIs." Readers would appreciate an 
informative reference for a mechanism to translate namespaced paths to 
and from file URIs, especially since there is a lot of technical content 
about Win32 processing in the rest of the Appendices.

I believe that the (American) English capitalization of Appendix D 
should be:
Appendix D. System-Specific Operations

Just curious: what happens if you try to access 
file://USERNAME@HOST/foo/bar.txt on a Windows UNC/network share, using a 
Windows machine and suitable API operations (e.g., Internet Explorer)? 
Will Windows try to access the network path with the given username, or 
something else? And does USER:PASS work?

I would be remiss if the term "alternate data streams" (ADS) were not 
mentioned in the context of Windows naming conventions. E.g.:

The syntax is already supported by the normative Syntax section, and is 
acknowledged without being named in the Security Considerations section. 
Therefore, no additional text is needed (but others may find it 
desirable--I leave that decision to this WG). At least it's now a part 
of the discussion record on this mailing list.

I just did a cursory check of some browsers on a Windows 7 machine. 
Ironically, Windows Explorer and Internet Explorer claim that they 
cannot find the ADS path, but Firefox and Chrome/Chromium-based browsers 
will load the ADS path all right. (I did not test what happens with 
relative references in, e.g., ./foo.txt:composite.html.)

Not sure if other file: URI processors handle such things, e.g., 
extended attributes / getxattr in Linux.