Re: more 'file' suggestions for draft-hoffman-file-uri

OK, so to summarize, regarding this text...

  "This scheme, unlike most other URL schemes, does not designate a
   resource that is universally accessible over the Internet."

My suggestion was to delete it. Larry suggested rephrasing it to say that 
uniformity of identification, rather than uniformity of access/dereference, 
was the problem. I objected on the grounds that a URI darn well better 
Uniformly Identify something, so if file URIs don't meet that criteria then 
they need some serious fixing. Roy disagreed with Larry in that uniformity of 
identification is not the problem, rather just that users/implementers tend to 
misuse the scheme / assume too much about is being represented. He suggested
a possible rephrasing that better captures the spirit of the original text:

> I think the warning should be that "file" refers to filesystem names
> from the perspective of the user of a reference, rather than in relation
> to a globally-defined naming authority, so care should be taken
> to ensure that such references are actually intended to be in relation
> to the user's filesystem interface.

In another subthread of this discussion, I am suggesting that in the standard, 
those things that are being conceptually represented by the URI components and 
by the URI as a whole be made clear, and their relationships to the lexical 
syntax components be explicitly described separate from the syntax. I think 
that if those suggestions are acted upon, they will further reinforce the idea 
behind Roy's version. I hope that his statement can make it into the next
draft, even if my suggestions are deferred or tossed out.


I also suggested dropping the statement that a file URI's syntax be 
file://<host>/<path>, for what was at the time various unstated reasons,
but that I've hopefully expressed a little better in other messages, if
everyone isn't already hitting Delete at first sight of email from me.

Larry replied:
> > No, certainly not. I think we should preserve and encourage
> > uniformity of meaning for 'file:'. My only hesitation is whether
> > we should drop the pretense of 'host', since it is almost always
> > omitted.

I wasn't sure which pretense of 'host' was meant here, but Roy
seemed to understand, and criticized:

> That would break existing data and software where it isn't omitted.

Just as a general philosophy, I don't see what is wrong with invalidating a 
few implementations if there was no right or wrong way of implementing to 
begin with, especially when we're talking about making the invalidation be 
part of an update to a standard -- implementations of previous versions can't 
be expected to conform.  When confronted with certain relative reference 
resolution edge cases, some implementations may be "right" today in the sense 
that RFC 2396 doesn't say they are wrong, but they are going to be definitely 
be wrong when rfc2396bis is published as a standard. I'm not sure how the 
interpretation of the 'host' part of a file URI is any different in this 
regard, but maybe I am missing something.

Roy continued:
> I don't like that at all.  Just make the authority component optional
> and deprecate (but don't disallow) "//localhost".

I'd like to know: How much leeway does a scheme have in allowing or 
disallowing components from the generic syntax? If it can disallow certain 
components, then is a URI that has those components no longer governed by that 
scheme? Or is disallowing a component really just a way of leaving its 
interpretation undefined, leaving the rest of the URI to be interpreted 
according to the scheme? ... I would think such interpretations would be 
troublesome; shouldn't every scheme be subordinate to the generic syntax? I 
would think that means nothing in the generic syntax could be truly disallowed 
-- the most restrictive a scheme could be, I'd think, is to say that an 
extraneous component would just be said to be unused, if acknowledged by the 
scheme at all.

> The theory was that a smart filesystem interface with automounting
> could make use of a file URI with a hostname. I think that is also
> the basis of Win32 UNC names, but I can't remember if they actually
> work that way on MSIE or not.

The Address bar widget used by Windows Explorer, Internet Explorer, and other 
Microsoft products, as well as one of the standard Open File dialogs used in 
many Windows applications, does indeed resolve the host in a 
typed-or-pasted-in URL as a UNC host name, and in that situation treats the 
first path segment as a share name.

I am also pretty sure this is not the only mapping of UNC path <-> file URI 
that is supported by the underlying resolver; I think 
"file://///<host>/<share>/<path>" may be supported as well. I'm not in a good 
position to confirm at the moment though.

The widgets also do some cleanup on what you enter (slash direction and 
drivespec adjustments, maybe more), and may or may not update what you typed, 
so it is difficult to say, without looking at network traffic, exactly how 
file URIs are being interpreted, and at what level. If there are any 
developers familiar with the guts of MS Windows lurking on the list, their 
input into this process would be most appreciated, even if it just involves
pointing to some docs.

-Mike

Received on Thursday, 23 September 2004 06:06:30 UTC