RE: Can someone answer my questions , please

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.
>
>BUT
> From RFC 2396 I understood it replaces RFC 1738.

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

<quote
cite="ftp://ftp.ietf.org/rfc/rfc2396.txt">

    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.

</quote>

><<<
>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 
demonstrated
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.

Al


> >>>
>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 
><http://lists.w3.org/Archives/Public/uri/2003Feb/0035.html>http://lists.w3.org/Archives/Public/uri/2003Feb/0035.html 
>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 
>conflict?
>
> >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" ?
>
>No.
>
> >Are the last 2 examples which uses scheme name and relative form , 
> invalid >URIs ?
>
>Yes.
>
> >Thanks in advance >Israel

Received on Monday, 10 March 2003 14:41:02 UTC