- From: Kitchen Pages <jrobinson@kitchenpages.com>
- Date: Sat, 23 Oct 2004 13:19:18 GMT
- To: uri@w3.org
- CC: mike@skew.org
Hi again. No reply is required but if needed one is welcomed; these are two more file comments (I am at the bottom of the barrel now for these comments). I have dug through the links sent and I see a great deal of my other issues have been discovered in 2003 along with others in 2002. My many thanks again for posting the links. On another note: i) I noticed that current draft also refers to "file-URI"; which should be "file URI" – but this is IMHO to keep with the 'new draft' standard posted up to the URI list recently. ii)I would also like the following (or something along these lines) added to file URI: 3.3 Use of hostname and host name The file URI specification calls for using the actual host name as the name authority and allowing it to be omitted for a resource found on the client requestor. Some applications can and do generate file-URIs with no authority component at all, such as "file:/this/is/the/path". As above these applications do not use DNS, NetBIOS, or NetBEUI by default and have no need for an name authority or host as they do not require the protocol stack for navigation of such; in many cases they do not require any protocol stack as this file uri is defined for local operations. This kind of file-URI as above has a Permanent URI Scheme Name Status. The same can be said in regards to FQDN because a DNS is required and some applications and implementations like the current Microsoft DLLs do not allow the file URI to invade DNS for resolutions as NetBIOS/NetBEIU for host authorities are defined on local and sometimes server machine boot/update/s. The host refered to in these cases is within the windows domain of the requestor/resolver; the result is something like the following example: 2 machines in different domains with the same host names. 1 machine in a single windows domain calls for a host. The result will be a host known within the callers domain, not out side. The commands of a host are UNC and not FQDN. It should be noted that file URI has no socket component on windows. This kind of file URI as above has a Provisional URI Scheme Name Status. The file URI may and can be changed at anytime without notice. ------==rabbit comments==-------- (I removed the checking part, and reduced Microsoft to a 'radical' unknown so an update could proceed without a MCP reply too request of info – I would think that Microsoft would revoke a persons MCP status because – as I was told – they do not allow or like information given out because it would lower the qualification of all MCPs; also I can not imagen a MCP that would want to aid and abet the cause for cross-platform use by linux, etc – another simba?) Don't get me wrong – I love windows; just not some of the stuff done with it by its owner. Perhaps an open letter to Microsoft by the URI list owners is in order? ----------------- The line of "The commands of a host are UNC and not FQDN" above simply states that file://fqdn/HOST/resource/path/file and f ile://HOST.fqdn/resource/path/file a re not supported. I avoided a bit about case in host names for UNC windows uses (a host 'should be' upper-case; but can be any case). ----------------- I have attempted to create a file URI document for my own uses (http://kitchenpages.com/help/i3/i-uri-file-draft-hoffman-file-uri-kp.txt that is based around a test page at http://kitchenpages.com/help/i3/draft-kp-file-uri[0]-testpage.htm); my document and test are both flawed but I thought I would post the links for lol... ----------------- REF: mid:E1CGyoU-0001bA-IE@frink.w3.org My many thanks again and kindest regards, Jason JRobinson@KitchenPages.com :-)
Received on Friday, 22 October 2004 20:16:33 UTC