Re: [apps-discuss] Call for Adoption: draft-kerwin-file-scheme

[Sean Leonard <[e-mail]>]

On 12/18/2014 6:06 AM, Scott Kitterman wrote:
> On Wednesday, December 17, 2014 08:37:34 Murray S. Kucherawy wrote:
>> This opens a call for adoption for draft-kerwin-file-scheme, to be
>> processed by APPSAWG.  There appears to be enough interest in the work
>> given the feedback it's getting, and it appears to fit within our charter.
>>
>> Please indicate your support or objection by replying to this thread.  The
>> call will close on January 9, 2015.
>>
>> -MSK, APPSAWG co-chair
> In its current form, the draft has normative references to two non-IETF
> documents that don't have clear licensing terms, specifically MS-DTYP and MS-
> NBTE.  As nearly as I can determine, these are not covered by the Microsoft
> Open Specification Promise [1].  Given that these are normative references, I
> think it's essential that their IPR status be clear.  I don't think it's
> appropriate on something as fundamental as the file URI scheme to end up with a
> document that's IPR constrained.
>
> Before this document is accepted, it should either be reworked to no require
> these as normative references or the IPR status of the references should be
> clarified to make it clear that their use is not encumbered (adding them to the
> OSP would be a great way to do this).

This is probably a good non-technical example of why I advocated for the 
"local convention" from a technical standpoint (see

http://mailarchive.ietf.org/arch/msg/apps-discuss/k80c33MWSWC2lxdGq0YmcrJi5Uw  ; also echoed in Larry Masinter's second comment http://mailarchive.ietf.org/arch/msg/apps-discuss/NsOYamN15GcMrSV1bBuOrA5XirY)

file: should be seen as an "escape hatch" for the (majority of) the string to be processed by an OS-specific filesystem API, with no more than rudimentary interpolation.

Documenting these operating-specific behaviors is all well and good, but passing normative statements on OS vendors for their own software will not get what you want or change the behaviors of these APIs/products. The best thing is to say "look to the [OS vendor] documentation for [normative guidance] on how this is constructed".

To pick a non-Microsoft example, consider Apple Mac OS X's handling of file URLs:
https://developer.apple.com/library/ios/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/AccessingFilesandDirectories/AccessingFilesandDirectories.html

The premise that normative documentation by one OS vendor (e.g., Microsoft) is required to interpret file: for that OS, should not be a barrier to the file: scheme in general or to an RFC in particular. The right way to deal with that is to write the RFC in such a way that OS-specific variations are not required for RFC-compliance in the first place. If you want to write a Linux tool that interprets Microsoft Windows file: URLs, #1 - why bother? it's not usable; #2 - as the tool author, shouldn't you be looking at Microsoft's documentation anyway, regardless of its licensing terms? You want compatibility with actual Windows software, not with some arbitrary RFC.

-Sean