idnits 2.17.00 (12 Aug 2021) /tmp/idnits20726/draft-smaes-lemonade-s2c-notification-reqs-01.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.5 on line 644. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing revision: the document name given in the document, 'draft-smaes-lemonade-s2c-notification-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-smaes-lemonade-s2c-notification-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-smaes-lemonade-s2c-notification-', but the file name used is 'draft-smaes-lemonade-s2c-notification-reqs-01' == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 4) being 60 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 2005) is 6303 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 564, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 565, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 566, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 567, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 572, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 574, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 576, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 577, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 578, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 579, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 580, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-lemonade-notify-s2s (ref. 'LEMONADES2S') -- No information found for draft-maes-lemonade-mobile-email-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MEMAIL' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- No information found for draft-ietf-lemonade-profile-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LEMONADEPROFILE' -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 13 errors (**), 1 flaw (~~), 18 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Lemonade 2 Internet Draft: Lemonade Requirements Server to S. H. Maes 3 Client Notifications 4 Document: draft-smaes-lemonade-s2c-notification- C. Wilson 5 reqs-01 6 Expires: August 2005 February 2005 8 Lemonade Requirements for Server to Client Notifications 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of Section 10 of RFC2026. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes Lemonade requirements for server to client 38 notifications. These server to client notifications provide 39 information on crucial changes to a client. 41 This document does not assume how notifications are provided to the 42 clients: the client to server notifications may be actively pushed to 43 a client through different mechanisms rather than requiring the 44 client to initiate contact to ask for state changes; or they may be 45 polled by the client, still avoiding that the client performs full 46 state comparisons. 48 Conventions used in this document 49 February 2005 51 In examples, "C:" and "S:" indicate lines sent by the client and 52 server respectively. 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 An implementation is not compliant if it fails to satisfy one or more 59 of the MUST or REQUIRED level requirements for the protocol(s) it 60 implements. An implementation that satisfies all the MUST or REQUIRED 61 level and all the SHOULD level requirements for a protocol is said to 62 be "unconditionally compliant" to that protocol; one that satisfies 63 all the MUST level requirements but not all the SHOULD level 64 requirements is said to be "conditionally compliant." When 65 describing the general syntax, some definitions are omitted as they 66 are defined in [RFC3501]. 68 Table of Contents 70 Status of this Memo...............................................1 71 Abstract..........................................................1 72 Conventions used in this document.................................1 73 Table of Contents.................................................2 74 1. Introduction...................................................3 75 2. Use cases for Lemonade Server to Client Notifications..........3 76 2.1. Outband notifications.....................................4 77 2.2. Inband notifications......................................4 78 2.3. Event-based synchronization...............................5 79 2.4. Notification filtering....................................5 80 2.5. Notification buffering or polling.........................5 81 2.6. Changes of notification mechanisms........................5 82 2.7. Changes of filtering......................................5 83 2.8. Notification content......................................5 84 2.9. End-to-end Notification confidentiality...................6 85 2.10. End-to-end Notification reliability......................6 86 2.11. Notification buffering...................................6 87 2.12. Notification from multiple server........................6 88 2.13. Quick re-synchronization.................................6 89 2.14. Notification service provider............................7 90 2.15. Usage patterns...........................................7 91 3. Server to server notifications.................................7 92 3.1. A mobile e-mail use case that releates S2C and S2S........7 93 3.2. Implementation considerations.............................8 94 4. Requirements for Lemonade Client to Server Notifications.......8 95 Security Considerations..........................................11 96 References.......................................................11 97 Version History..................................................11 98 Authors Addresses................................................12 100 February 2005 102 Intellectual Property Statement..................................12 103 Full Copyright Statement.........................................13 105 1. 106 Introduction 108 In this document, we assume clients with limited computing resources 109 and battery life time able to connect to a Lemonade server through a 110 network with constrained or costly bandwidth (e.g. mobile network). 112 The lemonade profile [LEMONADEPROFILE] extends IMAPv4 Rev1 [RFC3501] 113 with optimizations that are especially useful when accessing, 114 manipulating or sending messages from resource and bandwidth 115 constrained clients. 117 Users of wired systems (desktop, laptop) have come to expect a quasi- 118 instantaneous reflection on the client of changes that take place on 119 the mail server. These same users are expecting the same behavior on 120 mobile devices while, at the same time, minimizing bandwidth and 121 power requirements to allow normal client response over a nominal 122 time frame. 124 As a result, server to client notifications are required to support 125 some or all of the following: 126 - avoid unnecessary polling when possible 127 - enable quasi instantaneous client wake up and update when 128 possible 129 - avoid full fledged state comparison by the client as typically 130 performed by IMAP clients. 132 The Lemonade server to client notifications inform the client of 133 changes in an end user's mailbox. 135 Solutions like IMAP IDLE work well over well connected, high 136 bandwidth reliable network. IDLE is however not designed for use over 137 a network with restricted bandwidth where connectivity can often be 138 lost. 140 This document provides requirements for server to client 141 notifications that would be outside the IMAP sessions. 143 Within the scope of IETF Lemonade, such server to client 144 notifications are expected to be exchanged over IP. However, as 145 discussed in [MEMAIL], it is important that mobile e-mail may also 146 rely on notifications outside the IP band. 148 2. 149 Use cases for Lemonade Server to Client Notifications 151 February 2005 153 Use cases are at a very high level. As the work progress more details 154 may be added. These use cases may also expand into additional use 155 cases and requirements for Lemonade Profile. 157 2.1. 158 Outband notifications 160 Permanent connections from the client to the server have an 161 associated cost in battery power which may limit the lifetime of the 162 device beyond the usefulness of the email client. Permanent 163 connections may also be prohibitively expensive as well depending on 164 the network operatorÆs billing structure. 166 In order to preserve battery power and/or limit the cost of 167 connection, it is desirable for a mobile client not to maintain a 168 permanent data connection (IP address, etc...). However, the user 169 expects that his client will reflect changes that take place on the 170 mail server quasi-instantaneously (e.g. new e-mail, deleted e-mail, 171 change of status (read/unread), e-mail move ...). 173 By allowing the mobile device to receive outband notifications over a 174 wireless network (GSM, CDMA, WLAN, à), the client is made aware of 175 the event (i.e. it is awakened). The client can react as determined 176 by its settings (user preferences, client settings ...) by updating 177 its state if it has enough information, or connecting to the server 178 to access the information required to update its state. 180 2.2. 181 Inband notifications 183 Even when a client is always data connected, in order to preserve 184 battery power or to limit the cost of connection, a client (mobile 185 device) limits its requests for changes to the server. Still the user 186 expects that his client will quasi-instantaneously reflect changes 187 that take place on the mail server (e.g. new e-mail, deleted e-mail, 188 change of status (read/unread), e-mail move, ...). 190 With a mechanism for inband notifications, the client can await for 191 server events to request information on changes on the server. The 192 client can react as determined by its settings (user preferences, 193 client settings, ...) by updating its state (if it has enough 194 information) or connect to the server to access the information 195 required to update its state. 197 Such a mechanism should minimize bandwidth requirements and 198 processing requirements on the client. 200 These notifications may be inband to the the IMAP band or within the 201 same data channel but outside the IMAP band (e.g. SIP event 202 notification). 204 February 2005 206 2.3. 207 Event-based synchronization 209 The client spends a significant time during the lifetime of the 210 connection making sure that the server and client are properly 211 synchronized. In order to minimize this cost (bandwidth and 212 processing) a mobile client can avoid full state comparisons by 213 simply collecting all the changes that took place on the server and 214 applying them on the client. These events can be actively sent to the 215 client by the server (notification) or made available to a client 216 that request synchronization with the server. 218 2.4. 219 Notification filtering 221 A user may decide to send the client (mobile device) only 222 notifications related to special events (e.g. e-mail marked urgent or 223 e-mail from a particular sender). 225 Other changes can be kept on the server (delayed notification) and 226 made available during the event-based synchronization that takes 227 place when the client connects to the server. 229 2.5. 230 Notification buffering or polling 232 On a network where notifications may not be reliable, a client may 233 connect to server without having been notified or may not have 234 received all the notifications the server has sent. The server then 235 provides the notifications that have not yet been acted on for the 236 client to perform event-based synchronization. 238 2.6. 239 Changes of notification mechanisms 241 A user may want to be able to change the notification mechanisms to 242 be used: 243 - Outband to a new device address / new device 244 - From inband (when connected) to outband (to save batteries, 245 because of change of network technologies or because of change of 246 cost of bandwidth). 247 - From pushed notifications (inband or outband) to periodic poll. 249 2.7. 250 Changes of filtering 252 While connected, a user may want to be able to change the 253 notification filters to be applied (e.g. to add a user or event for 254 push notification or delayed notification). 256 2.8. 257 Notification content 259 February 2005 261 A server may simply notify that an event took place and invite the 262 client to access the notification details from the server. 264 It may also provide more information about the details of the event 265 in the notification to allow the client, as determined by its 266 settings (user preferences, client settings, ...), to immediately 267 update its state prior to connecting to the server. 269 2.9. 270 End-to-end Notification confidentiality 272 A server that provides notifications with more information about the 273 details of the events must encrypt the notification to preserve 274 confidentiality. 276 2.10. 277 End-to-end Notification reliability 279 Notifications may not be reliable under some conditions (e.g. outband 280 notifications over mobile network or inband notifications lost when 281 connectivity is lost). 283 The server maintains the notifications that have not yet been acted 284 on for the client to perform event-based synchronization. After a 285 certain period of inaction, based on settings or preferences, the 286 server may send (e.g. periodically) an additional notification to 287 prompt the client to access these remaining notifications; until the 288 client acts upon them. 290 Similarly, if no notification was received for a while, and based on 291 settings or preferences, a client may access the server to check for 292 missing notifications stored by the server. 294 2.11. 295 Notification buffering 297 After determining that a client does not react to notifications, the 298 server may stop sending them and solely stored / buffer them on the 299 server. 301 A mechanism as described in the End-to-end Notification reliability 302 use case can be used for the client to eventually receive them. 304 Notification from multiple server 306 A client receives notifications associated to multiple servers / e- 307 mail accounts. 309 2.13. 310 Quick re-synchronization 312 A client receives inband or outband information about the events that 313 have taken place on the server. Using this information, the client 315 February 2005 317 can either update it state (based on the information provided by the 318 notification), decide to wait for further changes or information or 319 decide to contact the server to access more information. 321 In such case, the event payload may contain a significant amount of 322 information of the IMAP state changes. 324 2.14. 325 Notification service provider 327 A client is notified by a notification service provided by a service 328 provider that reacts to events communicates by the e-mail server in 329 an enterprise domain. Confidentiality and integrity of the 330 notifications is maintained. A typical example would be a mobile e- 331 mail service provided by a GSM or CDMA operator that provides client 332 to server notification (and support for Lemonade profile) to 333 enterprise e-mail server and employees. 335 2.15. 336 Usage patterns 338 [MEMAIL] provides examples of deployment models including for 339 notifications. 341 3. 342 Server to server notifications 344 Lemonade is completing work on the requirements for server to server 345 notifications: [LEMONADES2S]. 347 Server to server notifications are supposed to inform other server of 348 typically taking place outside the IMAP band. It is natural to expect 349 them to take place over IP. 351 As such it would be natural to target sharing specifications between 352 S2C and S2S notifications. Indeed, S2S requirements seem to be 353 essentially a subset of the S2C requirements described here, except 354 may be for the nature of the information to exchange. 356 3.1. 357 A mobile e-mail use case that releates S2C and S2S 359 [MEMAIL] introduces deployment models A, B, C.1 and C2. In all cases, 360 there is value to offer a scalable notification mechanisms between 361 the e-mail server and the mobile e-mail enabling server. 363 Deployment models A and B may not require such mechanisms if the two 364 server are implemented as one component. But in general, this is not 365 the case. 367 The notifications passing between the server and the mobile e-mail 368 enabling server are expected to be very similar to the notifications 370 February 2005 372 passed between the mobile enabling server and the client. The 373 difference may be that the server to server notifications may cover 374 multiple e-mail account and describe the details of the e-mail 375 account in the notifications, while the server to client 376 notifications are expected to be limited to a single or few accounts 377 accessed by the clients. 379 Different usage model can be considered: 380 - The mobile e-mail enabling server processes the S2S event, 381 adapts it to the affected client and sends it as a S2C 382 notification to the client 383 - The mobile e-mail enabling server processes the S2S events and 384 access the server to get more information. It then generates, 385 if appropriate, a S2C notification for the affected clients and 386 it sends it to that client. 388 3.2. 389 Implementation considerations 391 Lessons learned from implementation and deployments of such systems 392 server notifications schemes that impose maintaining sessions between 393 the server (e.g. IDLE session per user or device). 395 4. 396 Requirements for Lemonade Client to Server Notifications 398 This section contains a list of requirements for the Lemonade Client 399 to Server Notifications. 401 R-1: Notifications MUST support association to server mail events 402 including: 403 - New incoming e-mail 404 - E-mail status change (read/unread, deleted, ...) 405 - E-mail moved to new folder 406 - New folder 407 - New sent e-mail 409 R-2: Notifications MUST support partial description that an event 410 took place, as decided by server settings or preferences 412 R-3: Notification MAY provide details of the event that took place on 413 the server (i.e. more details than just mentioning that the even took 414 place) 416 R-4: When notifications provide additional details, they MUST support 417 end-to-end confidentiality between server and client 419 R-5: Notification mechanisms MUST be independent of the transport 420 mechanisms 422 February 2005 424 R-6: The server to client notification MUST specify server to client 425 notification payload in ways that are notification transport 426 independent. 428 R-7: Notifications MUST support outband notification mechanisms for 429 clients and networks that support such mechanisms. These include: 430 - SMS 431 - Push (e.g. WAP Push) 432 - MMS 433 - IP (e.g. SIP event notifications) 434 - UDP 435 R-8: Notifications MUST support inband notification mechanisms for 436 clients that are data connected to the network and support pushed 437 notification to the client. 439 R-9: When available, it MUST be possible to use outband notification 440 to wake up clients that are not permanently data connected to the 441 network (e.g. no IP address). 443 R-10: Wake-up notification MUST allow passing additional information 444 about the state of the IMAP server. 446 R-11: Lemonade servers MUST be able to store Notifications that have 447 not yet been acted upon by the client and make them available when 448 the client accesses the server. 450 R-12: A client MUST be able to query for Notifications that have not 451 yet been acted upon by the client. 453 R-13: The overall notification mechanism MUST be end-to-end reliable 454 even if the notification transport / channel may be unreliable (e.g. 455 SMS). 457 R-14: The overall notification mechanism MUST provide event-based 458 synchronization so that the client reflects all changes on the server 459 based on settings / preferences / filtering. 461 R-15: The overall notification mechanisms MUST allow filtering of the 462 notifications pushed to the client versus the notification kept on 463 the server for when the client accesses it. 465 R-16: It MUST be possible to change the notification filtering rules 466 from the client. 468 R-17: It MUST be possible to change the notification mechanisms from 469 the client (e.g. new device, inband, outband, polling, ...) 471 February 2005 473 R-18: The server MUST be able to limit the number of notifications 474 sent to the client within a given time span if the client does not 475 react to them and a certain number of notifications are pending on 476 the server as determined by settings or preferences. 478 R-19: Clients MUST be able, based on settings or preferences, to 479 handle situations where no notification has been received for a 480 certain period of time by accessing the server and checking for 481 notifications that have not been acted upon. 483 R-20: Servers MUST be able, based on settings or preferences, to 484 handle situations where no notification has been acted upon for a 485 certain period of time by periodically trying to notify the client 486 server of pending notifications. 488 R-21: Outband notification MUST support the associated addressing 489 schema of the mobile network. 491 R-22: Notification SHOULD be designed to allow quasi-instantaneous 492 transmission to the client when supported by network and device. 494 R-23: Notifications MUST be designed to minimize bandwidth 495 requirements to convey their intended information. 497 R-24: A client MUST always be able to associate a notification with 498 the correct originating server in order to update its state properly. 500 R-25: Notifications MUST be compatible with firewalls when 501 appropriate. 503 R-26: Notification MUST be confidential when needed. 505 R-27: Proxy deployments MUST be compatible with end-to-end 506 confidential notifications. 508 R-27: All notification mechanisms MUST be designed to minimize 509 processing requirements on the client. 511 R-28: The notification payload MUST be extensible to accommodate S2S 512 information requirements. 514 R-29: It MUST be possible to exchange the S2C notifications between 515 servers. 517 R-30: The notifications MUST be compatible with the presence of 518 intermediaries between the sender and recipient of the notifications. 520 R-31: The notification mechanisms MUST allow not constrain 521 scalability of the server. 523 Security Considerations 525 We have the same security requirements for an in-response, polled and 526 inband connectivity mode as IMAP. 528 For the outband connectivity mode, servers should use encryption 529 methods for notifications if sensitive information is included in the 530 payload of that notification. 532 When an implementation of Lemonade is proxy-based, this may create 533 new security issues. 535 There may be SPAM issues. With the proliferation of SPAM opening 536 notifications to a large user base could bring existing wireless 537 networks to a halt. They may also lead to denial of service attack on 538 client. Mechanisms may be needed to address these issues. 540 References 542 [LEMONADES2S] Decktor, G., ôServer To Server Notification Protocol 543 Requirements", draft-ietf-lemonade-notify-s2s-00.txt, (Work in 544 progress, proposed to WGLC as standard). 546 [MEMAIL] Maes, S.H., ôLemonade and Mobile e-mail", draft-maes- 547 lemonade-mobile-email-xx.txt, (work in progress). 549 [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate 550 Requirement Levels", RFC 2119, March 1997. 551 http://www.ietf.org/rfc/rfc2119 553 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 554 Version 4 rev1", RFC 3501, March 2003. 555 http://www.ietf.org/rfc/rfc3501 557 [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 558 draft-ietf-lemonade-profile-XX.txt, (work in progress). 560 Version History 562 Revision 01: 564 [1] Update of status of document with boiler plate statement. 565 [2] Section 1: addition of scope qualifications and motivations. 566 [3] Section 2: Editorial re-ordering of text from section 1. 567 [4] Section 2.2: Additional details on inband notifications (i.e. 568 within data connection but outside IMAP band). 570 February 2005 572 [5] New section 2.13: Additional requirement on quick re- 573 synchronization. 574 [6] New section 2.15: Additional considerations on mobile e-mail 575 usage patterns. 576 [7] New section 3: Server to server notifications. 577 [8] Section 4: new requirements R-6, R-10 and R-28 to R-31. 578 [9] Updated references 579 [10] Version history 580 [11] Updated copyright section with boiler plate statements. 582 Authors Addresses 583 Stephane H. Maes 584 Oracle Corporation 585 500 Oracle Parkway 586 M/S 4op634 587 Redwood Shores, CA 94065 588 USA 589 Phone: +1-650-607-6296 590 Email: stephane.maes@oracle.com 592 Corby Wilson 593 Enterprise Mobility Systems 594 Nokia 595 503 Martindale Street 596 Suite 610 597 Pittsburgh, PA 15212 598 USA 599 Phone: +1-412-576-5402 600 Email: Corby.Wilson@nokia.com 602 Intellectual Property Statement 604 The IETF takes no position regarding the validity or scope of any 605 intellectual property or other rights that might be claimed to 606 pertain to the implementation or use of the technology described in 607 this document or the extent to which any license under such rights 608 might or might not be available; neither does it represent that it 609 has made any effort to identify any such rights. Information on the 610 IETF's procedures with respect to rights in standards-track and 611 standards-related documentation can be found in BCP-11. Copies of 612 claims of rights made available for publication and any assurances of 613 licenses to be made available, or the result of an attempt made to 614 obtain a general license or permission for the use of such 615 proprietary rights by implementors or users of this specification can 616 be obtained from the IETF Secretariat. 618 The IETF invites any interested party to bring to its attention any 619 copyrights, patents or patent applications, or other proprietary 620 rights which may cover technology that may be required to practice 622 February 2005 624 this standard. Please address the information to the IETF Executive 625 Director. 627 Acknowledgement 629 Funding for the RFC Editor function is currently provided by the 630 Internet Society. 632 Full Copyright Statement 634 Copyright (C) The Internet Society 2004. This document is subject to 635 the rights, licenses and restrictions contained in BCP 78, and except 636 as set forth therein, the authors retain all their rights. 638 This document and the information contained herein are provided on an 639 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 640 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 641 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 642 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 643 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 644 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 646 This document and translations of it may be copied and furnished to 647 others, and derivative works that comment on or otherwise explain it 648 or assist in its implementation may be prepared, copied, published 649 and distributed, in whole or in part, without restriction of any 650 kind, provided that the above copyright notice and this paragraph are 651 included on all such copies and derivative works. However, this 652 document itself may not be modified in any way, such as by removing 653 the copyright notice or references to the Internet Society or other 654 Internet organizations, except as needed for the purpose of 655 developing Internet standards in which case the procedures for 656 copyrights defined in the Internet Standards process must be 657 followed, or as required to translate it into languages other than 658 English. 660 The limited permissions granted above are perpetual and will not be 661 revoked by the Internet Society or its successors or assigns.