Subject: [apps-discuss] Working Group Last Call for draft-ietf-appsawg-file-scheme

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 2 Nov 2015 12:50:08 +0900

Colleagues,

This note starts a Working Group Last Call for
draft-ietf-appsawg-file-scheme.  This document has been with us for a while
and feedback has fallen to a trickle.  We've gotten all the feedback from
W3C that we expect, so we'd like to move it toward publication.

Please provide review comments or expressions of support for the current
version either on this list or privately to
[email-masked] on or before November 20,
2015.  Be as detailed as possible.  The co-chairs need to determine if the
document has working group consensus, which means we need to know people
have read the latest version and agree with its content and with the idea
that it is ready to proceed.  A simple “+1” doesn’t tell us anything.

Also, if any participant has knowledge of IPR that needs to be declared on
this work, please do so, as required by BCPs 78 and 79.

Dave Crocker is fulfilling the duties of document shepherd.

-MSK, APPSAWG co-chair

---

From: Ned Freed <[email-masked]>
Date: Mon, 02 Nov 2015 13:42:06 -0800 (PST)

I scanned the document, and maybe I'm missing something obvious, but it looks
to me like the material about the "authority" field is a bit mixed up.

The document starts by importing the "authority" production from RFC 3986,
but AFAICT never actually uses the production. That production is:

  authority     = [ userinfo "@" ] host [ ":" port ]

The reason it's not used is the [ ":" port ] part is unneeded and unwanted. (I
think I agree with that assessment, but even so this difference from the
generic syntax should be stated somwhere.)

The production that's used instead is:

  file-auth      = [ userinfo "@" ] host

Which is a fine way to get rid of the unwanted optional port clause. But then
the document speaks of things in terms of use or non-use of the "authority"
field, when that field does not in fact appear in the file: URI ABNF. 

I can think of a bunch of different ways of addressing this problem, e.g.,
changing file-auth back to authority and noting the difference between it here
and in RFC 3986, but since I'm not familiar with the document history and how
it has arrived at this point it would be a bit presumptious of me to suggest a
specific course of action.

I also found the directions in section 3.1, "Translating Local File Path to
file URI", regarding the authority field to be a bit confusing. Step 3 says:

 3.  If including an empty authority field, append the "//" sigil to
       the URI.

No explanation given as to why I might - or might not - want to include an
empty authority (file-auth) field. Some elaboration here would be nice.

It also took me a minute to figure out that when the text talks about a local
versus non-local file path, it's really talking about the sort of file: URL
that's being output. The way I think of it is that you start with a local file
path and either do or don't add host information to make it into a local or
non-local file: URI.

Or, to put it another way, while some systems, e.g. OpenVMS, have a special
syntax for a "non-local file path", most systems don't. What you have instead
is two (or more) separate pieces of information, usually a host name and
absolute file path, that you then combine to create a non-local file: URI.

In regards to this last I'm not actually advocating any change, mostly
because I can't think a better way to say it, but I did want to make note
of the potential issue.

				Ned

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 3 Nov 2015 10:10:05 +1000

> field, when that field does not in fact appear in the file: URI ABNF.
​You're right, the text in Section 2 wasn't updated when the ABNF stopped
directly using the "authority" rule. I'll fix that up, and make sure the
right things are imported.

Throughout the document I used both "path" and "authority" to refer to
functional components of the URI, rather than syntactic, even though both
of those words are also used as ABNF rules in RFC 3986. If we remove the
import, does that resolve the issue? (Would we then need a definition of
"authority", or is the ref to RFC 3986 enough?)

> empty authority (file-auth) field. Some elaboration here would be nice.
​Hmm, yes. How about something in the relevant paragraph in section 2, to
the effect of: "To maximise compatibility with previous specifications,
implementations MAY include an empty file-auth." ?

Incidentally I just noticed another mistake; in that paragraph it says 'the
"auth-path" rule can match...' instead of 'the "file-auth" rule...'. I've
fixed that in github[1]​.

> because I can't think a better way to say it, but I did want to make note
That's a fair observation. Yes, the distinction is between 'URIs with no
authority, or a blank authority, or where the authority eq "localhost"' vs
any others. I couldn't think of better names then "local" and "non-local."

OpenVMS was an interesting case for me, because before that the only
non-local paths I'd seen were SMB shares/UNC paths, which already look a
bit like URLs. Since we're all living in hypervirtualised cloud-based
distributed computing environments these days, I really tried not to talk
about the actual location of the file; all I really wanted to know was "can
you turn this URI into a Unix file path?" and the obvious signal for that,
harking back to RFC 1738 (or even 1630) was whether there's a non-localhost
"host" in the authority. Inversely, then, a "local file path" would be one
that can be losslessly turned into a URI like "file:/path". This is purely
syntactic, although it could become a bit more semantic if the question
changes to "can you open() it?"

I tried to sum that up in a single sentence in section 1.3, but that might
not have been sufficient. ;)

​​[1]: http://phluid61.github.io/internet-drafts/file-scheme/​

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

---

From: Ned Freed <[email-masked]>
Date: Mon, 02 Nov 2015 22:44:59 -0800 (PST)

> import, does that resolve the issue?

No, not really. If anything it makes it worse, because now you're talking about
something that's effectively undefined.

> (Would we then need a definition of

You need to link whatever term you use to the component of URL it refers to.

> implementations MAY include an empty file-auth." ?

That sounds OK to me.

				Ned

---

From: Matthew Kerwin <[email-masked]>
Date: Fri, 13 Nov 2015 10:10:19 +1000

Ahh somehow I managed to not see this email for a whole week. It's marked
as "read" in gmail and everything. Sorry!

On 3 November 2015 at 16:44, Ned Freed <[email-masked]> wrote:

> > > Which is a fine way to get rid of the unwanted optional port clause.
> But
> > > then
​That's true, but it was always the case for "path"​ and nobody seemed to
mind that. It would have been convenient if the core spec defined some sort
of URI object model, so we could subclass it appropriately; however since
we've only the ABNF rules to go on, would something like this suffice?

   The core syntax in RFC 3986 includes "path" and "authority"
   components, for each of which only a subset is used in the definition
   of the file URI scheme. The subset of "path" is "path-absolute", and
   the subset of "authority" is "file-auth".

I think that also carries the semantics of what the authority /*means*/
over to "file-auth," in its limited applicability.

> > > changing file-auth back to authority and noting the difference between
> it
> > > here
> > > and in RFC 3986, but since I'm not familiar with the document history
> and
> > > how

​Ok, I've changed it to:

   As a special case, the “file-auth” rule can match the string
   “localhost” or the empty string; either value is interpreted as “the
   machine from which the URI is being interpreted,” exactly as if no
   authority was present. To maximise compatibility with previous
   specifications, implementations MAY choose to include an empty
   “file-auth”.​

Seeing that with Chrome's spelling suggestions makes me wonder if I should
Americanize all my "-ise" words, or just leave it for the editors.

Cheers

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Nov 2015 17:09:16 +0000

Hi,
Sorry for the late review.

> On 2 Nov 2015, at 03:50, Murray S. Kucherawy <[email-masked]> wrote:
> 
> Colleagues,
> 
> This note starts a Working Group Last Call for draft-ietf-appsawg-file-scheme.  This document has been with us for a while and feedback has fallen to a trickle.  We've gotten all the feedback from W3C that we expect, so we'd like to move it toward publication.
> 
> Please provide review comments or expressions of support for the current version either on this list or privately to [email-masked] on or before November 20, 2015.  Be as detailed as possible.  The co-chairs need to determine if the document has working group consensus, which means we need to know people have read the latest version and agree with its content and with the idea that it is ready to proceed.  A simple “+1” doesn’t tell us anything.

I read and reviewed the document and I am pleased with its quality. I haven't tested various statements about what different implementations do. I support the document being published.

Alexey,
as an APPSAWG participant.
> 
> Also, if any participant has knowledge of IPR that needs to be declared on this work, please do so, as required by BCPs 78 and 79.
>

---

From: t.petch <[email-masked]>
Date: Tue, 24 Nov 2015 10:24:04 +0000

---- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "IETF Apps Discuss" <[email-masked]>
Sent: Monday, November 02, 2015 3:50 AM

Colleagues,

This note starts a Working Group Last Call for
draft-ietf-appsawg-file-scheme.  This document has been with us for a
while
and feedback has fallen to a trickle.  We've gotten all the feedback
from
W3C that we expect, so we'd like to move it toward publication.

Please provide review comments or expressions of support for the current
version either on this list or privately to
[email-masked] on or before November
20,
2015.  Be as detailed as possible.  The co-chairs need to determine if
the
document has working group consensus, which means we need to know people
have read the latest version and agree with its content and with the
idea
that it is ready to proceed.  A simple “+1” doesn’t tell us anything.

<tp>

Ah well, in that case I shall have to make some editorial suggestions:-)

s1.1
**/former/the former/

References
   [Win32-Namespaces]
lacks a URL

Appendix C
The phrase which starts
" Regular DOS or Windows file URIs, ..."
threw me at first, until I realised that it was an 'i.e.' for the three
lines above.  There was a case recently where the RFC Editor removed the
indentation and turned comprehensible pseudo-code into
easy-to-misunderstand pseudo-code so something similar might happen here
I think that the text should be reordered so that the indentation is not
needed to make this easy to understand.  For example,

OLD
This is intended to support URIs of the form:

   o  "file:///c|/path/to/file"

   o  "file:/c|/path/to/file"

   o  "file:c|/path/to/file"

         Regular DOS or Windows file URIs, with vertical line characters
         in the drive letter construct.

NEW

This is intended to support regular DOS or Windows file URIs, with
vertical line characters in the drive letter construct e.g.

   o  "file:///c|/path/to/file"

   o  "file:/c|/path/to/file"

   o  "file:c|/path/to/file"

This applies in several places in Appendix C.

Appendix F

This imports rules from the non-Normative Appendix C and is thus, I
presume, non-Normative.

Tom Petch

Also, if any participant has knowledge of IPR that needs to be declared
on
this work, please do so, as required by BCPs 78 and 79.

-MSK, APPSAWG co-chair

------------------------------------------------------------------------
--------

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Graham Klyne <[email-masked]>
Date: Tue, 24 Nov 2015 12:22:31 +0000

All,

Apologies for my late response - I missed the original last call, and early 
follow-up.

I would be happy for this to go forward as-is, but I do have a couple of minor 
comments to offer (if only to prove I actually read it again!).

...

[Minor] In section 3, I'm finding the reference to "implementation" a bit vague 
(does this mean URI generators, parsers, or what?), though I suppose it's easy 
enough to figure from the context.

Suggest:

OLD:
3.  Operations on file URIs

    Implementations SHOULD, at a minimum, provide a read-like operation
    to return the contents of a file located by a file URI.  Additional
    operations MAY be provided, such as writing to, creating, and
    deleting files.  See the POSIX file and directory operations [POSIX]
    for examples of standardized operations that can be performed on
    files.

NEW:
3.  Operations on file URIs

    Implementations that provide dereferencing operations on file: URIs
    SHOULD, at a minimum, provide a read-like operation
    to return the contents of a file located by a file URI.  Additional
    operations MAY be provided, such as writing to, creating, and
    deleting files.  See the POSIX file and directory operations [POSIX]
    for examples of standardized operations that can be performed on
    files.

(I hope it's clear that "dereference" is used here in the sense of section 1.2.2 
of RFC3986 - https://tools.ietf.org/html/rfc3986#section-1.2.2)

...

[Minor] In section 3, the text "can only be dereferenced" seems a bit strong - 
in that it appears to prohibit dereferencing lon-local file URIs.

Suggest:

OLD:
    A file URI can only be dereferenced or translated to a local file
    path if it is local.  A file URI is considered "local" if it has a
    blank or no authority, or the authority is the special string
    "localhost".

NEW:
    A file URI can be dependably dereferenced or translated to a local file
    path only if it is local.  A file URI is considered "local" if it has a
    blank or no authority, or the authority is the special string
    "localhost".

...

(Section 6, aside: it's really strange for me to read "HP OpenVMS Systems 
Documentation" -- but of course, it's quite correct.)

...

Good work!

#g
--

On 02/11/2015 03:50, Murray S. Kucherawy wrote:
> Colleagues,
>
> This note starts a Working Group Last Call for draft-ietf-appsawg-file-scheme.
> This document has been with us for a while and feedback has fallen to a
> trickle.  We've gotten all the feedback from W3C that we expect, so we'd like to
> move it toward publication.
>
> Please provide review comments or expressions of support for the current version
> either on this list or privately to
> [email-masked]
> <mailto:[email-masked]> on or before November
> 20, 2015.  Be as detailed as possible.  The co-chairs need to determine if the
> document has working group consensus, which means we need to know people have
> read the latest version and agree with its content and with the idea that it is
> ready to proceed.  A simple “+1” doesn’t tell us anything.
>
> Also, if any participant has knowledge of IPR that needs to be declared on this
> work, please do so, as required by BCPs 78 and 79.
>

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 26 Nov 2015 11:30:31 +1000

Thanks for the review, I'll incorporate all the straight-forward
suggestions (see inline).

> Ah well, in that case I shall have to make some editorial suggestions:-)

​Thanks, I'll fix these.

> ​
> ​

​I see the point here, and  do want to avoid any potential issues with
readability. The current layout hangs over from when there was a single
large list of examples of all the supported constructs. Now the "real" list
shows up in Appendix A, with the non-standard fragments scattered
throughout Section C. I'd like there to be consistency between the various
examples; I'll think a bit more on how to present it.

> ​
> ​
> ​​
​
> This imports rules from the non-Normative Appendix C and is thus, I
​Yes, I'll make that explicit.​

> Tom Petch
​Cheers

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 26 Nov 2015 11:50:21 +1000

On 24 November 2015 at 22:22, Graham Klyne <[email-masked]> wrote:

> All,
>
> Apologies for my late response - I missed the original last call, and
> early follow-up.
>
> I would be happy for this to go forward as-is, but I do have a couple of
> minor comments to offer (if only to prove I actually read it again!).
>
>
​Thanks, it's appreciated.​

> ...
>
> [Minor] In section 3, I'm finding the reference to "implementation" a bit
> vague (does this mean URI generators, parsers, or what?), though I suppose
> it's easy enough to figure from the context.
>
> Suggest:
>
> OLD:
> (I hope it's clear that "dereference" is used here in the sense of section
> 1.2.2 of RFC3986 - https://tools.ietf.org/html/rfc3986#section-1.2.2)
>
>
​Yeah, that's a fair call. I'll take the suggested addition.​

> ...
>
> [Minor] In section 3, the text "can only be dereferenced" seems a bit
> strong - in that it appears to prohibit dereferencing lon-local file URIs.
>
> Suggest:
>
> OLD:
​Again, yes, that's good. I think it better expresses the intent.  This is
a little different from 1738, which seemed to carry the weight of judgement
(remote files are bad, don't read them) but I don't think that's what we
want to say now.

> Documentation" -- but of course, it's quite correct.)
Starlet? VAX? Micro? (I used Wikipedia to look those up; to me they're just
arcane words you see from time to time in ancient manuals.)

> #g
​Thanks!

​Cheers