Re: URI vs Relative URI

Re: URI vs Relative URI - I would have to state that the draft is clear 
in regards to "URI vs RELATIVE URI".
 
My reason / example is : On windows if one is to rename a drive to a four 
letter name like "http" then the
relative URI could not apply in an external lookup unless the application 
interface (like a web browser) knew how to handle it.  (if someone would 
like to find out it would be wonderful but I would suspect the 
application interface would do a external lookup and not seek a drive 
named http mainly because of its pre-programmed methods in resolving such 
a request using the protocol stack)
 
Entering http:.. into explorer shows that interfaces can do this as a 
form of voodoo magic, and the same with IniFiles.hpp as I 
suspect Inifiles.hpp adds a IP address or netbios path depending on 
condition (found or not).
 
When it comes into external lookup's the draft is correct in my view as 
two or more parts are required - AUTHORITY://URI (with URL being apart of 
URI in this case) to be entered into the application interface by many 
methods.
The interface then handles the request as it is passed through the 
protocol stacks for that application interface until a suitable or first 
found Authority is located and the resource is rendered in some manner.
 
So to conclude my limited view - a renamed drive of http can not be 
resolved on many an application interface without first the application 
interface/s being programmed to handle such a request for a local 
resource or external resource of any kind - but a more lax system would 
in many cases show the local defined term(if any - a drive in this case 
would be returned as the network protocol is almost last).
 
Some other examples have been posted which include defined terms by an 
application interface like that of  Star Office for example by Sun (
file://c|path/name.ext).  
Another is a recent example of netbios domain name systems without a 
trail '.' would be seeking a relative URI on a local machine, then 
network broadcast if any, and finally external with a trail '.' to avoid 
the hosted domain and then go external (if the domain allows it)which is 
defined by the Domain the local machine happens to be in.  The same can 
be applied in reverse for a external user looking up a resource on a 
local network/machine.
 
The problem in my view comes from the protocol stacks used to define such 
terms used by application interface/s as these ideals are almost always 
left to the last thing of seeking the resource from anything due to the 
nature of changing resources, protocol stacks, application interfaces, 
and the Internet. 
In English a application interface should be made to lookup local things 
before going external (unless programmed otherwise like the voodoo magic 
above – or proxies, etc) and in that case the draft is correct in the way 
that I am reading it.
 
However - there are more then likely better ways to explain this then I 
do here and I do not think the URI draft is the place for such.  But a 
reference of  some kind or another would be handy just to note that other 
methods like news, etc may be used before reaching the 'required' 
protocol authority depending on the application interface/s used.

Received on Saturday, 28 August 2004 01:28:20 UTC