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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 927E112D0E0; Sun, 15 May 2016 09:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 YnKwp6uCjiXF; Sun, 15 May 2016 09:14:21 -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 2A33712B01B; Sun, 15 May 2016 09:14:21 -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 D4C57509B8; Sun, 15 May 2016 12:14:18 -0400 (EDT)
To: Matthew Kerwin <>
References: <> <> <>
From: Sean Leonard <>
Message-ID: <>
Date: Sun, 15 May 2016 09:13:24 -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: multipart/alternative; boundary="------------AF56DCD46DF470E5094B5710"
Archived-At: <>
Cc:, IETF Apps Discuss <>
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 16:14:23 -0000

On 5/15/2016 5:24 AM, Matthew Kerwin wrote:
> On 15 May 2016 at 20:15, Sean Leonard < 
> <>> wrote:
>     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:
>     <>
>     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.
> ​Well, I did access the en-us versions. When I go to the short URL you 
> linked above, I get the en-au versions ;)

Yep. Short URL is language/locale-neutral.

> Nevertheless I can refresh the references and update the dates. I'm 
> confused, though; MS-DTYP now includes an ABNF (which is cool) but 
> it's broken (which is not cool.) I think I know what they meant to 
> say, but that's not what they've actually said. I don't feel great 
> referencing that, even informatively.

Well, the best solution is to report it to Microsoft and get them to fix 
it. You can reference this thread, among others. I see the following 
problems with that ABNF in gg465305:

host-name          = "[" IPv6address ‘]" / IPv4address / reg-name

has a turned comma; it should be:

host-name          = "[" IPv6address "]" / IPv4address / reg-name

pchar, fchar, and schar are defined in the range 00h-FFh. However, the 
definition says that "The filespace selector is a null-terminatedUnicode 
The reference to "Unicode character" says "Unless otherwise specified, a 
16-bit UTF-16 code unit." Also: "Unless otherwise specified, allUnicode 
the UTF-16LE encoding scheme with no Byte Order Mark (BOM)." (Unicode 
string) This would mean that the domain of the ABNF is 0000-FFFF.

I am fairly certain that Windows does not enforce well-formedness 
Unicode surrogate sequences, which makes the ABNF easier: you can blow 
through %x80-FFFF without needing special handling of high and low 
surrogate points.

/However/, the RPC type is defined as STRING, which is UCHAR*, which is 
"a null-terminated string of 8-bit characters". Therefore, we might be 
in UTF-8 land. If in UTF-8 land, is the UTF8-non-ascii production 
appropriate? (RFC 6532 & RFC 3629)

I haven't groked pchar, fchar, or schar. Overall, however, the authors 
of that MS spec have to determine and fix:

  * Is the ABNF in 0000-FFFF (16-bit units), or 00-FF (8-bit units)?
  * Is UTF-8 or UTF-16 intended?
  * What's actually going on in real life? I know that the Windows API
    is UTF-16LE. What about SMB on the wire?

> ​
>     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.
> ​They might, but I don't have one. What would you suggest? What is 
> currently done?
> ​

Need someone else to chime in on this (and the other stuff).