idnits 2.17.1 draft-snell-atompub-link-extensions-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4287, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC4287, updated by this document, for RFC5378 checks: 2004-07-09) -- 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.) -- The document date (June 8, 2010) is 5071 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1864' is defined on line 254, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Snell 3 Internet-Draft June 8, 2010 4 Updates: 4287 (if approved) 5 Intended status: Informational 6 Expires: December 10, 2010 8 Atom Link Extensions 9 draft-snell-atompub-link-extensions-06.txt 11 Abstract 13 This specification adds additional attributes to the Atom Syndication 14 Format link and content elements that may be used to express 15 additional metadata about linked resources. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 10, 2010. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 53 3. Hash Attributes . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Computing Hash Digests . . . . . . . . . . . . . . . . . . 3 55 3.2. The 'hash' attributes . . . . . . . . . . . . . . . . . . . 3 56 4. The 'etag' attribute . . . . . . . . . . . . . . . . . . . . . 4 57 5. The 'modified' attribute . . . . . . . . . . . . . . . . . . . 5 58 6. The 'accessed' attribute . . . . . . . . . . . . . . . . . . . 5 59 7. The 'media' attribute . . . . . . . . . . . . . . . . . . . . . 5 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 10. Normative References . . . . . . . . . . . . . . . . . . . . . 7 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 This specification adds additional attribute to the Atom Syndication 68 Format [RFC4287] link and content elements that may be used to 69 express additional metadata about linked resources. 71 2. Notational Conventions 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in BCP 14, [RFC2119] 77 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 78 to uniquely identify XML element names. It uses the following 79 namespace prefix for the indicated namespace URI; 81 "atom": "http://www.w3.org/2005/Atom" 83 3. Hash Attributes 85 3.1. Computing Hash Digests 87 When the resource referenced by atom:link or atom:content elements is 88 retrievable using HTTP, hash digest values are computed by first 89 performing an HTTP GET request on the URL specified by the @href or 90 @src attributes, extracting the returned entity-body, then following 91 the steps specified in Section 14.15 of [RFC2616]. 93 It should be noted, however, that there are a variety of factors that 94 influence whether the entity-body returned by the HTTP GET will yield 95 a hash digest value matching that specified by a hash attribute 96 contained by the atom:link or atom:content elements. Accordingly, 97 hash attribute values MUST be considered to be strictly advisory and 98 cannot be used reliably as an end-to-end integrity check. 100 3.2. The 'hash' attributes 102 The 'hash' Attribute specifies a whitespace-delimited list of hash 103 digest values calculated over the resource identified by the atom: 104 link/@href or atom:content/@src attributes. Each digest value is 105 represented as a token identifying the hash algorithm and the hex- 106 encoded digest separated by an ASCII colon (":"). The 'hash' 107 attribute MAY appear as a child of the atom:link and atom:content 108 elements. 110 hash = attribute hash { digest-list } 111 digest-value = token ":" 1*HEXDIG 112 digest-list = digest-value *( LWSP digest-value ) 114 An example MD5 and SHA-256 digests of an enclosed MP3 file: 116 121 This specification defines the following hash algorithm tokens: 122 "md2", "md5", "sha-1", "sha-224", "sha-256", "sha-384", and "sha- 123 512". Additional hash algorithms MAY be used. 125 4. The 'etag' attribute 127 The 'etag' Attribute specifies an Entity Tag [RFC2616] for the 128 resource identified by the atom:link or atom:content element as 129 provided by the server hosting the resource. The 'etag' attribute 130 MAY appear as a child of the atom:link and atom:content elements. 132 etag = attribute le:etag { entity-tag } 134 entity-tag = [ weak ] opaque-tag 135 weak = "W/" 136 opaque-tag = quoted-string 138 An example weak entity tag for an enclosed MP3 file: 140 144 Note that HTTP defines the Entity Tag production such that quotes are 145 significant. For example, the values "W/xyzzy" and W/"xyzzy" 146 represent two distinctly different Entity Tags, the former being 147 considered a "strong" entity tag, the latter a "weak" entity tag. 148 The etag attribute value MUST include the appropriate double 149 quotation marks. 151 The presence and placement of the quotes in the entity tag value can 152 introduce some difficulty when inserting the value into the etag 153 attribute. Producers of Atom documents must either use single quotes 154 when specifying the value of the etag attribute, e.g. 155 etag='W/"xyzzy"' or use the " entity reference to escape the 156 double quotes within the etag value, e.g. etag="W/"xyzzy"". 158 A strong entity tag would be encoded as either etag='"xyzzy"' or 159 etag=""xyzzy"". 161 5. The 'modified' attribute 163 The 'modified' Attribute specifies the date and time when the 164 resource identified by the atom:link or atom:content element was last 165 modified. The value MUST conform to the "date-time" production 166 defined by [RFC3339]. An uppercase "T" character MUST be used to 167 separate date and time, and an uppercase "Z" character MUST be 168 present in the absence of a numeric time zone offset. The 'modified' 169 attribute MAY appear as a child of the atom:link and atom:content 170 elements. 172 modified = attribute modified { xsd:dateTime } 174 An example last-modified attribute for an enclosed MP3 file: 176 180 6. The 'accessed' attribute 182 The 'accessed' Attribute specifies the most recent date and time when 183 the resource identified by the atom:link or atom:content element was 184 accessed. The value MUST conform to the "date-time" production 185 defined by [RFC3339]. An uppercase "T" character MUST be used to 186 separate date and time, and an uppercase "Z" character MUST be 187 present in the absence of a numeric time zone offset. The 'accessed' 188 attribute MAY appear as a child of the atom:link and atom:content 189 elements. 191 accessed = attribute accessed { xsd:dateTime } 193 An example accessed attribute for an enclosed MP3 file: 195 199 7. The 'media' attribute 201 The 'media' attribute identifies the optimum media for the resource 202 identified by the atom:link/@href attribute. The value MUST be a 203 valid media query as specified by the Media Queries Specification 204 [W3C.CR-css3-mediaqueries-20090915]. The media attribute MUST be 205 considered to be purely advisory and identifies for which type of 206 media the resource in question was designed. The 'media' attribute 207 MAY appear as a child of the atom:link element. 209 media = attribute media { media-query } 211 An example media attribute on an atom:link element: 213 217 Section 4.1.2 of the Atom specification [RFC4287] limits the ability 218 for an atom:entry to contain multiple atom:link elements with a rel 219 attribute value of "alternate". Specifically, the specification 220 states that an atom:entry "MUST NOT contain more than one atom:link 221 element with a rel attribute value of "alternate" that has the same 222 combination of type and hreflang attribute values." This restriction 223 limits the ability of an Atom document publisher to provide multiple 224 media-targeted alternate links of the same content type. Each 225 alternate link MUST specify a different media type or language. 226 Other types of links do not share the same limitation. 228 8. Security Considerations 230 The 'hash', 'etag' and 'modified' attributes are intended to allow an 231 Atom publisher the means of describing the state of a linked resource 232 at a point-in-time -- usually at the moment specified by the 233 'accessed' attribute or at the moment the atom:link or atom:content 234 element was created. An Atom consumer that is aware of these 235 attributes can use their values as an integrity check to determine if 236 the linked resource has been modified since the attribute values were 237 established by the publisher. 239 The 'hash' attribute is intended for use when the publisher of an 240 Atom document requires the ability to link to a specific version of a 241 resource that is expected to remain stable and unchanged for a useful 242 period of time. If publishers fall into the habit of regularly 243 including hash digests for resources whose states change frequently, 244 there is a danger that consumers of feeds containing large numbers of 245 invalid digests will simply begin to ignore them and completely 246 undermine the utility of the attribute. 248 9. IANA Considerations 250 No IANA actions are required by this document. 252 10. Normative References 254 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 255 RFC 1864, October 1995. 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 261 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 262 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 264 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 265 Internet: Timestamps", RFC 3339, July 2002. 267 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 268 Syndication Format", RFC 4287, December 2005. 270 [W3C.CR-css3-mediaqueries-20090915] 271 Celik, T., Glazman, D., Lie, H., and A. Kesteren, "Media 272 Queries", World Wide Web Consortium CR CR-css3- 273 mediaqueries-20090915, September 2009, 274 . 276 [W3C.REC-xml-names-19990114] 277 Hollander, D., Layman, A., and T. Bray, "Namespaces in 278 XML", World Wide Web Consortium FirstEdition REC-xml- 279 names-19990114, January 1999, 280 . 282 Author's Address 284 James M Snell 286 Phone: 287 Email: jasnell@us.ibm.com 288 URI: http://ibm.com