idnits 2.17.1 draft-shur-pack-uri-scheme-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4234 (ref. '2') (Obsoleted by RFC 5234) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Andrey Shur 2 Intended status: Informational Jerry Dunietz 3 Creation date: February 17, 2009 Microsoft Corp 4 Expiration date: August 2009 6 The "pack" URI Scheme 7 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with 12 the provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright (c) 2007 IETF Trust and the persons identified as the 30 document authors. All rights reserved. 32 Abstract 34 A package is a logical entity that holds a collection of parts. 35 Given the URI for a complete package, the "pack" URI scheme provides 36 for the construction and use of URIs referring to individual parts 37 within the package. It also provides for the use of part's URIs as 38 base URIs for resolving relative references between the parts in a 39 single package. 41 1. Introduction 43 The material in this document is also included within the "Office 44 Open XML File Formats" ECMA-376 Standard (http://www.ecma- 45 international.org/publications/standards/Ecma-376.htm, Part 2),and 46 is being presented as an IETF RFC for informational purposes. 48 The purpose of the "pack" URI scheme is: 50 a. To identify a part resource within a package that conforms to 51 Open Packaging Conventions [4]. 53 b. To enable the use of a part's URI as a base URI for resolving 54 relative references to parts within the same package as it is 55 defined in RFC 3986, section 5.2 [1]. 57 2. Terminology 59 The following terms are used as they are defined in RFC 3986 [1]: 60 "URI", "relative reference", "base URI", "scheme", "component", 61 "query", "unreserved", "sub-delims", "pct-encoded", "resource" 63 Section 3.3 of this document defines the terms "authority", "path", 64 and "segment" in a manner that is consistent with, but more 65 restrictive than, RFC 3986 [1]. 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 69 this document are to be interpreted as described in RFC 2119 [3]. 71 3. Syntax Rules 73 3.1. General Syntax 75 The "pack" URI takes the form: 77 "pack://" authority ["/" | path ] 79 The authority component contains an encoded URI that identifies 80 the package resource. 82 The path component identifies a particular part within the 83 package identified by the authority component. When provided, the 84 path component describes a path to a part in the package. 86 When the path component is missing, the "pack" URI identifies the 87 package resource as a whole. 89 3.2. Examples 91 pack://http:,,www.mysite.com,my.package/a/b/foo.xml 92 pack://http:,,www.mysite.com,my.package 93 pack://http:,,www.mysite.com,my.package/ 95 3.3. Grammar 97 The ABNF [2] (certain values are included by reference from RFC 98 3986 [1]): 100 pack-uri = "pack://" authority ["/" | path ] 102 authority = *( unreserved | sub-delims | pct-encoded | ":" ) 103 path = 1*( "/" segment ) 104 segment = 1*( pchar ) 106 unreserved = // as specified in RFC 3986 107 sub-delims = // as specified in RFC 3986 108 pct-encoded = // as specified in RFC 3986 109 pchar = // as specified in RFC 3986 110 The grammar must fit the following restrictions: 112 a. A segment MUST NOT contain pct-encoded "/" or "\" characters. 113 b. A segment MUST NOT contain pct-encoded unreserved characters. 114 c. A segment MUST NOT end with a dot (".") character. 115 d. A segment MUST include at least one non-dot character. 117 4. Resolving 119 This section defines the process of resolving a "pack" URI to a 120 resource (either a package or a package part): 122 a. Parse the "pack" URI into the scheme, authority, and path 123 components, following the rules established for these 124 components for generic URI syntax in RFC 3986 [1]. 125 b. In the authority component replace all "," characters with 126 "/". 127 c. In the resulting authority component un-escape all pct-encoded 128 ASCII characters. 129 d. The resulting authority component MUST hold an absolute URI 130 identifying the package resource. 131 e. If the path component is missing, "pack" URI resolves to the 132 package resource identified by the authority component. 133 f. If path component is present, "pack" URI resolves to the 134 part, with the name equal to the path component, within the 135 package identified by the authority component. 137 5. Equivalence 139 Pack URIs are equivalent if all three of the following conditions 140 hold: 142 a. The scheme components are octet-by-octet identical after they 143 are converted to lowercase. 145 b. The decoded (as it is defined by 4.b, 4.c in this document) 146 authority components are equivalent URIs (the equivalency rules 147 by scheme, as per RFC 3986). 149 c. The path components are equivalent when compared as case- 150 insensitive ASCII strings. 152 6. Security Considerations 154 a. The "pack" URI scheme is not associated with any particular 155 network protocols. Its grammar is fully compatible with the 156 generic URI syntax defined in RFC 3986 [1]. The "pack" URI 157 scheme does not introduce any specific security issues related 158 to URI parsing and relative reference resolution. 160 b. Because the authority component of a "pack" URI identifies a 161 package, resolving a relative reference that does not begin with 162 "//" against a base "pack" URI will never yield a target URI 163 identifying a resource outside of the package. 165 7. IANA Considerations 167 The IANA registry for URI schemes 168 SHOULD be 169 updated to include an entry for the "pack" URI scheme 170 (under Provisional URI Schemes) when the "pack" URI scheme is 171 accepted for publication as an RFC. This entry SHOULD contain 172 the following values: 174 Scheme Name: pack 176 Description: "pack" URI scheme provides for the construction and 177 use of URIs referring to individual parts within the package. 179 Reference: RFC TBD 181 8. Normative References 183 [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 184 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 185 January 2005. 187 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 188 Specifications: ABNF", RFC 4234, October 2005. 190 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 191 Levels", BCP 14, RFC 2119, March 1997. 193 [4] Open Packaging Conventions. (Standard ECMA-376 "Office Open XML 194 File Formats", Part 2, December 2006) 196 9. Author's Addresses 198 Andrey Shur 199 Microsoft Corporation 200 One Microsoft Way 201 Redmond, WA 98052-6399 202 Email: andreysh@microsoft.com 204 Jerry Dunietz 205 Microsoft Corporation 206 One Microsoft Way 207 Redmond, WA 98052-6399 208 Email: jerryd@microsoft.com 210 Acknowledgment 212 Funding for the RFC Editor function is provided by the IETF 213 Administrative Support Activity (IASA).