draft-ietf-lemonade-mms-mapping-02.txt   draft-ietf-lemonade-mms-mapping-03.txt 
Internet Draft: Mapping Between MMS and Internet Mail R. Gellens Internet Draft: Mapping Between MMS and Internet Mail R. Gellens
Document: draft-ietf-lemonade-mms-mapping-02.txt Qualcomm Document: draft-ietf-lemonade-mms-mapping-03.txt Qualcomm
Expires: May 2005 November 2004 Expires: October 2005 April 2005
Mapping Between the Multimedia Messaging Service (MMS) Mapping Between the Multimedia Messaging Service (MMS)
and Internet Mail and Internet Mail
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed patent or other IPR claims of which I am aware have been disclosed
and any of which I become aware will be disclosed, in accordance and any of which I become aware will be disclosed, in accordance
with RFC 3668 (BCP 79). with RFC 3668 (BCP 79).
skipping to change at line 44 skipping to change at line 45
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The cellular telephone industry has defined a service known as the The cellular telephone industry has defined a service known as the
Multimedia Messaging Service (MMS). This service uses formats and Multimedia Messaging Service (MMS). This service uses formats and
protocols which are similar to, but differ in key ways from those protocols which are similar to, but differ in key ways from those
used in Internet mail. used in Internet mail.
Gellens [Page 1] Expires May 2005 Gellens [Page 1] Expires October 2005
This document specifies how to exchange messages between these two This document specifies how to exchange messages between these two
services, including mapping information elements as used in MMS services, including mapping information elements as used in MMS
X-Mms-* headers as well as delivery and disposition reports, to and X-Mms-* headers as well as delivery and disposition reports, to and
from that used in ESMTP and Internet message headers. from that used in ESMTP and Internet message headers.
Gellens [Page 2] Expires May 2005 Gellens [Page 2] Expires October 2005
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Conventions Used in this Document . . . . . . . . . . . . 4 1.2 Conventions Used in this Document . . . . . . . . . . . . 4
1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 1.4 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 1.5 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6
2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6 2 Mapping Between MMS and Internet Mail . . . . . . . . . . . . 6
skipping to change at line 100 skipping to change at line 101
1.1 Scope 1.1 Scope
This document describes how to exchange messages with Internet mail This document describes how to exchange messages with Internet mail
systems. This includes translation between MMS (as defined by systems. This includes translation between MMS (as defined by
3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple 3GPP/3GPP2/OMA) and Internet Mail messages using Extended Simple
Mail Transfer Protocol [SMTP] and Internet message format [Msg-Fmt]. Mail Transfer Protocol [SMTP] and Internet message format [Msg-Fmt].
This also includes translation between delivery and disposition This also includes translation between delivery and disposition
reports as used in MMS and in Internet mail ([DSN-Msg] and [MDN]). reports as used in MMS and in Internet mail ([DSN-Msg] and [MDN]).
Gellens [Page 3] Expires May 2005 Gellens [Page 3] Expires October 2005
The MMS architecture [Stage_2] and specifications [Stage_3] refer to The MMS architecture [Stage_2] and specifications [Stage_3] refer to
interfaces as reference points named MMx. For example, MM1 is the interfaces as reference points named MMx. For example, MM1 is the
client-server interface, MM4 is the server-server interface, and MM3 client-server interface, MM4 is the server-server interface, and MM3
is an interface to "external" or non-MMS systems. The specification is an interface to "external" or non-MMS systems. The specification
in this document can be used for message exchange between any system in this document can be used for message exchange between any system
which uses Internet Message formats and protocols and an MMS system; which uses Internet Message formats and protocols and an MMS system;
from the perspective of the MMS system, reference point MM3 is used. from the perspective of the MMS system, reference point MM3 is used.
This document includes support for voice messages specified by the This document includes support for voice messages specified by the
Voice Profile for Internet Mail [VPIM]. The VPIM specification Voice Profile for Internet Mail [VPIM]. The VPIM specification
skipping to change at line 132 skipping to change at line 133
or sub-interfaces of MM3; it is only concerned with Internet mail or sub-interfaces of MM3; it is only concerned with Internet mail
interworking and specifically exchange of messages. interworking and specifically exchange of messages.
All MM3 Stage 2 [Stage_2] functions are supported except for reply All MM3 Stage 2 [Stage_2] functions are supported except for reply
charging and sender address hiding, which may be addressed in future charging and sender address hiding, which may be addressed in future
extensions. extensions.
1.2 Conventions Used in this Document 1.2 Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and NOT", and "MAY" in this document are to be interpreted as described
"MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels" in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS]. [KEYWORDS].
Note that in the text of this document, a distinction is made Note that in the text of this document, a distinction is made
between use of "SMTP" or "Simple Mail Transfer Protocol", and between use of "SMTP" or "Simple Mail Transfer Protocol", and
"ESMTP" or "Extended Simple Mail Transfer Protocol": when the term "ESMTP" or "Extended Simple Mail Transfer Protocol": when the term
"ESMTP" or "Extended" is used, it indicates use of extended features "ESMTP" or "Extended" is used, it indicates use of extended features
of SMTP; that is, those beyond the facilities of RFC 821. (These of SMTP; that is, those beyond the facilities of RFC 821. (These
extended facilities may be in RFC 2821 or in other RFCs, as extended facilities may be in RFC 2821 or in other RFCs, as
indicated by the specific RFC reference used; note that the name of indicated by the specific RFC reference used; note that the name of
the RFC 2821 reference is "SMTP" because that is the official title the RFC 2821 reference is "SMTP" because that is the official title
of the RFC.) of the RFC.)
Gellens [Page 4] Expires May 2005 Gellens [Page 4] Expires October 2005
1.3 Definitions 1.3 Definitions
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Anonymous Remailer |A service which accepts messages and resends Anonymous Remailer |A service which accepts messages and resends
|them to their intended recipient, masking |them to their intended recipient, masking
|information about the original sender. |information about the original sender.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Body |The portion of an SMTP message's Content Body |The portion of an SMTP message's Content
|following the Header (that is, following the |following the Header (that is, following the
skipping to change at line 193 skipping to change at line 193
|(such as "To:"), also known as Header Fields |(such as "To:"), also known as Header Fields
|or Headers. The message Header contains |or Headers. The message Header contains
|information used by User Agents. |information used by User Agents.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gateway Function |An agent which acts as both MMSC and MTA Gateway Function |An agent which acts as both MMSC and MTA
|and/or MSA. |and/or MSA.
--------------------|---------------------------------------------- --------------------|----------------------------------------------
User Agent |An MMS or Email user agent User Agent |An MMS or Email user agent
--------------------|---------------------------------------------- --------------------|----------------------------------------------
Gellens [Page 5] Expires May 2005 Gellens [Page 5] Expires October 2005
1.4 Abbreviations 1.4 Abbreviations
--------|---------------------------------------------------------- --------|----------------------------------------------------------
ESMTP |Extended Simple Mail Transfer Protocol. The use of ESMTP |Extended Simple Mail Transfer Protocol. The use of
|features and capabilities added to SMTP since RFC 821. |features and capabilities added to SMTP since RFC 821.
--------|---------------------------------------------------------- --------|----------------------------------------------------------
MSA |Message Submission Agent. A server which accepts messages MSA |Message Submission Agent. A server which accepts messages
|from User Agents and processes them; either delivering |from User Agents and processes them; either delivering
|them locally or relaying to an MTA. |them locally or relaying to an MTA.
skipping to change at line 241 skipping to change at line 241
When sending a message to an Internet mail system the MMS When sending a message to an Internet mail system the MMS
Relay/Server MUST convert the MM if required, and MUST comply with Relay/Server MUST convert the MM if required, and MUST comply with
the requirements of [SMTP] (for example, use of a null return-path the requirements of [SMTP] (for example, use of a null return-path
for automatically-generated messages). for automatically-generated messages).
The MMS Relay/Server SHOULD use the information elements associated The MMS Relay/Server SHOULD use the information elements associated
with the MM to define the control information (Internet Message with the MM to define the control information (Internet Message
header fields and ESMTP values) needed for the transfer protocol. header fields and ESMTP values) needed for the transfer protocol.
Gellens [Page 6] Expires May 2005 Gellens [Page 6] Expires October 2005
Section 2.1.3 lists the mappings between X-Mms-* headers and Section 2.1.3 lists the mappings between X-Mms-* headers and
Internet Message header fields and ESMTP values. Internet Message header fields and ESMTP values.
Delivery and read report MMs SHOULD be converted to standard Delivery and read report MMs SHOULD be converted to standard
Internet Message report format (multipart/report). In addition to Internet Message report format (multipart/report). In addition to
converting Internet Message reports, the MMS Relay/Server MUST converting Internet Message reports, the MMS Relay/Server MUST
generate delivery and read report MMs for received messages as generate delivery and read report MMs for received messages as
appropriate. See section 2.1.4 for more information. appropriate. See section 2.1.4 for more information.
2.1.2 Internet Mail to MMS 2.1.2 Internet Mail to MMS
skipping to change at line 271 skipping to change at line 271
Section 2.1.3 lists the mappings between X-Mms-* headers and Section 2.1.3 lists the mappings between X-Mms-* headers and
Internet Message header fields and ESMTP values. Internet Message header fields and ESMTP values.
Standard Internet Message report format (multipart/report) messages Standard Internet Message report format (multipart/report) messages
MAY be converted to delivery or read report MMs, as appropriate. In MAY be converted to delivery or read report MMs, as appropriate. In
addition to converting report MMs, the MMS Relay/Server MUST addition to converting report MMs, the MMS Relay/Server MUST
generate standard Internet Message delivery and disposition reports generate standard Internet Message delivery and disposition reports
for received Internet messages as appropriate. See section 2.1.4 for received Internet messages as appropriate. See section 2.1.4
for more information. for more information.
Gellens [Page 7] Expires May 2005 Gellens [Page 7] Expires October 2005
2.1.3 MMS Information Element Mappings 2.1.3 MMS Information Element Mappings
The mappings between MMS elements and ESMTP/Internet Message The mappings between MMS elements and ESMTP/Internet Message
elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are elements (either [SMTP] parameters, [Msg-Fmt] headers, or both) are
summarized in the table below, and detailed in subsequent sections. summarized in the table below, and detailed in subsequent sections.
The "MMS Headers" are from [OMA-MMS]. Note that only information The "MMS Headers" are from [OMA-MMS]. Note that only information
elements which need to be mapped are listed. [Ms elements which need to be mapped are listed. [Msg-Fmt] headers not
g-Fmt] headers not
listed here SHOULD be passed unaltered listed here SHOULD be passed unaltered
2.1.3.1 Table 1: MM3 Mappings 2.1.3.1 Table 1: MM3 Mappings
=================|=================|================|============== =================|=================|================|==============
Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header Information Elem |[SMTP] Element |[Msg-Fmt] Header|MMS Header
=================|=================|================|============== =================|=================|================|==============
3GPP MMS Version |N/A |N/A |X-Mms-Version: 3GPP MMS Version |N/A |N/A |X-Mms-Version:
| | | | | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
skipping to change at line 321 skipping to change at line 320
|generated MMs | | |generated MMs | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Content type |N/A |Content-Type: |Content-type: Content type |N/A |Content-Type: |Content-type:
| | | | | |
| |For voice mes- | | |For voice mes- |
| |sages compliant | | |sages compliant |
| |to [VPIM], see | | |to [VPIM], see |
| |Note 2 | | |Note 2 |
=================|=================|================|============== =================|=================|================|==============
Gellens [Page 8] Expires May 2005 Gellens [Page 8] Expires October 2005
=================|=================|================|============== =================|=================|================|==============
Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header
=================|=================|================|============== =================|=================|================|==============
Message class |Class=auto: |MAY set 'Prece |X-Mms-Message- Message class |Class=auto: |MAY set 'Prece |X-Mms-Message-
|MUST set MAIL | dence: bulk' | Class: |MUST set MAIL | dence: bulk' | Class:
|FROM to null |on class=auto | |FROM to null |on class=auto |
|("<>"). | | |("<>"). | |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Date and time |N/A |Date: |Date: Date and time |N/A |Date: |Date:
of submission | | | of submission | | |
skipping to change at line 371 skipping to change at line 370
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging- permission |supported) |supported) | Charging-
deadline | | | Deadline: deadline | | | Deadline:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
permission |supported) |supported) | Charging- permission |supported) |supported) | Charging-
limitation | | | Size: limitation | | | Size:
=================|=================|================|============== =================|=================|================|==============
Gellens [Page 9] Expires May 2005 Gellens [Page 9] Expires October 2005
=================|=================|================|============== =================|=================|================|==============
Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header Information Elem |RFC 2821 Element |RFC 2822 Header |MMS Header
=================|=================|================|============== =================|=================|================|==============
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
usage request |supported) |supported) | Charging- usage request |supported) |supported) | Charging-
| | | Id: | | | Id:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Reply-charging |(not currently |(not currently |X-Mms-Reply- Reply-charging |(not currently |(not currently |X-Mms-Reply-
usage reference |supported) |supported) | Charging: usage reference |supported) |supported) | Charging:
_________________|_________________|________________|______________ _________________|_________________|________________|______________
skipping to change at line 403 skipping to change at line 402
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Hop/host trace |N/A |Received: |(Not sup- Hop/host trace |N/A |Received: |(Not sup-
| | |ported) | | |ported)
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Sensitivity |N/A |Sensitivity: see|N/A Sensitivity |N/A |Sensitivity: see|N/A
| |Note 1 | | |Note 1 |
_________________|_________________|________________|______________ _________________|_________________|________________|______________
Content |N/A |<message body> |<message body> Content |N/A |<message body> |<message body>
=================|=================|================|============== =================|=================|================|==============
Note 1: The [VPIM] 'Sensitivity' header element i Note 1: The [VPIM] 'Sensitivity' header element indicates the
ndicates the
privacy requested by the message originator (values are "personal" privacy requested by the message originator (values are "personal"
or "private"); a message recipient MUST NOT forward a message with a or "private"); a message recipient MUST NOT forward a message with a
'Sensitivity' header. 'Sensitivity' header.
Note 2: A MIME-Version header with a comment of "Voice 2.0" Note 2: A MIME-Version header with a comment of "Voice 2.0"
indicates that the voice message conforms to [VPIM]. indicates that the voice message conforms to [VPIM].
2.1.3.2 Conversion of messages from MMS to Internet format 2.1.3.2 Conversion of messages from MMS to Internet format
3GPP MMS Version 3GPP MMS Version
The 'X-Mms-Version:' header, if present, SHOULD be removed. The 'X-Mms-Version:' header, if present, SHOULD be removed.
Gellens [Page 10] Expires May 2005 Gellens [Page 10] Expires October 2005
Message Type (of PDU) Message Type (of PDU)
The 'X-Mms-Message-Type:' header, if present, SHOULD be removed. The 'X-Mms-Message-Type:' header, if present, SHOULD be removed.
Transaction ID Transaction ID
The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed. The 'X-Mms-Transaction-Id:' header, if present, SHOULD be removed.
Message ID Message ID
skipping to change at line 467 skipping to change at line 465
characters, but in the absence of such an extension [Hdr-Enc] MUST characters, but in the absence of such an extension [Hdr-Enc] MUST
be used. be used.
Sender address Sender address
The address of the message sender SHOULD appear in the 'From:' The address of the message sender SHOULD appear in the 'From:'
header, unless address hiding has been requested. If address hiding header, unless address hiding has been requested. If address hiding
has been requested, the 'From:' header MAY contain a comment to this has been requested, the 'From:' header MAY contain a comment to this
effect, for example, 'From: (anonymous sender)'. effect, for example, 'From: (anonymous sender)'.
Gellens [Page 11] Expires May 2005 Gellens [Page 11] Expires October 2005
The address of the message sender for all user-generated messages The address of the message sender for all user-generated messages
('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP ('X-Mms-Message-Class: Personal') SHOULD be transmitted in the SMTP
envelope as the MAIL FROM value unless address hiding has been envelope as the MAIL FROM value unless address hiding has been
requested and the receiving server is not known and trusted to requested and the receiving server is not known and trusted to
support address hiding. support address hiding.
The 'From:' header and the MAIL FROM value MAY be set to a The 'From:' header and the MAIL FROM value MAY be set to a
locally-generated value to hide the sender identity in anonymous locally-generated value to hide the sender identity in anonymous
messages when the receiving system does not support anonymous messages when the receiving system does not support anonymous
messages. Locally generated addresses MAY be internally mapped to messages. Locally generated addresses MAY be internally mapped to
skipping to change at line 515 skipping to change at line 513
conversion is done, the 'Content-Type:' header MUST be updated if it conversion is done, the 'Content-Type:' header MUST be updated if it
is no longer correct. is no longer correct.
Message class Message class
The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence: The 'X-Mms-Message-Class:' header MAY be retained. A 'Precedence:
bulk' header MAY be inserted for class=auto or class=advertisement. bulk' header MAY be inserted for class=auto or class=advertisement.
See 'Sender Address' above. (Class=personal and class=informational See 'Sender Address' above. (Class=personal and class=informational
do not require special handling.) do not require special handling.)
Gellens [Page 12] Expires May 2005 Gellens [Page 12] Expires October 2005
Time of Expiry Time of Expiry
The 'X-Mms-Expiry:' header, if present, SHOULD be removed. The 'X-Mms-Expiry:' header, if present, SHOULD be removed.
The remaining time until the message is considered expired SHOULD be The remaining time until the message is considered expired SHOULD be
transmitted in the ESMTP envelope by using the DELIVER-BY extension, transmitted in the ESMTP envelope by using the DELIVER-BY extension,
as specified in [Deliver-By]. as specified in [Deliver-By].
Note that the ESMTP DELIVER-BY extension carries time remaining Note that the ESMTP DELIVER-BY extension carries time remaining
until expiration; each server decrements the value by the amount of until expiration; each server decrements the value by the amount of
skipping to change at line 563 skipping to change at line 561
be transmitted using an 'Importance:' header (although currently not be transmitted using an 'Importance:' header (although currently not
all Internet mail clients support this header). all Internet mail clients support this header).
An 'X-Priority:' header MAY be used in addition. Although not An 'X-Priority:' header MAY be used in addition. Although not
standardized, most email applications support the 'X-Priority:' standardized, most email applications support the 'X-Priority:'
header, and use an 'X-Priority' value of 3 for messages with header, and use an 'X-Priority' value of 3 for messages with
"normal" priority. More important messages have lower values and "normal" priority. More important messages have lower values and
less important message have higher values. In most cases, urgent less important message have higher values. In most cases, urgent
messages have an X-Priority value of 1. messages have an X-Priority value of 1.
Gellens [Page 13] Expires May 2005 Gellens [Page 13] Expires October 2005
Suggested mappings: Suggested mappings:
2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message) 2.1.3.2.1 Table 2: Importance Mappings (MMS to Internet Message)
---------------------------|------------------ ---------------------------|------------------
'X-Mms-Priority: High' |'Importance: High' 'X-Mms-Priority: High' |'Importance: High'
---------------------------|------------------ ---------------------------|------------------
'X-Mms-Priority: Normal' |[omit] 'X-Mms-Priority: Normal' |[omit]
---------------------------|----------------- ---------------------------|------------------
-
'X-Mms-Priority: Low' |'Importance: Low' 'X-Mms-Priority: Low' |'Importance: Low'
---------------------------|------------------ ---------------------------|------------------
Normal priority messages should omit the 'Importance:' header. Normal priority messages should omit the 'Importance:' header.
2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message) 2.1.3.2.2 Table 3: X-Priority Mappings (MMS to Internet Message)
---------------------------|---------------------- ---------------------------|----------------------
'X-Mms-Priority: High' |'X-Priority: 2 (high)' 'X-Mms-Priority: High' |'X-Priority: 2 (high)'
---------------------------|---------------------- ---------------------------|----------------------
skipping to change at line 615 skipping to change at line 612
The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed. The 'X-Mms-Read-Reply:' header, if present, SHOULD be removed.
Reply-charging Reply-charging
Reply charging permission and acceptance are complex issues Reply charging permission and acceptance are complex issues
requiring both user agent and server support. Misapplied reply requiring both user agent and server support. Misapplied reply
charging may cause incorrect billing. Until the security issues charging may cause incorrect billing. Until the security issues
have been properly addressed, reply charging SHOULD NOT be honored have been properly addressed, reply charging SHOULD NOT be honored
Gellens [Page 14] Expires May 2005 Gellens [Page 14] Expires October 2005
when using this interface. when using this interface.
The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:', The 'X-Mms-Reply-Charging:', 'X-Mms-Reply-Charging-Deadline:',
'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers 'X-Mms-Reply-Charging-Size:', and 'X-Mms-Reply-Charging-Id:' headers
MAY be removed. Messages containing a reply-charging usage request MAY be removed. Messages containing a reply-charging usage request
('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or ('X-Mms-Reply-Charging-Id:' and 'X-Mms-Reply-Charging: accepted' or
'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be 'X-Mms-Reply-Charging: accepted (text only)' headers) SHOULD be
rejected. rejected.
Subject Subject
skipping to change at line 663 skipping to change at line 660
addition of 'Resent-' headers to explain the resending to the new addition of 'Resent-' headers to explain the resending to the new
recipient. recipient.
A message may be resent more than once; each time new 'Resent-' A message may be resent more than once; each time new 'Resent-'
headers SHOULD be added at the top of the message. Thus, if more headers SHOULD be added at the top of the message. Thus, if more
than one series of 'Resent-' headers are present, the original than one series of 'Resent-' headers are present, the original
series is the last; the most recent is the first. series is the last; the most recent is the first.
Forward counter Forward counter
Gellens [Page 15] Expires May 2005 Gellens [Page 15] Expires October 2005
The 'Resent-Count:' header MAY be used to track the number of times The 'Resent-Count:' header MAY be used to track the number of times
the message has been resent. Note that loop control is often done the message has been resent. Note that loop control is often done
by counting 'Received' headers, which are more general than by counting 'Received' headers, which are more general than
'Resent-' headers. 'Resent-' headers.
Previously-sent Information Previously-sent Information
A 'Resent-From:' header MAY be added to indicate the address of the A 'Resent-From:' header MAY be added to indicate the address of the
user who directed the message to be resent. user who directed the message to be resent.
skipping to change at line 714 skipping to change at line 711
The message content appears in the message body. Note that Internet The message content appears in the message body. Note that Internet
message format requires that line-endings be encoded as CR LF, thus message format requires that line-endings be encoded as CR LF, thus
charset encodings that do not have this property cannot be used in charset encodings that do not have this property cannot be used in
text/* body parts. (They MAY be used in other body parts, but only text/* body parts. (They MAY be used in other body parts, but only
when they are suitable encoded or when binary transmission has been when they are suitable encoded or when binary transmission has been
negotiated.) In particular, MMS allows UTF-16, while Internet negotiated.) In particular, MMS allows UTF-16, while Internet
message format does not. UTF-16 encoding MUST be translated to message format does not. UTF-16 encoding MUST be translated to
UTF-8 or another charset and encoding which is suitable for use in UTF-8 or another charset and encoding which is suitable for use in
Internet message format/protocols. Internet message format/protocols.
Gellens [Page 16] Expires May 2005 Gellens [Page 16] Expires October 2005
2.1.3.3 Conversion of messages from Internet to MMS format 2.1.3.3 Conversion of messages from Internet to MMS format
3GPP MMS Version 3GPP MMS Version
An 'X-Mms-Mms-Version:' header SHOULD be added. An 'X-Mms-Mms-Version:' header SHOULD be added.
Message Type (of PDU) Message Type (of PDU)
An 'X-Mms-Message-Type:' header SHOULD be used in accordance with An 'X-Mms-Message-Type:' header SHOULD be used in accordance with
skipping to change at line 762 skipping to change at line 759
The 'From:' header MUST be retained. The 'From:' header MUST be retained.
Content type Content type
The complete 'Content-Type:' header (including any parameters) The complete 'Content-Type:' header (including any parameters)
SHOULD be preserved. SHOULD be preserved.
Message class Message class
Gellens [Page 17] Expires May 2005 Gellens [Page 17] Expires October 2005
An X-Mms-Message-Class: personal' header SHOULD be created for all An X-Mms-Message-Class: personal' header SHOULD be created for all
received messages with a non-null return path (MAIL FROM value in received messages with a non-null return path (MAIL FROM value in
the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be the SMTP envelope). An X-Mms-Message-Class: auto' header MAY be
created for messages with a null return path. created for messages with a null return path.
Time of Expiry Time of Expiry
An 'x-Mms-Expiry:' header SHOULD be created if the message contains An 'x-Mms-Expiry:' header SHOULD be created if the message contains
a relative time to expiration in the DELIVER-BY extension, as a relative time to expiration in the DELIVER-BY extension, as
specified in [Deliver-By]. specified in [Deliver-By].
skipping to change at line 813 skipping to change at line 810
-------------------------------|---------------------- -------------------------------|----------------------
'X-Priority: 2 (high)' |'X-Mms-Priority: High' 'X-Priority: 2 (high)' |'X-Mms-Priority: High'
-------------------------------|---------------------- -------------------------------|----------------------
'Importance: High' |'X-Mms-Priority: High' 'Importance: High' |'X-Mms-Priority: High'
-------------------------------|---------------------- -------------------------------|----------------------
'X-Priority: 3 (normal)' | [omitted] 'X-Priority: 3 (normal)' | [omitted]
-------------------------------|---------------------- -------------------------------|----------------------
'Importance: Normal' | [omitted] 'Importance: Normal' | [omitted]
-------------------------------|---------------------- -------------------------------|----------------------
Gellens [Page 18] Expires May 2005 Gellens [Page 18] Expires October 2005
'X-Priority: 4 (low)' |'X-Mms-Priority: Low' 'X-Priority: 4 (low)' |'X-Mms-Priority: Low'
-------------------------------|---------------------- -------------------------------|----------------------
'Importance: Low' |'X-Mms-Priority: Low' 'Importance: Low' |'X-Mms-Priority: Low'
-------------------------------|---------------------- -------------------------------|----------------------
'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low' 'X-Priority: 5 (lowest)' |'X-Mms-Priority: Low'
-------------------------------|---------------------- -------------------------------|----------------------
Normal priority messages SHOULD omit the 'X-Mms-Priority:' header. Normal priority messages SHOULD omit the 'X-Mms-Priority:' header.
Sender visibility Sender visibility
skipping to change at line 861 skipping to change at line 858
The 'Sensitivity:' header field (value = "personal" or "private") The 'Sensitivity:' header field (value = "personal" or "private")
[VPIM] indicates the desire of a voice message originator to send [VPIM] indicates the desire of a voice message originator to send
the message contents to the original recipient list with assurance the message contents to the original recipient list with assurance
that the message will not be forwarded further by either the that the message will not be forwarded further by either the
messaging system or the actual message recipient(s). Since messaging system or the actual message recipient(s). Since
sensitivity is not an MMS feature, any messages which contain a sensitivity is not an MMS feature, any messages which contain a
'Sensitivity:' header SHOULD NOT be sent to an MMS system. An 'Sensitivity:' header SHOULD NOT be sent to an MMS system. An
appropriate extended error response code [RESP] SHOULD be used in appropriate extended error response code [RESP] SHOULD be used in
the associated negative delivery status report. the associated negative delivery status report.
Gellens [Page 19] Expires May 2005 Gellens [Page 19] Expires October 2005
Content Content
The message content appears in the message body. The message content appears in the message body.
2.1.4 Report Generation and Conversion 2.1.4 Report Generation and Conversion
Internet Message systems use the multipart/report MIME type for Internet Message systems use the multipart/report MIME type for
delivery and disposition reports (often called "read reports") as delivery and disposition reports (often called "read reports") as
specified in [Report-Fmt]. This format is a two- or three-part MIME specified in [Report-Fmt]. This format is a two- or three-part MIME
message; one part is a structured format describing the event being message; one part is a structured format describing the event being
skipping to change at line 907 skipping to change at line 904
This text may include a statement that the report was synthesized This text may include a statement that the report was synthesized
based on an MMS report. The second subpart is of type based on an MMS report. The second subpart is of type
report/delivery-status (for delivery reports) or report/delivery-status (for delivery reports) or
report/disposition-notification (for disposition reports). This report/disposition-notification (for disposition reports). This
second part contains a structured itemization of the event. The second part contains a structured itemization of the event. The
third subpart is of type message/rfc822 and includes the headers and third subpart is of type message/rfc822 and includes the headers and
optionally the body of the referenced (original) message. optionally the body of the referenced (original) message.
2.1.4.1 Delivery Report Mapping from MMS to Internet Message 2.1.4.1 Delivery Report Mapping from MMS to Internet Message
Gellens [Page 20] Expires May 2005 Gellens [Page 20] Expires October 2005
The following table maps information elements from MMS delivery The following table maps information elements from MMS delivery
reports to the format specified in [DSN-Msg]. reports to the format specified in [DSN-Msg].
2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message) 2.1.4.1.1 Table 5: Delivery Report Mappings (MMS to Internet Message)
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem | |Report Elem |
======================|============|=================================== ======================|============|===================================
ID of message whose |Message-Id: |'Original-Envelope-ID' field of ID of message whose |Message-Id: |'Original-Envelope-ID' field of
delivery status is | |per-message fields ( delivery status is | |per-message fields (use value of
use value of
being reported | |ENVID from ESMTP envelope if avail- being reported | |ENVID from ESMTP envelope if avail-
| |able, 'Message-ID:' otherwise). | |able, 'Message-ID:' otherwise).
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Recipient address of |From: |'Final-Recipient' field of the Recipient address of |From: |'Final-Recipient' field of the
the original message | |per-recipient section the original message | |per-recipient section
(object of delivery | | (object of delivery | |
report) | | report) | |
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Destination address of|To: |'To:' header field value of top- Destination address of|To: |'To:' header field value of top-
report | |level. report | |level.
| | | |
| |Value taken from [SMTP] envelope | |Value taken from [SMTP] envelope
| |return-path of message being | |return-path of message being
| |reported, not its 'From:' header | |reported, not its 'From:' header
| |field. | |field.
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Date and time the |Date: |'Date:' header field value of top- Date and time the |Date: |'Date:' header field value of top-
message was handled | |level message was handled | |level
======================|============|=================================== ======================|============|===================================
Gellens [Page 21] Expires May 2005 Gellens [Page 21] Expires October 2005
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element Information Element |MMS Delivery|[DSN-Msg] Element
|Report Elem | |Report Elem |
======================|============|===================================Delivery status of |X-Mms- |Action and Status fields of ======================|============|===================================Delivery status of |X-Mms- |Action and Status fields of
original message | Status: |per-recipient section. original message | Status: |per-recipient section.
| | | |
| |The 'Action' field indicates if the | |The 'Action' field indicates if the
| |message was delivered. | |message was delivered.
| | | |
skipping to change at line 989 skipping to change at line 985
* Top-level header field 'To:' SHOULD be the [SMTP] return-path of * Top-level header field 'To:' SHOULD be the [SMTP] return-path of
the message whose status is being reported. the message whose status is being reported.
* Top-level header field 'From:' SHOULD be the address of the * Top-level header field 'From:' SHOULD be the address of the
recipient that the delivery-report concerns. recipient that the delivery-report concerns.
* The first part of the [DSN-Msg] SHOULD include the MM Status Text * The first part of the [DSN-Msg] SHOULD include the MM Status Text
field that would have been generated for an MM1 delivery-report. field that would have been generated for an MM1 delivery-report.
Gellens [Page 22] Expires May 2005 Gellens [Page 22] Expires October 2005
2.1.4.2 Delivery Report Mapping from Internet Message to MMS 2.1.4.2 Delivery Report Mapping from Internet Message to MMS
The following table maps information elements from a delivery report The following table maps information elements from a delivery report
as specified in [DSN-Msg] to the format of an MMS delivery report. as specified in [DSN-Msg] to the format of an MMS delivery report.
2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS) 2.1.4.2.1 Table 6: Delivery Report Mappings (Internet Message to MMS)
===================|==================|================================ ===================|==================|================================
Information Element|MMS Delivery |[DSN=Msg] Element Information Element|MMS Delivery |[DSN=Msg] Element
skipping to change at line 1026 skipping to change at line 1022
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Destination address|To: |'To:' header field value of Destination address|To: |'To:' header field value of
of report | |top-level. of report | |top-level.
| | | |
| |Value taken from [SMTP] envelope | |Value taken from [SMTP] envelope
| |return-path of message being | |return-path of message being
| |reported, not its 'From:' header | |reported, not its 'From:' header
| |field. | |field.
===================|==================|=================================== ===================|==================|===================================
Gellens [Page 23] Expires May 2005 Gellens [Page 23] Expires October 2005
===================|==================|================================ ===================|==================|================================
Information Element|MMS Delivery |[DSN=Msg] Element Information Element|MMS Delivery |[DSN=Msg] Element
|Report Element | |Report Element |
===================|==================|================================ ===================|==================|================================
Date and time the |Date: |'Date:' header field value of Date and time the |Date: |'Date:' header field value of
message was handled| |top-level message was handled| |top-level
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of Delivery status of |X-Mms-Status: |'Action' and 'Status' fields of
original message | |per-recipient section original message | |per-recipient section
skipping to change at line 1062 skipping to change at line 1058
|'deferred' MUST | |'deferred' MUST |
|NOT be used | |NOT be used |
|(ignore DSNs with | |(ignore DSNs with |
|'Action' value | |'Action' value |
|'delayed') | |'delayed') |
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Status Text | |Text in first part (human- Status Text | |Text in first part (human-
| |readable part) | |readable part)
===================|==================|================================ ===================|==================|================================
Gellens [Page 24] Expires May 2005 Gellens [Page 24] Expires October 2005
Internet Draft Mapping Between MMS an
d Internet Mail November 2004
2.1.4.3 Read Report Mapping from MMS to Internet Message 2.1.4.3 Read Report Mapping from MMS to Internet Message
The following table maps information elements from MMS read reports The following table maps information elements from MMS read reports
to the format specified in [MDN]. to the format specified in [MDN].
2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message) 2.1.4.3.1 Table 7: Read Report Mappings (MMS to Internet Message)
======================|============|=================================== ======================|============|===================================
Information Element |MMS Delivery|[DSN-Msg] Element Information Element |MMS Delivery|[DSN-Msg] Element
skipping to change at line 1113 skipping to change at line 1106
| |use 'disposition-type' value | |use 'disposition-type' value
| |'deleted') | |'deleted')
----------------------|------------|----------------------------------- ----------------------|------------|-----------------------------------
Status Text | |Text in first part (human-readable Status Text | |Text in first part (human-readable
| |part) | |part)
======================|============|=================================== ======================|============|===================================
When an MMS Relay/Server generates an [MDN] in response to a message When an MMS Relay/Server generates an [MDN] in response to a message
received using ESMTP on MM3: received using ESMTP on MM3:
Gellens [Page 25] Expires May 2005 Gellens [Page 25] Expires October 2005
* Top-level header field 'To:' SHOULD be the value of the * Top-level header field 'To:' SHOULD be the value of the
'Disposition-Notification-To:' header field of the message whose 'Disposition-Notification-To:' header field of the message whose
disposition is being reported . disposition is being reported .
* Top-level header field 'From:' SHOULD be the address of the * Top-level header field 'From:' SHOULD be the address of the
recipient that the read report concerns. recipient that the read report concerns.
2.1.4.4 Disposition Report Mapping from Internet Message to MMS 2.1.4.4 Disposition Report Mapping from Internet Message to MMS
The following table maps information elements from a disposition The following table maps information elements from a disposition
skipping to change at line 1153 skipping to change at line 1146
| | | |
| |Value taken from 'Disposition- | |Value taken from 'Disposition-
| |Notification-To:' header field | |Notification-To:' header field
| |of message being reported, not | |of message being reported, not
| |its 'From:' header field. | |its 'From:' header field.
-------------------|------------------|-------------------------------- -------------------|------------------|--------------------------------
Date and time the |Date: |'Date:' header field value of Date and time the |Date: |'Date:' header field value of
message was handled| |top-level message was handled| |top-level
===================|==================|================================ ===================|==================|================================
Gellens [Page 26] Expires May 2005 Gellens [Page 26] Expires October 2005
===================|==================|================================ ===================|==================|================================
Information Element|MMS Read Report |[DSN=Msg] Element Information Element|MMS Read Report |[DSN=Msg] Element
|Element | |Element |
===================|==================|================================Disposition of |X-Mms-Read-Status:|disposition-field ===================|==================|================================Disposition of |X-Mms-Read-Status:|disposition-field
message being | | message being | |
reported |Set to one of the | reported |Set to one of the |
|following values: | |following values: |
| | | |
|'read' (used for | |'read' (used for |
skipping to change at line 1200 skipping to change at line 1193
3 Security Considerations 3 Security Considerations
Data contained within messages should not be automatically trusted. Data contained within messages should not be automatically trusted.
Even within a carrier's network, and certainly within the Internet, Even within a carrier's network, and certainly within the Internet,
various deliberate and accidental attacks or corruptions are various deliberate and accidental attacks or corruptions are
possible. For example, routers may contain vulnerabilities which possible. For example, routers may contain vulnerabilities which
may be exploited, IP traffic may be intercepted and/or modified, may be exploited, IP traffic may be intercepted and/or modified,
etc. etc.
Gellens [Page 27] Expires May 2005 Gellens [Page 27] Expires October 2005
The following messaging-related security threats can be identified: The following messaging-related security threats can be identified:
* Misidentification of message source. * Misidentification of message source.
* Message interception (unauthorized disclosure of contents). * Message interception (unauthorized disclosure of contents).
* Unauthorized disclosure of message sender or recipient. * Unauthorized disclosure of message sender or recipient.
* Message modification (by adversary). * Message modification (by adversary).
* Message replay. * Message replay.
* Traffic analysis (determining who is communicating with whom). * Traffic analysis (determining who is communicating with whom).
There are existing mechanisms used to protect email traffic against There are existing mechanisms which can be used to protect email
some of these threats, such as: traffic against some of these threats, such as:
* Use of SSL/TLS (via [StartTLS]) to address disclosure and * Use of SSL/TLS (via [StartTLS]) to address disclosure and
modification in transit between adjacent servers. modification in transit between adjacent servers.
* SMTP Authentication [Auth] to protect against misidentification of * SMTP Authentication [Auth] to protect against misidentification of
message source. message source.
* Use of end-to-end security mechanisms such as [PGP] or S/MIME * Use of end-to-end security mechanisms such as [PGP] or S/MIME
[SMIME] to protect message contents. [SMIME] to protect message contents.
* Use of [IPSec] to protect against disclosure or mod * Use of [IPSec] to protect against disclosure or modification in
ification in
transit between servers. transit between servers.
These mechanisms SHOULD be employed whenever the required Use of these mechanisms is encouraged. When a message uses
infrastructure is available, e.g., a certificate infrastructure is end-to-end security mechanisms such as [PGP] or S/MIME [SMIME],
necessary to support S/MIME, or user agent support for PGP is servers MUST be careful not to accidently destroy the integrity of
available. Enabling SMTP Authentication [Auth] and STARTTLS the protected content (for example, by altering any text within the
[StartTLS] are easy measures to deploy and SHOULD be used. region covered by a signature while mapping between MMS and email).
Since MMS does not include a clear separation between in-transit Since MMS does not include a clear separation between in-transit
envelope and message content, there are increased risks of envelope and message content, there are increased risks of
unauthorized disclosure of information, and additional challenges in unauthorized disclosure of information, and additional challenges in
protecting data. For example, Bcc recipients do not normally appear protecting data. For example, Bcc recipients do not normally appear
in the message content, only in the envelope; care MUST be taken in in the message content, only in the envelope; care MUST be taken in
the gateway function to ensure that Bcc recipients which do appear the gateway function to ensure that Bcc recipients which do appear
are deleted from the message content. are deleted from the message content.
Some MMS features contain inherently more risk than others. For Some MMS features contain inherently more risk than others. For
example, reply charging and sender address hiding. The reply example, reply charging and sender address hiding. The reply
charging mechanism requires a high degree of trust between entities charging mechanism requires a high degree of trust between entities
with little technical basis. Deliberate or accidental abuse of this with little technical basis. Deliberate or accidental abuse of this
trust can result in unexpected or unauthorized charges. For trust can result in unexpected or unauthorized charges. For
example, a sender may be charged for unauthorized replies, or a example, a sender may be charged for unauthorized replies, or a
Gellens [Page 28] Expires May 2005 Gellens [Page 28] Expires October 2005
sender may be charged for a reply which the author thought would be sender may be charged for a reply which the author thought would be
paid for by the recipient. A sender's identity may be disclosed in paid for by the recipient. A sender's identity may be disclosed in
violation of a request for this to be blocked. The identity of violation of a request for this to be blocked. The identity of
recipients may be disclosed to other recipients (or even recipients may be disclosed to other recipients (or even
non-recipients) for a message in which the sender intended for the non-recipients) for a message in which the sender intended for the
recipients not to be disclosed. recipients not to be disclosed.
It is possible to hide the sender's identity from non-recipients It is possible to hide the sender's identity from non-recipients
using anonymous remailers. It is hard to hide the sender's identity using anonymous remailers. It is hard to hide the sender's identity
from recipients when the mail is cryptographically signed. In view from recipients when the mail is cryptographically signed. In view
skipping to change at line 1299 skipping to change at line 1291
[MDN] "An Extensible Message Format for Message Disposition [MDN] "An Extensible Message Format for Message Disposition
Notifications", Fajman, RFC 2298, March 1998. Notifications", Fajman, RFC 2298, March 1998.
[Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001. [Msg-Fmt] "Internet Message Format", Resnick, RFC 2822, April 2001.
[Report-Fmt] "The Multipart/Report Content Type for the Reporting of [Report-Fmt] "The Multipart/Report Content Type for the Reporting of
Mail System Administrative Messages", Vaudreuil, RFC 3462, January Mail System Administrative Messages", Vaudreuil, RFC 3462, January
2003 2003
Gellens [Page 29] Expires May 2005 Gellens [Page 29] Expires October 2005
[RESP] Enhanced Mail System Status Codes, Vaudreuil, RFC 1893, [RESP] Enhanced Mail System Status Codes, Vaudreuil, RFC 1893,
January 1996. January 1996.
[SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April [SMTP] "Simple Mail Transfer Protocol", Klensin, RFC 2821, April
2001. 2001.
5 Informative References 5 Informative References
IETF: IETF:
skipping to change at line 1346 skipping to change at line 1338
[StartTLS] "SMTP Service Extension for Secure SMTP over Transport [StartTLS] "SMTP Service Extension for Secure SMTP over Transport
Layer Security", Hoffman, RFC 3207, February 2002 Layer Security", Hoffman, RFC 3207, February 2002
[Submission] "Message Submission", Gellens, Klensin, RFC 2476, [Submission] "Message Submission", Gellens, Klensin, RFC 2476,
December 1998. December 1998.
[VPIM] "Voice Profile Internet Mail - Version 2", Vaudreuil, [VPIM] "Voice Profile Internet Mail - Version 2", Vaudreuil,
Parsons, RFC 2421, September 1998. Parsons, RFC 2421, September 1998.
Gellens [Page 30] Expires May 2005 Gellens [Page 30] Expires October 2005
OMA: OMA:
OMA specifications are available at the OMA web site OMA specifications are available at the OMA web site
<http://www.openmobilealliance.org>. <http://www.openmobilealliance.org>.
[OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C [OMA-MMS] OMA-WAP-MMS-ENC-V1_2-20040323-C
3GPP2 and 3GPP: 3GPP2 and 3GPP:
3GPP2 specifications are available at the 3GPP2 (Third 3GPP2 specifications are available at the 3GPP2 (Third
skipping to change at line 1394 skipping to change at line 1386
6 Author's Address 6 Author's Address
Randall Gellens Randall Gellens
QUALCOMM Incorporated QUALCOMM Incorporated
5775 Morehouse Drive 5775 Morehouse Drive
San Diego, CA 92121 San Diego, CA 92121
USA USA
randy@qualcomm.com randy@qualcomm.com
Gellens [Page 31] Expires May 2005 Gellens [Page 31] Expires October 2005
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made 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 to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat. can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be re rights which may cover technology that may be required to practice
quired to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
skipping to change at line 1437 skipping to change at line 1428
Disclaimer Disclaimer
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens [Page 32] Expires May 2005 Gellens [Page 32] Expires October 2005
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/