idnits 2.17.1
draft-ietf-atompub-format-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** It looks like you're using RFC 3978 boilerplate. You should update this
to the boilerplate described in the IETF Trust License Policy document
(see https://trustee.ietf.org/license-info), which is required now.
-- Found old boilerplate from RFC 3667, Section 5.1 on line 16.
-- Found old boilerplate from RFC 3978, Section 5.5 on line 1262.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1239.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1246.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1252.
** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line
1268), which is fine, but *also* found old RFC 2026, Section 10.4C,
paragraph 1 text on line 38.
** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure
Acknowledgement -- however, there's a paragraph with a matching
beginning. Boilerplate error?
** This document has an original RFC 3978 Section 5.4 Copyright Line,
instead of the newer IETF Trust Copyright according to RFC 4748.
** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
of the newer disclaimer which includes the IETF Trust according to RFC
4748.
** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate
instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission
of drafts without verbatim RFC 3978 boilerplate is not accepted.
The following non-3978 patterns matched text found in the document.
That text should be removed or replaced:
By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
-- 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 (January 10, 2005) is 7046 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Non-RFC (?) normative reference: ref.
'Atom-autodiscovery'
-- Possible downref: Non-RFC (?) normative reference: ref. 'Atom-protocol'
** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986)
** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200)
** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322)
** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303)
** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647)
** Obsolete normative reference: RFC 3548 (Obsoleted by RFC 4648)
-- Obsolete informational reference (is this intentional?): RFC 2434
(Obsoleted by RFC 5226)
Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group M. Nottingham, Ed.
3 Internet-Draft
4 Expires: July 11, 2005 R. Sayre, Ed.
5 Boswijck Memex Consulting
6 January 10, 2005
8 The Atom Syndication Format
9 draft-ietf-atompub-format-04
11 Status of this Memo
13 By submitting this Internet-Draft, I certify that any applicable
14 patent or other IPR claims of which I am aware have been disclosed,
15 and any of which I become aware will be disclosed, in accordance with
16 RFC 3668.
18 Internet-Drafts are working documents of the Internet Engineering
19 Task Force (IETF), its areas, and its working groups. Note that
20 other groups may also distribute working documents as
21 Internet-Drafts.
23 Internet-Drafts are draft documents valid for a maximum of six months
24 and may be updated, replaced, or obsoleted by other documents at any
25 time. It is inappropriate to use Internet-Drafts as reference
26 material or to cite them other than as "work in progress."
28 The list of current Internet-Drafts can be accessed at
29 http://www.ietf.org/ietf/1id-abstracts.txt.
31 The list of Internet-Draft Shadow Directories can be accessed at
32 http://www.ietf.org/shadow.html.
34 This Internet-Draft will expire on July 11, 2005.
36 Copyright Notice
38 Copyright (C) The Internet Society (2005). All Rights Reserved.
40 Abstract
42 This document specifies Atom, an XML-based Web content and metadata
43 syndication format.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
48 1.1 Editorial Notes . . . . . . . . . . . . . . . . . . . . . 4
49 1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
50 1.3 Conformance . . . . . . . . . . . . . . . . . . . . . . . 5
51 1.4 Notational Conventions . . . . . . . . . . . . . . . . . . 5
52 2. Atom Documents . . . . . . . . . . . . . . . . . . . . . . . 7
53 3. Common Atom Constructs . . . . . . . . . . . . . . . . . . . 8
54 3.1 Text Constructs . . . . . . . . . . . . . . . . . . . . . 8
55 3.1.1 "type" Attribute . . . . . . . . . . . . . . . . . . . 8
56 3.2 Person Constructs . . . . . . . . . . . . . . . . . . . . 9
57 3.2.1 "atom:name" Element . . . . . . . . . . . . . . . . . 9
58 3.2.2 "atom:uri" Element . . . . . . . . . . . . . . . . . . 9
59 3.2.3 "atom:email" Element . . . . . . . . . . . . . . . . . 9
60 3.3 Date Constructs . . . . . . . . . . . . . . . . . . . . . 9
61 3.4 Service Constructs . . . . . . . . . . . . . . . . . . . . 9
62 3.4.1 "href" Attribute . . . . . . . . . . . . . . . . . . . 10
63 3.5 Link Constructs . . . . . . . . . . . . . . . . . . . . . 10
64 3.5.1 "rel" Attribute . . . . . . . . . . . . . . . . . . . 10
65 3.5.2 "type" Attribute . . . . . . . . . . . . . . . . . . . 11
66 3.5.3 "href" Attribute . . . . . . . . . . . . . . . . . . . 11
67 3.5.4 "hreflang" Attribute . . . . . . . . . . . . . . . . . 11
68 3.5.5 "title" Attribute . . . . . . . . . . . . . . . . . . 11
69 3.5.6 "length" Attribute . . . . . . . . . . . . . . . . . . 11
70 3.6 Identity Constructs . . . . . . . . . . . . . . . . . . . 12
71 3.6.1 Dereferencing Identity Constructs . . . . . . . . . . 12
72 3.6.2 Comparing Identity Constructs . . . . . . . . . . . . 12
73 3.7 The Category Construct . . . . . . . . . . . . . . . . . . 13
74 3.7.1 The "term" Attribute . . . . . . . . . . . . . . . . . 13
75 3.7.2 The "scheme" Attribute . . . . . . . . . . . . . . . . 13
76 3.7.3 The "label" attribute . . . . . . . . . . . . . . . . 13
77 4. The "atom:feed" Element . . . . . . . . . . . . . . . . . . 14
78 4.1 "version" Attribute . . . . . . . . . . . . . . . . . . . 14
79 4.2 The "atom:head" Element . . . . . . . . . . . . . . . . . 14
80 4.2.1 "atom:title" Element . . . . . . . . . . . . . . . . . 14
81 4.2.2 "atom:link" Element . . . . . . . . . . . . . . . . . 14
82 4.2.3 "atom:category" Element . . . . . . . . . . . . . . . 15
83 4.2.4 "atom:introspection" Element . . . . . . . . . . . . . 15
84 4.2.5 "atom:post" Element . . . . . . . . . . . . . . . . . 15
85 4.2.6 "atom:author" Element . . . . . . . . . . . . . . . . 15
86 4.2.7 "atom:contributor" Element . . . . . . . . . . . . . . 15
87 4.2.8 "atom:tagline" Element . . . . . . . . . . . . . . . . 15
88 4.2.9 "atom:id" Element . . . . . . . . . . . . . . . . . . 16
89 4.2.10 "atom:generator" Element . . . . . . . . . . . . . . 16
90 4.2.11 "atom:copyright" Element . . . . . . . . . . . . . . 16
91 4.2.12 "atom:info" Element . . . . . . . . . . . . . . . . 16
92 4.2.13 "atom:updated" Element . . . . . . . . . . . . . . . 16
94 5. The "atom:entry" Element . . . . . . . . . . . . . . . . . . 18
95 5.1 "atom:title" Element . . . . . . . . . . . . . . . . . . . 18
96 5.2 "atom:link" Element . . . . . . . . . . . . . . . . . . . 18
97 5.3 "atom:category" Element . . . . . . . . . . . . . . . . . 18
98 5.4 "atom:edit" Element . . . . . . . . . . . . . . . . . . . 19
99 5.5 "atom:author" Element . . . . . . . . . . . . . . . . . . 19
100 5.6 "atom:contributor" Element . . . . . . . . . . . . . . . . 19
101 5.7 "atom:host" Element . . . . . . . . . . . . . . . . . . . 19
102 5.8 "atom:id" Element . . . . . . . . . . . . . . . . . . . . 19
103 5.9 "atom:updated" Element . . . . . . . . . . . . . . . . . . 19
104 5.10 "atom:published" Element . . . . . . . . . . . . . . . . 20
105 5.11 "atom:summary" Element . . . . . . . . . . . . . . . . . 20
106 5.12 "atom:content" Element . . . . . . . . . . . . . . . . . 20
107 5.12.1 "type" attribute . . . . . . . . . . . . . . . . . . 20
108 5.12.2 "src" attribute . . . . . . . . . . . . . . . . . . 21
109 5.12.3 Processing Model . . . . . . . . . . . . . . . . . . 21
110 5.13 "atom:copyright" Element . . . . . . . . . . . . . . . . 22
111 5.14 "atom:head" Element . . . . . . . . . . . . . . . . . . 22
112 6. Managing Feed State . . . . . . . . . . . . . . . . . . . . 23
113 7. Securing Atom Documents . . . . . . . . . . . . . . . . . . 24
114 7.1 Digital Signatures . . . . . . . . . . . . . . . . . . . . 24
115 7.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . 24
116 8. Embedding Atom in Other Formats . . . . . . . . . . . . . . 25
117 9. Extending Atom . . . . . . . . . . . . . . . . . . . . . . . 26
118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
119 10.1 Registry of Link Relations . . . . . . . . . . . . . . . 27
120 11. Security Considerations . . . . . . . . . . . . . . . . . . 29
121 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
122 12.1 Normative References . . . . . . . . . . . . . . . . . . . 30
123 12.2 Informative References . . . . . . . . . . . . . . . . . . 31
124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
125 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
126 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 34
127 Intellectual Property and Copyright Statements . . . . . . . 36
129 1. Introduction
131 Atom is an XML-based document format intended to allow lists of
132 related information, known as "feeds". Feeds are composed of a
133 number of items, known as "entries", each with an extensible set of
134 attached metadata. For example, each entry has a title.
136 The primary use case that Atom addresses is the syndication of Web
137 content such as Weblogs and news headlines to Web sites as well as
138 directly to user agents. However, nothing precludes it from being
139 used for other purposes and kinds of content.
141 Details of communication protocols between software agents using Atom
142 can be found in the Atom Protocol specification [Atom-protocol].
144 [[ more motivation / design principles ]]
146 1.1 Editorial Notes
148 The Atom format is a work-in-progress, and this draft is both
149 incomplete and likely to change rapidly. As a result, THE FORMAT
150 DESCRIBED BY THIS DRAFT SHOULD NOT BE DEPLOYED, either in production
151 systems or in any non-experimental fashion on the Internet.
153 Discussion of this draft happens in two fora;
155 The mailing list [1]
156 The Atom Wiki Web site [2]
158 Active development takes place on the mailing list, while the Wiki is
159 used for issue tracking and new proposals.
161 This document is an early draft and known to be incomplete. Topics
162 marked [[like this]] indicate where additional text is likely to be
163 added.
165 1.2 Example
167 A minimal, single-entry Atom Feed Document:
169
170
174
175 Example Feed
176
177 2003-12-13T18:30:02Z
178
179 John Doe
180
181
182
183 Atom-Powered Robots Run Amok
184
185 vemmi://example.org/2003/32397
186 2003-12-13T18:30:02Z
187
188
190 1.3 Conformance
192 [[ talk about atom documents and atom consumers, and how requirements
193 are placed on them ]]
195 1.4 Notational Conventions
197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
199 document are to be interpreted as described in BCP 14, [RFC2119].
201 This specification uses XML Namespaces [W3C.REC-xml-names-19990114]
202 to uniquely identify XML elements and attribute names. It uses the
203 following namespace prefixes for the indicated namespace URIs;
205 "atom": http://purl.org/atom/ns#draft-ietf-atompub-format-04
207 Note that the choice of any namespace prefix is arbitrary and not
208 semantically significant.
210 Atom is specified using terms from the XML Infoset
211 [W3C.REC-xml-infoset-20011024]. However, this specification uses a
212 shorthand for two common terms; the phrase "Information Item" is
213 omitted when naming Element Information Items and Attribute
214 Information Items.
216 Therefore, when this specification uses the term "element," it is
217 referring to an Element Information Item in Infoset terms. Likewise,
218 when it uses the term "attribute," it is referring to an Attribute
219 Information Item.
221 2. Atom Documents
223 This specification describes two kinds of Atom Documents; Atom Feed
224 Documents and Atom Entry Documents.
226 An Atom Feed Document is a representation of an Atom feed, including
227 metadata about the feed, and some or all of the entries associated
228 with it. Its document element is atom:feed.
230 An Atom Entry Document represents exactly one Atom Entry, outside of
231 the context of an Atom Feed. Its document element is atom:entry.
233 Both kinds of Atom documents are specified in terms of the XML
234 Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and
235 identified with the "application/atom+xml" media type. Atom
236 Documents MUST be well-formed XML.
238 [[ Validity? ]]
240 Atom constrains the appearance and content of elements and
241 attributes; unless otherwise stated, Atom Documents MAY contain other
242 Information Items as appropriate. In particular, Comment Information
243 Items and Processing Instruction Information Items SHOULD be ignored
244 in the normal processing of an Atom Document.
246 Any element in an Atom Document MAY have an xml:base attribute. XML
247 Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any
248 relative reference [RFC2396bis] present in an Atom Document. This
249 includes such elements and attributes as specified by Atom itself, as
250 well as those specified by extensions to Atom.
252 Any element in an Atom Document MAY have an xml:lang attribute, whose
253 content indicates the default natural language of the element's
254 content. Requirements regarding the content and interpretation of
255 xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section
256 2.12.
258 [[ discussion of URI escaping and i18n, IRI ]]
260 [[ discussion of white space ]]
262 Atom is extensible. See the section titled 'Extending Atom' later in
263 this document for a full description of how Atom Documents can be
264 extended.
266 3. Common Atom Constructs
268 Many of Atom's elements share a few common structures. This section
269 defines a few such structures and their requirements, for convenient
270 reference by the appropriate element definitions.
272 When an element is identified as being a particular kind of
273 construct, it inherits the corresponding requirements from that
274 construct's definition in this section.
276 3.1 Text Constructs
278 A Text construct contains human readable text, usually in fairly
279 small quantities.
281 3.1.1 "type" Attribute
283 Text constructs MAY have a "type" attribute. When present, the value
284 MUST be one of "TEXT", "HTML" or "XHTML". If the "type" attribute is
285 not provided, software MUST behave as though it were present with a
286 value of "TEXT".
288 Note that MIME media types [RFC2045] are not acceptable values for
289 the "type" attribute.
291 If the value is "TEXT", the content of the Text construct MUST NOT
292 contain child elements. Such text is intended to be presented to
293 humans in a readable fashion. Thus, software MAY display it using
294 normal text rendering techniques such as proportional fonts,
295 white-space collapsing, and justification.
297 If the value of "type" is "HTML", the content of the Text construct
298 MUST NOT contain child elements, and SHOULD be suitable for handling
299 by software that knows HTML. The HTML markup must be escaped; for
300 example, " " as "<br>". The HTML markup SHOULD be such that it
301 could validly appear directly within an HTML
element.
302 Receiving software which displays the content MAY use the markup to
303 aid in displaying it.
305 If the value of "type" is "XHTML", the content of the Text construct
306 MAY contain child elements. The content SHOULD be XHTML text and
307 markup that could validly appear directly within an xhtml:div
308 element. Receiving software which displays the content MAY use the
309 markup to aid in displaying it. Escaped markup is interpreted as a
310 text representation of markup, and MUST NOT be interpreted as markup
311 itself.
313 3.2 Person Constructs
315 A Person construct is an element that describes a person,
316 corporation, or similar entity.
318 Person constructs MAY be extended by namespace-qualified element
319 children.
321 This specification assigns no significance to the order of appearance
322 of the child elements of a Person construct.
324 3.2.1 "atom:name" Element
326 The "atom:name" element's content conveys a human-readable name for
327 the person. Person constructs MUST contain exactly one "atom:name"
328 element.
330 3.2.2 "atom:uri" Element
332 The "atom:uri" element's content conveys a URI associated with the
333 person. Person constructs MAY contain an atom:uri element, but MUST
334 NOT contain more than one. The content of atom:uri in a Person
335 construct MUST be a URI reference [RFC2396bis].
337 xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to the
338 atom:uri element's content.
340 3.2.3 "atom:email" Element
342 The "atom:email" element's content conveys an e-mail address
343 associated with the persons. Person constructs MAY contain an
344 atom:email element, but MUST NOT contain more than one. Its content
345 MUST be an e-mail address [RFC2822].
347 3.3 Date Constructs
349 A Date construct is an element whose content MUST conform to the
350 date-time BNF rule in [RFC3339].
352 3.4 Service Constructs
354 A Service construct is an empty element that conveys the URI of an
355 Atom Publishing Protocol [Atom-protocol] service associated with an
356 entry or feed. The type of service is identified by the element
357 name.
359 A Service construct has the following attribute:
361 3.4.1 "href" Attribute
363 The "href" attribute contains the a URI pointing to the endpoint of
364 the service named by the name attribute. atom:service elements MUST
365 have a "href" attribute, whose value MUST be a URI reference
366 [RFC2396bis].
368 xml:base processing MUST be applied to the "href" attribute.
370 3.5 Link Constructs
372 A Link construct is an empty element that describes a connection from
373 an Atom Document to another Web resource.
375 3.5.1 "rel" Attribute
377 Link constructs MAY have an optional "rel" attribute that indicates
378 the link relation type. If the "rel" attribute is not present, the
379 link construct MUST be interpreted as if the link relation type is
380 "alternate".
382 rel_attribute = segment-nz-nc / URI
384 The value of "rel" MUST be either a name, which is non-empty and does
385 not contain any colon (":") characters, or a URI [RFC2396bis]. Note
386 that use of a relative reference to the "rel" value URI is not
387 allowed. If a name is given, implementations MUST consider the link
388 relation type to be equivalent to the same name registered within the
389 IANA Registry of Link Relations Section 10, and thus the URI that
390 would be obtained by appending the value of the rel attribute to the
391 string "http://www.iana.org/assignments/relation/". The value of
392 "rel" describes the meaning of the link, but does not impose any
393 behavioral requirements on implementations.
395 This document defines two initial values for the Registry of Link
396 Relations:
398 The value "alternate" signifies that the URI in the value of the href
399 attribute identifies an alternate version of the resource described
400 by the containing element.
402 The value "related" signifies that the URI in the value of the href
403 attribute identifies a resource to which the resource described by
404 the containing atom:feed or atom:entry element is related. For
405 example, the feed for a site which discusses the performance of the
406 search engine at "http://search.example.com" might contain, as a
407 child of atom:head:
408
409 An identical link might appear as a child of any atom:entry whose
410 content contains a discussion of that same search engine.
412 3.5.2 "type" Attribute
414 Link constructs MAY have a type attribute, whose value MUST conform
415 to the syntax of a MIME media type [RFC2045].
417 The type attribute's value is an advisory media type; it MAY be used
418 as a hint to determine the type of the representation which is
419 expected to be returned when the value of the href attribute is
420 dereferenced. Note that the type attribute does not override the
421 actual media type returned with the representation.
423 3.5.3 "href" Attribute
425 The "href" attribute contains the link's URI. Link constructs MUST
426 have a href attribute, whose value MUST be a URI reference
427 [RFC2396bis].
429 xml:base [W3C.REC-xmlbase-20010627] processing MUST be applied to the
430 href attribute's content.
432 3.5.4 "hreflang" Attribute
434 The "hreflang" attribute's content describes the language of the
435 resource pointed to by the href attribute. When used together with
436 the rel="alternate", it implies a translated version of the entry.
437 Link constructs MAY have an hreflang attribute, whose value MUST be a
438 language tag [RFC3066].
440 3.5.5 "title" Attribute
442 The "title" attribute conveys human-readable information about the
443 link. Link constructs MAY have a title attribute.
445 3.5.6 "length" Attribute
447 The "length" attribute indicates an advisory length of the linked
448 content in octets; it MAY be used as a hint to determine the content
449 length of the representation returned when the URI in the href
450 attribute is dereferenced. Note that the length attribute does not
451 override the actual content length of the representation as reported
452 by the underlying protocol.
454 Link constructs MAY have a length attribute.
456 3.6 Identity Constructs
458 An Identity construct is an element whose content conveys a
459 permanent, universally unique identifier for the construct's parent.
460 Its content MUST be a URI, as defined by [RFC2396bis]. Note that the
461 definition of "URI" excludes relative references.
463 When an Atom document is relocated, migrated, syndicated,
464 republished, exported or imported, the content of its Identity
465 construct MUST NOT change. Put another way, an Identity construct
466 pertains to all instantiations of a particular Atom entry or feed;
467 revisions retain the same content in their Identity constructs.
469 3.6.1 Dereferencing Identity Constructs
471 The content of an Identity construct MAY be dereferencable (e.g. an
472 HTTP URI). However, processors MUST NOT assume it to be
473 dereferencable.
475 The content of an Identity construct MUST be created in a way that
476 assures uniqueness, and it is suggested that the Identity construct
477 be stored along with the associated resource.
479 Because of the risk of confusion between URIs that would be
480 equivalent if dereferenced, the following normalization strategy is
481 strongly encouraged when generating Identity constructs:
483 o Provide the scheme in lowercase characters.
484 o Provide the host, if any, in lowercase characters.
485 o Only perform percent-encoding where it is essential.
486 o Use uppercase A-through-F characters when percent-encoding.
487 o Prevent dot-segments appearing in paths.
488 o For schemes that define a default authority, use an empty
489 authority if the default is desired.
490 o For schemes that define an empty path to be equivalent to a path
491 of "/", use "/".
492 o For schemes that define a port, use an empty port if the default
493 is desired.
494 o Preserve empty fragment identifiers and queries.
495 o Ensure that all portions of the URI are UTF-8 encoded NFC form
496 Unicode strings.
498 3.6.2 Comparing Identity Constructs
500 Instances of Identity constructs can be compared to determine whether
501 an entry or feed is the same as one seen before. Processors MUST
502 compare Identity constructs on a character-by-character basis in a
503 case-sensitive fashion.
505 As a result, two URIs that resolve to the same resource but are not
506 character-for-character identical will be considered different for
507 the purposes of Identifier comparison.
509 For example, "http://www.example.org/thing",
510 "http://www.example.org/Thing", "http://www.EXAMPLE.org/thing" and
511 "HTTP://www.example.org/thing" will all be considered different
512 identifiers, despite their differences in case.
514 Likewise, "http://www.example.com/~bob",
515 "http://www.example.com/%7ebob" and "http://www.example.com/%7Ebob"
516 will all be considered different identifiers, because URI %-escaping
517 is significant for the purposes of comparison.
519 3.7 The Category Construct
521 Category constructs contain information about a category to which an
522 Atom feed or entry is associated.
524 3.7.1 The "term" Attribute
526 The "term" attribute will be a string which identifies the category
527 within the categorization scheme to which the entry or feed belongs.
528 Category constructs MUST have a "term" attribute.
530 3.7.2 The "scheme" Attribute
532 The is a URI that identifies a categorization scheme. Category
533 constructs MAY have a "scheme" attribute.
535 3.7.3 The "label" attribute
537 The "label" attribute provides a human-readable label that may be
538 displayed in end-user applications. Category constructs MAY have a
539 "label" attribute.
541 4. The "atom:feed" Element
543 The "atom:feed" element is the document (i.e., top-level) element of
544 an Atom Feed Document, acting as a container for metadata and data
545 associated with the feed. Its first element child MUST be atom:head,
546 which MAY be followed zero or more atom:entry child elements.
548 4.1 "version" Attribute
550 atom:feed elements MUST have a "version" attribute whose content
551 indicates the version of the Atom specification that the feed
552 conforms to. The content of this attribute is unstructured text.
554 The version identifier for this specification is
555 "draft-ietf-atompub-format-04 : do not deploy".
557 4.2 The "atom:head" Element
559 The atom:head element acts as a container for metadata about the feed
560 itself.
562 The atom:head element MAY contain any namespace-qualified
563 [W3C.REC-xml-names-19990114] elements as children. This
564 specification assigns no significance to the order of appearance of
565 the child elements of atom:head.
567 The following child elements are defined by this specification (note
568 that the presence of some of these elements is required):
570 4.2.1 "atom:title" Element
572 The "atom:title" element is a Text construct that conveys a
573 human-readable title for the feed. atom:head elements MUST contain
574 exactly one atom:title element.
576 4.2.2 "atom:link" Element
578 The "atom:link" element is a Link construct that conveys a URI
579 associated with the feed. The nature of the relationship is
580 determined by the construct's rel attribute.
582 atom:head elements MUST contain at least one atom:link element with a
583 rel attribute value of "alternate".
585 atom:head elements MUST NOT contain more than one atom:link element
586 with a rel attribute value of "alternate" that has the same type
587 attribute value.
589 If a feed's atom:link element with type="alternate" resolves to an
590 HTML document, then that document SHOULD have a autodiscovery link
591 element [Atom-autodiscovery] that reflects back to the feed.
593 atom:head elements MAY contain additional atom:link elements beyond
594 those described above.
596 4.2.3 "atom:category" Element
598 A Category Construct identifying a category with which the feed is
599 associated. atom:head elements MAY contain any number of
600 atom:category elements.
602 4.2.4 "atom:introspection" Element
604 The "atom:introspection" element is a Service construct that conveys
605 the URI of an introspection file associated with the feed. atom:head
606 elements MUST NOT contain more than one atom:introspection element.
608 4.2.5 "atom:post" Element
610 The "atom:post" element is a Service construct that conveys the URI
611 used to add entries to the feed. atom:head elements MUST NOT contain
612 more than one atom:post element.
614 4.2.6 "atom:author" Element
616 The "atom:author" element is a Person construct that indicates the
617 default author of the feed. atom:head elements MUST contain exactly
618 one atom:author element, UNLESS all of the atom:feed element's child
619 atom:entry elements contain an atom:author element. atom:head
620 elements MUST NOT contain more than one atom:author element.
622 [[explain inheritance]]
624 4.2.7 "atom:contributor" Element
626 The "atom:contributor" element is a Person construct that indicates a
627 person or other entity who contributes to the feed. atom:head
628 elements MAY contain one or more atom:contributor elements.
630 4.2.8 "atom:tagline" Element
632 The "atom:tagline" element is a Text construct that conveys a
633 human-readable description or tagline for the feed. atom:head
634 elements MAY contain an atom:tagline element, but MUST NOT contain
635 more than one.
637 4.2.9 "atom:id" Element
639 The "atom:id" element is an Identity construct that conveys a
640 permanent, universally unique identifier for a feed. atom:head
641 elements MAY contain an atom:id element, but MUST NOT contain more
642 than one.
644 4.2.10 "atom:generator" Element
646 The "atom:generator" element's content identifies the software agent
647 used to generate the feed, for debugging and other purposes.
648 atom:head elements MAY contain an atom:generator element, but MUST
649 NOT contain more than one.
651 The content of this element, when present, MUST be a string that is a
652 human-readable name for the generating agent.
654 The atom:generator element MAY have a "uri" attribute whose value
655 MUST be a URI reference [RFC2396bis]. When dereferenced, that URI
656 SHOULD produce a representation that is relevant to that agent.
658 The atom:generator element MAY have a "version" attribute that
659 indicates the version of the generating agent. When present, its
660 value is unstructured text.
662 4.2.11 "atom:copyright" Element
664 The "atom:copyright" element is Text construct that conveys a
665 human-readable copyright statement for the feed. atom:head elements
666 MAY contain an atom:copyright element, but MUST NOT contain more than
667 one.
669 The atom:copyright element SHOULD NOT be used to convey
670 machine-readable licensing information.
672 4.2.12 "atom:info" Element
674 The "atom:info" element is a Text construct that conveys a
675 human-readable explanation of the feed format itself. atom:head
676 elements MAY contain an atom:info element, but MUST NOT contain more
677 than one.
679 The atom:info element SHOULD NOT considered meaningful by processors;
680 it is a convenience to publishers in certain situations.
682 4.2.13 "atom:updated" Element
684 The "atom:updated" element is a Date construct indicating the most
685 recent instant in time when the feed was modified in a way the
686 producer considers significant. Therefore, not all modifications
687 necessarily result in a changed atom:updated value.
689 atom:head elements MUST contain exactly one atom:updated element.
691 5. The "atom:entry" Element
693 The "atom:entry" element represents an individual entry. This
694 element can appear as a child of the atom:feed element, or it can
695 appear as the document (i.e., top-level) element of a standalone Atom
696 Entry Document.
698 When appearing in an Atom Entry Document, atom:entry elements MUST
699 have a "version" attribute whose content indicates the version of the
700 Atom specification that the entry conforms to.
702 The version identifier for this specification is
703 "draft-ietf-atompub-format-04 : do not deploy".
705 The atom:entry element MAY contain any namespace-qualified
706 [W3C.REC-xml-names-19990114] elements as children. This
707 specification assigns no significance to the order of appearance of
708 the child elements of atom:entry.
710 The following child elements are defined by this specification (note
711 that it requires the presence of some of these elements):
713 5.1 "atom:title" Element
715 The "atom:title" element is a Text construct that conveys a
716 human-readable title for the entry. atom:entry elements MUST have
717 exactly one "atom:title" element.
719 5.2 "atom:link" Element
721 The "atom:link" element is a Link construct that conveys a URI
722 associated with the entry. The nature of the relationship as well as
723 the link itself is determined by the element's content.
725 atom:entry elements that contain no child atom:content element MUST
726 contain at least one atom:link element with a rel attribute value of
727 "alternate".
729 atom:entry elements MUST NOT contain more than one atom:link element
730 with a rel attribute value of "alternate" that has the same type
731 attribute value.
733 atom:entry elements MAY contain additional atom:link elements beyond
734 those described above.
736 5.3 "atom:category" Element
738 A Category Construct identifying a category with which the entry is
739 associated. atom:entry elements MAY contain any number of
740 atom:category elements.
742 5.4 "atom:edit" Element
744 The "atom:edit" element is a Service construct that conveys the URI
745 used to retrieve and edit the source representation of the entry.
746 atom:entry elements MUST NOT contain more than one atom:edit element.
748 5.5 "atom:author" Element
750 The "atom:author" element is a Person construct that indicates the
751 default author of the entry. atom:entry elements MUST contain
752 exactly one atom:author element, unless, in an Atom Feed Document,
753 the atom:head element contains an atom:author element itself.
754 atom:entry elements MUST NOT contain more than one atom:author
755 element.
757 5.6 "atom:contributor" Element
759 The "atom:contributor" element is a Person construct that indicates a
760 person or other entity who contributes to the entry. atom:entry
761 elements MAY contain one or more atom:contributor elements.
763 5.7 "atom:host" Element
765 The "atom:host" element's content conveys a domain name or network
766 address associated with the entry's origin. atom:entry elements MAY
767 contain a single atom:host element. Its content MUST be a domain
768 name [RFC1035], a dotted-decimal IPv4 address [RFC0791], or a
769 colon-delimited IPv6 address [RFC2460].
771 5.8 "atom:id" Element
773 The "atom:id" element is an Identity construct that conveys a
774 permanent, universally unique identifier for an entry. atom:entry
775 elements MUST contain exactly one atom:id element.
777 5.9 "atom:updated" Element
779 The "atom:updated" element is a Date construct indicating the most
780 recent instant in time when the entry was modified in a way the
781 producer considers significant. Therefore, not all modifications
782 necessarily result in a changed atom:updated value.
784 atom:entry elements MUST contain exactly one atom:updated element.
786 Publishers MAY change the value of this element over time.
788 Processors MAY present entries sorted using this value. Processors
789 MAY choose not to present entries until the instant in time specified
790 in the atom:updated element has passed.
792 5.10 "atom:published" Element
794 The "atom:published" element is a Date construct indicating an
795 instant in time associated with an event early in the life cycle of
796 the entry. Typically, atom:published will be associated with the
797 initial creation or first availability of the resource.
799 atom:entry elements MAY contain an atom:published element, but MUST
800 NOT contain more than one.
802 Processors MAY present entries sorted using this value. Processors
803 MAY choose not to present entries until the instant in time specified
804 in the atom:published element has passed.
806 5.11 "atom:summary" Element
808 The "atom:summary" element is a Text construct that conveys a short
809 summary, abstract or excerpt of the entry. atom:entry elements MAY
810 contain an atom:summary element, but MUST NOT contain more than one.
812 atom:entry elements MUST contain an atom:summary element in any of
813 the following cases:
815 o the atom:entry element contains no atom:content element.
816 o the atom:entry contains an atom:content which has a "src"
817 attribute (and is thus empty).
818 o the atom:entry contains content which is encoded in Base64; i.e.
819 the "type" attribute of atom:content is a MIME media type
820 [RFC2045] and does not begin with "text/" nor end with "+xml".
822 5.12 "atom:content" Element
824 The "atom:content" element either contains or links to the content of
825 the entry. atom:entry elements MUST contain zero or one atom:content
826 elements.
828 5.12.1 "type" attribute
830 atom:content MAY have a "type" attribute, When present, the value MAY
831 be one of "TEXT", "HTML", or "XHTML". Failing that, it MUST be a
832 MIME media type [RFC2045] in which, to use the terminology of Section
833 5 of [RFC2045], the top level is a discrete type. If the type
834 attribute is not provided, software MUST behave as though it were
835 present with a value of "TEXT".
837 5.12.2 "src" attribute
839 atom:content MAY have a "src" attribute, whose value MUST be a URI
840 reference [RFC2396bis]. If the "src" attribute is present, software
841 MAY use the URI to retrieve the content. If the "src" attribute is
842 present, atom:content MUST be empty. That is to say, the content may
843 be retrievable using "src=" URI, or it may be contained within
844 atom:content, but not both.
846 If the "src" attribute is present, the "type" attribute SHOULD be
847 provided and MUST be a MIME media type [RFC2045], rather than "TEXT",
848 "HTML", or "XHTML". The value is advisory; that is to say, upon
849 dereferencing the URI to retrieve the content, if the server
850 providing that content also provides a media type, the
851 server-provided media type is authoritative.
853 If the value of type begins with "text/" or ends with "+xml", the
854 content SHOULD be local; that is to say, no "src" attribute should be
855 provided.
857 5.12.3 Processing Model
859 Software MUST apply the following rules in succession in the order
860 below to ascertain the rules governing the content of "atom:content".
862 1. If the value is "TEXT", the content of atom:content MUST NOT
863 contain child elements. Such text is intended to be presented to
864 humans in a readable fashion. Thus, software MAY display it
865 using normal text rendering techniques such as proportional
866 fonts, white-space collapsing, and justification.
867 2. If the value of "type" is "HTML", the content of atom:content
868 MUST NOT contain child elements, and SHOULD be suitable for
869 handling by software that knows HTML. The HTML markup must be
870 escaped; for example, " " as "<br>". The HTML markup
871 SHOULD be such that it could validly appear directly within an
872 HTML
element. Receiving software which displays the
873 content SHOULD use the markup to aid in displaying it.
874 3. If the value of "type" is "XHTML", the content of atom:content
875 MAY contain child elements. The content SHOULD be XHTML text and
876 markup that could validly appear directly within an xhtml:div
877 element. Receiving software which displays the content SHOULD
878 use the markup to aid in displaying it. Escaped markup is
879 interpreted as a text representation of markup, and MUST NOT be
880 interpreted as markup itself.
881 4. If the value of "type" ends with "+xml" or "/xml", the content of
882 atom:content may include child elements, and SHOULD be suitable
883 for handling by software that knows the indicated media type. If
884 the "src" attribute is not provided, this would normally mean
885 that the "atom:content" element would contain a single child
886 element which would serve as the root element of the XML document
887 of the indicated type.
888 5. If the value of "type" begins with "text/" the content of
889 atom:content MUST NOT contain child elements.
890 6. For all other values of "type", the content of atom:content MUST
891 be a valid Base64 encoding [RFC3548], which when decoded SHOULD
892 be suitable for handling by software that knows the indicated
893 media type. In this case, the characters in the Base64 encoding
894 may be preceded and followed in the atom:content element by
895 whitespace, and lines are separated by a single newline (U+000A)
896 character, as required by XML.
898 5.13 "atom:copyright" Element
900 The "atom:copyright" element is a Text construct that conveys a
901 human-readable copyright statement for the entry. atom:entry
902 elements MAY contain an atom:copyright element, but MUST NOT contain
903 more than one.
905 The atom:copyright element SHOULD NOT be used to convey
906 machine-readable licensing information.
908 If an atom:entry element does not contain an atom:copyright element,
909 then the atom:copyright element of the containing atom:feed element's
910 atom:head element, if present, should be considered to apply to the
911 entry.
913 5.14 "atom:head" Element
915 The atom:head element acts as a container for metadata about the feed
916 within which the entry was created.
918 atom:entry elements MAY contain at most one atom:head element. If
919 the atom:head element is present, it SHOULD be the first child
920 element of atom:entry.
922 If an atom:entry is copied into one feed from another feed, then the
923 atom:head element of the source feed SHOULD be inserted into the
924 atom:entry unless the entry, as copied, already contains an atom:head
925 element. If the atom:entry already contains an atom:head, then that
926 atom:head SHOULD be copied without modification.
928 [[ ... example ... ]]
930 6. Managing Feed State
932 [[ talk about what it means to keep a view of a feed ]]
934 7. Securing Atom Documents
936 Because Atom is an XML-based format, existing XML security mechanisms
937 can be used to secure its content.
939 Note that while these mechanisms are available to secure Atom
940 documents, they should not be used indiscriminately.
942 7.1 Digital Signatures
944 The document element of an Atom document (i.e., atom:feed in an Atom
945 Feed Document, atom:entry in an Atom Entry Document) MAY have an
946 Enveloped Signature, as described by XML-Signature and Syntax
947 Processing [W3C.REC-xmldsig-core-20020212]. Other XML signature
948 mechanisms MUST NOT be used on the document element of an Atom
949 document.
951 Processors MUST NOT reject an Atom document containing such a
952 signature because they are not capable of verifying it; they MUST
953 continue processing and MAY inform the user of their failure to
954 validate the signature.
956 In other words, the presence of an element with the namespace URI
957 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature"
958 as a child of the document element must not cause a processor to fail
959 merely because of its presence.
961 Other elements in an Atom document MUST NOT be signed unless their
962 definitions explicitly specify such a capability.
964 7.2 Encryption
966 The document element of an Atom document (i.e., atom:feed in an Atom
967 Feed Document, atom:entry in an Atom Entry Document) MAY be
968 encrypted, using the mechanisms described by XML Encryption Syntax
969 and Processing [W3C.REC-xmlenc-core-20021210]. Other XML encryption
970 mechanisms MUST NOT be used on the document element of an Atom
971 document.
973 8. Embedding Atom in Other Formats
975 [[ ... ]]
977 9. Extending Atom
979 [[ ... ]]
981 10. IANA Considerations
983 An Atom Document, when serialized as XML 1.0, can be identified with
984 the following media type:
986 MIME media type name: application
987 MIME subtype name: atom+xml
988 Mandatory parameters: None.
989 Optional parameters:
990 "charset": This parameter has identical semantics to the charset
991 parameter of the "application/xml" media type as specified in
992 RFC 3023 [RFC3023]. [RFC3023].
993 Encoding considerations: Identical to those of "application/xml" as
994 described in RFC 3023 [RFC3023], section 3.2.
995 Security considerations: As defined in this specification. [[update
996 upon publication]]
997 In addition, as this media type uses the "+xml" convention, it
998 shares the same security considerations as described in RFC 3023
999 [RFC3023], section 10.
1000 Interoperability considerations: There are no known interoperability
1001 issues.
1002 Published specification: This specification. [[update upon
1003 publication]]
1004 Applications which use this media type: No known applications
1005 currently use this media type.
1007 Additional information:
1009 Magic number(s): As specified for "application/xml" in RFC 3023
1010 [RFC3023], section 3.2.
1011 File extension: .atom
1012 Fragment identifiers: As specified for "application/xml" in RFC 3023
1013 [RFC3023], section 5.
1014 Base URI: As specified in RFC 3023 [RFC3023], section 6.
1015 Macintosh File Type code: TEXT
1016 Person and email address to contact for further information: Mark
1017 Nottingham
1018 Intended usage: COMMON
1019 Author/Change controller: This specification's author(s). [[update
1020 upon publication]]
1022 10.1 Registry of Link Relations
1024 This registry is maintained by IANA and initially contains the two
1025 values: "alternate" and "related". New assignments are subject to
1026 IESG Approval, as outlined in [RFC2434]. Requests should be made by
1027 email to IANA, which will then forward the request to the IESG
1028 requesting approval. The request should contain discussion of at
1029 least the following five topics:
1031 o A value for the "rel" attribute that conforms to the syntax rule
1032 given in Section 3.5.1
1033 o Common name for link type.
1034 o Description of link type semantics.
1035 o Expected display characteristics.
1036 o Security considerations.
1038 11. Security Considerations
1040 Atom document can be encrypted and signed using
1041 [W3C.REC-xmlenc-core-20021210] and [W3C.REC-xmldsig-core-20020212],
1042 respectively, and is subject to the security considerations implied
1043 by their use.
1045 12. References
1047 12.1 Normative References
1049 [Atom-autodiscovery]
1050 Pilgrim, M., "Atom Feed Autodiscovery", work-in-progress,
1051 August 2004.
1053 [Atom-protocol]
1054 Gregorio, J. and R. Sayre, "The Atom Publishing Protocol",
1055 work-in-progress, July 2004.
1057 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1058 1981.
1060 [RFC1035] Mockapetris, P., "Domain names - implementation and
1061 specification", STD 13, RFC 1035, November 1987.
1063 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
1064 Extensions (MIME) Part One: Format of Internet Message
1065 Bodies", RFC 2045, November 1996.
1067 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1068 Requirement Levels", BCP 14, RFC 2119, March 1997.
1070 [RFC2396bis]
1071 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
1072 Resource Identifier (URI): Generic Syntax", awaiting RFC
1073 number, December 2004.
1075 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
1076 (IPv6) Specification", RFC 2460, December 1998.
1078 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
1079 2001.
1081 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media
1082 Types", RFC 3023, January 2001.
1084 [RFC3066] Alvestrand, H., "Tags for the Identification of
1085 Languages", BCP 47, RFC 3066, January 2001.
1087 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
1088 Timestamps", RFC 3339, July 2002.
1090 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
1091 Encodings", RFC 3548, July 2003.
1093 [W3C.NOTE-datetime-19980827]
1094 Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C
1095 NOTE NOTE-datetime-19980827, August 1998.
1097 [W3C.REC-xml-20040204]
1098 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and
1099 E. Maler, "Extensible Markup Language (XML) 1.0 (Third
1100 Edition)", W3C REC REC-xml-20040204, February 2004.
1102 [W3C.REC-xml-infoset-20011024]
1103 Tobin, R. and J. Cowan, "XML Information Set", W3C
1104 FirstEdition REC-xml-infoset-20011024, October 2001.
1106 [W3C.REC-xml-names-19990114]
1107 Hollander, D., Bray, T. and A. Layman, "Namespaces in
1108 XML", W3C REC REC-xml-names-19990114, January 1999.
1110 [W3C.REC-xmlbase-20010627]
1111 Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627, June
1112 2001.
1114 [W3C.REC-xmldsig-core-20020212]
1115 Solo, D., Reagle, J. and D. Eastlake, "XML-Signature
1116 Syntax and Processing", W3C REC REC-xmldsig-core-20020212,
1117 February 2002.
1119 [W3C.REC-xmlenc-core-20021210]
1120 Reagle, J. and D. Eastlake, "XML Encryption Syntax and
1121 Processing", W3C REC REC-xmlenc-core-20021210, December
1122 2002.
1124 12.2 Informative References
1126 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1127 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
1128 October 1998.
1130 URIs
1132 [1]
1134 [2]
1136 Authors' Addresses
1138 Mark Nottingham (editor)
1140 EMail: mnot@pobox.com
1141 URI: http://www.mnot.net/
1143 Robert Sayre (editor)
1144 Boswijck Memex Consulting
1146 EMail: rfsayre@boswijck.com
1147 URI: http://boswijck.com
1149 Appendix A. Contributors
1151 The following people contributed to preliminary drafts of this
1152 document: Tim Bray, Mark Pilgrim, and Sam Ruby. The content and
1153 concepts within are a product of the Atom community and the Atom
1154 Publishing Format and Protocol Working Group.
1156 Appendix B. Revision History
1158 [[ this section should be removed before final publication. ]]
1160 -04: Update URI terms for 2396bis.
1161 Add Category construct (PaceCategoryRevised).
1162 Insert paranoid XHTML interpretation guidelines.
1163 Adjust atom:copyright, per chairs' instruction.
1164 Add atom:host as child element of atom:entry, per chairs'
1165 direction (PacePersonConstruct).
1166 Add link/content co-constraint (PaceContentOrLink).
1167 Remove atom:origin as a side effect of adding atom:head to
1168 atom:entry (PaceHeadInEntry).
1169 Add optional length attribute to atom:link (PaceLinkRelated).
1170 Add Link registry to Link Construct, IANA Considerations
1171 placeholder (PaceFieldingLinks).
1172 Change definition of atom:updated (PaceUpdatedDefinition).
1173 -03: Move definition of Link @rel to format spec, restrict
1174 acceptable values (PaceMoveLinkElement, PaceLinkAttrDefaults).
1175 Add Service Construct, head/post, head/introspection, entry/edit
1176 (PaceServiceElement).
1177 Add Text Construct, entry/content (PaceReformedContent3).
1178 Add entry/published (PaceDatePublished).
1179 Adjust definition of Identity Construct per chairs' direction to
1180 "fix it."
1181 Add Sayre to editors.
1182 -02: Removed entry/modified, entry/issued, entry/created; added
1183 entry/updated (PaceDateUpdated).
1184 Changed date construct from W3C date-time to RFC3339
1185 (PaceDateUpdated).
1186 Feed links to HTML pages should be reflected back
1187 (PaceLinkReflection).
1188 Added Identity construct (PaceIdConstruct).
1189 Changed feed/id and entry/id to be Identity constructs
1190 (PaceIdConstruct).
1191 Changed entry/origin's content so that it's the same as the feed's
1192 id, rather than its link/@rel="alternate" (PaceIdConstruct).
1193 Added "Securing Atom Documents" (PaceDigitalSignatures).
1194 -01: Constrained omission of "Information Item" to just elements and
1195 attributes.
1196 Clarified xml:lang inheritence.
1197 Removed entry- and feed-specific langauge about xml:lang (covered
1198 by general discussion of xml:lang)
1199 Changed xml:lang to reference XML for normative requirements.
1200 Changed "... MUST be a string" to "... is unstructued text."
1201 Remomved langauge about DOCTYPEs, PIs, Comments, Entities.
1202 Changed atom:url to atom:uri, @url to @uri
1203 Introduced atom:head
1204 Introduced "Atom Feed Document" and "Atom Entry Document".
1205 Removed requirement for all elements and attributes to be
1206 namespace-qualified; now children of selective elements
1207 Added extensibility to Person constructs.
1208 Removed requirement for media types to be registered
1209 (non-registered media types are legal)
1210 Added atom:origin (PaceEntryOrigin)
1211 Added requirement for entry/id to be present and a URI
1212 (PaceEntryIdRequired).
1213 Clarified approach to Comments, PIs and well-formedness, as per
1214 RFC3470.
1215 Referenced escaping algorithm in XML.
1216 Assorted editorial nits and cleanup, refactoring
1217 -00: Initial IETF Internet-Draft submission.
1218 Added optional version attribute to entry
1219 (PaceEntryElementNeedsVersionAttribute).
1220 Added hreflang attribute (PaceHrefLang).
1221 Clarified inheritence of copyright element (PaceItemCopyright).
1222 Added xml:lang to entries (PaceItemLang).
1223 Tweaked Infoset-related language (PaceNoInfoSet).
1224 Clarified lack of structure in version attribute
1225 (PaceVersionAsText).
1226 Changed approach to XML Base (PaceXmlBaseEverywhere).
1227 Added XML Base processing to atom:id (PaceXmlBaseId).
1228 Various editorial cleanup and adjustments for IETF publication.
1230 Intellectual Property Statement
1232 The IETF takes no position regarding the validity or scope of any
1233 Intellectual Property Rights or other rights that might be claimed to
1234 pertain to the implementation or use of the technology described in
1235 this document or the extent to which any license under such rights
1236 might or might not be available; nor does it represent that it has
1237 made any independent effort to identify any such rights. Information
1238 on the procedures with respect to rights in RFC documents can be
1239 found in BCP 78 and BCP 79.
1241 Copies of IPR disclosures made to the IETF Secretariat and any
1242 assurances of licenses to be made available, or the result of an
1243 attempt made to obtain a general license or permission for the use of
1244 such proprietary rights by implementers or users of this
1245 specification can be obtained from the IETF on-line IPR repository at
1246 http://www.ietf.org/ipr.
1248 The IETF invites any interested party to bring to its attention any
1249 copyrights, patents or patent applications, or other proprietary
1250 rights that may cover technology that may be required to implement
1251 this standard. Please address the information to the IETF at
1252 ietf-ipr@ietf.org.
1254 Disclaimer of Validity
1256 This document and the information contained herein are provided on an
1257 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1258 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1259 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1260 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1261 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1262 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1264 Copyright Statement
1266 Copyright (C) The Internet Society (2005). This document is subject
1267 to the rights, licenses and restrictions contained in BCP 78, and
1268 except as set forth therein, the authors retain all their rights.
1270 Acknowledgment
1272 Funding for the RFC Editor function is currently provided by the
1273 Internet Society.