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

[Sean Leonard <[e-mail]>]

On 5/15/2016 5:24 AM, Matthew Kerwin wrote:
>
>
> On 15 May 2016 at 20:15, Sean Leonard <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 5/14/2016 10:15 PM, [e-mail]
>     <mailto:[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}
>     <https://msdn.microsoft.com/library/%7BARTICLEID%7D>
>
>     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-terminatedUnicode 
character 
<https://msdn.microsoft.com/en-us/library/cc230275#gt_fd33af2e-e1ce-4f8e-a706-f9fb8123f9b0>string". 
The reference to "Unicode character" says "Unless otherwise specified, a 
16-bit UTF-16 code unit." Also: "Unless otherwise specified, allUnicode 
strings 
<https://msdn.microsoft.com/en-us/library/cc230275#gt_b069acb4-e364-453e-ac83-42d469bb339e>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