Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

[Sam Ruby <[e-mail]>]

On 01/02/2015 09:27 AM, Graham Klyne wrote:
> On 01/01/2015 19:08, Sam Ruby wrote:
>>>> https://mailarchive.ietf.org/arch/msg/apps-discuss/KyxFLw2FCwv7CSpiWAmLr8Ha7vc
>>>>
>>>
>>> This raises two points for me:
>>>
>>> 1. 'file: should be seen as an "escape hatch"'.
>>>
>>> I disagree.  For me, the value of file: URIs is to provide a file naming
>>> structure that can be used in libraries that unify local and web access
>>> to resources.  So I think it's important that file: URIs follow common
>>> URI syntax and resolution mechanisms, even if their interpretation for
>>> the purposes of dereferencing, etc., is defined locally.
>>>
>>> (This is not to impose "normative statements on OS vendors for their own
>>> software" - unless the vendors choose to use URIs natively for file
>>> naming.)
>>
>> I'll contrast "can be used in libraries that..." (immediately above),
>> and "works
>> for everyone" (previous point).
>>
>> If the intent of draft-kerwin-file-scheme is only to be valid in a
>> subset of
>> libraries, then it should say so.  If it is intended to also match
>> other user
>> agent behaviors (e.g. browsers), then we collectively have
>> considerably more
>> work to do.
>
> I never made that claim.

I'm confused.  Let me try again.

I am making the claim that draft-kerwin-file-scheme does "work for 
everyone".  Either there needs to be considerably more work done, or it 
needs to reduce its scope.

> I also think it is not the role of the URI spec to describe "agent
> behaviour" (beyond relative reference resolution, if that is a
> "behaviour").
>
> I think it is the role of the URI spec to:
>
> (a) define what constitutes a valid URI, and URI reference, and
>
> (b) describe how to combine a valid base URI with a valid URI reference
> to yield a valid resulting URI.
>
> Which is, of course, what RFC3986 does (how well is up for discussion).

I, indeed, would like to discuss that topic.

> I fully accept that there may be desirable agent behaviours that are not
> covered here, and that an additional document may be desired to describe
> these, particularly where the behaviours impact interoperability.

I would like to discuss that topic too.

Whether that document is separate or not will depend on the outcome of 
the discussion as to whether RFC 3986 matches current, deployed 
applications.

>>> 2. Use of vendor-specific documentation
>>>
>>> I agree with this, specifically: "The right way ... is to write the RFC
>>> in such a way that OS-specific variations are not required for
>>> RFC-compliance in the first place"
>>>
>>> So it's clear to me that there are aspects of file: URI handling that
>>> are local-context dependent (e.g. how to actually dereference).  But I
>>> think other activities (such as relative reference resolution should be
>>> possible without regard to the underlying file system implementation -
>>> and this is the level of commonality that a file: URI scheme RFC should
>>> aim to provide.
>>
>> I'll note that draft-kerwin-file-scheme includes such constructs as
>> windows-path
>> and unc-path.
>
> Sure, but I'm not sure what point you're making here.

Let me try to make that point in a different way then.  I'm skeptical 
that Apple will be interested in implementing any portion of a 
specification that is specific to Microsoft Windows.  This goes back to 
the point of trying to build a specification that "works for everyone".

> I would want to see all such system-specific forms conform to standard
> URI syntax, and to yield the desired results when resolved using a
> standard resolution algorithm.

We are going to need to qualify that statement considerably.

Here is an example of a system-specific form: "C:\Program Files (x86)".

A strategy that is more likely to be successful would be to identify 
URIs as being completely system independent, and URLs as being mostly 
system independent, and for there to be a well known and documented 
mechanism for converting from URLs to URIs.  Even that is not likely to 
be completely achieved -- the conversion may end up being (at least 
partially) system dependent, but in such cases we should be able to 
define the problematic set of the inputs as non-conforming.

An example of a restriction we should consider: valid schemes must have 
at least two characters.

>>>> It is my hope that by working together I can feel confident enough to
>>>> remove
>>>> that red box.  As it is, I don't feel that either spec matches widely
>>>> deployed
>>>> applications.
>>>
>>> Fair enough.  Which suggests to me that focusing on a single focused
>>> spec and aligning around that might be a productive way to tackle this.
>>
>> What I am focused on is the following question: what should a
>> "URI.parse" method
>> do?  In some ways that question is more general (in that is isn't
>> file: scheme
>> specific).  In some ways that question is more focused (in that it
>> doesn't
>> attempt to describe the operating system specific interpretations of
>> the results).
>
> For me, the question of what URI.parse *does* goes beyond what the core
> URI spec needs to define.  But I agree about operating system specific
> behaviours of file: URIs being outside the desirable scope of that core
> spec.

Can I get you to explain what you mean by this.  We can ignore operating 
system specific behaviors for the moment.  I would think that the basic 
operation of identifying the scheme, path, fragment, etc for a given 
input is exactly what a URI spec needs to define.  Why do you think 
otherwise and/or what am I missing?

>>> <aside>
>>> A problem for me is (as I've said before in other forums) that RFC3986
>>> is a perfectly good specification of URI syntax and I don't see the need
>>> to consult any other.  So why should I put energy into so doing?  I make
>>> this point on the presumption that I'm not the only one who is OK with
>>> RFC 3986.
>>>
>>> Now, if the community decides that some other spec is the True
>>> Pronouncement about URI syntax, I shall have to reconsider.  But I don't
>>> see why I should be asked to put energy into reviewing a specification
>>> which doesn't give me anything I don't already have.
>>>
>>> This doesn't mean I oppose this specification in its goals to cover
>>> areas that are not covered by RFC3986.  But, speaking personally, I'd
>>> really like to be assured that any valid RFC3986 URI will be acceptable
>>> according to the syntax you describe.  That way I don't have to read the
>>> other document if I don't want the extra capabilities it offers.
>>
>> I have evidence that RFC 3986 doesn't match a variety of user agent
>> behavior.
>> Agents that aren't limited to browsers, but also to libraries that are
>> used by
>> what you would consider "middleware".
>>
>> Here is a filtered list of test results that only considers RFC 3986
>> valid URI
>> references as inputs:
>>
>> https://url.spec.whatwg.org/interop/test-results/?filter=valid
>
> I took a brief look, but haven't delved into the details of your
> results.  At that superficial level, the list suggests to me that there
> are many cases where implementations are buggy, and in different ways.
> It doesn't tell me what are the problems in RFC3986.

We can agree that implementations don't match RFC 3986.  In such cases, 
where the bug is would be need to be determined on a case by case basis.

> In a brief sampling, I couldn't see any divergence which is likely to be
> resolvable by changing the URI spec.

I encourage you to spend more time with that data.  An example of a 
concrete problem is handing of hosts in a UTS-46 compliant manner.

> #g
> --

- Sam Ruby