idnits 2.17.1 draft-nottingham-rss2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (April 9, 2003) is 7688 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. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 822 (ref. '4') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2396 (ref. '6') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3023 (ref. '7') (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 3066 (ref. '8') (Obsoleted by RFC 4646, RFC 4647) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft April 9, 2003 4 Expires: October 8, 2003 6 RSS 2.0 7 draft-nottingham-rss2-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 except that the right to 13 produce derivative works is not granted. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 8, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This specification documents version 2.0 of RSS, an XML-based format 39 for syndicating Web content and metadata. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 44 1.1 Document terminology and conventions . . . . . . . . . . 3 45 2. Document Structure . . . . . . . . . . . . . . . . . . . 3 46 3. The rss Element . . . . . . . . . . . . . . . . . . . . 3 47 4. The channel Element . . . . . . . . . . . . . . . . . . 3 48 4.1 Required Children . . . . . . . . . . . . . . . . . . . 3 49 4.1.1 title Element . . . . . . . . . . . . . . . . . . . . . 4 50 4.1.2 link Element . . . . . . . . . . . . . . . . . . . . . . 4 51 4.1.3 description Element . . . . . . . . . . . . . . . . . . 4 52 4.2 Optional Children . . . . . . . . . . . . . . . . . . . 4 53 4.2.1 language Element . . . . . . . . . . . . . . . . . . . . 4 54 4.2.2 copyright Element . . . . . . . . . . . . . . . . . . . 4 55 4.2.3 managingEditor Element . . . . . . . . . . . . . . . . . 4 56 4.2.4 webMaster Element . . . . . . . . . . . . . . . . . . . 4 57 4.2.5 pubDate Element . . . . . . . . . . . . . . . . . . . . 4 58 4.2.6 lastBuildDate Element . . . . . . . . . . . . . . . . . 5 59 4.2.7 category Element . . . . . . . . . . . . . . . . . . . . 5 60 4.2.8 generator Element . . . . . . . . . . . . . . . . . . . 5 61 4.2.9 docs Element . . . . . . . . . . . . . . . . . . . . . . 5 62 4.2.10 cloud Element . . . . . . . . . . . . . . . . . . . . . 5 63 4.2.11 ttl Element . . . . . . . . . . . . . . . . . . . . . . 5 64 4.2.12 image Element . . . . . . . . . . . . . . . . . . . . . 5 65 4.2.13 rating Element . . . . . . . . . . . . . . . . . . . . . 6 66 4.2.14 textInput Element . . . . . . . . . . . . . . . . . . . 6 67 4.2.15 skipHours Element . . . . . . . . . . . . . . . . . . . 7 68 4.2.16 skipDays Element . . . . . . . . . . . . . . . . . . . . 7 69 4.3 The item Element . . . . . . . . . . . . . . . . . . . . 7 70 4.3.1 Optional Children . . . . . . . . . . . . . . . . . . . 7 71 4.3.1.1 title Element . . . . . . . . . . . . . . . . . . . . . 7 72 4.3.1.2 link Element . . . . . . . . . . . . . . . . . . . . . . 7 73 4.3.1.3 description Element . . . . . . . . . . . . . . . . . . 8 74 4.3.1.4 author Element . . . . . . . . . . . . . . . . . . . . . 8 75 4.3.1.5 category Element . . . . . . . . . . . . . . . . . . . . 8 76 4.3.1.6 comments Element . . . . . . . . . . . . . . . . . . . . 8 77 4.3.1.7 enclosure Element . . . . . . . . . . . . . . . . . . . 8 78 4.3.1.8 guid Element . . . . . . . . . . . . . . . . . . . . . . 8 79 4.3.1.9 pubDate Element . . . . . . . . . . . . . . . . . . . . 9 80 4.3.1.10 source Element . . . . . . . . . . . . . . . . . . . . . 9 81 5. Date Formatting . . . . . . . . . . . . . . . . . . . . 9 82 6. Extending RSS . . . . . . . . . . . . . . . . . . . . . 9 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . 10 84 8. Security Considerations . . . . . . . . . . . . . . . . 10 85 References . . . . . . . . . . . . . . . . . . . . . . . 11 86 Author's Address . . . . . . . . . . . . . . . . . . . . 11 87 A. UserLand Copyright Statement . . . . . . . . . . . . . . 11 88 Intellectual Property and Copyright Statements . . . . . 13 90 1. Introduction 92 This specification documents version 2.0 of RSS (Really Simple 93 Syndication), an XML-based format for syndicating Web content and 94 metadata. 96 This specification provides stable documentation for the RSS 2.0 97 format [9] as described by Dave Winer of UserLand Software, to assist 98 in implementation. As such, RSS documents conformant with this 99 specification should be conformant with that specification, and vice 100 versa. 102 [[[NOTE: This Internet-Draft is being made available ONLY to allow 103 the community to ascertain whether the specification described herein 104 is true to the original RSS 2.0 specification. Comments should be 105 directed to the RSS2 Support mailing list 106 (RSS2-Support@yahoogroups.com).]]] 108 1.1 Document terminology and conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [5]. 114 2. Document Structure 116 RSS documents MUST be conformant to the XML 1.0 specification [1]. 117 There is explicitly no namespace URI [2] associated with the elements 118 described in this document. 120 3. The rss Element 122 The root (top-level) element of an RSS document MUST be the rss 123 element. It has one mandatory attribute, version, which indicates the 124 version of RSS which the document conforms to. Documents conformant 125 to this specification MUST have a version attribute of "2.0". 127 The rss element MUST contain a channel element. 129 4. The channel Element 131 The channel element contains metadata about the RSS channel, as well 132 as the items which comprise it. 134 4.1 Required Children 136 The following elements MUST be present as children of the channel 137 element; 139 4.1.1 title Element 141 The title element MUST contain a string, to be used as a name for the 142 channel. Its content SHOULD be the same as that of the human-readable 143 Web page it refers to. 145 4.1.2 link Element 147 The link element MUST contain a URL [6] which indicates a 148 (human-readable) Web page associated with the channel. 150 4.1.3 description Element 152 The description element MUST contain a string describing the channel. 154 4.2 Optional Children 156 The following elements MAY be present as children of the channel 157 element; 159 4.2.1 language Element 161 The langauage element, if present, MUST contain a language tag, as 162 defined in RFC3066 [8]. 164 4.2.2 copyright Element 166 The copyright element, if present, MUST contains a string, which 167 serves as copyright notice regarding the channel's content. 169 4.2.3 managingEditor Element 171 The managingEditor element, if present, MUST contain an e-mail 172 address, indicating the person or entity responsible for the content 173 (in an editorial sense). 175 4.2.4 webMaster Element 177 The webMaster element, if present, MUST contain an e-mail address, 178 indicating the person or entity responsible for the technical 179 administration of the channel. 181 4.2.5 pubDate Element 183 The pubDate element, if present, MUST contain an RFC822-formatted [4] 184 date (subject to the caveats below). It represents the publication 185 date for the channel. 187 For example, the New York Times publishes on a daily basis, the 188 publication date flips once every 24 hours. That's when the pubDate 189 of the channel changes. 191 4.2.6 lastBuildDate Element 193 The lastBuildDate element, if present, MUST contain an 194 RFC822-formatted [4] date (subject to the caveats below). It 195 represents the moment when the content of the channel last changed. 197 4.2.7 category Element 199 The category element, when present, MUST contain a string that 200 identifies a categorization for the channel. It SHOULD use forward 201 slash delimitation to indicate hierarchy. 203 The category element MAY have a domain attribute, which MUST be a 204 string that identifies a categorization taxonomy. 206 The category element MAY be repeated to associate multiple 207 categorizations with a channel. 209 4.2.8 generator Element 211 The generator element, if present, MUST contain a string, indicating 212 the program used to generate the document. 214 4.2.9 docs Element 216 The docs element, if present, MUST contain a URL that resolves to 217 documentation for the format of the RSS file, for future reference. 219 4.2.10 cloud Element 221 The cloud element, if present, allows processes to register to be 222 notified of updates to the channel, by using a lightweight 223 publish-subscribe protocol. 225 For more information, see the rssCloud [10] interface. 227 4.2.11 ttl Element 229 The ttl element, when present, MUST contain an integer number of 230 minutes that indicates how long a channel's representation can be 231 cached. 233 4.2.12 image Element 234 The image element, when present, allows an image such as an 235 illustration or photograph to be assocated with the channel. It MUST 236 have the following children: the url element, the title element, and 237 the link element. 239 The url element MUST contain a URL which can be used to locate the 240 image. It SHOULD be capable of returning an image with one of the 241 following media types; image/gif, image/jpeg, image/png. 243 The title element MUST be a string describing the image (this element 244 as the same semantic as the HTML alt attribute). 246 The link element MUST contain a URL which indicates the locatation of 247 the site associated with the image. 249 In practice, the title element and link element SHOULD be the same as 250 those associated with the channel itself. 252 Additionally, the image element MAY have the following children: the 253 width element and the height element. 255 Both the width element and the height element MUST contain integers 256 which indicate the width and height of the image in pixels, 257 respectively. 259 The value of the width element MUST NOT be greater than 144; if it is 260 not present, consumers MAY assume it to be 88. 262 The value of the height element MUST NOT be greater than 400; if it 263 is not present, consumers MAY assume it to be 31. 265 4.2.13 rating Element 267 The rating element, when present, MUST contain the PICS [3] rating 268 for the channel. 270 4.2.14 textInput Element 272 The textInput element describes a text input control that can be used 273 in conjunction with the channel. It MUST contain the following 274 children: the title element, the description element, the name 275 element and the link element. It is included in this specification 276 for backwards-compatibility. 278 The title element MUST contain a string that can be used as a label 279 for the text input submission widget. 281 The description element MUST contain a string that explains the text 282 input area. 284 The name element MUST contain a string that associates a name with 285 the input text. 287 The link element MUST contain a URL to which the text can be 288 submitted. 290 4.2.15 skipHours Element 292 The skipHours element, if present, MUST contain one to 24 hour 293 elements. 295 The hour element MUST contain an integer between 0 and 23. Its value 296 indicates an hour in which consumers SHOULD NOT attempt to fetch 297 representations of the channel; a value of 0 indicates midnight GMT. 299 4.2.16 skipDays Element 301 The skipDays element, if present, MUST contain one to seven day 302 elements. 304 The day element MUST contain one of the following strings; "Monday", 305 "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" or "Sunday". 306 Its value indicates a day on which consumers SHOULD NOT attempt to 307 fetch representation of the channel. 309 4.3 The item Element 311 In addition to the required and optional children described above, 312 the channel element MAY have any number of item elements following 313 them. 315 item elements embody the payload of the RSS channel. Although all 316 item child elements described here are optional, each item MUST have 317 either a title element or description element as a child. 319 4.3.1 Optional Children 321 4.3.1.1 title Element 323 The title element, if present, MUST contain a string, to be used as a 324 name for the item. 326 4.3.1.2 link Element 328 The link element, if present, MUST contain a URL which indicates a 329 (human-readable) Web page associated with the item. 331 4.3.1.3 description Element 333 The description element, if present, MUST contain a string describing 334 the item. 336 4.3.1.4 author Element 338 The author element, if present, MUST contain an e-mail addres, 339 indicating the author of the item. 341 For examples, publications syndicated via RSS might indicate the 342 person who wrote the article that the item describes. For 343 collaborative Weblogs, the author of the item might be different from 344 the managing editor or Webmaster. For a Weblog authored by a single 345 individual, it may be appropriate to omit the author element. 347 4.3.1.5 category Element 349 The category element, if present, MUST contain a string that 350 identifies a categorization for the item. It SHOULD use forward slash 351 delimitation to indicate hierarchy. 353 The category element MAY have a domain attribute, which MUST be a 354 string that identifies a categorization taxonomy. 356 The category element MAY be repeated to associate multiple 357 categorizations with an item. 359 4.3.1.6 comments Element 361 The comments element, if present, MUST be a URL, indicating a page 362 for comments relating to the item. 364 4.3.1.7 enclosure Element 366 The enclosure element, if present, describes a media object that is 367 logically attached to the item. It MUST have a url attribute, a 368 length attribute, and a type attribute. 370 The url attribute indicates the location of the enclosure; it MUST be 371 a http-schemed URL. 373 The length attribute indicates the size of the enclosure in bytes. 375 The type attribute indicates the media type of the enclosure. 377 4.3.1.8 guid Element 378 The guid element, if present, MUST contain a string that uniquely 379 identifies the item. Commonly, the guid element is used to determine 380 whether an item is new, and to disambiguate it from other items. 382 The guid element MAY have a isPermaLink attribute, whose value MUST 383 be either "true" or "false". The isPermaLink attribute indicates 384 whether the guid also serves as a long-lived URL for the item. If the 385 isPermaLink attribute is not present, the default value is "true". 387 If the value of the isPermaLink attribute is "true", the contents of 388 the guid element MUST contain a URL that points to a Web page 389 described by the item element. 391 If the value of the isPermaLink attribute is "false", consumers of 392 RSS documents MUST consider the guid string as opaque. 394 4.3.1.9 pubDate Element 396 The pubDate element, if present, MUST be an RFC822-formatted [4] date 397 (subject to the caveats below) that indicates when the item was 398 published. If pubDate indicates a future date, consumers MAY choose 399 to ignore the item until that date has passed. 401 4.3.1.10 source Element 403 The source element, if present, MUST contain a string that indicates 404 the RSS channel that the item came from. It SHOULD be derived from 405 the channel's title. 407 The source element MUST have a url attribute, which MUST be a URL 408 indicating an XML source of the channel. 410 This element is designed to enable the propogation of credit for 411 items, and SHOULD be generated automatically by tools where 412 appropriate. 414 5. Date Formatting 416 RFC822-formatted dates in this specification MAY use two or four 417 digits to indicate a year; it is RECOMMENDED that four digits are 418 used. 420 6. Extending RSS 422 Elements and attributes MAY be introduced in the RSS format to extend 423 its functionality. Such extensions MUST use XML Namespaces [2] to 424 distinguish themselves from RSS elements as well as other extensions. 426 7. IANA Considerations 428 To: ietf-types@iana.org 430 Subject: Registration of MIME media type application/rss+xml 432 MIME media type name: application 434 MIME subtype name: rss+xml 436 Required parameters: none 438 Optional parameters: 440 charset 442 Same as charset parameter of application/xml as specified in 443 RFC3023 [7]. 445 revision 447 The optional revision parameter indicates the integer version of 448 RSS used; the value is specified by the target RSS version. 450 namespace 452 The optional namespace parameter indicates the XML namespace [2] 453 URI of the RSS format, if available. 455 Encoding considerations: 457 Same as encoding considerations of application/xml as specified in 458 RFC3023 [7]. 460 8. Security Considerations 462 Like any Internet format, values in RSS documents should be examined 463 for invalid content, and careful care should be taken if it is to be 464 used as input to further processing (e.g., using a date value as the 465 basis of a calculation). 467 Furthermore, because HTML is a common payload of RSS files, careful 468 consideration should be given before excecuting content such as 469 ECMAScript or similar. 471 Additionally, the security considerations of RFC3023 [7] should be 472 taken into account when generating and processing RSS files. 474 References 476 [1] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 477 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC 478 REC-xml-20001006, October 2000. 480 [2] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C 481 REC REC-xml-names-19990114, January 1999. 483 [3] Krauskopf, T., Miller, J., Resnick, P. and W. Treese, "PICS 1.1 484 Label Distribution -- Label Syntax and Communication Protocols", 485 W3C REC REC-PICS-labels-961031, October 1996. 487 [4] Crocker, D., "Standard for the format of ARPA Internet text 488 messages", STD 11, RFC 822, August 1982. 490 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 491 Levels", BCP 14, RFC 2119, March 1997. 493 [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 494 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 496 [7] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 497 3023, January 2001. 499 [8] Alvestrand, H., "Tags for the Identification of Languages", BCP 500 47, RFC 3066, January 2001. 502 [9] 504 [10] 506 Author's Address 508 Mark Nottingham 510 EMail: mnot@pobox.com 511 URI: http://www.mnot.net/ 513 Appendix A. UserLand Copyright Statement 515 This work is derived from the RSS 2.0.1 specification, which requires 516 the following statement: 518 รจ Copyright 1997-2002 UserLand Software. All Rights Reserved. 520 This document and translations of it may be copied and furnished 521 to others, and derivative works that comment on or otherwise 522 explain it or assist in its implementation may be prepared, 523 copied, published and distributed, in whole or in part, without 524 restriction of any kind, provided that the above copyright notice 525 and these paragraphs are included on all such copies and 526 derivative works. 528 This document may not be modified in any way, such as by removing 529 the copyright notice or references to UserLand or other 530 organizations. Further, while these copyright restrictions apply 531 to the written RSS specification, no claim of ownership is made by 532 UserLand to the format it describes. Any party may, for commercial 533 or non-commercial purposes, implement this format without royalty 534 or license fee to UserLand. The limited permissions granted herein 535 are perpetual and will not be revoked by UserLand or its 536 successors or assigns. 538 This document and the information contained herein is provided on 539 an "AS IS" basis and USERLAND DISCLAIMS ALL WARRANTIES, EXPRESS OR 540 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 541 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 544 Intellectual Property Statement 546 The IETF takes no position regarding the validity or scope of any 547 intellectual property or other rights that might be claimed to 548 pertain to the implementation or use of the technology described in 549 this document or the extent to which any license under such rights 550 might or might not be available; neither does it represent that it 551 has made any effort to identify any such rights. Information on the 552 IETF's procedures with respect to rights in standards-track and 553 standards-related documentation can be found in BCP-11. Copies of 554 claims of rights made available for publication and any assurances of 555 licenses to be made available, or the result of an attempt made to 556 obtain a general license or permission for the use of such 557 proprietary rights by implementors or users of this specification can 558 be obtained from the IETF Secretariat. 560 The IETF invites any interested party to bring to its attention any 561 copyrights, patents or patent applications, or other proprietary 562 rights which may cover technology that may be required to practice 563 this standard. Please address the information to the IETF Executive 564 Director. 566 Full Copyright Statement 568 Copyright (C) The Internet Society (2003). All Rights Reserved. 570 This document and translations of it may be copied and furnished to 571 others, and derivative works that comment on or otherwise explain it 572 or assist in its implementation may be prepared, copied, published 573 and distributed, in whole or in part, without restriction of any 574 kind, provided that the above copyright notice and this paragraph are 575 included on all such copies and derivative works. However, this 576 document itself may not be modified in any way, such as by removing 577 the copyright notice or references to the Internet Society or other 578 Internet organizations, except as needed for the purpose of 579 developing Internet standards in which case the procedures for 580 copyrights defined in the Internet Standards process must be 581 followed, or as required to translate it into languages other than 582 English. 584 The limited permissions granted above are perpetual and will not be 585 revoked by the Internet Society or its successors or assignees. 587 This document and the information contained herein is provided on an 588 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 589 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 590 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 591 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 592 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 594 Acknowledgement 596 Funding for the RFC Editor function is currently provided by the 597 Internet Society.