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

[Sean Leonard <[e-mail]>]

Basically this entire reply is a big +1 in the hopes of converging on 
consensus and moving onwards.

On 1/3/2015 4:10 AM, Graham Klyne wrote:
> Sam,
>
> Rather than continue the blow-by-blow exchange of points, let me try 
> and respond in one place where I think we stand:
>
>
> 1. I agree that draft-kerwin-file-scheme *should* work for everyone.  
> And that probably means reducing the scope of anything there that may 
> be considered normative.
+1
>
>    But I also believe it can be useful to document other behaviours 
> *informatively*.  I think this is discussed elsewhere and anticipate 
> evolution in this direction.  This could mean, to develop your 
> example, describing Microsoft Windows specific behaviours without any 
> expectation that such behaviours would be implemented by Apple.
+½

As I have stated previously, I do not believe that a Standards-Track RFC 
on this topic should enumerate local forms (i.e., Windows vs. Mac OS X 
vs. VMS vs. whatever). But informative text does not seem harmful to me.

>
>
> 2. I think our disagreement may lie primarily in the area of what 
> should be the scope of RFC 3986 or its successor.  There is (I claim) 
> a substantial developer community who are familiar with RFC3986 as it 
> stands, and creating a new document to cover the same material with 
> enlarged scope is unnecessary and disruptive. The additional scope 
> coverage could be in a new document that builds upon what RFC3986 does 
> specify.
>
>    Part of this disagreement is that I don't think the URI core spec 
> needs to describe the operation of splitting a URI into its 
> components.  (I regard https://tools.ietf.org/html/rfc3986#appendix-B 
> as merely informative.)  The syntax specification is sufficient to 
> associate substrings of a well-formed URI with named syntax productions.
+1
>
>    I also think the core URI spec should not be describing how to turn 
> non-URI strings (some of which may be system-dependent forms) into 
> valid URIs.  (Except URI-references, which are covered by the 
> resolution specification.)
+1
>
>
> 3. Where there is divergence between implementations and RFC3986, 
> these indeed should be considered on a case-by-case basis, but with 
> (IMO) the presumption that RFC3986 is correct.  I.e. it is for those 
> who think there is a problem with RFC3986 to make the case.
+1
>
>    You ask me to spend time with your data.  That's a big ask.  If 
> some implementers think there is a problem with RFC 3986 then I think 
> it is they who should be making the specific arguments about where 
> RFC3986 is problematic.  I accept that UTS-46 host names is such an 
> area, concerning which there should be a considered and focused debate 
> (and about which I have insufficient knowledge to make a meaningful 
> contribution).
+1. UTS-46 host names shouldn't affect the file: scheme any differently 
than anything else.

>
>
> 4. I agree with your point about qualifying my statement about 
> system-dependent forms conforming to core URI syntax.  While forms 
> such as "C:\Program Files (x86)" might be described as variations, I 
> don't think they should be considered to be valid URIs.
>
> I'm supportive of the strategy you outline (repeated here for ease of 
> reference), which I don't think is so different from what I've argued 
> for:
>
> [[
> 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.
> ]]
> -- 
> https://mailarchive.ietf.org/arch/msg/apps-discuss/lNsLrE3xDYpo2GyvgHzGGZv-PLI
+1

>
> Where I may diverge is that I don't think the "well known and 
> documented mechanism for converting from URLs to URIs" should be part 
> of the URI specification (cf. my point 2 above).
+1 it's a local convention issue

>
>
> 5. The previous point also begs the question of what should be covered 
> by the file: scheme document.  I think it may be appropriate to 
> describe some commonly occurring system-dependent file: URL forms, but 
> I'm less convinced that this is the place to describe how to map them 
> to URIs.  Any normative specification of file: URI formats should be 
> restricted to forms that comply fully with RFC3986.
+1

There could be some value in having a "normative" file: URI 
format...which if anything, probably means that it is:
file://{HOST}/{root stuff}/{directories...}/{filename}

In an abstract non-system-specific way, that fully complies with RFC 3986.

Individual systems (Windows, Mac OS) can have other forms (e.g., \ 
[which doesn't comply with 3986 and thus is not a URI] or : [which does 
comply and therefore is a URI, but isn't analyzable in the 3986 
p-component way]), and those other forms are acceptable for their use, 
but they aren't the "normative" form (whether or not they are "URIs") 
and that's okay.

The end.

Sean