Network Working Group | J.M. Snell |
Internet-Draft | June 2012 |
Updates: 4287 (if approved) | |
Intended status: Standards Track | |
Expires: December 01, 2012 |
Atom Link Extensions
draft-snell-atompub-link-extensions-09
This specification adds additional attributes to the Atom Syndication Format link and content elements that may be used to express additional metadata about linked resources.
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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December 01, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This specification adds additional attribute to the Atom Syndication Format [RFC4287] link and content elements that may be used to express additional metadata about linked resources most specifically for the purpose of allowing a consuming application to detect whether a linked resource has potentially been modified since the link was established or whether the content of the linked resource has been correctly fetched as a result of dereferencing the link.
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 BCP 14, [RFC2119].
This specification uses XML Namespaces [W3C.REC-xml-names-19990114] to uniquely identify XML element names. It uses the following namespace prefix for the indicated namespace URI;
"atom": "http://www.w3.org/2005/Atom"
Hash digest values are computed by the producers of Atom documents and are representative of the state of linked resources at a given point in time. The intent of providing hash values is to allow consumers of the Atom document to later determine if linked resource have been modified since the document was produced. There are, however, many factors that determine whether a consumer of a document will be capable of calculating a digest value identical to that specified in a hash attribute. Accordingly, hash attribute values MUST be considered to be strictly advisory. User agents SHOULD notify users when matching hash digest values cannot be computed but MUST NOT stop processing or signal an error.
When the resource referenced by atom:link or atom:content elements is retrievable using HTTP, hash digest values are computed by first performing an HTTP GET request on the URL specified by the @href or @src attributes, extracting the returned entity-body, then following the steps specified in Section 14.15 of [RFC2616].
The 'hash' Attribute specifies a whitespace-delimited list of hash digest values calculated over the resource identified by the atom:link/@href or atom:content/@src attributes. Each digest value is represented as a token identifying the hash algorithm and the hex-encoded digest separated by an ASCII colon (":"). The 'hash' attribute MAY appear as a child of the atom:link and atom:content elements.
hash = attribute hash { digest-list } digest-list = digest-value *( LWSP digest-value ) digest-value = token ":" 1*HEXDIG
An example MD5 and SHA-256 digest of an enclosed MP3 file:
<atom:link rel="enclosure" href="http://example.org/media/myfile.mp3" hash="md5:9e107d9d372bb6826bd81d3542a419d6 sha-256:6bf05cbbde96d6...d5ffe91e29272d805c98b988dc" />
This specification defines the following hash algorithm tokens: "md2", "md5", "sha-1", "sha-224", "sha-256", "sha-384", and "sha-512". Additional hash algorithms MAY be used.
The 'etag' Attribute specifies an Entity Tag [RFC2616] for the resource identified by the atom:link or atom:content element as provided by the server hosting the resource. The 'etag' attribute MAY appear as a child of the atom:link and atom:content elements.
etag = attribute etag { entity-tag } entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) qdtext = <any TEXT except <">> quoted-pair = "\" CHAR
An example weak entity tag for an enclosed MP3 file:
<atom:link rel="enclosure" href="http://example.org/media/myfile.mp3" etag="W/"xyzzy"" />
Note that HTTP defines the Entity Tag production such that quotes are significant. For example, the values "W/xyzzy" and W/"xyzzy" represent two distinctly different Entity Tags, the former being considered a "strong" entity tag, the latter a "weak" entity tag. The etag attribute value MUST include the appropriate double quotation marks.
The presence and placement of the quotes in the entity tag value can introduce some difficulty when inserting the value into the etag attribute. Producers of Atom documents must either use single quotes when specifying the value of the etag attribute, e.g. etag='W/"xyzzy"' or use the " entity reference to escape the double quotes within the etag value, e.g. etag="W/"xyzzy"". A strong entity tag would be encoded as either etag='"xyzzy"' or etag=""xyzzy"".
The 'modified' Attribute specifies the date and time when the resource identified by the atom:link or atom:content element was last modified. The value MUST conform to the "date-time" production defined by [RFC3339]. An uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset. The 'modified' attribute MAY appear as a child of the atom:link and atom:content elements.
modified = attribute modified { xsd:dateTime }
An example last-modified attribute for an enclosed MP3 file:
<atom:link rel="enclosure" href="http://example.org/media/myfile.mp3" modified="2010-12-12T12:12:12Z" />
The 'accessed' Attribute specifies the most recent date and time when the resource identified by the atom:link or atom:content element was accessed by the producer of the Atom document. The value MUST conform to the "date-time" production defined by [RFC3339]. An uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset. The 'accessed' attribute MAY appear as a child of the atom:link and atom:content elements.
accessed = attribute accessed { xsd:dateTime }
An example accessed attribute for an enclosed MP3 file:
<atom:link rel="enclosure" href="http://example.org/media/myfile.mp3" accessed="2010-12-12T12:12:12Z" />
The intent of the 'accessed' attribute is to allow the Atom document producer to establish an explicit point-in-time at which additional metadata about the linked resource was established. For instance, if the 'accessed' attribute is used, a consuming user agent can assume that any hash attribute values, entity tags and modified timestamps were valid at the date and time specified by the 'accessed' attributes value. If the 'accessed' attribute is not specified, consumers SHOULD use the value of the atom:updated element to determine the point-in-time at which the link metadata was considered to be valid.
The 'hash', 'etag' and 'modified' attributes are intended to allow an Atom publisher the means of describing the state of a linked resource at a point-in-time -- usually at the moment specified by the 'accessed' attribute or at the moment specified by the atom:updated element. An Atom consumer that is aware of these attributes can use their values as an integrity check to determine if the linked resource has been modified since the attribute values were established by the publisher.
The 'hash' attribute is intended for use when the publisher of an Atom document requires the ability to link to a specific version of a resource that is expected to remain stable and unchanged for a useful period of time. If publishers fall into the habit of regularly including hash digests for resources whose states change frequently, there is a danger that consumers of feeds containing large numbers of invalid digests will simply begin to ignore them and completely undermine the utility of the attribute.
No IANA actions are required by this document.
[RFC1864] | Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC2616] | Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. |
[RFC3339] | Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. |
[RFC4287] | Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005. |
[W3C.REC-xml-names-19990114] | Hollander, D., Bray, T. and A. Layman, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999. |