                           <LDELIVER>                    September 2005 
 
 
Lemonade                                                                
Internet Draft: LDELIVER                                     S. H. Maes 
Document: draft-maes-lemonade-deliver-01                    R. Cromwell 
                                                              (Editors) 
                                                                        
Expires: March 2006                                      September 2005 
    
    
                                 LDELIVER 
                                      
Status of this Memo 
    
   
   By submitting this Internet-Draft, each author represents that any 
   applicable patent or other IPR claims of which he or she is aware have 
   been or will be disclosed, and any of which he or she becomes aware 
   will be disclosed, in accordance with Section 6 of BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups.  Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
        http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
        http://www.ietf.org/shadow.html. 
    
Abstract 
    
   This draft introduces LDELIVER and LCOMPOSE as a LEMONADE extensions 
   to the IMAPv4 Rev1 protocol [RFC3501] to enable sending email as an 
   IMAP command. It provides simple ways to provide reply and forward 
   without download with a gateway to the email and submit servers as 
   well we as support to send only edit differences to the server. It is 
   complementary to the trio BURL/URLAUTH/CATENATE described in 
   [LEMONADEPROFILE]. 
 
 
Conventions used in this document 
    

Maes                                                          [Page 1] 


                              <LDELIVER>                September 2005 
 
 
   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in [RFC2119]. 
    
   An implementation is not compliant if it fails to satisfy one or more 
   of the MUST or REQUIRED level requirements for the protocol(s) it 
   implements. An implementation that satisfies all the MUST or REQUIRED 
   level and all the SHOULD level requirements for a protocol is said to 
   be "unconditionally compliant" to that protocol; one that satisfies 
   all the MUST level requirements but not all the SHOULD level 
   requirements is said to be "conditionally compliant."  When 
   describing the general syntax, some definitions are omitted as they 
   are defined in [RFC3501].   
 
 
Table of Contents 
          
   Status of this Memo...............................................1 
   Abstract..........................................................1 
   Conventions used in this document.................................1 
   Table of Contents.................................................2 
   1. Introduction...................................................3 
   2. Relation with other E-mail specifications......................3 
   3. Interactions between the Client and Server when supporting 
   LDELIVER..........................................................4 
   4. The CAPABILITY Command.........................................4 
   5. Specification details..........................................4 
      5.1. the LCOMPOSE command......................................4 
         5.1.1. Formal Syntax........................................5 
         5.1.2. Examples.............................................5 
      5.2. IMAPURL extensions........................................6 
      5.3 The LDELIVER command.......................................6 
         5.3.2 Formal Syntax.........................................7 
         5.3.2 Examples..............................................7 
   6. Note on LDELIVER, SMTP and Lemonade Profile....................8 
   Security Considerations...........................................9 
   References.......................................................10 
   Future Work......................................................11 
         TBD........................................................11 
   Version History..................................................11 
   Acknowledgments..................................................11 
   Authors Addresses................................................11 
   Intellectual Property Statement..................................13 
   Full Copyright Statement.........................................14 
    
    
Maes                     Expires û March 2006                 [Page 2] 


                              <LDELIVER>                September 2005 
 
 
1.    Introduction 
    
   LDELIVER defines extensions to the IMAPv4 Rev1 protocol [RFC3501] to 
   enable the efficient composition and transmission of email using IMAP 
   commands. This provides simple ways to provide reply and forward 
   without download complete messages utilizing a gateway to the email 
   and submit servers. 
    
   LDELIVER is not intended to replace SMTP [RFC2821]. Instead it is 
   envisaged as a simple way to implement gateways that support features 
   like reply and forward without downloading complete messages when the 
   email and submit servers may not support the commands described in 
   [LEMONADEPROFILE] to support such capabilities. 
    
   LDELIVER may allow some clients to reduce the amount of protocols 
   supported ports in use, parameters to set or provisioned, or network 
   protocols required. 
    
   All these are important features required in particular to support 
   mobile email use cases [MEMAIL][OMA-ME-RD]: 
   - Forward and reply without download 
   - Ease of provisioning over the air 
   - Ease of manual provisioning 
   - Reduction of resources on the client 
   - Ease of implementation and deployment with existing email and 
     submit servers 
 
    
2.   Relation with other E-mail specifications 
    
   LDELIVER can be seen as a command that allows optimization of IMAP 
   for mobile clients.  
    
   The Lemonade Profile [LEMONADEPROFILE] specifies the Lemonade Pull 
   Model that governs the exchanges among mail servers or between 
   desktop mail client and mail servers. Lemonade investigates adding 
   mobile optimizations for the next version of the profile. 
    
   LDELIVER should be seen as a way to address the issues of mobile 
   optimization and an input to the Lemonade Profile work as an 
   alternative suitable for fast support of forward, reply and edit 
   without download.  
    
   Clients and servers MAY support other Lemonade extensions and 
   behaviors. 
    
   This document assumes that clients MUST be compliant to LDELIVER, if 
   they decide to use LDELIVER. The server that advertises support for 

 
Maes                     Expires û March 2006                 [Page 3] 


                              <LDELIVER>                September 2005 
 
 
   LDELIVER via CAPABILITY MUST be compliant to LDELIVER for its 
   exchanges with the mobile client.  
    
3.   Interactions between the Client and Server when supporting LDELIVER 
    
   A compliant server must support all IMAPv4Rev1 commands from client 
   devices following the syntax defined in [RFC3501].  Thus, a client 
   may issue any existing IMAP commands to the server, and both the 
   server and client must behave as specified in [RFC3501].   
    
    
4.   The CAPABILITY Command 
    
   The CAPABILITY command is defined in [RFC3501], section 6.1.1.  The 
   client sends a CAPABILITY command so it can query the server to find 
   out what commands it supports.  In [RFC3501], the IMAP server is 
   allowed to specify additional capabilities not included in that 
   specification.  A server that supports LDELIVER conforms to that 
   requirement, and MUST list that it supports LDELIVER.   
    
   A server can also enumerate individually the other commands that it 
   supports.  
    
    
   capability_cmd =  tag SP "CAPABILITY"  
   Valid States:  NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT 
   Responses:  REQUIRED untagged response: CAPABILITY 
   Result:  OK - capability completed 
      BAD - command unknown or arguments invalid 
    
   Example: A server that implements LDELIVER.  
      C: a001 CAPABILITY 
      S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE LDELIVER 
      S: a001 OK CAPABILITY completed 
    
5.   Specification details 
 
   The LDELIVER specification proposes two commands. LCOMPOSE which 
   allows messages to be created on the server for later transmission 
   and LDELIVER which allows the previous composed messages to be 
   transmitted via SMTP. It also introduces two new types of message 
   literals, the substituted literal and the delta literal. 
    
5.1.     the LCOMPOSE command 
    
   The LCOMPOSE command is an extension to the IMAP APPEND command and 
   builds on CATENATE which may be used to compose new messages which 
   include parts of other messages that already exist on the server, 
   and/or edit those parts. It also includes a short-cut syntax to 
 
 
Maes                     Expires û March 2006                 [Page 4] 

                              <LDELIVER>                September 2005 
 
 
   handle the two most common use cases: replying and forwarding 
   messages that contain the original attachments. 
    
   The inclusion of other data is handled by the CATENATE URL command 
   and a new literal DTEXT, the delta literal allows parts of other 
   messages to be included and ôpatchedö via a delta encoded literal. 
    
   Servers which support LCOMPOSE MUST support the LITERAL+ extension 
   [RFC2088]  
    
    
5.1.1. Formal Syntax 
    
   append-data =/ ôLCOMPOSEö "(" compose-part *(SP compose-part) ")" 
   compose-part = text-literal / dtext-literal 
   text-literal = "TEXT" SP literal 
   dtext-literal = ôDTEXTö SP astring SP literal 
    
   The astring in dtext-literal represents an IMAPURL pointing to an 
   existing message part to be included and ôpatchedö by the delta 
   encoded literal. The chosen delta encoding is the well known UNIX 
   ôdiff ûeö format. 
    
   The text-literal functions as described in [CATENATE], except that 
   LITERAL+ support is mandated. 
    
    
5.1.2. Examples 
 
   Append a new message in the Drafts folder using 2 literals, one a 
   substituted literal which includes two pieces of data from a message  
   UID=4321 and the second literal simply providing the ending MIME 
   boundary. 
    
      C: A003 APPEND Drafts (\Seen \Draft $MDNSent) LCOMPOSE (TEXT 
   {666+} 
      C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 
      C: From: Fred Foobar <foobar@Blurdybloop.COM> 
      C: Subject: afternoon meeting 
      C: To:   mooch@owatagu.siam.edu 
      C: Message-Id: <B27397-0100000@Blurdybloop.COM> MIME-Version: 1.0  
      C: Content-Type: multipart/mixed; 
      C:               boundary="------------12345678" 
      C: 
      C: --------------12345678 
      C: Content-Type: text/plain; charset=us-ascii 
      C: Content-Transfer-Encoding: 7bit 
      C: 

 
Maes                     Expires û March 2006                 [Page 5] 


                              <LDELIVER>                September 2005 
 
 
      C: Hello Joe, do you think we can meet at 3:30 tomorrow? I 
   reattached a picture of the diagram we need to discuss that Mary sent 
   me. 
      C: 
      C: --------------12345678 
      C: URL ô/Inbox;UIDVALIDITY=9999/;UID=4321;Section=2.MIME}ö 
      C: URL ô/Inbox;UIDVALIDITY=9999/;UID=4321;Section=2}ö 
      C: TEXT {46+} 
      C: 
      C: --------------12345678-- 
      C: ) 
      S: A003 OK [APPENDUID 9999 33] append Completed 
       
   This example shows how a client can efficiently ôeditö an existing 
   message via a delta encoded literal. 
    
      C: A003 APPEND Drafts (\Seen \Draft $MDNSent) LCOMPOSE (TEXT 
   {123+} 
      C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 
      C: From: Fred Foobar <foobar@Blurdybloop.COM> 
      C: Subject: some minor changes  
      C: To:   mooch@owatagu.siam.edu 
      C: Message-Id: <B27397-0100000@Blurdybloop.COM> MIME-Version: 1.0  
      C: Content-Type: text/plain; charset=us-ascii 
      C: 
      C: DTEXT ô/Inbox;UIDVALIDITY=9999/;UID=1234;Section=1ö {456+} 
      C: 3a4,6 
      C: > The trouble with tribbles is that 
      C: > they insert themselves in your 
      C: > files where you least expect it. 
      C: ) 
      S: A003 OK [APPENDUID 9999 33] append Completed 
 
5.2.     IMAPURL extensions 
 
   IMAPURL is hereby modified to support a special section attribute 
   value ô(F)REATTACHö. ôSection=(F)REATTACHö wgucg consists of all 
   multipart/mixed body parts of the original MIME message except for 
   the first text body part. This is used when one wants to include all 
   attachments in a reply/forward, except for the original text. 
   FREATTACH includes even the first text body part. 
 
 
5.3 The LDELIVER command 
     
   After a message has been composed, it can be handed off to a submit 
   server. The mechanism by which it does this is by proxying a batched 
   set of SMTP commands to an SMTP server. LDELIVER is not an active 
   SMTP tunnel, but instead works similarly to [RFC2442] Batch SMTP, by 
 
 
Maes                     Expires û March 2006                 [Page 6] 


                              <LDELIVER>                September 2005 
 
 
   allowing the client to compose a set of SMTP commands to be executed. 
   The major difference is that those commands are not delivered via a 
   special MIME message, but rather LDELIVER is the batch SMTP 
   processor. Moreover, since LDELIVER exposes SMTP extensions that are 
   available, the client need not make any assumptions about which SMTP 
   extensions are available. 
    
   Finally, LDELIVER reuses the LCOMPOSE TEXT and DTEXT literals when 
   building the batch in order to allow inclusion of pre-composed 
   messages or editing of envelope parameters. 
 
5.3.2 Formal Syntax 
 
   ldeliver-cmd = ôLDELIVERö SP (ôCAPABILITYö / text-literal / dtext-
   literal) 
 
5.3.2 Examples 
 
   The following example will pick up the message that was composed in 
   the LCOMPOSE chapter and send it via SMTP 
    
   Example: 
    
   C: a004 LDELIVER CAPABILITY 
   S: * LDELIVER CAPABILITY (ô8BITMIMEö ôEXPNö ôHELPö) 
   C: a005 LDELIVER TEXT {123+} 
   C: EHLO 
   C: MAIL FROM: john@smith.com 
   C: RCPT TO: mooch@owatagu.siam.edu 
   C: DATA 
   C: URL ô/Inbox;UIDVALIDITY=9999/;UID=33;Section=BODYö 
   . 
   S: * LDELIVER SMTP-RESPONSE {321} 
   S: 220 mail.metastructure.net ESMTP 
   S: 250-mail.metastructure.net 
   S: 250-AUTH LOGIN CRAM-MD5 PLAIN 
   S: 250-AUTH=LOGIN CRAM-MD5 PLAIN 
   S: 250-PIPELINING 
   S: 250 8BITMIME 
   S: 250 ok 
   S: 250 ok 
   S: 354 go ahead 
   S: 250 ok 1126337586 qp 28229 
    
   And this example shows on-the-fly inline composition 
    
   Example: 
    
   C: a004 LDELIVER CAPABILITY 
 
 
Maes                     Expires û March 2006                 [Page 7] 


                              <LDELIVER>                September 2005 
 
 
   S: * LDELIVER CAPABILITY (ô8BITMIMEö ôEXPNö ôHELPö) 
   C: a005 LDELIVER TEXT {123+} 
   C: EHLO 
   C: MAIL FROM: john@smith.com 
   C: RCPT TO: mooch@owatagu.siam.edu 
   C: DATA 
   C: TEXT{234+} 
   C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 
   C: From: Fred Foobar <foobar@Blurdybloop.COM> 
   C: Subject: afternoon meeting 
   C: To:   mooch@owatagu.siam.edu 
   C: Message-Id: <B27397-0100000@Blurdybloop.COM> MIME-Version: 1.0  
   C: Content-Type: multipart/mixed; 
   C:               boundary="------------12345678" 
   C: 
   C: --------------12345678 
   C: Content-Type: text/plain; charset=us-ascii 
   C: Content-Transfer-Encoding: 7bit 
   C: 
   C: Hello Joe, do you think we can meet at 3:30 tomorrow? I reattached  
   picture of the diagram we need to discuss that Mary sent me. 
   C: 
   C: --------------12345678 
   C: URL ô/Inbox;UIDVALIDITY=9999/;UID=4321;Section=2.MIME}ö 
   C: URL ô/Inbox;UIDVALIDITY=9999/;UID=4321;Section=2}ö 
   C: TEXT {46+} 
   C: 
   C: --------------12345678ù 
   C:. 
   S: * LDELIVER SMTP-RESPONSE {321} 
   S: 220 mail.metastructure.net ESMTP 
   S: 250-mail.metastructure.net 
   S: 250-AUTH LOGIN CRAM-MD5 PLAIN 
   S: 250-AUTH=LOGIN CRAM-MD5 PLAIN 
   S: 250-PIPELINING 
   S: 250 8BITMIME 
   S: 250 ok 
   S: 250 ok 
   S: 354 go ahead 
   S: 250 ok 1126337586 qp 28229 
    
 
6.   Note on LDELIVER, SMTP and Lemonade Profile 
    
   A server MAY always rather support SMTP instead of LDELIVER. A client 
   MAY then select to rely on SMTP instead of LDELIVER. This of course 
   may reduce the forward / reply without download capabilities that may 
   be available. 
    
 
Maes                     Expires û March 2006                 [Page 8] 


                              <LDELIVER>                September 2005 
 
 
   A server MAY also advertise via capability support for Lemonade 
   Profile [LEMONADEPROFILE] or the subset of commands (see 
   [LEMONADEPROFILE] needed to support forward without download. In such 
   case, the client MAY rely on the Lemonade profile forward without 
   download mechanisms. 
    
   In general, because of mobile device resource constraints, and 
   corporate firewall and security policies, LDELIVER is easier to 
   deploy for mobile devices, than exposing and restricting SMTP 
   services to mobile devices, especially those devices without VPN 
   functionality. 
 
Security Considerations 
    
   The protocol calls for the same security requirements as IMAP and 
   [LEMONADEPROFILE].   
 
   It is also recommended that clients be explicitly registered with the 
   server through separate channels / application. Exchanges should then 
   be paired, encrypted and signed as deemed appropriate by the user and 
   administrators. 
    
   When an implementation is based on gateways, this may create new 
   security issues.   
    
   In some implementations, the client may connect to a proxy that sits 
   in an operator network, but the backend email storage server sits in 
   a separate enterprise network.  The enterprise network is assumed to 
   be secure, but the operator network may not be trusted.  If 
   unencrypted information lies in the operator network, that 
   information is vulnerable to attacks. 
    
   If the LDELIVER server is implemented in the enterprise network, then 
   the proxy on the carrier should be an encrypted SSL pass-through 
   proxy.  The proxy is unaware of the encryption keys and thus cannot 
   encrypt any data.  Without the encryption key, this proxy cannot see 
   any of the information sent from the client, nor can it send any 
   bogus commands to the backend enterprise email server to corrupt the 
   user's mailbox.  The additional cost for this design is that the 
   backend enterprise email server and the client devices must have 
   additional processing to handle this encryption. 
    
   If the LDELIVER server is implemented as a backend IMAP server with 
   additional command processing done on it, there are more complex 
   security issues.  This proxy must be able to send commands to the 
   backend server to accomplish its tasks, as well as read information 
   coming from the backend server.  An attacker thus can send commands 
   to the backend.    This proxy may also send bogus responses back to 
   the client.  Clearly, this setup is not an ideal issue and many 
 
 
Maes                     Expires û March 2006                 [Page 9] 


                              <LDELIVER>                September 2005 
 
 
   complications that make this problem complex to solve.  The 
   suggestion recommended is to rely on encrypted messages to be 
   decrypted at the backend submit server before being sent by it. The 
   key exchange for encryption should not occur through the proxy.  It 
   has to be done through another channel: manually entered by user 
   (e.g. password), or via an HTTP SSL request to the enterprise server.  
    
    
References 
    
   [BURL] Newman, C., "Message Composition", draft-ietf-lemonade-burl-xx 
      (work in progress). 
    
   [CATENATE] Resnick, P. ôIMAP CATENATE Extensionö, draft-ietf-
      lemonade-catenate-xx.txt, March 2005 (work in progress) 
 
   [IMAP-DISC] Austein, R.  "Synchronization Operations For Disconnected 
      Imap4 Clients", IMAP-DISC, November 1994.  
      http://asg.web.cmu.edu/cyrus/rfc/draft-ietf-imap-disc-01.html 
    
   [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", 
      draft-ietf-lemonade-profile-XX.txt, (work in progress). 
    
   [MEMAIL] Maes, S.H., ôLemonade and Mobile e-mail", draft-maes-
      lemonade-mobile-email-xx.txt, (work in progress). 
    
   [OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document, 
      (Work in progress).  http://www.openmobilealliance.org/ 
    
   [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document, 
      (Work in progress).  http://www.openmobilealliance.org/ 
 
   [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 
      Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn 
      S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP 
      Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in 
      progress). 
    
   [RFC2088] Myers, J. ôIMAP non-synchronizing literalsö, RFC2088, 
      January 1997 
      http://www.ietf.org/rfc/rfc2088 
    
   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate 
      Requirement Levels", RFC 2119, March 1997.  
      http://www.ietf.org/rfc/rfc2119 
 
   [RFC2192] Newman, C. ôIMAP URL Schemeö, RFC 2192, September 1997. 
      http://www.faqs.org/rfcs/rfc2192.html 
    
 
Maes                     Expires û March 2006                [Page 10] 


                              <LDELIVER>                September 2005 
 
 
   [RFC2442] Freed, N., Newman, C., Belissent, J. and Hoy, M., "The 
      Batch SMTP Media Type", RFC 2442, November 1998.  
      http://www.ietf.org/rfc/rfc2442.txt?number=2442.  
    
 
   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 
      April 2001. 
    
   [RFC2822] Resnick, P. "Internet Message Format", RFC 2822, April 
      2001.  http://www.ietf.org/rfc/rfc2822 
     
   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 
      Version 4 rev1", RFC 3501, March 2003. 
      http://www.ietf.org/rfc/rfc3501 
    
   [URLAUTH] Cripsin, M. "Internet Message Access Protocol (IMAP) - 
      URLAUTH Extension", draft-ietf-lemonade-urlauth-xx.txt, (work in 
      progress). 
    
     
Future Work 
    
    TBD 
     
Version History 
 
   Release 00 
      Initial release published in June 2005 
    
   Release 01 
      Updated abstract 
      Updated section 5 based on comments received on Lemonade mailing 
   list and from Sun: 
         5.1: New command LCOMPOSE  
         5.2: Updated command LDELIVER 
      Updated section 6 
       
     
Acknowledgments 
 
   The authors want to thank all who have contributed key insight and 
   extensively reviewed and discussed the concepts of LDELIVER and its 
   early introduction as XDELIVER in P-IMAP [P-IMAP]. In particular, we 
   derived the latest designs from comments from C. Newman (Sun) and N. 
   Freed (Sun). 
 
Authors Addresses 
    
   Stephane H. Maes 
 
 
Maes                     Expires û March 2006                [Page 11] 


                              <LDELIVER>                September 2005 
 
 
   Oracle Corporation 
   500 Oracle Parkway 
   M/S 4op634 
   Redwood Shores, CA 94065 
   USA 
   Phone: +1-650-607-6296 
   Email: stephane.maes@oracle.com 
    
   Rafiul Ahad 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
    
   Eugene Chiu 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
    
   Ray Cromwell 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
    
   Jia-der Day 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
    
   Wook-Hyun Jeong 
   Samsung Electronics,CO., LTD 
   416, Maetan-3dong, Yeongtong-gu, 
   Suwon-city, Gyeonggi-do,  
   Korea 442-600 
   Tel: +82-31-279-8289 
   E-mail: wh75.jeong@samsung.com 
    
   Chang Kuang 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
    
   Rodrigo Lima 
   Oracle Corporation 
   500 Oracle Parkway 
 
 
Maes                     Expires û March 2006                [Page 12] 


                              <LDELIVER>                September 2005 
 
 
   Redwood Shores, CA 94065 
   USA 
    
   Gustaf Rosell 
   Sony Ericsson 
   P.O. Box 64 
   SE-164 94 Kista,  
   Sweden 
   Tel: +46 8 508 780 00 
    
   Jean Sini 
   6480 Via Del Oro  
   San Jose, CA 95119 
   USA 
    
   Sung-Mu Son 
   LG Electronics  
   Mobile Communication Technology Research Lab.  
   Tel: +82-31-450-1910 
   E-Mail: sungmus@lge.com 
    
   Fan Xiaohui 
   Product Development Division 
   R&D CENTER 
   CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC) 
   ADD: 53A, Xibianmennei Ave.,Xuanwu District, 
   Beijing,100053  
   China 
   TEL:+86 10 66006688 EXT 3137 
    
   Zhao Lijun 
   CMCC R&D 
   ADD: 53A, Xibianmennei Ave.,Xuanwu District, 
   Beijing,100053  
   China 
   TEL:.8610.66006688.3041 
    
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   intellectual property or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; neither does it represent that it 
   has made any effort to identify any such rights.  Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in BCP-11.  Copies of 
   claims of rights made available for publication and any assurances of 
   licenses to be made available, or the result of an attempt made to 
 
 
Maes                     Expires û March 2006                [Page 13] 


                              <LDELIVER>                September 2005 
 
 
   obtain a general license or permission for the use of such 
   proprietary rights by implementors or users of this specification can 
   be obtained from the IETF Secretariat. 
        
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice 
   this standard.  Please address the information to the IETF Executive 
   Director. 
    
Acknowledgement 
    
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2005). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
    
   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. 
        
   This document and translations of it may be copied and furnished to 
   others, and derivative works that comment on or otherwise explain it 
   or assist in its implementation may be prepared, copied, published 
   and distributed, in whole or in part, without restriction of any 
   kind, provided that the above copyright notice and this paragraph are 
   included on all such copies and derivative works.  However, this 
   document itself may not be modified in any way, such as by removing 
   the copyright notice or references to the Internet Society or other 
   Internet organizations, except as needed for the purpose of 
   developing Internet standards in which case the procedures for 
   copyrights defined in the Internet Standards process must be 
   followed, or as required to translate it into languages other than 
   English. 
        
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns. 
        
    
Maes                     Expires û March 2006                [Page 14]