Difference between revisions of "URI/File scheme/Plan of action"

From Offset
Jump to navigationJump to search
(List of implementations to Survey: Added some answers plus new browsers)
(Survey implementations of file: URIs: +Approach)
Line 1: Line 1:
 
This is the plan of action for updating the 'file' URI scheme. It is part of the W3C URI Interest Group's [[URI/File scheme|'file' URI scheme update project]].
 
This is the plan of action for updating the 'file' URI scheme. It is part of the W3C URI Interest Group's [[URI/File scheme|'file' URI scheme update project]].
 +
 +
== Approach ==
 +
 +
There is disagreement over how prescriptive the specification should be, but the general approach taken by the IETF in the past has always leaned toward ''document what works'' moreso than trying to ''fix what's broken.'' The chapter "[http://www.faqs.org/docs/artu/ietf_process.html IETF and the RFC Standards Process]", from ''The Art of Unix Programming'' by Eric Steven Raymond, emphasizes that Internet RFCs and standards tend to be based more on actual implementation than pie-in-the-sky theory.
 +
 +
Therefore, we are starting with a survey of implementations.
  
 
== Survey implementations of file: URIs ==
 
== Survey implementations of file: URIs ==

Revision as of 12:36, 18 August 2005

This is the plan of action for updating the 'file' URI scheme. It is part of the W3C URI Interest Group's 'file' URI scheme update project.

Approach

There is disagreement over how prescriptive the specification should be, but the general approach taken by the IETF in the past has always leaned toward document what works moreso than trying to fix what's broken. The chapter "IETF and the RFC Standards Process", from The Art of Unix Programming by Eric Steven Raymond, emphasizes that Internet RFCs and standards tend to be based more on actual implementation than pie-in-the-sky theory.

Therefore, we are starting with a survey of implementations.

Survey implementations of file: URIs

What do they implement? How do they map file: URIs to various operating system special situations, including handling of character set transformations, inclusion of drive letters, remote mount directories, individual mount points, symbolic links or redirections?

What is useful common practice for getting interoperable results when creating file: URIs?

Recommend useful practice based on implementations

Based on the survey of implementations, recommend action:

  • What should URI creators write for file: URIs to be interoperable with most current implementations
  • What should (new or updated) file: URI interpreters do to handle the diversity of file URIs likely to be seen
  • Update the Proposed Standard for file: URIs to be consistent with common current practice, such that progression to Draft Standard (multiple, independent, interoperable implementations) is likely.

Lmm 09:35, 21 Jun 2005 (MDT)


List of implementations to Survey

(originally proposed by Robert Herriot, updated by Lmm):

Here is a list of browsers that we should cover:

  • Firefox: Windows 2000/XP (maybe Windows 98), Mac OS X, Linux
    • Version 1.0.6 on Windows XP:
      • empty authority: local file system
      • "localhost" authority: local file system
      • authority is a drive letter: rewritten so authority is empty and drive letter is part of path
      • other: URL is ignored completely
  • Netscape: same as above
  • Mozilla: same as above (there is a new version, even though I thought that Firefox was supposed to replace Mozilla)
  • Opera: same as above
  • Lynx: character mode browser, same as above
    • Version 2.8.5rel.2 on Cygwin on Windows XP:
      • drive letters not understood on Cygwin, but /cygdrive/c is
      • note anomaly: if no trailing slash after authority, path is treated as "." rather than "/"
      • empty authority: local file system
      • "localhost" authority: local file system
      • other: file URI is treated as ftp URI
  • Links: character mode browser, same as above
    • Version 0.99pre14 on Cygwin on Windows XP:
      • drive letters not understood on Cygwin, but /cygdrive/c is
      • empty authority: local file system
      • other: error
  • W3m: character mode browser, same as above
    • Version 0.5.1 on Cygwin on Windows XP:
      • drive letters not understood on Cygwin, but /cygdrive/c is
      • empty authority: local file system
      • "localhost" authority: local file system
      • other: error
  • Internet Explorer: same Windows OSs as above; Internet Explorer on Macintosh. (No Linux)
    • Version 6.0 on Windows XP:
      • empty authority: local file system
      • "localhost" authority: error
      • authority is a drive letter: rewritten so authority is empty and drive letter is part of path
      • other: file://authority/path is rewritten as UNC name \\authority\path
  • Safari: Mac OS X
  • Konqueror: Linux (KDE)
  • Galeon: Linux (Gnome)

The list above covers the major browsers and a few minor ones. We should focus on the latest of each; perhaps some older versions with a large installed base should be included.

Among various questions to survey, in addition to drive letters, remote mounts, add "file" access to local files with a) no hostname, b) "localhost", c) the actual host name. Does "file" accesses remote hosts either via their name or IP address when not remotely mounted? My experience with this last question is that it fails with the browsers that I have tried.

In addition, check for variation with different character encodings (especially for Asian languages).