idnits 2.17.1 draft-ietf-sieve-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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 744. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (February 20, 2007) is 6272 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'COMPARATOR' is mentioned on line 497, but not defined == Missing Reference: 'MATCH-TYPE' is mentioned on line 497, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 3920 (ref. 'XMPP') (Obsoleted by RFC 6120) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Limited 4 Intended status: Standards Track B. Leiba, Ed. 5 Expires: August 24, 2007 W. Segmuller 6 IBM T.J. Watson Research Center 7 T. Martin 8 BeThereBeSquare Inc. 9 February 20, 2007 11 Sieve Extension: Notifications 12 draft-ietf-sieve-notify-07 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on August 24, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 Users go to great lengths to be notified as quickly as possible that 46 they have received new mail. Most of these methods involve polling 47 to check for new messages periodically. A push method handled by the 48 final delivery agent gives users quicker notifications and saves 49 server resources. This document does not specify the notification 50 method but it is expected that using existing instant messaging 51 infrastructure such as XMPP, or SMS messages will be popular. This 52 draft describes an extension to the Sieve mail filtering language 53 that allows users to give specific rules for how and when 54 notifications should be sent. 56 Changes since draft-ietf-sieve-notify-06 58 o Remove extract_text. The WG consensus was to move it to another 59 document, such as Sieve MIME loops. 61 o Deleted markers for open issues from the document. 63 o Clarified that a notification mechanism can treat some URI 64 parameters as an error. 66 o Added notify_method_capability test and example. 68 o Minor corrections to the IANA registration as a result of other 69 changes. 71 Changes since draft-ietf-sieve-notify-05 73 o Fixed XMPP URI in one example. 75 o Addressed Michael's issue with how timestamp are described. 77 o Renamed "valid_notif_method" to "valid_notify_method". 79 o Added text about truncation of a textual part when it is stored in 80 a variable using extract_text. 82 o Changed tagged :method argument to positional argument. 84 o Added text about notification throttling, identifying notification 85 source and restricting values of the :from parameter. 87 o Added a requirement on documents describing notification methods 88 to list which URI parameters must be ignored. 90 Changes since draft-ietf-sieve-notify-04 92 o Made notification method required. 94 o Defined "mailto" as a mandatory-to-implement method. 96 o Added normative reference to mailto. 98 o Clarified that :importance may be treated as a transport 99 indicator. 101 o Clarified that :importance value can be included in the default 102 :message, if one is not specified. 104 o Made the default :message implementation specific. 106 o Renamed the capability name from "notify" to "enotify" 108 o Updated IANA registration. 110 o Moved text about ManageSieve capability to the ManageSieve 111 document itself. 113 o Removed reference to IANA registry for options. 115 o Some miscellaneous text cleanup and clarification. 117 Changes since draft-ietf-sieve-notify-03 119 o Added a warning that "notify" must not be used as a crappy form of 120 "redirect". 122 o Added a warning about using "notify" to forward confidential 123 information in order to bypass organization's policy. 125 o Fixed syntax of the :options argument - it is a string list, each 126 string containing "=" 128 o Renamed :priority to :importance 130 o Cleaned up section about requirements on methods. 132 Changes since draft-ietf-sieve-notify-02 134 o Added :from tagged argument. 136 o Added Extract_text action, which allows to extract content of the 137 first text/* part. 139 o Added back the ":options" parameter to the notify action. 141 o Added new section talking about requirements on notification 142 method specs. 144 o Added more examples. 146 Changes since draft-ietf-sieve-notify-00 148 o Updated references, etc. 150 o Added IANA considerations section. 152 o Removed denotify action. 154 o Updated examples to use the variables extension. 156 o Replaced notification method with URI. 158 o Removed text suggesting that this extension can be used to track 159 all Sieve actions taken. 161 o Changed priority to be a string. 163 o Added text about URI verification. 165 o Clarified that a notification method is allowed to perform 166 adaptation of notification context (e.g. truncation, charset 167 conversion, etc.). These adaptations must be documented in a 168 document describing the notification method. 170 o Clarified that notify is compatible with all existing actions. 172 o Removed the :id parameter to the notify action. 174 o Added valid_notif_method test that allows to test if an 175 notification method (URI) is supported. 177 o Added a new capability response to ManageSieve that allows to 178 report supported notification types. 180 Table of Contents 182 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 183 1.1. Conventions used in this document . . . . . . . . . . . . . 6 185 2. Capability Identifier . . . . . . . . . . . . . . . . . . . 6 187 3. Notify Action . . . . . . . . . . . . . . . . . . . . . . . 6 188 3.1. Notify Action Syntax and Semantics . . . . . . . . . . . . . 6 189 3.2. Notify parameter "method" . . . . . . . . . . . . . . . . . 6 190 3.3. Notify tag ":from" . . . . . . . . . . . . . . . . . . . . . 7 191 3.4. Notify tag ":importance" . . . . . . . . . . . . . . . . . . 7 192 3.5. Notify tag ":options" . . . . . . . . . . . . . . . . . . . 8 193 3.6. Notify tag ":message" . . . . . . . . . . . . . . . . . . . 8 194 3.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 195 3.8. Requirements on notification methods specifications . . . . 11 197 4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 12 199 5. Test notify_method_capability . . . . . . . . . . . . . . . 13 201 6. Interactions with Other Sieve Actions . . . . . . . . . . . 14 203 7. Security Considerations . . . . . . . . . . . . . . . . . . 14 205 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 207 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 209 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 210 10.1. Normative References . . . . . . . . . . . . . . . . . . . . 16 211 10.2. Informative References . . . . . . . . . . . . . . . . . . . 16 213 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 214 Intellectual Property and Copyright Statements . . . . . . . 18 216 1. Introduction 218 This is an extension to the Sieve language defined by [Sieve] for 219 providing instant notifications. It defines the new action "notify". 221 This document does not specify the notification methods. Examples of 222 possible notification methods are email and XMPP. To allow a 223 mechanism for portability of scripts that use notifications, 224 implementation of the [MailTo] method is mandatory. Other available 225 methods shall depend upon the implementation and configuration of the 226 system. 228 1.1. Conventions used in this document 230 Conventions for notations are as in [Sieve] section 1.1, including 231 the use of [ABNF]. 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [Kwds]. 237 2. Capability Identifier 239 The capability string associated with the extension defined in this 240 document is "enotify". 242 3. Notify Action 244 3.1. Notify Action Syntax and Semantics 246 Usage: notify [":from" string] 247 [":importance" <"1" / "2" / "3">] 248 [":options" string-list] 249 [":message" string] 250 252 The Notify action specifies that a notification should be sent to a 253 user. The format of the notification is implementation-defined and 254 is also affected by the notification method used (see Section 3.2). 255 However, all content specified in the :message parameter SHOULD be 256 included. 258 3.2. Notify parameter "method" 260 The method positional parameter identifies the notification method 261 that will be used; it is a URI [URI]. For example, the notification 262 method can be an SMS URI [SMS-URI] containing a phone number, or an 263 XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]. 265 The supported URI values will be site-specific, but support for the 266 [MailTo] method is REQUIRED in order to insure interoperability. If 267 a URI schema is specified that the implementation does not support, 268 the notification MUST cause an error condition. Sieve scripts can 269 check the supported methods using the "valid_notify_method" test to 270 be sure that they only use supported ones, to avoid such error 271 conditions. 273 If the method parameter contains a supported URI schema, then the URI 274 MUST be checked for syntactic validity. An invalid URI syntax or an 275 unsupported URI extension MUST cause an error. An implementation MAY 276 enforce other semantic restrictions on URIs -- for example an SMS URI 277 can only contain phone numbers in a particular geographical region -- 278 and will treat violations of such semantic restrictions as errors. 280 3.3. Notify tag ":from" 282 A ":from" parameter may be used to specify an author of the 283 notification. The syntax of this parameter's value is method- 284 specific. Implementations SHOULD check the syntax according to the 285 notification method specification and generate an error when a 286 syntactically invalid ":from" parameter is specified. In order to 287 minimize/prevent forgery of the author value, implementations SHOULD 288 impose restrictions on what values can specified in a ":from" 289 parameter; it is suggested that values which fail such a validity 290 check simply be ignored rather than causing the notify action to 291 fail. 293 3.4. Notify tag ":importance" 295 The :importance tag specifies the importance of the delivery of the 296 notification. The :importance tag is followed by a numeric value 297 represented as a string: "1" (high importance), "2" (normal 298 importance), and "3" (low importance). If no importance is given, 299 the default value "2" SHOULD be assumed. A notification method can 300 treat the importance value as a transport indicator. For example, it 301 might deliver notifications of high importance quicker than 302 notifications of normal or low importance. Some notification methods 303 allow users to specify their state of activity (for example "busy" or 304 "away from keyboard"). If the notification method provides this 305 information it SHOULD be used to selectively send notifications. If, 306 for example, the user marks herself as "busy", a notification method 307 can require that a notification with importance of "3" is not to be 308 sent, however the user should be notified of a notification with 309 higher importance. 311 If the notification method allows users to filter messages based upon 312 certain parameters in the message, users SHOULD be able to filter 313 based upon importance. If the notification method does not support 314 importance, then this parameter MUST be ignored, however an 315 implementation MAY include the importance value in the default 316 message Section 3.6, if one is not provided. 318 3.5. Notify tag ":options" 320 The :options tag is used to send additional parameters to the 321 notification method. Interpretation of the parameters is method- 322 specific. This document doesn't specify any such additional 323 parameter. 325 Each string in the options string list has the following syntax: 326 "=" 328 3.6. Notify tag ":message" 330 The :message tag specifies the message data to be included in the 331 notification. The entirety of the string SHOULD be sent but 332 implementations MAY shorten the message for technical or aesthetic 333 reasons. If the message parameter is absent, a default 334 implementation-specific message is used. Unless specified otherwise 335 by a particular notification mechanism, an implementation default 336 containing at least the value of the "From" header field and the 337 value of the "Subject" header field is RECOMMENDED. 339 In order to construct more complex messages the notify extension can 340 be used together with the Sieve variables extension [Variables], as 341 shown in the examples below. 343 3.7. Examples 344 Example 1: 345 require ["enotify", "fileinto", "variables"]; 347 if header :contains "from" "boss@example.org" { 348 notify :importance "1" 349 :message "This is probably very important" 350 "mailto:alm@example.com"; 351 # Don't send any further notifications 352 stop; 353 } 355 if header :contains "to" "sievemailinglist@example.org" { 356 # :matches is used to get the value of the Subject header 357 if header :matches "Subject" "*" { 358 set "subject" "${1}"; 359 } 361 # :matches is used to get the value of the From header 362 if header :matches "From" "*" { 363 set "from" "${1}"; 364 } 366 notify :importance "3" 367 :message "[SIEVE] ${from}: ${subject}" 368 "mailto:alm@example.com"; 369 fileinto "INBOX.sieve"; 370 } 372 Example 2: 373 require ["enotify", "fileinto", "variables", "envelope"]; 375 if header :matches "from" "*@*.example.org" { 376 # :matches is used to get the MAIL FROM address 377 if envelope :all :matches "from" "*" { 378 set "env_from" " [really: ${1}]"; 379 } 381 # :matches is used to get the value of the Subject header 382 if header :matches "Subject" "*" { 383 set "subject" "${1}"; 384 } 386 # :matches is used to get the address from the From header 387 if address :matches :all "from" "*" { 388 set "from_addr" "${1}"; 389 } 391 notify :message "${from_addr}${env_from}: ${subject}" 392 "mailto:alm@example.com"; 393 } 395 Example 3: 396 require ["enotify", "variables"]; 398 set "notif_method" 399 "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; 401 if header :contains "subject" "Your dog" { 402 set "notif_method" "sms:+14085551212"; 403 } 405 if header :contains "to" "sievemailinglist@example.org" { 406 set "notif_method" ""; 407 } 409 if not string :is "${notif_method}" "" { 410 notify "${notif_method}"; 411 } 413 if header :contains "from" "boss@example.org" { 414 # :matches is used to get the value of the Subject header 415 if header :matches "Subject" "*" { 416 set "subject" "${1}"; 417 } 419 # don't need high importance notification for 420 # a 'for your information' 421 if not header :contains "subject" "FYI:" { 422 notify :importance "1" :message "BOSS: ${subject}" 423 "sms:+14085551212"; 424 } 425 } 427 3.8. Requirements on notification methods specifications 429 This section describes requirements for documents that define 430 specific Sieve notification methods. 432 A notification method MAY allow modification of the final 433 notification text -- for example, truncating it if it exceeds a 434 length limit, or modifying characters that can not be represented in 435 the target character set. Characters in the notification text which 436 can't be represented by the notification method SHOULD be replaced 437 with a symbol indicating an unknown character. Allowed modifications 438 MUST be documented in the document describing the notification 439 method. 441 A notification method MAY ignore parameters specified in the Notify 442 action. 444 A notification method MAY recommend the default message value to be 445 used if the :message argument is not specified. 447 Notifications SHOULD include timestamps, if the notification method 448 allows for their transmission outside of the textual message. 449 Implementation methods which can only transmit timestamps in the 450 textual message MAY include them in the textual message. 452 Notifications SHOULD includes means to identify/track its origin, in 453 order to allow a recipient to stop notifications or find out how to 454 contact the sender. This requirement is to help tracking a 455 misconfigured or abusive origin of notifications. 457 Methods SHOULD NOT include any other extraneous information not 458 specified in parameters to the notify action. 460 Methods MUST specify which URI parameters (if any) must be ignored, 461 which ones must be used in the resulting notification and which ones 462 must cause an error. 464 Methods MUST specify what values are returned by the 465 notify_method_capability test Section 5. 467 If there are errors sending the notification, the Sieve interpreter 468 SHOULD ignore the notification and not retry indefinitely. The Sieve 469 interpreter MAY throttle notifications; if it does, a request to send 470 a notification can be silently ignored. Documents describing 471 notification methods SHOULD describe how retries, throttling, 472 duplicate suppression (if any), etc. are to be handled by 473 implementations. 475 4. Test valid_notify_method 477 Usage: valid_notify_method 479 The "valid_notify_method" test is true if the notification methods 480 listed in the notification-uris argument are supported and they are 481 syntactically (including URI parameters) and semantically (including 482 implementation-specific semantic restrictions) valid. This test MUST 483 perform exactly the same validation as would be performed on the 484 "method" parameter to the "notify" action. 486 The test is true only if ALL of the listed notification methods are 487 supported and valid. 489 Example 4 (partial): 490 if not valid_notify_method ["mailto:", 491 "http://gw.example.net/notify?test"] { 492 stop; 493 } 495 5. Test notify_method_capability 497 Usage: notify_method_capability [COMPARATOR] [MATCH-TYPE] 498 499 500 502 The "notify_method_capability" test retrieves the notification 503 capability specified by the notification-capability string that is 504 specific to the notification-uri and matches it to the values 505 specified in the key-list. The test succeeds if a match occurs. The 506 type of match defaults to ":is" and the default comparator is 507 "i;ascii-casemap". 509 The notification-capability is case insensitive. 511 The notify_method_capability test MUST fail unconditionally if the 512 specified notification-uri is syntactically invalid (as determined by 513 the valid_notify_method test Section 4) or specifies an unsupported 514 notification method. However this MUST NOT cause an error. 516 The notify_method_capability test MUST fail unconditionally if the 517 specified notification-capability item does not exist. A script MUST 518 NOT fail with an error if the item does not exist. This allows 519 scripts to be written that handle nonexistent items gracefully. 521 This document defines a single notification-capability value 522 "online", which is described below. Additional notification- 523 capability values may be defined by a Standard Track or Experimental 524 RFC. 526 For the "online" notification-capability the notify_method_capability 527 test can match one of the following key-list values: 529 o "yes" - the entity identified by the notification-uri can receive 530 a notify notification immediately. Note that even after this 531 value is returned, there is no guaranty that the entity would 532 actually be able to receive any notification immediately or even 533 receive it at all. Transport errors, recipient policy, etc. can 534 prevent that. 536 o "no" - the entity identified by the notification-uri is not 537 currently available to receive an immediate notification. 539 o "maybe" - Sieve interpreter can't determine if the the entity 540 identified by the notification-uri is online or not. 542 The "relational" extension [Relational] adds a match type called 543 ":count". The count of an notify_method_capability test is 0 if the 544 returned information is the empty string, or 1 otherwise. 546 Example 5: 547 require ["enotify"]; 549 if notify_method_capability 550 "xmpp:tim@example.com?message;subject=SIEVE" 551 "Online" 552 "yes" { 553 notify :importance "1" :message "You got mail" 554 "xmpp:tim@example.com?message;subject=SIEVE"; 555 } else { 556 notify :message "You got mail" "sms:+14085551212"; 557 } 559 6. Interactions with Other Sieve Actions 561 The notify action is compatible with all other actions, and does not 562 affect the operation of other actions. In particular, the notify 563 action MUST NOT cancel the implicit keep. 565 Multiple executed notify actions are allowed. Specific notification 566 methods MAY allow multiple notifications from the same script to be 567 collapsed into one. 569 7. Security Considerations 571 Security considerations are discussed in [Sieve]. Additionally, 572 implementations must be careful to follow the security considerations 573 of the specific notification methods. 575 The notify action is potentially very dangerous. The path the 576 notification takes through the network may not be secure. An error 577 in the options string may cause the message to be transmitted to 578 someone it was not intended for, or may expose information to 579 eavesdroppers. 581 Just because a notification is received doesn't mean that it was sent 582 by the Sieve implementation. It might be possible to forge 583 notifications with some notification methods. 585 An organization may have a policy about the forwarding of classified 586 information to unclassified networks. Unless the policy is also 587 enforced in the module responsible for generating (or sending) of 588 notifications, users can use the extension defined in this document 589 to extract classified information and bypass the policy. 591 Notifications can result in loops and bounces. In particular, a 592 notification to an email address will not contain necessary Received 593 header fields that might be otherwise used to prevent mail loops. 594 All notification methods must take care to provide mechanisms for 595 avoiding notification loops. 597 8. IANA Considerations 599 The following template specifies the IANA registration of the notify 600 Sieve extension specified in this document: 602 To: iana@iana.org 603 Subject: Registration of new Sieve extension 604 Capability name: enotify 605 Description: adds the 'notify' action for notifying user about the 606 received message. It also provides two new test: valid_notify_method 607 checks notification URIs for validity; notify_method_capability can 608 check recipients capabilities. 609 RFC number: this RFC 610 Contact address: 611 The Sieve discussion list 613 This information should be added to the list of sieve extensions 614 given on http://www.iana.org/assignments/sieve-extensions. 616 9. Acknowledgements 618 Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus 619 Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. 620 Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen 621 and Peter Saint-Andre for help with this document. 623 10. References 624 10.1. Normative References 626 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 627 Specifications: ABNF", RFC 4234, October 2005. 629 [Kwds] Bradner, S., "Key words for use in RFCs to Indicate 630 Requirement Levels", RFC 2119, March 1997. 632 [MailTo] Leiba, B. and M. Haardt, "Sieve Notification Mechanism: 633 mailto", work in progress, draft-ietf-sieve-notify-mailto, 634 October 2006. 636 [Relational] 637 Segmuller, W. and B. Leiba, "Sieve Extension: Relational 638 Tests", work in progress, draft-ietf-sieve-3431bis, 639 December 2005. 641 [Sieve] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 642 Language", work in progress, draft-ietf-sieve-3028bis, 643 August 2006. 645 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 646 Resource Identifier (URI): Generic Syntax", STD 66, 647 RFC 3986, January 2005. 649 [Variables] 650 Homme, K., "Sieve Extension: Variables", work in 651 progress, draft-ietf-sieve-variables, December 2005. 653 10.2. Informative References 655 [SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short 656 Message Service", work in progress, draft-wilde-sms-uri, 657 August 2005. 659 [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence 660 Protocol (XMPP): Core", RFC 3920, October 2004. 662 [XMPP-URI] 663 Saint-Andre, P., "Internationalized Resource Identifiers 664 (IRIs) and Uniform Resource Identifiers (URIs) for the 665 Extensible Messaging and Presence Protocol (XMPP)", work 666 in progress, draft-saintandre-xmpp-iri, September 2005. 668 Authors' Addresses 670 Alexey Melnikov (editor) 671 Isode Limited 672 5 Castle Business Village 673 36 Station Road 674 Hampton, Middlesex TW12 2BX 675 UK 677 Email: Alexey.Melnikov@isode.com 679 Barry Leiba (editor) 680 IBM T.J. Watson Research Center 681 19 Skyline Drive 682 Hawthorne, NY 10532 683 US 685 Phone: +1 914 784 7941 686 Email: leiba@watson.ibm.com 688 Wolfgang Segmuller 689 IBM T.J. Watson Research Center 690 19 Skyline Drive 691 Hawthorne, NY 10532 692 US 694 Phone: +1 914 784 7408 695 Email: werewolf@us.ibm.com 697 Tim Martin 698 BeThereBeSquare Inc. 699 672 Haight st. 700 San Francisco, CA 94117 701 US 703 Phone: +1 510 260-4175 704 Email: timmartin@alumni.cmu.edu 706 Full Copyright Statement 708 Copyright (C) The IETF Trust (2007). 710 This document is subject to the rights, licenses and restrictions 711 contained in BCP 78, and except as set forth therein, the authors 712 retain all their rights. 714 This document and the information contained herein are provided on an 715 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 716 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 717 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 718 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 719 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 720 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 722 Intellectual Property 724 The IETF takes no position regarding the validity or scope of any 725 Intellectual Property Rights or other rights that might be claimed to 726 pertain to the implementation or use of the technology described in 727 this document or the extent to which any license under such rights 728 might or might not be available; nor does it represent that it has 729 made any independent effort to identify any such rights. Information 730 on the procedures with respect to rights in RFC documents can be 731 found in BCP 78 and BCP 79. 733 Copies of IPR disclosures made to the IETF Secretariat and any 734 assurances of licenses to be made available, or the result of an 735 attempt made to obtain a general license or permission for the use of 736 such proprietary rights by implementers or users of this 737 specification can be obtained from the IETF on-line IPR repository at 738 http://www.ietf.org/ipr. 740 The IETF invites any interested party to bring to its attention any 741 copyrights, patents or patent applications, or other proprietary 742 rights that may cover technology that may be required to implement 743 this standard. Please address the information to the IETF at 744 ietf-ipr@ietf.org. 746 Acknowledgment 748 Funding for the RFC Editor function is provided by the IETF 749 Administrative Support Activity (IASA).