Re: more 'file' suggestions for draft-hoffman-file-uri

>Paul Hoffman / VPNC wrote:
>> This seems like overkill for a scheme that has gone under-defined for
>> a decade. I see no reason to try to reinterpret the scheme now

>The amount of time it has been under-defined is irrelevant. If, *today*,
>all in agreement that it is inadequately defined, and if, today, we're
all in
>agreement that it's unfortunate that this has led to a morass of
>ad-hoc interpretations that hinder interoperability, then what more
reason do
>you want to knock it into better shape? How can you even call this a
>"standard" if it is so vaguely specified, that it doesn't standardize
>anything? About the only thing that file URIs have in common today is
>they all start with "file:".

>If you intend to leave it underdefined, then I feel there should be a
>statement to that effect in the standard, and you shouldn't be asking
>further comment aside from those that are strictly nonsubstantive, such
>pointing out the typos and grammatical errors.


Paul is very correct but at the same time I have to agree with what Mike
is saying in this post. Currently for windows C++ the File protocol seems
to no longer exist – with the invent of wininet.h yet the scheme does ?!?

So for everything like IE5 (socks) the File protocol is underneath the
application layer, and can be accessed from the application layer 
using the prefix of file://

But with wininet.h I can only then presume that File is gathered by one
of the following methods: (method for file is not stated – port 0 ?)
stdio.h, Http, Gopher.

And then the URI may be altered by a client phrase for encoding,
decoding, etc. ?
However, considering the rest of 'windows' is written to the RFC it makes
no sense to not have the file protocol correctly defined as an RFC which
includes all various 'components' of the protocol which is not dependant
on a client implementation.  And before File is written into the abiss.

So going back to the issue of not knowing which method is used; I have
to presume that percent encoding would not be performed; the default port
of 0 would be used according to my readings; etc... Kind of makes it hard
to get a FQDN using File and wininet in my view of things.

So the quickest method would be in using FILE and a FQDN
without setting up a DNS server would be that windows is really
using the HTTP method on port 80 for file reading into a buffer.

I am not a windows dev by any means :–(  so I am more then likely
wrong about my assuming of the quickest method.

But I think the main Internet libraries are wininet.*; socks*.*; dot
net.. for most windows implementations of RFC file protocol where 
I can not see any real implementation of the file protocol.

I have to agree with the ideal of a statement too the affect that
the File protocol is implemented to suit just that the client operating
system or that of the entire File protocol RFC.  A minor and major 
version with most implementations using the minor standard unless 
otherwise stated?

The other choice faced is one like the following; just for dot net there
are things like:
(A Dot Net Framework test example for finding the platform-specific bad
path characters).  I could also bet the same exists for other frameworks.

I still think a table stating such would of been a better choice of
example (as if I am going to spend time running around on various 
systems, etc) – but I am extremely old school in this way.
Example:  I will learn the answer when I know the question :)

I also think two users that are not using the same implementation
should be able to access the same resources using the same URI.
(all things being equal, etc)

I would also consider such a tabled 'answer' to be in line with the RFC

I would not mind a file extension conversion table but I will stop short
of asking for one :)

Apart from Mac's there is none – a small joke for the Mac users.

So I must commend Mike and the other list members for work in
standardizing the
file standard as its well long over due :-)
Also I find the emails very informative.

I have skimmed through current list emails – but had to reply here 
(4 days old).

Kindest regards,
Jason Robinson

Received on Thursday, 23 September 2004 17:01:02 UTC