idnits 2.17.1 draft-ietf-atompub-format-07.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.a on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1911. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1918. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1924. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 31, 2005) is 6965 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) == Unused Reference: 'Atom-autodiscovery' is defined on line 1312, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Atom-autodiscovery' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** 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) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham, Ed. 3 Internet-Draft R. Sayre, Ed. 4 Expires: October 2, 2005 March 31, 2005 6 The Atom Syndication Format 7 draft-ietf-atompub-format-07 9 Status of this Memo 11 This document is an Internet-Draft and is subject to all provisions 12 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 13 author represents that any applicable patent or other IPR claims of 14 which he or she is aware have been or will be disclosed, and any of 15 which he or she become aware will be disclosed, in accordance with 16 RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 2, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document specifies Atom, an XML-based Web content and metadata 43 syndication format. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.2 Notational Conventions . . . . . . . . . . . . . . . . . . 5 50 2. Atom Documents . . . . . . . . . . . . . . . . . . . . . . . 6 51 3. Common Atom Constructs . . . . . . . . . . . . . . . . . . . 8 52 3.1 Text Constructs . . . . . . . . . . . . . . . . . . . . . 8 53 3.1.1 The "type" Attribute . . . . . . . . . . . . . . . . . 8 54 3.2 Person Constructs . . . . . . . . . . . . . . . . . . . . 11 55 3.2.1 The "atom:name" Element . . . . . . . . . . . . . . . 11 56 3.2.2 The "atom:uri" Element . . . . . . . . . . . . . . . . 11 57 3.2.3 The "atom:email" Element . . . . . . . . . . . . . . . 11 58 3.3 Date Constructs . . . . . . . . . . . . . . . . . . . . . 12 59 4. Atom Element Definitions . . . . . . . . . . . . . . . . . . 13 60 4.1 Container Elements . . . . . . . . . . . . . . . . . . . . 13 61 4.1.1 The "atom:feed" Element . . . . . . . . . . . . . . . 13 62 4.1.2 The "atom:entry" Element . . . . . . . . . . . . . . . 15 63 4.1.3 The "atom:content" Element . . . . . . . . . . . . . . 17 64 4.2 Metadata Elements . . . . . . . . . . . . . . . . . . . . 20 65 4.2.1 The "atom:author" Element . . . . . . . . . . . . . . 20 66 4.2.2 The "atom:category" Element . . . . . . . . . . . . . 20 67 4.2.3 The "atom:contributor" Element . . . . . . . . . . . . 20 68 4.2.4 The "atom:copyright" Element . . . . . . . . . . . . . 21 69 4.2.5 The "atom:generator" Element . . . . . . . . . . . . . 21 70 4.2.6 The "atom:icon" Element . . . . . . . . . . . . . . . 21 71 4.2.7 The "atom:id" Element . . . . . . . . . . . . . . . . 22 72 4.2.8 The "atom:image" Element . . . . . . . . . . . . . . . 23 73 4.2.9 The "atom:link" Element . . . . . . . . . . . . . . . 24 74 4.2.10 The "atom:published" Element . . . . . . . . . . . . 26 75 4.2.11 The "atom:source" Element . . . . . . . . . . . . . 26 76 4.2.12 The "atom:subtitle" Element . . . . . . . . . . . . 27 77 4.2.13 The "atom:summary" Element . . . . . . . . . . . . . 27 78 4.2.14 The "atom:title" Element . . . . . . . . . . . . . . 27 79 4.2.15 The "atom:updated" Element . . . . . . . . . . . . . 27 80 5. Securing Atom Documents . . . . . . . . . . . . . . . . . . 29 81 6. Extending Atom . . . . . . . . . . . . . . . . . . . . . . . 30 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 32 83 8. Security Considerations . . . . . . . . . . . . . . . . . . 34 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 85 9.1 Normative References . . . . . . . . . . . . . . . . . . . 35 86 9.2 Informative References . . . . . . . . . . . . . . . . . . 36 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 37 88 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 38 89 B. Collected RELAX NG Compact Schema . . . . . . . . . . . . . 39 90 C. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 47 91 Intellectual Property and Copyright Statements . . . . . . . 50 93 1. Introduction 95 Atom is an XML-based document format that describes lists of related 96 information known as "feeds". Feeds are composed of a number of 97 items, known as "entries", each with an extensible set of attached 98 metadata. For example, each entry has a title. 100 The primary use case that Atom addresses is the syndication of Web 101 content such as Weblogs and news headlines to Web sites as well as 102 directly to user agents. However, nothing precludes it from being 103 used for other purposes and kinds of content. 105 1.1 Examples 107 A minimal, single-entry Atom Feed Document: 109 110 112 Example Feed 113 114 2003-12-13T18:30:02Z 115 116 John Doe 117 119 120 Atom-Powered Robots Run Amok 121 122 urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a 123 2003-12-13T18:30:02Z 124 Some text. 125 127 128 A more extensive, single-entry Atom Feed Document: 130 131 132 dive into mark 133 134 A <em>lot</em> of effort 135 went into making this effortless 136 137 2005-04-02T12:29:29Z 138 tag:example.org,2003:3 139 141 Copyright (c) 2003, Mark Pilgrim 142 143 Example Toolkit 144 145 146 Atom draft-07 snapshot 147 149 151 tag:example.org,2003:3.2397 152 2005-04-02T12:29:29Z 153 2003-12-13T08:29:29-04:00 154 155 Mark Pilgrim 156 http://example.org/ 157 f8dy@example.com 158 159 160 Sam Ruby 161 http://intertwingly.net/blog/ 162 163 164 Joe Gregorio 165 http://bitworking.org/ 166 167 169
170

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

171
172 173 174 176 1.2 Notational Conventions 178 This specification describes conformance in terms of two artifacts; 179 Atom Feed Documents and Atom Entry documents. Additionally, it 180 places some requirements on Atom Processors. 182 This specification uses XML Namespaces [W3C.REC-xml-names-19990114] 183 to uniquely identify XML element names. It uses the following 184 namespace prefix for the indicated namespace URI; 186 "atom": http://purl.org/atom/ns#draft-ietf-atompub-format-07 188 Note that the choice of any namespace prefix is arbitrary and not 189 semantically significant. 191 Atom is specified using terms from the XML Infoset 192 [W3C.REC-xml-infoset-20040204]. However, this specification uses a 193 shorthand for two common terms; the phrase "Information Item" is 194 omitted when naming Element Information Items and Attribute 195 Information Items. 197 Therefore, when this specification uses the term "element," it is 198 referring to an Element Information Item in Infoset terms. Likewise, 199 when it uses the term "attribute," it is referring to an Attribute 200 Information Item. 202 Some sections of this specification are illustrated with fragments of 203 a non-normative RELAX NG Compact schema [RELAX-NG]. However, the 204 text of this specification provides the definition of conformance. A 205 collected schema appears in Appendix B. 207 Some sections of this specification are illustrated with Augmented 208 Backus-Naur Form (ABNF), a format used to represent permissible 209 strings in a protocol or language, as defined in [RFC2234]. 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in BCP 14, [RFC2119], as 214 scoped to those conformance targets. 216 2. Atom Documents 218 This specification describes two kinds of Atom Documents; Atom Feed 219 Documents and Atom Entry Documents. 221 An Atom Feed Document is a representation of an Atom feed, including 222 metadata about the feed, and some or all of the entries associated 223 with it. Its root is the atom:feed element. 225 An Atom Entry Document represents exactly one Atom entry, outside of 226 the context of an Atom feed. Its root is the atom:entry element. 228 namespace atom = 229 "http://purl.org/atom/ns#draft-ietf-atompub-format-07" 230 start = atomFeed | atomEntry 232 Both kinds of Atom documents are specified in terms of the XML 233 Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204] and 234 identified with the "application/atom+xml" media type. Atom 235 Documents MUST be well-formed XML. 237 Atom constrains the appearance and content of elements and 238 attributes; unless otherwise stated, Atom Documents MAY contain other 239 Information Items as appropriate. 241 Any element defined by this specification MAY have an xml:base 242 attribute. XML Base [W3C.REC-xmlbase-20010627] processing MUST be 243 applied to any relative reference [RFC3987] present in an Atom 244 Document. This includes such elements and attributes as specified by 245 Atom itself, as well as those specified by extensions to Atom. 247 Any element defined by this specification MAY have an xml:lang 248 attribute, whose content indicates the natural language for the 249 element and its children. The language context is only significant 250 for elements and attributes declared to be "language-sensitive" by 251 this specification. Requirements regarding the content and 252 interpretation of xml:lang are specified in XML 1.0 253 [W3C.REC-xml-20040204], Section 2.12. 255 atomCommonAttributes = 256 attribute xml:base { atomUri }?, 257 attribute xml:lang { atomLanguageTag }? 259 Atom allows the use of IRIs [RFC3987], as well as URIs [RFC3986]. 260 For resolution, IRIs can easily be converted to URIs. When comparing 261 IRIs serving as atom:id values, they MUST NOT be converted to URIs. 262 By definition, every URI is an IRI, so any URI can be used where an 263 IRI is needed. 265 Atom is an extensible format. See the section titled 'Extending 266 Atom' later in this document for a full description of how Atom 267 Documents can be extended. 269 Atom Processors MAY keep state (e.g., metadata in atom:feed, entries) 270 sourced from Atom Feed Documents and combine them with other Atom 271 Feed Documents, in order to facilitate a contiguous view of the 272 contents of a feed. The manner in which Atom Feed Documents are 273 combined in order to reconstruct a feed (e.g., updating entries and 274 metadata, dealing with missing entries) is out of the scope of this 275 specification, but may be defined by an extension to Atom. 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". 311 Note that MIME media types [RFC2045] are not acceptable values for 312 the "type" attribute. 314 3.1.1.1 Text 316 Example atom:title with text content: 318 ... 319 320 Less: < 321 322 ... 324 If the value is "text", the content of the Text construct MUST NOT 325 contain child elements. Such text is intended to be presented to 326 humans in a readable fashion. Thus, Atom Processors MAY display it 327 using normal text rendering techniques such as proportional fonts, 328 white-space collapsing, and justification. 330 3.1.1.2 HTML 332 Example atom:title with HTML content: 334 ... 335 336 Less: <em> &lt; </em> 337 338 ... 340 If the value of "type" is "html", the content of the Text construct 341 MUST NOT contain child elements, and SHOULD be suitable for handling 342 as HTML [W3C.REC-html401-19991224]. Any markup within MUST be 343 escaped; for example, "
" as "<br>". HTML markup within SHOULD 344 be such that it could validly appear directly within an HTML
345 element, after unescaping. Atom Processors that display such content 346 MAY use that markup to aid in its display. 348 3.1.1.3 XHTML 350 Example atom:title with XHTML content: 352 ... 353 354 <xhtml:div> 355 Less: <xhtml:em> < </xhtml:em> 356 </xhtml:div> 357 358 ... 360 If the value of "type" is "xhtml", the content of the Text construct 361 MUST be a single XHTML div element [W3C.REC-xhtml-basic-20001219]. 362 The XHTML div MUST contain XHTML text and markup that could validly 363 appear within an XHTML div element. The XHTML div element itself 364 MUST NOT be considered part of the content. Atom Processors which 365 display the content MAY use the markup to aid in displaying it. 366 Escaped characters, such as "&" and ">", represent those characters, 367 not markup. 369 Examples of valid XHTML content: 371 ... 372 373
374 This is XHTML content. 375
376 377 ... 378 379 380 This is XHTML content. 381 382 383 ... 385 The following example assumes that the XHTML namespace has been bound 386 to the "xh" prefix earlier in the document: 388 ... 389 390 391 This is XHTML content. 392 393 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 429 atom:email element, but MUST NOT contain more than one. Its content 430 MUST conform to the addr-spec BNF rule in [RFC2822]. 432 3.3 Date Constructs 434 A Date construct is an element whose content MUST conform to the 435 extended date-time form ABNF rule in [RFC3339]. In addition, an 436 uppercase "T" character MUST be used to separate date and time, and 437 an uppercase "Z" character MUST be present in the absence of a 438 numeric time zone 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 Date values SHOULD be as accurate as possible. For example, it would 449 be generally inappropriate for a publishing system to apply the same 450 timestamp to several entries which were published during the course 451 of a single day. 453 4. Atom Element Definitions 455 4.1 Container Elements 457 4.1.1 The "atom:feed" Element 459 The "atom:feed" element is the document (i.e., top-level) element of 460 an Atom Feed Document, acting as a container for metadata and data 461 associated with the feed. Its element children consist of metadata 462 elements followed by zero or more atom:entry child elements. 464 atomFeed = 465 element atom:feed { 466 atomCommonAttributes, 467 (atomAuthor? 468 & atomCategory* 469 & atomContributor* 470 & atomCopyright? 471 & atomGenerator? 472 & atomIcon? 473 & atomId? 474 & atomImage? 475 & atomLink+ 476 & atomSubtitle? 477 & atomTitle 478 & atomUpdated 479 & extensionElement*), 480 atomEntry* 481 } 483 This specification assigns no significance to the order of atom:entry 484 elements within the feed. 486 The following child elements are defined by this specification (note 487 that the presence of some of these elements is required): 489 o atom:feed elements MUST contain exactly one atom:author element, 490 UNLESS all of the atom:feed element's child atom:entry elements 491 contain an atom:author element. atom:feed elements MUST NOT 492 contain more than one atom:author element. 493 o atom:feed elements MAY contain any number of atom:category 494 elements. 495 o atom:feed elements MAY contain any number of atom:contributor 496 elements. 497 o atom:feed elements MUST NOT contain more than one atom:copyright 498 element. 499 o atom:feed elements MUST NOT contain more than one atom:generator 500 element. 501 o atom:feed elements MUST NOT contain more than one atom:icon 502 element. 503 o atom:feed elements MUST NOT contain more than one atom:image 504 element. 505 o atom:feed elements MUST NOT contain more than one atom:id element. 506 o atom:feed elements MUST contain at least one atom:link element 507 with a relation of "alternate". 508 o atom:feed elements SHOULD contain one atom:link element with a rel 509 attribute value of "self". This URI identifies the feed and a 510 representation equivalent to the feed. 511 o atom:feed elements MUST NOT contain more than one atom:link 512 element with a rel attribute value of "alternate" that has the 513 same type attribute value. If a feed's atom:link element with 514 type="alternate" resolves to an HTML document, then that document 515 SHOULD have a autodiscovery link element [Atom-autodiscovery] that 516 reflects back to the feed. atom:feed elements MAY contain 517 additional atom:link elements beyond those described above. 518 o atom:feed elements MUST NOT contain more than one atom:subtitle 519 element. 520 o atom:feed elements MUST contain exactly one atom:title element. 521 o atom:feed elements MUST contain exactly one atom:updated element. 522 o atom:feed elements MUST NOT contain atom:entry elements with 523 identical atom:id values. 525 4.1.2 The "atom:entry" Element 527 The "atom:entry" element represents an individual entry, acting as a 528 container for metadata and data associated with the entry. This 529 element can appear as a child of the atom:feed element, or it can 530 appear as the document (i.e., top-level) element of a standalone Atom 531 Entry Document. 533 atomEntry = 534 element atom:entry { 535 atomCommonAttributes, 536 (atomAuthor? 537 & atomCategory* 538 & atomContent? 539 & atomContributor* 540 & atomCopyright? 541 & atomId 542 & atomLink* 543 & atomPublished? 544 & atomSource? 545 & atomSummary? 546 & atomTitle 547 & atomUpdated 548 & extensionElement*) 549 } 551 This specification assigns no significance to the order of appearance 552 of the child elements of atom:entry. 554 The following child elements are defined by this specification (note 555 that it requires the presence of some of these elements): 557 o atom:entry elements MUST contain exactly one atom:author element, 558 unless the atom:entry contains an atom:source element which 559 contains an atom:author element, or, in an Atom Feed Document, the 560 atom:feed element contains an atom:author element itself. 561 atom:entry elements MUST NOT contain more than one atom:author 562 element. 563 o atom:entry elements MAY contain any number of atom:category 564 elements. 565 o atom:entry elements MUST NOT contain more than one atom:content 566 element. 567 o atom:entry elements MAY contain any number of atom:contributor 568 elements. 569 o atom:entry elements MUST NOT contain more than one atom:copyright 570 element. 571 o atom:entry elements MUST contain exactly one atom:id element. 572 o atom:entry elements that contain no child atom:content element 573 MUST contain at least one atom:link element with a rel attribute 574 value of "alternate". atom:entry elements MUST NOT contain more 575 than one atom:link element with a rel attribute value of 576 "alternate" that has the same combination of type and hreflang 577 attribute values. atom:entry elements MAY contain additional 578 atom:link elements beyond those described above. 579 o atom:entry elements MUST NOT contain more than one atom:published 580 element. 581 o atom:entry elements MUST NOT contain more than one atom:source 582 element. 583 o atom:entry elements MUST contain an atom:summary element in any of 584 the following cases: 585 * the atom:entry element contains no atom:content element. 586 * the atom:entry contains an atom:content that has a "src" 587 attribute (and is thus empty). 588 * the atom:entry contains content that is encoded in Base64; i.e. 589 the "type" attribute of atom:content is a MIME media type 590 [RFC2045] and does not begin with "text/" nor end with "+xml". 591 o atom:entry elements MUST NOT contain more than one atom:summary 592 element. 593 o atom:entry elements MUST have exactly one "atom:title" element. 594 o atom:entry elements MUST contain exactly one atom:updated element. 596 4.1.3 The "atom:content" Element 598 The "atom:content" element either contains or links to the content of 599 the entry. The content of atom:content is language-sensitive. 601 atomInlineTextContent = 602 element atom:content { 603 atomCommonAttributes, 604 attribute type { "text" | "html" }?, 605 (text)* 606 } 608 atomInlineXHTMLContent = 609 element atom:content { 610 atomCommonAttributes, 611 attribute type { "xhtml" }, 612 xhtmlDiv 613 } 615 atomInlineOtherContent = 616 element atom:content { 617 atomCommonAttributes, 618 attribute type { atomMediaType }?, 619 (text|anyElement)* 620 } 622 atomOutOfLineContent = 623 element atom:content { 624 atomCommonAttributes, 625 attribute type { atomMediaType }?, 626 attribute src { atomUri }, 627 empty 628 } 630 atomContent = atomInlineTextContent 631 | atomInlineXHTMLContent 632 | atomInlineOtherContent 633 | atomOutOfLineContent 635 4.1.3.1 The "type" attribute 637 atom:content MAY have a "type" attribute. When present, the value 638 MAY be one of "text", "html", or "xhtml". Failing that, it MUST be a 639 MIME media type [RFC2045] with a discrete top-level type (see Section 640 5 of [RFC2045]). If the type attribute is not provided, Atom 641 Processors MUST behave as though it were present with a value of 642 "text". 644 4.1.3.2 The "src" attribute 646 atom:content MAY have a "src" attribute, whose value MUST be an IRI 647 reference [RFC3987]. If the "src" attribute is present, Atom 648 Processors MAY use the IRI to retrieve the content. If the "src" 649 attribute is present, atom:content MUST be empty. That is to say, 650 the content may be retrievable using "src=" IRI, or it may be 651 contained within atom:content, but not both. 653 If the "src" attribute is present, the "type" attribute SHOULD be 654 provided and MUST be a MIME media type [RFC2045], rather than "text", 655 "html", or "xhtml". The value is advisory; that is to say, upon 656 dereferencing the IRI to retrieve the content, if the server 657 providing that content also provides a media type, the 658 server-provided media type is authoritative. 660 If the value of type begins with "text/" or ends with "+xml", the 661 content SHOULD be local; that is to say, no "src" attribute should be 662 provided. 664 4.1.3.3 Processing Model 666 Atom Documents MUST conform to the following rules. Atom Processors 667 MUST interpret atom:content according to the first applicable rule. 669 1. If the value of "type" is "text", the content of atom:content 670 MUST NOT contain child elements. Such text is intended to be 671 presented to humans in a readable fashion. Thus, Atom Processors 672 MAY display it using normal text rendering techniques such as 673 proportional fonts, white-space collapsing, and justification. 675 2. If the value of "type" is "html", the content of atom:content 676 MUST NOT contain child elements, and SHOULD be suitable for 677 handling as HTML [W3C.REC-html401-19991224]. The HTML markup 678 must be escaped; for example, "
" as "<br>". The HTML 679 markup SHOULD be such that it could validly appear directly 680 within an HTML
element. Atom Processors that display the 681 content SHOULD use the markup to aid in displaying it. 683 3. If the value of "type" is "xhtml", the content of atom:content 684 MUST be a single XHTML div element 685 [W3C.REC-xhtml-basic-20001219]. The XHTML div MUST contain XHTML 686 text and markup that could validly appear within an XHTML div 687 element. The XHTML div element itself MUST NOT be considered 688 part of the content. Atom Processors that display the content 689 MAY use the markup to aid in displaying it. Escaped markup is 690 interpreted as a text representation of markup, and MUST NOT be 691 interpreted as markup itself. 693 4. If the value of "type" ends with "+xml" or "/xml" 694 (case-insensitive), the content of atom:content may include child 695 elements, and SHOULD be suitable for handling as the indicated 696 media type. If the "src" attribute is not provided, this would 697 normally mean that the "atom:content" element would contain a 698 single child element which would serve as the root element of the 699 XML document of the indicated type. 701 5. If the value of "type" begins with "text/" (case-insensitive), 702 the content of atom:content MUST NOT contain child elements. 704 6. For all other values of "type", the content of atom:content MUST 705 be a valid Base64 encoding [RFC3548], which when decoded SHOULD 706 be suitable for handling as the indicated media type. In this 707 case, the characters in the Base64 encoding may be preceded and 708 followed in the atom:content element by whitespace, and lines are 709 separated by a single newline (U+000A) character. 711 4.1.3.4 Examples 713 XHTML inline: 715 ... 716 717
718 This is XHTML content. 719
720 721 ... 722 723 724 This is XHTML content. 725 726 727 ... 729 The following example assumes that the XHTML namespace has been bound 730 to the "xh" prefix earlier in the document: 732 ... 733 734 735 This is XHTML content. 736 737 738 ... 740 4.2 Metadata Elements 742 4.2.1 The "atom:author" Element 744 The "atom:author" element is a Person construct that indicates the 745 author of the entry or feed. 747 atomAuthor = element atom:author { atomPersonConstruct } 749 4.2.2 The "atom:category" Element 751 The "atom:category" element conveys information about a category 752 associated with an entry or feed. 754 atomCategory = 755 element atom:category { 756 atomCommonAttributes, 757 attribute term { text }, 758 attribute scheme { atomUri }?, 759 attribute label { text }?, 760 empty 761 } 763 4.2.2.1 The "term" Attribute 765 The "term" attribute is a string that identifies the category to 766 which the entry or feed belongs. Category elements MUST have a 767 "term" attribute. 769 4.2.2.2 The "scheme" Attribute 771 The "scheme" attribute is an IRI that identifies a categorization 772 scheme. Category elements MAY have a "scheme" attribute. 774 4.2.2.3 The "label" attribute 776 The "label" attribute provides a human-readable label for display in 777 end-user applications. The content of the "label" attribute is 778 language-sensitive. Category elements MAY have a "label" attribute. 780 4.2.3 The "atom:contributor" Element 782 The "atom:contributor" element is a Person construct that indicates a 783 person or other entity who contributed to the entry or feed. 785 atomContributor = element atom:contributor { atomPersonConstruct } 787 4.2.4 The "atom:copyright" Element 789 The "atom:copyright" element is a Text construct that conveys a 790 human-readable copyright statement for an entry or feed. 792 atomCopyright = element atom:copyright { atomTextConstruct } 794 The atom:copyright element SHOULD NOT be used to convey 795 machine-readable licensing information. 797 If an atom:entry element does not contain an atom:copyright element, 798 then the atom:copyright element of the containing atom:feed element's 799 atom:head element, if present, is considered to apply to the entry. 801 4.2.5 The "atom:generator" Element 803 The "atom:generator" element's content identifies the agent used to 804 generate a feed, for debugging and other purposes. 806 atomGenerator = element atom:generator { 807 atomCommonAttributes, 808 attribute uri { atomUri }?, 809 attribute version { text }?, 810 text 811 } 813 The content of this element, when present, MUST be a string that is a 814 human-readable name for the generating agent. 816 The atom:generator element MAY have a "uri" attribute whose value 817 MUST be an IRI reference [RFC3987]. When dereferenced, that IRI 818 SHOULD produce a representation that is relevant to that agent. 820 The atom:generator element MAY have a "version" attribute that 821 indicates the version of the generating agent. When present, its 822 value is unstructured text. 824 4.2.6 The "atom:icon" Element 826 The "atom:icon" element's content is an IRI reference [RFC3987] which 827 identifies an image which provides iconic visual identification for a 828 feed. 830 atomIcon = element atom:icon { 831 atomCommonAttributes, 832 (atomUri) 833 } 834 The image SHOULD have an aspect ratio of one (horizontal) to one 835 (vertical), and should be suitable for presentation at a small size. 837 4.2.7 The "atom:id" Element 839 The "atom:id" element conveys a permanent, universally unique 840 identifier for an entry or feed. 842 atomId = element atom:id { 843 atomCommonAttributes, 844 (atomUri) 845 } 847 Its content MUST be an IRI, as defined by [RFC3987]. Note that the 848 definition of "IRI" excludes relative references. Though the IRI 849 might use a dereferencable scheme, Atom Processors MUST NOT assume it 850 can be dereferenced. 852 When an Atom document is relocated, migrated, syndicated, 853 republished, exported or imported, the content of its atom:id element 854 MUST NOT change. Put another way, an atom:id element pertains to all 855 instantiations of a particular Atom entry or feed; revisions retain 856 the same content in their atom:id elements. It is suggested that the 857 atom:id element be stored along with the associated resource. 859 The content of an atom:id element MUST be created in a way that 860 assures uniqueness. 862 Because of the risk of confusion between IRIs that would be 863 equivalent if dereferenced, the following normalization strategy is 864 strongly encouraged when generating atom:id elements: 866 o Provide the scheme in lowercase characters. 867 o Provide the host, if any, in lowercase characters. 868 o Only perform percent-encoding where it is essential. 869 o Use uppercase A-through-F characters when percent-encoding. 870 o Prevent dot-segments appearing in paths. 871 o For schemes that define a default authority, use an empty 872 authority if the default is desired. 873 o For schemes that define an empty path to be equivalent to a path 874 of "/", use "/". 875 o For schemes that define a port, use an empty port if the default 876 is desired. 877 o Preserve empty fragment identifiers and queries. 878 o Ensure that all components of the IRI are appropriately 879 character-normalized, e.g. by using NFC or NFKC. 881 4.2.7.1 Comparing atom:id 883 Instances of atom:id elements can be compared to determine whether an 884 entry or feed is the same as one seen before. Processors MUST 885 compare atom:id elements on a character-by-character basis (in a 886 case-sensitive fashion). Comparison operations MUST be based solely 887 on the IRI character strings, and MUST NOT rely on dereferencing the 888 IRIs. 890 As a result, two IRIs that resolve to the same resource but are not 891 character-for-character identical will be considered different for 892 the purposes of identifier comparison. 894 For example: 896 http://www.example.org/thing 897 http://www.example.org/Thing 898 http://www.EXAMPLE.org/thing 899 HTTP://www.example.org/thing 901 are four distinct identifiers, despite their differences in case. 903 Likewise, 905 http://www.example.com/~bob 906 http://www.example.com/%7ebob 907 http://www.example.com/%7Ebob 909 are three distinct identifiers, because IRI %-escaping is significant 910 for the purposes of comparison. 912 4.2.8 The "atom:image" Element 914 The "atom:image" element's content is an IRI reference [RFC3987] 915 which identifies an image which provides visual identification for a 916 feed. 918 atomImage = element atom:image { 919 atomCommonAttributes, 920 (atomUri) 921 } 923 The image SHOULD have an aspect ratio of 2 (horizontal) to 1 924 (vertical). 926 4.2.9 The "atom:link" Element 928 The "atom:link" element is an empty element that defines a reference 929 from an entry or feed to a Web resource. 931 atomLink = 932 element atom:link { 933 atomCommonAttributes, 934 attribute href { atomUri }, 935 attribute rel { atomNCName | atomUri }?, 936 attribute type { atomMediaType }?, 937 attribute hreflang { atomLanguageTag }?, 938 attribute title { text }?, 939 attribute length { text }?, 940 empty 941 } 943 4.2.9.1 The "href" Attribute 945 The "href" attribute contains the link's IRI. atom:link elements 946 MUST have a href attribute, whose value MUST be a IRI reference 947 [RFC3987]. 949 4.2.9.2 The "rel" Attribute 951 atom:link elements MAY have a "rel" attribute that indicates the link 952 relation type. If the "rel" attribute is not present, the link 953 element MUST be interpreted as if the link relation type is 954 "alternate". 956 ABNF for the "rel" attribute: 958 rel_attribute = isegment-nz-nc / IRI 960 The value of "rel" MUST be string that is non-empty, does not contain 961 any colon (":") characters, and matches the "isegment-nz-nc" or "IRI" 962 ABNF forms in [RFC3987]. Note that use of a relative reference is 963 not allowed. If a name is given, implementations MUST consider the 964 link relation type to be equivalent to the same name registered 965 within the IANA Registry of Link Relations Section 7, and thus the 966 IRI that would be obtained by appending the value of the rel 967 attribute to the string "http://www.iana.org/assignments/relation/". 968 The value of "rel" describes the meaning of the link, but does not 969 impose any behavioral requirements on implementations. 971 This document defines five initial values for the Registry of Link 972 Relations: 974 1. The value "alternate" signifies that the IRI in the value of the 975 href attribute identifies an alternate version of the resource 976 described by the containing element. 978 2. The value "related" signifies that the IRI in the value of the 979 href attribute identifies a resource related to the resource 980 described by the containing element. For example, the feed for a 981 site that discusses the performance of the search engine at 982 "http://search.example.com" might contain, as a child of 983 atom:feed: 985 987 An identical link might appear as a child of any atom:entry whose 988 content contains a discussion of that same search engine. 990 3. The value "self" signifies that the IRI in the value of the href 991 attribute identifies a resource equivalent to the containing 992 element. 994 4. The value "enclosure" signifies that the IRI in the value of the 995 href attribute identifies a related resource which is potentially 996 large in size and may require special handling by consuming 997 software. For Link elements with rel="enclosure", the length 998 attribute SHOULD be provided. 1000 5. The value "via" signifies that the IRI in the value of the href 1001 attribute identifies a resource that is the source of the 1002 information provided in the containing element. 1004 4.2.9.3 The "type" Attribute 1006 The "type" attribute's value is an advisory media type; it is a hint 1007 about the type of the representation that is expected to be returned 1008 when the value of the href attribute is dereferenced. Note that the 1009 type attribute does not override the actual media type returned with 1010 the representation. Link elements MAY have a type attribute, whose 1011 value MUST conform to the syntax of a MIME media type [RFC2045]. 1013 4.2.9.4 The "hreflang" Attribute 1015 The "hreflang" attribute's content describes the language of the 1016 resource pointed to by the href attribute. When used together with 1017 the rel="alternate", it implies a translated version of the entry. 1018 Link elements MAY have an hreflang attribute, whose value MUST be a 1019 language tag [RFC3066]. 1021 4.2.9.5 The "title" Attribute 1023 The "title" attribute conveys human-readable information about the 1024 link. The content of the "title" attribute is language sensitive. 1025 Link elements MAY have a title attribute. 1027 4.2.9.6 The "length" Attribute 1029 The "length" attribute indicates an advisory length of the linked 1030 content in octets; it is a hint about the content length of the 1031 representation returned when the IRI in the href attribute is 1032 dereferenced. Note that the length attribute does not override the 1033 actual content length of the representation as reported by the 1034 underlying protocol. Link elements MAY have a length attribute. 1036 4.2.10 The "atom:published" Element 1038 The "atom:published" element is a Date construct indicating an 1039 instant in time associated with an event early in the life cycle of 1040 the entry. 1042 atomPublished = element atom:published { atomDateConstruct } 1044 Typically, atom:published will be associated with the initial 1045 creation or first availability of the resource. 1047 4.2.11 The "atom:source" Element 1049 If an atom:entry is copied from one feed into another feed, then the 1050 source atom:feed's metadata (all child elements of atom:feed other 1051 than the atom:entry elements) MAY be preserved within the copied 1052 entry by adding an atom:source child element, if it is not already 1053 present in the entry, and including some or all of the source feed's 1054 metadata elements as the atom:source element's children. Such 1055 metadata SHOULD be preserved if the source atom:feed contains any of 1056 the child elements atom:author, atom:contributor, atom:copyright, or 1057 atom:category and those child elements are not present in the source 1058 atom:entry. 1060 atomSource = 1061 element atom:source { 1062 atomCommonAttributes, 1063 (atomAuthor? 1064 & atomCategory* 1065 & atomContributor* 1066 & atomCopyright? 1067 & atomGenerator? 1068 & atomIcon? 1069 & atomId? 1070 & atomImage? 1071 & atomLink+ 1072 & atomSubtitle? 1073 & atomTitle 1074 & atomUpdated 1075 & extensionElement*) 1076 } 1078 4.2.12 The "atom:subtitle" Element 1080 The "atom:subtitle" element is a Text construct that conveys a 1081 human-readable description or subtitle for a feed. 1083 atomSubtitle = element atom:subtitle { atomTextConstruct } 1085 4.2.13 The "atom:summary" Element 1087 The "atom:summary" element is a Text construct that conveys a short 1088 summary, abstract or excerpt of an entry. 1090 atomSummary = element atom:summary { atomTextConstruct } 1092 4.2.14 The "atom:title" Element 1094 The "atom:title" element is a Text construct that conveys a 1095 human-readable title for an entry or feed. 1097 atomTitle = element atom:title { atomTextConstruct } 1099 4.2.15 The "atom:updated" Element 1101 The "atom:updated" element is a Date construct indicating the most 1102 recent instant in time when an entry or feed was modified in a way 1103 the publisher considers significant. Therefore, not all 1104 modifications necessarily result in a changed atom:updated value. 1106 atomUpdated = element atom:updated { atomDateConstruct } 1107 Publishers MAY change the value of this element over time. 1109 5. Securing Atom Documents 1111 Because Atom is an XML-based format, existing XML security mechanisms 1112 can be used to secure its content. 1114 5.1 Digital Signatures 1116 The root of an Atom document (i.e., atom:feed in an Atom Feed 1117 Document, atom:entry in an Atom Entry Document) MAY have an Enveloped 1118 Signature, as described by XML-Signature and Syntax Processing 1119 [W3C.REC-xmldsig-core-20020212]. 1121 Processors MUST NOT reject an Atom Document containing such a 1122 signature because they are not capable of verifying it; they MUST 1123 continue processing and MAY inform the user of their failure to 1124 validate the signature. 1126 In other words, the presence of an element with the namespace URI 1127 "http://www.w3.org/2000/09/xmldsig#" and a local name of "Signature" 1128 as a child of the document element must not cause an Atom Processor 1129 to fail merely because of its presence. 1131 Other elements in an Atom Document MUST NOT be signed unless their 1132 definitions explicitly specify such a capability. 1134 5.2 Encryption 1136 The root of an Atom Document (i.e., atom:feed in an Atom Feed 1137 Document, atom:entry in an Atom Entry Document) MAY be encrypted, 1138 using the mechanisms described by XML Encryption Syntax and 1139 Processing [W3C.REC-xmlenc-core-20021210]. 1141 6. Extending Atom 1143 6.1 Extensions From Non-Atom Vocabularies 1145 This specification describes Atom's XML markup vocabulary. Markup 1146 from other vocabularies ("foreign markup") can be used in an Atom 1147 document. Note that the atom:content element is designed to support 1148 the inclusion of arbitrary foreign markup. 1150 6.2 Extensions To the Atom Vocabulary 1152 Future versions of this specification may add new elements and 1153 attributes to the Atom markup vocabulary. Software written to 1154 conform to this version of the specification will not be able to 1155 process such markup correctly and, in fact, will not be able to 1156 distinguish it from markup error. For the purposes of this 1157 discussion, unrecognized markup from the Atom vocabulary will be 1158 considered "foreign markup". 1160 6.3 Software Processing of Foreign Markup 1162 Software processing an Atom Document which encounters foreign markup 1163 in a location that is legal according to this specification MUST NOT 1164 stop processing or signal an error. It may be the case that the 1165 software is able to process the foreign markup correctly and does so. 1166 Otherwise, such markup is termed "unknown foreign markup". 1168 When unknown foreign markup is encountered as a child of atom:entry, 1169 atom:feed, or a Person construct, software MAY bypass the markup and 1170 any textual content and MUST NOT change its behavior as a result of 1171 the markup's presence. 1173 When unknown foreign markup is encountered in a Text Contruct or 1174 atom:content element, software SHOULD ignore the markup and process 1175 any text content of foreign elements as though the surrounding markup 1176 were not present. 1178 6.4 Extension Elements 1180 Atom allows foreign markup anywhere in an Atom document. Child 1181 elements of atom:entry, atom:feed, and Person constructs are 1182 considered Metadata Elements, and are described below. Child 1183 elements of Person constructs are considered to apply to the 1184 construct. The role of other foreign markup is undefined by this 1185 specification. 1187 6.4.1 Simple Extension Elements 1189 A Simple Extension element MUST NOT have any attributes or child 1190 elements. The element MAY contain character data, or be empty. 1191 Simple Extension elements are not language-sensitive. 1193 The element can be interpreted as a simple property (or name/value 1194 pair) of the parent element that encloses it. The pair consisting of 1195 the namespace-URI of the element and the local name of the element 1196 can be interpreted as the name of the property. The character data 1197 content of the element can be interpreted as the value of the 1198 property. If the element is empty, then the property value can be 1199 interpreted as an empty string. 1201 6.4.2 Structured Extension Elements 1203 The root element of a Structured Extension element MUST have at least 1204 one attribute or child element. It MAY have attributes, it MAY 1205 contain well-formed XML content (including character data), or it MAY 1206 be empty. Structured Extension elements are language-sensitive. 1208 The structure of a Structured Extension element, including the order 1209 of its child elements, could be significant. 1211 This specification does not provide an interpretation of a Structured 1212 Extension element. The syntax of the XML contained in the element, 1213 and an interpretation of how the element relates to its containing 1214 element is defined by the specification of the Atom extension. 1216 7. IANA Considerations 1218 An Atom Document, when serialized as XML 1.0, can be identified with 1219 the following media type: 1221 MIME media type name: application 1222 MIME subtype name: atom+xml 1223 Mandatory parameters: None. 1224 Optional parameters: 1225 "charset": This parameter has identical semantics to the charset 1226 parameter of the "application/xml" media type as specified in 1227 [RFC3023]. 1228 Encoding considerations: Identical to those of "application/xml" as 1229 described in [RFC3023], section 3.2. 1230 Security considerations: As defined in this specification. 1231 [[anchor59: update upon publication]] 1232 In addition, as this media type uses the "+xml" convention, it 1233 shares the same security considerations as described in [RFC3023], 1234 section 10. 1235 Interoperability considerations: There are no known interoperability 1236 issues. 1237 Published specification: This specification. [[anchor60: update upon 1238 publication]] 1239 Applications that use this media type: No known applications 1240 currently use this media type. 1242 Additional information: 1244 Magic number(s): As specified for "application/xml" in [RFC3023], 1245 section 3.2. 1246 File extension: .atom 1247 Fragment identifiers: As specified for "application/xml" in 1248 [RFC3023], section 5. 1249 Base URI: As specified in [RFC3023], section 6. 1250 Macintosh File Type code: TEXT 1251 Person and email address to contact for further information: Mark 1252 Nottingham 1253 Intended usage: COMMON 1254 Author/Change controller: This specification's author(s). 1255 [[anchor61: update upon publication]] 1257 7.1 Registry of Link Relations 1259 This registry is maintained by IANA and initially contains five 1260 values: "alternate", "related", "self", "enclosure", and "via". New 1261 assignments are subject to IESG Approval, as outlined in [RFC2434]. 1262 Requests should be made by email to IANA, which will then forward the 1263 request to the IESG requesting approval. The request should contain 1264 discussion of at least the following five topics: 1266 o A value for the "rel" attribute that conforms to the syntax rule 1267 given in Section 4.2.9.2 1268 o Common name for link type. 1269 o Description of link type semantics. 1270 o Expected display characteristics. 1271 o Security considerations. 1273 8. Security Considerations 1275 8.1 HTML and XHTML Content 1277 Text constructs and atom:content allow the delivery of HTML and XHTML 1278 to receiving software, which may process it. Many elements in these 1279 languages are considered 'unsafe' in that they open clients to one or 1280 more types of attack. Implementers of software which processes Atom 1281 should carefully consider their handling of every type of element 1282 when processing incoming (X)HTML in Atom documents. See the security 1283 sections of [RFC2854] and [W3C.REC-html401-19991224] for guidance. 1285 Atom Processors should pay particular attention to the security of 1286 the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and 1287 LINK elements, but other elements may also have negative security 1288 properties. 1290 (X)HTML can either directly contain or indirectly reference 1291 executable content. 1293 8.2 URIs 1295 Atom Processors handle URIs. See Section 7 of [RFC3986]. 1297 8.3 IRIs 1299 Atom Processors handle IRIs. See Section 8 of [RFC3987]. 1301 8.4 Encryption and Signing 1303 Atom documents can be encrypted and signed using 1304 [W3C.REC-xmlenc-core-20021210] and [W3C.REC-xmldsig-core-20020212], 1305 respectively, and are subject to the security considerations implied 1306 by their use. 1308 9. References 1310 9.1 Normative References 1312 [Atom-autodiscovery] 1313 Pilgrim, M., "Atom Feed Autodiscovery", work-in-progress, 1314 August 2004. 1316 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1317 Extensions (MIME) Part One: Format of Internet Message 1318 Bodies", RFC 2045, November 1996. 1320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1321 Requirement Levels", BCP 14, RFC 2119, March 1997. 1323 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1324 Specifications: ABNF", RFC 2234, November 1997. 1326 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 1327 2001. 1329 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 1330 Type", RFC 2854, June 2000. 1332 [RFC3023] Murata, M., St. Laurent, S. and D. Kohn, "XML Media 1333 Types", RFC 3023, January 2001. 1335 [RFC3066] Alvestrand, H., "Tags for the Identification of 1336 Languages", BCP 47, RFC 3066, January 2001. 1338 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1339 Timestamps", RFC 3339, July 2002. 1341 [RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data 1342 Encodings", RFC 3548, July 2003. 1344 [RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1345 Resource Identifier (URI): Generic Syntax", STD 66, 1346 RFC 3986, January 2005. 1348 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 1349 Identifiers (IRIs)", RFC 3987, January 2005. 1351 [W3C.REC-html401-19991224] 1352 Raggett, D., Hors, A. and I. Jacobs, "HTML 4.01 1353 Specification", W3C REC REC-html401-19991224, December 1354 1999. 1356 [W3C.REC-xhtml-basic-20001219] 1357 Baker, M., Ishikawa, M., Matsui, S., Stark, P., Wugofski, 1358 T. and T. Yamakami, "XHTML Basic", W3C 1359 REC REC-xhtml-basic-20001219, December 2000. 1361 [W3C.REC-xml-20040204] 1362 Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T. and 1363 E. Maler, "Extensible Markup Language (XML) 1.0 (Third 1364 Edition)", W3C REC REC-xml-20040204, February 2004. 1366 [W3C.REC-xml-infoset-20040204] 1367 Cowan, J. and R. Tobin, "XML Information Set (Second 1368 Edition)", W3C REC REC-xml-infoset-20040204, February 1369 2004. 1371 [W3C.REC-xml-names-19990114] 1372 Hollander, D., Bray, T. and A. Layman, "Namespaces in 1373 XML", W3C REC REC-xml-names-19990114, January 1999. 1375 [W3C.REC-xmlbase-20010627] 1376 Marsh, J., "XML Base", W3C REC REC-xmlbase-20010627, June 1377 2001. 1379 [W3C.REC-xmldsig-core-20020212] 1380 Solo, D., Reagle, J. and D. Eastlake, "XML-Signature 1381 Syntax and Processing", W3C REC REC-xmldsig-core-20020212, 1382 February 2002. 1384 [W3C.REC-xmlenc-core-20021210] 1385 Reagle, J. and D. Eastlake, "XML Encryption Syntax and 1386 Processing", W3C REC REC-xmlenc-core-20021210, December 1387 2002. 1389 9.2 Informative References 1391 [ISO.8601.1988] 1392 International Organization for Standardization, "Data 1393 elements and interchange formats - Information interchange 1394 - Representation of dates and times", ISO Standard 8601, 1395 June 1988. 1397 [RELAX-NG] 1398 OASIS Technical Committee: RELAX NG, "RELAX NG 1399 Specification", December 2001. 1401 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1402 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1403 October 1998. 1405 [W3C.NOTE-datetime-19980827] 1406 Wolf, M. and C. Wicksteed, "Date and Time Formats", W3C 1407 NOTE NOTE-datetime-19980827, August 1998. 1409 [W3C.REC-xmlschema-2-20041028] 1410 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 1411 Second Edition", W3C REC REC-xmlschema-2-20041028, October 1412 2004. 1414 Authors' Addresses 1416 Mark Nottingham (editor) 1418 Email: mnot@pobox.com 1419 URI: http://www.mnot.net/ 1421 Robert Sayre (editor) 1423 Email: rfsayre@boswijck.com 1424 URI: http://boswijck.com 1426 Appendix A. Contributors 1428 The following people contributed to preliminary drafts of this 1429 document: Tim Bray, Mark Pilgrim, and Sam Ruby. Norman Walsh 1430 provided the Relax NG schema. The content and concepts within are a 1431 product of the Atom community and the Atom Publishing Format and 1432 Protocol Working Group. 1434 Appendix B. Collected RELAX NG Compact Schema 1436 This appendix is informative. 1438 # -*- rnc -*- 1439 # RELAX NG Compact Syntax Grammar for the 1440 # Atom Format Specification Version 07 1442 namespace atom = 1443 "http://purl.org/atom/ns#draft-ietf-atompub-format-07" 1444 namespace xhtml = "http://www.w3.org/1999/xhtml" 1445 namespace s = "http://www.ascc.net/xml/schematron" 1447 start = atomFeed | atomEntry 1449 # Common attributes 1451 atomCommonAttributes = 1452 attribute xml:base { atomUri }?, 1453 attribute xml:lang { atomLanguageTag }? 1455 # Text Constructs 1457 atomPlainTextConstruct = 1458 atomCommonAttributes, 1459 attribute type { "text" | "html" }?, 1460 text 1462 atomXHTMLTextConstruct = 1463 atomCommonAttributes, 1464 attribute type { "xhtml" }, 1465 xhtmlDiv 1467 atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct 1469 # Person Construct 1471 atomPersonConstruct = 1472 atomCommonAttributes, 1473 (element atom:name { text } 1474 & element atom:uri { atomUri }? 1475 & element atom:email { atomEmailAddress }? 1476 & extensionElement*) 1478 # Date Construct 1480 atomDateConstruct = 1481 atomCommonAttributes, 1482 xsd:dateTime 1484 # atom:feed 1486 atomFeed = 1487 [ 1488 s:rule [ 1489 context = "atom:feed" 1490 s:assert [ 1491 test = "atom:link[@rel='alternate']" 1492 "An atom:feed must have at least one link element " 1493 ~ "with a rel attribute of 'alternate'." 1494 ] 1495 ] 1496 s:rule [ 1497 context = "atom:feed" 1498 s:assert [ 1499 test = "atom:author or not(atom:entry[not(atom:author)])" 1500 "An atom:feed must have an atom:author unless all " 1501 ~ "of its atom:entry children have an atom:author." 1502 ] 1503 ] 1504 ] 1505 element atom:feed { 1506 atomCommonAttributes, 1507 (atomAuthor? 1508 & atomCategory* 1509 & atomContributor* 1510 & atomCopyright? 1511 & atomGenerator? 1512 & atomIcon? 1513 & atomId? 1514 & atomImage? 1515 & atomLink+ 1516 & atomSubtitle? 1517 & atomTitle 1518 & atomUpdated 1519 & extensionElement*), 1520 atomEntry* 1521 } 1523 # atom:entry 1525 atomEntry = 1526 [ 1527 s:rule [ 1528 context = "atom:entry" 1529 s:assert [ 1530 test = "atom:link[@rel='alternate'] or atom:content" 1531 "An atom:entry must have at least one link element " 1532 ~ "with a rel attribute of 'alternate' or content." 1533 ] 1534 ] 1535 s:rule [ 1536 context = "atom:entry" 1537 s:assert [ 1538 test = "atom:author or " 1539 ~ "../atom:author or atom:source/atom:author" 1540 "An atom:entry must have an atom:author " 1541 ~ "if its feed does not." 1542 ] 1543 ] 1545 # N.B. This rule doesn't test 1546 # for content with a non-binary type. 1547 s:rule [ 1548 context = "atom:entry" 1549 s:assert [ 1550 test = "atom:summary or atom:content[not(@src)]" 1551 "An atom:entry must have an atom:summary " 1552 ~ "if the atom:content element is empty." 1553 ] 1554 ] 1555 ] 1556 element atom:entry { 1557 atomCommonAttributes, 1558 (atomAuthor? 1559 & atomCategory* 1560 & atomContent? 1561 & atomContributor* 1562 & atomCopyright? 1563 & atomId 1564 & atomLink* 1565 & atomPublished? 1566 & atomSource? 1567 & atomSummary? 1568 & atomTitle 1569 & atomUpdated 1570 & extensionElement*) 1571 } 1573 # atom:content 1575 atomInlineTextContent = 1576 element atom:content { 1577 atomCommonAttributes, 1578 attribute type { "text" | "html" }?, 1579 (text)* 1580 } 1582 atomInlineXHTMLContent = 1583 element atom:content { 1584 atomCommonAttributes, 1585 attribute type { "xhtml" }, 1586 xhtmlDiv 1587 } 1589 atomInlineOtherContent = 1590 element atom:content { 1591 atomCommonAttributes, 1592 attribute type { atomMediaType }?, 1593 (text|anyElement)* 1594 } 1596 atomOutOfLineContent = 1597 element atom:content { 1598 atomCommonAttributes, 1599 attribute type { atomMediaType }?, 1600 attribute src { atomUri }, 1601 empty 1602 } 1604 atomContent = atomInlineTextContent 1605 | atomInlineXHTMLContent 1606 | atomInlineOtherContent 1607 | atomOutOfLineContent 1609 # atom:author 1611 atomAuthor = element atom:author { atomPersonConstruct } 1613 # atom:category 1615 atomCategory = 1616 element atom:category { 1617 atomCommonAttributes, 1618 attribute term { text }, 1619 attribute scheme { atomUri }?, 1620 attribute label { text }?, 1621 empty 1622 } 1624 # atom:contributor 1625 atomContributor = element atom:contributor { atomPersonConstruct } 1627 # atom:copyright 1629 atomCopyright = element atom:copyright { atomTextConstruct } 1631 # atom:generator 1633 atomGenerator = element atom:generator { 1634 atomCommonAttributes, 1635 attribute uri { atomUri }?, 1636 attribute version { text }?, 1637 text 1638 } 1640 # atom:icon 1642 atomIcon = element atom:icon { 1643 atomCommonAttributes, 1644 (atomUri) 1645 } 1647 # atom:id 1649 atomId = element atom:id { 1650 atomCommonAttributes, 1651 (atomUri) 1652 } 1654 # atom:image 1656 atomImage = element atom:image { 1657 atomCommonAttributes, 1658 (atomUri) 1659 } 1661 # atom:link 1663 atomLink = 1664 element atom:link { 1665 atomCommonAttributes, 1666 attribute href { atomUri }, 1667 attribute rel { atomNCName | atomUri }?, 1668 attribute type { atomMediaType }?, 1669 attribute hreflang { atomLanguageTag }?, 1670 attribute title { text }?, 1671 attribute length { text }?, 1672 empty 1674 } 1676 # atom:published 1678 atomPublished = element atom:published { atomDateConstruct } 1680 # atom:source 1682 atomSource = 1683 element atom:source { 1684 atomCommonAttributes, 1685 (atomAuthor? 1686 & atomCategory* 1687 & atomContributor* 1688 & atomCopyright? 1689 & atomGenerator? 1690 & atomIcon? 1691 & atomId? 1692 & atomImage? 1693 & atomLink+ 1694 & atomSubtitle? 1695 & atomTitle 1696 & atomUpdated 1697 & extensionElement*) 1698 } 1700 # atom:subtitle 1702 atomSubtitle = element atom:subtitle { atomTextConstruct } 1704 # atom:summary 1706 atomSummary = element atom:summary { atomTextConstruct } 1708 # atom:title 1710 atomTitle = element atom:title { atomTextConstruct } 1712 # atom:updated 1714 atomUpdated = element atom:updated { atomDateConstruct } 1716 # Low-level simple types 1718 atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" } 1720 # Whatever a media type is, it contains at least one slash 1721 atomMediaType = xsd:string { pattern = ".+/.+" } 1722 # As defined in RFC 3066 1723 atomLanguageTag = xsd:string { 1724 pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*" 1725 } 1727 # Unconstrained; it's not entirely clear how IRI fit into 1728 # xsd:anyURI so let's not try to constrain it here 1729 atomUri = text 1731 # Whatever an email address is, it contains at least one @ 1732 atomEmailAddress = xsd:string { pattern = ".+@.+" } 1734 # Extensibility 1736 simpleExtensionElement = 1737 element * - atom:* { 1738 text 1739 } 1741 structuredExtensionElement = 1742 element * - atom:* { 1743 (attribute * { text }+, 1744 (text|anyElement)*) 1745 | (attribute * { text }*, 1746 (text?, anyElement+, (text|anyElement)*)) 1747 } 1749 extensionElement = 1750 simpleExtensionElement | structuredExtensionElement 1752 anyElement = 1753 element * - atom:* { 1754 (attribute * { text } 1755 | text 1756 | anyElement)* 1757 } 1759 # XHTML 1761 anyXHTML = element xhtml:* { 1762 (attribute * { text } 1763 | text 1764 | anyXHTML)* 1765 } 1767 xhtmlDiv = element xhtml:div { 1768 (attribute * { text } 1769 | text 1770 | anyXHTML)* 1771 } 1773 # EOF 1775 Appendix C. Change Log 1777 [[anchor72: This section should be removed before final 1778 publication.]] 1780 -07: Change atom:source-feed to atom:source. 1781 Add ABNF reference 1782 Many editorial tweaks 1783 Rework extensibility 1784 Adjust page breaks in txt version 1785 -06: Move Identity Construct into atom:id (only place it's used) 1786 atom:id values must be unique within a feed. 1787 restore atom:copyright definition mistakenly dropped during 1788 alphabetizing. 1789 Remove atom:head, add atom:source-feed, and "Extension Construct" 1790 text in an effort to accurately reflect WG consensus on data model 1791 and extensibility, acknowledging two opinions in favor of 1792 atom:head. 1793 Note @hreflang issue. 1794 Add comment on atom:entry/atom:summary requirements. 1795 Rework atom:id text. The dereferencing section didn't talk about 1796 dereferencing. 1797 Remove protocol reference. 1798 Alphabetize where appropriate (PaceOrderSpecAlphabetically). 1799 Add mI language (PaceExtendingAtom). 1800 Add atom:icon and atom:image (PaceImageAndIcon). 1801 Change atom:tagline to atom:subtitle 1802 Add inline XHTML language (PaceXHTMLNamespaceDiv). 1803 Change "TEXT" etc, to lowercase 1804 Change example id IRI to urn:uuid:... 1805 Add rel="self" (PaceFeedLink). 1806 Add Feed State text (PaceNoFeedState). 1807 Move to IRIs (PaceIRI). 1808 Add rel="via" (PaceLinkRelVia). 1809 Add rel="enclosure" (PaceEnclosuresAndPix). 1810 Remove info and host (PaceRemoveInfoAndHost) 1811 Clarify order of entries (PaceEntryOrder). 1812 Remove version attribute (PaceRemoveVersionAttr). 1813 Date format roundup (PaceDatesXSD). 1814 Remove Service construct and elements. 1815 fix atom:contributor cardinality typo 1816 Removed motivation/design principles note; if we haven't come up 1817 with them by now... 1818 Put conformance text into notational conventions. 1819 Removed instances of 'software'; too specific. 1821 Added refs to HTML and XHTML. 1822 Updated ref to Infoset. 1823 Various editorial tweaks. 1824 Fix RFC 3023 refs in IANA section 1825 Adjust head/link requirement 1826 fix @version typos 1827 -05: Add RNC from N. Walsh. 1828 Re-organize element definitions. 1829 Lift the prohibition on other types of DSig and encryption. 1830 Remove text on "indiscriminate use" of DSig and XMLEnc. 1831 -04: Update URI terms for 2396bis. 1832 Add Category construct (PaceCategoryRevised). 1833 Insert paranoid XHTML interpretation guidelines. 1834 Adjust atom:copyright, per chairs' instruction. 1835 Add atom:host as child element of atom:entry, per chairs' 1836 direction (PacePersonConstruct). 1837 Add link/content co-constraint (PaceContentOrLink). 1838 Remove atom:origin as a side effect of adding atom:head to 1839 atom:entry (PaceHeadInEntry). 1840 Add optional length attribute to atom:link (PaceLinkRelated). 1841 Add Link registry to Link Construct, IANA Considerations 1842 placeholder (PaceFieldingLinks). 1843 Change definition of atom:updated (PaceUpdatedDefinition). 1844 -03: Move definition of Link @rel to format spec, restrict 1845 acceptable values (PaceMoveLinkElement, PaceLinkAttrDefaults). 1846 Add Service Construct, head/post, head/introspection, entry/edit 1847 (PaceServiceElement). 1848 Add Text Construct, entry/content (PaceReformedContent3). 1849 Add entry/published (PaceDatePublished). 1850 Adjust definition of Identity Construct per chairs' direction to 1851 "fix it." 1852 Add Sayre to editors. 1853 -02: Removed entry/modified, entry/issued, entry/created; added 1854 entry/updated (PaceDateUpdated). 1855 Changed date construct from W3C date-time to RFC3339 1856 (PaceDateUpdated). 1857 Feed links to HTML pages should be reflected back 1858 (PaceLinkReflection). 1859 Added Identity construct (PaceIdConstruct). 1860 Changed feed/id and entry/id to be Identity constructs 1861 (PaceIdConstruct). 1862 Changed entry/origin's content so that it's the same as the feed's 1863 id, rather than its link/@rel="alternate" (PaceIdConstruct). 1864 Added "Securing Atom Documents" (PaceDigitalSignatures). 1865 -01: Constrained omission of "Information Item" to just elements and 1866 attributes. 1868 Clarified xml:lang inheritence. 1869 Removed entry- and feed-specific langauge about xml:lang (covered 1870 by general discussion of xml:lang) 1871 Changed xml:lang to reference XML for normative requirements. 1872 Changed "... MUST be a string" to "... is unstructued text." 1873 Remomved langauge about DOCTYPEs, PIs, Comments, Entities. 1874 Changed atom:url to atom:uri, @url to @uri 1875 Introduced atom:head 1876 Introduced "Atom Feed Document" and "Atom Entry Document". 1877 Removed requirement for all elements and attributes to be 1878 namespace-qualified; now children of selective elements 1879 Added extensibility to Person constructs. 1880 Removed requirement for media types to be registered 1881 (non-registered media types are legal) 1882 Added atom:origin (PaceEntryOrigin) 1883 Added requirement for entry/id to be present and a URI 1884 (PaceEntryIdRequired). 1885 Clarified approach to Comments, PIs and well-formedness, as per 1886 RFC3470. 1887 Referenced escaping algorithm in XML. 1888 Assorted editorial nits and cleanup, refactoring 1889 -00: Initial IETF Internet-Draft submission. 1890 Added optional version attribute to entry 1891 (PaceEntryElementNeedsVersionAttribute). 1892 Added hreflang attribute (PaceHrefLang). 1893 Clarified inheritence of copyright element (PaceItemCopyright). 1894 Added xml:lang to entries (PaceItemLang). 1895 Tweaked Infoset-related language (PaceNoInfoSet). 1896 Clarified lack of structure in version attribute 1897 (PaceVersionAsText). 1898 Changed approach to XML Base (PaceXmlBaseEverywhere). 1899 Added XML Base processing to atom:id (PaceXmlBaseId). 1900 Various editorial cleanup and adjustments for IETF publication. 1902 Intellectual Property Statement 1904 The IETF takes no position regarding the validity or scope of any 1905 Intellectual Property Rights or other rights that might be claimed to 1906 pertain to the implementation or use of the technology described in 1907 this document or the extent to which any license under such rights 1908 might or might not be available; nor does it represent that it has 1909 made any independent effort to identify any such rights. Information 1910 on the procedures with respect to rights in RFC documents can be 1911 found in BCP 78 and BCP 79. 1913 Copies of IPR disclosures made to the IETF Secretariat and any 1914 assurances of licenses to be made available, or the result of an 1915 attempt made to obtain a general license or permission for the use of 1916 such proprietary rights by implementers or users of this 1917 specification can be obtained from the IETF on-line IPR repository at 1918 http://www.ietf.org/ipr. 1920 The IETF invites any interested party to bring to its attention any 1921 copyrights, patents or patent applications, or other proprietary 1922 rights that may cover technology that may be required to implement 1923 this standard. Please address the information to the IETF at 1924 ietf-ipr@ietf.org. 1926 Disclaimer of Validity 1928 This document and the information contained herein are provided on an 1929 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1930 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1931 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1932 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1933 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1934 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1936 Copyright Statement 1938 Copyright (C) The Internet Society (2005). This document is subject 1939 to the rights, licenses and restrictions contained in BCP 78, and 1940 except as set forth therein, the authors retain all their rights. 1942 Acknowledgment 1944 Funding for the RFC Editor function is currently provided by the 1945 Internet Society.