idnits 2.17.1 draft-snell-atompub-link-extensions-08.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 (November 9, 2010) is 4915 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1864' is defined on line 242, 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 November 9, 2010 4 Updates: 4287 (if approved) 5 Intended status: Informational 6 Expires: May 13, 2011 8 Atom Link Extensions 9 draft-snell-atompub-link-extensions-08.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 May 13, 2011. 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. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1. Introduction 66 This specification adds additional attribute to the Atom Syndication 67 Format [RFC4287] link and content elements that may be used to 68 express additional metadata about linked resources. 70 2. Notational Conventions 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in BCP 14, [RFC2119] 76 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 77 to uniquely identify XML element names. It uses the following 78 namespace prefix for the indicated namespace URI; 80 "atom": "http://www.w3.org/2005/Atom" 82 3. Hash Attributes 84 Hash digest values are computed by the producers of Atom documents 85 and are representative of the state of linked resources at a given 86 point in time. The intent of providing hash values is to allow 87 consumers of the Atom document to later determine if linked resource 88 have been modified since the document was produced. There are, 89 however, many factors that determine whether a consumer of a document 90 will be capable of calculating a digest value identical to that 91 specified in a hash attribute. Accordingly, hash attribute values 92 MUST be considered to be strictly advisory. User agents SHOULD 93 notify users when matching hash digest values cannot be computed but 94 MUST NOT stop processing or signal an error. 96 3.1. Computing Hash Digests 98 When the resource referenced by atom:link or atom:content elements is 99 retrievable using HTTP, hash digest values are computed by first 100 performing an HTTP GET request on the URL specified by the @href or 101 @src attributes, extracting the returned entity-body, then following 102 the steps specified in Section 14.15 of [RFC2616]. 104 3.2. The 'hash' attributes 106 The 'hash' Attribute specifies a whitespace-delimited list of hash 107 digest values calculated over the resource identified by the atom: 108 link/@href or atom:content/@src attributes. Each digest value is 109 represented as a token identifying the hash algorithm and the hex- 110 encoded digest separated by an ASCII colon (":"). The 'hash' 111 attribute MAY appear as a child of the atom:link and atom:content 112 elements. 114 hash = attribute hash { digest-list } 115 digest-list = digest-value *( LWSP digest-value ) 116 digest-value = token ":" 1*HEXDIG 118 An example MD5 and SHA-256 digest of an enclosed MP3 file: 120 125 This specification defines the following hash algorithm tokens: 126 "md2", "md5", "sha-1", "sha-224", "sha-256", "sha-384", and "sha- 127 512". Additional hash algorithms MAY be used. 129 4. The 'etag' attribute 131 The 'etag' Attribute specifies an Entity Tag [RFC2616] for the 132 resource identified by the atom:link or atom:content element as 133 provided by the server hosting the resource. The 'etag' attribute 134 MAY appear as a child of the atom:link and atom:content elements. 136 etag = attribute etag { entity-tag } 138 entity-tag = [ weak ] opaque-tag 139 weak = "W/" 140 opaque-tag = quoted-string 141 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> ) 142 qdtext = > 143 quoted-pair = "\" CHAR 145 An example weak entity tag for an enclosed MP3 file: 147 151 Note that HTTP defines the Entity Tag production such that quotes are 152 significant. For example, the values "W/xyzzy" and W/"xyzzy" 153 represent two distinctly different Entity Tags, the former being 154 considered a "strong" entity tag, the latter a "weak" entity tag. 155 The etag attribute value MUST include the appropriate double 156 quotation marks. 158 The presence and placement of the quotes in the entity tag value can 159 introduce some difficulty when inserting the value into the etag 160 attribute. Producers of Atom documents must either use single quotes 161 when specifying the value of the etag attribute, e.g. 162 etag='W/"xyzzy"' or use the " entity reference to escape the 163 double quotes within the etag value, e.g. etag="W/"xyzzy"". 164 A strong entity tag would be encoded as either etag='"xyzzy"' or 165 etag=""xyzzy"". 167 5. The 'modified' attribute 169 The 'modified' Attribute specifies the date and time when the 170 resource identified by the atom:link or atom:content element was last 171 modified. The value MUST conform to the "date-time" production 172 defined by [RFC3339]. An uppercase "T" character MUST be used to 173 separate date and time, and an uppercase "Z" character MUST be 174 present in the absence of a numeric time zone offset. The 'modified' 175 attribute MAY appear as a child of the atom:link and atom:content 176 elements. 178 modified = attribute modified { xsd:dateTime } 180 An example last-modified attribute for an enclosed MP3 file: 182 186 6. The 'accessed' attribute 188 The 'accessed' Attribute specifies the most recent date and time when 189 the resource identified by the atom:link or atom:content element was 190 accessed by the producer of the Atom document. The value MUST 191 conform to the "date-time" production defined by [RFC3339]. An 192 uppercase "T" character MUST be used to separate date and time, and 193 an uppercase "Z" character MUST be present in the absence of a 194 numeric time zone offset. The 'accessed' attribute MAY appear as a 195 child of the atom:link and atom:content elements. 197 accessed = attribute accessed { xsd:dateTime } 199 An example accessed attribute for an enclosed MP3 file: 201 205 The intent of the 'accessed' attribute is to allow the Atom document 206 producer to establish an explicit point-in-time at which additional 207 metadata about the linked resource was established. For instance, if 208 the 'accessed' attribute is used, a consuming user agent can assume 209 that any hash attribute values, entity tags and modified timestamps 210 were valid at the date and time specified by the 'accessed' 211 attributes value. If the 'accessed' attribute is not specified, 212 consumers SHOULD use the value of the atom:updated element to 213 determine the point-in-time at which the link metadata was considered 214 to be valid. 216 7. Security Considerations 218 The 'hash', 'etag' and 'modified' attributes are intended to allow an 219 Atom publisher the means of describing the state of a linked resource 220 at a point-in-time -- usually at the moment specified by the 221 'accessed' attribute or at the moment specified by the atom:updated 222 element. An Atom consumer that is aware of these attributes can use 223 their values as an integrity check to determine if the linked 224 resource has been modified since the attribute values were 225 established by the publisher. 227 The 'hash' attribute is intended for use when the publisher of an 228 Atom document requires the ability to link to a specific version of a 229 resource that is expected to remain stable and unchanged for a useful 230 period of time. If publishers fall into the habit of regularly 231 including hash digests for resources whose states change frequently, 232 there is a danger that consumers of feeds containing large numbers of 233 invalid digests will simply begin to ignore them and completely 234 undermine the utility of the attribute. 236 8. IANA Considerations 238 No IANA actions are required by this document. 240 9. Normative References 242 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field", 243 RFC 1864, October 1995. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, March 1997. 248 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 249 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 250 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 252 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the 253 Internet: Timestamps", RFC 3339, July 2002. 255 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 256 Syndication Format", RFC 4287, December 2005. 258 [W3C.REC-xml-names-19990114] 259 Bray, T., Hollander, D., and A. Layman, "Namespaces in 260 XML", World Wide Web Consortium FirstEdition REC-xml- 261 names-19990114, January 1999, 262 . 264 Author's Address 266 James M Snell 268 Phone: 269 Email: jasnell@us.ibm.com 270 URI: http://ibm.com