idnits 2.17.1 draft-saintandre-atompub-notify-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 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 7, 2008) is 5834 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Atom API' is mentioned on line 168, but not defined ** Obsolete normative reference: RFC 3920 (ref. 'XMPP-CORE') (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft XMPP Standards Foundation 4 Intended status: Informational J. Hildebrand 5 Expires: November 8, 2008 Jabber, Inc. 6 B. Wyman 7 May 7, 2008 9 Atomsub: Transporting Atom Notifications over the Publish-Subscribe 10 Extension to the Extensible Messaging and Presence Protocol (XMPP) 11 draft-saintandre-atompub-notify-07 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 8, 2008. 38 Abstract 40 This memo describes a method for notifying interested parties about 41 changes in syndicated information encapsulated in the Atom feed 42 format, where such notifications are delivered via an extension to 43 the Extensible Messaging and Presence Protocol (XMPP) for publish- 44 subscribe functionality. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Process Flows . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Notification of Entry Creation . . . . . . . . . . . . . . 5 54 2.3. Notification of Entry Modification . . . . . . . . . . . . 9 55 2.4. Notification of Entry Deletion . . . . . . . . . . . . . . 12 56 3. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 13 57 3.1. Association Between User and Pubsub Node . . . . . . . . . 13 58 3.2. Generation of ItemIDs . . . . . . . . . . . . . . . . . . 13 59 3.3. Handling of Duplicate Entries . . . . . . . . . . . . . . 13 60 3.4. Notifications Matching Multiple Subscriptions . . . . . . 13 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 62 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 5.1. Normative References . . . . . . . . . . . . . . . . . . . 15 64 5.2. Informative References . . . . . . . . . . . . . . . . . . 15 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 66 Intellectual Property and Copyright Statements . . . . . . . . . . 17 68 1. Introduction 70 1.1. Overview 72 The Atom Publishing Format and Protocol Working Group has developed 73 two technologies relevant to content syndication: 75 1. An XML data format for syndication of information about 76 periodically-updated resources (such as weblog entries and news 77 stories) available on the World Wide Web (see [ATOM-FORMAT]). 78 2. A protocol for publishing, editing, deleting, and otherwise 79 managing such resources (see [ATOM-PROTOCOL]). 81 Content syndication follows a classic "observer" or "publish- 82 subscribe" software design pattern: a person or application publishes 83 information to a "channel", and an event notification (or the data 84 itself) is broadcasted to all those who are interested in knowing 85 when such information is published or modified. On the Internet 86 today, publication of periodically-updated resources is handled by 87 means of standard technologies such as [HTTP], and it is not 88 envisioned that this will change since [ATOM-PROTOCOL] specifies the 89 use of HTTP for publication. However, existing methods for learning 90 that a resource has been updated are currently limited to "polling" 91 for changes via HTTP, which is inherently inefficient. What is 92 needed is a technology that can be relied on to "push" information 93 only when a resource undergoes a state change, and only to those who 94 are interested in learning about such state changes. 96 One possible technology for doing so is email, since [SMTP] provides 97 a way to initiate the sending of information from "publishers" to 98 "subscribers" (think, for example, of email lists such as those used 99 to announce newly-published RFCs). While email is one possible 100 solution, it is not necessarily the best solution for Atom; in 101 particular, [ATOM-FORMAT] defines an XML data format for content 102 syndication, which implies that it might be beneficial to use a 103 native XML delivery mechanism rather than to attach a special XML 104 media type to email messages. Thankfully, a specialized XML delivery 105 protocol has been developed through the IETF: the Extensible 106 Messaging and Presence Protocol (XMPP) as specified in [XMPP-CORE]. 107 XMPP has the added benefit of being optimized for near-real-time data 108 delivery, which may be important in applications of Atom that require 109 subscribers to be notified about syndicated content in a highly 110 timely manner. 112 While the semantics of a normal XMPP element may be 113 suitable for Atom content notifications, there also exists an XMPP 114 extension that provides more structured communications in the context 115 of information "channels" or "nodes" of the kind that are used in 116 typical content syndication technologies, where an interested entity 117 can subscribe to that channel or node and thus receive notifications 118 related to the topic of interest. This extension is specified in 119 [XMPP-PUBSUB] and may be especially useful for delivering 120 notifications related to changes in Atom resources. Therefore, this 121 memo describes a method for notifying interested parties about 122 changes in syndicated information encapsulated in the Atom feed 123 format, where such notifications are delivered via the XMPP publish- 124 subscribe extension. 126 1.2. Terminology 128 This document inherits terminology from [ATOM-FORMAT], [XMPP-CORE], 129 and [XMPP-PUBSUB]. 131 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 132 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 133 RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 134 interpreted as described in RFC 2119 [TERMS]. 136 2. Process Flows 138 2.1. Overview 140 The following process flows demonstrate how Atom-formatted data 141 (specifically, feed entries) can be delivered using the XMPP pubsub 142 extension. The actors in these process flows are an application and 143 one or more XMPP users. The application acts as a translator between 144 HTTP and XMPP, since it generates XMPP pubsub requests when certain 145 events occur at an Atom-aware HTTP service (e.g., an HTTP POST to 146 create a new dynamic resource). The XMPP pubsub service then 147 translates those pubsub requests into notifications that are sent to 148 a potentially large number of XMPP users who have subscribed to such 149 events (e.g., who have asked to receive an XMPP notification whenever 150 a new dynamic resource is created for a certain Atom "channel"). Of 151 course, an XMPP user is not necessarily a human, and could represent 152 another application on the XMPP network (e.g., a chatroom, a bot, or 153 a content management system). 155 Note well that an HTTP user (e.g., a weblog author) would still 156 publish information using the methods defined in [ATOM-PROTOCOL]; the 157 process flows described herein enable the HTTP service with which an 158 HTTP user interacts to generate notifications that are delivered via 159 an XMPP pubsub service to a potentially large number of XMPP users 160 who want to receive such information. 162 We can visualize the architecture as follows: 164 +-----------+ 165 | HTTP User | 166 +-----------+ 167 | 168 | [Atom API] 169 | 170 +--------------+ 171 | HTTP Service | 172 +--------------+ 173 | 174 | [XMPP Pubsub] 175 | 176 +---------------------+ 177 | XMPP Pubsub Service | 178 +---------------------+ 179 | 180 | [XMPP Pubsub] 181 | 182 +--------+-------+ 183 | | 184 +-----------+ +-----------+ 185 | XMPP User | | XMPP User | 186 +-----------+ +-----------+ 188 In the examples shown below, we stipulate the following particulars: 190 o The XMPP address of the HTTP Service is "atompub.example.org". 191 o The XMPP address of the XMPP Pubsub Service is 192 "pubsub.example.com". 193 o The NodeID of the XMPP pubsub node to which the HTTP Service 194 publishes and to which the XMPP Users subscribe is "an-atom-node". 195 o The ItemID of the XMPP pubsub item published by the HTTP Service 196 is "70b2a83be71dfca04df91133d953fb22b41b4267". 197 o The XMPP addresses of the XMPP Users who are subscribed to the 198 node are "alice@example.net" and "bob@example.com". 200 2.2. Notification of Entry Creation 202 An implementation MUST support notifications related to creation of 203 an entry. 205 When a content author publishes a new dynamic resource, many entities 206 may be interested in learning that the resource is now available. 207 The process flow is as follows: 209 o Author publishes a new entry to the HTTP service via the Atom API. 211 o The HTTP service sends data for the new Atom entry in an XMPP 212 pubsub "publish" request to a specific node at the XMPP pubsub 213 service. (Note: If the entry may be copied from one feed to 214 another, e.g., in the generation of "synthetic" feeds, the entry 215 SHOULD contain an atom:source element to ensure consistent 216 metadata.) 217 o The XMPP pubsub service sends an XMPP message notification to each 218 XMPP entity that is subscribed to the pubsub node. 220 The result is that the XMPP subscribers will receive something close 221 to real-time notification whenever a new feed entry has been 222 published. 224 Obviously the first step is out of scope for this memo, since it is 225 described in [ATOM-PROTOCOL]. The XMPP protocols for the last two 226 steps are shown below. 228 First the HTTP service sends an XMPP pubsub "publish" request to the 229 XMPP pubsub service: 231 235 236 237 238 239 240 Example Feed 241 242 245 tag:example.org,2003:home 246 2003-12-13T18:30:02Z 247 248 John Doe 249 250 251 Atom-Powered Robots Run Amuck 252 Asimov's First Law horribly violated! 253 256 tag:example.org,2003:entry-32397 257 2003-12-13T18:30:02Z 258 2003-12-13T18:30:02Z 259 260 261 262 263 265 The XMPP pubsub service then sends a pubsub notification to each XMPP 266 subscriber; depending on pubsub node configuration, the notification 267 may or may not contain the Atom payload (we assume here that the 268 payload will be included). 270 272 273 274 275 276 277 Example Feed 278 279 282 tag:example.org,2003:home 283 2003-12-13T18:30:02Z 284 285 John Doe 286 287 288 Atom-Powered Robots Run Amuck 289 Asimov's First Law horribly violated! 290 293 tag:example.org,2003:entry-32397 294 2003-12-13T18:30:02Z 295 2003-12-13T18:30:02Z 296 297 298 299 300 302 304 305 306 307 308 309 Example Feed 310 311 314 tag:example.org,2003:home 315 2003-12-13T18:30:02Z 316 317 John Doe 318 319 320 Atom-Powered Robots Run Amuck 321 Asimov's First Law horribly violated! 322 325 tag:example.org,2003:entry-32397 326 2003-12-13T18:30:02Z 327 2003-12-13T18:30:02Z 328 329 330 331 332 334 2.3. Notification of Entry Modification 336 An implementation SHOULD support notifications related to 337 modification of an entry. 339 When a content author updates an existing dynamic resource, many 340 entities may be interested in learning that the resource has been 341 modified. The process flow is as follows: 343 o Author updates an existing entry at the HTTP service via the Atom 344 API. 345 o The HTTP service sends data for the updated Atom entry in an XMPP 346 pubsub "publish" request to a specific node at the XMPP pubsub 347 service, specifying the same Item ID as previously supplied. 348 (Note: If the entry may be copied from one feed to another, e.g., 349 in the generation of "synthetic" feeds, the entry SHOULD contain 350 an atom:source element to ensure consistent metadata.) 351 o The XMPP pubsub service sends an XMPP message notification to each 352 XMPP entity that is subscribed to the pubsub node. 354 First the HTTP service sends an XMPP pubsub "publish" request to the 355 XMPP pubsub service (note the modified title and time): 357 361 362 363 364 365 366 Example Feed 367 368 371 tag:example.org,2003:home 372 2003-12-13T18:30:02Z 373 374 John Doe 375 376 377 Atom-Powered Robots Run Amok 378 Asimov's First Law horribly violated! 379 382 tag:example.org,2003:entry-32397 383 2003-12-13T18:30:02Z 384 2003-12-13T18:31:03Z 385 386 387 388 389 391 Subject to node configuration and/or subscription options, each XMPP 392 subscriber would then receive a pubsub notification, which may or may 393 not contain the Atom payload. 395 397 398 399 400 401 402 Example Feed 403 404 407 tag:example.org,2003:home 408 2003-12-13T18:30:02Z 409 410 John Doe 411 412 413 Atom-Powered Robots Run Amok 414 Asimov's First Law horribly violated! 415 418 tag:example.org,2003:entry-32397 419 2003-12-13T18:30:02Z 420 2003-12-13T18:31:03Z 421 422 423 424 425 427 429 430 431 432 433 434 Example Feed 435 436 439 tag:example.org,2003:home 440 2003-12-13T18:30:02Z 441 442 John Doe 443 444 445 Atom-Powered Robots Run Amok 446 Asimov's First Law horribly violated! 447 450 tag:example.org,2003:entry-32397 451 2003-12-13T18:30:02Z 452 2003-12-13T18:31:03Z 454 455 456 457 458 460 2.4. Notification of Entry Deletion 462 An implementation MAY support notifications related to deletion of an 463 entry. 465 If a content author deletes an existing dynamic resource, many 466 entities may be interested in learning that the resource is no longer 467 available. The process flow is as follows: 469 o Author deletes an existing entry at the HTTP service via the Atom 470 API. 471 o The HTTP service sends an XMPP pubsub "retract" request to a 472 specific node at the XMPP pubsub service, specifying the same Item 473 ID as previously supplied. 474 o The XMPP pubsub service sends an XMPP message notification to each 475 XMPP entity that is subscribed to the pubsub node. 477 First the HTTP service sends an XMPP pubsub "retract" request to the 478 XMPP pubsub service: 480 484 485 486 487 488 489 491 Subject to node configuration and/or subscription options, each XMPP 492 subscriber would then receive a pubsub notification that the item was 493 deleted. 495 497 498 499 500 501 502 504 506 507 508 509 510 511 513 3. Implementation Notes 515 3.1. Association Between User and Pubsub Node 517 As explained in [XMPP-PUBSUB], a notification MAY include an XMPP 518 SHIM Stanza Headers and Internet Metadata [XMPP-SHIM] header named 519 "Reply-To" that specifies the JabberID of the publishing entity. 520 Alternatively, as described in [XMPP-PEP], the XMPP server of the 521 publishing entity MAY enable the publishing entity to associate a 522 virtual pubsub service with the JabberID of its account, obviating 523 the need for a separate pubsub service. 525 3.2. Generation of ItemIDs 527 The pubsub ItemIDs MUST conform to the rules defined in 528 [XMPP-PUBSUB]. One possible method for generating a unique ItemID is 529 to concatenate the XMPP address of the pubsub service, the pubsub 530 node to which the item is published, and the atom:id of the feed 531 entry, then hash the resulting string using the [SHA1] algorithm. 533 3.3. Handling of Duplicate Entries 535 It is the responsibility of the receiving application to remove or 536 ignore duplicate entries that might be received from multiple feeds. 538 3.4. Notifications Matching Multiple Subscriptions 540 An XMPP entity may subscribe to a publish-subscribe node multiple 541 times (e.g., once for each of several keywords), in which case a 542 single notification may match one or more subscriptions. In order to 543 specify which of one or more subscriptions are matched, the 544 notification message SHOULD specify the subscription IDs using the 545 header syntax defined in [XMPP-SHIM] and the "pubsub#subid" header 546 defined in [XMPP-PUBSUB], as shown at the end of the following 547 example. 549 551 552 553 554 555 556 Example Feed 557 558 561 tag:example.org,2003:home 562 2003-12-13T18:30:02Z 563 564 John Doe 565 566 567 Atom-Powered Robots Run Amok 568 Asimov's First Law horribly violated! 569 572 tag:example.org,2003:entry-32397 573 2003-12-13T18:30:02Z 574 2003-12-13T18:31:03Z 575 576 577 578 579 580
123-abc
581
004-yyy
582 583 585 4. Security Considerations 587 Detailed security considerations for the relevant protocols profiled 588 in this memo are given in [ATOM-FORMAT], [XMPP-CORE], and 590 [XMPP-PUBSUB]; this memo introduces no new security concerns above 591 and beyond those described in the foregoing specifications. 593 5. References 595 5.1. Normative References 597 [ATOM-FORMAT] 598 Nottingham, M. and R. Sayre, "The Atom Syndication 599 Format", RFC 4287, December 2005. 601 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 602 Requirement Levels", BCP 14, RFC 2119, March 1997. 604 [XMPP-CORE] 605 Saint-Andre, P., "Extensible Messaging and Presence 606 Protocol (XMPP): Core", RFC 3920, October 2004. 608 [XMPP-PUBSUB] 609 Millard, P., Saint-Andre, P., and R. Meijer, "Publish- 610 Subscribe", XSF XEP 0060, March 2008. 612 5.2. Informative References 614 [ATOM-PROTOCOL] 615 Gregorio, J. and B. de hOra, "The Atom Publishing 616 Protocol", RFC 5023, October 2007. 618 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 619 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 620 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 622 [SHA1] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 623 (SHA1)", RFC 3174, September 2001. 625 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 626 April 2001. 628 [XMPP-PEP] 629 Saint-Andre, P. and K. Smith, "Personal Eventing via 630 Pubsub", XSF XEP 0163, September 2007. 632 [XMPP-SHIM] 633 Saint-Andre, P. and J. Hildebrand, "Stanza Headers and 634 Internet Metadata (SHIM)", XSF XEP 0131, July 2006. 636 Authors' Addresses 638 Peter Saint-Andre 639 XMPP Standards Foundation 641 Email: stpeter@jabber.org 642 URI: https://stpeter.im/ 644 Joe Hildebrand 645 Jabber, Inc. 647 Email: jhildebrand@jabber.com 649 Bob Wyman 651 Email: bob@wyman.us 653 Full Copyright Statement 655 Copyright (C) The IETF Trust (2008). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 664 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 665 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 666 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org.