[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05

Internet Draft                                              Andrey Shur
Intended status: Informational                            Jerry Dunietz
Creation date:   February 17, 2009                       Microsoft Corp
Expiration date: August 2009

                           The "pack" URI Scheme
                    <draft-shur-pack-uri-scheme-05.txt>

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Copyright (c) 2007 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Abstract

   A package is a logical entity that holds a collection of parts.
   Given the URI for a complete package, the "pack" URI scheme provides
   for the construction and use of URIs referring to individual parts
   within the package.  It also provides for the use of part's URIs as
   base URIs for resolving relative references between the parts in a
   single package.

Shur & Dunietz             Expires August 2009               [Page 1]

Internet Draft           The "pack" URI Scheme          February 2009

1. Introduction

   The material in this document is also included within the "Office
   Open XML File Formats" ECMA-376 Standard (http://www.ecma-
   international.org/publications/standards/Ecma-376.htm, Part 2),and
   is being presented as an IETF RFC for informational purposes.

   The purpose of the "pack" URI scheme is:

   a. To identify a part resource within a package that conforms to
      Open Packaging Conventions [4].

   b. To enable the use of a part's URI as a base URI for resolving
      relative references to parts within the same package as it is
      defined in RFC 3986, section 5.2 [1].

2. Terminology

   The following terms are used as they are defined in RFC 3986 [1]:
   "URI", "relative reference", "base URI", "scheme", "component",
   "query", "unreserved", "sub-delims", "pct-encoded", "resource"

   Section 3.3 of this document defines the terms "authority", "path",
   and "segment" in a manner that is consistent with, but more
   restrictive than, RFC 3986 [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [3].

3. Syntax Rules

3.1. General Syntax

   The "pack" URI takes the form:

   "pack://" authority ["/" | path ]

   The authority component contains an encoded URI that identifies
   the package resource.

   The path component identifies a particular part within the
   package identified by the authority component. When provided, the
   path component describes a path to a part in the package.

   When the path component is missing, the "pack" URI identifies the
   package resource as a whole.

3.2. Examples

   pack://http:,,www.mysite.com,my.package/a/b/foo.xml
   pack://http:,,www.mysite.com,my.package
   pack://http:,,www.mysite.com,my.package/

Shur & Dunietz             Expires August 2009               [Page 2]

Internet Draft           The "pack" URI Scheme          February 2009

3.3. Grammar

   The ABNF [2] (certain values are included by reference from RFC
   3986 [1]):

   pack-uri     = "pack://" authority ["/" | path ]

   authority    = *( unreserved | sub-delims | pct-encoded | ":" )
   path         = 1*( "/" segment )
   segment      = 1*( pchar )

   unreserved   = // as specified in RFC 3986
   sub-delims   = // as specified in RFC 3986
   pct-encoded  = // as specified in RFC 3986
   pchar        = // as specified in RFC 3986
   The <segment> grammar must fit the following restrictions:

   a. A segment MUST NOT contain pct-encoded "/" or "\" characters.
   b. A segment MUST NOT contain pct-encoded unreserved characters.
   c. A segment MUST NOT end with a dot (".") character.
   d. A segment MUST include at least one non-dot character.

4. Resolving

   This section defines the process of resolving a "pack" URI to a
   resource (either a package or a package part):

   a. Parse the "pack" URI into the scheme, authority, and path
      components, following the rules established for these
      components for generic URI syntax in RFC 3986 [1].
   b. In the authority component replace all "," characters with
      "/".
   c. In the resulting authority component un-escape all pct-encoded
      ASCII characters.
   d. The resulting authority component MUST hold an absolute URI
      identifying the package resource.
   e. If the path component is missing, "pack" URI resolves to the
      package resource identified by the authority component.
   f. If path component is present, "pack" URI resolves to the
      part, with the name equal to the path component, within the
      package identified by the authority component.

Shur & Dunietz             Expires August 2009               [Page 3]

Internet Draft           The "pack" URI Scheme          February 2009


5. Equivalence

   Pack URIs are equivalent if all three of the following conditions
   hold:

   a. The scheme components are octet-by-octet identical after they
      are converted to lowercase.

   b. The decoded (as it is defined by 4.b, 4.c in this document)
      authority components are equivalent URIs (the equivalency rules
      by scheme, as per RFC 3986).

   c. The path components are equivalent when compared as case-
      insensitive ASCII strings.

6. Security Considerations

   a. The "pack" URI scheme is not associated with any particular
      network protocols. Its grammar is fully compatible with the
      generic URI syntax defined in RFC 3986 [1]. The "pack" URI
      scheme does not introduce any specific security issues related
      to URI parsing and relative reference resolution.

  b. Because the authority component of a "pack" URI identifies a
      package, resolving a relative reference that does not begin with
      "//" against a base "pack" URI will never yield a target URI
      identifying a resource outside of the package.

7. IANA Considerations

    The IANA registry for URI schemes
    <http://www.iana.org/assignments/uri-schemes.html> SHOULD be
    updated to include an entry for the "pack" URI scheme
    (under Provisional URI Schemes) when the "pack" URI scheme is
    accepted for publication as an RFC. This entry SHOULD contain
    the following values:

    Scheme Name: pack

    Description: "pack" URI scheme provides for the construction and
    use of URIs referring to individual parts within the package.

    Reference: RFC TBD

Shur & Dunietz             Expires August 2009               [Page 4]

Internet Draft           The "pack" URI scheme          February 2009

8. Normative References

   [1]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
        Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
        January 2005.

   [2]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 4234, October 2005.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Open Packaging Conventions. (Standard ECMA-376 "Office Open XML
        File Formats", Part 2, December 2006)

9. Author's Addresses

   Andrey Shur
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   Email: andreysh@microsoft.com

   Jerry Dunietz
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399
   Email: jerryd@microsoft.com

Shur & Dunietz             Expires August 2009               [Page 5]
Internet Draft           The "pack" URI scheme          February 2009

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/