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

[Matthew Kerwin <[e-mail]>]

On 2 January 2015 at 01:57, Graham Klyne <[e-mail]> wrote:

> Matthew,
>
> I've finally been prompted to read through your
> https://tools.ietf.org/html/draft-kerwin-file-scheme-13.  I think it's
> great that this is being tackled (again), and I'm hoping that there will be
> enough pragmatism this time round to achieve consensus on something that's
> an improvement over the status quo, even if not perfect.
>
> My comments follow...
>
>
> Section 2: windows-path
>
> I'm pretty sure I've come across '/c:/rest-of-path' as a mapping of
> Windows file paths (I'm not sure where; I may even have used it myself.  It
> makes some logical sense to me in that on Windows (non-UNC-naming) the
> drive letters are effectively the top-level directories in a single-root
> file system.)
>
> But that would subsumed by 'path-absolute'.  [Later] I see you have this
> covered as an example, and more.
>
>
Yes, the ABNF is currently being changed to remove a lot of unnecessary
redundancy and confusion like this, and also hopefully to resolve the
following point.



>
> Section 2: Inclusion of "|"
>
> As others have raised, there's an question of how to deal with common
> extensions to normal URI syntax, and separation of a preferred core for
> file: URI syntax from documentation of common variations.  If possible, my
> preference would be to treat non-conformance with RFC3986, like this, as a
> common variation.  I think 'core' file URIs should preferably be fully
> RFC3986 conformant so that existing generic parsers will handle them.
>
> [Later] I see you have this covered too.
>
> I think the document might be clearer in its intent if at the start of
> section 2, and in the syntax productions, it were more clearly signaled
> that the syntax described here includes commonly-used forms that go beyond
> RFC3986 syntax.
>
>
​The current plan is to move it to a non-normative appendix as a "commonly
used but invalid" thingy, so the normative construct can be simpler.​



>
> Section 2: local vs non-local
>
> See below.  I think this is a non-relevant distinction.  e.g. Is a remote
> file system mounted on a Unix-style mount point supposed to include an
> authority?
>
>
Probably not. My intention was to distinguish things that don't have an
authority (can use local filesystem calls to access) from those that
require an authority (must be opened some other way, like a different
syscall, or by implementing some other protocol). This part of the language
would benefit from having more peoples' input.



>
> Section 3: methods on file URIs
>
> I'm not sure I agree that translation to filename is the  *only* operation
> that can be done using a file: URI.  And I have concerns about use of the
> term "method" here, which is strongly suggestive of HTTP "methods".
> ​
> ​
>
> ​
> ​


​RE the only operation: rather than deal with trying to define (or
reasonably leave unspecified) the set of operations that are made available
by the local filesystem API, I went a bit reductive. I'm not sure of a
better way forward, other than to make the language less strong.

RE the term "method": actually that's my OO programming background shining
through, but yes, BCP 35 or 115 or whatever it's called uses "operations"
so I can change to conform with that.


​
>
> ​​
> Specifically, dereferencing:  I have frequently used APIs that retrieve
> the entity referenced by a URI, including file: URIs.  Indeed, in much of
> my code, this is central to unifying web and local file access.   I think
> retrieval is an operation that is very naturally performed on a file URI,
> with results broadly equivalent to an HTTP GET.  Some analogue to HTTP PUT
> is also conceivable.
> ​​
>
> ​
> ​


Yes, that's fair, I was being overly reductive. Presumably file: URIs ought
to support the full CRUD suite, assuming the underlying filesystem allows
it.


​
>
> I think the issue here is not that the nature of operations that can be
> performed is restricted, but the details of how to perform them, which will
> vary from system to system.
>
> You also say "The local file system API can only be used if the file URI
> has a
>    blank (or absent) authority and the path, when transformed to the
>    local system's conventions, is not a UNC string."
>
> A common case I've come across is where the authority is "localhost", in
> which case it seems reasonable to allow local file access based the file:
> URI.
> ​​
>
> ​
> ​


​I've swung back and forth on this particular topic. The issue is that some
folk (including Chrome) treat "file://localhost/foo" as \\localhost\foo
(i.e. a samba file share served from this machine), and when it comes to
choosing one way or the other, this time I went with Chrome.

This is a change (potentially a big one?) from 1738, but I guessed it was
reasonable.


​
>
> More generally, it seems to me that the difference between local and
> remote files (with or without host) is in the mechanism that might be used
> to access the file.  In some cases, it may be the same, by virtue of being
> handled by the underlying system's file system.  And in some cases, a
> filename that appears to have no host may in fact be remote (cf. remote
> file system, mounted on Unix-like file system).  I think that trying to
> make this distinction raises more questions than it answers.
>
>
That may be the case. Is it better to do a 1738 and not say anything useful
about a non-blank, non-localhost authority?



>
> Section 3.1 (esp step 4):
>
> I'm a bit confused by the intent here.  I think it's reasonably clear that
>
>   file://example.org/c:/path/segments
>   file:///c:/path/segments
>
> would be expected, but what about:
>
>   file:/c:/path/segments
> vs
>   file:c:/path/segments
>
> I think you prefer the latter.
>
> But I think it would be more consistent, and would avoid potential
> ambiguities in relative reference resolution, to prefer the former;  i.e.
> to consider that drives are like top-level sub-directories of a root "/".
> I think this section could also be thereby simplified a little.
>
>
​To be perfectly honest, if someone can propose something about the root
that makes my life easier, I'll welcome it with open arms. My struggle has
been with addressing the UNIX root directory, and now you're suggesting I
also include it in Windows. I guess if it's ubiquitous it saves me the
burden of trying to describe it, or explain when not to use it.​



>
> Section 3.3, steps 5, 6:
>
> I think it is necessary to say something about %-escaping here.  I've been
> bitten in the past by doing roughly what you describe here, with filenames
> that happen to contain (say) '#' characters.
>
>
Isn't that covered by "Transform the directory name to a path segment (
[RFC3986], <https://tools.ietf.org/html/rfc3986#section-3.3> Section 3.3
<https://tools.ietf.org/html/rfc3986#section-3.3>) as per Section 2 of
[RFC3986] <https://tools.ietf.org/html/rfc3986#section-2>."?



>
> Section 6:
>
> Can you please include a full registration template for the file: scheme
> here. cf.  https://tools.ietf.org/html/rfc4395#section-5.4
>
> (Many of the fields will just refer to other sections of the document)
>
>
It used to be like that until version 12, when somebody (I can't remember
who) suggested it could be simplified to what it currently is.




>
> Again, thanks for tackling this.
>
>
​No worries, thanks for the comments.​


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