Re: file:yyy and file:ddd/yyy

Jeremy Carroll wrote:
> Summary:
> ========
> 
> What is the correct reading of file:yyy and file:ddd/yyy?
> 
> Is it that these are relative URIs to be interpreted against the current 
> working directory (as an absolute file: URI) of an application using 
> them. Or is it better to treat them as absolute URIs?

Without making a subjective assessment of what treatment is "better", STD 66 /
RFC 3986 says they are, by their syntax, absolute URIs. Via different, but
roughly compatible grammars, RFCs 2396 and 1808 said the same thing. So to
answer your question about what is "correct", since June 1995 it has only been
correct to read and process them as absolute.

As you're probably aware, your examples are not conformant with the one and
only syntactic description of the 'file' URI scheme (RFC 1738 sec. 3.10, from
December 1994), which says that a 'file' URI must begin with 'file://'
followed by an optional host and then a third '/'.

So asking for advice on how "file:yyy" should be interpreted is a bit like
asking how "mailto:uri+at+w3.org" should be interpreted. The author of such a
URI should know that by definition, they have produced an absolute URI, thus
they should not expect for it to be treated as anything different -- the
scheme being 'file' has no bearing on it.

They should also know that it is invalid as a 'file' URI, so any software
consuming it might reject it outright, if that software chooses to validate it
and be strict about what it accepts. The URI RFCs aren't likely to prescribe
any specific behavior for an implementation, though; we're really only
concerned about how to produce, recognize, and process (to the most
unrestrictive degree) a *valid* URI.

> Treating them as errors would seem to go against too much deployed practice.

Depends on how you define "treating them as errors". They aren't valid
according to RFC 1738, but nowhere does it say that a URI consuming
application must validate them, let alone reject invalid ones.

It's fairly well known that 'file' has been one of the most poorly spec'd,
most variably-implemented schemes. Had the preponderance of lenient
implementations been taken as a sign of a need for the generic syntax to
define 'file:yyy' as being equivalent to 'yyy' during the development of STD
66, going all the way back to RFC 1808, then it would've been addressed before
the current interpretation had been made an Internet Standard. So, going 
forward, I would say you should just follow STD 66/RFC 3986 to the letter.

When we get around to writing a more thorough and useful description of the
'file' scheme, we *might* survey some implementations and make mention of how
'file' URIs that are compliant with the generic syntax, but that are otherwise
malformed, have typically been (mis)handled. But we're obligated to avoid
prescribing, even implicitly, any interpretations that would conflict with STD
66.

Received on Monday, 6 February 2006 03:34:39 UTC