idnits 2.17.1 draft-ietf-atompub-format-09.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 2174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2151. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2158. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2164. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: atom:content MAY have a "src" attribute, whose value MUST be an IRI reference [RFC3987]. If the "src" attribute is present, atom:content MUST be empty. Atom Processors MAY use the IRI to retrieve the content, and MAY NOT process or present remote content in the same manner as local content. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 07, 2005) is 6891 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 '' and '' 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: 8 errors (**), 0 flaws (~~), 4 warnings (==), 12 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: December 9, 2005 June 07, 2005 6 The Atom Syndication Format 7 draft-ietf-atompub-format-09 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 December 9, 2005. 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 . . . . . . . . . . . . . . . . . . . . . . . 30 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 82 8. Security Considerations . . . . . . . . . . . . . . . . . . 34 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . 35 85 9.2 Informative References . . . . . . . . . . . . . . . . . . 36 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 87 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 88 B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 39 89 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 90 Intellectual Property and Copyright Statements . . . . . . . 53 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 108 110 Example Feed 111 112 2003-12-13T18:30:02Z 113 114 John Doe 115 116 urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6 118 119 Atom-Powered Robots Run Amok 120 121 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 122 2003-12-13T18:30:02Z 123 Some text. 124 126 127 A more extensive, single-entry Atom Feed Document: 129 130 131 dive into mark 132 133 A <em>lot</em> of effort 134 went into making this effortless 135 136 2005-04-02T12:29:29Z 137 tag:example.org,2003:3 138 140 Copyright (c) 2003, Mark Pilgrim 141 142 Example Toolkit 143 144 145 Atom draft-07 snapshot 146 148 150 tag:example.org,2003:3.2397 151 2005-04-02T12:29:29Z 152 2003-12-13T08:29:29-04:00 153 154 Mark Pilgrim 155 http://example.org/ 156 f8dy@example.com 157 158 159 Sam Ruby 160 161 162 Joe Gregorio 163 164 166
167

[Update: The Atom draft-07 snapshot is out.]

168
169 170 171 173 1.2 Namespace and Version 175 The XML Namespaces URI [W3C.REC-xml-names-19990114] for the XML data 176 format described in this specification is: 178 http://purl.org/atom/ns#draft-ietf-atompub-format-09 180 [[anchor4: This paragraph to be removed by the RFC Editor. The 181 namespace here is a temporary one and will be changed when the IESG 182 approves this document as a standard. At that time, the namespace 183 will be drawn from W3C URI space. The choice of that namespace will 184 be coordinated between the IETF and W3C through their respective 185 liaisons.]] 187 For convenience, this data format may be referred to as "Atom 1.0". 188 This specification uses "Atom" internally. 190 1.3 Notational Conventions 192 This specification describes conformance in terms of two artifacts; 193 Atom Feed Documents and Atom Entry documents. Additionally, it 194 places some requirements on Atom Processors. 196 This specification uses the namespace prefix "atom:" for the 197 Namespace URI identified in section 1.2. above. Note that the choice 198 of namespace prefix is arbitrary and not semantically significant. 200 Atom is specified using terms from the XML Infoset [W3C.REC-xml- 201 infoset-20040204]. However, this specification uses a shorthand for 202 two common terms; the phrase "Information Item" is omitted when 203 naming Element Information Items and Attribute Information Items. 204 Therefore, when this specification uses the term "element," it is 205 referring to an Element Information Item in Infoset terms. Likewise, 206 when it uses the term "attribute," it is referring to an Attribute 207 Information Item. 209 Some sections of this specification are illustrated with fragments of 210 a non-normative RELAX NG Compact schema [RELAX-NG]. However, the 211 text of this specification provides the definition of conformance. A 212 complete schema appears in Appendix B. 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in BCP 14, [RFC2119], as 217 scoped to those conformance targets. 219 2. Atom Documents 221 This specification describes two kinds of Atom Documents; Atom Feed 222 Documents and Atom Entry Documents. 224 An Atom Feed Document is a representation of an Atom feed, including 225 metadata about the feed, and some or all of the entries associated 226 with it. Its root is the atom:feed element. 228 An Atom Entry Document represents exactly one Atom entry, outside of 229 the context of an Atom feed. Its root is the atom:entry element. 231 namespace atom = 232 "http://purl.org/atom/ns#draft-ietf-atompub-format-09" 233 start = atomFeed | atomEntry 235 Both kinds of Atom documents are specified in terms of the XML 236 Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and 237 identified with the "application/atom+xml" media type. Atom 238 Documents MUST be well-formed XML. This specification does not 239 define a DTD for Atom Documents, and hence does not require them to 240 be valid (in the sense used by XML). 242 Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. 243 IRIs can easily be converted to URIs. Every URI is an IRI, so any 244 URI can be used where an IRI is needed. When comparing IRIs serving 245 as atom:id values, they MUST NOT be converted to URIs. 247 Any element defined by this specification MAY have an xml:base 248 attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an 249 Atom document, it serves the function described in section 5.1.1 of 250 [RFC3986], establishing the base URI (or IRI) for resolving any 251 relative references found within the effective scope of the xml:base 252 attribute. 254 Any element defined by this specification MAY have an xml:lang 255 attribute, whose content indicates the natural language for the 256 element and its descendents. The language context is only 257 significant for elements and attributes declared to be "Language- 258 Sensitive" by this specification. Requirements regarding the content 259 and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml- 260 20040204], Section 2.12. 262 atomCommonAttributes = 263 attribute xml:base { atomUri }?, 264 attribute xml:lang { atomLanguageTag }?, 265 undefinedAttribute* 267 Atom is an extensible format. See Section 6 of this document for a 268 full description of how Atom Documents can be extended. 270 Atom Processors MAY keep state sourced from Atom Feed Documents and 271 combine them with other Atom Feed Documents, in order to facilitate a 272 contiguous view of the contents of a feed. The manner in which Atom 273 Feed Documents are combined in order to reconstruct a feed (e.g., 274 updating entries and metadata, dealing with missing entries) is out 275 of the scope of this specification. 277 3. Common Atom Constructs 279 Many of Atom's elements share a few common structures. This section 280 defines those structures and their requirements for convenient 281 reference by the appropriate element definitions. 283 When an element is identified as being a particular kind of 284 construct, it inherits the corresponding requirements from that 285 construct's definition in this section. 287 3.1 Text Constructs 289 A Text construct contains human-readable text, usually in small 290 quantities. The content of Text constructs is Language-Sensitive. 292 atomPlainTextConstruct = 293 atomCommonAttributes, 294 attribute type { "text" | "html" }?, 295 text 297 atomXHTMLTextConstruct = 298 atomCommonAttributes, 299 attribute type { "xhtml" }, 300 xhtmlDiv 302 atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct 304 3.1.1 The "type" Attribute 306 Text constructs MAY have a "type" attribute. When present, the value 307 MUST be one of "text", "html" or "xhtml". If the "type" attribute is 308 not provided, Atom Processors MUST behave as though it were present 309 with a value of "text". MIME media types [MIMEREG] MUST NOT be used 310 as values for the "type" attribute. 312 3.1.1.1 Text 314 Example atom:title with text content: 316 ... 317 318 Less: < 319 320 ... 322 If the value is "text", the content of the Text construct MUST NOT 323 contain child elements. Such text is intended to be presented to 324 humans in a readable fashion. Thus, Atom Processors MAY collapse 325 white-space (including line-breaks), and display the text using 326 typographic techniques such as justification and proportional fonts. 328 3.1.1.2 HTML 330 Example atom:title with HTML content: 332 ... 333 334 Less: <em> &lt; </em> 335 336 ... 338 If the value of "type" is "html", the content of the Text construct 339 MUST NOT contain child elements, and SHOULD be suitable for handling 340 as HTML [HTML]. Any markup within MUST be escaped; for example, 341 "
" as "<br>". HTML markup within SHOULD be such that it could 342 validly appear directly within an HTML
element, after 343 unescaping. Atom Processors that display such content MAY use that 344 markup to aid in its display. 346 3.1.1.3 XHTML 348 Example atom:title with XHTML content: 350 ... 351 352 <xhtml:div> 353 Less: <xhtml:em> < </xhtml:em> 354 </xhtml:div> 355 356 ... 358 If the value of "type" is "xhtml", the content of the Text construct 359 MUST be a single XHTML div element [XHTML], and SHOULD be suitable 360 for handling as XHTML. The XHTML div element itself MUST NOT be 361 considered part of the content. Atom Processors that display the 362 content MAY use the markup to aid in displaying it. The escaped 363 versions of characters such as "&" and ">" represent those 364 characters, not markup. 366 Examples of valid XHTML content: 368 ... 369 370
371 This is XHTML content. 372
373 374 ... 375 376 377 This is XHTML content. 378 379 380 ... 382 The following example assumes that the XHTML namespace has been bound 383 to the "xh" prefix earlier in the document: 385 ... 386 387 388 This is XHTML content. 389 390 391 ... 393 3.2 Person Constructs 395 A Person construct is an element that describes a person, 396 corporation, or similar entity (hereafter, 'person'). 398 atomPersonConstruct = 399 atomCommonAttributes, 400 (element atom:name { text } 401 & element atom:uri { atomUri }? 402 & element atom:email { atomEmailAddress }? 403 & extensionElement*) 405 This specification assigns no significance to the order of appearance 406 of the child elements in a Person construct. Person constructs allow 407 extension Metadata elements (see Section 6.4). 409 3.2.1 The "atom:name" Element 411 The "atom:name" element's content conveys a human-readable name for 412 the person. The content of atom:name is Language-Sensitive. Person 413 constructs MUST contain exactly one "atom:name" element. 415 3.2.2 The "atom:uri" Element 417 The "atom:uri" element's content conveys an IRI associated with the 418 person. Person constructs MAY contain an atom:uri element, but MUST 419 NOT contain more than one. The content of atom:uri in a Person 420 construct MUST be an IRI reference [RFC3987]. 422 3.2.3 The "atom:email" Element 424 The "atom:email" element's content conveys an e-mail address 425 associated with the person. Person constructs MAY contain an atom: 426 email element, but MUST NOT contain more than one. Its content MUST 427 conform to the "addr-spec" production in [RFC2822]. 429 3.3 Date Constructs 431 A Date construct is an element whose content MUST conform to the 432 "date-time" production in [RFC3339]. In addition, an uppercase "T" 433 character MUST be used to separate date and time, and an uppercase 434 "Z" character MUST be present in the absence of a numeric time zone 435 offset. 437 atomDateConstruct = 438 atomCommonAttributes, 439 xsd:dateTime 441 Such date values happen to be compatible with the following 442 specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and 443 [W3C.REC-xmlschema-2-20041028]. 445 Example Date constructs: 447 2003-12-13T18:30:02Z 448 2003-12-13T18:30:02.25Z 449 2003-12-13T18:30:02+01:00 450 2003-12-13T18:30:02.25+01:00 452 Date values SHOULD be as accurate as possible. For example, it would 453 be generally inappropriate for a publishing system to apply the same 454 timestamp to several entries which were published during the course 455 of a single day. 457 4. Atom Element Definitions 459 4.1 Container Elements 461 4.1.1 The "atom:feed" Element 463 The "atom:feed" element is the document (i.e., top-level) element of 464 an Atom Feed Document, acting as a container for metadata and data 465 associated with the feed. Its element children consist of metadata 466 elements followed by zero or more atom:entry child elements. 468 atomFeed = 469 element atom:feed { 470 atomCommonAttributes, 471 (atomAuthor* 472 & atomCategory* 473 & atomContributor* 474 & atomGenerator? 475 & atomIcon? 476 & atomId 477 & atomLink* 478 & atomLogo? 479 & atomRights? 480 & atomSubtitle? 481 & atomTitle 482 & atomUpdated 483 & extensionElement*), 484 atomEntry* 485 } 487 This specification assigns no significance to the order of atom:entry 488 elements within the feed. 490 The following child elements are defined by this specification (note 491 that the presence of some of these elements is required): 493 o atom:feed elements MUST contain one or more atom:author elements, 494 unless all of the atom:feed element's child atom:entry elements 495 contain at least one atom:author element. 497 o atom:feed elements MAY contain any number of atom:category 498 elements. 500 o atom:feed elements MAY contain any number of atom:contributor 501 elements. 503 o atom:feed elements MUST NOT contain more than one atom:generator 504 element. 506 o atom:feed elements MUST NOT contain more than one atom:icon 507 element. 509 o atom:feed elements MUST NOT contain more than one atom:image 510 element. 512 o atom:feed elements MUST contain exactly one atom:id element. 514 o atom:feed elements SHOULD contain one atom:link element with a rel 515 attribute value of "self". This is the preferred URI for 516 retrieving Atom Feed Documents representing this Atom feed. 518 o atom:feed elements MUST NOT contain more than one atom:link 519 element with a rel attribute value of "alternate" that has the 520 same type attribute value. atom:feed elements MAY contain 521 additional atom:link elements beyond those described above. 523 o atom:feed elements MUST NOT contain more than one atom:rights 524 element. 526 o atom:feed elements MUST NOT contain more than one atom:subtitle 527 element. 529 o atom:feed elements MUST contain exactly one atom:title element. 531 o atom:feed elements MUST contain exactly one atom:updated element. 533 If multiple atom:entry elements with the same atom:id value appear in 534 an Atom Feed Document, they represent the same entry. Their atom: 535 updated timestamps SHOULD be different. If an Atom Feed Document 536 contains multiple entries with the same atom:id, Atom Processors MAY 537 choose to display all of them or some subset of them. One typical 538 behavior would be to display only the entry with the latest atom: 539 updated timestamp. 541 4.1.1.1 Providing Textual Content 543 Experience teaches that feeds which contain textual content are in 544 general more useful than those which do not. Some applications (one 545 example is full-text indexers) require a minimum amount of text or 546 (X)HTML to function reliably and predictably. Feed producers should 547 be aware of these issues. It is advisable that each atom:entry 548 element contain a non-empty atom:title element, a non-empty atom: 549 content element when that element is present, and a non-empty atom: 550 summary element when the entry contains no atom:content element. 551 However, the absence of atom:summary is not an error and Atom 552 Processors MUST NOT fail to function correctly as a consequence of 553 such an absence. 555 4.1.2 The "atom:entry" Element 557 The "atom:entry" element represents an individual entry, acting as a 558 container for metadata and data associated with the entry. This 559 element can appear as a child of the atom:feed element, or it can 560 appear as the document (i.e., top-level) element of a standalone Atom 561 Entry Document. 563 atomEntry = 564 element atom:entry { 565 atomCommonAttributes, 566 (atomAuthor* 567 & atomCategory* 568 & atomContent? 569 & atomContributor* 570 & atomId 571 & atomLink* 572 & atomPublished? 573 & atomRights? 574 & atomSource? 575 & atomSummary? 576 & atomTitle 577 & atomUpdated 578 & extensionElement*) 579 } 581 This specification assigns no significance to the order of appearance 582 of the child elements of atom:entry. 584 The following child elements are defined by this specification (note 585 that it requires the presence of some of these elements): 587 o atom:entry elements MUST contain one or more atom:author elements, 588 unless the atom:entry contains an atom:source element which 589 contains an atom:author element, or, in an Atom Feed Document, the 590 atom:feed element contains an atom:author element itself. 592 o atom:entry elements MAY contain any number of atom:category 593 elements. 595 o atom:entry elements MUST NOT contain more than one atom:content 596 element. 598 o atom:entry elements MAY contain any number of atom:contributor 599 elements. 601 o atom:entry elements MUST contain exactly one atom:id element. 603 o atom:entry elements that contain no child atom:content element 604 MUST contain at least one atom:link element with a rel attribute 605 value of "alternate". 607 o atom:entry elements MUST NOT contain more than one atom:link 608 element with a rel attribute value of "alternate" that has the 609 same combination of type and hreflang attribute values. 611 o atom:entry elements MAY contain additional atom:link elements 612 beyond those described above. 614 o atom:entry elements MUST NOT contain more than one atom:published 615 element. 617 o atom:entry elements MUST NOT contain more than one atom:rights 618 element. 620 o atom:entry elements MUST NOT contain more than one atom:source 621 element. 623 o atom:entry elements MUST contain an atom:summary element in either 624 of the following cases: 626 * the atom:entry contains an atom:content that has a "src" 627 attribute (and is thus empty). 629 * the atom:entry contains content that is encoded in Base64; i.e. 630 the "type" attribute of atom:content is a MIME media type 631 [MIMEREG], but is not an XML media type [RFC3023], does not 632 begin with "text/", and does not end with "/xml" or "+xml". 634 o atom:entry elements MUST NOT contain more than one atom:summary 635 element. 637 o atom:entry elements MUST have exactly one "atom:title" element. 639 o atom:entry elements MUST contain exactly one atom:updated element. 641 4.1.3 The "atom:content" Element 643 The "atom:content" element either contains or links to the content of 644 the entry. The content of atom:content is Language-Sensitive. 646 atomInlineTextContent = 647 element atom:content { 648 atomCommonAttributes, 649 attribute type { "text" | "html" }?, 650 (text)* 651 } 653 atomInlineXHTMLContent = 654 element atom:content { 655 atomCommonAttributes, 656 attribute type { "xhtml" }, 657 xhtmlDiv 658 } 660 atomInlineOtherContent = 661 element atom:content { 662 atomCommonAttributes, 663 attribute type { atomMediaType }?, 664 (text|anyElement)* 665 } 667 atomOutOfLineContent = 668 element atom:content { 669 atomCommonAttributes, 670 attribute type { atomMediaType }?, 671 attribute src { atomUri }, 672 empty 673 } 675 atomContent = atomInlineTextContent 676 | atomInlineXHTMLContent 677 | atomInlineOtherContent 678 | atomOutOfLineContent 680 4.1.3.1 The "type" attribute 682 On the atom:content element, the value of the "type" attribute MAY be 683 one of "text", "html", or "xhtml". Failing that, it MUST be a MIME 684 media type, but MUST NOT be a composite type (see Section 4.2.6 of 685 [MIMEREG]). If the type attribute is not provided, Atom Processors 686 MUST behave as though it were present with a value of "text". 688 4.1.3.2 The "src" attribute 690 atom:content MAY have a "src" attribute, whose value MUST be an IRI 691 reference [RFC3987]. If the "src" attribute is present, atom:content 692 MUST be empty. Atom Processors MAY use the IRI to retrieve the 693 content, and MAY NOT process or present remote content in the same 694 manner as local content. 696 If the "src" attribute is present, the "type" attribute SHOULD be 697 provided and MUST be a MIME media type [MIMEREG], rather than "text", 698 "html", or "xhtml". The value is advisory; that is to say, upon 699 dereferencing the IRI to retrieve the content, if the server 700 providing that content also provides a media type, the server- 701 provided media type is authoritative. 703 4.1.3.3 Processing Model 705 Atom Documents MUST conform to the following rules. Atom Processors 706 MUST interpret atom:content according to the first applicable rule. 708 1. If the value of "type" is "text", the content of atom:content 709 MUST NOT contain child elements. Such text is intended to be 710 presented to humans in a readable fashion. Thus, Atom Processors 711 MAY collapse white-space (including line-breaks), and display the 712 text using typographic techniques such as justification and 713 proportional fonts. 715 2. If the value of "type" is "html", the content of atom:content 716 MUST NOT contain child elements, and SHOULD be suitable for 717 handling as HTML [HTML]. The HTML markup MUST be escaped; for 718 example, "
" as "<br>". The HTML markup SHOULD be such 719 that it could validly appear directly within an HTML
720 element. Atom Processors that display the content MAY use the 721 markup to aid in displaying it. 723 3. If the value of "type" is "xhtml", the content of atom:content 724 MUST be a single XHTML div element [XHTML], and SHOULD be 725 suitable for handling as XHTML. The XHTML div element itself 726 MUST NOT be considered part of the content. Atom Processors that 727 display the content MAY use the markup to aid in displaying it. 728 The escaped versions of characters such as "&" and ">" represent 729 those characters, not markup. 731 4. If the value of "type" is an XML media type [RFC3023], or ends 732 with "+xml" or "/xml" (case-insensitive), the content of 733 atom:content MAY include child elements, and SHOULD be suitable 734 for handling as the indicated media type. If the "src" attribute 735 is not provided, this would normally mean that the "atom:content" 736 element would contain a single child element which would serve as 737 the root element of the XML document of the indicated type. 739 5. If the value of "type" begins with "text/" (case-insensitive), 740 the content of atom:content MUST NOT contain child elements. 742 6. For all other values of "type", the content of atom:content MUST 743 be a valid Base64 encoding, as described in [RFC3548], section 3. 744 When decoded, it SHOULD be suitable for handling as the indicated 745 media type. In this case, the characters in the Base64 encoding 746 MAY be preceded and followed in the atom:content element by 747 white-space, and lines are separated by a single newline (U+000A) 748 character. 750 4.1.3.4 Examples 752 XHTML inline: 754 ... 755 756
757 This is XHTML content. 758
759 760 ... 761 762 763 This is XHTML content. 764 765 766 ... 768 The following example assumes that the XHTML namespace has been bound 769 to the "xh" prefix earlier in the document: 771 ... 772 773 774 This is XHTML content. 775 776 777 ... 779 4.2 Metadata Elements 781 4.2.1 The "atom:author" Element 783 The "atom:author" element is a Person construct that indicates the 784 author of the entry or feed. 786 atomAuthor = element atom:author { atomPersonConstruct } 788 If an atom:entry element does not contain atom:author elements, then 789 the atom:author elements of the contained atom:source element are 790 considered to apply. In an Atom Feed Document, the atom:author 791 elements of the containing atom:feed element are considered to apply 792 to the entry if there are no atom:author elements in the locations 793 described above. 795 4.2.2 The "atom:category" Element 797 The "atom:category" element conveys information about a category 798 associated with an entry or feed. This specification assigns no 799 meaning to the content (if any) of this element. 801 atomCategory = 802 element atom:category { 803 atomCommonAttributes, 804 attribute term { text }, 805 attribute scheme { atomUri }?, 806 attribute label { text }?, 807 undefinedContent 808 } 810 4.2.2.1 The "term" Attribute 812 The "term" attribute is a string that identifies the category to 813 which the entry or feed belongs. Category elements MUST have a 814 "term" attribute. 816 4.2.2.2 The "scheme" Attribute 818 The "scheme" attribute is an IRI that identifies a categorization 819 scheme. Category elements MAY have a "scheme" attribute. 821 4.2.2.3 The "label" attribute 823 The "label" attribute provides a human-readable label for display in 824 end-user applications. The content of the "label" attribute is 825 Language-Sensitive. Category elements MAY have a "label" attribute. 827 4.2.3 The "atom:contributor" Element 829 The "atom:contributor" element is a Person construct that indicates a 830 person or other entity who contributed to the entry or feed. 832 atomContributor = element atom:contributor { atomPersonConstruct } 834 4.2.4 The "atom:generator" Element 836 The "atom:generator" element's content identifies the agent used to 837 generate a feed, for debugging and other purposes. 839 atomGenerator = element atom:generator { 840 atomCommonAttributes, 841 attribute uri { atomUri }?, 842 attribute version { text }?, 843 text 844 } 846 The content of this element, when present, MUST be a string that is a 847 human-readable name for the generating agent. 849 The atom:generator element MAY have a "uri" attribute whose value 850 MUST be an IRI reference [RFC3987]. When dereferenced, that IRI 851 SHOULD produce a representation that is relevant to that agent. 853 The atom:generator element MAY have a "version" attribute that 854 indicates the version of the generating agent. 856 4.2.5 The "atom:icon" Element 858 The "atom:icon" element's content is an IRI reference [RFC3987] which 859 identifies an image which provides iconic visual identification for a 860 feed. 862 atomIcon = element atom:icon { 863 atomCommonAttributes, 864 (atomUri) 865 } 867 The image SHOULD have an aspect ratio of one (horizontal) to one 868 (vertical), and SHOULD be suitable for presentation at a small size. 870 4.2.6 The "atom:id" Element 872 The "atom:id" element conveys a permanent, universally unique 873 identifier for an entry or feed. 875 atomId = element atom:id { 876 atomCommonAttributes, 877 (atomUri) 878 } 880 Its content MUST be an IRI, as defined by [RFC3987]. Note that the 881 definition of "IRI" excludes relative references. Though the IRI 882 might use a dereferencable scheme, Atom Processors MUST NOT assume it 883 can be dereferenced. 885 When an Atom document is relocated, migrated, syndicated, 886 republished, exported or imported, the content of its atom:id element 887 MUST NOT change. Put another way, an atom:id element pertains to all 888 instantiations of a particular Atom entry or feed; revisions retain 889 the same content in their atom:id elements. It is suggested that the 890 atom:id element be stored along with the associated resource. 892 The content of an atom:id element MUST be created in a way that 893 assures uniqueness. 895 Because of the risk of confusion between IRIs that would be 896 equivalent if dereferenced, the following normalization strategy 897 SHOULD be applied when generating atom:id elements: 899 o Provide the scheme in lowercase characters. 901 o Provide the host, if any, in lowercase characters. 903 o Only perform percent-encoding where it is essential. 905 o Use uppercase A-through-F characters when percent-encoding. 907 o Prevent dot-segments appearing in paths. 909 o For schemes that define a default authority, use an empty 910 authority if the default is desired. 912 o For schemes that define an empty path to be equivalent to a path 913 of "/", use "/". 915 o For schemes that define a port, use an empty port if the default 916 is desired. 918 o Preserve empty fragment identifiers and queries. 920 o Ensure that all components of the IRI are appropriately character- 921 normalized, e.g. by using NFC or NFKC. 923 4.2.6.1 Comparing atom:id 925 Instances of atom:id elements can be compared to determine whether an 926 entry or feed is the same as one seen before. Processors MUST 927 compare atom:id elements on a character-by-character basis (in a 928 case-sensitive fashion). Comparison operations MUST be based solely 929 on the IRI character strings, and MUST NOT rely on dereferencing the 930 IRIs. 932 As a result, two IRIs that resolve to the same resource but are not 933 character-for-character identical will be considered different for 934 the purposes of identifier comparison. 936 For example, these are four distinct identifiers, despite the fact 937 that they differ only in case: 939 http://www.example.org/thing 941 http://www.example.org/Thing 943 http://www.EXAMPLE.org/thing 945 HTTP://www.example.org/thing 947 Likewise, these are three distinct identifiers, because IRI 948 %-escaping is significant for the purposes of comparison: 950 http://www.example.com/~bob 952 http://www.example.com/%7ebob 954 http://www.example.com/%7Ebob 956 4.2.7 The "atom:link" Element 958 The "atom:link" element defines a reference from an entry or feed to 959 a Web resource. This specification assigns no meaning to the content 960 (if any) of this element. 962 atomLink = 963 element atom:link { 964 atomCommonAttributes, 965 attribute href { atomUri }, 966 attribute rel { atomNCName | atomUri }?, 967 attribute type { atomMediaType }?, 968 attribute hreflang { atomLanguageTag }?, 969 attribute title { text }?, 970 attribute length { text }?, 971 undefinedContent 972 } 974 4.2.7.1 The "href" Attribute 976 The "href" attribute contains the link's IRI. atom:link elements MUST 977 have a href attribute, whose value MUST be a IRI reference [RFC3987]. 979 4.2.7.2 The "rel" Attribute 981 atom:link elements MAY have a "rel" attribute that indicates the link 982 relation type. If the "rel" attribute is not present, the link 983 element MUST be interpreted as if the link relation type is 984 "alternate". 986 The value of "rel" MUST be a string that is non-empty, and matches 987 the "isegment-nz-nc" or "IRI" production in [RFC3987]. Note that use 988 of a relative reference is not allowed. If a name is given, 989 implementations MUST consider the link relation type to be equivalent 990 to the same name registered within the IANA Registry of Link 991 Relations Section 7, and thus the IRI that would be obtained by 992 appending the value of the rel attribute to the string 993 "http://www.iana.org/assignments/relation/". The value of "rel" 994 describes the meaning of the link, but does not impose any behavioral 995 requirements on Atom Processors. 997 This document defines five initial values for the Registry of Link 998 Relations: 1000 1. The value "alternate" signifies that the IRI in the value of the 1001 href attribute identifies an alternate version of the resource 1002 described by the containing element. 1004 2. The value "related" signifies that the IRI in the value of the 1005 href attribute identifies a resource related to the resource 1006 described by the containing element. For example, the feed for a 1007 site that discusses the performance of the search engine at 1008 "http://search.example.com" might contain, as a child of 1009 atom:feed: 1011 1013 An identical link might appear as a child of any atom:entry whose 1014 content contains a discussion of that same search engine. 1016 3. The value "self" signifies that the IRI in the value of the href 1017 attribute identifies a resource equivalent to the containing 1018 element. 1020 4. The value "enclosure" signifies that the IRI in the value of the 1021 href attribute identifies a related resource which is potentially 1022 large in size and might require special handling. For atom:link 1023 elements with rel="enclosure", the length attribute SHOULD be 1024 provided. 1026 5. The value "via" signifies that the IRI in the value of the href 1027 attribute identifies a resource that is the source of the 1028 information provided in the containing element. 1030 4.2.7.3 The "type" Attribute 1032 On the link element, the "type" attribute's value is an advisory 1033 media type; it is a hint about the type of the representation that is 1034 expected to be returned when the value of the href attribute is 1035 dereferenced. Note that the type attribute does not override the 1036 actual media type returned with the representation. Link elements 1037 MAY have a type attribute, whose value MUST conform to the syntax of 1038 a MIME media type [MIMEREG]. 1040 4.2.7.4 The "hreflang" Attribute 1042 The "hreflang" attribute's content describes the language of the 1043 resource pointed to by the href attribute. When used together with 1044 the rel="alternate", it implies a translated version of the entry. 1045 Link elements MAY have an hreflang attribute, whose value MUST be a 1046 language tag [RFC3066]. 1048 4.2.7.5 The "title" Attribute 1050 The "title" attribute conveys human-readable information about the 1051 link. The content of the "title" attribute is Language-Sensitive. 1052 Link elements MAY have a title attribute. 1054 4.2.7.6 The "length" Attribute 1056 The "length" attribute indicates an advisory length of the linked 1057 content in octets; it is a hint about the content length of the 1058 representation returned when the IRI in the href attribute is 1059 dereferenced. Note that the length attribute does not override the 1060 actual content length of the representation as reported by the 1061 underlying protocol. Link elements MAY have a length attribute. 1063 4.2.8 The "atom:logo" Element 1065 The "atom:logo" element's content is an IRI reference [RFC3987] which 1066 identifies an image which provides visual identification for a feed. 1068 atomLogo = element atom:logo { 1069 atomCommonAttributes, 1070 (atomUri) 1071 } 1073 The image SHOULD have an aspect ratio of 2 (horizontal) to 1 1074 (vertical). 1076 4.2.9 The "atom:published" Element 1078 The "atom:published" element is a Date construct indicating an 1079 instant in time associated with an event early in the life cycle of 1080 the entry. 1082 atomPublished = element atom:published { atomDateConstruct } 1084 Typically, atom:published will be associated with the initial 1085 creation or first availability of the resource. 1087 4.2.10 The "atom:rights" Element 1089 The "atom:rights" element is a Text construct that conveys 1090 information about rights held in and over an entry or feed. 1092 atomRights = element atom:rights { atomTextConstruct } 1094 The atom:rights element SHOULD NOT be used to convey machine-readable 1095 licensing information. 1097 If an atom:entry element does not contain an atom:rights element, 1098 then the atom:rights element of the containing atom:feed element, if 1099 present, is considered to apply to the entry. 1101 4.2.11 The "atom:source" Element 1103 If an atom:entry is copied from one feed into another feed, then the 1104 source atom:feed's metadata (all child elements of atom:feed other 1105 than the atom:entry elements) MAY be preserved within the copied 1106 entry by adding an atom:source child element, if it is not already 1107 present in the entry, and including some or all of the source feed's 1108 Metadata elements as the atom:source element's children. Such 1109 metadata SHOULD be preserved if the source atom:feed contains any of 1110 the child elements atom:author, atom:contributor, atom:rights, or 1111 atom:category and those child elements are not present in the source 1112 atom:entry. 1114 atomSource = 1115 element atom:source { 1116 atomCommonAttributes, 1117 (atomAuthor? 1118 & atomCategory* 1119 & atomContributor* 1120 & atomGenerator? 1121 & atomIcon? 1122 & atomId? 1123 & atomLink* 1124 & atomLogo? 1125 & atomRights? 1126 & atomSubtitle? 1127 & atomTitle? 1128 & atomUpdated? 1129 & extensionElement*) 1130 } 1132 The atom:source element is designed to allow the aggregation of 1133 entries from different feeds while retaining information about an 1134 entry's source feed. For this reason, Atom Processors which are 1135 performing such aggregation SHOULD include at least the required 1136 feed-level Metadata elements (atom:id, atom:title, and atom:updated) 1137 in the atom:source element. 1139 4.2.12 The "atom:subtitle" Element 1141 The "atom:subtitle" element is a Text construct that conveys a human- 1142 readable description or subtitle for a feed. 1144 atomSubtitle = element atom:subtitle { atomTextConstruct } 1146 4.2.13 The "atom:summary" Element 1148 The "atom:summary" element is a Text construct that conveys a short 1149 summary, abstract, or excerpt of an entry. 1151 atomSummary = element atom:summary { atomTextConstruct } 1153 It is not advisable for the atom:summary element to duplicate atom: 1154 title or atom:content, because Atom Processors might assume there is 1155 a useful summary when there is none. 1157 4.2.14 The "atom:title" Element 1159 The "atom:title" element is a Text construct that conveys a human- 1160 readable title for an entry or feed. 1162 atomTitle = element atom:title { atomTextConstruct } 1164 4.2.15 The "atom:updated" Element 1166 The "atom:updated" element is a Date construct indicating the most 1167 recent instant in time when an entry or feed was modified in a way 1168 the publisher considers significant. Therefore, not all 1169 modifications necessarily result in a changed atom:updated value. 1171 atomUpdated = element atom:updated { atomDateConstruct } 1173 Publishers MAY change the value of this element over time. 1175 5. Securing Atom Documents 1177 Because Atom is an XML-based format, existing XML security mechanisms 1178 can be used to secure its content. 1180 5.1 Digital Signatures 1182 The root of an Atom document (i.e., atom:feed in an Atom Feed 1183 Document, atom:entry in an Atom Entry Document) MAY have an Enveloped 1184 Signature, as described by XML-Signature and Syntax Processing 1185 [W3C.REC-xmldsig-core-20020212]. 1187 Atom Processors MUST NOT reject an Atom Document containing such a 1188 signature because they are not capable of verifying it; they MUST 1189 continue processing and MAY inform the user of their failure to 1190 validate the signature. 1192 In other words, the presence of an element with the namespace URI 1193 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 1194 as a child of the document element MUST NOT cause an Atom Processor 1195 to fail merely because of its presence. 1197 Other elements in an Atom Document MUST NOT be signed unless their 1198 definitions explicitly specify such a capability. 1200 5.2 Encryption 1202 The root of an Atom Document (i.e., atom:feed in an Atom Feed 1203 Document, atom:entry in an Atom Entry Document) MAY be encrypted, 1204 using the mechanisms described by XML Encryption Syntax and 1205 Processing [W3C.REC-xmlenc-core-20021210]. 1207 6. Extending Atom 1209 6.1 Extensions From Non-Atom Vocabularies 1211 This specification describes Atom's XML markup vocabulary. Markup 1212 from other vocabularies ("foreign markup") can be used in an Atom 1213 document. Note that the atom:content element is designed to support 1214 the inclusion of arbitrary foreign markup. 1216 6.2 Extensions To the Atom Vocabulary 1218 Future versions of this specification could add new elements and 1219 attributes to the Atom markup vocabulary. Software written to 1220 conform to this version of the specification will not be able to 1221 process such markup correctly and, in fact, will not be able to 1222 distinguish it from markup error. For the purposes of this 1223 discussion, unrecognized markup from the Atom vocabulary will be 1224 considered "foreign markup". 1226 6.3 Processing Foreign Markup 1228 Atom Processors which encounter foreign markup in a location that is 1229 legal according to this specification MUST NOT stop processing or 1230 signal an error. It might be the case that the Atom Processor is 1231 able to process the foreign markup correctly and does so. Otherwise, 1232 such markup is termed "unknown foreign markup". 1234 When unknown foreign markup is encountered as a child of atom:entry, 1235 atom:feed, or a Person construct, Atom Processors MAY bypass the 1236 markup and any textual content and MUST NOT change their behavior as 1237 a result of the markup's presence. 1239 When unknown foreign markup is encountered in a Text Contruct or 1240 atom:content element, software SHOULD ignore the markup and process 1241 any text content of foreign elements as though the surrounding markup 1242 were not present. 1244 6.4 Extension Elements 1246 Atom allows foreign markup anywhere in an Atom document, except where 1247 it is explicitly forbidden. Child elements of atom:entry, atom:feed, 1248 and Person constructs are considered Metadata elements, and are 1249 described below. Child elements of Person constructs are considered 1250 to apply to the construct. The role of other foreign markup is 1251 undefined by this specification. 1253 6.4.1 Simple Extension Elements 1255 A Simple Extension element MUST NOT have any attributes or child 1256 elements. The element MAY contain character data, or be empty. 1257 Simple Extension elements are not Language-Sensitive. 1259 simpleExtensionElement = 1260 element * - atom:* { 1261 text 1262 } 1264 The element can be interpreted as a simple property (or name/value 1265 pair) of the parent element that encloses it. The pair consisting of 1266 the namespace-URI of the element and the local name of the element 1267 can be interpreted as the name of the property. The character data 1268 content of the element can be interpreted as the value of the 1269 property. If the element is empty, then the property value can be 1270 interpreted as an empty string. 1272 6.4.2 Structured Extension Elements 1274 The root element of a Structured Extension element MUST have at least 1275 one attribute or child element. It MAY have attributes, it MAY 1276 contain well-formed XML content (including character data), or it MAY 1277 be empty. Structured Extension elements are Language-Sensitive. 1279 structuredExtensionElement = 1280 element * - atom:* { 1281 (attribute * { text }+, 1282 (text|anyElement)*) 1283 | (attribute * { text }*, 1284 (text?, anyElement+, (text|anyElement)*)) 1285 } 1287 The structure of a Structured Extension element, including the order 1288 of its child elements, could be significant. 1290 This specification does not provide an interpretation of a Structured 1291 Extension element. The syntax of the XML contained in the element, 1292 and an interpretation of how the element relates to its containing 1293 element is defined by the specification of the Atom extension. 1295 7. IANA Considerations 1297 An Atom Document, when serialized as XML 1.0, can be identified with 1298 the following media type: 1300 MIME media type name: application 1302 MIME subtype name: atom+xml 1304 Mandatory parameters: None. 1306 Optional parameters: 1308 "charset": This parameter has identical semantics to the charset 1309 parameter of the "application/xml" media type as specified in 1310 [RFC3023]. 1312 Encoding considerations: Identical to those of "application/xml" as 1313 described in [RFC3023], section 3.2. 1315 Security considerations: As defined in this specification. 1317 In addition, as this media type uses the "+xml" convention, it 1318 shares the same security considerations as described in [RFC3023], 1319 section 10. 1321 Interoperability considerations: There are no known interoperability 1322 issues. 1324 Published specification: This specification. 1326 Applications that use this media type: No known applications 1327 currently use this media type. 1329 Additional information: 1331 Magic number(s): As specified for "application/xml" in [RFC3023], 1332 section 3.2. 1334 File extension: .atom 1336 Fragment identifiers: As specified for "application/xml" in 1337 [RFC3023], section 5. 1339 Base URI: As specified in [RFC3023], section 6. 1341 Macintosh File Type code: TEXT 1343 Person and email address to contact for further information: Mark 1344 Nottingham 1346 Intended usage: COMMON 1348 Author/Change controller: IESG 1350 7.1 Registry of Link Relations 1352 This registry is maintained by IANA and initially contains five 1353 values: "alternate", "related", "self", "enclosure", and "via". New 1354 assignments are subject to IESG Approval, as outlined in [RFC2434]. 1355 Requests should be made by email to IANA, which will then forward the 1356 request to the IESG requesting approval. The request should use the 1357 following template: 1359 o Attribute Value: ( A value for the "rel" attribute that conforms 1360 to the syntax rule given in Section 4.2.7.2 ) 1362 o Description: 1364 o Expected display characteristics: 1366 o Security considerations: 1368 8. Security Considerations 1370 8.1 HTML and XHTML Content 1372 Text constructs and atom:content allow the delivery of HTML and 1373 XHTML. Many elements in these languages are considered 'unsafe' in 1374 that they open clients to one or more types of attack. Implementers 1375 of software which processes Atom should carefully consider their 1376 handling of every type of element when processing incoming (X)HTML in 1377 Atom documents. See the security sections of [RFC2854] and [HTML] 1378 for guidance. 1380 Atom Processors should pay particular attention to the security of 1381 the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and 1382 LINK elements, but other elements might also have negative security 1383 properties. 1385 (X)HTML can either directly contain or indirectly reference 1386 executable content. 1388 8.2 URIs 1390 Atom Processors handle URIs. See Section 7 of [RFC3986]. 1392 8.3 IRIs 1394 Atom Processors handle IRIs. See Section 8 of [RFC3987]. 1396 8.4 Spoofing 1398 Atom Processors should be aware of the potential for spoofing attacks 1399 where the attacker publishes an atom:entry with the atom:id value of 1400 an entry from another feed, perhaps with a falsified atom:source 1401 element duplicating the atom:id of the other feed. For example, an 1402 Atom Processor could suppress display of duplicate entries by 1403 displaying only one entry from a set of entries with identical 1404 atom:id values. In that situation, the Atom Processor might also 1405 take steps to determine whether the entries originated from the same 1406 publisher before considering them to be duplicates. 1408 8.5 Encryption and Signing 1410 Atom documents can be encrypted and signed using [W3C.REC-xmlenc- 1411 core-20021210] and [W3C.REC-xmldsig-core-20020212], respectively, and 1412 are subject to the security considerations implied by their use. 1414 9. References 1416 9.1 Normative References 1418 [HTML] Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 1419 Specification", W3C REC REC-html401-19991224, 1420 December 1999, 1421 . 1423 [MIMEREG] Freed, N. and J. Klensin, "Media Type Specifications and 1424 Registration Procedures", work-in-progress 1425 (draft-freed-media-type-reg-04), April 2005. 1427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1428 Requirement Levels", BCP 14, RFC 2119, March 1997. 1430 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1431 April 2001. 1433 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 1434 Type", RFC 2854, June 2000. 1436 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 1437 Types", RFC 3023, January 2001. 1439 [RFC3066] Alvestrand, H., "Tags for the Identification of 1440 Languages", BCP 47, RFC 3066, January 2001. 1442 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1443 Timestamps", RFC 3339, July 2002. 1445 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1446 Encodings", RFC 3548, July 2003. 1448 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1449 Resource Identifier (URI): Generic Syntax", STD 66, 1450 RFC 3986, January 2005. 1452 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1453 Identifiers (IRIs)", RFC 3987, January 2005. 1455 [W3C.REC-xml-20040204] 1456 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., 1457 and E. Maler, "Extensible Markup Language (XML) 1.0 (Third 1458 Edition)", W3C REC REC-xml-20040204, February 2004, 1459 . 1461 [W3C.REC-xml-infoset-20040204] 1462 Cowan, J. and R. Tobin, "XML Information Set (Second 1463 Edition)", W3C REC REC-xml-infoset-20040204, 1464 February 2004, 1465 . 1467 [W3C.REC-xml-names-19990114] 1468 Hollander, D., Bray, T., and A. Layman, "Namespaces in 1469 XML", W3C REC REC-xml-names-19990114, January 1999, 1470 . 1472 [W3C.REC-xmlbase-20010627] 1473 Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627, 1474 June 2001, 1475 . 1477 [W3C.REC-xmldsig-core-20020212] 1478 Solo, D., Reagle, J., and D. Eastlake, "XML-Signature 1479 Syntax and Processing", W3C REC REC-xmldsig-core-20020212, 1480 February 2002, 1481 . 1483 [W3C.REC-xmlenc-core-20021210] 1484 Reagle, J. and D. Eastlake, "XML Encryption Syntax and 1485 Processing", W3C REC REC-xmlenc-core-20021210, 1486 December 2002, 1487 . 1489 [XHTML] Altheim, M., Boumphrey, F., McCarron, S., Dooley, S., 1490 Schnitzenbaumer, S., and T. Wugofski, "Modularization of 1491 XHTML[TM]", W3C REC REC-xhtml-modularization-20010410, 1492 April 2001, . 1495 9.2 Informative References 1497 [ISO.8601.1988] 1498 International Organization for Standardization, "Data 1499 elements and interchange formats - Information interchange 1500 - Representation of dates and times", ISO Standard 8601, 1501 June 1988. 1503 [RELAX-NG] 1504 Clark, J., "RELAX NG Compact Syntax", December 2001, . 1508 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1509 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1510 October 1998. 1512 [W3C.NOTE-datetime-19980827] 1513 Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C 1514 NOTE NOTE-datetime-19980827, August 1998, 1515 . 1517 [W3C.REC-xmlschema-2-20041028] 1518 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1519 Second Edition", W3C REC REC-xmlschema-2-20041028, 1520 October 2004, 1521 . 1523 Authors' Addresses 1525 Mark Nottingham (editor) 1527 Email: mnot@pobox.com 1528 URI: http://www.mnot.net/ 1530 Robert Sayre (editor) 1532 Email: rfsayre@boswijck.com 1533 URI: http://boswijck.com 1535 Appendix A. Contributors 1537 The following people contributed to preliminary drafts of this 1538 document: Tim Bray, Mark Pilgrim, and Sam Ruby. Norman Walsh 1539 provided the Relax NG schema. The content and concepts within are a 1540 product of the Atom community and the Atom Publishing Format and 1541 Protocol Working Group. 1543 Appendix B. RELAX NG Compact Schema 1545 This appendix is informative. 1547 # -*- rnc -*- 1548 # RELAX NG Compact Syntax Grammar for the 1549 # Atom Format Specification Version 09 1551 namespace atom = 1552 "http://purl.org/atom/ns#draft-ietf-atompub-format-09" 1553 namespace xhtml = "http://www.w3.org/1999/xhtml" 1554 namespace s = "http://www.ascc.net/xml/schematron" 1555 namespace local = "" 1557 start = atomFeed | atomEntry 1559 # Common attributes 1561 atomCommonAttributes = 1562 attribute xml:base { atomUri }?, 1563 attribute xml:lang { atomLanguageTag }?, 1564 undefinedAttribute* 1566 # Text Constructs 1568 atomPlainTextConstruct = 1569 atomCommonAttributes, 1570 attribute type { "text" | "html" }?, 1571 text 1573 atomXHTMLTextConstruct = 1574 atomCommonAttributes, 1575 attribute type { "xhtml" }, 1576 xhtmlDiv 1578 atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct 1580 # Person Construct 1582 atomPersonConstruct = 1583 atomCommonAttributes, 1584 (element atom:name { text } 1585 & element atom:uri { atomUri }? 1586 & element atom:email { atomEmailAddress }? 1587 & extensionElement*) 1589 # Date Construct 1590 atomDateConstruct = 1591 atomCommonAttributes, 1592 xsd:dateTime 1594 # atom:feed 1596 atomFeed = 1597 [ 1598 s:rule [ 1599 context = "atom:feed" 1600 s:assert [ 1601 test = "atom:author or not(atom:entry[not(atom:author)])" 1602 "An atom:feed must have an atom:author unless all " 1603 ~ "of its atom:entry children have an atom:author." 1604 ] 1605 ] 1606 ] 1607 element atom:feed { 1608 atomCommonAttributes, 1609 (atomAuthor* 1610 & atomCategory* 1611 & atomContributor* 1612 & atomGenerator? 1613 & atomIcon? 1614 & atomId 1615 & atomLink* 1616 & atomLogo? 1617 & atomRights? 1618 & atomSubtitle? 1619 & atomTitle 1620 & atomUpdated 1621 & extensionElement*), 1622 atomEntry* 1623 } 1625 # atom:entry 1627 atomEntry = 1628 [ 1629 s:rule [ 1630 context = "atom:entry" 1631 s:assert [ 1632 test = "atom:link[@rel='alternate'] " 1633 ~ "or atom:link[not(@rel)] " 1634 ~ "or atom:content" 1635 "An atom:entry must have at least one atom:link element " 1636 ~ "with a rel attribute of 'alternate' " 1637 ~ "or an atom:content." 1639 ] 1640 ] 1641 s:rule [ 1642 context = "atom:entry" 1643 s:assert [ 1644 test = "atom:author or " 1645 ~ "../atom:author or atom:source/atom:author" 1646 "An atom:entry must have an atom:author " 1647 ~ "if its feed does not." 1648 ] 1649 ] 1650 ] 1651 element atom:entry { 1652 atomCommonAttributes, 1653 (atomAuthor* 1654 & atomCategory* 1655 & atomContent? 1656 & atomContributor* 1657 & atomId 1658 & atomLink* 1659 & atomPublished? 1660 & atomRights? 1661 & atomSource? 1662 & atomSummary? 1663 & atomTitle 1664 & atomUpdated 1665 & extensionElement*) 1666 } 1668 # atom:content 1670 atomInlineTextContent = 1671 element atom:content { 1672 atomCommonAttributes, 1673 attribute type { "text" | "html" }?, 1674 (text)* 1675 } 1677 atomInlineXHTMLContent = 1678 element atom:content { 1679 atomCommonAttributes, 1680 attribute type { "xhtml" }, 1681 xhtmlDiv 1682 } 1684 atomInlineOtherContent = 1685 element atom:content { 1686 atomCommonAttributes, 1687 attribute type { atomMediaType }?, 1688 (text|anyElement)* 1689 } 1691 atomOutOfLineContent = 1692 element atom:content { 1693 atomCommonAttributes, 1694 attribute type { atomMediaType }?, 1695 attribute src { atomUri }, 1696 empty 1697 } 1699 atomContent = atomInlineTextContent 1700 | atomInlineXHTMLContent 1701 | atomInlineOtherContent 1702 | atomOutOfLineContent 1704 # atom:author 1706 atomAuthor = element atom:author { atomPersonConstruct } 1708 # atom:category 1710 atomCategory = 1711 element atom:category { 1712 atomCommonAttributes, 1713 attribute term { text }, 1714 attribute scheme { atomUri }?, 1715 attribute label { text }?, 1716 undefinedContent 1717 } 1719 # atom:contributor 1721 atomContributor = element atom:contributor { atomPersonConstruct } 1723 # atom:generator 1725 atomGenerator = element atom:generator { 1726 atomCommonAttributes, 1727 attribute uri { atomUri }?, 1728 attribute version { text }?, 1729 text 1730 } 1732 # atom:icon 1734 atomIcon = element atom:icon { 1735 atomCommonAttributes, 1736 (atomUri) 1737 } 1739 # atom:id 1741 atomId = element atom:id { 1742 atomCommonAttributes, 1743 (atomUri) 1744 } 1746 # atom:logo 1748 atomLogo = element atom:logo { 1749 atomCommonAttributes, 1750 (atomUri) 1751 } 1753 # atom:link 1755 atomLink = 1756 element atom:link { 1757 atomCommonAttributes, 1758 attribute href { atomUri }, 1759 attribute rel { atomNCName | atomUri }?, 1760 attribute type { atomMediaType }?, 1761 attribute hreflang { atomLanguageTag }?, 1762 attribute title { text }?, 1763 attribute length { text }?, 1764 undefinedContent 1765 } 1767 # atom:published 1769 atomPublished = element atom:published { atomDateConstruct } 1771 # atom:rights 1773 atomRights = element atom:rights { atomTextConstruct } 1775 # atom:source 1777 atomSource = 1778 element atom:source { 1779 atomCommonAttributes, 1780 (atomAuthor? 1781 & atomCategory* 1782 & atomContributor* 1783 & atomGenerator? 1784 & atomIcon? 1785 & atomId? 1786 & atomLink* 1787 & atomLogo? 1788 & atomRights? 1789 & atomSubtitle? 1790 & atomTitle? 1791 & atomUpdated? 1792 & extensionElement*) 1793 } 1795 # atom:subtitle 1797 atomSubtitle = element atom:subtitle { atomTextConstruct } 1799 # atom:summary 1801 atomSummary = element atom:summary { atomTextConstruct } 1803 # atom:title 1805 atomTitle = element atom:title { atomTextConstruct } 1807 # atom:updated 1809 atomUpdated = element atom:updated { atomDateConstruct } 1811 # Low-level simple types 1813 atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" } 1815 # Whatever a media type is, it contains at least one slash 1816 atomMediaType = xsd:string { pattern = ".+/.+" } 1818 # As defined in RFC 3066 1819 atomLanguageTag = xsd:string { 1820 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1821 } 1823 # Unconstrained; it's not entirely clear how IRI fit into 1824 # xsd:anyURI so let's not try to constrain it here 1825 atomUri = text 1827 # Whatever an email address is, it contains at least one @ 1828 atomEmailAddress = xsd:string { pattern = ".+@.+" } 1830 # Simple Extension 1831 simpleExtensionElement = 1832 element * - atom:* { 1833 text 1834 } 1836 # Structured Extension 1838 structuredExtensionElement = 1839 element * - atom:* { 1840 (attribute * { text }+, 1841 (text|anyElement)*) 1842 | (attribute * { text }*, 1843 (text?, anyElement+, (text|anyElement)*)) 1844 } 1846 # Other Extensibility 1848 extensionElement = 1849 simpleExtensionElement | structuredExtensionElement 1851 undefinedAttribute = 1852 attribute * - (xml:base | xml:lang | local:*) { text } 1854 undefinedContent = (text|anyForeignElement)* 1856 anyElement = 1857 element * { 1858 (attribute * { text } 1859 | text 1860 | anyElement)* 1861 } 1863 anyForeignElement = 1864 element * - atom:* { 1865 (attribute * { text } 1866 | text 1867 | anyElement)* 1868 } 1870 # XHTML 1872 anyXHTML = element xhtml:* { 1873 (attribute * { text } 1874 | text 1875 | anyXHTML)* 1876 } 1878 xhtmlDiv = element xhtml:div { 1879 (attribute * { text } 1880 | text 1881 | anyXHTML)* 1882 } 1884 # EOF 1886 Appendix C. Change Log 1888 [[anchor72: This section should be removed before final 1889 publication.]] 1891 -09: Changed atom:copyright to atom:rights. 1893 Clarify atom:source, also reflect changes to atom:feed 1895 Change 'minimal' to brief (PaceBriefExample). 1897 Add text about "Atom 1.0" (PaceAtom10). 1899 Remove SHOULD about content@src. 1901 feed/id now required. 1903 rework xml:base text 1905 rework xml:lang terms and requirements 1907 rework escaped markup explanations 1909 change atom:image to atom:logo 1911 Add example Date Constructs 1913 Clarify that atom:link and atom:category MUST be empty. 1915 Make XHTML definitions consistent 1917 atom:icon editorial fix-- capitalize SHOULD. 1919 -08: Remove BNF 1921 complete rather than collected schema 1923 Remove a couple introductory sentences 1925 update MIME references 1927 Many editorial adjustments 1929 -07: Change atom:source-feed to atom:source. 1931 Add ABNF reference 1933 Many editorial tweaks 1935 Rework extensibility 1937 Adjust page breaks in txt version 1939 -06: Move Identity Construct into atom:id (only place it's used) 1941 atom:id values must be unique within a feed. 1943 restore atom:copyright definition mistakenly dropped during 1944 alphabetizing. 1946 Remove atom:head, add atom:source-feed, and "Extension Construct" 1947 text in an effort to accurately reflect WG consensus on data model 1948 and extensibility, acknowledging two opinions in favor of atom: 1949 head. 1951 Note @hreflang issue. 1953 Add comment on atom:entry/atom:summary requirements. 1955 Rework atom:id text. The dereferencing section didn't talk about 1956 dereferencing. 1958 Remove protocol reference. 1960 Alphabetize where appropriate (PaceOrderSpecAlphabetically). 1962 Add mI language (PaceExtendingAtom). 1964 Add atom:icon and atom:image (PaceImageAndIcon). 1966 Change atom:tagline to atom:subtitle 1968 Add inline XHTML language (PaceXHTMLNamespaceDiv). 1970 Change "TEXT" etc, to lowercase 1972 Change example id IRI to urn:uuid:... 1974 Add rel="self" (PaceFeedLink). 1976 Add Feed State text (PaceNoFeedState). 1978 Move to IRIs (PaceIRI). 1980 Add rel="via" (PaceLinkRelVia). 1982 Add rel="enclosure" (PaceEnclosuresAndPix). 1984 Remove info and host (PaceRemoveInfoAndHost) 1986 Clarify order of entries (PaceEntryOrder). 1988 Remove version attribute (PaceRemoveVersionAttr). 1990 Date format roundup (PaceDatesXSD). 1992 Remove Service construct and elements. 1994 fix atom:contributor cardinality typo 1996 Removed motivation/design principles note; if we haven't come up 1997 with them by now... 1999 Put conformance text into notational conventions. 2001 Removed instances of 'software'; too specific. 2003 Added refs to HTML and XHTML. 2005 Updated ref to Infoset. 2007 Various editorial tweaks. 2009 Fix RFC 3023 refs in IANA section 2011 Adjust head/link requirement 2013 fix @version typos 2015 -05: Add RNC from N. Walsh. 2017 Re-organize element definitions. 2019 Lift the prohibition on other types of DSig and encryption. 2021 Remove text on "indiscriminate use" of DSig and XMLEnc. 2023 -04: Update URI terms for 2396bis. 2025 Add Category construct (PaceCategoryRevised). 2027 Insert paranoid XHTML interpretation guidelines. 2029 Adjust atom:copyright, per chairs' instruction. 2031 Add atom:host as child element of atom:entry, per chairs' 2032 direction (PacePersonConstruct). 2034 Add link/content co-constraint (PaceContentOrLink). 2036 Remove atom:origin as a side effect of adding atom:head to atom: 2037 entry (PaceHeadInEntry). 2039 Add optional length attribute to atom:link (PaceLinkRelated). 2041 Add Link registry to Link Construct, IANA Considerations 2042 placeholder (PaceFieldingLinks). 2044 Change definition of atom:updated (PaceUpdatedDefinition). 2046 -03: Move definition of Link @rel to format spec, restrict 2047 acceptable values (PaceMoveLinkElement, PaceLinkAttrDefaults). 2049 Add Service Construct, head/post, head/introspection, entry/edit 2050 (PaceServiceElement). 2052 Add Text Construct, entry/content (PaceReformedContent3). 2054 Add entry/published (PaceDatePublished). 2056 Adjust definition of Identity Construct per chairs' direction to 2057 "fix it." 2059 Add Sayre to editors. 2061 -02: Removed entry/modified, entry/issued, entry/created; added 2062 entry/updated (PaceDateUpdated). 2064 Changed date construct from W3C date-time to RFC3339 2065 (PaceDateUpdated). 2067 Feed links to HTML pages should be reflected back 2068 (PaceLinkReflection). 2070 Added Identity construct (PaceIdConstruct). 2072 Changed feed/id and entry/id to be Identity constructs 2073 (PaceIdConstruct). 2075 Changed entry/origin's content so that it's the same as the feed's 2076 id, rather than its link/@rel="alternate" (PaceIdConstruct). 2078 Added "Securing Atom Documents" (PaceDigitalSignatures). 2080 -01: Constrained omission of "Information Item" to just elements and 2081 attributes. 2083 Clarified xml:lang inheritence. 2085 Removed entry- and feed-specific langauge about xml:lang (covered 2086 by general discussion of xml:lang) 2088 Changed xml:lang to reference XML for normative requirements. 2090 Changed "... MUST be a string" to "... is unstructued text." 2092 Remomved langauge about DOCTYPEs, PIs, Comments, Entities. 2094 Changed atom:url to atom:uri, @url to @uri 2096 Introduced atom:head 2098 Introduced "Atom Feed Document" and "Atom Entry Document". 2100 Removed requirement for all elements and attributes to be 2101 namespace-qualified; now children of selective elements 2103 Added extensibility to Person constructs. 2105 Removed requirement for media types to be registered (non- 2106 registered media types are legal) 2108 Added atom:origin (PaceEntryOrigin) 2110 Added requirement for entry/id to be present and a URI 2111 (PaceEntryIdRequired). 2113 Clarified approach to Comments, PIs and well-formedness, as per 2114 RFC3470. 2116 Referenced escaping algorithm in XML. 2118 Assorted editorial nits and cleanup, refactoring 2120 -00: Initial IETF Internet-Draft submission. 2122 Added optional version attribute to entry 2123 (PaceEntryElementNeedsVersionAttribute). 2125 Added hreflang attribute (PaceHrefLang). 2127 Clarified inheritence of copyright element (PaceItemCopyright). 2129 Added xml:lang to entries (PaceItemLang). 2131 Tweaked Infoset-related language (PaceNoInfoSet). 2133 Clarified lack of structure in version attribute 2134 (PaceVersionAsText). 2136 Changed approach to XML Base (PaceXmlBaseEverywhere). 2138 Added XML Base processing to atom:id (PaceXmlBaseId). 2140 Various editorial cleanup and adjustments for IETF publication. 2142 Intellectual Property Statement 2144 The IETF takes no position regarding the validity or scope of any 2145 Intellectual Property Rights or other rights that might be claimed to 2146 pertain to the implementation or use of the technology described in 2147 this document or the extent to which any license under such rights 2148 might or might not be available; nor does it represent that it has 2149 made any independent effort to identify any such rights. Information 2150 on the procedures with respect to rights in RFC documents can be 2151 found in BCP 78 and BCP 79. 2153 Copies of IPR disclosures made to the IETF Secretariat and any 2154 assurances of licenses to be made available, or the result of an 2155 attempt made to obtain a general license or permission for the use of 2156 such proprietary rights by implementers or users of this 2157 specification can be obtained from the IETF on-line IPR repository at 2158 http://www.ietf.org/ipr. 2160 The IETF invites any interested party to bring to its attention any 2161 copyrights, patents or patent applications, or other proprietary 2162 rights that may cover technology that may be required to implement 2163 this standard. Please address the information to the IETF at 2164 ietf-ipr@ietf.org. 2166 Disclaimer of Validity 2168 This document and the information contained herein are provided on an 2169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2171 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2172 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2173 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2176 Copyright Statement 2178 Copyright (C) The Internet Society (2005). This document is subject 2179 to the rights, licenses and restrictions contained in BCP 78, and 2180 except as set forth therein, the authors retain all their rights. 2182 Acknowledgment 2184 Funding for the RFC Editor function is currently provided by the 2185 Internet Society.