[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet-Draft                                           J. C. Mallery
draft-mallery-urn-pdi-00.txt                             M.I.T.
Expires in six months                                    November 10, 1997

                  Persistent Document Identifiers
                  Filename: draft-mallery-urn-pdi-00.txt


Status of This Memo

      This document is an Internet-Draft.  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.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).


Abstract

   This document specifies the syntax and semantics of the Persistent
   Document Identifier (PDI) namespace within the URN framework
   defined by RFC 2141 [17]. PDIs provide a means to refer to digital
   objects and fragments that does not depend their storage location
   or the protocol used to access them. Since 1994, several
   large-scale applications with these requirements have used PDIs
   [12] [21].

   PDIs are intended primarily as permanent identifiers for archival
   reference to long-lived documents.  PDIs have a fragment syntax to
   allow permanent references to parts of documents (within specific
   formats) as well as a citation syntax to allow references to
   appearances of such fragments in composite documents.

   PDIs are most useful for any document series that is distributed via
   multiple protocols, is available from multiple sources, migrates to
   new locations, needs fragment references, or participates in
   distributed assertion semantics related to collaboration or access
   control.

1. Namespace Syntax


1.2 Design Goals

   Persistent Document Identifiers provide a means to refer to digital
   objects and fragments that does not depend their storage location
   or the protocol used to access them.  PDIs offer the following
   capabilities:

        * Multisourcing: The same resource can be stored in different
        locations yet retrieved by a virtue of a shared identifier.

        * Multiple Protocols: Identifiers are not tied to specific
        transport protocols.

        * Persistence: PDIs persist across relocation of a digital
        object to different storage sites. The longevity of a PDI is
        not limited by lifetime of a directory, domain name, or even,
        a transport protocol.

        * Organizational Delegation: PDIs define a hierarchical
        encoding of the issuing authority that allows delegation in a
        manner analogous to names in the Domain Name System names but
        more akin to X.400.

        * Chronological Delegation: PDIs incorporate a time hierarchy
        that allows delegation of identifiers with different time
        ranges to different authorities or to different resolution
        regimes.

        * Fragment Syntax: PDIs offer an extensible syntax for
        referring to part of a resource. This evolutionary approach
        allows different schemes according to media type as well as
        multiple schemes per media type. Longevity of reference is
        sought by defining fragment schemes that are independent of
        machine representation. Referential consistency is guaranteed
        by monotonic commitment of versioned PDIs to immutable
        resource representations.

        * Citation Syntax: PDIs include a syntax for referring to
        appearances of document fragments as quoted in other composite
        documents. This makes fragment quotations first-class objects,
        about which assertions can be made.

        * User Friendly: PDIs carry a relatively simple syntax with
        some mnemonics so that, if need be, people can type them to
        access a resource.

   A guiding design principle for PDIs is to minimize the document
   semantics carried within the identifier.  Most semantics is better
   encoded by assertions about PDIs. Not only is overloading of the
   identifier avoided, but assertions can also be modified without
   recourse to changing the identifier.

1. Namespace Syntax

   Consistent with the URN syntax specification in RFC 2141 [17], each
   namespace must specify syntax related information that is specific to
   that namespace.  This section provides these specifications for the
   PDI namespace. The PDI grammar below uses the ABNF [6]. A URN using
   the Persistent Document Identifier namespace has the form:

        <URN> = "urn:" pdi              ; Encoding in URN syntax

1.1. Namespace Identifier (NID)

   The Namespace Identifier for this namespace is "pdi", which is case
   insensitive.

        <PDI> = "pdi" ":" nss           ; Persistent Document Identifier

1.2. Namespace Specific String (NSS)

   The Namespace Specific String for this namespace is:

        <NSS> = resource-identifier [(citation-specifier / fragment-specifier)]

1.2.1 Resource Identifier

        <RESOURCE-IDENTIFIER> = "//" document-series "/" iso-date "/" specifier

        <DOCUMENT-SERIES> = component *["." component] "." iso-country

        <COMPONENT> = alpha-hyphen-digits

        <ISO-COUNTRY> = 2*alpha                 ; See ISO Standard 3166 [10]

        <ISO-DATE> = year "/" month "/" day

        <YEAR> = 4*digit / wildcard

        <MONTH> = 2*digit / wildcard

        <DAY> = 2*digit / wildcard

        <SPECIFIER> = unique-id ["." format ["." version]] ;versions require formats

        <UNIQUE-ID>  = daily-serial-number / encapulated-unique-id / digits /
                         wildcard

        <DAILY-SERIAL-NUMBER> = digits

        <ENCAPULATED-UNIQUE-ID> = unique-id-chars

        <UNIQUE-ID-CHARS> = alpha / digit / other / "%" hex hex

        <FORMAT> =  media-type-token / wildcard

        <MEDIA-TYPE-TOKEN> = "text" / "html" / extension-token

        <EXTENSION-TOKEN> = alpha-hyphen

        <VERSION> = digits / wildcard

        <WILDCARD> = "*"

1.2.2 Citation Specifier

        <CITATION-SPECIFIER> = "@" origin-position "=" pdi

        <ORIGIN-POSITION> = position

1.2.3 Fragment Specifier

        <FRAGMENT-SPECIFIER> = "#" [fragment-scheme "="] position [*("," position)]

        <FRAGMENT-SCHEME> = "char" / "elt" / "name" / "rect" / "msec" / "sec" /
                              "crop" / "byte" / ext-fragment-scheme

        <EXT-FRAGMENT-SCHEME> = alpha-hyphen

        <POSITION> = char-position / element-position / element-name /
                       2-dim-coordinate / frame-number / time / byte-position /
                       ext-position

        <EXT-POSITION> = position-specifier /
                           "(" position-specifier  *["," position-specifier] ")"

        <POSITION-SPECIFIER> = alphadigits


1.2.4 Supporting Definitions

        <ALPHA> = %x41-5A / %x61-7A                     ; A-Z / a-z

        <ALPHA-DIGITS> = alphas / digits

        <ALPHA-HYPHEN-DIGITS> = alpha-hyphen / digits

        <ALPHA-HYPHEN> = alpha / "-"

        <ALPHA-HYPHENS> = *alpha-hyphen

        <ALPHAS> = *ALPHA

        <DIGIT> = %x30-39                               ; 0-9

        <DIGITS> = *DIGIT

        <URN-CHARS> = trans / "%" hex hex               ;RFC 2141

        <TRANS> =  alpha / digit / other / reserved

        <HEX> = digit / "A" / "B" / "C" / "D" / "E" / "F" /
                        "a" / "b" / "c" / "d" / "e" / "f"

        <OTHER> = "(" / ")" / "-" / ":" / ";" / "$" / "_" / "!" / "'"

        <RESERVED> = "%" / "." / "," / "/" / "#" / "*" / "@" /
                     "=" / "?" / "+"


1.2.5 Reserved Characters

   <RESERVED> are used as special characters in the PDI grammar. They
   MUST be encoded according to the character escaping method
   described in RFC 2141 [17].

2 Discussion

2.1 Minting PDIs

   PDIs are issued by the authority named in <DOCUMENT-SERIES>.
   <DOCUMENT-SERIES> is intended to look like a domain name for easy
   parsing but there is no requirement to serve the name via the Domain
   Name System (DNS) nor to assure that the name is not assigned for
   other purposes by DNS.

   The encoded date in <ISO-DATE> is the date when the identifier is
   minted. This date is based on Greenwich meantime. The encoded date
   bears no relationship to dates associated with the resource that the
   PDI denotes, even if there may be proximity between the time when the
   resource issues and the time when the PDI is minted.

   The PDI namespace is monotonic; PDIs cannot be retracted. If a new
   version of the same document issues, it MUST increment the version
   number for the previously issued PDI. This requirement assures that
   any machine representation (byte sequence) associated with formats
   of a versioned PDI never changes.

   Byte equivalence for all resource formats denoted by a specific PDI
   version ensures that digital signatures associated with a PDI check
   for any uncorrupted resource. More significantly, byte equivalence
   enables reliable, efficient fragment references for many media types.
   It eliminates the potentially difficult problem of rolling fragment
   references forward as a target resource is modified.

2.2 Issuing Authority

   The issuing authority controls the name in a document series. These
   names are hierarchical so that administration can be delegated within
   authority domains. Unlike domain names, the right most component of a
   <DOCUMENT-SERIES> MUST be a two digit ISO 3166 country code [10],
   indicating the country in which the issuing organization resides.  In
   most cases, a <DOCUMENT-SERIES> SHOULD add a term to the issuing
   authority in order to differentiate the series from other document
   sets that the authority might issue. By specializing the document
   series below the issuing authority, identifiers reflect the chain of
   delegation.  Additionally, it becomes easier to obsolesce an entire
   document series, if that becomes necessary.

   For wide use of PDIs, an issuing authority will need to issue
   toplevel authority names to organizations wishing to mint PDIs in
   their own document series. Once a toplevel document series name has
   been obtained, an organization may issue PDIs itself or delegate
   subseries.

   A subseries is delegated by adding a name component to the left of
   <DOCUMENT-SERIES>. The accretion of components on a document series
   MAY utilize existing organizational names or acronyms whenever
   feasible in order to preserve mnemonics in the document series
   name. Additionally, dropping components from the left SHOULD lead
   to ever more general issuing authorities in terms of organizational
   scope.

   Delegation SHOULD follow de jure organizational structure. Issuing
   authority SHOULD NEVER be delegated outside the organization unless
   the external agent is acting directly on behalf of the document
   series owner. When organizational boundaries are crossed, a new
   document series toplevel SHOULD be acquired. Within an organization,
   issuing authority SHOULD be delegated to the level where
   responsibility for content resides. This facilitates contact with
   document originators. More importantly, it reduces administrative
   scope, and thus, encourages more uniform document management policies
   for a particular document series.

2.3 Hierarchical Date

   <ISO-DATE> of a PDI MUST be assigned when the identifier is minted.
   The calendar date MUST correspond to Greenwich Mean time.

   Inclusion of the ISO date conveys the time when the identifier was
   minted.  Beyond making it easier to guarantee identifier uniqueness,
   hierarchicalization by date enables reference to ranges of
   identifiers issued within specific time intervals.

   Use of ISO dates also ensures that lexical sorts of identifiers
   produce a chronological ordering of PDIs, making various listings
   (e.g., directory lists) automatically appear in a meaningful
   order.

   Moreover, different administrative policies MAY be applied to any
   particular time interval.  For example, when responsibility for
   resolving PDIs shifts to a different administrative authority,
   intervals covered by the new policy are readily specifiable and
   conveyed. For example, different intervals may be delegated to
   different URN resolvers and these delegations recorded with
   relevant URN discovery systems.

   Operations may be applied to identifiers within an interval. For
   example, a browser can provide a directory list of all the
   documents in a year, a month, or on a day.

   More generally, assertions can be made about identifiers within an
   interval, such as where to find a resolver.

2.4 Daily Unique ID

   An application may use a mnemonic name or a serial number as the
   <UNIQUE-ID>. The only requirement is that <UNIQUE-ID> MUST be a
   unique sequence of <UNIQUE-ID-CHARS> for <ISO-DATE> and
   <DOCUMENT-SERIES>.

   If the unique ID is a <DAILY-SERIAL-NUMBER>, serial numbers SHOULD
   start from 1 and SHOULD be incremented by 1 as each new PDI is
   minted. When the calendar day is incremented at midnight GMT, the
   unique ID of the day SHOULD be reset to start at 1 on the new day.
   This prevents daily unique IDs from growing very large as it
   enforces date semantics on the identifier.

2.4.1 Encapsulation of Foreign Identifiers

   The specification of this field has been left open so that foreign
   document identifiers MAY be incorporated within a PDI as the daily
   unique ID. For our purposes, a foreign identifier is any identifier
   used by other naming or reference regimes.  Examples of foreign
   identifiers include, serial numbers, invoice numbers, URIs, URLs or
   other application-specific identifiers.

   When encapsulating a foreign identifier, <FORMAT> is required and
   MUST use a <MEDIA-TYPE-TOKEN> that identifies the media type of the
   resource and format of the encapsulated identifier. The media type
   token is required in order to allow unambiguous interpretation by
   applications aware of the identifier semantics. All other
   applications, MUST treat the unique id as opaque.

2.5 Format

   Format should use standard, controlled terms that indicate the
   media type [3] of the resource to which the identifier refers or,
   in the case of encapsulated identifiers, indicate the type of the
   encapsulated identifier. <FORMAT> is case insensitive.

   The standards for MIME content types [10] do not as yet provide a
   single controlled term per media type that can be used as a file
   extension or here as a PDI format. Below we provide a rule for
   constructing the <MEDIA-TYPE-TOKEN>. These tokens are created from
   the registered media types [10] by using the <MINOR-TYPE> if it is
   unique, or otherwise, concatenating the <MAJOR-TYPE> and
   <MINOR-TYPE>. These tokens are case insensitive and MUST encode any
   reserved characters (<RESERVED>) for PDIs.

        <CONTENT-TYPE> = major-type "/" minor-type
                           [* (";" parameter ["=" value])]

        <MEDIA-TYPE-TOKEN> = minor-type / (major-type "+" minor-type)

        <MAJOR-TYPE> = alpha-hyphen-digits

        <MINOR-TYPE> = alpha-hyphen-digits

   There are two media types for which <MEDIA-TYPE-TOKEN> is not
   <MINOR-TYPE>:

        Token           Content Type

        text            text/plain
        header          message/header          ;RFC 822 message headers

   <FORMAT> is always required when:

      * A PDI is minted and assigned to a specific resource.
      * A foreign document ID is encapsulated in <UNIQUE-ID>.
      * References to resource fragments are made.
      * A client requests a resource in a specific format.

   The format indicates how to interpret encapsulated identifiers and
   MUST be supplied whenever foreign document identifiers are
   encapsulated. For example, if an HTTP URL was encapsulated, the
   PDI might look like:

   pdi://oma.eop.gov.us/1994/10/20/http%3a%2f%2fwww%2ewhitehouse%2egov%2f.html.1

   This PDI encapsulates the URL http://www.whitehouse.gov/ and denotes
   its content on October 20, 1994, when the site was unveiled.

   When a PDI contains fragment syntax, a format MUST be provided in
   order to convey the media type of the resource to which the
   fragment reference applies.

   A server may store any subset of formats for a resource. It may
   compute unstored formats on demand. A client can specify the desired
   format by using a PDI with the appropriate format field.

   If format is omitted, the identifier refers to the generic resource
   denoted by the PDI. Assertions about the generic resource apply to
   all the instantiations in the various media types indicated by the
   universe of format in which the resource is available.

2.6 Version

   The PDI <VERSION> is an optional component indicating a specific
   version of a resource. <VERSION> is a positive integer greater than
   0. When <VERSION> is omitted, it defaults to version 1.

   Version numbers refer to the generic resource and not the specific
   format, but a resource cannot have a version without having at
   least one format. When a resource is changed in any format, version
   numbers for all formats MUST be updated. In general, when a
   resource changes significantly, applications SHOULD generate new
   PDIs. When changes are small or incremental, applications SHOULD
   increment the version. Any change in the byte count of a resource
   for a specific <FORMAT> is a change and the version SHOULD be
   incremented. Addition of a new <FORMAT> with the same semantics as
   an existing <FORMAT> for the PDI is not a change and does not
   require the version to be incremented.

   Consequently, if an HTML document issues under

                 pdi://oma.eop.gov/1997/09/01.html.1

   ,and later, the HTML is converted to text, the PDI for the text
   version is

                 pdi://oma.eop.gov/1997/09/01.text.1

   However, if a spelling mistake is corrected later, whether or not
   it changes the byte count in any format, the version number is
   incremented.

                pdi://oma.eop.gov/1997/09/01.text.2

   An editing application MAY write internal versions of a document in
   progress and only commit to the versioned PDI at a point when the
   editing completed and the document is ready for release.

   Version numbers MUST be included when:

        * PDIs are minted and associated with specific resources.
        * PDIs contain a fragment references.
        * PDIs contain a fragment citation.

   Inclusion of a <VERSION> in a fragment references ensures that the
   fragment reference is resolved against a consistent machine
   representation of the resource.

3 Fragment Syntax

3.1 Motivation

   The PDI namespace provides an extensible syntax for referring to
   parts of resources. Fragment syntax must be extensible because:

        * There are too many existing media types.

        * Some media types require highly technical fragment syntax,
        (e.g., multidimensional points, multiresolution channels).

        * New media types are coming into existence all the time.

   The approach adopted here is to allow additional RFCs to extend
   fragment syntax by adding fragment specifiers as they are needed.

   The availability of a syntax for referring to resource fragments
   raises the problem of referring to citations of fragments by
   composite resources. The PDI namespace provides a fragment citation
   syntax to address this issue.

3.2 Philosophy

3.2.1 Media Representations

   A fragment syntax SHOULD differentiate the media representation from
   the machine representation. If fragment schemes for a particular
   media type use a media representation, they can be retargeted at new
   or different machine representations. Otherwise, fragment schemes may
   become unresolvable in the future when machine representations
   change. Consequently, although a byte fragment specifier is provided
   below, it SHOULD be used only for short-term purposes when
   alternatives are unavailable.

3.2.2  Immediate Fragments

   URNs require a fragment syntax because the alternative of interning
   every fragment PDI in a URN namespace does not scale. It requires
   the resolver to store potentially all possible permutations of the
   fragment specifier for every resource.  Immediate fragments require
   the fragment syntax to be part of the identifier.  With immediate
   fragments, resolvers need only store those fragment PDIs for which
   there are assertions beyond the binding to the resource subset.
   Additionally, immediate fragments enhance privacy by not storing
   all references to resource subsets. They also conserve storage and
   reduce computation on resolvers.

3.2.3 Fragment Conjunctions

   The fragment syntax does not support conjunctions of fragments
   because this introduces a source of ambiguity when assertions are
   made about PDIs.  Conjunctive fragments SHOULD be handled by creating
   a new PDI and asserting that it is the conjunction of some fragments.
   In this way, the set is explicitly represented and ambiguous
   references are excluded from the syntax.

3.2.4 Decoupling from Reference Mechanics

   Fragment reference could be accomplished by providing a program
   that given a resource return the specified part.  This is not the
   approach advocated here. The fragment scheme MUST be a minimal set
   of parameters required for a program to extract the relevant part.
   Additionally, these parameters SHOULD be specified in the order of
   importance for extracting the referent. This increases the
   probability of finding a referent if an identifier is accidently
   truncated. In general, new fragment specifiers SHOULD minimize the
   syntax the of invariants and parameters they require.

3.3 Fragment Scheme

   The <FRAGMENT-SCHEME> indicates the position syntax used in
   <POSITION>.  A default position scheme should be defined for each
   Content Type token used in PDIs. For example, text/plain uses
   character positions as the default.  The <FRAGMENT-SCHEME> MAY be
   omitted when it is the default position scheme for the content type
   indicated by <FORMAT>. In all other circumstances,
   <FRAGMENT-SCHEME> MUST be supplied in order to ensure unambiguous
   interpretation of position specifiers. Position schemes are case
   insensitive.

3.4 Fragment Specifiers

   The following position reference schemes have been defined:

3.4.1 Text Fragment Specifier

   Text fragments are defined for the MIME Content Type text/*.  Each
   text fragment is an interval bounded by two character positions in
   the resource. The fragment is the set of characters from <START>
   upto but excluding <END>. The first character position starts with
   0.  Character positions are relative to the canonical,CRLF encoded
   text for the resource.  Therefore, all text/* resources MUST be
   CRLF encoded to ensure correct fragment references.  The PDI
   <FORMAT> for text/plain is "text" and <CHAR-FRAGMENT-SPECIFIER> is
   the default position specifier for the media type.

        <CHAR-FRAGMENT-SPECIFIER> = "#" ["char" "="] start-char
                                        "," end-char

        <START-CHAR> = digits

        <END-CHAR> = digits

   Although wide-spread encodings for many alphabets use a single 8 bit
   byte (e.g., ISO-8859 [15]), other encodings (e.g., unicode) employ
   multi-byte encodings. Consequently, a server MUST be aware of the
   character set used to encode a text resource.  For 8 bit character
   sets, char fragment resolution reduces to byte position.  However,
   multi-byte character sets require the server to perform appropriate
   translation from the stored data representation.

   The following PDI refers to the text starting at character 37 and
   continuing upto but excluding character 51.

            pdi://oma.eop.gov.us/1997/09/01/1.text.1#char=37,51

   Since the default fragment specifier for text is
   <CHAR-FRAGMENT-SCHEME>, the following PDI is equivalent:

            pdi://oma.eop.gov.us/1997/09/01/1.text.1#37,51

   When a text/plain content type uses a multi-byte character set,
   <FORMAT> MUST be the character set token as defined by the IANA
   Character Set Registry [18].

3.4.2 HTML Fragment Specifier

   Fragments may be specified for the MIME Content Type text/html using
   character fragment specifiers. The PDI <FORMAT> for text/html is
   "html".  The default position specifier for text/html is "char"
   because it simplifies serving fragments.

   Although character references are simple and effective for HTML
   document fragments, it is often more convenient to use HTML
   elements to delimit an interval within a document.  Specific HTML
   elements can be identified using the name parameter value or the
   position of the tag in the document. In either case, the fragment
   consists of all text and HTML tags from <START-ELEMENT> to and
   including <END-ELEMENT>.  References to HTML containers is
   facilitated by use of a closed interval, but it can be awkward for
   tags that are not explicitly closed, especially if they are
   implicitly closed (e.g., <p>). Tag positions are counted from the
   start of the resource, with the first being assigned 0. An
   <ELEMENT-NAME> refers to the first element whose name parameter
   value is equal to <ELEMENT-NAME>, which must be encoded according
   to URN syntax [17], but decoded for case-sensitive equality testing.

        <HTML-FRAGMENT-SPECIFIER> = "#" start-element "," end-element

        <HTML-FRAGMENT-SCHEME> = char-fragment-scheme /
                                  element-fragment-scheme /
                                  named-fragment-scheme

        <ELEMENT-FRAGMENT-SCHEME> = "elt"

        <START-ELEMENT> = element-position / element-name

        <END-ELEMENT> = element-position / element-name

        <ELEMENT-POSITION> = digits

        <NAMED-FRAGMENT-SCHEME> = "name"

        <ELEMENT-NAME> = urn-chars

   Char, elt, and name position references MUST use the same position
   scheme for <START-ELEMENT> and <END-ELEMENT> an HTML fragment
   reference.

   HTML fragments may depend on surrounding context that is not part
   of the fragment. HTML rendition without this containing context may
   produce different effects or incorrect HTML. Responsibility for
   assuring legal and felicitous HTML must reside with the user or
   application creating the fragment reference because document
   authors cannot be expected to anticipate all possible citations.
   Therefore, the user or application creating the fragment citation
   MUST NOT create illegal HTML fragments.

   When fragments require context, the user or application MAY create
   an intermediate document that uses fragment references to extract
   both the relevant context and the target fragment.  This
   intermediate document SHOULD be legal HTML capable of standing
   alone.

3.4.2 SGML & XML Fragment Specifier

   The element and char fragment schemes can be applied to the more
   general Standard Generalized Markup Language (SGML) [14] and
   Extensible Markup Language XML [4] mark up languages, of which it
   is a subset.  The BNF below give the fragment specification for
   SGML and any subsets, such as XML.

        <SGML-FRAGMENT-SPECIFIER> = "#" sgml-start-element ","
                                        sgml-end-element

        <SGML-FRAGMENT-SCHEME> = element-fragment-scheme /
                                 char-fragment-scheme

        <SGML-START-ELEMENT> = element-position

        <SGML-END-ELEMENT> = element-position

   The default fragment specifier for SGML and SGML subsets is "char".
   The following content tokens are defined:

        text/sgml               sgml
        text/xml                xml

   The context caveats for HTML fragments should be extended pari pasu
   to SGML and XML fragments.

3.4.5 Image Fragment Specifier

   Image media types use a variety of encoding schemes and some
   include multiple frames. Fragment reference for image/* uses a two
   dimensional cartesian coordinate system with the origin (0, 0) being
   in the upper left hand corner. The scale of the coordinate system is
   the pixel level scale of the containing image. References to
   subrectangles are made by specifying for the image fragment the
   <START-COORDINATE> as the upper left most point and <END-COORDINATE>
   as the lower right most point. These x and y coordinates are in
   coordinate system of the containing image. When multiple frames are
   present in an image, the reference frame is specified by providing
   <FRAME>, which is 0 based and defaults to 0 when omitted.
   <RECTANGLE-FRAGMENT-SPECIFIER> is the default fragment specifier for
   the media types image/*.

        <RECTANGLE-FRAGMENT-SPECIFIER> = # ["rect" "="] start-coordinate
                                           "," end-coordinate ["," frame]

        <FRAME> = digits

        <START-COORDINATE> = 2-dim-coordinate

        <END-COORDINATE> = 2-dim-coordinate

        <2-DIM-COORDINATE> = "(" x-coordinate "," y-coordinate ")"

        <X-COORDINATE> = digits

        <Y-COORDINATE> = digits

   The example below refers to an image fragment whose origin is x=5,
   y=10 and extends to x=25, y=30. This yields the maximal rectangle
   including the coordinates (5,10), (24,10), (24,29), (5,29). Note that
   the zero-based coordinate system does not include the point denoted by
   the <END-COORDINATE>.

        pdi://images.satellite.nasa.gov.us/1997/09/30/1234.gif#(5,10),(25,30)

   Since frame is unspecified, it defaults to zero and this PDI is equivalent to

        pdi://images.satellite.nasa.gov.us/1997/09/30/1234.gif#(5,10),(25,30),0

   The next PDI refers to the third frame in an animated GIF. As it
   simplifies array references, the zero-based index shifts references
   to the left by 1.

        pdi://images.satellite.nasa.gov.us/1997/09/30/1234.gif#(5,10),(25,30),2

3.4.4 Audio Fragment Specifier

   Audio media types use various encoding schemes (including variable
   quality) that make byte ranges problematic for fragment references.
   Start and end times provide a coordinate scheme that can be resolved
   for any audio media type. A fragment reference includes data from and
   including <START-TIME> upto and excluding <END-TIME>. The position
   scheme for the temporal reference gives the time units. Two time
   position schemes are defined. "msec" is millesconds and "sec" is
   seconds.  Temporal position schemes MUST NOT be intermixed. The
   default time position scheme for audio/* is "sec".
   <TIME-FRAGMENT-SPECIFIER> is the default fragment specifier for
   audio/*.

        <TIME-FRAGMENT-SPECIFIER> = # time-position-scheme "="
                                      start-time "," end-time

        <TIME-POSITION-SCHEME> = "msec" / "sec" /
                                      ext-time-position-scheme

        <START-TIME> = time

        <END-TIME> = time

        <TIME> = digits

        <EXT-TIME-POSITION-SCHEME> = alpha-hyphen-digits

   The example below denotes the audio clip extending from second 23
   upto but not including second 57.

        pdi://audio.npr.org.us/1997/09/30/1234.au#sec=23,57


3.4.5 Video Fragment Specifier

   Video media types combine difficulties similar to those presented by
   audio and image media types.  A simple syntax for video should allow
   fragment references to video by start and end times. Because some
   applications may wish to crop the image, an optional x-y coordinate
   framework is also supported.

   The video fragment specifier uses a required time component and an
   optional pair of coordinates to denote cropping. A video fragment
   reference includes data from and including <START-TIME> upto and
   excluding <END-TIME> in time units given by <TIME-POSITION-SCHEME>.

   When cropping is desired, a fragment may include the optional
   <START-COORDINATE> and <END-COORDINATE>.

        <VIDEO-FRAGMENT-SPECIFIER> = # "crop" "=" time-position-scheme
                                       "," start-time "," end-time
                                       ["," start-coordinate "," end-coordinate]

   The following example refers to seconds 23 upto 51 of the video clip
   1234.mpeg.

        pdi://video.cnn.co.us/1997/09/30/1234.mpeg.1#sec,23,51



   The next PDI uses the crop fragment scheme and is equivalent to the
   preceding one because no cropping is specified.

        pdi://video.cnn.co.us/1997/09/30/1234.mpeg.1#crop=sec,23,51

   However, the crop scheme is easily able to specify a cropping, such
   as the one below.

        pdi://video.cnn.co.us/1997/09/30/1234.mpeg.1#crop=sec,23,51,(10,10),(20,20)

   Here, only the rectangle from origin (10,10) to (20,20), the right
   lowest point, is included in the fragment.

   The video fragment scheme presupposes a pixel-based imaging model.
   For other models, such as line-oriented analog video, specialized
   fragment schemes may be appropriate when cropping is desired.  Note
   that the time fragment scheme works for analog models. For this
   reason, the time position scheme <TIME-FRAGMENT-SPECIFIER> is the
   default fragment specifier for video/*.

3.4.6 Octet Fragment Specifier

   In general, long-lived fragment specifiers seek to avoid schemes
   that depend on the underlying data representation because of low
   generality and high probably of future failure when the data
   representation is obsolesced by future developments.  The byte
   fragment scheme is provided as short-term solution that SHOULD be
   superseded by defining a new fragment specifier. In any event, byte
   fragments provide a fallback scheme for use until a new extension
   can be introduced.

   The content token for <BYTE-FRAGMENT-SPECIFIER> is "byte". The
   fragment includes <START-BYTE> and all intervening bytes upto
   <END-BYTE> which is excluded from the fragment reference.


        <BYTE-FRAGMENT-SPECIFIER> = "#" "byte" "=" start-byte "," end-byte

        <START-BYTE> = digits

        <END-BYTE> = digits

   The fragment PDI below refers to the byte sequence starting with byte
   23 and continuing upto but excluding byte 57.

        pdi://documentation.adobe.co.us/1997/09/30/1234.pdf#byte=23,57

   These byte indices are compatible with byte ranges used in HTTP 1.1
   [9].

3.5 Fragment Citation

3.5.1 Motivation

   Once fragments can be specified, documents can move from a
   cut-and-paste model to an inline reference model, where the
   fragment is served from an origin site.  Composite documents are
   those that combine fragments using inline references. One reason
   for preferring inline fragment references to cut-and-paste is that
   the etiology of the fragment is preserved. Thus, meta-data such as
   digital signatures can be carried forward and a document consumer
   can easily follow references back to sources to examine original
   contexts.

   An example might be citing some sentences from Presidential policy
   speech in a decision memorandum. Authenticity can be checked
   because the original document and its digital signature are
   available.  But, what if the citation was out of context?  Someone
   else could use the citation syntax to refer to the citation of a
   fragment by the composite document and assert that the fragment
   citation was out of context as it built an argument against the
   logic of the decision memorandum.

3.5.2 Discussion

   Reference of a fragment as cited in a composite document is
   accomplished by using a position specifier to give the
   <ORIGIN-POSITION> in the composite document. The cited fragment
   begins at the origin position and continues for the full extent of
   the fragment. Thus, <ORIGIN-POSITION> provides the alignment in the
   citing document while the dimensions or extent is carried by the
   fragment reference.  By keeping knowledge of the dimensions of the
   fragment out of the coordinate framework of the composite document,
   any position scheme can use the same generic citation syntax.

   The origin position is defined as the point closest to the start of
   the document. In a media type structured as a single sequence of
   characters, the origin position is character 0.  In a three
   dimensional cartesian coordinate systems, the origin position is
   0,0,0. When each content type token is made available for fragment
   citation, the origin position MUST be defined.

   The following identifier

   pdi://oma.eop.gov.us/1997/11/03/4.text.1@103=pdi://oma.eop.gov.us/1997/09/01/1.text.1#37,51

   refers to the citation of the fragment

        pdi://oma.eop.gov.us/1997/09/01/1.text.1#37,51

   by the document,

        pdi://oma.eop.gov.us/1997/11/03/4.text.1



   The citing document PDI uses the fragment text from character 37 to
   51 starting from character 103. If the fragment PDI had no fragment
   specifier, the entire document would appear starting at position 103.

3.6 Operations on PDIs

   The three classes of operations on PDIs have slightly different
   characteristics.

3.6.1 Minting

   When PDIs are minted, they MUST carry a format and a version number
   and they MUST NOT contain any wildcards. This ensures that the
   identifiers associated with digital resources are fully specified
   and convey both the media type and the version number. The presence
   of a version number makes it possible to check for a higher version
   of the resource.  Together, the format and version number enable
   fragment citation.

3.6.2 Binding

   Once minted, a PDI can be bound to directly to a resource or
   indirectly via a Uniform Resource Indicator (URI) [2], which may
   often be a URL. Binding to a resource commits the PDI to a specific
   sequence of bytes. Therefore, a URI that is indirectly bound to a
   PDI MUST NOT change. If the URI changes, the indirect binding MUST
   be broken, and the original machine representation associated
   directly with the PDI.

3.6.3 Resolution

   PDIs may be resolved to URLs, or other locators using recent URN
   resolution standards, such as THTTP described by RFC 2169 [10] and
   these resolvers may be discovered using the DNS extensions for
   Naming Authority PoinTeR (NAPTR) described by RFC 2168 [8].  As
   these experimental resolution standards evolve, or new ones are
   introduced, PDI resolution can track any new standards precisely
   because a URN namespace is independent of the method used to resolve
   them.

   When requesting a PDI from a URN resolver, the omission of a
   version number is a request for the resolver to return to the
   highest version available for the PDI. When defaulting a PDI to the
   highest version, the resolver MUST indicate to the client the fully
   qualified PDI associated with the media object.  For THTTP, when a
   server returns an entity, the server MUST include a content
   location header [9] containing the fully-qualified PDI.  This
   allows the client to associate the entity body with the versioned
   PDI that specifically identifies it.

         When submitting a PDI to a URN resolver, wildcards may be used
   to obtain information for sets of PDIs. However, the set of returned
   PDIs MAY be complete only with regard to the specific knowledge about
   a document series available to a resolver at the time.

3.6.4 Lexical Equivalence

   PDIs can be lexically compared for equivalence after they are
   converted to canonical form using the following procedure:

        1.Unescape all escaped characters that are within <URN-CHARS> but which
        are not <RESERVED-CHARACTERS>.

        2. Downcase the two <HEX> characters following the escape character "%".

        3. Downcase all PDI components except <UNIQUE-ID> and <POSITION>.

        4. If it is an encapsulated identifier, canonicalize
        <UNIQUE-ID> according the rules for the foreign identifier.

        5. If <POSITION> is case-insensitive, as indicated by <FRAGMENT-SCHEME>,
        downcase position.

   Wildcards carry a semantic interpretation that is not relevant for
   lexical equivalence. Two PDIs are lexically equal if and only if any
   wildcards appear in exactly the same positions in both.

3.6.5 Assertions

   With the advent of URN standards, networked assertion infrastructures
   can now associate assertions (meta-data) with the unique identifier
   of a resource rather than replicating that information with every
   instance of a resource and creating a variety of synchronization
   problems.  On this view, each URN namespace may also become an
   assertion domain with specific semantics.

   A document series thus becomes an address space in which each PDI
   serves as a pointer. Assertions about PDIs are assertions about the
   digital objects or fragments to which they refer. The ability to make
   and retrieve assertions about PDIs provides a means to associate
   meta-data with digital objects.  For example, collaboration systems
   may use a typed link semantics to structure resources in meaningful
   ways.  Alternatively, security systems may assert digital signatures
   or other trust information about PDIs. For example, a digital
   signature may be attached to some mobile code to check its integrity
   regardless of its proximate source. Access control systems might even
   assert differential access to various components of a single digital
   object.

   Several groups are developing standards for associating meta-data
   with resources [11] [16]. These approaches are currently evolving and
   as yet lack a suitable persistent identifier model.  URNs [17] [19]
   [20] and specifically PDIs offer a suitable persistent identifier for
   use with assertion schemes.  The ability to refer to tokens and
   relations as first-class objects will dramatically simplify equality
   testing and significantly enhance the power and flexibility of the
   emerging standards for wide-area assertion infrastructures.

3.7 Registering New Fragment Specification Schemes

   [TBD: This section will provide rules for registering new fragment
   specification schemes with IANA.]

3.8 Interpreting PDIs as Uniform Resource Locators

   Current URN resolver discovery [8] and URN resolution [7] standards
   are experimental and lack wide deployment.  As these standards
   evolve and become more wide spread, an interim resolution strategy
   using existing servers and clients for HTTP may prove useful.  This
   section defines use of PDIs as URLs [1] with standard HTTP servers.

   PDIs MAY be interpreted as Uniform Resource Locators (URL) and MAY
   be used in contexts where URLs are appropriate, such as with HTTP
   servers. When interpreting PDIs as URLs, PDIs do not carry URN
   prefix.

                <URL> = pdi             ; Encoding in URL syntax

   In all other ways, the syntax and semantics of PDIs remains exactly
   the same as under the URN namespace interpretation. However,
   resolver discovery and resolution under the URL interpretation are
   somewhat different.

3.8.1 Resolver Discovery

   While an appropriate resolver for a PDI document series SHOULD be
   found using current standards [8], an HTTP resolver MAY also be
   discovered heuristically by interpreting the document series as a
   domain name and looking up an IP address associated with the name.
   If a PDI-aware HTTP server is operating at the IP address and it
   successfully answers HTTP requests on the document series, then
   assume that a resolver for the document series has been located.

   A client MAY also use new resolver discovery standards as they
   emerge or out of band methods to locate a resolver for a document
   series.

   Since the heuristic discovery method provides no indication
   concerning the completeness or authority of the resolver, server
   operators SHOULD ensure that any server providing PDI resolution
   has complete knowledge of the document series, whether served
   locally or proxied from remote servers.  Thus, if a server can
   resolve one PDI in a document series, the server operator
   guarantees the assumption that the server has sufficient knowledge
   to resolve any PDI in the series. An HTTP 1.1 or higher client MAY
   check whether an HTTP server resolves a PDI document series by
   issuing a HTTP request using the OPTIONS method on the PDI.

3.8.2 Resolution Methods

   Since the HTTP standard [9] provides for use of any URI [2] in HTTP
   requests, no immediate extensions to the HTTP standard are required
   for PDI resolution.  Requests for PDIs are just like requests for
   URLs, except that there are no relative PDIs; the scheme and
   document series MUST always be provided.  Fully-specified PDIs
   allow the server to distinguish PDIs from ordinary URLs using the
   HTTP scheme. Servers SHOULD invoke augmented parsing for PDIs, for
   example, as necessary for fragment resolution.

        <HTTP-REQUEST-LINE> = <method> " " <pdi> " " <http-version>
                              <crlf>

   HTTP provides a series of methods on URIs. Below we define the
   operations for each method in HTTP 1.1 with respect to PDIs.

        GET Resolves the PDI and returns the resource.

        HEAD Returns the meta-data of the PDI as headers.

        OPTIONS Returns the HTTP operations supported for the PDI.

        TRACE returns information on the path to the origin server
        through proxies.

   Non-idempotent HTTP methods interact with PDI semantics and require
   special handling.

        PUT associates a resource with a PDI. If the PDI already
        exists, the server MUST increment the PDI version number and
        store the resource under this new version. If the PDI does not
        exist, the server SHOULD return 404 "Not Found". If the client
        wishes to assign a new PDI, the PUT request MUST indicate the
        document series by providing a partial PDI:

        <DOCUMENT-SERIES-IDENTIFIER> = "pdi://" document-series "/"

        When a server receives a <document-series-identifier> as the
        URI in a PUT method, it MUST assign a unique PDI within the
        document series using the current <ISO-DATE>, a daily
        <UNIQUE-ID>, an appropriate <FORMAT>, and a <VERSION> equal to
        1.

        DELETE is not defined for PDIs as they are long-lived,
        persistent identifiers. An HTTP server MUST return 405 "Method
        Not Allowed".

   When an HTTP method is applied to an unknown PDI, the server MUST
   return 404 "Not Found."

   For all HTTP methods, whenever the server is unable to apply the
   method to an existing resource or to assign a new PDI, it MUST
   return 405 "Method Not Allowed."

3.8.3 Proxying HTTP Resolution

   When a server is proxying PDI operations to an upstream HTTP
   server, it MUST pass through all requests and responses.  The
   server contributes its knowledge of an origin server that can
   resolve the PDI.  A server unable or not wishing to proxy PDI
   operations but aware of a server capable of handling the operations
   SHOULD redirect the client to the PDI-capable server.

3.8.4 Proxying THTTP Resolution

   When the upstream server implements URN resolution, the proxy
   SHOULD perform protocol translation. For THTTP [7], the server
   SHOULD perform the following request translations.

                Request         Proxy Request

                GET <PDI>       GET "/uri-res/N2R?urn:" <PDI>

                HEAD <PDI>      GET "/uri-res/N2C?urn:" <PDI>

   Responses from the THTTP resolver SHOULD be passed through.  For
   HTTP methods other than GET and HEAD, the server MUST return a 405
   "Method Not Allowed"

4. History

   Persistent Document Identifiers (PDI) were developed in early 1994 in
   order to provide persistent, location-independent identifiers for
   electronic publications. PDIs were deployed in Fall, 1994 when the
   second White House Electronic Publications System [21] was brought
   online.  Every document published by the system since January 20,
   1993 now carries a PDI.  An identifier that was independent of
   protocol and transport proved extremely useful in managing this
   document set and resolving delivery failures. The publications server
   currently issues PDIs and resolves them using THTTP URN resolution
   [7].

   The White House publications are an excellent example of documents
   that are monotonic (not subject to revision), widely mirrored, and
   subject to eventual relocation.  Documents are never revised after
   they issue.  Instead, they may be superseded by a corrected versions,
   but corrections are limited to transcription errors.  Many sites
   around the world archive and redistribute the documents.  These
   include major online services, libraries, advocacy groups, government
   entities.  As of March 1996, it was estimated that about one million
   people around the world read at least some part of a document during
   the course of a week.  At the end of an administration, the White
   House ceases to serve a former President's documents and they must be
   relocated to the National Archives, and normally, to his Presidential
   library.  In sum, the White House documents are mirrored in many
   locations from which they may be obtained and the primary document
   repository must move after a period of time.

   Persistent Document Identifiers were also used in an advanced
   experiment in large-scale, asynchronous collaboration during the Vice
   President's Open Meeting on Government Reinvention in December 1994.
   [12] In the Open Meeting, PDIs not only identified resources but they
   also associated a collaboration semantics with resources. A variety
   of meta-data and annotations were attached to resources via PDIs.
   More generally, PDIs were used to build the persistent semantic
   network around resources that allowed arbitrary assertions using
   first-class links, each with their own PDIs. Both the document
   database and the semantic network were mirrored at another site using
   PDIs to align all structures.

5. Acknowledgments

   This specification was improved by comments from Andrew J.
   Blumberg, Mitchell N. Charity, Ron Daniel jr., Henrik Frystyk
   Nielsen, Jerry Saltzar, Karen R.  Sollins, Christopher R.  Vincent.
   This specification was revised and extended from an earlier draft
   dated December, 1994.

   This specification describes research done at the Artificial
   Intelligence Laboratory of the Massachusetts Institute of
   Technology.  Support for the M.I.T. Artificial Intelligence
   Laboratory's artificial intelligence research is provided in part
   by the Defense Advanced Research Projects Agency of the Department
   of Defense under contract numbers MDA972-93-1-003N7 and
   F30602-97-2-0239.

6. References

   [1] T. Berners-Lee, L. Masinter, M. McCahill, ``Uniform Resource
   Locators (URL)'', RFC 1738, December, 1994.
   http://ds.internic.net/rfc/rfc1738.txt

   [2] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
   Identifiers (URI): Generic Syntax and Semantics", Internet Draft
   (work in progress), November 5, 1997.

   [3] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
   Extensions) Part One: Mechanisms for Specifying and Describing the
   Format of Internet Message Bodies", RFC 1521, September 1993.
   http://ds.internic.net/rfc/rfc1521.txt

   [4] T. Bray, J. Paoli, C. M. Sperberg-McQueen, ``Extensible Markup
   Language (XML),'' World Wide Web Consortium, August, 1997,
   http://www.w3.org/TR/WD-xml

   [5] T. Bray, S. DeRose, ``Extensible Markup Language (XML): Part
   2. Linking,'' World Wide Web Consortium, July, 1997.
   http://www.w3.org/TR/WD-xml-link

   [6] D. Crocker, P. Overell, "Augmented BNF for Syntax
   Specifications: ABNF," Internet Draft (work in progress), January
   1997.

   [7] R. Daniel, "A Trivial Convention for using HTTP in URN
   Resolution," RFC 2169, June, 1997.
   http://ds.internic.net/rfc/rfc2169.txt

   [8] R. Daniel, M. Mealling, "Resolution of Uniform Resource
   Identifiers using the Domain Name System," RFC 2168, June, 1997.
   http://ds.internic.net/rfc/rfc2168.txt

   [9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
   "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068, January, 1997.
   http://ds.internic.net/rfc/rfc2068.txt

   [10] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail
   Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
   November, 1996.  http://ds.internic.net/rfc/rfc2048.txt
   Registered media types can be found at:
   ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

   [11] R. V. Guha, T. Bray, "Meta Content Framework Using XML," W3C
   Technical Note NOTE-MCF-XML, June, 1997.

   [12] R. Hurwitz, J. C. Mallery, ``The Open Meeting: A Web-Based
   System for Conferencing and Collaboration,'' Proceedings of The
   Fourth International Conference on The World-Wide Web, December 12,
   1995. Also in Web Journal, Winter, 1996, 1(1): 17-36.

   [13] ISO 3166:1988 (E/F) - Codes for the representation of names of
   countries - The International Organization for Standardization, 3rd
   edition, 1988-08-15. ISO 3166 country codes can be found at:
   ftp://ftp.isi.edu/in-notes/iana/assignments/country-codes

   [14] ISO 8879 Information Processing -- Text and Office Systems --
   Standard Generalized Markup Language (SGML), ISO 8879:1986.  For
   the list of SGML entities, consult
   ftp://ftp.ifi.uio.no/pub/SGML/ENTITIES/.

   [15] ISO-8859. International Standard -- Information Processing --
     8-bit Single Byte Coded Graphic Character Sets --
     Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
     Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
     Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
     Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
     Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
     Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
     Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
     Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
     Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

   [16] O. Lassila, R. R. Swick, "Resource Description Framework
   (RDF): Model and Syntax," World Wide Web Consortium, Technical Note
   RDF-Syntax (work in progress), August, 1997.

   [17] R. Moats, "URN Syntax," RFC 2141, May 5, 1997.
   http://ds.internic.net/rfc/rfc2141.txt

   [18] J. Reynolds & J. Postel, ``Assigned Numbers,'' STD 2, RFC 1700,
   October, 1994.

   [19] K. Sollins, "Architectural Principles of Uniform Resource Name
   Resolution," Internet Draft (work in progress), July, 1997.

   [20] K. Sollins, L. Masinter, "Functional Requirements for Uniform
   Resource Names," RFC 1737, December, 1994.
   http://ds.internic.net/rfc/rfc1737.txt

   [21] White House Electronic Publications System,
   http://www.pub.whitehouse.gov

6. Author's Address

   John C. Mallery
   Artificial Intelligence Laboratory
   Massachusetts Institute of Technology
   545 Technology Square, NE43-797
   Cambridge, MA 02139 USA
   Email: JCMa@ai.mit.edu
   Phone: 617-253-5966