W3C home > Mailing lists > Public > uri@w3.org > December 2013

Re: reviving the file URI scheme

From: Mike Brown <mike@skew.org>
Date: Thu, 12 Dec 2013 03:56:42 -0700 (MST)
Message-Id: <201312121056.rBCAugcm051911@chilled.skew.org>
To: Matthew Kerwin <matthew@kerwin.net.au>
CC: uri@w3.org
Matthew Kerwin wrote:
> Hi, some of you may have seen that about six months ago I somewhat naively
> created an ID to resurrect the 'file' URI scheme.  In the intervening
> months I've spent a bit of time lurking on IETF and W3C mailing lists
> familiarising myself with the standardisation process, and studying up on
> how people are using and supporting file URIs, and updating the ID.  The
> latest version, 09, was published yesterday: <
> http://tools.ietf.org/html/draft-kerwin-file-scheme-09>
> 
> What I would really like is your opinions as experts, whether you think
> it's a worthwhile effort, or if my approach is suitable, or any specific
> issues (technical or editorial) with the ID itself.

The last go-'round on this went nowhere, so I wish you luck. It's good to see
someone putting in some effort on this again.

Maybe you already saw it, but back in 2005-2006, I thought maybe a 
MediaWiki-based wiki would work better than the discussion list as a sort-of 
shared whiteboard, but it never took off:

  https://offset.skew.org/wiki/URI/File_scheme

I think Larry Masinter is the only one besides me who ever used it. I'm happy 
to keep the wiki going, though, and can set up accounts for whoever wants 
them. Or it can just stay up as a historical reference; no problem.

This really isn't much help, and it's pretty typical of me to be distracted by 
something so minor, but the first thing I'd change in your draft isn't 
technical, but rather just a pet peeve of the copy editor in me:

Unless you're writing a math tutorial, you should avoid repeatedly telling the 
reader to "note" things, or that things should be noted, or any other explicit 
ways of highlighting content or directing the reader's attention. I feel you 
can do it one time, but that's it...so make it a good one...and that's if 
you're OK with addressing or referring to the reader at all, rather than just 
stating facts and giving examples.

So, generally speaking, if something is too important for the reader to 
overlook, maybe it should be mentioned sooner, or prefaced with some 
background info that will indicate why it's important (without actually saying 
"this is important", of course).

Another copy edit to consider is deciding whether "filesystem" is a word, or 
if it's best written with as the more formal "file system", and be consistent 
about it.

As for the actual content, the question that comes to my mind when reading the 
introduction is "does this document fulfill its goals?" So, does it 
acknowledge specific interoperability issues and then demonstrate how they can 
be resolved? Does it acknowledge specific syntax disagreements on the major 
file systems and then provide a syntax that works for each of them? Does it 
define an interoperable scheme parseable in the same way as other URIs, and 
does it make it clear that this is a change from what we had before? The 
answers should be easy to find.

The intro also says "Because that document has been made obsolete, this 
document copies the 'file' URI scheme from it to allow that material to remain 
on standards track." That was Paul Hoffman's text, and reflected his approach 
of not actually changing anything at first. I think we kinda shot that down as 
not being a good use of a new RFC, so I think this paragraph should be updated 
to indicate that you're not just moving relatively useless material from RFC 
1738 into a new RFC; you're building on it and making it into something 
beneficial.

I think a concern that was raised before is that we need to acknowledge what 
implementations are doing in the real world right now, and not break what 
works. If the major 'file' URI consumers and producers all behave a certain 
way which doesn't quite comport with the new draft's principles, then saying 
that they have to all change in the interest of tidiness and conformance to a 
new spec might be an uphill battle.

It looks like maybe you're aware of this; you expressly avoid prescribing how 
to handle relative file paths. I'm just having trouble reconciling that with 
the stated goals from the introduction.

For example, if an RFC 3986-compliant URI processor encounters a relative URI 
reference with a base URI that includes a Windows drive letter as the first 
path segment, it's at risk of obliterating or overwriting the drive letter 
when it resolves the reference to absolute form. This is why the drive letter 
sometimes is shoved into the authority component. If it's not OK to produce a 
URI with a drivespec as authority (and it's discouraged by RFC 3986 sec. 3.2.3 
as well), then how does leaving it up to the implementation to decide how to 
handle it improve interoperability or compatibility with standard URI 
processing tools?

Same issue with UNC paths...I think people expect the hostname to be 'sticky'.

Maybe I'm overthinking it or just haven't spent enough time with it, though. I 
haven't actually touched this stuff in years, so take what I say with a huge 
grain of salt. On that note, I'll bow out of the discussion now, unless you 
have questions for me.

Mike
Received on Thursday, 12 December 2013 10:57:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:16 UTC