Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt

From: [email-masked]
Date: Sun, 11 Jan 2015 17:12:16 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : The file URI Scheme
        Author          : Matthew Kerwin
	Filename        : draft-ietf-appsawg-file-scheme-00.txt
	Pages           : 16
	Date            : 2015-01-11

Abstract:
   This document specifies the "file" Uniform Resource Identifier (URI)
   scheme, replacing the definition in RFC 1738.

   It attempts to document current practices, while at the same time
   defining a common core which is intended to interoperate across the
   broad spectrum of existing implementations.

Note to Readers (To be removed by the RFC Editor)

   This draft should be discussed on the IETF Applications Area Working
   Group discussion list <[email-masked]>.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 12 Jan 2015 11:26:34 +1000

Hi all,

As you can see below, the file: scheme draft has been adopted by the WG.
I'm in the process of writing a mini-charter, part of which is a list of
people who will commit to doing timely reviews of the document.

Could I please ask for volunteers to provide reviews, whose names I can
list in the charter?

Cheers, and thanks.

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Jan 2015 08:42:18 +0100

> Could I please ask for volunteers to provide reviews, whose names I can

I volunteer.

Best regards, Julian

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jan 2015 09:01:47 -0800

> Could I please ask for volunteers to provide reviews, whose names I can

APPSAWG also regularly invites people other than the co-chairs to act as
document shepherd for the documents we develop.  If anyone would be
interested in filling this role for this document, please email
[email-masked].

-MSK

---

From: t.petch <[email-masked]>
Date: Mon, 12 Jan 2015 18:17:30 +0000

Matthew

Fascinating.

My post earlier today was intended to prod whoever would declare
consensus on adopting your I-D into declaring consensus.  I am not sure
what has happened, I see no statement of adoption in my Inbox or in the
IETF archives but no matter, as long as the powers that be agree on
adoption, that is fine.

My earlier note also speculated on the powers that be wanting a charter
change, in which case I proposed

'I see the objective, were it to be codified as such, as updating the
file: scheme from the level of RFC1738 to the level of RFC3986 and not
attempting to go beyond that. '

which remains what I will work toward.  Changes to RFC3986/RFC3987 I
regard as out of scope, bordering on a DoS attack.

Tom Petch

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "Matthew Kerwin" <[email-masked]>
Cc: "IETF Apps Discuss" <[email-masked]>
Sent: Monday, January 12, 2015 5:01 PM

> [email-masked].

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

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

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Jan 2015 12:24:04 -0600

> Could I please ask for volunteers to provide reviews, whose names I can

I'll review.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jan 2015 10:33:35 -0800

> regard as out of scope, bordering on a DoS attack.

Apologies for the confusion, if any, which was likely my fault.  I should
have had the mini-charter drafted and sent out as part of the Call For
Adoption rather than doing it after the fact.  In the pre-holiday rush I
got the order of operations backwards.

We do still need to square that away before we can do any real work on the
content.

-MSK, slightly sheepish APPSAWG co-chair

---

From: Nico Williams <[email-masked]>
Date: Mon, 12 Jan 2015 12:39:38 -0600

> IETF archives but no matter, as long as the powers that be agree on

The fact that draft-ietf-appsawg-file-scheme-00 got submitted with a
handle that starts with draft-ietf-appsawg- very strongly implies that
the APPS chairs thought there was consensus to adopt (since the author
could not have caused such an I-D to be accepted otherwise).

> attempting to go beyond that. '

I don't mind all sorts of informative language, but yes, as to RFCs 3986

> regard as out of scope, bordering on a DoS attack.

I agree most emphatically, at least if the proposed changes to those
RFCs were to be backwards-incompatible ones.

I doubt we'd reach consensus on backwards-incompatible changes to those
two RFCs, but if we were to try, we should do that via an explicitly
separate process (separate from the file URI I-D).

Nico
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Jan 2015 11:15:36 -0800

> could not have caused such an I-D to be accepted otherwise).

Also correct.  An email I sent to the author saying as much and inviting
him to submit a WG-named version should have been sent to the list.

-MSK, slightly more sheepish APPSAWG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 12 Jan 2015 15:11:52 -0500

> him to submit a WG-named version should have been sent to the list.

This issue I've previously mentioned about IPR encumbered normative references 
is still present in the update.  We really, really ought to have something as 
file: standardized in an unemcumbered manner.

Scott K

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 13 Jan 2015 09:49:17 +1000

> > Could I please ask for volunteers to provide reviews, whose names I can

Thanks Nico and Julian.

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 13 Jan 2015 10:01:25 +1000

> regard as out of scope, bordering on a DoS attack.
​Yes, that's essentially my goal. I've written this:

| The "file" URI scheme is woefully out of date. The document that defines
| it, RFC 1738, has been superseded by the generic URI syntax of RFC 3986,
| and its status is listed as "Obsolete". As such, the "file" URI scheme
| is viewed by many in the internet community as being without a current
| defining standard, and in need of updating to match current standards
| and implementations.
|
| This document defines an updated "file" URI scheme, promoting
| interoperability by being compatible with the generic syntax of
| RFC 3986, while enumerating commonly-encountered variations that have
| arisen during the scheme's long history of vague standardisation.
|
| Reviewers:
|
| * Julian Reschke <[email-masked]>
| * Nico Williams <[email-masked]>
| * Sean Leonard <[email-masked]>

Does that suit?​ If so I'll give it to Murray to put in the wiki.

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 13 Jan 2015 10:18:46 +1000

> file: standardized in an unemcumbered manner.
The update I submitted only changed metadata (name, date, working group),
so all the open issues remain.

​That said, I heartily agree. I'm trying to look up the conversation where
somebody originally suggested I use MS-DTYP as the normative reference,
instead of trying to redefine it myself, as that might provide some
guidance.

In the meantime I've created an open issue, because it's something that
definitely needs to be resolved.

Cheers

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 13 Jan 2015 10:24:54 +1000

> instead of trying to redefine it myself, as that might provide some
Ah, it was an early review from Dave Thaler.

Dave, do you have any advice here?

Cheers

---

From: Larry Masinter <[email-masked]>
Date: Tue, 13 Jan 2015 05:34:32 +0000

I'm still not sure  what the problem is with IPR-encumbered normative references. That said, I'd prefer a list (IANA registry?) of OS+filesystems and OS+filesystem-specific "file:" mappings, which could be vendor-supplied or Informational, rather than standards track. 

Even things like case-sensitivity in file systems is likely to change the mapping.

Larry
--
http://larry.masinter.net

> -----Original Message-----
> From: apps-discuss [mailto:[email-masked]] On Behalf
> Of Scott Kitterman
> Sent: Monday, January 12, 2015 12:12 PM
> To: [email-masked]
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-
> 00.txt
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 13 Jan 2015 16:33:43 +0900

> -MSK, slightly more sheepish APPSAWG co-chair

In the East Asian zodiac, this year is the year of the sheep, so you are 
in good and timely company :-).

Regards,   Martin.

---

From: t.petch <[email-masked]>
Date: Tue, 13 Jan 2015 13:35:27 +0000

Scott

Some WG, prior to adopting an I-D and prior to Last Calling an I-D, do
an explicit IPR call to the authors requiring them to disclose any IPR
that they are aware of, and inviting others to do the same.

I think it a good idea, but realise it is more admin for the powers that
be.  But then it can prevent the IPR emerging after an IETF Last Call
which is even more work for the powers that be.

I have on occasions raised a third party IPR disclosure at such a time
leading to a 'Whoops, sorry we missed that' from a well-regarded vendor.

I am also a fan of removing from an IETF Standard techniques that are
IPR encumbered unless we have RAND terms and the techniques are
essential.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Tue, 13 Jan 2015 13:37:36 +0000

Minor tweak
'its status' is mildly ambiguous
suggest 'the status of RFC 1738'

Tom Petch

----- Original Message -----
From: "Matthew Kerwin" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Murray S. Kucherawy" <[email-masked]>; "IETF Apps Discuss"
<[email-masked]>
Sent: Tuesday, January 13, 2015 12:01 AM

| The "file" URI scheme is woefully out of date. The document that
defines
| it, RFC 1738, has been superseded by the generic URI syntax of RFC
3986,

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 14 Jan 2015 09:11:28 +1000

> suggest 'the status of RFC 1738'
That makes sense. I've changed it in my version on github [1].

Thanks​

[1]: <
https://github.com/phluid61/internet-drafts/blob/master/file-scheme/mini-charter.md

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 13 Jan 2015 18:28:59 -0500

>From my point of view, a standard I can't implement is useless. Since these are normative, not informative, they are presumably required to implement file: in a cross-platform manner. 

What are the license terms associated I can use for code derived from those references?  At this point, it's completely unknown. For something as basic as file:, I don't think it's acceptable. 

Scott K

On January 13, 2015 12:34:32 AM EST, Larry Masinter <[email-masked]> wrote:
>I'm still not sure  what the problem is with IPR-encumbered normative
>references. That said, I'd prefer a list (IANA registry?) of
>OS+filesystems and OS+filesystem-specific "file:" mappings, which could
>be vendor-supplied or Informational, rather than standards track. 
>
>> > > > consensus on adopting your I-D into declaring consensus.  I am
>not
>> sure
>> > > > what has happened, I see no statement of adoption in my Inbox
>or
>> in the
>> > > > IETF archives but no matter, as long as the powers that be
>agree
>> on
>> > > > adoption, that is fine.
>> > >
>> > > The fact that draft-ietf-appsawg-file-scheme-00 got submitted
>with
>> a
>> is still present in the update.  We really, really ought to have
>something
>> as

---

From: Graham Klyne <[email-masked]>
Date: Wed, 14 Jan 2015 22:36:36 +0000

> | * Sean Leonard <[email-masked]>

I think there are two useful facets for the putative revised file URI spec:

1.  A normative syntax specification that defines a subset of RFC 3986 URI 
syntax that will be considered valid file: URI strings, and sufficient to cover 
common file: URI usage in the wild where it does not conflict with RFC3986.  I 
think we need to be very careful about extending the scope of any normative 
specification beyond this.

2. An informative aspect that describes some common file: URI usages and how 
they map onto underlying file systems.  This may reference proprietary 
documents, but since such material would be informative they wouldn't be 
normative references.

BTW, I'll review, but I can't promise to be always timely.

#g

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 15 Jan 2015 08:59:15 +1000

On 15 January 2015 at 08:36, Graham Klyne <[email-masked]> wrote:

> syntax that will be considered valid file: URI strings, and sufficient to
> cover common file: URI usage in the wild where it does not conflict with
> RFC3986.  I think we need to be very careful about extending the scope of
> any normative specification beyond this.
>
> 2. An informative aspect that describes some common file: URI usages and
> how they map onto underlying file systems.  This may reference proprietary
I think it's good to add specific deliverables like this. I'm pretty sure
the current text at <
https://github.com/phluid61/internet-drafts/blob/master/file-scheme/mini-charter.md>
captures everything we want to say, and doesn't leave anything too vague.
Not too long?

> ​
> ​

​
> ​
I'm pretty sure lots of people are in the same boat. As long as all
discussion happens here on the list, I don't doubt there'll be more than
three people with opinions on most aspects of the text.

Cheers

---

From: t.petch <[email-masked]>
Date: Sat, 17 Jan 2015 17:34:08 +0000

Matthew

Assuming that the minicharter requires us to conform to RFC3986, then I
think that s.2 has to be changed to remove the vertical bar (&#179; ?).

RFC6874 has the same issue and the idea of updating RFC3986 to change
the reserved and unreserved character sets was roundly rejected by the
IETF, although the character in question was in widespread use by some
browsers, in contravention of RFC3986.

I think you will have to follow the same pattern, that the formal syntax
for file: must conform to RFC3986 but an explanatory note can say that
there is this non-conforming variant in use (but SHOULD NOT be).

RFC6874 also picks up on the difference between a URI and a browser box,
that the latter can contain anything, such as
c|    \\host.example.com
which can be rendered into a conformant URI.  I think that this I-D
should also cover this.

Tom Petch

---

From: Matthew Kerwin <[email-masked]>
Date: Sun, 18 Jan 2015 07:46:03 +1000

> think that s.2 has to be changed to remove the vertical bar (&#179; ?).

Yeah, that discussion has been had on the list, and was one on the
motivators for suggesting separate non-normative appendices for
non-conforming but oft-seen variations.

I'm not sure we can entirely punt it to "human-facing", though, since
historically actual machine-land URLs have included the bar character.
I think it will be enough to say that they exist(ed?), and if one were
to be updated to the current spec it could be translated *thus*.

I am working on making this change.