idnits 2.17.1
draft-snell-atompub-link-extensions-05.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 (May 17, 2010) is 5086 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC1864' is defined on line 207, 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 May 17, 2010
4 Updates: 4287 (if approved)
5 Intended status: Informational
6 Expires: November 18, 2010
8 Atom Link Extensions
9 draft-snell-atompub-link-extensions-05.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 November 18, 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 'media' attribute . . . . . . . . . . . . . . . . . . . . . 5
59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
61 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6
62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 3.1. Computing Hash Digests
86 When the resource referenced by atom:link or atom:content elements is
87 retrievable using HTTP, hash digest values are computed by first
88 performing an HTTP GET request on the URL specified by the @href or
89 @src attributes, extracting the returned entity-body, then following
90 the steps specified in Section 14.15 of [RFC2616].
92 It should be noted, however, that there are a variety of factors that
93 influence whether the entity-body returned by the HTTP GET will yield
94 a hash digest value matching that specified by a hash attribute
95 contained by the atom:link or atom:content elements. Accordingly,
96 hash attribute values MUST be considered to be strictly advisory and
97 cannot be used reliably as an end-to-end integrity check.
99 3.2. The 'hash' attributes
101 The 'hash' Attribute specifies a whitespace-delimited list of hash
102 digest values calculated over the resource identified by the atom:
103 link/@href or atom:content/@src attributes. Each digest value is
104 represented as a token identifying the hash algorithm and the hex-
105 encoded digest separated by an ASCII colon (":"). The 'hash'
106 attribute MAY appear as a child of the atom:link and atom:content
107 elements.
109 hash = attribute hash { digest-list }
110 digest-value = token ":" 1*HEXDIG
111 digest-list = digest-value *( LWSP digest-value )
113 An example MD5 and SHA-256 digests of an enclosed MP3 file:
115
120 This specification defines the following hash algorithm tokens:
121 "md2", "md5", "sha-1", "sha-224", "sha-256", "sha-384", and "sha-
122 512". Additional hash algorithms MAY be used.
124 4. The 'etag' attribute
126 The 'etag' Attribute specifies an Entity Tag [RFC2616] for the
127 resource identified by the atom:link or atom:content element. The
128 'etag' attribute MAY appear as a child of the atom:link and atom:
129 content elements.
131 etag = attribute le:etag { entity-tag }
133 entity-tag = [ weak ] opaque-tag
134 weak = "W/"
135 opaque-tag = quoted-string
137 An example weak entity tag for an enclosed MP3 file:
139
143 Note that HTTP defines the Entity Tag production such that quotes are
144 significant. For example, the values "W/xyzzy" and W/"xyzzy"
145 represent two distinctly different Entity Tags, the former being
146 considered a "strong" entity tag, the latter a "weak" entity tag.
147 The etag attribute value MUST include the appropriate double
148 quotation marks.
150 The presence and placement of the quotes in the entity tag value can
151 introduce some difficulty when inserting the value into the etag
152 attribute. Producers of Atom documents must either use single quotes
153 when specifying the value of the etag attribute, e.g.
154 etag='W/"xyzzy"' or use the " entity reference to escape the
155 double quotes within the etag value, e.g. etag="W/"xyzzy"".
157 A strong entity tag would be encoded as either etag='"xyzzy"' or
158 etag=""xyzzy"".
160 5. The 'modified' attribute
162 The 'modified' Attribute specifies the date and time when the
163 resource identified by the atom:link or atom:content element was last
164 modified. The value MUST conform to the "date-time" production
165 defined by [RFC3339]. An uppercase "T" character MUST be used to
166 separate date and time, and an uppercase "Z" character MUST be
167 present in the absence of a numeric time zone offset. The 'modified'
168 attribute MAY appear as a child of the atom:link and atom:content
169 elements.
171 modified = attribute modified { xsd:dateTime }
173 An example last-modified attribute for an enclosed MP3 file:
175
179 6. The 'media' attribute
181 The 'media' attribute identifies the optimum media for the resource
182 identified by the atom:link/@href attribute. The value MUST be a
183 valid media query as specified by the Media Queries Specification
184 [TODO: Link]. The media attribute MUST be considered to be purely
185 advisory and identifies for which type of media the resource in
186 question was designed. The 'media' attribute MAY appear as a child
187 of the atom:link element.
189 media = attribute media { media-query }
191 An example media attribute on an atom:link element:
193
197 7. Security Considerations
199 TBD
201 8. IANA Considerations
203 No IANA actions are required by this document.
205 9. Normative References
207 [RFC1864] Myers, J. and M. Rose, "The Content-MD5 Header Field",
208 RFC 1864, October 1995.
210 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
211 Requirement Levels", BCP 14, RFC 2119, March 1997.
213 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
214 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
215 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
217 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
218 Internet: Timestamps", RFC 3339, July 2002.
220 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
221 Syndication Format", RFC 4287, December 2005.
223 [W3C.REC-xml-names-19990114]
224 Hollander, D., Layman, A., and T. Bray, "Namespaces in
225 XML", World Wide Web Consortium FirstEdition REC-xml-
226 names-19990114, January 1999,
227 .
229 Author's Address
231 James M Snell
233 Phone:
234 Email: jasnell@us.ibm.com
235 URI: http://ibm.com