Re: file: URI scheme

Hi file-uri list and uri members.

I Suggest a very minor spelling fix to draft ieft version of file-uri-01:
>ftp://ftp.ietf.org/internet-drafts/draft-hoffman-file-uri-01.txt
>under "2.  Scheme Definition"; Starting with Amaya at line Number + 74; 
Char + 48;
I suggest that the following
>"syntaxt" should be "syntax", and "docoument" should be "document"
Reason for this change is a minor typo correction/s.  (I did not test 
whole document)

Feel free to post back :-) I am ready for a good Roast if needed.
This will be my last post of comment at w3 uri list until file-uri-02 
is online and ready for some comments.

Many thanks again for allowing my comments, and previous whinges.
Kindest regards,
Jason
JRobinson@KitchenPages.com

:-)


I have done some work on my comments found in '*' and '**' symbols 
respectively, below as comments only.

I have No really good arguments at this time to support most of my 
comments made to-date but I did manage to stay in scope this time :(

No real changes requested at this time for the following:

---------------------------------------------
comments'
---------------------------------------------

./draft-hoffman-file-uri-01.txt

2.  Scheme Definition

   The file URL scheme is used to designate files accessible on a
   particular host computer.  This scheme, unlike most other URL
   schemes, does not designate a resource that is universally accessible
   over the Internet.

*I am just a little un-easy about the 'universally' bit considering the
statement below and the FQDN terms stated later in this document.
I would assume that if two computers using different protocols would
have this kind of problem - I take note of the line in regards to
the current document providing a historical setting of a common use?**

   The file URL scheme has historically had little or no
   interoperability between platforms.  Further, implementers on a
   single platform have often disagreed on the syntaxt to use for a
   particular filesystem.  This docoument does not try to resolve those
   problems, only to show what has been commonly seen in use on the
   Internet.

*URL? vs URI? above and below with no actual reason as to the
difference - like url is separate from uri/iri, etc.
Again while its kind of confusing I do note the referenced to
newer URI/IRI schemes**

*I kind of dislike the use of syntax because it relates to part of 
grammar in
treating of arrangement of words in a sentence (meaning of n); however I 
think the document refers to how the symbols are evaluated before getting 
to the stage of searching for a path or words - see nfile for an example 
of
arrangement of words as a path as the syntax differs for each system.
Either way syntax is an ok word to use but at the same time I can
also understand what is being explained - its just not current with
other systems like a cbm64 syntax error messages - but then again
the amount of users on cbm's is somewhat limited**

   A file URL takes the form:

   file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

*I think the <path> should be more over related to 'local service' 
as in if DNS is accessible and the 'local' system is then resolved 
to a FQDN; only then is the <path> is accessible as a FQDN URI with
permissions (share/user/both) or other security settings and even 
symbolic links on linux/unix**

   As a special case, <host> can be the string "localhost" or the empty
   string; this is interpreted as "the machine from which the URL is
   being interpreted".  However, this part of the syntax has been
   ignored on many systems.  That is, for some systems, the following
   are considered equal, while on others they are not:

      file://localhost/path/to/file.txt
      file:///path/to/file.txt

   Some systems allow URLs to point to directories.  In this case, there
   is usually (but not always) a terminating "/" character, such as in:

   file://usr/local/bin/


*file is for file as defined in this document.  I do not see how this can
make a jump to explain how a linux path is known as a file as any such
uri like the above in my view should be treated as a directory booting
up another interface to handle the requests (IE swaps to explorer mode).

Someone may of changed this but I was sort of told that unix file systems
are numbered alot better then windows attempts too; using numbers and 
then
assign human reference.  The only real down side is that
a path can be used as a file - but that is then rejected by the interface
if a user should attempt to load a directory as a file.

I guess that the above seems a bit mixed between win and lin; while in
other RFC like nfile the terminating "/" character is required in many 
cases.
(nfile and http are two examples of terminating "\") My Apache server 
hangs 
without a terminating "/" on a path http uri for windows9x users; 
and I presume its because of this kind of confusion.  
without a terminating "/" a linux system should only look inside its last 
"/" terminator for a file with the name of 'bin'**

   On systems running some versions of Microsoft Windows, the local
   drive specification is sometimes preceded by a "/" character.  Thus,
   for a file called "example.ini" in the "windows" directory on the
   "c:" drive, the URL might be:

   file:///c:/windows/example.ini

*not sure if this is in relation to MSDos as cd\ or even cd.
It gives me the impression that the third or fourth '/' 
will be translated into a preceding '\' symbol for windows 
users like '\c:\windows\example.ini' when used without services
like share/user(domain).  The '\c:' is supported by MSDos5. 

However - my examples are out of scope and I do not have another
at this time; I also think that the more current post by 
Gisle Aas seems to have the same problem but is a much 
better example**

*The draft document makes no statement in relation why 
'file:///c/config.sys' does NOT equate to 
'file:///c:/config.sys' or 'file:///c|/config.sys' for
windows9x ie5.5 clients - as in example above.

Perhaps adding more URI/URL examples or a table to the
draft could solve this issue without it becoming one; even
if its a history list - its just a something to work from**

*is it possible to have a major or minor implementations
defined along with such examples?  A major would support
all implementations and attempt to resolve resource on
request by some kind of 'voodoo' magic URI-FILE**

Received on Sunday, 10 October 2004 15:15:07 UTC