Internet DRAFT - draft-maes-lemonade-deliver
draft-maes-lemonade-deliver
<LDELIVER> September 2005
Lemonade
Internet Draft: LDELIVER S. H. Maes
Document: draft-maes-lemonade-deliver-02 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
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
Maes [Page 1]
<LDELIVER> September 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
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
1. Introduction
Maes Expires û March 2006 [Page 2]
<LDELIVER> September 2005
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
LDELIVER via CAPABILITY MUST be compliant to LDELIVER for its
exchanges with the mobile client.
Maes Expires û March 2006 [Page 3]
<LDELIVER> September 2005
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 a new types of message
literal, the delta litera as well as requiring LITERAL+ support for
CATENATE's TEXT 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
handle the two most common use cases: replying and forwarding
messages that contain the original attachments.
Maes Expires û March 2006 [Page 4]
<LDELIVER> September 2005
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
literal+ followed by two pieces of data from a message UID=4321 using
URL statements, 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:
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.
Maes Expires û March 2006 [Page 5]
<LDELIVER> September 2005
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
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
Maes Expires û March 2006 [Page 6]
<LDELIVER> September 2005
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
S: * LDELIVER CAPABILITY (ô8BITMIMEö ôEXPNö ôHELPö)
C: a005 LDELIVER TEXT {123+}
C: EHLO
Maes Expires û March 2006 [Page 7]
<LDELIVER> September 2005
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.
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
Maes Expires û March 2006 [Page 8]
<LDELIVER> September 2005
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
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
Maes Expires û March 2006 [Page 9]
<LDELIVER> September 2005
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
[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.
Maes Expires û March 2006 [Page 10]
<LDELIVER> September 2005
[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
Release 02
Correction in section 5 regarding the message literals introduced
Correction in section 5.1.2 of the description of the first
example.
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
Maes Expires û March 2006 [Page 11]
<LDELIVER> September 2005
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
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
Maes Expires û March 2006 [Page 12]
<LDELIVER> September 2005
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
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
Maes Expires û March 2006 [Page 13]
<LDELIVER> September 2005
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.
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]
