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