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

[Matthew Kerwin <[e-mail]>]

On 3 January 2015 at 22:10, Graham Klyne <[e-mail]> 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.
>
>    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.
>
>
This is in the works. I've had a computer die, and been in full time
vacation mode for the past month, so I'm a bit behind schedule, but I'll
have something for folks to look at as soon as I can.



> 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
>
> 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).
>
>
Is there a reference somewhere that distinguishes URIs and URLs the way you
guys are here? I thought URL was still a subset of URI. Has that changed?



>
> 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.
>
>
Indeed. The normative core of the spec will be the pure RFC 3986-compatible
parts; the non-normative appendices will include bad things like pipe
characters and backslashes and such. I think it would be helpful to
*suggest* how to map those to valid URIs, at the very least so people can
update their old documents.


-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/