idnits 2.17.1 draft-kerwin-file-scheme-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC1738]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 18, 2013) is 3865 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) -- Looks like a reference, but probably isn't: '5' on line 317 -- Looks like a reference, but probably isn't: '6' on line 331 -- Looks like a reference, but probably isn't: '1' on line 558 -- Looks like a reference, but probably isn't: '2' on line 561 -- Looks like a reference, but probably isn't: '3' on line 565 -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'UTR15' -- Obsolete informational reference (is this intentional?): RFC 1738 (Obsoleted by RFC 4248, RFC 4266) -- Obsolete informational reference (is this intentional?): RFC 3530 (Obsoleted by RFC 7530) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Kerwin 3 Internet-Draft QUT 4 Intended status: Standards Track September 18, 2013 5 Expires: March 22, 2014 7 The 'file' URI Scheme 8 draft-kerwin-file-scheme-08 10 Abstract 12 This document specifies the file Uniform Resource Identifier (URI) 13 scheme that was originally specified in [RFC1738]. The purpose of 14 this document is to keep the information about the scheme on 15 standards track, since [RFC1738] has been made obsolete, and to 16 promote interoperability by resolving disagreements between various 17 implementations. 19 Note to Readers 21 This draft should be discussed on its github project page [github]. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 22, 2014. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4 57 2. Scheme Definition . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Components . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3. Implementation Notes . . . . . . . . . . . . . . . . . . . . 7 61 3.1. Hierarchical Structure . . . . . . . . . . . . . . . . . 7 62 3.2. Absolute and relative file paths . . . . . . . . . . . . 8 63 3.3. Drive Letters . . . . . . . . . . . . . . . . . . . . . . 8 64 3.4. UNC File Paths . . . . . . . . . . . . . . . . . . . . . 9 65 3.5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 10 66 4. Encoding and Character Set Considerations . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 6.1. URI Scheme Name . . . . . . . . . . . . . . . . . . . . . 11 70 6.2. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . 11 72 6.4. URI Scheme Semantics . . . . . . . . . . . . . . . . . . 11 73 6.5. Encoding Considerations . . . . . . . . . . . . . . . . . 11 74 6.6. Applications/Protocols That Use This URI Scheme Name . . 12 75 6.7. Interoperability Considerations . . . . . . . . . . . . . 12 76 6.8. Security Considerations . . . . . . . . . . . . . . . . . 12 77 6.9. Contact . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.10. Author/Change Controller . . . . . . . . . . . . . . . . 12 79 6.11. References . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 8.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The 'file' URI scheme has historically had little or no 89 interoperability between platforms. Further, implementers on a 90 single platform have often disagreed on the syntax to use for a 91 particular filesystem. This document attempts to resolve those 92 problems, and define a standard scheme which is interoperable between 93 different extant and future implementations. Additionally, it aims 94 to ease implementation by conforming to a general syntax that allows 95 existing URI parsing machinery to parse 'file' URIs. 97 URIs were previously defined in [RFC1738], which was updated by 98 [RFC3986]. Those documents also specify how to define schemes for 99 URIs. 101 The first definition for many URI schemes appeared in [RFC1738]. 102 Because that document has been made obsolete, this document copies 103 the 'file' URI scheme from it to allow that material to remain on 104 standards track. 106 1.1. History 108 This section is non-normative. 110 The 'file' URI scheme was first defined in [RFC1630], which, being an 111 informational RFC, does not specify an Internet standard. The 112 definition was standardised in [RFC1738], and the scheme was 113 registered with the Internet Assigned Numbers Authority (IANA) 114 [IANA-URI-Schemes]; however that definition omitted certain language 115 included by former that clarified aspects such as: 117 o the use of slashes to donate boundaries between directory levels 118 of a hierarchical file system; and 120 o the requirement that client software convert the 'file' URI into a 121 file name in the local file name conventions. 123 The Internet draft [I-D.draft-hoffman-file-uri] was written in an 124 effort to keep the 'file' URI scheme on standards track when 125 [RFC1738] was made obsolete, but that draft expired in 2005. It 126 enumerated concerns arising from the various, often conflicting 127 implementations of the scheme. It serves as the basis of this 128 document. 130 The 'file' URI scheme defined in [RFC1738] is referenced three times 131 in the current URI Generic Syntax standard [RFC3986], despite the 132 former's obsoletion: 134 1. RFC 3986, Section 1.1 uses "file:///etc/hosts" as an example for 135 identifying a resource in relation to the end-user's local 136 context. 138 2. RFC 3968, Section 1.2.3 mentions the "file" scheme regarding 139 relative references. 141 3. RFC 3968, Section 3.2.2 says that '...the "file" URI scheme is 142 defined so that no authority, an empty host, and "localhost" all 143 mean the end-user's machine...'. 145 Finally the WHATWG defines a living URL standard [WHATWG-URL], which 146 includes algorithms for interpreting file URIs (as URLs). 148 1.2. Conventions and Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 2. Scheme Definition 156 The 'file' URI scheme is used to identify and retrieve 'files' 157 accessible on a particular host computer, where a "file" is a named 158 resource which can be accessed through the computer's filesystem 159 interface. These file names are interpreted from the perspective of 160 the user of a reference, rather than in relation to a globally- 161 defined naming authority, so care ought to be taken when distributing 162 'file' URIs to ensure that such references are actually intended to 163 be interpreted in relation to the end user's filesystem interface. 165 This scheme, unlike most other URI schemes, does not identify a 166 resource that is universally accessible over the Internet. 168 The mechanism for retrieving a representation of a dereferenced 169 'file' URI is through the computer's filesystem interface; for 170 example using the POSIX "open", "read" and "close" functions [POSIX]. 172 Also note that 'file' and 'ftp' URIs are not the same, even when the 173 target of the 'ftp' URI is the local host. 175 2.1. Components 177 The 'file' URI scheme conforms with the generic structure defined in 178 [RFC3986], and can be described in terms of its components: 180 Scheme 181 The literal value "file" 183 Authority 184 The authority component of a 'file' URI describes the machine or 185 system on which the file is accessible. If the authority refers 186 to a remote system, from the point of view of the user of the URI, 187 the implication is that the file system cannot be accessed, or 188 perhaps that some other mechanism must be used to access the file. 189 It does not imply that the file ought to be accessible over a 190 network connection. No retrieval mechanism for files stored on a 191 a remote machine is defined by this specification. 193 The authority component is optional in a 'file' URI. 195 If present it is either: one of the special values "localhost" or 196 the empty string (""); or the host name of the system on which the 197 file is accessible. 199 If the authority component is omitted, or has either of the 200 special values "localhost" or the empty string (""), it is 201 interpreted as "the machine from which the URI is being 202 interpreted". 204 Path 205 The path component of a 'file' URI describes the hierarchical 206 directory path to the file, using the slash ("/") character to 207 separate directories. Implementations SHOULD translate between 208 the slash-separated URI syntax and the local system's conventions 209 for specifying file paths, where they differ. (See: Section 3.1) 211 Note that the leading slash, if any, is included in the path 212 value. 214 Some systems allow 'file' URIs to refer to directories. In this 215 case, the path usually (but not always) includes a terminating 216 slash character, such as in: 218 file:///usr/local/bin/ 220 The presence of a terminating slash character always indicates 221 that the 'file' URI refers to a directory, but the absence of a 222 slash does not necessarily indicate that it refers to a filesystem 223 object other than a directory. Implementations ought to use other 224 mechanisms to detect directories, if and when such detection is 225 required. 227 Query 228 The query component of a 'file' URI contains non-hierarchical data 229 that, along with data in the path component, serves to identify a 230 file. For example, in a versioning file system, the query 231 component might be used to refer to a specific version of a file. 233 Few implementations are known to use or support query components 234 in 'file' URIs. 236 Fragment 237 The semantics of a fragment component are undefined by this 238 specification. A protocol that employs 'file' URIs MAY define its 239 own semantics for fragment components in the context of that 240 protocol. 242 Previous definitions of the 'file' URI scheme required two slashes 243 between the scheme and path, so implementations that wish to remain 244 interoperable with older implementations ought to include an 245 authority component in any 'file' URIs they generate. 247 2.2. Syntax 249 The 'file' URI syntax is defined here in Augmented Backus-Naur Form 250 (ABNF) [RFC5234], including the core ABNF syntax rule 'ALPHA' defined 251 by that specification, and borrowing the 'host', 'path-absolute' and 252 'segment' rules from [RFC3986] (as updated by [RFC6874]). 254 fileURI = "file" ":" ( auth-file / local-file ) 256 auth-file = "//" ( host-file / nohost-file ) 258 host-file = hostpart path-absolute 259 ; file:/// 260 ; file://localhost/ 262 nohost-file = path-abs ; begins with "/" 263 / path-abs-win ; begins with drive-letter 264 ; file:/// 265 ; file://// 266 ; file://c:/ * 268 local-file = path-absolute ; file:/ 269 / path-abs-win ; file:c:/ 271 hostpart = "localhost" / host 273 path-abs = 1*( "/" segment ) 275 path-abs-win = drive-letter path-absolute 276 drive-letter = ALPHA [ drive-marker ] 277 drive-marker = ":" / "|" 279 * The 'no-host-file' rule allows for dubious URIs that encode a 280 Windows drive letter as the authority component. See Section 3.3 of 281 RFC XXXX. [Note to RFC Editor: please replace XXXX with the number 282 issued to this document.] 284 Note the difference between the 'path-abs' and 'path-absolute' rules: 285 only the former allows a zero-length first segment followed by a 286 slash, e.g. "//foo/bar" 288 Systems exhibit different levels of case-sensitivity. 289 Implementations SHOULD maintain the case of file and directory names 290 when translating 'file' URIs to and from the local system's 291 representation of file paths, and any systems or devices that 292 transport 'file' URIs SHOULD NOT alter the case of 'file' URIs they 293 transport. 295 3. Implementation Notes 297 3.1. Hierarchical Structure 299 Most implementations of the 'file' URI scheme do a reasonable job of 300 mapping the hierarchical part of a directory structure into the slash 301 ("/") delimited hierarchy of the URI syntax, independent of the 302 native platform's delimiter. 304 For example, on Microsoft Windows platforms, it is typical that the 305 file system presents backslash ("\") as the file delimeter for file 306 names, yet the URI's forward slash ("/") can be used in 'file' URIs 307 interpreted on those platforms. Similarly, on (some) Macintosh OS 308 versions, at least in some contexts, the colon (":") is used as the 309 delimiter in the native presentation of file path names. Unix 310 systems natively use the same forward slash ("/") delimiter for 311 hierarchy, so there is a closer mapping between 'file' URI paths and 312 native path names. 314 In accordance with Section 3.3 of [RFC3986], the path segments "." 315 and "..", also known as dot-segments, are only interpreted within 316 the URI path hierarchy and are removed as part of the resolution 317 process ([RFC3986], Section 5.2 [5]). Implementations operating on 318 or interacting with systems that allow dot-segments in their native 319 path representation may be required to escape those segments using 320 some other means when translating to and from 'file' URIs. 322 3.2. Absolute and relative file paths 324 The conventions for specifying absolute file paths differ from system 325 to system. For example, in a UNIX-based system an absolute file path 326 begins with a slash ("/") character, denoting the root of the 327 filesystem, whereas on a Microsoft DOS- or Windows-based system an 328 absolute file path begins with a drive letter (e.g. "c:\"). 330 As relative references are resolved into their respective (absolute) 331 target URIs according to Section 5 [6] of [RFC3986], this document 332 does not describe that resolution. However, a fully resolved URI may 333 contain a non-absolute path. For example, using a generic parser, 334 the URI: 336 file:alpha/bravo/charlie 338 would be parsed and interpreted as: file 'charlie', in directory 339 'bravo', in directory 'alpha', on the machine on which the URI is 340 being interpreted (i.e. localhost); however there is no indication of 341 the location of the directory 'alpha' on that machine. By convention 342 an absolute file path would begin with a slash ("/") character on a 343 Unix-based system, or a drive letter (e.g. "c:\") on a Microsoft 344 Windows system, etc. 346 Resolution of relative file paths is undefined by this specification. 347 A protocol that employs 'file' URIs MAY define its own rules for 348 resolution of relative file paths in the context of that protocol. 350 3.3. Drive Letters 352 Historically drive letters have been mapped into the top of a 'file' 353 URI in various ways. On systems running some versions of Microsoft 354 Windows the drive letter may be specified with a colon (":") 355 character, however sometimes the colon is replaced with a pipe ("|") 356 character, and in some implementations the colon is omitted entirely. 357 The three representations MAY be considered equivalent, and any 358 implementation which could interact with a Microsoft Windows 359 environment SHOULD interpret a single letter, optionally followed by 360 a colon or pipe character, in the first segment of the path as a 361 drive letter (see the "drive-letter" rule in Section 2.2). For 362 example, the following URIs: 364 file:///c:/TMP/test.txt 365 file:///c|/TMP/test.txt 366 file:///c/TMP/test.txt 368 when interpreted on the same machine, would refer to the same file: 370 c:\TMP\test.txt 372 Implementations SHOULD use a colon (":") character to specify drive 373 letters when generating URIs for Windows- and DOS-based systems. 375 Note that the generic URI syntax in [RFC3986] dictates that "if a URI 376 contains an authority component [even if it's a blank authority], 377 then the path component must ... begin with a slash ("/") character." 378 However some systems running some versions of Microsoft Windows are 379 known to omit the slash before the drive letter, effectively 380 replacing the URI's authority component with the drive specification; 381 for example, "file://c:/TMP/test.txt". In line with Postel's 382 robustness principle ("an implementation must be conservative in its 383 sending behavior, and liberal in its receiving behavior" [RFC791]) 384 implementations that are likely to encounter such a URI MAY interpret 385 it as a drive letter, but SHOULD NOT generate such URIs. 387 3.4. UNC File Paths 389 The Microsoft Windows Universal Naming Convention (UNC) [MS-DTYP] 390 defines a convention for specifying the location of resources such as 391 shared files or devices, for example Windows shares accessed via the 392 SMB/CIFS protocol [MS-SMB2]. The general structure of a UNC file 393 path, given in Augmented Backus-Naur Form (ABNF) [RFC5234], is: 395 UNC = "\\" hostname "\" sharename *( "\" objectname ) 396 hostname = 397 sharename = 398 objectname = 400 Note that this syntax description is non-normative. 402 The canonical representation of a UNC file path as a 'file' URI 403 copies the UNC 'hostname' into the URI 'host' field, and the UNC 404 'sharename' and 'objectname's, concatenated with forward slash ("/") 405 characters, into the 'path'. For example, the following UNC path: 407 \\server.example.com\Share\path\to\file.doc 409 is represented as a 'file' URI canonically as: 411 file://server.example.com/Share/path/to/file.doc 412 \________________/\_____________________/ 413 hostname sharename+objectnames 415 Historically some implementations have translated UNC file paths 416 entirely into the 'path' segment of a 'file' URI, including both 417 leading slashes, and the Firefox web browser even prefixes the UNC 418 file path with another slash. For example, the UNC path given above 419 might be translated as: 421 file:////server.example.com/Share/path/to/file.doc 422 \_________________________________________/ 423 translated UNC path 425 or even: 427 file://///server.example.com/Share/path/to/file.doc 428 \_________________________________________/ 429 translated UNC path 431 An implementation receiving such a URI SHOULD convert it to the 432 canonical representation before processing it. 434 The 'file' URI scheme is unusual in that it does not specify an 435 Internet protocol or access method for shared files; as such, its 436 utility in network protocols between hosts is limited. Examples of 437 file server protocols that do define such access methods include SMB/ 438 CIFS [MS-SMB2], NFS [RFC3530], and NCP [NOVELL]. 440 3.5. Namespaces 442 The Microsoft Windows API defines Win32 Namespaces [Win32-Namespaces] 443 for interacting with files and devices using Windows API functions. 444 These namespaced paths are prefixed by "\\?\" for Win32 File 445 Namespaces and "\\.\" for Win32 Device Namespaces. There is also a 446 special case for UNC file paths [MS-DTYP] in Win32 File Namespaces, 447 referred to as "Long UNC", using the prefix "\\?\UNC\". 449 This specification does not define a mechanism for translating 450 namespaced file paths into 'file' URIs. 452 4. Encoding and Character Set Considerations 454 As specified in [RFC3986], the 'file' URI scheme allows any character 455 from the Universal Character Set (UCS) [ISO10646] encoded as UTF-8 456 [RFC3629] and then percent-encoded in valid ASCII [RFC20]. 458 If the local file system uses a known non-Unicode character encoding, 459 the file path SHOULD be converted to a sequence of Unicode characters 460 normalized according to Normalization Form C (NFC, [UTR15]). 462 Before applying any percent-encoding, an application MUST ensure the 463 following about the string that is used as input to the URI- 464 construction process: 466 o The host, if any, consists only of Unicode code points that 467 conform to the rules specified in [RFC5892]. 469 o Internationalized domain name (IDN) labels are encoded as A-labels 470 [RFC5890]. 472 5. Security Considerations 474 There are many security considerations for URI schemes discussed in 475 [RFC3986]. 477 File access and the granting of privileges for specific operations 478 are complex topics, and the use of 'file' URIs can complicate the 479 security model in effect for file privileges. Under no circumstance 480 should software using 'file' URIs grant greater access than would be 481 available for other file access methods. 483 6. IANA Considerations 485 In accordance with the guidelines and registration procedures for new 486 URI schemes [RFC4395], this section provides the information needed 487 to update the registration of the 'file' URI scheme. 489 6.1. URI Scheme Name 491 file 493 6.2. Status 495 permanent 497 6.3. URI Scheme Syntax 499 See Section 2.2 of RFC XXXX. [Note to RFC Editor: please replace 500 XXXX with the number issued to this document.] 502 6.4. URI Scheme Semantics 504 See Section 2 of RFC XXXX. [Note to RFC Editor: please replace XXXX 505 with the number issued to this document.] 507 6.5. Encoding Considerations 509 See Section 4 of RFC XXXX. [Note to RFC Editor: please replace XXXX 510 with the number issued to this document.] 512 6.6. Applications/Protocols That Use This URI Scheme Name 514 Web browsers: 516 o Firefox 518 Note: Firefox has a unique interpretation of RFC 1738 (See: 519 Bugzilla#107540 [1]), which affects UNC paths. 521 o Chromium 523 o Internet Explorer 525 o Opera 527 Other applications/protocols: 529 o Windows API [2, 3] 531 o Perl LWP 533 6.7. Interoperability Considerations 535 Due to the convoluted history of the 'file' URI scheme there a many, 536 varied implementations in existence. Many have converged over time, 537 forming a few kernels of closely-related functionality, and RFC XXXX 538 attempts to accommodate such common functionality. [Note to RFC 539 Editor: please replace XXXX with the number issued to this document.] 540 However there will always be exceptions, and this fact is recognised. 542 6.8. Security Considerations 544 See Section 4 of RFC XXXX [Note to RFC Editor: please replace XXXX 545 with the number issued to this document.] 547 6.9. Contact 549 Matthew Kerwin, matthew.kerwin@qut.edu.au 551 6.10. Author/Change Controller 553 This scheme is registered under the IETF tree. As such, the IETF 554 maintains change control. 556 6.11. References 558 [1] "Bug 107540", Bugzilla@Mozilla, October 2007, 559 . 561 [2] "PathCreateFromUrl function", MSDN, June 2013, 562 . 565 [3] "UrlCreateFromPath function", MSDN, June 2013, 566 569 7. Acknowledgements 571 This specification is derived from RFC 1738 [RFC1738], RFC 3986 572 [RFC3986], and I-D draft-hoffman-file-uri (expired) 573 [I-D.draft-hoffman-file-uri]; the acknowledgements in those documents 574 still apply. 576 8. References 578 8.1. Normative References 580 [ISO10646] 581 International Organization for Standardization, 582 "Information Technology - Universal Multiple-Octet Coded 583 Character Set (UCS)", December 2003. 585 [RFC20] Cerf, V., "ASCII format for Network Interchange", October 586 1969. 588 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", March 1997. 591 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 592 10646", November 2003. 594 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 595 Resource Identifier (URI): Generic Syntax", January 2005. 597 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 598 Specifications: ABNF", January 2008. 600 [RFC5890] Klensin, J., "Internationalized Domain Names for 601 Applications (IDNA): Definitions and Document Framework", 602 August 2010. 604 [RFC5892] Faltstrom, P., "The Unicode Code Points and 605 Internationalized Domain Names for Applications (IDNA)", 606 August 2010. 608 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 609 IPv6 Zone Identifiers in Address Literals and Uniform 610 Resource Identifiers", February 2013. 612 [UTR15] Davis, M. and K. Whistler, "Unicode Normalization Forms", 613 August 2012, 614 . 616 8.2. Informative References 618 [I-D.draft-hoffman-file-uri] 619 Hoffman, P., "The file URI Scheme", January 2005. 621 [IANA-URI-Schemes] 622 Internet Assigned Numbers Authority, "Uniform Resource 623 Identifier (URI) Schemes registry", June 2013, . 626 [MS-DTYP] Microsoft Open Specifications, "Windows Data Types, 2.2.56 627 UNC", January 2013, 628 . 630 [MS-SMB2] Microsoft Open Specifications, "Server Message Block (SMB) 631 Protocol Versions 2 and 3", January 2013, 632 . 634 [NOVELL] Novell, "NetWare Core Protocols", 2013, . 637 [POSIX] IEEE, "IEEE Std 1003.1, 2013 Edition", 2013, 638 . 640 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A 641 Unifying Syntax for the Expression of Names and Addresses 642 of Objects on the Network as used in the World-Wide Web", 643 June 1994. 645 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform 646 Resource Locators (URL)", December 1994. 648 [RFC3530] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., 649 Beame, C., Eisler, M., and D. Noveck, "Network File System 650 (NFS) version 4 Protocol", April 2003. 652 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 653 Registration Procedures for New URI Schemes", February 654 2006. 656 [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program, 657 Protocol Specification", September 1981. 659 [WHATWG-URL] 660 WHATWG, "URL Living Standard", May 2013, 661 . 663 [Win32-Namespaces] 664 Microsoft Developer Network, "Naming Files, Paths, and 665 Namespaces", June 2013, . 669 [github] Kerwin, M., "file-uri-scheme GitHub repository", n.d., 670 . 672 Author's Address 674 Matthew Kerwin 675 Queensland University of Technology 676 Victoria Park Rd 677 Kelvin Grove, QLD 4059 678 Australia 680 EMail: matthew.kerwin@qut.edu.au