Internet DRAFT - draft-maes-lemonade-lconvert

draft-maes-lemonade-lconvert



 

Lemonade                                                                
Internet Draft: LCONVERT                                     S. H. Maes 
Document: draft-maes-lemonade-lconvert-01                   R. Cromwell 
                                                              (Editors) 
                                                                        
                                                                        
Expires: January 2006                                         July 2005 
    
    
                                 LCONVERT 
                                      
Status of this Memo 
    
   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026.  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 
    
   LCONVERT defines extensions to the IMAPv4 Rev1 protocol [RFC3501] for 
   optimization in a mobile setting, aimed at allowing adaptation and 
   transcoding of attachments as needed by the client. Conversion 
   (adaptation, transcoding) may be requested by the client and 
   performed by the server on a best effort basis or decided by the 
   server based on its knowledge of the client capabilities, user or 
   administrator preferences or its settings.  
 
Conventions used in this document 
    
   In examples, "C:" and "S:" indicate lines sent by the client and 
   server respectively. 
 
 
Maes                                                          [Page 1] 





                              <LCONVERT>                     July 2005 
 
 
    
   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...................................................2 
   2. Relation with other E-mail specifications......................3 
   3. Interactions between the Client and Server when supporting 
   LCONVERT..........................................................3 
   4. The CAPABILITY Command.........................................4 
   5. LCONVERT BODY and BINARY data item extension...................4 
   6. FETCH response extensions......................................6 
   7. Status responses, Response code extensions.....................6 
   8. Formal Syntax..................................................7 
   Security Considerations...........................................7 
   References........................................................8 
   Normative Appendices..............................................9 
      A. Security Issues for Proxy-Based Implementations.............9 
      B. LCONVERT transcoding parameters............................10 
   Future Work......................................................10 
   Version History..................................................10 
   Acknowledgments..................................................10 
   Authors Addresses................................................11 
   Intellectual Property Statement..................................13 
   Full Copyright Statement.........................................13 
    
    
1.    Introduction 
    
   LCONVERT is based on IMAPv4 Rev1 [RFC3501]. It defines additional 
   enhancements for optimization in a mobile setting: extensions to the 
   IMAPv4 Rev1 protocol [RFC3501] that allows adaptation and transcoding 
 
 
Maes                    Expires û January 2006                [Page 2] 




                              <LCONVERT>                     July 2005 
 
 
   of body parts as needed by the client. Conversion (adaptation, 
   transcoding) may be requested by the client and performed by the 
   server on a best effort basis or decided by the server based on its 
   knowledge of the client capabilities, user or administrator 
   preferences or its settings.  
    
   These are important features required in particular to support mobile 
   email use cases [MEMAIL], [OMA-ME-RD]. 
    
   A server that supports LCONVERT can convert leaf body parts to other 
   formats to be viewed on a mobile device. The client can explicitly 
   request a particular conversion. The server complies on a best effort 
   basis. When not possible, the server determines based on its own 
   strategy (e.g. based on knowledge of the client as discussed 
   hereafter) how to convert. If the server knows the characteristics of 
   the device or can determine them (out of scope of LCONVERT), the 
   attachments can also be optimized for the capabilities of the devices 
   (e.g. form factor of pictures). See discussion in Appendix B. This is 
   a recommended server behavior. 
      
2.   Relation with other E-mail specifications 
    
   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. 
    
   LCONVERT should be seen as a way to address the issues of mobile 
   optimization and an input to the Lemonade Profile work. It addresses 
   the topic of attachment conversions identified by the Lemonade work 
   as critical for mobile email.  
    
   LCONVERT does not address conversion and streaming of media as also 
   identified of interest by lemonade. This has not been identified as 
   relevant to mobile e-mail [MEMAIL] and [OMA-ME-RD]. 
    
   Clients and servers MAY support other Lemonade extensions and 
   behaviors. 
    
   This document assumes that clients MUST be compliant to LCONVERT when 
   it decides to use this extension. The server that claims support of 
   LCONVERT MUST be compliant to LCONVERT for its exchanges with the 
   mobile client.  
    
3.   Interactions between the Client and Server when supporting LCONVERT 
    
   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 
 
 
Maes                    Expires û January 2006                [Page 3] 



                              <LCONVERT>                     July 2005 
 
 
   server and client must behave as specified in [RFC3501].  In 
   addition, the client and server SHOULD support the IMAP Binary 
   specification [RFC3516]. 
 
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 LCONVERT and its requirements 
   MUST list that it supports LCONVERT.   
 
   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 LCONVERT BINARY 
      S: a001 OK CAPABILITY completed 
 
5.   LCONVERT BODY and BINARY data item extension 
    
   LCONVERT is a FETCH extension used to transcode the media type of a 
   leaf MIME part into another media type, and/or the same media type, 
   with different encoding parameters. It adds new options to the 
   section-spec part of the BODY data item, a new FETCH response data 
   item BODYPARTSTRUCTURE, and new response codes. It is also expected 
   to work with IMAP BINARY data item extension, whose grammar is 
   modified as well. 
    
   LCONVERTÆs syntax is modeled after the HEADER.FIELDS syntax in 
   RFC3501, and is generally structured as: 
    
   BODY[section-part.LCONVERT (ômedia typeö ôsubtypeö (parameters))] 
    
   BODY.PEEK[section-part.LCONVERT (ômedia typeö ôsubtypeö 
   (parameters))]<partial> 
    
   BINARY[section-part.LCONVERT (ômedia typeö ôsubtypeö 
   (parameters))]<partial> 
    

 
 
Maes                    Expires û January 2006                [Page 4] 



                              <LCONVERT>                     July 2005 
 
 
   BINARY.PEEK[section-part.LCONVERT (ômedia typeö ôsubtypeö 
   (parameters))]<partial> 
    
   BINARY.SIZE[section-part.LCONVERT (ômedia typeö ôsubtypeö 
   (parameters))]<partial> 
    
    
   Example:  The client fetches body part section 3 in the message with 
   the message sequence number of 2 and asks to have that attachment 
   converted to pdf format.   
    
      C: a001 FETCH 2 BODY[3.LCONVERT (ôAPPLICATIONö ôPDFö)] 
      S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("APPLICATION" "PDF" () NIL  
         NIL "Base64" 2135 NIL NIL NIL) BODY[3] {2135} 
         <the document in .pdf format> 
         ) 
      S: a001 OK FETCH COMPLETED 
 
   Example:  The client requests for conversion of a text/html section 
   as text/plain and asks for a charset of us-ascii.  The server cannot 
   respect the charset request because there are non-us-ascii characters 
   in the html code.  Thus, in the untagged response, the server returns 
   the charset of UTF-8 and utilizes a content transfer encoding capable 
   of representing the full 8-bit range, along with the converted text. 
    
      C: a001 FETCH 2 BODY[3.LCONVERT (ôtextö ôplainö (ôcharsetö ôus-
   asciiö))] 
      S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL  
         NIL "Base64" 2135 181 NIL NIL NIL) BODY[3] {2135} 
           the document in text/plain format 
           ) 
      S: a001 OK FETCH COMPLETED 
 
 
   Example:  The client requests for conversion of a text/html section 
   as text/plain, but only wants 1000 bytes, starting from byte 2001.  
      C: a001 FETCH 2 BODY[3.LCONVERT (ôTEXTö ôPLAINö (ôCHARSETö ôus-
   asciiö))]<2001.1000>  
      S: * 2 FETCH (BODYPARTSTRUCTURE[3] ("TEXT" "PLAIN" () NIL  
         NIL "7bit" 2135 181 NIL NIL NIL) BODY[3]<2001> {135} 
           bytes 2001 - 2135 of the document in text/plain format 
           ) 
      S: a001 OK FETCH COMPLETED 
    
   The server is not required to respect a particular transcoding 
   request or its request parameters, although it MAY try to make a best 
   effort to fulfill that request. Indeed, the server may know a priori 
   information about the client obtained through a different mechanism 
   outside the scope of LCONVERT (e.g. dynamically through device 
 
 
Maes                    Expires û January 2006                [Page 5] 





                              <LCONVERT>                     July 2005 
 
 
   description mechanisms or when the device was associated to the 
   account). These preferences may be used to predefine what conversions 
   are possible. Ideally the client should request the same conversions. 
   In addition, this information may also allow attachment adaptation 
   (e.g. picture form factor) instead of solely format conversion. 
    
6.   FETCH response extensions 
    
   The BODYPARTSTRUCTURE data item is introduced when using the LCONVERT 
   extension.  It follows the exact syntax specified in the [RFC3501] 
   BODYSTRUCTURE data item, but contains information for only the 
   converted part.  All information contained in BODYPARTSTRUCTURE 
   pertains to the state of the part after it is converted, such as the 
   converted mime-type, sub-type, size, or charset.  The client must 
   respect the return values and not assume the conversion request 
   succeeds.  
    
7.   Status responses, Response code extensions 
    
   Some transcodings may require parameters. If a transcoding request is 
   sent for a format which requires parameters, the server can reply 
   with a BAD response. Likewise, malformed mime types may also generate 
   BAD responses.  
    
   If the server is unable to perform the requested conversion because a 
   resource is unavailable (internal error, transcoding service down) 
   than a BAD response should be returned. 
    
   If a request is denied because of an operational error, such as lack 
   of disk space, or because the requested conversion for some reason 
   cannot be performed, and there is no fallback for this particular 
   device (such as the case where a proprietary document format has no 
   existing transcoding implementation, and the server recognizes that 
   the client has no default viewer for it), the server SHOULD return a 
   NO response. 
    
   Otherwise, the server should return an OK response. The client in 
   general can tell from the BODYPARTSTRUCTURE response whether or not 
   its request was honored exactly, but may not know exactly why it 
   different. 
    
   The following extension response codes are provided for OK and NO 
   responses to disambiguate those situations, or warn about possible 
   important data loss. 
    
   INFORMATIONLOSS û the conversion was satisfied for conversion 
   request, but it may have resulted in the loss of important data 
   (primarily of use for loss of text data, since richmedia is often 
   compressed with loss) 
 
 
Maes                    Expires û January 2006                [Page 6] 



                              <LCONVERT>                     July 2005 
 
 
    
   BADPARAMETERS ô(ô lconvert-params ô)ö û the listed parameters were 
   not understood, or could not be honored for the reasons noted in 
   section-text 
    
   SERVEROVERRIDE û the server overrode the request because it 
   determined it could substitute a better one based on preferences, 
   device capability knowledge, or server policy. 
    
8.   Formal Syntax 
    
   The following syntax specification uses the augmented Backus-Naur 
   Form (ABNF) notation as used in [ABNF], and incorporates by reference 
   the Core Rules defined in that document. 
    
      This syntax augments the grammar specified in [RFC3501] and 
   [RFC3516]. 
    
   In the ABNF section-msgtext grammar in section 9 of [RFC3501]. 
   Section-msgtext is hereby amended to read: 
    
   section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list 
   / "TEXT" / ôXCONVERTö SP xconvert-params 
    
      lconvert-params = "(" (media-basic / default-conversion)  [SP "(" 
      transcoding-params ")"] ")" 
    
      transcoding-params  = transcoding-param-name SP transcoding-param-
   value 
      *(SP transcoding-param-name SP transcoding-param-value) 
    
      transcoding-param-name = string 
    
      transcoding-param-value = string 
    
      default-conversion = "NIL" "NIL" 
    
   In the ABNF syntax ôsection-binaryö of [RFC3516], is amended to: 
    
          section-binary =   "[" [section-part [ô.XCONVERTö SP xconvert-
   params] "]" 
    
Security Considerations 
    
   When an implementation is proxy-based, this may create new security 
   issues.  These issues are discussed in detail in Appendix C, because 
   the issues are dependent on the implementation of this protocol 
   rather than inherent to the protocol itself. 
 
 
 
Maes                    Expires û January 2006                [Page 7] 




                              <LCONVERT>                     July 2005 
 
 
   On bandwidth limited mobile networks where users pay per data 
   volumes, spam may become an important issue. It can be mitigated with 
   appropriate filters and server-side spam prevention tools. These are 
   of course outside the scope of LCONVERT. 
 
   It is also recommended that clients be explicitly registered with the 
   server through separate channels / application. Exchanges should then 
   be paired. 
    
    
References 
    
   [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: 
      ABNFö, RFC 2234, November 1997.  
      http://www.ietf.org/rfc/rfc2234 
    
   [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-RD] Open Mobile Alliance Mobile Email Requirement Document, 
      (Work in progress).  http://www.openmobilealliance.org/  
     
   [OMA-STI] Open Mobile Alliance, Standard Transcoding Interface 
      Specification, version 1.0, [Work in progress] 
      (http://member.openmobilealliance.org/ftp/Public_documents/BAC/STI
      /Permanent_documents/OMA-STI-V1_0-20050209-D.zip).  
    
    [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). 
 
   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate 
      Requirement Levels", RFC 2119, March 1997.  
      http://www.ietf.org/rfc/rfc2119 
 
   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 
      Version 4 rev1", RFC 3501, March 2003. 
      http://www.ietf.org/rfc/rfc3501 
    
   [RFC3516] Nerenberg, L. ôIMAP4 Binary Content Extensionö, RFC3516, 
      April 2003. 
      http://www.ietf.org/rfc/rfc3516 
 

 
 
Maes                    Expires û January 2006                [Page 8] 





                              <LCONVERT>                     July 2005 
 
 
Normative Appendices  
 
A.   Security Issues for Proxy-Based Implementations  
    
   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 LCONVERT extensions are all implemented in the enterprise 
   network, then the proxy on the carrier should be an encrypted SSL 
   pass-through proxy.  SSL ensures confidentiality and integrity of the 
   proxied datastream, ensuring that the proxy cannot monitor the 
   content of messages, nor inject commands to modify or corrupt the 
   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 the overhead of SSL. 
    
   If the LCONVERT compliant server is implemented as a backend IMAP 
   server with additional command processing done on the proxy, 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 who 
   compromises the proxy thus can send commands to the backend to change 
   the state of the mail storage, possibly corrupting it.  In addition, 
   it can read responses from the mail server that might contain 
   confidential email information.  This proxy may also send bogus 
   responses back to the client.  Clearly, this setup is not an ideal 
   issue and many complications that make this problem complex to solve.  
   The suggestion recommended is to remedy the problem of unencrypted, 
   untagged FETCH responses that may contain confidential information.  
   Encrypted responses should be used in place of any untagged FETCH 
   responses, which contain encrypted message information to be passed 
   through the proxy on the operator network.  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.  Any other 
   additional server responses containing sensitive information 
   (passwords, etc.) should be encrypted. 
    
   It is beyond the scope of this document to define the implementation 
   of transcoding services. In general, it is recommended that they 
   reside within the same domain as the IMAP server, and are not 
   performed by third party services, which may compromise the privacy 
   of the data being transcoded. 
      
 
 
Maes                    Expires û January 2006                [Page 9] 




                              <LCONVERT>                     July 2005 
 
 
    
B.   LCONVERT transcoding parameters 
     
   LCONVERT servers MAY support additional transcoding parameters for 
   each media type. All LCONVERT compliant servers MUST minimally 
   support recognition of charset for text/* mime types, although they 
   may decline to honor some requests. For media types other than text, 
   it is beyond the scope of this document to define conversion 
   parameters. In general however, LCONVERT compliant servers MAY choose 
   to support additional parameters, and if so, they SHOULD follow the 
   OMA STI 1.0 spec [OMA-STI] adopting the same parameter names as 
   defined in second 5.2.4 and above for the most popular image/*, 
   video/*, and audio/* codecs 
    
   As an example, in section 5.2.6.2 of [OMA-STI], the parameters 
   "width" and "height" are defined. The following example illustrates 
   how these OMA STI parameters MUST be used with LCONVERT. 
    
         C: a001 UID FETCH 100 BINARY[2.LCONVERT (ôIMAGEö ôJPGö (ôWIDTHö 
   ô128ö ôHEIGHTö ô96ö))]  
         S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2] ("IMAGE" "JPG"   
            () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2] {4182}   
            <this part of a document is a rescaled image in JPG format 
   with width=128, height=96.>  
            )  
         S: a001 OK UID FETCH COMPLETED 
     
Future Work 
    
   TBD 
     
Version History 
    
   Release 01 
      Update to re-use the Binary / Fetch mechanisms in answer to SunÆs 
   comments 
    
    
   Release 00 
      Initial release published in June 2005 
     
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].  
    
   The following contributed to the authoring of LCONVERT. 
    
 
 
Maes                    Expires û January 2006               [Page 10] 




                              <LCONVERT>                     July 2005 
 
 
    
Authors Addresses 
    
   Stephane H. Maes 
   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 
    
   Vida Ha 
   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 
 
 
Maes                    Expires û January 2006               [Page 11] 





                              <LCONVERT>                     July 2005 
 
 
    
   Chang Kuang 
   Oracle Corporation 
   500 Oracle Parkway 
   Redwood Shores, CA 94065 
   USA 
    
   Rodrigo Lima 
   Oracle Corporation 
   500 Oracle Parkway 
   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 
   Symbol Technologies 
   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 
    
   Dwayne Bennett 
 
 
Maes                    Expires û January 2006               [Page 12] 





                              <LCONVERT>                     July 2005 
 
 
   Consilient 
   P.O. Box 2172 
   St. John's, NL A1C 6E6 
   Canada 
   Tel: +1 709 576 1706 
   E-mail: bennett@consilient.com 
    
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 
   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. 
        

 
 
Maes                    Expires û January 2006               [Page 13] 





                              <LCONVERT>                     July 2005 
 
 
   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 û January 2006               [Page 14]