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

Matthew Kerwin <> Sun, 04 January 2015 13:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8CB4B1A8893 for <>; Sun, 4 Jan 2015 05:02:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.627
X-Spam-Status: No, score=-1.627 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id muPnVBbSWVDY for <>; Sun, 4 Jan 2015 05:02:22 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DF6111A00A8 for <>; Sun, 4 Jan 2015 05:02:21 -0800 (PST)
Received: by with SMTP id i17so14741244qcy.35 for <>; Sun, 04 Jan 2015 05:02:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g3rqPFBEF/2IxbwamyDQHdLTQ5TT/VVCy39k2A92mME=; b=Gb3rQQ2yhnjay6ZCR80/r5d+dlm/CmQ797z1PBhWY4XPQcYIqFt+q3/mX17PiMSP6a ffMrkE+GiuZB0ibfmvItH7fS9S2YJszD2F6YZ38vJwQFjxwO2n9cCRRmVjqj0pPsnqzG DpFLPptASXfWbCdP6lvs4w3Wx40iWfhT6bQt/AoHlWT9vC1D3nOqyowRQVX/jGZn1Aw9 Vu3Zv5oxc/d5fKwA53dkrdyQ2Zi/Mx4835nIBtncsjy+iRXRNKrHM/hEylm0gNPjFNaG KALdpCXO6Opd272+9lEc21gT67iUGT9kq1EB59UWVRsl27TcElN6QH30+maT3Z41zxlp U+sA==
MIME-Version: 1.0
X-Received: by with SMTP id mk9mr137045937qcb.4.1420376540957; Sun, 04 Jan 2015 05:02:20 -0800 (PST)
Received: by with HTTP; Sun, 4 Jan 2015 05:02:20 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
Date: Sun, 04 Jan 2015 23:02:20 +1000
X-Google-Sender-Auth: NWpHQdamSDhZxKAq_tWOhLtiDLo
Message-ID: <>
From: Matthew Kerwin <>
To: Graham Klyne <>
Content-Type: multipart/alternative; boundary="001a11334d902bd312050bd32fbd"
Cc: IETF Apps Discuss <>
Subject: Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 04 Jan 2015 13:02:27 -0000

On 2 January 2015 at 01:57, Graham Klyne <> wrote:

> Matthew,
> I've finally been prompted to read through your
>  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

> 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

> 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://
>   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], <> Section 3.3
<>) as per Section 2 of
[RFC3986] <>."?

> Section 6:
> Can you please include a full registration template for the file: scheme
> here. cf.
> (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