W3C home > Mailing lists > Public > uri@w3.org > March 2003

RE: Can someone answer my questions , please

From: Al Gilman <asgilman@iamdigex.net>
Date: Sat, 08 Mar 2003 08:04:46 -0500
Message-Id: <>
To: Israel Viente <Israel_Viente@il.vio.com>, uri@w3.org

At 04:07 AM 2003-03-06, Israel Viente wrote:

>Thank you for clarifying issues 2 & 3.
>About issue 1.
>In RFC 1738's definition of "file:" URIs, there _must_ be a host field, 
>although the host can be omitted.
>So, if you're asking is it 'legal' to write 
>'<file:/e:/xxx.pdf'>file:/e:/xxx.pdf', the answer is no, not according to 
>RFC 1738, you must write '<file:///e:/xxx.pdf'>file:///e:/xxx.pdf' which 
>is valid.
> From RFC 2396 I understood it replaces RFC 1738.

This is a misunderstanding.  By its own terms, it does not.


    This document defines a grammar that is a superset of all valid URI,
    such that an implementation can parse the common components of a URI
    reference without knowing the scheme-specific requirements of every
    possible identifier type.  This document does not define a generative
    grammar for URI; that task will be performed by the individual
    specifications of each URI scheme.


>This document defines the generic syntax of URI, including both absolute 
>and relative forms, and guidelines for their use; it revises and replaces 
>the generic definitions in RFC 1738 and RFC 1808.

First and foremost, you have not answered my question.  So far you have not 
any resource you need to designate with a file: URL that you can't do with 
an URL which
conforms to both of these RFCs.

But even at the juridical level that you have adopted, RFC2396 restates a 
new generic
syntax across multiple schemes, but it does not force schemes to accept any 
string that
matches the generic syntax.  Schemes can specialize the generic syntax and 
file: does.

You still need the hostpart.

The generic syntax fits any legal file: URL but not anything generated from
the generic syntax is a legal file: URL.


> >>>
>And in RFC 2396 '<file:/e:/xxx.pdf'>file:/e:/xxx.pdf' seems to be legal as 
>an absolute URI.
>absoluteURI = scheme ":" ( hier_part | opaque_part )
>hier_part = ( net_path | abs_path ) [ "?" query ]
>net_path = "//" authority [ abs_path ]
>abs_path = "/" path_segments >>> ---> so 
>'<file:/e:/xxx.pdf'>file:/e:/xxx.pdf' is legal.
>See also 
>for reference.
>Thanks Israel
>-----Original Message----- From:  Al Gilman [SMTP:asgilman@iamdigex.net] 
>Sent:  Wednesday, March 05, 2003 10:42 PM To:    Israel Viente; uri@w3.org 
>Subject:       Re: Can someone answer my questions , please
>At 02:03 PM 2003-03-05, Israel Viente wrote:
> >Hi, >1) Which RFC should I follow in case of file URIs 2396 or 1738 ?
>Why can't you satisfy both?  What do you *need* to do where they are in 
> >2) About the escaping of ':' separator of the drive letter. >I 
> understood there is no need to escape the ":". But 
> is >"<<file:///e%3a/xxx.pdf>file:///e%3a/xxx.pdf>file:///e%3a/xxx.<<file:/ 
> //e%3a/xxx.pdf>file:///e%3a/xxx.pdf>pdf" also valid ?
>It is a valid URI.  As a URI it is synonymous with the URI containing the 
>unescaped ':' character.  Whether all file: scheme processors will process 
>this correctly is something I don't know.
>A file system that expects a drive letter at the head of a file path and 
>fails to treat e%3a as synonymous with e: where it appears in the 
>appropriate path segment for a drive letter to appear in a file: URL is 
>strange indeed.
>Of course, stranger things have happened.
> >3) Relative file URIs : Is it equivalent to use "./foo.pdf" 
> or >"<<file:/./foo.pdf>file:/./foo.pdf>file:/./foo.<<file:/./foo.pdf>file: 
> /./foo.pdf>pdf" 
> or >"<<file:///./foo.pdf>file:///./foo.pdf>file:///./foo.<<file:///./foo.p 
> df>file:///./foo.pdf>pdf" ?
> >Are the last 2 examples which uses scheme name and relative form , 
> invalid >URIs ?
> >Thanks in advance >Israel
Received on Monday, 10 March 2003 14:41:02 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:42 UTC