idnits 2.17.1 draft-hoffman-file-uri-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 218. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 30, 2004) is 7086 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 2396 (Obsoleted by RFC 3986) -- No information found for draft-fielding-uri-rfc2396bis-nn - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Hoffman 2 Internet-Draft VPN Consortium 3 Expires: May 31, 2005 November 30, 2004 5 The file URI Scheme 6 draft-hoffman-file-uri-02.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 31, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This document specifies the file Uniform Resource Identifier (URI) 42 scheme that was originally specified in RFC 1738. The purpose of 43 this document is to allow RFC 1738 to be moved to historic while 44 keeping the information about the scheme on standards track. 46 1. Introduction 48 URIs were previously defined in RFC 2396 [RFC2396], which was updated 49 by draft-fielding-uri-rfc2396bis [2396bis]. Those documents also 50 specify how to define schemes for URIs. 52 The first definition for many URI schemes appeared in RFC 1738 53 [RFC1738]. Because that document has been moved to Historic status, 54 this document copies the file URI scheme from it to allow that 55 material to remain on standards track. 57 2. Scheme Definition 59 The file URL scheme is used to designate files accessible on a 60 particular host computer. This scheme, unlike most other URL 61 schemes, does not designate a resource that is universally accessible 62 over the Internet. 64 The file URL scheme has historically had little or no 65 interoperability between platforms. Further, implementers on a 66 single platform have often disagreed on the syntaxt to use for a 67 particular filesystem. This docoument does not try to resolve those 68 problems, only to show what has been commonly seen in use on the 69 Internet. 71 A file URL takes the form: 73 file:/// 75 where is the fully qualified domain name of the system on 76 which the is accessible, and is a hierarchical 77 directory path of the form //.../. 79 As a special case, can be the string "localhost" or the empty 80 string; this is interpreted as "the machine from which the URL is 81 being interpreted". However, this part of the syntax has been 82 ignored on many systems. That is, for some systems, the following 83 are considered equal, while on others they are not: 85 file://localhost/path/to/file.txt 86 file:///path/to/file.txt 88 Some systems allow URLs to point to directories. In this case, there 89 is usually (but not always) a terminating "/" character, such as in: 91 file://usr/local/bin/ 93 On systems running some versions of Microsoft Windows, the local 94 drive specification is sometimes preceded by a "/" character. Thus, 95 for a file called "example.ini" in the "windows" directory on the 96 "c:" drive, the URL might be: 98 file:///c:/windows/example.ini 100 For Windows shares, there is an additional "/" prepended to the name. 101 Thus, the file "example.doc" on the shared directory "department" 102 would have the URL: 104 file:////department/example.doc 106 The file URL scheme is unusual in that it does not specify an 107 Internet protocol or access method for such files; as such, its 108 utility in network protocols between hosts is limited. 110 3. Implementation Notes 112 3.1 Hierarchical Structure 114 Most implementations of the file URI scheme do a reasonable job of 115 mapping the hierarchical part of a directory structure into the "/" 116 delimited hierarchy of the URI syntax, independent of what the native 117 platform delimiter is. 119 For example, on Windows platforms, it is typical that the file system 120 presents backslash "\" as the file delimeter for file names, yet the 121 URI's forward slash "/" can be used in file: URIs. Similarly, on 122 (some) Macintosh OS versions, at least in some contexts, the colon 123 (":") is used as the delimiter in the native presentation of file 124 path names. Unix systems natively use the same forward slash "/" 125 delimiter for hierarchy, so there is a closer mapping between file 126 paths and native path names. 128 3.2 Drives, drive letters, mount points, file system root 130 There is considerable difference, in practice, for handling of the 131 syntax for the "top" of the hierarchy. The file URI syntax provides 132 one simple place for designating the root of the file hierachy, and 133 implementations have diverged, even on the same platform, sometimes 134 even within a single application. 136 For example, DOS- and Windows-based systems support the notion of a 137 "drive letter", a single character which represents a (virtual) 138 drive, mount point, or device. Native representations of file paths 139 start with the drive letter, a colon, and then the path; e.g., 140 "c:\tmp\test.txt". 142 Drive letters are mapped into the top of a file URI in various ways, 143 depending on the implementation; some applications substitute 144 vertical bar ("|") for the colon after the drive letter, yielding 145 "file:///c|/tmp/test.txt". In some cases, the colon is left 146 unchanged, as in "file:///c:/tmp/test.txt". In other cases, the 147 colon is simply omitted, as in "file:///c/tmp/test.txt". 149 3.3 Use of hostname and host name checking 151 The file URI specification calls for using the actual host name as 152 the name authority and allowing it to be omitted. This practice is 153 rarely followed, and frequently is not checked. Some applications 154 generate URIs with no authority component at all, such as 155 "file:/this/is/the/path". 157 3.4 Character sets and encodings 159 Local file systems sometimes use many different encodings for 160 representing file names. For interoperability sake, it would be 161 preferable for file: URI libraries to translate the native character 162 encoding for file names to and from Unicode. 164 4. Security Considerations 166 There are many security considerations for URI schemes discussed in 167 [2396bis]. 169 Software that resolves a file: URL should have the same priviledges 170 as the user of the software to prevent a user from using file: 171 schemes to read files for which they do not have privileges. 173 5 Informative References 175 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 176 Resource Locators (URL)", RFC 1738, December 1994. 178 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 179 Resource Identifiers (URI): Generic Syntax", RFC 2396, 180 August 1998. 182 [2396bis] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 183 Resource Identifiers (URI): Generic Syntax", work in 184 progress, draft-fielding-uri-rfc2396bis-nn.txt. 186 Author's Address 188 Paul Hoffman 189 VPN Consortium 190 127 Segre Place 191 Santa Cruz, CA 95060 192 US 194 EMail: paul.hoffman@vpnc.org 196 Intellectual Property Statement 198 The IETF takes no position regarding the validity or scope of any 199 Intellectual Property Rights or other rights that might be claimed to 200 pertain to the implementation or use of the technology described in 201 this document or the extent to which any license under such rights 202 might or might not be available; nor does it represent that it has 203 made any independent effort to identify any such rights. Information 204 on the procedures with respect to rights in RFC documents can be 205 found in BCP 78 and BCP 79. 207 Copies of IPR disclosures made to the IETF Secretariat and any 208 assurances of licenses to be made available, or the result of an 209 attempt made to obtain a general license or permission for the use of 210 such proprietary rights by implementers or users of this 211 specification can be obtained from the IETF on-line IPR repository at 212 http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights that may cover technology that may be required to implement 217 this standard. Please address the information to the IETF at 218 ietf-ipr@ietf.org. 220 Disclaimer of Validity 222 This document and the information contained herein are provided on an 223 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 224 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 225 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 226 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 227 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 228 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 230 Copyright Statement 232 Copyright (C) The Internet Society (2004). This document is subject 233 to the rights, licenses and restrictions contained in BCP 78, and 234 except as set forth therein, the authors retain all their rights. 236 Acknowledgment 238 Funding for the RFC Editor function is currently provided by the 239 Internet Society.