V.Shveidel
Internet Draft A.Erev
Document: draft-shveidel-mediasize-02.txt Comverse
Expires: September 2003 February 2003
SMTP Service Extension for message Media Size declaration
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
This Internet-Draft will expire on September 15, 2003.
Copyright notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This memo defines an extension to the SMTP service whereby an SMTP
client and server may interact to give the server an opportunity to
decline or accept a message (perhaps temporarily) based on the
client's estimate of the general message size and sizes of media
parts the message contains.
[9] lists a number of issues and requirements for the use of
internet messaging in the context of Unified Messaging and Telephone
User Interface. This memo elaborates and suggests an implementation
for chapter 3.2 of [9].
This memo extends facilities of "SMTP Service Extension for Message
Size Declaration" [3]. As such, the authors of this memo used
portions of the text in [3] as a basis for this memo.
Shveidel/Erev Internet draft - Expires September 15, 2003 1
SMTP Per Media Size Declaration February 2003
Table of Contents
Status of this Memo................................................1
Copyright notice...................................................1
Abstract...........................................................1
1. Document Conventions...........................................2
2. Introduction...................................................3
3. Definitions....................................................4
4. Framework for the PER-MEDIA SIZE Declaration Extension.........4
5. The Message Media Size Declaration service extension...........5
6. The extended MAIL command......................................6
6.1 Server action on receipt of the extended MAIL command..........7
6.2 Client action on receiving response to extended MAIL command...7
6.3 Messages containing media parts larger than the declared media
size...............................................................8
6.4 Per-recipient rejection based on message per media size........8
7. Minimal usage..................................................8
8. Example........................................................9
9. Formal syntax.................................................11
10. Security considerations......................................12
11. IANA Considerations..........................................12
11.1. Message Context size units Registrations....................13
11.2. Registration Template.......................................13
12. References....................................................14
13. Author's Addresses............................................14
14. List of main changes..........................................15
Full Copyright Statement..........................................15
Acknowledgement...................................................16
1. Document Conventions
In protocol examples, this document uses a prefix of "C: " to denote
lines sent by the client (SMTP-sender) to the server (SMTP-
receiver), and "S: " for lines sent by the server (SMTP-receiver) to
the client (SMTP-sender). No line break is present in the protocol
unless specifically mentioned.
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 [8].
Other capitalized words are SMTP [1] and SMTP SIZE extension [3]
keywords or keywords from this document.
Shveidel/Erev Internet draft - Expires September 15, 2003 2
SMTP Per Media Size Declaration February 2003
2. Introduction
The MIME extensions to the Internet message protocol provide for the
transmission of many kinds of data which were previously unsupported
in Internet mail. One expected result of the use of MIME is that
SMTP will be expected to carry a much wider range of message sizes
and message media types than was previously the case. This has an
impact on the amount of resources (e.g., disk space) required by a
system acting as a server.
This memo uses the mechanism defined in [5] to define extensions to
the SMTP service whereby a client (SMTP-sender) may declare the
general size of a particular message and a per-media size to a server
(SMTP-receiver), after which the server may indicate to the client
that it is or is not willing to accept the message based on the
declared per-media size of the message and whereby a server (SMTP-
receiver) may declare the maximum per-media size for a message it is
willing to accept from a client (SMTP-sender).
This memo extends facilities of "SMTP Service Extension for Message
Size Declaration" [3].
As mentioned above, the proposed extension allows an SMTP client and
an SMTP server to coordinate transmission of a message based on its
size, classified by specific media type(s). This allows the server
to manage quota per media or per message-context (see [6]).
The common use case for this extension is the case of a submitting
client that sends a message to the final server. However, the
extension can be used also in relaying scenario without any protocol
change.
There are basically two alternatives to manage per-media/context
quota: (1) Associate the media size of the whole message to a
"Message-Context" category (see [6]). Or, (2) Associate each body
part to a specific Quota class, based on its content/media type.
An example of (1) is a "voice-message" message-context, which may
include a text attachment. Both the voice and the text parts will be
accounted on the "voice-message" Quota.
An example of (2) is a "video message" that contains a body part
with video content-type and another body part with audio Content-
Type - each of them accounted to different quota classes "video" and
"audio" respectively.
A server that supports the Message MediaSize declaration extension
MUST use per message context quota association (i.e.(1)) for media
types that contains postfix "-message" in the media name and are
registered as "Message-Context" (see [6]).
The server MAY use either per body-part (i.e. (2)) or per message
context (i.e.(1)) quota association for non "Message-Context" media
types. For those media types an implementation MAY decide which of
Shveidel/Erev Internet draft - Expires September 15, 2003 3
SMTP Per Media Size Declaration February 2003
the above alternatives to use. Such media types are subject for
future standardization.
3. Definitions
The "per-media message size" (or "per-media size") is defined as the
sequence of general message size (as it is defined in [3]), and one
or more media size items describing duration of the whole message or
duration of specific media parts of the message.
The "media size" item is defined as the sequence of the character
";", media name, the character ":", media size (or duration) value
and immediately following it, the unit measurement name.
"media name" is defined as alphabetical string and is subject for
future standardization.
"media size (duration) value" is defined as a number. All
implementations of "Message MediaSize Declaration" MUST support at
least 32 bit unsigned integer representation for this value.
"measurement unit" is defined as alphabetical string and is subject
for future standardization.
The "fixed maximum message per-media size" (or "fixed maximum per-
media size") is defined as the set of the fixed maximum sizes for
specific media potentially contained in the message that a server is
ever willing to accept. An attempt to transfer any message
containing a media part larger than the fixed maximum for this media
will always fail.
The fixed maximum message per-media size may be an implementation
artifact of the SMTP server, or it may be chosen by the administrator
of the server.
The "fixed maximum media size" (fixed maximum message size for
specific media) is defined as the sequence of media name, the
character ":" and one or more pairs of media size value followed by
the measurement unit. Pairs are delimited by a ";". Each pair gives
an alternative for media size/duration representation supported by
the server.
The "declared message media size" is defined as a client's estimate
of the message per-media size for a particular message.
4. Framework for the PER-MEDIA SIZE Declaration Extension
The following service extension is therefore defined:
(1) The name of the SMTP service extension is "Message MediaSize
Declaration".
Shveidel/Erev Internet draft - Expires September 15, 2003 4
SMTP Per Media Size Declaration February 2003
(2) The EHLO keyword value associated with this extension is
"MEDIASIZE".
(3) Some optional parameters are allowed with this EHLO keyword.
Each parameter is a string indicating the fixed maximum size of
media parts of the message in special units that the server will
accept.
A media size value of 0 (zero) indicates that no server's fixed
maximum media size for corresponding media is in force.
If some parameter is omitted, no information is conveyed about the
server's fixed maximum media size for corresponding media.
The formal syntax of the parameter is defined in section 9 of this
document.
(4) One optional parameter using the keyword "SIZE" is added to the
MAIL FROM command. The value associated with this parameter is a
string indicating the general size and the per-media size of the
message that is to be transmitted.
The formal syntax of the parameter is defined in section 9 of this
document.
(5) No additional SMTP verbs are defined by this extension.
The remainder of this memo specifies how support for the extension
affects the behavior of an SMTP client and server.
5. The Message Media Size Declaration service extension
An SMTP server MAY have a fixed upper limit not only on general
message size but also an upper limit on each media type, which may be
contained in the message. Any attempt by a client to transfer a
message containing a media part whose size is larger than this fixed
upper limit will fail. In addition, a server normally has limited
space for storing incoming messages. Transfer of a message MAY
therefore fail due to lack of storage space for a specific media, but
MAY succeed at a later time.
A client using the SMTP protocol defined in [1] (with no extensions)
or the SMTP protocol with "Message Size Declaration service
extension" [3] can only be informed of such failures after
transmitting the entire message to the server (which discards the
transferred message). If, however, both client and server support the
Message Media Size Declaration service extension, such conditions may
be detected before any transfer is attempted.
An SMTP client wishing to relay large media content MAY issue the
EHLO command to start an SMTP session, to determine if the server
supports any of several service extensions. If the server responds
Shveidel/Erev Internet draft - Expires September 15, 2003 5
SMTP Per Media Size Declaration February 2003
with code 250 to the EHLO command, and the response includes the EHLO
keyword value MEDIASIZE, then the Message Media Size Declaration
extension is supported.
If a string of parameters follows the MEDIASIZE keyword value of the
EHLO response, each of the parameters indicates the maximal size and
units for a specific media type of the message, or parts of the
message, that the server is willing to accept. Any attempt by a
client to transfer a message containing a media part that is larger
than this limit will be rejected with a permanent failure (552) reply
code.
If the SMTP server has no fixed maximum size limitation for a
specific media, it still SHOULD include this media type in the
MEDIASIZE EHLO response (with the maximum size set to 0) so that the
client knows that this media type is supported by the server and the
media unit(s) supported in the context of MEDIASIZE processing.
A server that supports the Message Media Size Declaration extension
MUST accept the extended version of the MAIL command described below.
When supported by the server, a client MAY use the extended MAIL
command (instead of the MAIL command as defined in [1] and extension
defined in [3]) to declare an estimate of the per-media size of a
message it wishes to transfer. The server may then return an
appropriate error code if it determines that an attempt to transfer a
message with media part of that size would fail.
6. The extended MAIL command
The extended MAIL command is issued by a client when it wishes to
inform a server of the media size(s) of the message to be sent. The
extended MAIL command is identical to the MAIL command as defined in
[3], except that a SIZE parameter contains not only general message
size but also the media size (or duration).
The complete syntax of the extended command is defined in [5]. The
esmtp-keyword is SIZE and the syntax for esmtp-value is given by the
syntax for mediasize-parameter-value shown in section 9.
The value associated with the SIZE parameter is a string
representation of the declared message media size in specific units
for each media type. General message size is represented as it is
defined in [3].
Ideally, the declared message media size is equal to the true message
size. However, since exact computation of the message media size may
be infeasible, the client may use a heuristically-derived estimate.
Such heuristics SHOULD be chosen so that the declared message media
size is larger than the actual message size.
NOTE: Servers MUST NOT use the SIZE parameter to determine end of
content in the DATA command.
Shveidel/Erev Internet draft - Expires September 15, 2003 6
SMTP Per Media Size Declaration February 2003
6.1 Server action on receipt of the extended MAIL command
Upon receipt of an extended MAIL command containing a media extended
SIZE parameter, a server SHOULD determine whether the declared
general message size exceeds its (current) fixed maximum message size
and whether declared media size(s) exceed corresponding fixed maximum
media sizes. If the declared general message size and all of
declared media sizes are smaller than the corresponding fixed maximum
message sizes, the server may also wish to determine whether
sufficient resources are available to buffer a message of the
declared media size and to maintain it in stable storage, until the
message can be delivered or relayed to each of its recipients.
A server may respond to the extended MAIL command with any of the
error codes defined in [1] and [3] for the MAIL command. In
addition, one of the following error codes may be returned:
(1) If the server does not support the measurement unit for a
specific media that was specified by the client in the MAIL
command, the server SHOULD respond with a 501 reply (illegal unit
name).
(2) If the server currently lacks sufficient resources to accept a
message of the indicated media size, but may be able to accept the
message at a later time, it SHOULD respond with a 452 reply
(insufficient system media-specific storage).
(3) If the indicated per media size is larger than the server's fixed
maximum message per media size, the server SHOULD respond with a
552 reply (message media size exceed fixed maximum media size).
A server is permitted, but not required, to accept a message,
which is, in fact, larger than declared in the extended MAIL
command, such as might occur if the client employed a size-
estimation heuristic which was inaccurate (produced a lower
result).
6.2 Client action on receiving response to extended MAIL command
(1) If the reply code 452 (insufficient system media storage) is
returned, the client SHOULD next send either a RSET command (if it
wishes to attempt to send other messages) or a QUIT command. The
client SHOULD then repeat the attempt to send the message to the
server at a later time.
(2) If the reply code 552 (message media size exceeds fixed maximum
message media size) is received, the client SHOULD immediately
send either a RSET command (if it wishes to attempt to send
Shveidel/Erev Internet draft - Expires September 15, 2003 7
SMTP Per Media Size Declaration February 2003
additional messages), or a QUIT command. The client MUST then
declare the message undeliverable and return appropriate
notification to the sender (if a sender address was present in the
MAIL command).
A successful (250) reply code in response to the extended MAIL
command does not constitute an absolute guarantee that the message
transfer will succeed. SMTP clients using the extended MAIL
command MUST still be prepared to handle both temporary and
permanent error reply codes (including codes 452 and 552), either
immediately after issuing the DATA command, or after transfer of
the message.
6.3 Messages containing media parts larger than the declared media size.
Once a server has agreed (via the extended MAIL command) to accept a
message of a particular media size, it SHOULD NOT return a 552 reply
code after the transfer phase of the DATA command, unless the actual
per media size of the message transferred is greater than the
declared message per media size. A server MAY also choose to accept a
message containing media parts which are somewhat larger than the
declared media size.
A client is permitted to declare a message to be smaller than its
actual per media size. However, in this case, a successful (250
reply code is no assurance that the server will accept the message or
has sufficient resources to do so. The server MAY reject such a
message after its DATA transfer.
6.4 Per-recipient rejection based on message per media size.
A server that implements this extension MAY return a 452 or 552 reply
code (as it is explained in 6.1) in response to a RCPT command, based
on its unwillingness to accept a message of the declared per media
size for a particular recipient.
(1) If a 452 reply code is returned, the client is expected to re-
queue the message for later delivery to the same recipient.
(2) If a 552 reply code is returned, the client is expected to
refrain from any later retry delivery to the same recipient.
7. Minimal usage
A "minimal" client MAY use this extension to simply compare the
(perhaps estimated) per media size of the message that it wishes to
send, with the server's fixed maximum message per-media size (from
the parameter to the MEDIASIZE keyword in the EHLO response), to
determine whether the server will ever accept the message. Such an
implementation need not declare message per-media size via the
extended MAIL command. However, neither will it be able to discover
Shveidel/Erev Internet draft - Expires September 15, 2003 8
SMTP Per Media Size Declaration February 2003
temporary limits on message media size due to server resource
limitations, nor per-recipient limitations on message media size.
A "minimal" server that employs this service extension MAY simply use
the MEDIASIZE keyword value to inform the client of the size of the
largest media parts of message it will accept, or to inform the
client that there is no fixed limit on message media sizes. Such a
server MUST accept the extended MAIL command and return a 552 reply
code if the client's declared media size exceeds its fixed media size
limit (if any), but it need not detect "temporary" limitations on
message media size.
The string parameters to the EHLO MEDIASIZE keyword are OPTIONAL. If
some parameter is omitted entirely it indicates that the server does
not advertise a fixed maximum for this media size. A server that
returns the MEDIASIZE keyword with no parameter or with omitted
parameter for specific media in response to the EHLO command SHOULD
NOT issue a positive (250) response to an extended MAIL command
containing a media-extended SIZE specification without first checking
to see if sufficient resources are available to transfer a message of
the declared media sizes, and to retain it in stable storage until it
can be relayed or delivered to its recipients. If possible, the
server SHOULD actually reserve sufficient message storage space to
transfer the message.
8. Example
The following examples illustrates the use of per media size
declaration with some permanent and temporary failures.
8.1 General case. Quota is associated with "Message-Context" category
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 vis.comverse.com ESMTP Service ready
C: EHLO merlot.comverse.com
S: 250- merlot.comverse.com
S: 250-EXPN
S: 250-HELP
S: 250 SIZE 1000000
S: 250 MEDIASIZE text-message:8000000octets fax-
message:20pages;2000000octets voice-message:10sec
C: MAIL FROM:<vis@mme.xx> SIZE=80000;voice-message:107sec
S: 552 message media size exceeds fixed maximum message media size
(voice-message)
C: MAIL FROM:<vis@mme.xx> SIZE=80000;voice-message:7sec
S: 250 Address Ok.
C: RCPT TO:<v@comverse.com>
S: 250 v@comverse.com OK; can accept 80000;voice-message:7sec;
Shveidel/Erev Internet draft - Expires September 15, 2003 9
SMTP Per Media Size Declaration February 2003
C: RCPT TO:<x@cmvt.com>
S: 452 insufficient system media storage (voice-message)
C: RCPT TO:<z@comverse.com>
S: 552 Mailbox media quota (voice-message) exceeded: z@comverse.com
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
C: Date: Mon, 2 Sep, 2002 17:34:50 +0300
C: From: <vis@mme.xx>
C: Subject: Mediasize SMTP extension draft
...
C: .
S: 250 OK
C: QUIT
S: 250 Goodbye
8.2 Some Quotas are associated to body parts based on its
content/media type (optional scenario)
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 vis.comverse.com ESMTP Service ready
C: EHLO merlot.comverse.com
S: 250- merlot.comverse.com
S: 250-EXPN
S: 250-HELP
S: 250 SIZE 1000000
S: 250 MEDIASIZE fax-message:20pages;2000000octets voice-
message:10sec x-video:100sec;1000000octets x-audio:10min
C: MAIL FROM:<vis@mme.xx> SIZE=80000;x-video:107sec
S: 552 message media size exceeds fixed maximum message media size
(x-video)
C: MAIL FROM:<vis@mme.xx> SIZE=80000;x-audio:7min;x-video:30sec
S: 250 Address Ok.
C: RCPT TO:<v@comverse.com>
S: 250 v@comverse.com OK; can accept 80000; x-audio:7min;x-
video:30sec
C: RCPT TO:<x@cmvt.com>
S: 452 insufficient system media storage (x-video)
C: RCPT TO:<z@comverse.com>
S: 552 Mailbox media quota (x-audio) exceeded: z@comverse.com
C: DATA
Shveidel/Erev Internet draft - Expires September 15, 2003 10
SMTP Per Media Size Declaration February 2003
S: 354 Send message, ending in CRLF.CRLF.
C: Date: Mon, 2 Sep, 2002 17:34:50 +0300
C: From: <vis@mme.xx>
C: Subject: Mediasize SMTP extension draft
...
C: .
S: 250 OK
C: MAIL FROM:<vis@mme.xx> SIZE=80000;voice-message:7sec
S: 250 Address Ok.
C: RCPT TO:<v@comverse.com>
S: 250 v@comverse.com OK; can accept 80000;voice-message:7sec;
C: RCPT TO:<z@comverse.com>
S: 552 Mailbox media quota (voice-message) exceeded: z@comverse.com
C: DATA
S: 354 Send message, ending in CRLF.CRLF.
C: Date: Mon, 2 Sep, 2002 17:34:50 +0300
C: From: <vis@mme.xx>
C: Subject: Mediasize SMTP extension draft
...
C: .
S: 250 OK
C: QUIT
9. Formal syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in ABNF [10].
Non-terminals referenced but not defined below are as defined by SMTP
[1] and SMTP SIZE extension [3].
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lower case characters to define
token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion.
Mediasize-ehlo-line ::= "MEDIASIZE" mediasize-params
mediasize-params ::= *(SP media-size-dsc)
Shveidel/Erev Internet draft - Expires September 15, 2003 11
SMTP Per Media Size Declaration February 2003
media-size-dsc ::= media-name ":" maxsize unit *(";" maxsize
unit)
maxsize ::= size-value
media_name ::= message-context-name / media-type-name
message-context-name ::= media-type-name "-message"
media-type-name ::= (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
unit ::= ALPHA *(ALPHA / "-")
size-value ::= 1*DIGIT
mediasize-esmtp-parameter ::= "SIZE=" mediasize-parameter-value
mediasize-parameter-value ::= general-size *(";" media-size)
general-size ::= size-value
media-size ::= media ":" size-value unit
10. Security considerations
The media size declaration extensions described in this memo can
conceivably be used to facilitate crude service denial attacks.
Specifically, both the information contained in the SIZE parameter
and use of the extended MAIL command make it somewhat quicker and
easier to devise an efficacious service denial attack.
It is recommended that an implementation supports internal mapping
between media size units and compares the declared size and the
actually received size (if in different units) to validate that the
two relate to each other reasonably. This should prevent cases where
the declared size (expressed in some unit) defers from the actual
sent size (possibly measured in another unit).
Describing the mapping algorithm (which may be dependent on specific
file formats and encoding schemes) is out of the scope of this draft.
Other than that this extension does not create any vulnerability that
has not existed with SMTP or with SMTP with the original SIZE
extension.
11. IANA Considerations
On publication of this document by the RFC Editor, IANA shall
register the Message MediaSize Declaration ESMTP extension defined in
section 4.
Shveidel/Erev Internet draft - Expires September 15, 2003 12
SMTP Per Media Size Declaration February 2003
To promote interoperability and coherent interpretations of
different media types, a central repository for well-known media
types and possible measurement units SHOULD be maintained.
To support the mandatory level of support of media size (associate
with message-context), the relevant repository is the IANA-managed
Message-Context repository. There is a need to extend the message-
context registration by registering the size units appropriate to
each of the message-context values.
The following is a suggested list for initial values for
registration.
11.1. Message Context size units Registrations
Internet Message-Context Size Units
======================================
Media Type (referenced Possible Unit(s)
Message-Context value) first is default)
----------------------- ---------------------------
voice-message "octets"
"sec" (seconds)
fax-message "octets"
"pages"
multimedia-message "octets"
text-message "octets"
11.2. Registration Template
In the following template, a pipe symbol, "|", precedes instructions
or other helpful material. Be sure to replace "<mediatype_name>"
with the media type name you are defining.
Media Type name:
<mediatype_name>
|Referenced Message-Context value
Default measurement unit:
| Name of default measurement unit for the media (not longer
| than 10 characters)
Possible measurement units:
| List of possible names of measurement unit for the media
| type (each name MUST be not longer than 10 characters)
Shveidel/Erev Internet draft - Expires September 15, 2003 13
SMTP Per Media Size Declaration February 2003
Person & email address to contact for further information:
| Name & e-mail
12. References
[1] Klensin J, "Simple Mail Transfer Protocol", STD 10, RFC 2821,
AT&T Laboratories, April 2001.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] J. Klensin, WG Chair, "SMTP Service Extension for Message
Size Declaration", RFC 1427, University of Tennessee,
February 1993.
[4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United
Nations University, Innosoft International, Inc., Dover Beach
Consulting, Inc., Network Management Associates, Inc., The
Branch Office, February 1993.
[5] J. Klensin, WG Chair, " SMTP Service Extensions ", RFC
1869,Brandenburg Consulting, November 1995.
[6] E. Burger, C. Eliot, G. Klyne, E. Candell, "Message Context
for Internet Mail", Internet draft, Microsoft, Comverse,
Baltimore Technologies, SnowShore Networks June 2001.
[7] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Greg Vaudreuil, "Messaging Profile For Telephone-based
Messaging Clients".
http://www.ietf.org/internet-drafts/draft-vaudreuil-um-
issues-00.txt
[10] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
13. Author's Addresses
Vladimir Shveidel
Comverse
29 Habarzel St.
Tel-Aviv 69710
Israel
Shveidel/Erev Internet draft - Expires September 15, 2003 14
SMTP Per Media Size Declaration February 2003
EMail: Vladimir.Shveidel@comverse.com
Ari Erev
Comverse
29 Habarzel St.
Tel-Aviv 69710
Israel
EMail: Ari.Erev@comverse.com
14. List of main changes
Changes to version 01:
- the Formal syntax of the extension was moved into a separate
section.
- Section Document Convention was added.
- Section Definition is relocated to the top of the document (thanks
to Alexey Melnikov).
- Changed slightly the paragraph on Server and Client actions to
clarify actions taken with respect to return and error codes.
- Minor bugs in ABNF notation were fixed (thanks to Alexey
Melnikov).
- Requirement of supporting at least 32 bit unsigned integer size-
value representation was added (thanks to Alexey Melnikov).
- Some of ABNF definitions were more clearly formulated.
- In section IANA Consideration, measurement units "kilobytes" were
changed to "octets". (comment made by Dan Kohn [dan@dankohn.com])
Changes to version 02:
- As per feedback received in "Lemonade" working group meeting in
IETF 55 (Atlanta): The default and minimally required method of
identifying the various media quota is by accounting the whole
message to the "Message-Context" category. (see [6]).
- As a result, the central repository for well-known media types and
possible measurement is the IANA-managed Message-Context
repository.
- Discussion of the possibility to extend this draft to handle more
general resource queries/coordination was removed (as per feedback
received in IETF 55, Lemonade WG).
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
Shveidel/Erev Internet draft - Expires September 15, 2003 15
SMTP Per Media Size Declaration February 2003
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.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Shveidel/Erev Internet draft - Expires September 15, 2003 16