idnits 2.17.1 

draft-ietf-atompub-format-11.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 3978, Section 5.1 on line 14.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 2302.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2279.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2286.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2292.

  ** 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.


  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 :
  ----------------------------------------------------------------------------

  ** There is 1 instance of lines with control characters in the document.


  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 (August 15, 2005) is 6823 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  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. 'HTML'

  == Outdated reference: A later version (-05) exists of
     draft-freed-media-type-reg-04

  ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322)

  ** Downref: Normative reference to an Informational RFC: RFC 2854

  ** 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)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'XHTML'

  -- Obsolete informational reference (is this intentional?): RFC 2434
     (Obsoleted by RFC 5226)


     Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 11 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                                             R. Sayre, Ed.
4	Expires: February 16, 2006                               August 15, 2005

6	                      The Atom Syndication Format
7	                      draft-ietf-atompub-format-11

9	Status of this Memo

11	   By submitting this Internet-Draft, each author represents that any
12	   applicable patent or other IPR claims of which he or she is aware
13	   have been or will be disclosed, and any of which he or she becomes
14	   aware will be disclosed, in accordance with Section 6 of BCP 79.

16	   Internet-Drafts are working documents of the Internet Engineering
17	   Task Force (IETF), its areas, and its working groups.  Note that
18	   other groups may also distribute working documents as Internet-
19	   Drafts.

21	   Internet-Drafts are draft documents valid for a maximum of six months
22	   and may be updated, replaced, or obsoleted by other documents at any
23	   time.  It is inappropriate to use Internet-Drafts as reference
24	   material or to cite them other than as "work in progress."

26	   The list of current Internet-Drafts can be accessed at
27	   http://www.ietf.org/ietf/1id-abstracts.txt.

29	   The list of Internet-Draft Shadow Directories can be accessed at
30	   http://www.ietf.org/shadow.html.

32	   This Internet-Draft will expire on February 16, 2006.

34	Copyright Notice

36	   Copyright (C) The Internet Society (2005).

38	Abstract

40	   This document specifies Atom, an XML-based Web content and metadata
41	   syndication format.

43	Table of Contents

45	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
46	     1.1  Examples . . . . . . . . . . . . . . . . . . . . . . . . .   3
47	     1.2  Namespace and Version  . . . . . . . . . . . . . . . . . .   5
48	     1.3  Notational Conventions . . . . . . . . . . . . . . . . . .   5
49	   2.   Atom Documents . . . . . . . . . . . . . . . . . . . . . . .   6
50	   3.   Common Atom Constructs . . . . . . . . . . . . . . . . . . .   8
51	     3.1  Text Constructs  . . . . . . . . . . . . . . . . . . . . .   8
52	       3.1.1  The "type" Attribute . . . . . . . . . . . . . . . . .   8
53	     3.2  Person Constructs  . . . . . . . . . . . . . . . . . . . .  11
54	       3.2.1  The "atom:name" Element  . . . . . . . . . . . . . . .  11
55	       3.2.2  The "atom:uri" Element . . . . . . . . . . . . . . . .  11
56	       3.2.3  The "atom:email" Element . . . . . . . . . . . . . . .  11
57	     3.3  Date Constructs  . . . . . . . . . . . . . . . . . . . . .  12
58	   4.   Atom Element Definitions . . . . . . . . . . . . . . . . . .  13
59	     4.1  Container Elements . . . . . . . . . . . . . . . . . . . .  13
60	       4.1.1  The "atom:feed" Element  . . . . . . . . . . . . . . .  13
61	       4.1.2  The "atom:entry" Element . . . . . . . . . . . . . . .  15
62	       4.1.3  The "atom:content" Element . . . . . . . . . . . . . .  17
63	     4.2  Metadata Elements  . . . . . . . . . . . . . . . . . . . .  20
64	       4.2.1  The "atom:author" Element  . . . . . . . . . . . . . .  20
65	       4.2.2  The "atom:category" Element  . . . . . . . . . . . . .  20
66	       4.2.3  The "atom:contributor" Element . . . . . . . . . . . .  21
67	       4.2.4  The "atom:generator" Element . . . . . . . . . . . . .  21
68	       4.2.5  The "atom:icon" Element  . . . . . . . . . . . . . . .  21
69	       4.2.6  The "atom:id" Element  . . . . . . . . . . . . . . . .  22
70	       4.2.7  The "atom:link" Element  . . . . . . . . . . . . . . .  24
71	       4.2.8  The "atom:logo" Element  . . . . . . . . . . . . . . .  26
72	       4.2.9  The "atom:published" Element . . . . . . . . . . . . .  26
73	       4.2.10   The "atom:rights" Element  . . . . . . . . . . . . .  26
74	       4.2.11   The "atom:source" Element  . . . . . . . . . . . . .  27
75	       4.2.12   The "atom:subtitle" Element  . . . . . . . . . . . .  27
76	       4.2.13   The "atom:summary" Element . . . . . . . . . . . . .  28
77	       4.2.14   The "atom:title" Element . . . . . . . . . . . . . .  28
78	       4.2.15   The "atom:updated" Element . . . . . . . . . . . . .  28
79	   5.   Securing Atom Documents  . . . . . . . . . . . . . . . . . .  29
80	   6.   Extending Atom . . . . . . . . . . . . . . . . . . . . . . .  32
81	   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  34
82	   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  36
83	   9.   References . . . . . . . . . . . . . . . . . . . . . . . . .  38
84	     9.1  Normative References . . . . . . . . . . . . . . . . . . .  38
85	     9.2  Informative References . . . . . . . . . . . . . . . . . .  39
86	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40
87	   A.   Contributors . . . . . . . . . . . . . . . . . . . . . . . .  41
88	   B.   RELAX NG Compact Schema  . . . . . . . . . . . . . . . . . .  42
89	   C.   Change Log . . . . . . . . . . . . . . . . . . . . . . . . .  50
90	        Intellectual Property and Copyright Statements . . . . . . .  56

92	1.  Introduction

94	   Atom is an XML-based document format that describes lists of related
95	   information known as "feeds".  Feeds are composed of a number of
96	   items, known as "entries", each with an extensible set of attached
97	   metadata.  For example, each entry has a title.

99	   The primary use case that Atom addresses is the syndication of Web
100	   content such as Weblogs and news headlines to Web sites as well as
101	   directly to user agents.

103	1.1  Examples

105	   A brief, single-entry Atom Feed Document:

107	   <?xml version="1.0" encoding="utf-8"?>
108	   <feed xmlns="http://www.w3.org/2005/Atom">

110	     <title>Example Feed</title>
111	     <link href="http://example.org/"/>
112	     <updated>2003-12-13T18:30:02Z</updated>
113	     <author>
114	       <name>John Doe</name>
115	     </author>
116	     <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

118	     <entry>
119	       <title>Atom-Powered Robots Run Amok</title>
120	       <link href="http://example.org/2003/12/13/atom03"/>
121	       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
122	       <updated>2003-12-13T18:30:02Z</updated>
123	       <summary>Some text.</summary>
124	     </entry>

126	   </feed>
127	   A more extensive, single-entry Atom Feed Document:

129	   <?xml version="1.0" encoding="utf-8"?>
130	   <feed xmlns="http://www.w3.org/2005/Atom">
131	     <title type="text">dive into mark</title>
132	     <subtitle type="html">
133	       A &lt;em&gt;lot&lt;/em&gt; of effort
134	       went into making this effortless
135	     </subtitle>
136	     <updated>2005-07-31T12:29:29Z</updated>
137	     <id>tag:example.org,2003:3</id>
138	     <link rel="alternate" type="text/html"
139	      hreflang="en" href="http://example.org/"/>
140	     <link rel="self" type="application/atom+xml"
141	      href="http://example.org/feed.atom"/>
142	     <rights>Copyright (c) 2003, Mark Pilgrim</rights>
143	     <generator uri="http://www.example.com/" version="1.0">
144	       Example Toolkit
145	     </generator>
146	     <entry>
147	       <title>Atom draft-07 snapshot</title>
148	       <link rel="alternate" type="text/html"
149	        href="http://example.org/2005/04/02/atom"/>
150	       <link rel="enclosure" type="audio/mpeg" length="1337"
151	        href="http://example.org/audio/ph34r_my_podcast.mp3"/>
152	       <id>tag:example.org,2003:3.2397</id>
153	       <updated>2005-07-31T12:29:29Z</updated>
154	       <published>2003-12-13T08:29:29-04:00</published>
155	       <author>
156	         <name>Mark Pilgrim</name>
157	         <uri>http://example.org/</uri>
158	         <email>f8dy@example.com</email>
159	       </author>
160	       <contributor>
161	         <name>Sam Ruby</name>
162	       </contributor>
163	       <contributor>
164	         <name>Joe Gregorio</name>
165	       </contributor>
166	       <content type="xhtml" xml:lang="en"
167	        xml:base="http://diveintomark.org/">
168	         <div xmlns="http://www.w3.org/1999/xhtml">
169	           <p><i>[Update: The Atom draft is finished.]</i></p>
170	         </div>
171	       </content>
172	     </entry>
173	   </feed>

175	1.2  Namespace and Version

177	   The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML data
178	   format described in this specification is:

180	   http://www.w3.org/2005/Atom

182	   For convenience, this data format may be referred to as "Atom 1.0".
183	   This specification uses "Atom" internally.

185	1.3  Notational Conventions

187	   This specification describes conformance in terms of two artifacts;
188	   Atom Feed Documents and Atom Entry Documents.  Additionally, it
189	   places some requirements on Atom Processors.

191	   This specification uses the namespace prefix "atom:" for the
192	   Namespace URI identified in section 1.2. above.  Note that the choice
193	   of namespace prefix is arbitrary and not semantically significant.

195	   Atom is specified using terms from the XML Infoset [W3C.REC-xml-
196	   infoset-20040204].  However, this specification uses a shorthand for
197	   two common terms; the phrase "Information Item" is omitted when
198	   naming Element Information Items and Attribute Information Items.
199	   Therefore, when this specification uses the term "element," it is
200	   referring to an Element Information Item in Infoset terms.  Likewise,
201	   when it uses the term "attribute," it is referring to an Attribute
202	   Information Item.

204	   Some sections of this specification are illustrated with fragments of
205	   a non-normative RELAX NG Compact schema [RELAX-NG].  However, the
206	   text of this specification provides the definition of conformance.  A
207	   complete schema appears in Appendix B.

209	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
210	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
211	   document are to be interpreted as described in BCP 14, [RFC2119], as
212	   scoped to those conformance targets.

214	2.  Atom Documents

216	   This specification describes two kinds of Atom Documents; Atom Feed
217	   Documents and Atom Entry Documents.

219	   An Atom Feed Document is a representation of an Atom feed, including
220	   metadata about the feed, and some or all of the entries associated
221	   with it.  Its root is the atom:feed element.

223	   An Atom Entry Document represents exactly one Atom entry, outside of
224	   the context of an Atom feed.  Its root is the atom:entry element.

226	   namespace atom = "http://www.w3.org/2005/Atom"
227	   start = atomFeed | atomEntry

229	   Both kinds of Atom Documents are specified in terms of the XML
230	   Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and
231	   identified with the "application/atom+xml" media type.  Atom
232	   Documents MUST be well-formed XML.  This specification does not
233	   define a DTD for Atom Documents, and hence does not require them to
234	   be valid (in the sense used by XML).

236	   Atom allows the use of IRIs [RFC3987].  Every URI [RFC3986] is also
237	   an IRI, so a URI may be used wherever below an IRI is named.  There
238	   are two special considerations: when an IRI which is not also a URI
239	   is given for dereferencing, it MUST be mapped to a URI using the
240	   steps in Section 3.1 of [RFC3987]; when an IRI is serving as an
241	   atom:id value, it MUST NOT be so mapped, so that the comparison works
242	   as described in Section 4.2.6.1.

244	   Any element defined by this specification MAY have an xml:base
245	   attribute [W3C.REC-xmlbase-20010627].  When xml:base is used in an
246	   Atom Document, it serves the function described in section 5.1.1 of
247	   [RFC3986], establishing the base URI (or IRI) for resolving any
248	   relative references found within the effective scope of the xml:base
249	   attribute.

251	   Any element defined by this specification MAY have an xml:lang
252	   attribute, whose content indicates the natural language for the
253	   element and its descendents.  The language context is only
254	   significant for elements and attributes declared to be "Language-
255	   Sensitive" by this specification.  Requirements regarding the content
256	   and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-
257	   20040204], Section 2.12.

259	   atomCommonAttributes =
260	      attribute xml:base { atomUri }?,
261	      attribute xml:lang { atomLanguageTag }?,
262	      undefinedAttribute*

264	   Atom is an extensible format.  See Section 6 of this document for a
265	   full description of how Atom Documents can be extended.

267	   Atom Processors MAY keep state sourced from Atom Feed Documents and
268	   combine them with other Atom Feed Documents, in order to facilitate a
269	   contiguous view of the contents of a feed.  The manner in which Atom
270	   Feed Documents are combined in order to reconstruct a feed (e.g.,
271	   updating entries and metadata, dealing with missing entries) is out
272	   of the scope of this specification.

274	3.  Common Atom Constructs

276	   Many of Atom's elements share a few common structures.  This section
277	   defines those structures and their requirements for convenient
278	   reference by the appropriate element definitions.

280	   When an element is identified as being a particular kind of
281	   construct, it inherits the corresponding requirements from that
282	   construct's definition in this section.

284	   Note that there MUST NOT be any whitespace in a Date construct or in
285	   any IRI.  Some XML-emitting implementations erroneously insert
286	   whitespace around values by default, and such implementations will
287	   emit invalid Atom Documents.

289	3.1  Text Constructs

291	   A Text construct contains human-readable text, usually in small
292	   quantities.  The content of Text constructs is Language-Sensitive.

294	   atomPlainTextConstruct =
295	      atomCommonAttributes,
296	      attribute type { "text" | "html" }?,
297	      text

299	   atomXHTMLTextConstruct =
300	      atomCommonAttributes,
301	      attribute type { "xhtml" },
302	      xhtmlDiv

304	   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

306	3.1.1  The "type" Attribute

308	   Text constructs MAY have a "type" attribute.  When present, the value
309	   MUST be one of "text", "html" or "xhtml".  If the "type" attribute is
310	   not provided, Atom Processors MUST behave as though it were present
311	   with a value of "text".  Unlike the atom:content element defined in
312	   Section 4.1.3, MIME media types [MIMEREG] MUST NOT be used as values
313	   for the "type" attribute on Text constructs.

315	3.1.1.1  Text

317	   Example atom:title with text content:

319	   ...
320	   <title type="text">
321	     Less: &lt;
322	   </title>
323	   ...

325	   If the value is "text", the content of the Text construct MUST NOT
326	   contain child elements.  Such text is intended to be presented to
327	   humans in a readable fashion.  Thus, Atom Processors MAY collapse
328	   white-space (including line-breaks), and display the text using
329	   typographic techniques such as justification and proportional fonts.

331	3.1.1.2  HTML

333	   Example atom:title with HTML content:

335	   ...
336	   <title type="html">
337	     Less: &lt;em> &amp;lt; &lt;/em>
338	   </title>
339	   ...

341	   If the value of "type" is "html", the content of the Text construct
342	   MUST NOT contain child elements, and SHOULD be suitable for handling
343	   as HTML [HTML].  Any markup within MUST be escaped; for example,
344	   "<br>" as "&lt;br>".  HTML markup within SHOULD be such that it could
345	   validly appear directly within an HTML <DIV> element, after
346	   unescaping.  Atom Processors that display such content MAY use that
347	   markup to aid in its display.

349	3.1.1.3  XHTML

351	   Example atom:title with XHTML content:

353	   ...
354	   <title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
355	     <xhtml:div>
356	       Less: <xhtml:em> &lt; </xhtml:em>
357	     </xhtml:div>
358	   </title>
359	   ...

361	   If the value of "type" is "xhtml", the content of the Text construct
362	   MUST be a single XHTML div element [XHTML], and SHOULD be suitable
363	   for handling as XHTML.  The XHTML div element itself MUST NOT be
364	   considered part of the content.  Atom Processors that display the
365	   content MAY use the markup to aid in displaying it.  The escaped
366	   versions of characters such as "&" and ">" represent those
367	   characters, not markup.

369	   Examples of valid XHTML content:

371	   ...
372	   <summary type="xhtml">
373	      <div xmlns="http://www.w3.org/1999/xhtml">
374	         This is <b>XHTML</b> content.
375	      </div>
376	   </summary>
377	   ...
378	   <summary type="xhtml">
379	      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
380	         This is <xhtml:b>XHTML</xhtml:b> content.
381	      </xhtml:div>
382	   </summary>
383	   ...

385	   The following example assumes that the XHTML namespace has been bound
386	   to the "xh" prefix earlier in the document:

388	   ...
389	   <summary type="xhtml">
390	      <xh:div>
391	         This is <xh:b>XHTML</xh:b> content.
392	      </xh:div>
393	   </summary>
394	   ...

396	3.2  Person Constructs

398	   A Person construct is an element that describes a person,
399	   corporation, or similar entity (hereafter, 'person').

401	   atomPersonConstruct =
402	      atomCommonAttributes,
403	      (element atom:name { text }
404	       & element atom:uri { atomUri }?
405	       & element atom:email { atomEmailAddress }?
406	       & extensionElement*)

408	   This specification assigns no significance to the order of appearance
409	   of the child elements in a Person construct.  Person constructs allow
410	   extension Metadata elements (see Section 6.4).

412	3.2.1  The "atom:name" Element

414	   The "atom:name" element's content conveys a human-readable name for
415	   the person.  The content of atom:name is Language-Sensitive.  Person
416	   constructs MUST contain exactly one "atom:name" element.

418	3.2.2  The "atom:uri" Element

420	   The "atom:uri" element's content conveys an IRI associated with the
421	   person.  Person constructs MAY contain an atom:uri element, but MUST
422	   NOT contain more than one.  The content of atom:uri in a Person
423	   construct MUST be an IRI reference [RFC3987].

425	3.2.3  The "atom:email" Element

427	   The "atom:email" element's content conveys an e-mail address
428	   associated with the person.  Person constructs MAY contain an atom:
429	   email element, but MUST NOT contain more than one.  Its content MUST
430	   conform to the "addr-spec" production in [RFC2822].

432	3.3  Date Constructs

434	   A Date construct is an element whose content MUST conform to the
435	   "date-time" production in [RFC3339].  In addition, an uppercase "T"
436	   character MUST be used to separate date and time, and an uppercase
437	   "Z" character MUST be present in the absence of a numeric time zone
438	   offset.

440	   atomDateConstruct =
441	      atomCommonAttributes,
442	      xsd:dateTime

444	   Such date values happen to be compatible with the following
445	   specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and
446	   [W3C.REC-xmlschema-2-20041028].

448	   Example Date constructs:

450	   <updated>2003-12-13T18:30:02Z</updated>
451	   <updated>2003-12-13T18:30:02.25Z</updated>
452	   <updated>2003-12-13T18:30:02+01:00</updated>
453	   <updated>2003-12-13T18:30:02.25+01:00</updated>

455	   Date values SHOULD be as accurate as possible.  For example, it would
456	   be generally inappropriate for a publishing system to apply the same
457	   timestamp to several entries which were published during the course
458	   of a single day.

460	4.  Atom Element Definitions

462	4.1  Container Elements

464	4.1.1  The "atom:feed" Element

466	   The "atom:feed" element is the document (i.e., top-level) element of
467	   an Atom Feed Document, acting as a container for metadata and data
468	   associated with the feed.  Its element children consist of metadata
469	   elements followed by zero or more atom:entry child elements.

471	   atomFeed =
472	      element atom:feed {
473	         atomCommonAttributes,
474	         (atomAuthor*
475	          & atomCategory*
476	          & atomContributor*
477	          & atomGenerator?
478	          & atomIcon?
479	          & atomId
480	          & atomLink*
481	          & atomLogo?
482	          & atomRights?
483	          & atomSubtitle?
484	          & atomTitle
485	          & atomUpdated
486	          & extensionElement*),
487	         atomEntry*
488	      }

490	   This specification assigns no significance to the order of atom:entry
491	   elements within the feed.

493	   The following child elements are defined by this specification (note
494	   that the presence of some of these elements is required):

496	   o  atom:feed elements MUST contain one or more atom:author elements,
497	      unless all of the atom:feed element's child atom:entry elements
498	      contain at least one atom:author element.

500	   o  atom:feed elements MAY contain any number of atom:category
501	      elements.

503	   o  atom:feed elements MAY contain any number of atom:contributor
504	      elements.

506	   o  atom:feed elements MUST NOT contain more than one atom:generator
507	      element.

509	   o  atom:feed elements MUST NOT contain more than one atom:icon
510	      element.

512	   o  atom:feed elements MUST NOT contain more than one atom:logo
513	      element.

515	   o  atom:feed elements MUST contain exactly one atom:id element.

517	   o  atom:feed elements SHOULD contain one atom:link element with a rel
518	      attribute value of "self".  This is the preferred URI for
519	      retrieving Atom Feed Documents representing this Atom feed.

521	   o  atom:feed elements MUST NOT contain more than one atom:link
522	      element with a rel attribute value of "alternate" that has the
523	      same combination of type and hreflang attribute values.

525	   o  atom:feed elements MAY contain additional atom:link elements
526	      beyond those described above.

528	   o  atom:feed elements MUST NOT contain more than one atom:rights
529	      element.

531	   o  atom:feed elements MUST NOT contain more than one atom:subtitle
532	      element.

534	   o  atom:feed elements MUST contain exactly one atom:title element.

536	   o  atom:feed elements MUST contain exactly one atom:updated element.

538	   If multiple atom:entry elements with the same atom:id value appear in
539	   an Atom Feed Document, they represent the same entry.  Their atom:
540	   updated timestamps SHOULD be different.  If an Atom Feed Document
541	   contains multiple entries with the same atom:id, Atom Processors MAY
542	   choose to display all of them or some subset of them.  One typical
543	   behavior would be to display only the entry with the latest atom:
544	   updated timestamp.

546	4.1.1.1  Providing Textual Content

548	   Experience teaches that feeds which contain textual content are in
549	   general more useful than those which do not.  Some applications (one
550	   example is full-text indexers) require a minimum amount of text or
551	   (X)HTML to function reliably and predictably.  Feed producers should
552	   be aware of these issues.  It is advisable that each atom:entry
553	   element contain a non-empty atom:title element, a non-empty atom:
554	   content element when that element is present, and a non-empty atom:
555	   summary element when the entry contains no atom:content element.
556	   However, the absence of atom:summary is not an error and Atom
557	   Processors MUST NOT fail to function correctly as a consequence of
558	   such an absence.

560	4.1.2  The "atom:entry" Element

562	   The "atom:entry" element represents an individual entry, acting as a
563	   container for metadata and data associated with the entry.  This
564	   element can appear as a child of the atom:feed element, or it can
565	   appear as the document (i.e., top-level) element of a standalone Atom
566	   Entry Document.

568	   atomEntry =
569	      element atom:entry {
570	         atomCommonAttributes,
571	         (atomAuthor*
572	          & atomCategory*
573	          & atomContent?
574	          & atomContributor*
575	          & atomId
576	          & atomLink*
577	          & atomPublished?
578	          & atomRights?
579	          & atomSource?
580	          & atomSummary?
581	          & atomTitle
582	          & atomUpdated
583	          & extensionElement*)
584	      }

586	   This specification assigns no significance to the order of appearance
587	   of the child elements of atom:entry.

589	   The following child elements are defined by this specification (note
590	   that it requires the presence of some of these elements):

592	   o  atom:entry elements MUST contain one or more atom:author elements,
593	      unless the atom:entry contains an atom:source element which
594	      contains an atom:author element, or, in an Atom Feed Document, the
595	      atom:feed element contains an atom:author element itself.

597	   o  atom:entry elements MAY contain any number of atom:category
598	      elements.

600	   o  atom:entry elements MUST NOT contain more than one atom:content
601	      element.

603	   o  atom:entry elements MAY contain any number of atom:contributor
604	      elements.

606	   o  atom:entry elements MUST contain exactly one atom:id element.

608	   o  atom:entry elements that contain no child atom:content element
609	      MUST contain at least one atom:link element with a rel attribute
610	      value of "alternate".

612	   o  atom:entry elements MUST NOT contain more than one atom:link
613	      element with a rel attribute value of "alternate" that has the
614	      same combination of type and hreflang attribute values.

616	   o  atom:entry elements MAY contain additional atom:link elements
617	      beyond those described above.

619	   o  atom:entry elements MUST NOT contain more than one atom:published
620	      element.

622	   o  atom:entry elements MUST NOT contain more than one atom:rights
623	      element.

625	   o  atom:entry elements MUST NOT contain more than one atom:source
626	      element.

628	   o  atom:entry elements MUST contain an atom:summary element in either
629	      of the following cases:

631	      *  the atom:entry contains an atom:content that has a "src"
632	         attribute (and is thus empty).

634	      *  the atom:entry contains content that is encoded in Base64; i.e.
635	         the "type" attribute of atom:content is a MIME media type
636	         [MIMEREG], but is not an XML media type [RFC3023], does not
637	         begin with "text/", and does not end with "/xml" or "+xml".

639	   o  atom:entry elements MUST NOT contain more than one atom:summary
640	      element.

642	   o  atom:entry elements MUST contain exactly one atom:title element.

644	   o  atom:entry elements MUST contain exactly one atom:updated element.

646	4.1.3  The "atom:content" Element

648	   The "atom:content" element either contains or links to the content of
649	   the entry.  The content of atom:content is Language-Sensitive.

651	   atomInlineTextContent =
652	      element atom:content {
653	         atomCommonAttributes,
654	         attribute type { "text" | "html" }?,
655	         (text)*
656	      }

658	   atomInlineXHTMLContent =
659	      element atom:content {
660	         atomCommonAttributes,
661	         attribute type { "xhtml" },
662	         xhtmlDiv
663	      }

665	   atomInlineOtherContent =
666	      element atom:content {
667	         atomCommonAttributes,
668	         attribute type { atomMediaType }?,
669	         (text|anyElement)*
670	      }

672	   atomOutOfLineContent =
673	      element atom:content {
674	         atomCommonAttributes,
675	         attribute type { atomMediaType }?,
676	         attribute src { atomUri },
677	         empty
678	      }

680	   atomContent = atomInlineTextContent
681	    | atomInlineXHTMLContent
682	    | atomInlineOtherContent
683	    | atomOutOfLineContent

685	4.1.3.1  The "type" attribute

687	   On the atom:content element, the value of the "type" attribute MAY be
688	   one of "text", "html", or "xhtml".  Failing that, it MUST conform to
689	   the syntax of a MIME media type, but MUST NOT be a composite type
690	   (see Section 4.2.6 of [MIMEREG]).  If neither the type attribute nor
691	   the src attribute is provided, Atom Processors MUST behave as though
692	   the type attribute were present with a value of "text".

694	4.1.3.2  The "src" attribute

696	   atom:content MAY have a "src" attribute, whose value MUST be an IRI
697	   reference [RFC3987].  If the "src" attribute is present, atom:content
698	   MUST be empty.  Atom Processors MAY use the IRI to retrieve the
699	   content, and MAY chose to ignore remote content or present it in a
700	   different manner than local content.

702	   If the "src" attribute is present, the "type" attribute SHOULD be
703	   provided and MUST be a MIME media type [MIMEREG], rather than "text",
704	   "html", or "xhtml".  The value is advisory; that is to say, when the
705	   corresponding URI (mapped from an IRI, if necessary), is
706	   dereferenced, if the server providing that content also provides a
707	   media type, the server-provided media type is authoritative.

709	4.1.3.3  Processing Model

711	   Atom Documents MUST conform to the following rules.  Atom Processors
712	   MUST interpret atom:content according to the first applicable rule.

714	   1.  If the value of "type" is "text", the content of atom:content
715	       MUST NOT contain child elements.  Such text is intended to be
716	       presented to humans in a readable fashion.  Thus, Atom Processors
717	       MAY collapse white-space (including line-breaks), and display the
718	       text using typographic techniques such as justification and
719	       proportional fonts.

721	   2.  If the value of "type" is "html", the content of atom:content
722	       MUST NOT contain child elements, and SHOULD be suitable for
723	       handling as HTML [HTML].  The HTML markup MUST be escaped; for
724	       example, "<br>" as "&lt;br>".  The HTML markup SHOULD be such
725	       that it could validly appear directly within an HTML <DIV>
726	       element.  Atom Processors that display the content MAY use the
727	       markup to aid in displaying it.

729	   3.  If the value of "type" is "xhtml", the content of atom:content
730	       MUST be a single XHTML div element [XHTML], and SHOULD be
731	       suitable for handling as XHTML.  The XHTML div element itself
732	       MUST NOT be considered part of the content.  Atom Processors that
733	       display the content MAY use the markup to aid in displaying it.
734	       The escaped versions of characters such as "&" and ">" represent
735	       those characters, not markup.

737	   4.  If the value of "type" is an XML media type [RFC3023], or ends
738	       with "+xml" or "/xml" (case-insensitive), the content of
739	       atom:content MAY include child elements, and SHOULD be suitable
740	       for handling as the indicated media type.  If the "src" attribute
741	       is not provided, this would normally mean that the "atom:content"
742	       element would contain a single child element which would serve as
743	       the root element of the XML document of the indicated type.

745	   5.  If the value of "type" begins with "text/" (case-insensitive),
746	       the content of atom:content MUST NOT contain child elements.

748	   6.  For all other values of "type", the content of atom:content MUST
749	       be a valid Base64 encoding, as described in [RFC3548], section 3.
750	       When decoded, it SHOULD be suitable for handling as the indicated
751	       media type.  In this case, the characters in the Base64 encoding
752	       MAY be preceded and followed in the atom:content element by
753	       white-space, and lines are separated by a single newline (U+000A)
754	       character.

756	4.1.3.4  Examples

758	   XHTML inline:

760	   ...
761	   <content type="xhtml">
762	      <div xmlns="http://www.w3.org/1999/xhtml">
763	         This is <b>XHTML</b> content.
764	      </div>
765	   </content>
766	   ...
767	   <content type="xhtml">
768	      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
769	         This is <xhtml:b>XHTML</xhtml:b> content.
770	      </xhtml:div>
771	   </content>
772	   ...

774	   The following example assumes that the XHTML namespace has been bound
775	   to the "xh" prefix earlier in the document:

777	   ...
778	   <content type="xhtml">
779	      <xh:div>
780	         This is <xh:b>XHTML</xh:b> content.
781	      </xh:div>
782	   </content>
783	   ...

785	4.2  Metadata Elements

787	4.2.1  The "atom:author" Element

789	   The "atom:author" element is a Person construct that indicates the
790	   author of the entry or feed.

792	   atomAuthor = element atom:author { atomPersonConstruct }

794	   If an atom:entry element does not contain atom:author elements, then
795	   the atom:author elements of the contained atom:source element are
796	   considered to apply.  In an Atom Feed Document, the atom:author
797	   elements of the containing atom:feed element are considered to apply
798	   to the entry if there are no atom:author elements in the locations
799	   described above.

801	4.2.2  The "atom:category" Element

803	   The "atom:category" element conveys information about a category
804	   associated with an entry or feed.  This specification assigns no
805	   meaning to the content (if any) of this element.

807	   atomCategory =
808	      element atom:category {
809	         atomCommonAttributes,
810	         attribute term { text },
811	         attribute scheme { atomUri }?,
812	         attribute label { text }?,
813	         undefinedContent
814	      }

816	4.2.2.1  The "term" Attribute

818	   The "term" attribute is a string that identifies the category to
819	   which the entry or feed belongs.  Category elements MUST have a
820	   "term" attribute.

822	4.2.2.2  The "scheme" Attribute

824	   The "scheme" attribute is an IRI that identifies a categorization
825	   scheme.  Category elements MAY have a "scheme" attribute.

827	4.2.2.3  The "label" attribute

829	   The "label" attribute provides a human-readable label for display in
830	   end-user applications.  The content of the "label" attribute is
831	   Language-Sensitive.  Entities such as "&amp;" and "&lt;" represent
832	   their corresponding characters ("&" and "<" respectively), not
833	   markup.  Category elements MAY have a "label" attribute.

835	4.2.3  The "atom:contributor" Element

837	   The "atom:contributor" element is a Person construct that indicates a
838	   person or other entity who contributed to the entry or feed.

840	   atomContributor = element atom:contributor { atomPersonConstruct }

842	4.2.4  The "atom:generator" Element

844	   The "atom:generator" element's content identifies the agent used to
845	   generate a feed, for debugging and other purposes.

847	   atomGenerator = element atom:generator {
848	      atomCommonAttributes,
849	      attribute uri { atomUri }?,
850	      attribute version { text }?,
851	      text
852	   }

854	   The content of this element, when present, MUST be a string that is a
855	   human-readable name for the generating agent.  Entities such as
856	   "&amp;" and "&lt;" represent their corresponding characters ("&" and
857	   "<" respectively), not markup.

859	   The atom:generator element MAY have a "uri" attribute whose value
860	   MUST be an IRI reference [RFC3987].  When dereferenced, the resulting
861	   URI (mapped from an IRI, if necessary) SHOULD produce a
862	   representation that is relevant to that agent.

864	   The atom:generator element MAY have a "version" attribute that
865	   indicates the version of the generating agent.

867	4.2.5  The "atom:icon" Element

869	   The "atom:icon" element's content is an IRI reference [RFC3987] which
870	   identifies an image which provides iconic visual identification for a
871	   feed.

873	   atomIcon = element atom:icon {
874	      atomCommonAttributes,
875	      (atomUri)
876	   }

878	   The image SHOULD have an aspect ratio of one (horizontal) to one
879	   (vertical), and SHOULD be suitable for presentation at a small size.

881	4.2.6  The "atom:id" Element

883	   The "atom:id" element conveys a permanent, universally unique
884	   identifier for an entry or feed.

886	   atomId = element atom:id {
887	      atomCommonAttributes,
888	      (atomUri)
889	   }

891	   Its content MUST be an IRI, as defined by [RFC3987].  Note that the
892	   definition of "IRI" excludes relative references.  Though the IRI
893	   might use a dereferencable scheme, Atom Processors MUST NOT assume it
894	   can be dereferenced.

896	   When an Atom Document is relocated, migrated, syndicated,
897	   republished, exported or imported, the content of its atom:id element
898	   MUST NOT change.  Put another way, an atom:id element pertains to all
899	   instantiations of a particular Atom entry or feed; revisions retain
900	   the same content in their atom:id elements.  It is suggested that the
901	   atom:id element be stored along with the associated resource.

903	   The content of an atom:id element MUST be created in a way that
904	   assures uniqueness.

906	   Because of the risk of confusion between IRIs that would be
907	   equivalent if mapped to URIs and dereferenced, the following
908	   normalization strategy SHOULD be applied when generating atom:id
909	   elements:

911	   o  Provide the scheme in lowercase characters.

913	   o  Provide the host, if any, in lowercase characters.

915	   o  Only perform percent-encoding where it is essential.

917	   o  Use uppercase A-through-F characters when percent-encoding.

919	   o  Prevent dot-segments appearing in paths.

921	   o  For schemes that define a default authority, use an empty
922	      authority if the default is desired.

924	   o  For schemes that define an empty path to be equivalent to a path
925	      of "/", use "/".

927	   o  For schemes that define a port, use an empty port if the default
928	      is desired.

930	   o  Preserve empty fragment identifiers and queries.

932	   o  Ensure that all components of the IRI are appropriately character-
933	      normalized, e.g. by using NFC or NFKC.

935	4.2.6.1  Comparing atom:id

937	   Instances of atom:id elements can be compared to determine whether an
938	   entry or feed is the same as one seen before.  Processors MUST
939	   compare atom:id elements on a character-by-character basis (in a
940	   case-sensitive fashion).  Comparison operations MUST be based solely
941	   on the IRI character strings, and MUST NOT rely on dereferencing the
942	   IRIs or URIs mapped from them.

944	   As a result, two IRIs that resolve to the same resource but are not
945	   character-for-character identical will be considered different for
946	   the purposes of identifier comparison.

948	   For example, these are four distinct identifiers, despite the fact
949	   that they differ only in case:

951	      http://www.example.org/thing

953	      http://www.example.org/Thing

955	      http://www.EXAMPLE.org/thing

957	      HTTP://www.example.org/thing

959	   Likewise, these are three distinct identifiers, because IRI
960	   %-escaping is significant for the purposes of comparison:

962	      http://www.example.com/~bob

964	      http://www.example.com/%7ebob

966	      http://www.example.com/%7Ebob

968	4.2.7  The "atom:link" Element

970	   The "atom:link" element defines a reference from an entry or feed to
971	   a Web resource.  This specification assigns no meaning to the content
972	   (if any) of this element.

974	   atomLink =
975	      element atom:link {
976	         atomCommonAttributes,
977	         attribute href { atomUri },
978	         attribute rel { atomNCName | atomUri }?,
979	         attribute type { atomMediaType }?,
980	         attribute hreflang { atomLanguageTag }?,
981	         attribute title { text }?,
982	         attribute length { text }?,
983	         undefinedContent
984	      }

986	4.2.7.1  The "href" Attribute

988	   The "href" attribute contains the link's IRI. atom:link elements MUST
989	   have a href attribute, whose value MUST be a IRI reference [RFC3987].

991	4.2.7.2  The "rel" Attribute

993	   atom:link elements MAY have a "rel" attribute that indicates the link
994	   relation type.  If the "rel" attribute is not present, the link
995	   element MUST be interpreted as if the link relation type is
996	   "alternate".

998	   The value of "rel" MUST be a string that is non-empty, and matches
999	   either the "isegment-nz-nc" or the "IRI" production in [RFC3987].
1000	   Note that use of a relative reference other than a simple name is not
1001	   allowed.  If a name is given, implementations MUST consider the link
1002	   relation type to be equivalent to the same name registered within the
1003	   IANA Registry of Link Relations (Section 7), and thus the IRI that
1004	   would be obtained by appending the value of the rel attribute to the
1005	   string "http://www.iana.org/assignments/relation/".  The value of
1006	   "rel" describes the meaning of the link, but does not impose any
1007	   behavioral requirements on Atom Processors.

1009	   This document defines five initial values for the Registry of Link
1010	   Relations:

1012	   1.  The value "alternate" signifies that the IRI in the value of the
1013	       href attribute identifies an alternate version of the resource
1014	       described by the containing element.

1016	   2.  The value "related" signifies that the IRI in the value of the
1017	       href attribute identifies a resource related to the resource
1018	       described by the containing element.  For example, the feed for a
1019	       site that discusses the performance of the search engine at
1020	       "http://search.example.com" might contain, as a child of
1021	       atom:feed:

1023	       <link rel="related" href="http://search.example.com/"/>

1025	       An identical link might appear as a child of any atom:entry whose
1026	       content contains a discussion of that same search engine.

1028	   3.  The value "self" signifies that the IRI in the value of the href
1029	       attribute identifies a resource equivalent to the containing
1030	       element.

1032	   4.  The value "enclosure" signifies that the IRI in the value of the
1033	       href attribute identifies a related resource which is potentially
1034	       large in size and might require special handling.  For atom:link
1035	       elements with rel="enclosure", the length attribute SHOULD be
1036	       provided.

1038	   5.  The value "via" signifies that the IRI in the value of the href
1039	       attribute identifies a resource that is the source of the
1040	       information provided in the containing element.

1042	4.2.7.3  The "type" Attribute

1044	   On the link element, the "type" attribute's value is an advisory
1045	   media type; it is a hint about the type of the representation that is
1046	   expected to be returned when the value of the href attribute is
1047	   dereferenced.  Note that the type attribute does not override the
1048	   actual media type returned with the representation.  Link elements
1049	   MAY have a type attribute, whose value MUST conform to the syntax of
1050	   a MIME media type [MIMEREG].

1052	4.2.7.4  The "hreflang" Attribute

1054	   The "hreflang" attribute's content describes the language of the
1055	   resource pointed to by the href attribute.  When used together with
1056	   the rel="alternate", it implies a translated version of the entry.
1057	   Link elements MAY have an hreflang attribute, whose value MUST be a
1058	   language tag [RFC3066].

1060	4.2.7.5  The "title" Attribute

1062	   The "title" attribute conveys human-readable information about the
1063	   link.  The content of the "title" attribute is Language-Sensitive.
1064	   Entities such as "&amp;" and "&lt;" represent their corresponding
1065	   characters ("&" and "<" respectively), not markup.  Link elements MAY
1066	   have a title attribute.

1068	4.2.7.6  The "length" Attribute

1070	   The "length" attribute indicates an advisory length of the linked
1071	   content in octets; it is a hint about the content length of the
1072	   representation returned when the IRI in the href attribute is mapped
1073	   to a URI and dereferenced.  Note that the length attribute does not
1074	   override the actual content length of the representation as reported
1075	   by the underlying protocol.  Link elements MAY have a length
1076	   attribute.

1078	4.2.8  The "atom:logo" Element

1080	   The "atom:logo" element's content is an IRI reference [RFC3987] which
1081	   identifies an image which provides visual identification for a feed.

1083	   atomLogo = element atom:logo {
1084	      atomCommonAttributes,
1085	      (atomUri)
1086	   }

1088	   The image SHOULD have an aspect ratio of 2 (horizontal) to 1
1089	   (vertical).

1091	4.2.9  The "atom:published" Element

1093	   The "atom:published" element is a Date construct indicating an
1094	   instant in time associated with an event early in the life cycle of
1095	   the entry.

1097	   atomPublished = element atom:published { atomDateConstruct }

1099	   Typically, atom:published will be associated with the initial
1100	   creation or first availability of the resource.

1102	4.2.10  The "atom:rights" Element

1104	   The "atom:rights" element is a Text construct that conveys
1105	   information about rights held in and over an entry or feed.

1107	   atomRights = element atom:rights { atomTextConstruct }

1109	   The atom:rights element SHOULD NOT be used to convey machine-readable
1110	   licensing information.

1112	   If an atom:entry element does not contain an atom:rights element,
1113	   then the atom:rights element of the containing atom:feed element, if
1114	   present, is considered to apply to the entry.

1116	4.2.11  The "atom:source" Element

1118	   If an atom:entry is copied from one feed into another feed, then the
1119	   source atom:feed's metadata (all child elements of atom:feed other
1120	   than the atom:entry elements) MAY be preserved within the copied
1121	   entry by adding an atom:source child element, if it is not already
1122	   present in the entry, and including some or all of the source feed's
1123	   Metadata elements as the atom:source element's children.  Such
1124	   metadata SHOULD be preserved if the source atom:feed contains any of
1125	   the child elements atom:author, atom:contributor, atom:rights, or
1126	   atom:category and those child elements are not present in the source
1127	   atom:entry.

1129	   atomSource =
1130	      element atom:source {
1131	         atomCommonAttributes,
1132	         (atomAuthor*
1133	          & atomCategory*
1134	          & atomContributor*
1135	          & atomGenerator?
1136	          & atomIcon?
1137	          & atomId?
1138	          & atomLink*
1139	          & atomLogo?
1140	          & atomRights?
1141	          & atomSubtitle?
1142	          & atomTitle?
1143	          & atomUpdated?
1144	          & extensionElement*)
1145	      }

1147	   The atom:source element is designed to allow the aggregation of
1148	   entries from different feeds while retaining information about an
1149	   entry's source feed.  For this reason, Atom Processors which are
1150	   performing such aggregation SHOULD include at least the required
1151	   feed-level Metadata elements (atom:id, atom:title, and atom:updated)
1152	   in the atom:source element.

1154	4.2.12  The "atom:subtitle" Element

1156	   The "atom:subtitle" element is a Text construct that conveys a human-
1157	   readable description or subtitle for a feed.

1159	   atomSubtitle = element atom:subtitle { atomTextConstruct }

1161	4.2.13  The "atom:summary" Element

1163	   The "atom:summary" element is a Text construct that conveys a short
1164	   summary, abstract, or excerpt of an entry.

1166	   atomSummary = element atom:summary { atomTextConstruct }

1168	   It is not advisable for the atom:summary element to duplicate atom:
1169	   title or atom:content, because Atom Processors might assume there is
1170	   a useful summary when there is none.

1172	4.2.14  The "atom:title" Element

1174	   The "atom:title" element is a Text construct that conveys a human-
1175	   readable title for an entry or feed.

1177	   atomTitle = element atom:title { atomTextConstruct }

1179	4.2.15  The "atom:updated" Element

1181	   The "atom:updated" element is a Date construct indicating the most
1182	   recent instant in time when an entry or feed was modified in a way
1183	   the publisher considers significant.  Therefore, not all
1184	   modifications necessarily result in a changed atom:updated value.

1186	   atomUpdated = element atom:updated { atomDateConstruct }

1188	   Publishers MAY change the value of this element over time.

1190	5.  Securing Atom Documents

1192	   Because Atom is an XML-based format, existing XML security mechanisms
1193	   can be used to secure its content.

1195	   Producers of feeds and/or entries, and intermediaries who aggregate
1196	   feeds and/or entries, may have sound reasons for signing and/or
1197	   encrypting otherwise-unprotected content.  For example, a merchant
1198	   might digitally sign a message that contains a discount coupon for
1199	   its products.  A bank that uses Atom to deliver customer statements
1200	   is very likely to want to sign and encrypt those messages to protect
1201	   their customers' financial information and to assure the customer of
1202	   their authenticity.  Intermediaries may want to encrypt aggregated
1203	   feeds so that a passive observer cannot tell what topics the
1204	   recipient is interested in.  Of course, many other examples exist as
1205	   well.

1207	   The algorithm requirements in this section pertain to the Atom
1208	   Processor.  They require that a recipient, at a minimum, be able to
1209	   handle messages that use the specified cryptographic algorithms.
1210	   These requirements do not limit the algorithms that the sender can
1211	   choose.

1213	5.1  Digital Signatures

1215	   The root of an Atom Document (i.e., atom:feed in an Atom Feed
1216	   Document, atom:entry in an Atom Entry Document), or any atom:entry
1217	   element, MAY have an Enveloped Signature, as described by XML-
1218	   Signature and Syntax Processing [W3C.REC-xmldsig-core-20020212].

1220	   Atom Processors MUST NOT reject an Atom Document containing such a
1221	   signature because they are not capable of verifying it; they MUST
1222	   continue processing and MAY inform the user of their failure to
1223	   validate the signature.

1225	   In other words, the presence of an element with the namespace URI
1226	   "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature"
1227	   as a child of the document element MUST NOT cause an Atom Processor
1228	   to fail merely because of its presence.

1230	   Other elements in an Atom Document MUST NOT be signed unless their
1231	   definitions explicitly specify such a capability.

1233	   Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support for
1234	   Canonical XML [W3C.REC-xml-c14n-20010315].  However, many
1235	   implementers do not use it because signed XML documents enclosed in
1236	   other XML documents have their signatures broken.  Thus, Atom
1237	   Processors that verify signed Atom Documents MUST be able to
1238	   canonicalize with the exclusive XML canonicalization method
1239	   identified by the URI "http://www.w3.org/2001/10/xml-exc-c14n#", as
1240	   specified in Exclusive XML Canonicalization [W3C.REC-xml-exc-c14n-
1241	   20020718].

1243	   Intermediaries such as aggregators may need to add an atom:source
1244	   element to an entry that does not contain its own atom:source
1245	   element.  If such an entry is signed, the addition will break the
1246	   signature.  Thus, a publisher of individually-signed entries should
1247	   strongly consider adding an atom:source element to those entries
1248	   before signing them.  Implementors should also be aware of the issues
1249	   concerning the use of markup in the "xml:" namespace as it interacts
1250	   with canonicalization.

1252	   Section 4.4.2 of [W3C.REC-xmldsig-core-20020212] requires support for
1253	   DSA signatures and recommends support for RSA signatures.  However,
1254	   because of the much greater popularity in the market of RSA versus
1255	   DSA, Atom Processors that verify signed Atom Documents MUST be able
1256	   to verify RSA signatures, but do not need be able to verify DSA
1257	   signatures.  Due to security issues that can arise if the keying
1258	   material for MAC (message authentication code) authentication is not
1259	   handled properly, Atom Documents SHOULD NOT use MACs for signatures.

1261	5.2  Encryption

1263	   The root of an Atom Document (i.e., atom:feed in an Atom Feed
1264	   Document, atom:entry in an Atom Entry Document) MAY be encrypted,
1265	   using the mechanisms described by XML Encryption Syntax and
1266	   Processing [W3C.REC-xmlenc-core-20021210].

1268	   Section 5.1 of [W3C.REC-xmlenc-core-20021210] requires support of
1269	   TripleDES, AES-128, and AES-256.  Atom Processors that decrypt Atom
1270	   Documents MUST be able to decrypt with AES-128 in CBC mode.

1272	   Encryption based on [W3C.REC-xmlenc-core-20021210] does not assure
1273	   integrity of the original document.  There are known cryptographic
1274	   attacks where someone who cannot decrypt a message can still change
1275	   bits in a way where part or all the decrypted message makes sense but
1276	   has a different meaning.  Thus, Atom Processors that decrypt Atom
1277	   Documents SHOULD check the integrity of the decrypted document by
1278	   verifying the hash in the signature (if any) in the document, or by
1279	   verifying a hash of the document within the document (if any).

1281	5.3  Signing and Encrypting

1283	   When an Atom Document is to be both signed and encrypted, it is
1284	   generally a good idea to first sign the document, then encrypt the
1285	   signed document.  This provides integrity to the base document while
1286	   encrypting all the information, including the identity of the entity
1287	   that signed the document.  Note that, if MACs are used for
1288	   authentication, the order MUST be that the signed document is
1289	   encrypted, and not the other way around.

1291	6.  Extending Atom

1293	6.1  Extensions From Non-Atom Vocabularies

1295	   This specification describes Atom's XML markup vocabulary.  Markup
1296	   from other vocabularies ("foreign markup") can be used in an Atom
1297	   Document.  Note that the atom:content element is designed to support
1298	   the inclusion of arbitrary foreign markup.

1300	6.2  Extensions To the Atom Vocabulary

1302	   The Atom namespace is reserved for future forwards-compatible
1303	   revisions of Atom.  Future versions of this specification could add
1304	   new elements and attributes to the Atom markup vocabulary.  Software
1305	   written to conform to this version of the specification will not be
1306	   able to process such markup correctly and, in fact, will not be able
1307	   to distinguish it from markup error.  For the purposes of this
1308	   discussion, unrecognized markup from the Atom vocabulary will be
1309	   considered "foreign markup".

1311	6.3  Processing Foreign Markup

1313	   Atom Processors which encounter foreign markup in a location that is
1314	   legal according to this specification MUST NOT stop processing or
1315	   signal an error.  It might be the case that the Atom Processor is
1316	   able to process the foreign markup correctly and does so.  Otherwise,
1317	   such markup is termed "unknown foreign markup".

1319	   When unknown foreign markup is encountered as a child of atom:entry,
1320	   atom:feed, or a Person construct, Atom Processors MAY bypass the
1321	   markup and any textual content and MUST NOT change their behavior as
1322	   a result of the markup's presence.

1324	   When unknown foreign markup is encountered in a Text Construct or
1325	   atom:content element, software SHOULD ignore the markup and process
1326	   any text content of foreign elements as though the surrounding markup
1327	   were not present.

1329	6.4  Extension Elements

1331	   Atom allows foreign markup anywhere in an Atom document, except where
1332	   it is explicitly forbidden.  Child elements of atom:entry, atom:feed,
1333	   atom:source, and Person constructs are considered Metadata elements,
1334	   and are described below.  Child elements of Person constructs are
1335	   considered to apply to the construct.  The role of other foreign
1336	   markup is undefined by this specification.

1338	6.4.1  Simple Extension Elements

1340	   A Simple Extension element MUST NOT have any attributes or child
1341	   elements.  The element MAY contain character data, or be empty.
1342	   Simple Extension elements are not Language-Sensitive.

1344	   simpleExtensionElement =
1345	      element * - atom:* {
1346	         text
1347	      }

1349	   The element can be interpreted as a simple property (or name/value
1350	   pair) of the parent element that encloses it.  The pair consisting of
1351	   the namespace-URI of the element and the local name of the element
1352	   can be interpreted as the name of the property.  The character data
1353	   content of the element can be interpreted as the value of the
1354	   property.  If the element is empty, then the property value can be
1355	   interpreted as an empty string.

1357	6.4.2  Structured Extension Elements

1359	   The root element of a Structured Extension element MUST have at least
1360	   one attribute or child element.  It MAY have attributes, it MAY
1361	   contain well-formed XML content (including character data), or it MAY
1362	   be empty.  Structured Extension elements are Language-Sensitive.

1364	   structuredExtensionElement =
1365	      element * - atom:* {
1366	         (attribute * { text }+,
1367	            (text|anyElement)*)
1368	       | (attribute * { text }*,
1369	          (text?, anyElement+, (text|anyElement)*))
1370	      }

1372	   The structure of a Structured Extension element, including the order
1373	   of its child elements, could be significant.

1375	   This specification does not provide an interpretation of a Structured
1376	   Extension element.  The syntax of the XML contained in the element,
1377	   and an interpretation of how the element relates to its containing
1378	   element is defined by the specification of the Atom extension.

1380	7.  IANA Considerations

1382	   An Atom Document, when serialized as XML 1.0, can be identified with
1383	   the following media type:

1385	   MIME media type name: application

1387	   MIME subtype name: atom+xml

1389	   Mandatory parameters: None.

1391	   Optional parameters:

1393	      "charset": This parameter has identical semantics to the charset
1394	         parameter of the "application/xml" media type as specified in
1395	         [RFC3023].

1397	   Encoding considerations: Identical to those of "application/xml" as
1398	      described in [RFC3023], section 3.2.

1400	   Security considerations: As defined in this specification.

1402	      In addition, as this media type uses the "+xml" convention, it
1403	      shares the same security considerations as described in [RFC3023],
1404	      section 10.

1406	   Interoperability considerations: There are no known interoperability
1407	      issues.

1409	   Published specification: This specification.

1411	   Applications that use this media type: No known applications
1412	      currently use this media type.

1414	   Additional information:

1416	   Magic number(s): As specified for "application/xml" in [RFC3023],
1417	      section 3.2.

1419	   File extension: .atom

1421	   Fragment identifiers: As specified for "application/xml" in
1422	      [RFC3023], section 5.

1424	   Base URI: As specified in [RFC3023], section 6.

1426	   Macintosh File Type code: TEXT

1428	   Person and email address to contact for further information: Mark
1429	      Nottingham <mnot@pobox.com>

1431	   Intended usage: COMMON

1433	   Author/Change controller: IESG

1435	7.1  Registry of Link Relations

1437	   This registry is maintained by IANA and initially contains five
1438	   values: "alternate", "related", "self", "enclosure", and "via".  New
1439	   assignments are subject to IESG Approval, as outlined in [RFC2434].
1440	   Requests should be made by email to IANA, which will then forward the
1441	   request to the IESG requesting approval.  The request should use the
1442	   following template:

1444	   o  Attribute Value: ( A value for the "rel" attribute that conforms
1445	      to the syntax rule given in Section 4.2.7.2 )

1447	   o  Description:

1449	   o  Expected display characteristics:

1451	   o  Security considerations:

1453	8.  Security Considerations

1455	8.1  HTML and XHTML Content

1457	   Text constructs and atom:content allow the delivery of HTML and
1458	   XHTML.  Many elements in these languages are considered 'unsafe' in
1459	   that they open clients to one or more types of attack.  Implementers
1460	   of software which processes Atom should carefully consider their
1461	   handling of every type of element when processing incoming (X)HTML in
1462	   Atom Documents.  See the security sections of [RFC2854] and [HTML]
1463	   for guidance.

1465	   Atom Processors should pay particular attention to the security of
1466	   the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and
1467	   LINK elements, but other elements might also have negative security
1468	   properties.

1470	   (X)HTML can either directly contain or indirectly reference
1471	   executable content.

1473	8.2  URIs

1475	   Atom Processors handle URIs.  See Section 7 of [RFC3986].

1477	8.3  IRIs

1479	   Atom Processors handle IRIs.  See Section 8 of [RFC3987].

1481	8.4  Spoofing

1483	   Atom Processors should be aware of the potential for spoofing attacks
1484	   where the attacker publishes an atom:entry with the atom:id value of
1485	   an entry from another feed, perhaps with a falsified atom:source
1486	   element duplicating the atom:id of the other feed.  For example, an
1487	   Atom Processor could suppress display of duplicate entries by
1488	   displaying only one entry from a set of entries with identical
1489	   atom:id values.  In that situation, the Atom Processor might also
1490	   take steps to determine whether the entries originated from the same
1491	   publisher before considering them to be duplicates.

1493	8.5  Encryption and Signing

1495	   Atom Documents can be encrypted and signed using [W3C.REC-xmlenc-
1496	   core-20021210] and [W3C.REC-xmldsig-core-20020212], respectively, and
1497	   are subject to the security considerations implied by their use.

1499	   Digital signatures provide authentication, message integrity, and
1500	   non-repudiation with proof of origin.  Encryption provides data
1501	   confidentiality.

1503	9.  References

1505	9.1  Normative References

1507	   [HTML]     Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
1508	              Specification", W3C REC REC-html401-19991224,
1509	              December 1999,
1510	              <http://www.w3.org/TR/1999/REC-html401-19991224>.

1512	   [MIMEREG]  Freed, N. and J. Klensin, "Media Type Specifications and
1513	              Registration Procedures",  work-in-progress
1514	              (draft-freed-media-type-reg-04), April 2005.

1516	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1517	              Requirement Levels", BCP 14, RFC 2119, March 1997.

1519	   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822,
1520	              April 2001.

1522	   [RFC2854]  Connolly, D. and L. Masinter, "The 'text/html' Media
1523	              Type", RFC 2854, June 2000.

1525	   [RFC3023]  Murata, M., St. Laurent, S., and D. Kohn, "XML Media
1526	              Types", RFC 3023, January 2001.

1528	   [RFC3066]  Alvestrand, H., "Tags for the Identification of
1529	              Languages", BCP 47, RFC 3066, January 2001.

1531	   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
1532	              Timestamps", RFC 3339, July 2002.

1534	   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
1535	              Encodings", RFC 3548, July 2003.

1537	   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1538	              Resource Identifier (URI): Generic Syntax", STD 66,
1539	              RFC 3986, January 2005.

1541	   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
1542	              Identifiers (IRIs)", RFC 3987, January 2005.

1544	   [W3C.REC-xml-20040204]
1545	              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
1546	              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
1547	              Edition)", W3C REC REC-xml-20040204, February 2004,
1548	              <http://www.w3.org/TR/2004/REC-xml-2004020>.

1550	   [W3C.REC-xml-c14n-20010315]
1551	              Boyer, J., "Canonical XML Version 1.0", W3C REC REC-xml-
1552	              c14n-20010315, March 2001,
1553	              <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.

1555	   [W3C.REC-xml-exc-c14n-20020718]
1556	              Eastlake, D., Boyer, J., and J. Reagle, "Exclusive XML
1557	              Canonicalization Version 1.0", W3C REC REC-xml-exc-c14n-
1558	              20020718, July 2002,
1559	              <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.

1561	   [W3C.REC-xml-infoset-20040204]
1562	              Cowan, J. and R. Tobin, "XML Information Set (Second
1563	              Edition)", W3C REC REC-xml-infoset-20040204,
1564	              February 2004,
1565	              <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

1567	   [W3C.REC-xml-names-19990114]
1568	              Hollander, D., Bray, T., and A. Layman, "Namespaces in
1569	              XML", W3C REC REC-xml-names-19990114, January 1999,
1570	              <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

1572	   [W3C.REC-xmlbase-20010627]
1573	              Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627,
1574	              June 2001,
1575	              <http://www.w3.org/TR/2001/REC-xmlbase-20010627>.

1577	   [W3C.REC-xmldsig-core-20020212]
1578	              Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
1579	              Syntax and Processing", W3C REC REC-xmldsig-core-20020212,
1580	              February 2002,
1581	              <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.

1583	   [W3C.REC-xmlenc-core-20021210]
1584	              Reagle, J. and D. Eastlake, "XML Encryption Syntax and
1585	              Processing", W3C REC REC-xmlenc-core-20021210,
1586	              December 2002,
1587	              <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.

1589	   [XHTML]    Altheim, M., Boumphrey, F., McCarron, S., Dooley, S.,
1590	              Schnitzenbaumer, S., and T. Wugofski, "Modularization of
1591	              XHTML[TM]", W3C REC REC-xhtml-modularization-20010410,
1592	              April 2001, <http://www.w3.org/TR/2001/
1593	              REC-xhtml-modularization-20010410>.

1595	9.2  Informative References

1597	   [ISO.8601.1988]
1598	              International Organization for Standardization, "Data
1599	              elements and interchange formats - Information interchange
1600	              - Representation of dates and times", ISO Standard 8601,
1601	              June 1988.

1603	   [RELAX-NG]
1604	              Clark, J., "RELAX NG Compact Syntax", December 2001,
1605		      <http://www.oasis-open.org/committees/relax-ng/
1606	              compact-20021121.html>.

1608	   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
1609	              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
1610	              October 1998.

1612	   [W3C.NOTE-datetime-19980827]
1613	              Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C
1614	              NOTE NOTE-datetime-19980827, August 1998,
1615	              <http://www.w3.org/TR/1998/NOTE-datetime-19980827>.

1617	   [W3C.REC-xmlschema-2-20041028]
1618	              Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes
1619	              Second Edition", W3C REC REC-xmlschema-2-20041028,
1620	              October 2004,
1621	              <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

1623	Authors' Addresses

1625	   Mark Nottingham (editor)

1627	   Email: mnot@pobox.com
1628	   URI:   http://www.mnot.net/

1630	   Robert Sayre (editor)

1632	   Email: rfsayre@boswijck.com
1633	   URI:   http://boswijck.com

1635	Appendix A.  Contributors

1637	   The following people contributed to preliminary drafts of this
1638	   document: Tim Bray, Mark Pilgrim, and Sam Ruby.  Norman Walsh
1639	   provided the Relax NG schema.  The content and concepts within are a
1640	   product of the Atom community and the Atompub Working Group.

1642	   The Atompub Working Group has dozens of very active contributors who
1643	   proposed ideas and wording for this document, including:

1645	   Danny Ayers, James Aylett, Roger Benningfield, Arve Bersvendsen, Tim
1646	   Bray, Dan Brickley, Thomas Broyer, Robin Cover, Bill de hOra, Martin
1647	   Duerst, Roy Fielding, Joe Gregorio, Bjoern Hoehrmann, Paul Hoffman,
1648	   Anne van Kesteren, Brett Lindsley, Dare Obasanjo, David Orchard,
1649	   Aristotle Pagaltzis, John Panzer, Graham Parks, Dave Pawson, Mark
1650	   Pilgrim, David Powell, Julian Reschke, Phil Ringnalda, Antone Roundy,
1651	   Sam Ruby, Eric Scheid, Brent Simmons, Henri Sivonen, Ray Slakinski,
1652	   James Snell, Henry Story, Asbjorn Ulsberg, Walter Underwood, Norman
1653	   Walsh, Dave Winer, and Bob Wyman.

1655	Appendix B.  RELAX NG Compact Schema

1657	   This appendix is informative.

1659	   The Relax NG schema explicitly excludes elements in the Atom
1660	   namespace which are not defined in this revision of the
1661	   specification.  Requirements for Atom Processors encountering such
1662	   markup are given in Section 6.2 and Section 6.3.

1664	   # -*- rnc -*-
1665	   # RELAX NG Compact Syntax Grammar for the
1666	   # Atom Format Specification Version 11

1668	   namespace atom = "http://www.w3.org/2005/Atom"
1669	   namespace xhtml = "http://www.w3.org/1999/xhtml"
1670	   namespace s = "http://www.ascc.net/xml/schematron"
1671	   namespace local = ""

1673	   start = atomFeed | atomEntry

1675	   # Common attributes

1677	   atomCommonAttributes =
1678	      attribute xml:base { atomUri }?,
1679	      attribute xml:lang { atomLanguageTag }?,
1680	      undefinedAttribute*

1682	   # Text Constructs

1684	   atomPlainTextConstruct =
1685	      atomCommonAttributes,
1686	      attribute type { "text" | "html" }?,
1687	      text

1689	   atomXHTMLTextConstruct =
1690	      atomCommonAttributes,
1691	      attribute type { "xhtml" },
1692	      xhtmlDiv

1694	   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

1696	   # Person Construct

1698	   atomPersonConstruct =
1699	      atomCommonAttributes,
1700	      (element atom:name { text }
1701	       & element atom:uri { atomUri }?
1702	       & element atom:email { atomEmailAddress }?
1703	       & extensionElement*)

1705	   # Date Construct

1707	   atomDateConstruct =
1708	      atomCommonAttributes,
1709	      xsd:dateTime

1711	   # atom:feed

1713	   atomFeed =
1714	      [
1715	         s:rule [
1716	            context = "atom:feed"
1717	            s:assert [
1718	               test = "atom:author or not(atom:entry[not(atom:author)])"
1719	               "An atom:feed must have an atom:author unless all "
1720	               ~ "of its atom:entry children have an atom:author."
1721	            ]
1722	         ]
1723	      ]
1724	      element atom:feed {
1725	         atomCommonAttributes,
1726	         (atomAuthor*
1727	          & atomCategory*
1728	          & atomContributor*
1729	          & atomGenerator?
1730	          & atomIcon?
1731	          & atomId
1732	          & atomLink*
1733	          & atomLogo?
1734	          & atomRights?
1735	          & atomSubtitle?
1736	          & atomTitle
1737	          & atomUpdated
1738	          & extensionElement*),
1739	         atomEntry*
1740	      }

1742	   # atom:entry

1744	   atomEntry =
1745	      [
1746	         s:rule [
1747	            context = "atom:entry"
1748	            s:assert [
1749	               test = "atom:link[@rel='alternate'] "
1750	               ~ "or atom:link[not(@rel)] "
1751	               ~ "or atom:content"
1752	               "An atom:entry must have at least one atom:link element "
1753	               ~ "with a rel attribute of 'alternate' "
1754	               ~ "or an atom:content."
1755	            ]
1756	         ]
1757	         s:rule [
1758	            context = "atom:entry"
1759	            s:assert [
1760	               test = "atom:author or "
1761	               ~ "../atom:author or atom:source/atom:author"
1762	               "An atom:entry must have an atom:author "
1763	               ~ "if its feed does not."
1764	            ]
1765	         ]
1766	      ]
1767	      element atom:entry {
1768	         atomCommonAttributes,
1769	         (atomAuthor*
1770	          & atomCategory*
1771	          & atomContent?
1772	          & atomContributor*
1773	          & atomId
1774	          & atomLink*
1775	          & atomPublished?
1776	          & atomRights?
1777	          & atomSource?
1778	          & atomSummary?
1779	          & atomTitle
1780	          & atomUpdated
1781	          & extensionElement*)
1782	      }

1784	   # atom:content

1786	   atomInlineTextContent =
1787	      element atom:content {
1788	         atomCommonAttributes,
1789	         attribute type { "text" | "html" }?,
1790	         (text)*
1791	      }

1793	   atomInlineXHTMLContent =
1794	      element atom:content {
1795	         atomCommonAttributes,
1796	         attribute type { "xhtml" },
1797	         xhtmlDiv
1798	      }

1800	   atomInlineOtherContent =
1801	      element atom:content {
1802	         atomCommonAttributes,
1803	         attribute type { atomMediaType }?,
1804	         (text|anyElement)*
1805	      }

1807	   atomOutOfLineContent =
1808	      element atom:content {
1809	         atomCommonAttributes,
1810	         attribute type { atomMediaType }?,
1811	         attribute src { atomUri },
1812	         empty
1813	      }

1815	   atomContent = atomInlineTextContent
1816	    | atomInlineXHTMLContent
1817	    | atomInlineOtherContent
1818	    | atomOutOfLineContent

1820	   # atom:author

1822	   atomAuthor = element atom:author { atomPersonConstruct }

1824	   # atom:category

1826	   atomCategory =
1827	      element atom:category {
1828	         atomCommonAttributes,
1829	         attribute term { text },
1830	         attribute scheme { atomUri }?,
1831	         attribute label { text }?,
1832	         undefinedContent
1833	      }

1835	   # atom:contributor

1837	   atomContributor = element atom:contributor { atomPersonConstruct }

1839	   # atom:generator

1841	   atomGenerator = element atom:generator {
1842	      atomCommonAttributes,
1843	      attribute uri { atomUri }?,
1844	      attribute version { text }?,
1845	      text
1846	   }
1847	   # atom:icon

1849	   atomIcon = element atom:icon {
1850	      atomCommonAttributes,
1851	      (atomUri)
1852	   }

1854	   # atom:id

1856	   atomId = element atom:id {
1857	      atomCommonAttributes,
1858	      (atomUri)
1859	   }

1861	   # atom:logo

1863	   atomLogo = element atom:logo {
1864	      atomCommonAttributes,
1865	      (atomUri)
1866	   }

1868	   # atom:link

1870	   atomLink =
1871	      element atom:link {
1872	         atomCommonAttributes,
1873	         attribute href { atomUri },
1874	         attribute rel { atomNCName | atomUri }?,
1875	         attribute type { atomMediaType }?,
1876	         attribute hreflang { atomLanguageTag }?,
1877	         attribute title { text }?,
1878	         attribute length { text }?,
1879	         undefinedContent
1880	      }

1882	   # atom:published

1884	   atomPublished = element atom:published { atomDateConstruct }

1886	   # atom:rights

1888	   atomRights = element atom:rights { atomTextConstruct }

1890	   # atom:source

1892	   atomSource =
1893	      element atom:source {
1894	         atomCommonAttributes,
1895	         (atomAuthor*
1896	          & atomCategory*
1897	          & atomContributor*
1898	          & atomGenerator?
1899	          & atomIcon?
1900	          & atomId?
1901	          & atomLink*
1902	          & atomLogo?
1903	          & atomRights?
1904	          & atomSubtitle?
1905	          & atomTitle?
1906	          & atomUpdated?
1907	          & extensionElement*)
1908	      }

1910	   # atom:subtitle

1912	   atomSubtitle = element atom:subtitle { atomTextConstruct }

1914	   # atom:summary

1916	   atomSummary = element atom:summary { atomTextConstruct }

1918	   # atom:title

1920	   atomTitle = element atom:title { atomTextConstruct }

1922	   # atom:updated

1924	   atomUpdated = element atom:updated { atomDateConstruct }

1926	   # Low-level simple types

1928	   atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" }

1930	   # Whatever a media type is, it contains at least one slash
1931	   atomMediaType = xsd:string { pattern = ".+/.+" }

1933	   # As defined in RFC 3066
1934	   atomLanguageTag = xsd:string {
1935	      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
1936	   }

1938	   # Unconstrained; it's not entirely clear how IRI fit into
1939	   # xsd:anyURI so let's not try to constrain it here
1940	   atomUri = text

1942	   # Whatever an email address is, it contains at least one @
1943	   atomEmailAddress = xsd:string { pattern = ".+@.+" }

1945	   # Simple Extension

1947	   simpleExtensionElement =
1948	      element * - atom:* {
1949	         text
1950	      }

1952	   # Structured Extension

1954	   structuredExtensionElement =
1955	      element * - atom:* {
1956	         (attribute * { text }+,
1957	            (text|anyElement)*)
1958	       | (attribute * { text }*,
1959	          (text?, anyElement+, (text|anyElement)*))
1960	      }

1962	   # Other Extensibility

1964	   extensionElement =
1965	      simpleExtensionElement | structuredExtensionElement

1967	   undefinedAttribute =
1968	     attribute * - (xml:base | xml:lang | local:*) { text }

1970	   undefinedContent = (text|anyForeignElement)*

1972	   anyElement =
1973	      element * {
1974	         (attribute * { text }
1975	          | text
1976	          | anyElement)*
1977	      }

1979	   anyForeignElement =
1980	      element * - atom:* {
1981	         (attribute * { text }
1982	          | text
1983	          | anyElement)*
1984	      }

1986	   # XHTML

1988	   anyXHTML = element xhtml:* {
1989	      (attribute * { text }
1990	       | text
1991	       | anyXHTML)*
1992	   }

1994	   xhtmlDiv = element xhtml:div {
1995	      (attribute * { text }
1996	       | text
1997	       | anyXHTML)*
1998	   }

2000	   # EOF

2002	Appendix C.  Change Log

2004	   [[anchor70: This section should be removed before final
2005	   publication.]]

2007	   -10:  capitalize "Atom Document" consistently.

2009	      fix atom:feed/atom:logo

2011	      fix link hreflang/alternate in atom:feed

2013	      Add more acknowledgements

2015	      Expand security section

2017	      Clarify IRI processing

2019	   -09:  Changed atom:copyright to atom:rights.

2021	      Clarify atom:source, also reflect changes to atom:feed

2023	      Change 'minimal' to brief (PaceBriefExample).

2025	      Add text about "Atom 1.0" (PaceAtom10).

2027	      Remove SHOULD about content@src.

2029	      feed/id now required.

2031	      rework xml:base text

2033	      rework xml:lang terms and requirements

2035	      rework escaped markup explanations

2037	      change atom:image to atom:logo

2039	      Add example Date Constructs

2041	      Clarify that atom:link and atom:category MUST be empty.

2043	      Make XHTML definitions consistent

2045	      atom:icon editorial fix-- capitalize SHOULD.

2047	   -08:  Remove BNF

2049	      complete rather than collected schema

2051	      Remove a couple introductory sentences

2053	      update MIME references

2055	      Many editorial adjustments

2057	   -07:  Change atom:source-feed to atom:source.

2059	      Add ABNF reference

2061	      Many editorial tweaks

2063	      Rework extensibility

2065	      Adjust page breaks in txt version

2067	   -06:  Move Identity Construct into atom:id (only place it's used)

2069	      atom:id values must be unique within a feed.

2071	      restore atom:copyright definition mistakenly dropped during
2072	      alphabetizing.

2074	      Remove atom:head, add atom:source-feed, and "Extension Construct"
2075	      text in an effort to accurately reflect WG consensus on data model
2076	      and extensibility, acknowledging two opinions in favor of atom:
2077	      head.

2079	      Note @hreflang issue.

2081	      Add comment on atom:entry/atom:summary requirements.

2083	      Rework atom:id text.  The dereferencing section didn't talk about
2084	      dereferencing.

2086	      Remove protocol reference.

2088	      Alphabetize where appropriate (PaceOrderSpecAlphabetically).

2090	      Add mI language (PaceExtendingAtom).

2092	      Add atom:icon and atom:image (PaceImageAndIcon).

2094	      Change atom:tagline to atom:subtitle

2096	      Add inline XHTML language (PaceXHTMLNamespaceDiv).

2098	      Change "TEXT" etc, to lowercase

2100	      Change example id IRI to urn:uuid:...

2102	      Add rel="self" (PaceFeedLink).

2104	      Add Feed State text (PaceNoFeedState).

2106	      Move to IRIs (PaceIRI).

2108	      Add rel="via" (PaceLinkRelVia).

2110	      Add rel="enclosure" (PaceEnclosuresAndPix).

2112	      Remove info and host (PaceRemoveInfoAndHost)

2114	      Clarify order of entries (PaceEntryOrder).

2116	      Remove version attribute (PaceRemoveVersionAttr).

2118	      Date format roundup (PaceDatesXSD).

2120	      Remove Service construct and elements.

2122	      fix atom:contributor cardinality typo

2124	      Removed motivation/design principles note; if we haven't come up
2125	      with them by now...

2127	      Put conformance text into notational conventions.

2129	      Removed instances of 'software'; too specific.

2131	      Added refs to HTML and XHTML.

2133	      Updated ref to Infoset.

2135	      Various editorial tweaks.

2137	      Fix RFC 3023 refs in IANA section

2139	      Adjust head/link requirement

2141	      fix @version typos

2143	   -05:  Add RNC from N. Walsh.

2145	      Re-organize element definitions.

2147	      Lift the prohibition on other types of DSig and encryption.

2149	      Remove text on "indiscriminate use" of DSig and XMLEnc.

2151	   -04:  Update URI terms for 2396bis.

2153	      Add Category construct (PaceCategoryRevised).

2155	      Insert paranoid XHTML interpretation guidelines.

2157	      Adjust atom:copyright, per chairs' instruction.

2159	      Add atom:host as child element of atom:entry, per chairs'
2160	      direction (PacePersonConstruct).

2162	      Add link/content co-constraint (PaceContentOrLink).

2164	      Remove atom:origin as a side effect of adding atom:head to atom:
2165	      entry (PaceHeadInEntry).

2167	      Add optional length attribute to atom:link (PaceLinkRelated).

2169	      Add Link registry to Link Construct, IANA Considerations
2170	      placeholder (PaceFieldingLinks).

2172	      Change definition of atom:updated (PaceUpdatedDefinition).

2174	   -03:  Move definition of Link @rel to format spec, restrict
2175	      acceptable values (PaceMoveLinkElement, PaceLinkAttrDefaults).

2177	      Add Service Construct, head/post, head/introspection, entry/edit
2178	      (PaceServiceElement).

2180	      Add Text Construct, entry/content (PaceReformedContent3).

2182	      Add entry/published (PaceDatePublished).

2184	      Adjust definition of Identity Construct per chairs' direction to
2185	      "fix it."

2187	      Add Sayre to editors.

2189	   -02:  Removed entry/modified, entry/issued, entry/created; added
2190	      entry/updated (PaceDateUpdated).

2192	      Changed date construct from W3C date-time to RFC3339
2193	      (PaceDateUpdated).

2195	      Feed links to HTML pages should be reflected back
2196	      (PaceLinkReflection).

2198	      Added Identity construct (PaceIdConstruct).

2200	      Changed feed/id and entry/id to be Identity constructs
2201	      (PaceIdConstruct).

2203	      Changed entry/origin's content so that it's the same as the feed's
2204	      id, rather than its link/@rel="alternate" (PaceIdConstruct).

2206	      Added "Securing Atom Documents" (PaceDigitalSignatures).

2208	   -01:  Constrained omission of "Information Item" to just elements and
2209	      attributes.

2211	      Clarified xml:lang inheritence.

2213	      Removed entry- and feed-specific langauge about xml:lang (covered
2214	      by general discussion of xml:lang)

2216	      Changed xml:lang to reference XML for normative requirements.

2218	      Changed "...  MUST be a string" to "... is unstructued text."

2220	      Remomved langauge about DOCTYPEs, PIs, Comments, Entities.

2222	      Changed atom:url to atom:uri, @url to @uri

2224	      Introduced atom:head

2226	      Introduced "Atom Feed Document" and "Atom Entry Document".

2228	      Removed requirement for all elements and attributes to be
2229	      namespace-qualified; now children of selective elements

2231	      Added extensibility to Person constructs.

2233	      Removed requirement for media types to be registered (non-
2234	      registered media types are legal)

2236	      Added atom:origin (PaceEntryOrigin)

2238	      Added requirement for entry/id to be present and a URI
2239	      (PaceEntryIdRequired).

2241	      Clarified approach to Comments, PIs and well-formedness, as per
2242	      RFC3470.

2244	      Referenced escaping algorithm in XML.

2246	      Assorted editorial nits and cleanup, refactoring

2248	   -00:  Initial IETF Internet-Draft submission.

2250	      Added optional version attribute to entry
2251	      (PaceEntryElementNeedsVersionAttribute).

2253	      Added hreflang attribute (PaceHrefLang).

2255	      Clarified inheritence of copyright element (PaceItemCopyright).

2257	      Added xml:lang to entries (PaceItemLang).

2259	      Tweaked Infoset-related language (PaceNoInfoSet).

2261	      Clarified lack of structure in version attribute
2262	      (PaceVersionAsText).

2264	      Changed approach to XML Base (PaceXmlBaseEverywhere).

2266	      Added XML Base processing to atom:id (PaceXmlBaseId).

2268	      Various editorial cleanup and adjustments for IETF publication.

2270	Intellectual Property Statement

2272	   The IETF takes no position regarding the validity or scope of any
2273	   Intellectual Property Rights or other rights that might be claimed to
2274	   pertain to the implementation or use of the technology described in
2275	   this document or the extent to which any license under such rights
2276	   might or might not be available; nor does it represent that it has
2277	   made any independent effort to identify any such rights.  Information
2278	   on the procedures with respect to rights in RFC documents can be
2279	   found in BCP 78 and BCP 79.

2281	   Copies of IPR disclosures made to the IETF Secretariat and any
2282	   assurances of licenses to be made available, or the result of an
2283	   attempt made to obtain a general license or permission for the use of
2284	   such proprietary rights by implementers or users of this
2285	   specification can be obtained from the IETF on-line IPR repository at
2286	   http://www.ietf.org/ipr.

2288	   The IETF invites any interested party to bring to its attention any
2289	   copyrights, patents or patent applications, or other proprietary
2290	   rights that may cover technology that may be required to implement
2291	   this standard.  Please address the information to the IETF at
2292	   ietf-ipr@ietf.org.

2294	Disclaimer of Validity

2296	   This document and the information contained herein are provided on an
2297	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2298	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2299	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2300	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2301	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2302	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

2304	Copyright Statement

2306	   Copyright (C) The Internet Society (2005).  This document is subject
2307	   to the rights, licenses and restrictions contained in BCP 78, and
2308	   except as set forth therein, the authors retain all their rights.

2310	Acknowledgment

2312	   Funding for the RFC Editor function is currently provided by the
2313	   Internet Society.