TOC 
Network Working GroupJ. Snell
Internet-DraftMay 17, 2010
Updates: 4287 (if approved) 
Intended status: Informational 
Expires: November 18, 2010 


Atom Link Extensions
draft-snell-atompub-link-extensions-05.txt

Abstract

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.

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). 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 November 18, 2010.

Copyright Notice

Copyright (c) 2010 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.



Table of Contents

1.  Introduction
2.  Notational Conventions
3.  Hash Attributes
    3.1.  Computing Hash Digests
    3.2.  The 'hash' attributes
4.  The 'etag' attribute
5.  The 'modified' attribute
6.  The 'media' attribute
7.  Security Considerations
8.  IANA Considerations
9.  Normative References
§  Author's Address




 TOC 

1.  Introduction

This specification adds additional attribute to the Atom Syndication Format [RFC4287] (Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” December 2005.) link and content elements that may be used to express additional metadata about linked resources.



 TOC 

2.  Notational Conventions

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.)

This specification uses XML Namespaces [W3C.REC‑xml‑names‑19990114] (Hollander, D., Layman, A., and T. Bray, “Namespaces in XML,” January 1999.) to uniquely identify XML element names. It uses the following namespace prefix for the indicated namespace URI;

 "atom": "http://www.w3.org/2005/Atom"


 TOC 

3.  Hash Attributes



 TOC 

3.1.  Computing Hash Digests

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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.).

It should be noted, however, that there are a variety of factors that influence whether the entity-body returned by the HTTP GET will yield a hash digest value matching that specified by a hash attribute contained by the atom:link or atom:content elements. Accordingly, hash attribute values MUST be considered to be strictly advisory and cannot be used reliably as an end-to-end integrity check.



 TOC 

3.2.  The 'hash' attributes

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-value = token ":" 1*HEXDIG
  digest-list = digest-value *( LWSP digest-value )

An example MD5 and SHA-256 digests 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.



 TOC 

4.  The 'etag' attribute

The 'etag' Attribute specifies an Entity Tag [RFC2616] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) for the resource identified by the atom:link or atom:content element. The 'etag' attribute MAY appear as a child of the atom:link and atom: content elements.

  etag = attribute le:etag { entity-tag }

  entity-tag = [ weak ] opaque-tag
  weak       = "W/"
  opaque-tag = quoted-string

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 &quot; entity reference to escape the double quotes within the etag value, e.g. etag="W/&quot;xyzzy&quot;". A strong entity tag would be encoded as either etag='"xyzzy"' or etag="&quot;xyzzy&quot;".



 TOC 

5.  The 'modified' attribute

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] (Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” July 2002.). 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" />


 TOC 

6.  The 'media' attribute

The 'media' attribute identifies the optimum media for the resource identified by the atom:link/@href attribute. The value MUST be a valid media query as specified by the Media Queries Specification [TODO: Link]. The media attribute MUST be considered to be purely advisory and identifies for which type of media the resource in question was designed. The 'media' attribute MAY appear as a child of the atom:link element.

  media = attribute media { media-query }

An example media attribute on an atom:link element:

  <atom:link rel="alternate"
    href="http://example.org/media/index.html"
    media="handheld and (min-width: 20em)" />


 TOC 

7.  Security Considerations

TBD



 TOC 

8.  IANA Considerations

No IANA actions are required by this document.



 TOC 

9. Normative References

[RFC1864] Myers, J. and M. Rose, “The Content-MD5 Header Field,” RFC 1864, October 1995 (TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[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 (TXT, PS, PDF, HTML, XML).
[RFC3339] Klyne, G., Ed. and C. Newman, “Date and Time on the Internet: Timestamps,” RFC 3339, July 2002 (TXT, HTML, XML).
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., “The Atom Syndication Format,” RFC 4287, December 2005 (TXT, HTML, XML).
[W3C.REC-xml-names-19990114] Hollander, D., Layman, A., and T. Bray, “Namespaces in XML,” World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999 (HTML).


 TOC 

Author's Address

  James M Snell
 
Phone: 
Email:  jasnell@us.ibm.com
URI:  http://ibm.com