Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927E112D0E0; Sun, 15 May 2016 09:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnKwp6uCjiXF; Sun, 15 May 2016 09:14:21 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A33712B01B; Sun, 15 May 2016 09:14:21 -0700 (PDT) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D4C57509B8; Sun, 15 May 2016 12:14:18 -0400 (EDT) To: Matthew Kerwin References: <20160515051508.2444.90815.idtracker@ietfa.amsl.com> From: Sean Leonard Message-ID: <38873e4f-235e-54c1-9580-cb0696d85cd2@seantek.com> 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: draft-ietf-appsawg-file-scheme@ietf.org, IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-09.txt X-BeenThere: apps-discuss@ietf.org 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 This is a multi-part message in MIME format. --------------AF56DCD46DF470E5094B5710 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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, internet-drafts@ietf.org > 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. > > > =E2=80=8BWell, I did access the en-us versions. When I go to the short = URL you=20 > 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=20 > confused, though; MS-DTYP now includes an ABNF (which is cool) but=20 > it's broken (which is not cool.) I think I know what they meant to=20 > say, but that's not what they've actually said. I don't feel great=20 > 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=20 problems with that ABNF in gg465305: host-name =3D "[" IPv6address =E2=80=98]" / IPv4address / reg-na= me has a turned comma; it should be: host-name =3D "[" IPv6address "]" / IPv4address / reg-name pchar, fchar, and schar are defined in the range 00h-FFh. However, the=20 definition says that "The filespace selector is a null-terminatedUnicode = character=20 string".=20 The reference to "Unicode character" says "Unless otherwise specified, a = 16-bit UTF-16 code unit." Also: "Unless otherwise specified, allUnicode=20 strings=20 follow=20 the UTF-16LE encoding scheme with no Byte Order Mark (BOM)." (Unicode=20 string) This would mean that the domain of the ABNF is 0000-FFFF. I am fairly certain that Windows does not enforce well-formedness=20 Unicode surrogate sequences, which makes the ABNF easier: you can blow=20 through %x80-FFFF without needing special handling of high and low=20 surrogate points. /However/, the RPC type is defined as STRING, which is UCHAR*, which is=20 "a null-terminated string of 8-bit characters". Therefore, we might be=20 in UTF-8 land. If in UTF-8 land, is the UTF8-non-ascii production=20 appropriate? (RFC 6532 & RFC 3629) I haven't groked pchar, fchar, or schar. Overall, however, the authors=20 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? > =E2=80=8B > > 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. > > > =E2=80=8BThey might, but I don't have one. What would you suggest? What= is=20 > currently done? > =E2=80=8B Need someone else to chime in on this (and the other stuff). Sean --------------AF56DCD46DF470E5094B5710 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/15/2016 5:24 AM, Matthew Kerwin wrote:


On 15 May 2016 at 20:15, Sean Leonard <dev+ietf@seantek.com> wrote:
On 5/14/2016 10:15 PM, internet-drafts@ietf.org 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.


​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-terminated Unicode character string". The reference to "Unicode character" says "Unless otherwise specified, a 16-bit UTF-16 code unit." Also: "Unless otherwise specified, all Unicode strings follow 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).

Sean
--------------AF56DCD46DF470E5094B5710--