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

[Sean Leonard <[e-mail]>]

On 5/14/2016 10:15 PM, [e-mail] 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:
https://msdn.microsoft.com/library/{ARTICLEID}

Such as:
https://msdn.microsoft.com/library/gg465305
https://msdn.microsoft.com/library/aa365247

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.:
file:///G:/somebody.txt:other.txt

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.

Sean