RE: Can someone answer my questions , please

Thank you.
I think I understand it better after your explanation.

When writing a file: URL I should satisfy the specific parts of file: URI 
written in RFC 1738, and also the generic syntax across multiple schemes 
from RFC 2396 where it is not in contradiction with RFC 1738 file: URI.

Right ?

What about RFC 1808 ? I believe the same approach should be taken.

Thanks Israel
-----Original Message-----  From:   Al Gilman 
[SMTP:asgilman@iamdigex.net]  Sent:   Saturday, March 08, 2003 3:05 
PM  To:     Israel Viente; uri@w3.org  Subject:        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'>file:/e:/xxx.pdf', the answer 
is no, not according to >RFC 1738, you must write 
'<<file:///e:/xxx.pdf'>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>ftp://ftp.ietf.org/rfc/rfc2396.<ft 
p://ftp.ietf.org/rfc/rfc2396.txt>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'>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'>file:/e:/xxx.pdf' is 
legal.  >See 
also ><<http://lists.w3.org/Archives/Public/uri/2003Feb/0035.html>http://lis 
ts.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.pdf>file: 
///e%3a/xxx.<<file:/ > 
//e%3a/xxx.pdf><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.pdf>file:/./foo.<<file:/. 
/foo.pdf>file: > /./foo.pdf>pdf" > 
or >"<<<file:///./foo.pdf>file:///./foo.pdf>file:///./foo.pdf>file:///./foo. 
<<file:///./foo.p > df><file:///./foo.pdf>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 Thursday, 13 March 2003 10:25:32 UTC