idnits 2.17.1 draft-ietf-lemonade-notifications-04.txt: -(167): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(876): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1014): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1220. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1196. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1204. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1210. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 1172), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 1226. ** Found boilerplate matching RFC 3978, Section 5.5, updated by RFC 4748 (on line 1185), which is fine, but *also* found old RFC 3978, Section 5.5 text on line 1220. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances 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 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: ---------------------------------------------------------------------------- == In addition to RFC 3978, Section 5.5 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == In addition to RFC 3978, Section 5.5, updated by RFC 4748 boilerplate, a section with a similar start was also found: This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. -- 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 section? 'RFC2119' on line 98 looks like a reference -- Missing reference section? 'RFC3501' on line 988 looks like a reference -- Missing reference section? 'LEMONADEPROFILE' on line 947 looks like a reference -- Missing reference section? 'LEMONADEPROFILEBIS' on line 950 looks like a reference -- Missing reference section? 'OMA-ME-RD' on line 974 looks like a reference -- Missing reference section? 'SIEVE' on line 992 looks like a reference -- Missing reference section? 'VFOLDER' on line 1003 looks like a reference -- Missing reference section? 'IMAPSIEVE' on line 943 looks like a reference -- Missing reference section? 'ANNOTATEMORE' on line 929 looks like a reference -- Missing reference section? 'MSGEVENTS' on line 1130 looks like a reference -- Missing reference section? 'RFC2177' on line 985 looks like a reference -- Missing reference section? 'RECONNECT' on line 1026 looks like a reference -- Missing reference section? 'SIEVENOTIFICATION' on line 326 looks like a reference -- Missing reference section? 'IMAP-EVENTS' on line 1117 looks like a reference -- Missing reference section? 'IMAP-DISC' on line 936 looks like a reference -- Missing reference section? 'OMA-EN' on line 967 looks like a reference -- Missing reference section? 'OMN-EN' on line 373 looks like a reference -- Missing reference section? 'OMA-EMN' on line 390 looks like a reference -- Missing reference section? 'MANAGESIEVE' on line 954 looks like a reference -- Missing reference section? 'RFC-URL' on line 818 looks like a reference -- Missing reference section? 'URLAUTH' on line 999 looks like a reference -- Missing reference section? 'NOTIFICATIONPROTOCOL' on line 1038 looks like a reference -- Missing reference section? 'ABNF' on line 926 looks like a reference -- Missing reference section? 'OMA-ME-AD' on line 971 looks like a reference -- Missing reference section? 'P-IMAP' on line 1048 looks like a reference -- Missing reference section? 'SIEVENOTIFICATIONS' on line 995 looks like a reference -- Missing reference section? 'WAPWDP' on line 1090 looks like a reference -- Missing reference section? '1' on line 1014 looks like a reference -- Missing reference section? '2' on line 1023 looks like a reference -- Missing reference section? '3' on line 1025 looks like a reference -- Missing reference section? '4' on line 1029 looks like a reference -- Missing reference section? '5' on line 1033 looks like a reference -- Missing reference section? '6' on line 1037 looks like a reference -- Missing reference section? '7' on line 1040 looks like a reference -- Missing reference section? 'CLEARIDLE' on line 1130 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 44 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Lemonade Notifications and Filters S. H. Maes 3 R. Cromwell 4 Oracle 5 Document: draft-ietf-lemonade-notifications-04.txt R. Gellens 6 Expires: October 2007 Qualcomm 7 April, 2007 9 Lemonade Notifications and Filters 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference 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 The list of 30 Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The IETF Trust (2007). All Rights Reserved. 37 Abstract 39 This document discusses how to provide notification and filtering 40 mechanisms to IMAP as part the Lemonade profile. 42 This document also discusses the use of Lemonade notifications to 43 implement server to server notifications. 45 Maes et al [Page 1] Expires October 2007 46 Table of Contents 48 1. Conventions Used in this Document . . . . . . . . . . . . . 2 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Objectives . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Notification logical architecture and LEMONADE Profile bis 4 52 5. Capability . . . . . . . . . . . . . . . . . . . . . . . . 6 53 6. Event-based synchronization . . . . . . . . . . . . . . . 6 54 7. Filters . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 7.1. Next steps and future work . . . . . . . . . . . . . . 9 56 8. Inband notification payload . . . . . . . . . . . . . . . . 9 57 9. Outband Notification payload . . . . . . . . . . . . . . . 9 58 9.1. Outband Notification Payload in Clear Text . . . . . . 9 59 10. LEMONADE message store behavior . . . . . . . . . . . . . 11 60 11. Provisioning and Preferences for Notification Settings . . 11 61 11.1. Entry Names and Attributes . . . . . . . . . . . . . . 12 62 11.2. Provision Entries . . . . . . . . . . . . . . . . . . . 12 63 11.3. Preference Entries . . . . . . . . . . . . . . . . . . 13 64 11.4. Getting and setting preference and provisioning annotati 14 65 12. Changing filters from the client . . . . . . . . . . . . . 15 66 13. Out of scope items for IETF . . . . . . . . . . . . . . . . 15 67 14. Server to server notifications considerations . . . . . . 15 68 14.1. Scope of server to server notifications . . . . . . . . 16 69 14.2. Basic Operation . . . . . . . . . . . . . . . . . . . 17 70 14.3. Server to server terminology . . . . . . . . . . . . . 18 71 14.4. Notification payloads . . . . . . . . . . . . . . . . 18 72 14.5. Server to server notification protocol details . . . . 19 73 14.5.1. Generic case . . . . . . . . . . . . . . . . . . . 19 74 14.5.2. Abstracted notification protocol . . . . . . . . . 20 75 14.5.3. Exception Handling . . . . . . . . . . . . . . . . 20 76 14.6. Server to server complementary information . . . . . . 21 77 14.7. Event orders . . . . . . . . . . . . . . . . . . . . . 21 78 14.8. Reliability . . . . . . . . . . . . . . . . . . . . . . 21 79 15. Security Considerations . . . . . . . . . . . . . . . . . 21 80 16. Normative and Informative References . . . . . . . . . . . . 22 81 17. Future Work . . . . . . . . . . . . . . . . . . . . . . . 23 82 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 24 83 19. Authors Addresses . . . . . . . . . . . . . . . . . . . . 24 84 Appendix A: Out-of-band SMS channel binding (INFORMATIVE appen 25 85 Appendix B: Changes from Previous Versions . . . . . . . . . 25 86 Intellectual Property Statement . . . . . . . . . . . . . . . 26 87 Full Copyright Statement . . . . . . . . . . . . . . . . . . 27 89 1. Conventions Used in this Document 91 Maes et al [Page 2] Expires October 2007 92 In examples, "C:" and "S:" indicate lines sent by the client and 93 server respectively. 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 An implementation is not compliant if it fails to satisfy one or 100 more of the MUST or REQUIRED level requirements for the protocol(s) 101 it implements. An implementation that satisfies all the MUST or 102 REQUIRED level and all the SHOULD level requirements for a protocol 103 is said to be "unconditionally compliant" to that protocol; one that 104 satisfies all the MUST level requirements but not all the SHOULD 105 level requirements is said to be "conditionally compliant." When 106 describing the general syntax, some definitions are omitted as they 107 are defined in [RFC3501]. 109 2. Introduction 111 As the work on LEMONADE Profile ([LEMONADEPROFILE] and 112 [LEMONADEPROFILEBIS]) progresses, a need has been identified to 113 provide notification and filtering mechanisms to IMAP4. 115 The requirements for inband and outband server to client 116 notifications are documented in [OMA-ME-RD]. 118 3. Objectives 120 According to these analyses, there is a need to support: 121 # Mechanisms for event-based (server to client) synchronization: 122 * Defines the relationship between notification mechanisms and 123 the IMAP4 protocol 124 - To minimize the latency observed for email events on the 125 email server to be reflected in the email client. 126 - To avoid unnecessary polling and requests from the e-mail 127 clients: 128 . To reduce the total amount of data to be exchanged 129 between email server and client, e.g. by allowing the email client 130 to select which messages to synchronize and how to synchronize. 131 . To reduce the amount of transactions. 132 * Needs to cope with possible lost or delayed notifications 133 * Support in-band (within IMAP band) and out-band notifications 134 (Exchanged via other servers / enablers). 135 - Specified in ways that are network transport independent 136 but may contain some bindings to particular notification channels 137 (e.g. SMS binary, WAP Push, SIP Notification, ...) 138 - When the email client is connected to the email server, 140 Maes et al [Page 3] Expires October 2007 141 only inband notifications is expected take place 142 * Defines notification payload for inband and outband 143 mechanisms. 144 # Server-side filtering to decide which messages will be 145 accessible by the email client. 146 * Filtering results into the following logical types: 147 - Type A: Messages filtered out and not accessible by the 148 email client (no notification, no header access, no access) 149 - Type B: Messages that are accessible by the mobile e-mail 150 enabler client but no outband notification takes place. 151 Inband notification might however take place if email 152 client is already connected to email server. 153 - Type C: Messages that are accessible by the e-mail client 154 for which notifications (outband or inband) are always 155 sent to the email client. 156 # Notions of Filters: 157 * View filters: Filters that determine which email messages 158 are of type B and C or A 159 * Notification filters: Filters that determine which email 160 messages are of type C or B 161 * Event filters: Filters that determines what events are to be 162 notified to the client 163 # Mechanisms to allow the user to update the filters from the 164 email client 165 # Mechanisms to allow configuration and exchange of settings 166 between the client and the server in band or outband: - Server 167 to client: e.g. server ID, account name, policies, � - Client to 168 server: e.g. rules filters vacation notices, notification 169 channel, ... 171 The present document describes how this may be achieved within the 172 scope of LEMONADE Profile [LEMONADEPROFILEBIS]. 174 4. Notification logical architecture and LEMONADE Profile bis 176 The target logical architectures involving the LEMONADE Profile and 177 notifications are discussed in [LEMONADEPROFILEBIS]. 179 Maes et al [Page 4] Expires October 2007 180 Figure 1 illustrates how notification and filtering can be 181 introduced in the context of LEMONADE profile bis. 183 +--------------+ 184 | | 185 +---------| Notification | 186 | | Mechanism | 187 | +----------^---+ 188 |Notif. | 189 |Protocol -------\ +|-+_ 190 | ______| +---\>|NF|----+ 191 | | | +--+ | +-----+ 192 v | IMAP +--+_LEMONADE +---+ ESMTP +--+ | 193 +-----+<-------->|VF| IMAP |DF |<--------|AF| MTA | 194 | MUA |\ ME-2a +--+ Store +-^-+ +--+ | 195 | | \ +-------------+ | +-----+ 196 +-----+--\---------------|-------+ 197 \ |URLAUTH 198 \SUBMIT | 199 \ +----v-----+ 200 \ | | +-----+ 201 \ | LEMONADE | ESMTP | | 202 ---->| Submit |--------------->| MTA | 203 ME-2b | Server | | | 204 | | +-----+ 205 +----------+ 207 Figure 1: Filtering mechanism defined in LEMONADE Profile bis 208 architecture. 210 In Figure 1, four categories of filters are defined: 212 # AF: Administrative Filters - Set up by email service provider. 213 AF are typically not configured by the user and set to apply 214 policies content filtering, virus protection, spam filtering etc... 215 # DF: Deposit Filters - Filters that are executed on deposit of 216 new emails. They can be defined as SIEVE filters [SIEVE]. They 217 can include vacation notices. 218 # VF: View Filters - Filters that define which emails are visible 219 to the MUA. View filters can be defined as virtual folders 220 [VFOLDER] as described in later in this document. 221 # NF: Notification Filters - Filters that define for what email 222 server event an outband notification is sent to the client. 224 The filters are manageable from the MUA: 226 Maes et al [Page 5] Expires October 2007 227 # NF and DF: via SIEVE management protocol . [IMAPSIEVE] provides an example of how notification 229 filters (NF) may be expressed in SIEVE. 230 # VF: via VFOLDER as defined in [VFOLDER] 232 5. Capability 234 A server supporting Lemonade notifications MUST report the following 235 set of capabilities: IDLE, METADATA, LISTEXT, LNOTIFICATION, 236 VFOLDER. 238 METADATA (and by transitive dependency LISTEXT) are from the 239 [ANNOTATEMORE] extension, used to store notification provisioning 240 and preference information. 242 VFOLDER declares support for [VFOLDER]. 244 LNOTIFICATION is currently a placeholder umbrella capability 245 declares support for outband notification filters and filter 246 management as described in this document, which may includes works 247 in progress such as SIEVE notification filters and filter 248 management. 250 6. Event-based synchronization 252 The addition of Server-to-client notifications transforms the 253 LEMONADE profile into an event-based synchronization protocol. 254 Whenever an event of the type [MSGEVENTS] occurs within the view, a 255 notification can be generated. [MSGEVENTS] provides a list of 256 possible events that could be notified (based on the filter 257 settings). 259 If the MUA is connected to the IMAP server, inband notifications are 260 generated following IDLE [RFC2177]. 262 When the MUA is not connected, the Notification filter generates a 263 outband notification. The notification filter may be considered as 264 acting on a PUSH repository. 266 If the MUA is not connected, and outband notification is disabled, 267 the client must perform a quick-sync on reconnect to determine 268 mailbox changes. If the MUA has only momentarily lost connection, 269 it should also attempt to use [RECONNECT]. 271 Maes et al [Page 6] Expires October 2007 272 Formally, a repository consists of a set of folders, and each folder 273 has both a name and a set of messages associated with it. The 274 "complete repository" consists of all folders of an end user and all 275 the associated messages for each of those folders. 277 Maes et al [Page 7] Expires October 2007 278 This is illustrated in Figure 2. 280 +----------------+ +---------------+ +------------+ 281 | COMPLETE | | | | | 282 | | (VF) | VIEW | | PUSH | 283 | REPOSITORY | View | REPOSITORY |Notification| REPOSITORY | 284 | all the emails |Filters | emails to be | Filters | important | 285 |in an end user's|========|on the mobile |=========| emails / | 286 | | | | | | events | 287 | email account | |client(VFOLDER)| | | (NF) | 288 +----------------+ +---------------+ | +------------+ 289 | | 290 IDLE | 291 | Outband 292 | Notification 293 | | 294 V V 296 Figure 2: Filters and Repositories 298 In inband notification mode, the MUA issues IDLE, and notifications 299 are sent as unsolicited responses to the MUA from the LEMONADE IMAP 300 server. 302 In outband notification mode, the outband notification may be a 303 message (notification payload) and possibly a set of surrounding 304 exchanges sent with an appropriate format to a particular IP address 305 and port. This may be the address of the MUA. However, in general, 306 it conforms to the interface of a notification server / mechanisms 307 responsible for finalizing the format and sending the notification 308 to the MUA on the client with the appropriate protocol. 310 The following sections provide description of the outband 311 notification payload format and mechanisms to check, set and 312 notification settings. 314 7. Filters 316 [SIEVE] provides an email filtering language. 318 [VFOLDER] describes how the View Filter (VF) can be implemented and 319 modified from the MUA. Alternative mechanisms for creating virtual 320 mailbox views may be possible, however they should satisfy the 321 requirement that an out-of-band notification may refer to them by 322 name in order to tell the client which view an event occurred for. 324 Maes et al [Page 8] Expires October 2007 326 [SIEVENOTIFICATION] and [IMAPSIEVE] provides a mechanisms to 327 associate notifications based on the [SIEVE] filter whenever 328 messages are created or changed within a LEMONADE IMAP store. 330 7.1. Next steps and future work 332 [SIEVE] filters and [IMAPSIEVE] should be extended to support 333 binding to all [MSGEVENTS]. 335 8. Inband notification payload 337 Inband notification syntax follows the IDLE specifications 338 [RFC2177]. However, which unsolicited responses are generated by 339 each event is ambiguous in [RFC2177]. [IMAP-EVENTS] defines a more 340 rigorous set of requirements for IDLE events, including how to 341 monitor mailboxes when not in a selected state. 343 In lieu of this, simpler MUAs MAY choose to interpret unsolicited 344 responses in IDLE as a "wake up call" to perform a sync. 345 [IMAP-DISC] is an informative reference for how to do this 346 efficiently. 348 9. Outband Notification payload 350 9.1. Outband Notification Payload in Clear Text 352 The outband notification payload is in general in clear text, unless 353 the payload carries sensitive data. Server to Client Notification 354 and Filtering treats the notification as a signal to the client to 355 fetch the information on the server that awaits it. 357 The payload for wake-up notifications is the OMA EMN format, see 358 [OMA-EN]. This notification, minimally, informs the client that 359 some push event has happened on the server, so it must connect to 360 fetch the information. 362 Server to client notifications and filters treats the notification 363 as a MUA wake up event to fetch the information on the server that 364 awaits it. The MUA MAY present other behaviors that exploit 365 additional information provided in the notification. However this 366 is out of scope of the specifications. 368 Maes et al [Page 9] Expires October 2007 369 Wake-up events consists of the following payload (example): 373 The mailbox URI formats are defined in [OMN-EN]. 375 The notification payload is generated by NF and sent to an 376 appropriate messaging interface, appropriately formatted for that 377 interface. The messaging mechanism is then responsible for sending 378 the notification to the MUA. 380 Example: A new message arrives on the server and this is notified 381 via out-of-band. 382 S: pushes SMS with the following text: 383 386 388 Here the notification payload is sent to an SMSC messaging 389 interface, appropriately formatted for that interface. The SMSC is 390 responsible for sending the SMS to the MUA using [OMA-EMN] encoding. 392 If EXTENDED notification format is supported by the MUA, a new 393 extended EMN element is used which contains additional XML 394 attributes. 396 The format of this extended EMN element is: 398 413 With the 'xemn' element's allowed children as 415 ;CDATA contains optional snippet 416 of body of message or any text 417 to be displayed on MUA when 419 Maes et al [Page 10] Expires October 2007 420 viewing message prior to 421 synchronization. 423 Extended EMN payloads should be encrypted. 425 Example extended payload: 427 439 I can't make the 9:15 meeting, can we reschedule? 440 442 A client may treat an extended notification as a wakeup 443 notification, or it may parse the payload and utilize the included 444 data to synchronize new messages more efficiently. Not all of the 445 fields will have values, depending on the type of event. The client 446 may utilize the view and uid attributes to determine which IMAP 447 mailbox the event occurred in, and for which message. The view 448 attribute may refer to an IMAP Mailbox, or a named virtual folder if 449 implemented by the client. 451 10. LEMONADE message store behavior 453 Because outband notifications may be sent over unreliable channels 454 (i.e., they may be lost or delayed), the server MUST keep track of 455 the outband notifications that are sent via NF, until the MUA react 456 to them. 458 If a MUA does not react to outband notifications, the server MAY 459 stop sending outband notifications, except possibly periodic wake up 460 calls until the client reconnects. 462 Maes et al [Page 11] Expires October 2007 463 11. Provisioning and Preferences for Notification Settings 465 It is sometimes necessary for the server to inform the client of 466 default notification settings the first time the client is used, as 467 well as notification capabilities of the server. It is also 468 necessary for the client to adjust notification preferences. 469 [ANNOTATEMORE] is used to store provisioning and preference 470 information. 472 The difference between a provision entry and a preference entry is 473 that provision entries are typically read-only, global to the user, 474 and represent capabilities, whereas preference entries are writable 475 by the client, and per-mailbox, and represent actual settings. 477 A client only needs to access provision information once when the 478 device uses the Lemonade server for the first time. It MAY opt to 479 not cache provisioning information, and re-read it on each 480 connection, but it is not necessary. Re-provisioning MAY also be 481 initiated manually via user action, or via out-of-band notification. 483 Provision and preference data marked "private" in [ANNOTATEMORE] 484 terminology is also inherently per-device, not per-user. Attributes 485 marked "shared" are inherently per-user. If a user logs in as his 486 desktop client identity, "private" preference data is separate from 487 his mobile phone identity, rather than shared. However, "shared" 488 preference data may be visible to all of his devices (but not other 489 users) 491 11.1. Entry Names and Attributes 493 Entry names and Attributes listed in this section SHOULD be 494 supported by any server claiming LNOTIFICATION compliance. ABNF 495 structure of attribute values is provided. 497 11.2. Provision Entries 499 The following are server-global provision entries. 501 /notify/outband 502 Defines attributes related to out-of-band notification. 504 Attribute Names = Values: 505 "channel.priv" = "NONE" *(SP ("SMS" / "MMS" / "SIP" / "XMPP" / 506 "UDP") = format) 508 ;a list of supported out-of-band channels 509 ;for the current device and their formats 511 Maes et al [Page 12] Expires October 2007 512 format = "WAKEUP" / "EXTENDED" 514 Example: "NONE SMS=WAKEUP MMS=EXTENDED SIP=EXTENDED 515 UDP=EXTENDED" 517 "credential.priv" = string 518 ;the source address or identity of the server 519 sending the notifications, potentially with an 520 integrity check 522 /notify/inband 524 Defines attributes related to in-band notifications. 526 Attribute Names = Values: 527 "push.shared" = event-list 528 ;a space separated list of push event names 529 supported for in-band push. TBD in Lemonade events 530 / notification work. 532 /notify/security 534 Defines attributes related to negotiable security parameters for 535 securing out of band event notification and proxied deployment 536 models. TBD. 538 11.3. Preference Entries 540 The following are per-mailbox per-device preference entries. 542 /notify/outband 543 Defines attributes related to chosen preference for out-of-band 544 notification. 546 Attribute Names=Values: 547 "channel.priv" = "NONE" / "SMS=" format / "MMS=" format / 548 "SIP=" format / "XMPP=" format / "UDP=" format 549 ;for a device capable of multiple mechanisms, 550 ;set this attribute to the desired mechanism 552 format = "WAKEUP" / "EXTENDED" 554 "address.priv" = string 555 ;the phone number, email address, or 556 ;destination endpoint for notifications 558 Maes et al [Page 13] Expires October 2007 559 ;if different from server known device default 560 ;(e.g. device phone number, or device IP 561 ; address on well known open port, etc) 563 "limit.priv" = "size=" nz-number | "total=" nz-number 564 ;the maximum number of bytes to send in 565 ;notification payloads or the total number 566 ;of messages to send. Both per-day 568 /notify/inband 570 Defines attributes related to inband push events. 572 Attribute Names=Values: 573 "msgformat.priv" = fetch-att 574 ;RFC3501 fetch-att syntax detailing the format 575 ;of unsolicited FETCH responses generated in-band 576 ;for new message arrivals 578 "push.priv" = "push" / "pull" 579 ;specifies whether the client expects 580 ;new messages to be pushed via the unsolicited 581 ;FETCH response defined above, or via client 582 ;issued FETCH in response to an EXISTS response. 584 /notify/event 586 Defines attributes related to event / notification filtering. 588 "filter.priv" = "ALL" / "NEW" / "NONE" 589 ;specifies whether no events are pushed 590 ;NEW message events are pushed, or ALL 591 ;events are pushed 593 11.4. Getting and setting preference and provisioning annotations 595 To fetch a provision, a client should generate a GETANNOTATE command 596 with no mailbox specified according to [ANNOTATEMORE] 598 Example: Discover all provision parameters 600 C: a GETMETADATA /notify/* (channel credential push) 601 S: * METADATA /notify/outband (channel.priv "SMS=WAKEUP NONE" 602 credential.priv "55555" 603 push.shared "new expunged") 604 S: a OK GETMETADATA Complete 606 Maes et al [Page 14] Expires October 2007 607 Example: Set out-of-band mechanism to "MMS" with EMN extended 608 support 610 C: a SETMETADATA "INBOX" /notify/outband (channel.priv 611 "MMS=EXTENDED") 612 S: a OK SETMETADATA complete 614 12. Changing filters from the client 616 VFOLDER also provides ways to update VF. 618 NF Filter remote management mechanisms MAY rely on [MANAGESIEVE] 620 13. Out of scope items for IETF 622 OMA provides ways to perform provisioning via OMA client 623 provisioning and device management. Other provisioning 624 specifications are available (e.g. SMS based). 626 OMA provides enablers to support outband notifications: the outband 627 notification mechanisms. 629 Also, OMA XDM may be considered also for outband filter changes. 631 14. Server to server notifications considerations 633 The following sections focus on considerations and usage of the 634 Lemonade notifications for server to server notifications 636 With server to server notifications, a messaging system (e.g. email 637 server, voice mail system, etc.) submits alerts, which describe 638 potential notification events, regarding an end user mailbox status 639 change (e.g. new message has arrived, mailbox is full, etc.). 641 These alerts are sent to a notification mechanisms, which may, in 642 turn, generate an end user alert notification. 644 Server to server notifications facilitate a solution where the 645 messaging system initiates an end user notification, while allowing 646 the messaging system, not to be familiar with the end user's 647 notification preferences. 649 The notification mechanisms are the entities which is familiar with 650 the end user's notification preferences. 652 Maes et al [Page 15] Expires October 2007 653 Using server to server notifications, allow the messaging system to 654 provide the end user, a unified notification experience (the same 655 look and feel for all messaging systems' accounts), while allowing 656 smooth integration of additional Messaging systems. 658 14.1. Scope of server to server notifications 660 The suite of Internet mail protocols (POP3, IMAP4) allows different 661 mail clients to access and manipulate electronic mail messages on a 662 messaging system. These protocols, however, do not provide off-line 663 methods by which an end user can be notified upon changes in the 664 mailbox status. Further, none of the mentioned protocols defines a 665 way to aggregate the status within the end user's various mailboxes. 667 To provide an end user with the ability of unified Notification and 668 one centralized message-waiting indication (MWI), notification 669 mechanisms are required to aggregate the information of all the 670 events occurring on the end user's different messaging systems. 672 With server to server notifications, a messaging system notifies the 673 notification mechanisms regarding events occurring in an end user's 674 mailbox. It is important to emphasize, that server to server 675 notifications do not deal with the communications between the 676 notification mechanisms and the end user devices (SMS, WAP Push, 677 MWI, etc.). 679 For example, when an email message is deposited in an email server, 680 the email server sends a "new message" notification to the 681 notification service, which then notifies the end user by a Short 682 Text Message (SMS). 684 This process can be extended to include other mailbox events that 685 are important to the end user, such as "mailbox full" and "message 686 rejected" or any other mailbox status change. Each notification 687 should include additional information that is available to the end 688 user such as the mailbox status, message attributes, etc. 690 Maes et al [Page 16] Expires October 2007 691 The figure 3 depicts the server to server notification scope: 693 +--------+ +--------+ 694 New | | | SMS | 695 Message | Email | \ |Gateway | 696 -------> |Server 1| \ _ | | 697 +--------+ \ /| +--------+ 698 ^ \ / 699 | \ / ^ 700 | \ +--------------+ / | +--------+ 701 +--------+ | _|+-------------|+ / | | MWI | 702 Read | Voice | | || |/ | |Gateway | 703 Message | Mail |-------->| Notification |------->| | 704 -------> | Server | | ^ _ +| Mechanisms |\ ^ | +--------+ 705 +--------+ | | /| +--------------- \ | | 706 | |/ \ \| | 707 | / ^ \ ^ \ | 708 |/| | \ | |\| 709 +--------+ / | | \ | | \ +--------+ 710 Mailbox | | /| | | \| | |\ | Wap | 711 Full | Email |/ | | | ^ \ | |_|| Push | 712 -------> |Server 2| | | | | |\| | |Gateway | 713 +--------+ | | | | | \ | +--------+ 714 | | | | | |\| 715 | | | | | | \ 716 | | | | | | |\ 717 | | | | | | |_|+--------+ 718 | | | | | | | | IM | 719 | | | | | | | |Gateway | 720 | | | | | | | | | 721 | | | | | | | +--------+ 722 | | | | | | | 723 Server to OTHER 724 Server PROTOCOLS 725 Notifications 727 Figure 3: Scope of server to server notifications 729 The notification mechanisms can either provide an abstract 730 notification mechanism able to convert notifications to an 731 appropriate channel or expose the northbound interface (application 732 interface) exposed by a specific notification channel. In the 733 latter case it may just be a logical concept and the sender of 734 notifications may directly address the appropriate notification 735 channels. All the options are viable. 737 Maes et al [Page 17] Expires October 2007 738 14.2. Basic Operation 740 The messaging system notifies the notification mechanisms (which in 741 turn MAY notify an end user) about events that occurred in the end 742 user's mailbox. Each such notification, referring to a single 743 mailbox event is referred to as a notification request. 745 The notification request SHOULD contain data regarding the mailbox 746 event which has occurred. It's RECOMMENDED that the request would 747 not contain data regarding the end user notification destinations. 748 This would be left to the notification mechanisms� implementation. 749 If such data has been received the notification mechanisms MAY 750 ignore it. 752 14.3. Server to server terminology 754 This specification uses the following terms: 756 Message Waiting Indication (MWI): 758 A mechanism that indicates to the end user that a message is 759 waiting in a Messaging System 761 Examples for such action are: SMS message, WAP push message, 762 Instant messaging notification, telephony stutter tone, etc. MWI 763 states may be ON or OFF. 765 Notification Event: 767 An event that may result in a notification to the end user or may 768 change the MWI state (ON or OFF) 770 Messaging System: 772 A system that maintains a set of one or more mailboxes for end 773 user's messages, for example: email servers, voicemail systems, 774 etc. 776 Notification Mechanisms: 778 A system, which aggregates all notification events from multiple 779 Messaging systems to multiple end user destinations. 781 14.4. Notification payloads 783 Maes et al [Page 18] Expires October 2007 784 The cases of Figure 1 and Figure 3 are very similar. 786 In both cases a message must be generated by the message store as 787 result of a message event. This message is communicated to the 788 messaging mechanisms. 790 Within the context of Lemonade profile (Figure 1), the event is 791 filtered by NF and the payload of the notification is defined in 792 section 8. 794 In more generic cases, the server to server notification payload can 795 be any message. Certain may be defined to: 796 # Realize the messaging mecanisms� task which has caused the 797 notification event. The task may be related to one of the 798 following: 799 * New message Task 800 - New Message Deposit 801 * Mailbox Manipulation Task (e.g. Login, Logout, etc.) 802 - Login to mailbox 803 - Logout from mailbox 804 - Read message 805 - Delete Message 806 - Purge Message 807 * Management Task (e.g. Mailbox Full) 808 - Mailbox full 809 - Mailbox full cancellation 811 The task's types list, as defined above, SHOULD be extendable. 812 # Provide a rich experience to the end user of the notification, 813 without the need to actually retrieve the message. This MAY include 814 mailbox status, message attributes, etc. 815 # Practice different MWI behaviors (e.g. turn MWI indication off 816 after all the messages in all the end user's mailboxes have been 817 read). 818 # URL, as defined in [RFC-URL] or [URLAUTH], referring to the 819 message which has caused the event, to the notification 820 mecanisms (and eventually, to the end user). 822 14.5. Server to server notification protocol details 824 14.5.1. Generic case 826 Within the more general case of server to server notification, the 827 payload may be an arbitrary text or binary message. 829 Maes et al [Page 19] Expires October 2007 830 In both cases the interaction model is defined as: 831 1 An event takes place in the message store 832 2 The event is filtered. As a result it may be hidden or result 833 into a notification. 834 3 The notification is a message in a particular payload that is 835 prepared for the target notification mechanisms. 836 4 The payload is complemented with the necessary information to 837 tell the notification mechanism how and where to send the 838 notification. 839 5 The complemented payload is then formatted as required by the 840 target notification mechanisms (i.e. the right format on the 841 right port to be sent to the right address, possibly with an 842 appropriate protocol binding � e.g. HTTP PUT) plus the 843 information about where / how to send the notification. This 844 last step is imposed by the notification mechanisms and must be 845 known by the notification generating filter. 847 Different interfaces and bindings may be used depending on the 848 notification channel. 850 14.5.2. Abstracted notification protocol 852 When a mechanism is provided to abstractly notify a notification 853 mechanism that is then responsible for notifying via the appropriate 854 channel, the notification protocol MUST follow 855 [NOTIFICATIONPROTOCOL]. 857 14.5.3. Exception Handling 859 It is assumed that the interface exposed by the notification 860 mechanisms can notify the messaging system about the outcome of the 861 notification request (notification status message). The 862 notification mechanisms SHOULD notify the messaging system whenever 863 a problem has occurred. 865 If the request has failed, the response, when available, SHOULD be 866 coherent enough to allow the messaging system to determine the cause 867 of the failure. 869 The notification mechanisms SHOULD make a distinction between events 870 in which the content of the request has caused an error (request 871 errors), and cases in which a non-source-related reason has caused 872 the error. 874 Maes et al [Page 20] Expires October 2007 875 The Messaging system SHOULD parse the notification status message, 876 when available, to decide its next actions (e.g. clear the message�s 877 content, recompile the message data, etc.). 879 14.6. Server to server complementary information 881 The server to server complementary information MUST include: 882 * Identify the end user whose inbox has generated the 883 notification. 884 * Identify the end user or end target addresses or identifiers 885 that should be informed about the notification event (not 886 necessarily the same as the previous end user). 887 * Decide what kind of actions, the notification mechanisms should 888 perform, due to the notification request. 890 14.7. Event orders 892 For lemonade profile bis, the event order is not important. 894 For generic server to server notifications, the order may matter and 895 the messaging system must provide the notifications in the order 896 that they are generated by mailbox events. 898 14.8. Reliability 900 For Lemonade profile bis, lost or delayed notifications of the MUA 901 are not critical. A client can recover all missing events next time 902 it connects to the server and the server MUST buffer the 903 notifications and make them available to the MUA when it comes back 904 to the server. 906 For generic server to server notifications, it is assumed that the 907 data in a notification request is important, and therefore a high 908 level of reliability is needed. In such cases it MUST be possible 909 to provide acknowledgment by the target to the messaging system or 910 to repeat notification until such an acknowledgement is provided if 911 supported by the notification channel. Alternatively it must be 912 possible for the messaging system to request such repeats. 914 15. Security Considerations 916 Notifications must be secured (when useful information is sent) and 917 integrity should be checkable. 919 Maes et al [Page 21] Expires October 2007 920 It should be possible to authenticate sender and prevent Denial of 921 Service attack via notifications. 923 16. Normative and Informative References 924 [[ editor's note: split into two sections, update references ]] 926 [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: 927 ABNF", RFC 2234, November 1997. http://www.ietf.org/rfc/rfc2234 929 [ANNOTATEMORE] Daboo, C., "IMAP ANNOTATEMORE Extension", work in 930 progress, draft-daboo-imap-annotatemore-xx, (work in progress). 932 [GSM03.40] GSM 03.40 v7.4.0 Digital cellular telecommunications 933 system (Phase 2+); Technical realization of the Short Message 934 Service (SMS). ETSI 2000 936 [IMAP-DISC] Melnikov, A. "Synchronization operations for 937 disconnected IMAP4 clients", draft-melnikov-imap-disc-06.txt, 938 October 2004. 940 [IMAP-EVENTS] Melnikov, A. " Lemonade Inband Notifications", 941 draft-melnikov-lemonade-imap-events-00.txt, June 17, 2006 943 [IMAPSIEVE] Leiba, B., "Support for Sieve in Internet Message Access 944 Protocol (IMAP4)", draft-ietf-lemonade-imap-sieve-0x (work in 945 progress). 947 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 948 draft-ietf-lemonade-profile-XX.txt, (work in progress). 950 [LEMONADEPROFILEBIS] Maes, S.H., Melnikov A. and D. Cridland, " 951 LEMONADE profile bis", draft-ietf-lemonade-profile-bis-xx.txt, (work 952 in progress). 954 [MANAGESIEVE] Martin, T. and A. Melnikov, "A Protocol for Remotely 955 Managing Sieve Scripts", draft-martin-managesieve-xx.txt, (work in 956 progress). 958 [MSGEVENTS] Newman, C., "Internet Message Store Events", draft- 959 newman-lemonade-msgevent-xx.txt, (work in progress). 961 [NOTIFICATIONPROTOCOL] Maes, S.H., " Lemonade Notification protocol 962 ", draft-ietf-lemonade-notification-protocol-xx.txt, (work in 963 progress). 965 Maes et al [Page 22] Expires October 2007 967 [OMA-EN] Open Mobile Alliance Email Notification Version 1.0, August 968 2002. http://www.openmobilealliance.org/tech/docs/EmailNot/OMA- 969 Push-EMN-V1_0-20020830-C.pdf 971 [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document, 972 (Work in progress). http://www.openmobilealliance.org/ 974 [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 975 (Work in progress). http://www.openmobilealliance.org/ 977 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 978 Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S- 979 M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol 980 (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). 982 [RECONNECT] A. Melnikov, C. Wilson, "IMAP4 Extensions for Quick 983 Reconnect", draft-ietf-lemonade-reconnect-06.txt, May 2006 985 [RFC2177] Leiba, B. "IMAP4 IDLE Command", RFC 2177, June 1997. 986 http://www.ietf.org/rfc/rfc2177. 988 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 989 Version 4 rev1", RFC 3501, March 2003. 990 http://www.ietf.org/rfc/rfc3501 992 [SIEVE] SIEVE WG, http://www.ietf.org/html.charters/sieve- 993 charter.html 995 [SIEVENOTIFICATIONS] Melnikov, A., "Sieve -- An extension for 996 providing instant notifications", draft-ietf-sieve-notify-XX.txt, 997 (work in progress) 999 [URLAUTH] Crispin, M. and Newman, C., "Internet Message Access 1000 Protocol (IMAP) - URLAUTH Extension", draft-ietf-lemonade-urlauth- 1001 XX.txt, (work in progress). 1003 [VFOLDER] Maes, S. and et Al., "Persistent Search Extensions and 1004 Virtual Folder to the IMAP Protocol", draft-maes-lemonade-vfolder- 1005 0x, (work in progress). 1007 [WAPWDP] Wireless Datagram Protocol, Version 14-Jun-2001, Wireless 1008 Application Protocol WAP-259-WDP- 20010614-aWAP (WDP) 1010 17. Future Work 1012 Maes et al [Page 23] Expires October 2007 1014 [1] Complete the specification tasks and editor�s identified in this 1015 document: 1017 * ^Detailed NF specifications (Sieve or no sieve) 1018 * ^NF filter management protocol 1019 * ^Create new MSGEVENTS draft to define mandatory event support, 1020 including new OMA required events like client LOCK_DOWN, or 1021 request the client to re-provision (including encryption keys) 1023 [2] Map MSGEVENTS to mandatory in-band responses 1025 [3] Determine whether CHECKPOINT style inband event queuing is 1026 needed when client is disconnected, or whether [RECONNECT] suffices 1027 (e.g. we may need a lemonade idle event draft) 1029 [4] Possibly update MSGEVENTS, keeping what is necessary, and adding 1030 new ones (e.g. we may need a lemonade event draft starting from 1031 [MSGEVENTS]). 1033 [5] Review and sanitize introduction of server to server 1034 notification and possibly better integrate with structure of the 1035 text. 1037 [6] Better relate and divide text between this draft and 1038 [NOTIFICATIONPROTOCOL] 1040 [7] Reflect decisions on discussions of support of notification of 1041 multiple devices per user. 1043 18. Acknowledgments 1045 The authors want to thank all who have contributed key insight in 1046 notifications and filtering and have authored specifications or 1047 drafts used in this document, including the original work on P-IMAP 1048 [P-IMAP]. 1050 The authors want to thank the authors of the original work on Server 1051 To Server Notification Protocol Requirements (draft-ietf-lemonade- 1052 notify-s2s-00) whose material has been incorporated in the present 1053 document, in particular, Gev Decktor. 1055 19. Authors Addresses 1057 Stephane H. Maes 1058 Oracle Corporation 1059 500 Oracle Parkway 1060 M/S 4op634 1062 Maes et al [Page 24] Expires October 2007 1063 Redwood Shores, CA 94065 1064 USA 1065 Phone: +1-650-607-6296 1066 Email: stephane.maes@oracle.com 1068 Ray Cromwell 1069 Oracle Corporation 1070 500 Oracle Parkway 1071 Redwood Shores, CA 94065 1072 USA 1074 Appendix A: Out-of-band SMS channel binding (INFORMATIVE appendix) 1076 One method for delivering wake-up notifications is by pushing the 1077 notification payload as a binary SMS message. Upon receiving an 1078 SMS, a client would then parse the payload, determine if it is a 1079 email notification or some other SMS message, and process the 1080 message appropriately. 1082 This has the unfortunate side effect of forcing the client to parse 1083 every message trying to sense what kind of message it is. The 1084 proposed mechanism to fix this is to utilize the binary 1086 SMS User Data Header (UDH) to specify a destination port, according 1087 to the Application Port 1089 Addressing Scheme in [GSM03.40] or alternatively, on CDMA networks, 1090 to use the WAP WDP mapping to GSM SMS [WAPWDP]. 1092 Although any port number is usable, it might make sense to use port 1093 143 for consistency, which is the IANA IMAP port. Thus, OMA EMN or 1094 extended format notifications should be sent to port 143 via GSM SMS 1095 or WAP WDP. The client upon receiving the SMS will check the port 1096 number, and if the port is the right port, the message will be 1097 routed to the appropriate client application for processing. 1099 Because such mechanisms are network specific, a server should 1100 determine if a port specific SMS or WAP WDP mapping can be used 1101 based on knowledge of the device / network or on strategies that 1102 determine if the device reacts to such notifications. However, a 1103 client may also declare it / selecting the out-of-band notification 1104 channel as GSMSMS or WAPWDP as for any other notification channel. 1106 Appendix B: Changes from Previous Versions 1108 Maes et al [Page 25] Expires October 2007 1109 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 1111 version -04: 1112 * Update dates, slight reformatting, add editor's note for 1113 References 1115 version -03: 1116 * Updated examples to use new METADATA syntax 1117 * Drop CLEARIDLE and reference A. Melnikov's [IMAP-EVENTS] 1118 * XEMN notification format extended to with event and view 1119 attributes 1120 * View filter is a work in progress. Several proposals are being 1121 discussed, so the draft has been revised to try and capture high 1122 level requirements (e.g. out of band notifications must be able 1123 to identify which view an event occurred for) 1124 * Added notification protocol details and reference 1126 version -02: 1127 * LPROVISION/LGETPREFS/LSETPREFS removed in favor of mailbox 1128 annotations 1129 * Updated inband notification section to include discussion of 1130 [CLEARIDLE] and [MSGEVENTS] 1131 * EMN payload clarified for both wakeup and extended formats. 1132 * Some reference clean-up 1133 * Add server to server notifications based on the expired draft 1134 draft-ietf-lemonade-notify-s2s-00. 1136 version -01: 1137 * Move SMS / WAP examples to an informative appendix. 1138 * Restrict the exchange of keys via LPROVISION to secure 1139 exchanges. 1140 * Differentiate ANNOTATE from LPROVISION on that basis. 1142 versin -00: 1143 * Initial release 1145 Intellectual Property Statement 1147 The IETF takes no position regarding the validity or scope of any 1148 Intellectual Property Rights or other rights that might be claimed 1149 to pertain to the implementation or use of the technology described 1150 in this document or the extent to which any license under such 1151 rights might or might not be available; nor does it represent that 1152 it has made any independent effort to identify any such rights. 1153 Information on the procedures with respect to rights in RFC 1154 documents can be found in BCP 78 and BCP 79. 1156 Maes et al [Page 26] Expires October 2007 1157 Copies of IPR disclosures made to the IETF Secretariat and any 1158 assurances of licenses to be made available, or the result of an 1159 attempt made to obtain a general license or permission for the use 1160 of such proprietary rights by implementers or users of this 1161 specification can be obtained from the IETF on-line IPR repository 1162 at http://www.ietf.org/ipr. 1164 The IETF invites any interested party to bring to its attention any 1165 copyrights, patents or patent applications, or other proprietary 1166 rights that may cover technology that may be required to implement 1167 this standard. Please address the information to the IETF at 1168 ietf-ipr@ietf.org. 1170 Full Copyright Statement 1172 Copyright (C) The IETF Trust (2007). 1174 This document is subject to the rights, licenses and restrictions 1175 contained in BCP 78, and except as set forth therein, the authors 1176 retain all their rights. 1178 This document and the information contained herein are provided on 1179 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1180 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1181 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1182 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1183 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1184 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1185 FOR A PARTICULAR PURPOSE. 1187 Intellectual Property Statement 1189 The IETF takes no position regarding the validity or scope of any 1190 Intellectual Property Rights or other rights that might be claimed 1191 to pertain to the implementation or use of the technology described 1192 in this document or the extent to which any license under such 1193 rights might or might not be available; nor does it represent that 1194 it has made any independent effort to identify any such rights. 1195 Information on the procedures with respect to rights in RFC 1196 documents can be found in BCP 78 and BCP 79. 1198 Maes et al [Page 27] Expires October 2007 1199 Copies of IPR disclosures made to the IETF Secretariat and any 1200 assurances of licenses to be made available, or the result of an 1201 attempt made to obtain a general license or permission for the use 1202 of such proprietary rights by implementers or users of this 1203 specification can be obtained from the IETF on-line IPR repository 1204 at http://www.ietf.org/ipr. 1206 The IETF invites any interested party to bring to its attention any 1207 copyrights, patents or patent applications, or other proprietary 1208 rights that may cover technology that may be required to implement 1209 this standard. Please address the information to the IETF at ietf- 1210 ipr@ietf.org. 1212 Disclaimer of Validity 1214 This document and the information contained herein are provided on 1215 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1216 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1217 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1218 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1219 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1220 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1222 Copyright Statement 1224 Copyright (C) The Internet Society (2006). This document is subject 1225 to the rights, licenses and restrictions contained in BCP 78, and 1226 except as set forth therein, the authors retain all their rights. 1228 Acknowledgement 1230 Funding for the RFC Editor function is currently provided by the 1231 Internet Society. 1233 Maes et al [Page 28] Expires October 2007