file:/ vs file://<host>/ vs file:///

[Daniel Veillard]

On Fri, Nov 05, 2004 at 02:39:35AM +1100, Glenn McGrath wrote:
> On Thu, 4 Nov 2004 10:02:16 -0500
> Daniel Veillard <veillard at redhat.com> wrote:
> 
> > On Thu, Nov 04, 2004 at 11:45:36PM +1100, Glenn McGrath wrote:
> > > The file-uri-spec says that "file:/<path>" shouldnt be used as it
> > > isnt correct according to RFC1738.
> > > 
> > > The file-uri-spec says we should use file://localhost/<path> or
> > > file:///<path>
> > > 
> > > RFC2396 says the format of a URI is
> > > 
> > > absoluteURI = scheme ":" ( hier_part | opaque_part )
> > > hier_part = ( net_path | abs_path ) [ "?" query ]
> > > net_path = "//" authority [ abs_path ]
> > > abs_path = "/"  path_segments
> > > 
> > > Clearly file:/<path> is compatable with RFC2396
> > > 
> > > The "//" seperator is meant to represent a network location. I think
> > > its very unlikely that the file scheme would be used with a remote
> > > host, so it doenst make much sense. Using "localhost" or not
> > > specifying a host as a way of trying to negating the meaning of "//"
> > > is confusing and not necessary.
> > > 
> > > As "//localhost" is a net_path redirected to the the local machine,
> > > why not just use "/", the abs_path, it seems it was designed for
> > > this purpose.
> > 
> >   no. RFC2396 does not override RFC1738 on the matter of defining the
> > protocol schemes.
> 
> RFC1738 says file://<host>/<path> is ok, this rfc doesnt mention
> abs_path at all, it only talks about net_path.
> 
> RFC2396 says file://<host>/<path> and file:/<path> are both ok.
> 
> I think it would be ok if file-uri-spec suggested that
> file://<host>/<path> only be used with a remote host, but as the
> protocol used to contact that host isnt specified in the url i dont see
> how it can ever be uses effictively.
> 
> Its wrong to ignore abs_path in a document that should be trying to
> clear up the issue.
> 
> >   that would be in direct conflict with the current state of the RFC
> >   at the
> > IETF (unless someone can point to an RFC overriding 1738 on the matter
> > of the "file" protocol description).
> 
> RFC1738 doesnt address abs_path, so its not correct to judge the
> validity of file:/ against it.
> 
> RFC 2396 addresses both net_path and abs_path so i think it should be
> seen as a more relevant document.
> 
> Common sense should prevail if the RFC's conflict.

  RFC 2396 was confusing. It is being clarified in RFC2396bis

   http://gbiv.com/protocols/uri/rev-2002/rfc2396bis.html#components

Either you have an authority or not. In any case you cannot have
   file://foo

  Now what semantic would you provide for
   file:/foo ?

It has none as defined by the RFC defining the file protocol right now.
If *you* decide to provide a semantic for it, you are stepping on the toes
of the people who may fix the zillion problem in the file protocol 
definition (when someone goes to do it !). In the mean time we should
not promote using a syntax which has no semantic applied.
To be 100% clear:
   if you use 
      file:/etc/hosts
         to mean the file in /etc/hosts on localhost
	    then it may just conflict with a future extension of file:
	    trying to handle relative reference to a notion of current
	    directory
         to mean the file in etc/hosts on localhost relative to the current
	 directory
	    then it may just conflict with a future extension of file:
	    stating it is a shortcut for file:///etc/hosts

  Until you can guess the future or point me to an RFC redefining the
file protocol then, we should *not* advocate any file URI without an
authority part. It is just basic sound principle when dealing with
standards. And assuming RFC2396 defines any semantic for what file:/foo
may mean, please point me to that section, in RFC2396 or the RFC2396bis !
So far there is none. Syntax without semantic is not appropriate for use
in our context, sorry.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/