idnits 2.17.1
draft-snell-atompub-link-extensions-07.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 30, 2010) is 5047 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC1864' is defined on line 282, 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 30, 2010
4 Updates: 4287 (if approved)
5 Intended status: Informational
6 Expires: January 1, 2011
8 Atom Link Extensions
9 draft-snell-atompub-link-extensions-07.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 January 1, 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. The 'media' attribute . . . . . . . . . . . . . . . . . . . . . 6
60 8. Link extension values and the 'atom:updated' element . . . . . 6
61 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
62 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
63 11. Normative References . . . . . . . . . . . . . . . . . . . . . 7
64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
66 1. Introduction
68 This specification adds additional attribute to the Atom Syndication
69 Format [RFC4287] link and content elements that may be used to
70 express additional metadata about linked resources.
72 2. Notational Conventions
74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
76 document are to be interpreted as described in BCP 14, [RFC2119]
78 This specification uses XML Namespaces [W3C.REC-xml-names-19990114]
79 to uniquely identify XML element names. It uses the following
80 namespace prefix for the indicated namespace URI;
82 "atom": "http://www.w3.org/2005/Atom"
84 3. Hash Attributes
86 Hash digest values are computed by the producers of Atom documents
87 and are representative of the state of linked resources at a given
88 point in time. The intent of providing hash values is to allow
89 consumers of the Atom document to later determine if linked resource
90 have been modified since the document was produced. There are,
91 however, many factors that determine whether a consumer of a document
92 will be capable of calculating a digest value identical to that
93 specified in a hash attribute. Accordingly, hash attribute values
94 MUST be considered to be strictly advisory. User agents SHOULD
95 notify users when matching hash digest values cannot be computed but
96 MUST NOT stop processing or signal an error.
98 3.1. Computing Hash Digests
100 When the resource referenced by atom:link or atom:content elements is
101 retrievable using HTTP, hash digest values are computed by first
102 performing an HTTP GET request on the URL specified by the @href or
103 @src attributes, extracting the returned entity-body, then following
104 the steps specified in Section 14.15 of [RFC2616].
106 3.2. The 'hash' attributes
108 The 'hash' Attribute specifies a whitespace-delimited list of hash
109 digest values calculated over the resource identified by the atom:
110 link/@href or atom:content/@src attributes. Each digest value is
111 represented as a token identifying the hash algorithm and the hex-
112 encoded digest separated by an ASCII colon (":"). The 'hash'
113 attribute MAY appear as a child of the atom:link and atom:content
114 elements.
116 hash = attribute hash { digest-list }
117 digest-list = digest-value *( LWSP digest-value )
118 digest-value = token ":" 1*HEXDIG
120 An example MD5 and SHA-256 digests of an enclosed MP3 file:
122
127 This specification defines the following hash algorithm tokens:
128 "md2", "md5", "sha-1", "sha-224", "sha-256", "sha-384", and "sha-
129 512". Additional hash algorithms MAY be used.
131 4. The 'etag' attribute
133 The 'etag' Attribute specifies an Entity Tag [RFC2616] for the
134 resource identified by the atom:link or atom:content element as
135 provided by the server hosting the resource. The 'etag' attribute
136 MAY appear as a child of the atom:link and atom:content elements.
138 etag = attribute etag { entity-tag }
140 entity-tag = [ weak ] opaque-tag
141 weak = "W/"
142 opaque-tag = quoted-string
143 quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
144 qdtext = >
145 quoted-pair = "\" CHAR
147 An example weak entity tag for an enclosed MP3 file:
149
153 Note that HTTP defines the Entity Tag production such that quotes are
154 significant. For example, the values "W/xyzzy" and W/"xyzzy"
155 represent two distinctly different Entity Tags, the former being
156 considered a "strong" entity tag, the latter a "weak" entity tag.
157 The etag attribute value MUST include the appropriate double
158 quotation marks.
160 The presence and placement of the quotes in the entity tag value can
161 introduce some difficulty when inserting the value into the etag
162 attribute. Producers of Atom documents must either use single quotes
163 when specifying the value of the etag attribute, e.g.
164 etag='W/"xyzzy"' or use the " entity reference to escape the
165 double quotes within the etag value, e.g. etag="W/"xyzzy"".
166 A strong entity tag would be encoded as either etag='"xyzzy"' or
167 etag=""xyzzy"".
169 5. The 'modified' attribute
171 The 'modified' Attribute specifies the date and time when the
172 resource identified by the atom:link or atom:content element was last
173 modified. The value MUST conform to the "date-time" production
174 defined by [RFC3339]. An uppercase "T" character MUST be used to
175 separate date and time, and an uppercase "Z" character MUST be
176 present in the absence of a numeric time zone offset. The 'modified'
177 attribute MAY appear as a child of the atom:link and atom:content
178 elements.
180 modified = attribute modified { xsd:dateTime }
182 An example last-modified attribute for an enclosed MP3 file:
184
188 6. The 'accessed' attribute
190 The 'accessed' Attribute specifies the most recent date and time when
191 the resource identified by the atom:link or atom:content element was
192 accessed by the producer of the Atom document. The value MUST
193 conform to the "date-time" production defined by [RFC3339]. An
194 uppercase "T" character MUST be used to separate date and time, and
195 an uppercase "Z" character MUST be present in the absence of a
196 numeric time zone offset. The 'accessed' attribute MAY appear as a
197 child of the atom:link and atom:content elements.
199 accessed = attribute accessed { xsd:dateTime }
201 An example accessed attribute for an enclosed MP3 file:
203
207 The intent of the 'accessed' attribute is to allow the Atom document
208 producer to establish an explicit point-in-time at which additional
209 metadata about the linked resource was established. For instance, if
210 the 'accessed' attribute is used, a consuming user agent can assume
211 that any hash attribute values, entity tags and modified timestamps
212 were valid at the date and time specified by the 'accessed'
213 attributes value. If the 'accessed' attribute is not specified,
214 consumers SHOULD use the value of the atom:updated element to
215 determine the point-in-time at which the link metadata was considered
216 to be valid.
218 7. The 'media' attribute
220 The 'media' attribute identifies the optimum media for the resource
221 identified by the atom:link/@href attribute. The value MUST be a
222 valid media query as specified by the Media Queries Specification
223 [W3C.CR-css3-mediaqueries-20090915]. The media attribute MUST be
224 considered to be purely advisory and identifies for which type of
225 media the resource in question was designed. The 'media' attribute
226 MAY appear as a child of the atom:link element.
228 media = attribute media { media-query }
230 An example media attribute on an atom:link element:
232
236 Section 4.1.2 of the Atom specification [RFC4287] limits the ability
237 for an atom:entry to contain multiple atom:link elements with a rel
238 attribute value of "alternate". Specifically, the specification
239 states that an atom:entry "MUST NOT contain more than one atom:link
240 element with a rel attribute value of "alternate" that has the same
241 combination of type and hreflang attribute values." This restriction
242 limits the ability of an Atom document publisher to provide multiple
243 media-targeted alternate links of the same content type. Each
244 alternate link MUST specify a different media type or language.
245 Other types of links do not share the same limitation.
247 8. Link extension values and the 'atom:updated' element
249 Changes in the values of the 'hash', 'etag', 'modified' and
250 'accessed' attributes MUST be considered by Atom document producers
251 to be "significant" changes as discussed in Section 4.2.15 of
252 [RFC4287] and MUST result in a change to the value of the 'atom:
254 updated' element.
256 9. Security Considerations
258 The 'hash', 'etag' and 'modified' attributes are intended to allow an
259 Atom publisher the means of describing the state of a linked resource
260 at a point-in-time -- usually at the moment specified by the
261 'accessed' attribute or at the moment specified by the atom:updated
262 element. An Atom consumer that is aware of these attributes can use
263 their values as an integrity check to determine if the linked
264 resource has been modified since the attribute values were
265 established by the publisher.
267 The 'hash' attribute is intended for use when the publisher of an
268 Atom document requires the ability to link to a specific version of a
269 resource that is expected to remain stable and unchanged for a useful
270 period of time. If publishers fall into the habit of regularly
271 including hash digests for resources whose states change frequently,
272 there is a danger that consumers of feeds containing large numbers of
273 invalid digests will simply begin to ignore them and completely
274 undermine the utility of the attribute.
276 10. IANA Considerations
278 No IANA actions are required by this document.
280 11. Normative References
282 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
283 RFC 1864, October 1995.
285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
286 Requirement Levels", BCP 14, RFC 2119, March 1997.
288 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
289 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
290 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
292 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
293 Internet: Timestamps", RFC 3339, July 2002.
295 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
296 Syndication Format", RFC 4287, December 2005.
298 [W3C.CR-css3-mediaqueries-20090915]
299 Celik, T., Glazman, D., Lie, H., and A. Kesteren, "Media
300 Queries", World Wide Web Consortium CR CR-css3-
301 mediaqueries-20090915, September 2009,
302 .
304 [W3C.REC-xml-names-19990114]
305 Hollander, D., Bray, T., and A. Layman, "Namespaces in
306 XML", World Wide Web Consortium FirstEdition REC-xml-
307 names-19990114, January 1999,
308 .
310 Author's Address
312 James M Snell
314 Phone:
315 Email: jasnell@us.ibm.com
316 URI: http://ibm.com