V.Shveidel Internet Draft A.Erev Document: draft-shveidel-mediasize-04.txt Comverse Expires: May 2004 November 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 May 15, 2004. Copyright notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo defines an extension to the Simple Mail Transfer Protocol (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 the media parts the message contains. Table of Contents Status of this Memo................................................1 Copyright notice...................................................1 Abstract...........................................................1 1. Document Conventions...........................................2 2. Introduction...................................................2 3. Definitions....................................................4 Shveidel/Erev Internet draft - Expires May 15, 2004 1 SMTP Per Media Size Declaration November 2003 4. Framework for the PER-MEDIA SIZE Declaration Extension.........5 5. The Message Media Size Declaration service extension...........5 6. The MAIL command with extended SIZE parameter..................7 6.1 Server action on receipt of the MAIL command with extended SIZE parameter..........................................................7 6.2 Client action on receiving response to MAIL command with extended SIZE parameter.....................................................8 6.3 Messages containing media parts larger than the declared media size...............................................................8 6.4 Per-recipient rejection based on message per media size........9 7. Minimal usage..................................................9 8. Example.......................................................10 8.1 General case. Quota is associated with "Message-Context" category..........................................................10 8.2 Case where some quotas are associated to body parts based on its content/media context (optional scenario).....................11 9. Formal syntax.................................................12 10. Security considerations......................................13 11. IANA Considerations..........................................13 11.1. Message Context size units Registrations....................14 11.2. Registration Template.......................................15 12. References....................................................15 13. Author's Addresses............................................16 14. List of main changes..........................................16 Full Copyright Statement..........................................18 Acknowledgement...................................................18 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 [RFC2119]. Other capitalized words are SMTP [SMTP] SMTP SIZE extension [SIZE] and LMTP [LMTP] keywords or keywords from this document. When it is not specifically declared, any mentions of the SMTP protocol [SMTP] is also applied for LMTP protocol [LMTP] 2. Introduction Shveidel/Erev Internet draft - Expires May 15, 2004 2 SMTP Per Media Size Declaration November 2003 Multipurpose Internet Mail Extensions (MIME) [MIME1][MIME2] provides 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 Simple Mile Transfer Protocol (SMTP) is 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. [LEMONADE-GOALS] 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 6.2.2 of [LEMONADE-GOALS]. This memo uses the mechanism defined in [SMTP] 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 o accept the message based on the declared per-media size of the message. * 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" as defined in [SIZE] Specifically, it is expected that the media-size extension is used by Message Submission Agents (MSA) in SMTP-submit scenarios, as defined by [RFC2476]. Typically the SMTP Server in this scenario is the server where the messages are delivered (final server). 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 context(s). This allows the server to manage quota per media or per message-context (see [MSG- CONTEXT]). The main benefit of using this extension is that based on the SMTP- client and SMTP-server coordination, the client can predict (although not in full certainty) whether the message will be accepted by the server before an actual transfer of data takes place. (Note, that full certainty can not be guaranteed, in case of parallel sessions to the same address, where one message consumes enough space to cause the other one to be rejected) 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 [MSG-CONTEXT]). Or, (2) Associate each body part to a specific Quota class, based on its content 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. Shveidel/Erev Internet draft - Expires May 15, 2004 3 SMTP Per Media Size Declaration November 2003 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. alternative 1), above) for media contexts that contains postfix "-message" in the media name and are registered as "Message-Context" (see [RFC3458]). The server MAY use either per body-part (i.e. alternative (2)) or per message context (i.e.(1)) quota association for non "Message- Context" media contexts. For those media contexts an implementation MAY decide which of the above alternatives to use. Such media contexts 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 [SIZE]), 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 alphanumeric 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 configured 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 Shveidel/Erev Internet draft - Expires May 15, 2004 4 SMTP Per Media Size Declaration November 2003 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". (2) The EHLO (LHLO in case of LMTP) 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 the 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. The maximum length of this parameter should not exceed 512 characters, and hence the maximum possible length of a MAIL FROM command line should be increased by 512 characeters. (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 context, 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 Shveidel/Erev Internet draft - Expires May 15, 2004 5 SMTP Per Media Size Declaration November 2003 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 [SMTP] (with no extensions) or the SMTP protocol with "Message Size Declaration service extension" [SIZE] 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 the actual transfer of data is attempted. An SMTP client wishing to submit large media content MAY issue the EHLO (LHLO in case of LMTP) command to start an SMTP session, to determine if the server supports any of several service extensions. If the server responds 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 context 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. Each media context MUST appear only once in the string of parameters following the MEDIASIZE keyword. The server response indicating maximum media context sizes, may be dependent on client identity (provided that authentication took place before the EHLO command). If the SMTP server has no fixed maximum size limitation for a specific media, it still SHOULD include this media context in the MEDIASIZE EHLO response (with the maximum size set to 0) so that the client knows that this media context 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 MAIL command with extended SIZE parameter (instead of the MAIL command as defined in [SMTP] and extension defined in [SIZE]) 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. Shveidel/Erev Internet draft - Expires May 15, 2004 6 SMTP Per Media Size Declaration November 2003 6. The MAIL command with extended SIZE parameter The MAIL command with extended SIZE parameter is issued by a client when it wishes to inform a server of the media size(s) of the message to be sent. The MAIL command with extended SIZE parameter is identical to the MAIL command as defined in [SIZE], 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 [SMTP]. 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 context. General message size is represented as it is defined in [SIZE]. 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. 6.1 Server action on receipt of the MAIL command with extended SIZE parameter Upon receipt of an MAIL command with extended SIZE parameter 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 MAIL command with extended SIZE parameter with any of the error codes defined in [SMTP] and [SIZE] 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). Shveidel/Erev Internet draft - Expires May 15, 2004 7 SMTP Per Media Size Declaration November 2003 (2) If one or more of the media sizes that were specified by the client exceeds server implementation limit (32 bit unsigned value at least) the server SHOULD respond with a 501 reply (illegal media size value). (3) 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). (4) 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 MAIL command with extended SIZE parameter, 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 MAIL command with extended SIZE parameter (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 additional messages), or a QUIT command. The client MUST then declare the message undeliverable and return appropriate notification [DSN] to the sender (if a sender address was present in the MAIL command). The following Enhanced Mail System Status Codes [RFC3463] SHOULD be used in the DSN: 5.2.3 (message length exceeds administrative limit) A successful (250) reply code in response to the MAIL command with extended SIZE parameter does not constitute an absolute guarantee that the message transfer will succeed. SMTP clients using the MAIL command with extended SIZE parameter 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 MAIL command with extended SIZE parameter) to accept a message of a particular media size, it SHOULD Shveidel/Erev Internet draft - Expires May 15, 2004 8 SMTP Per Media Size Declaration November 2003 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. The client MUST then declare the message undeliverable to this recipient and return appropriate notification to the sender (if a sender address was present in the MAIL command). The following Enhanced Mail System Status Codes [RFC3463] SHOULD be used in the DSN: 4.2.2 (mailbox full). 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 accept the message. Such an implementation need not declare message per-media size via the MAIL command with extended SIZE parameter. However, neither will it be able to discover 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 MAIL command with extended SIZE parameter 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. Shveidel/Erev Internet draft - Expires May 15, 2004 9 SMTP Per Media Size Declaration November 2003 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 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 delivered to its recipients. 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: C: 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: SIZE=80000;voice-message:107sec S: 552 message media size exceeds fixed maximum message media size (voice-message) C: MAIL FROM: SIZE=80000;voice-message:7sec S: 250 Address Ok. C: RCPT TO: S: 250 v@comverse.com OK; can accept 80000;voice-message:7sec; C: RCPT TO: S: 452 insufficient system media storage (voice-message) C: RCPT TO: 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: C: Subject: Mediasize SMTP extension draft Shveidel/Erev Internet draft - Expires May 15, 2004 10 SMTP Per Media Size Declaration November 2003 ... C: . S: 250 OK C: QUIT S: 250 Goodbye 8.2 Case where some quotas are associated to body parts based on its content/media context (optional scenario) S: C: 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: SIZE=80000;x-video:107sec S: 552 message media size exceeds fixed maximum message media size (x-video) C: MAIL FROM: SIZE=80000;x-audio:7min;x-video:30sec S: 250 Address Ok. C: RCPT TO: S: 250 v@comverse.com OK; can accept 80000; x-audio:7min;x- video:30sec C: RCPT TO: S: 452 insufficient system media storage (x-video) C: RCPT TO: S: 552 Mailbox media quota (x-audio) 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: C: Subject: Mediasize SMTP extension draft ... C: . S: 250 OK C: MAIL FROM: SIZE=80000;voice-message:7sec S: 250 Address Ok. Shveidel/Erev Internet draft - Expires May 15, 2004 11 SMTP Per Media Size Declaration November 2003 C: RCPT TO: S: 250 v@comverse.com OK; can accept 80000;voice-message:7sec; C: RCPT TO: 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: 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 [BNF]. Non-terminals referenced but not defined below are as defined by SMTP [SMTP] and SMTP SIZE extension [SIZE]. 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) 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 Shveidel/Erev Internet draft - Expires May 15, 2004 12 SMTP Per Media Size Declaration November 2003 mediasize-esmtp-parameter = "SIZE=" mediasize-parameter-value mediasize-parameter-value = general-size *(";" media-size) general-size = size-value media-size = media-name ":" 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 [SIZE] and use of the MAIL command with extended SIZE parameter make it somewhat quicker and easier to devise an efficacious service denial attack. Malicious client may try to deceive the server by indicating disharmonious media context (to set wrong Message-Context header in the simplest case) in order that the message be accounted to the wrong media quota class. Such a client may also declare wrong media sizes in specific units. It is recommended that the server apply authentication of trusted transfer agents authorized to transfer distinguished messages as per [SMTP-AUTH] and [STARTTLS]. Based on successful authentication of the client, the server MAY decide whether to trust the MEDIASIZE information provided. It is also recommended that an implementation supports internal media context validation and 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) differs 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 May 15, 2004 13 SMTP Per Media Size Declaration November 2003 To promote interoperability and coherent interpretations of different media contexts, a central repository for well-known media contexts and possible measurement units will be maintained. To support the mandatory level of support of media size (associate with message-context), the relevant repository is the IANA-managed "Internet Message Context Types"repository [MSG-CONTEXT]. There is a need to extend the message-context registration by registering the size units appropriate to each of the message-context values. Note: Unit names, that are started with "x-" are not registered. Such names are reserved for pre-standards experiments and should not be widely deployed. To add new possible units to a registered message context type, you MUST publish an RFC to document the unit. In the RFC, include a copy of the registration template found found in Section 11.1 of this document. Put the template in your IANA Considerations section, filling-in the appropriate fields. To create a new message context type, you MUST publish an RFC to document the type. In the RFC, include a copy of the registration template found in Section 8.2 of [MSG-CONTEXT] and (optionally) template found in Section 11.1 of this document. Put the templates in your IANA Considerations section, filling-in the appropriate fields. You MUST describe any interoperability and security issues in your document. The following is a suggested list for initial values for registration. 11.1. Message Context size units Registrations Internet Message-Context Size Units ====================================== Media Context (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" Shveidel/Erev Internet draft - Expires May 15, 2004 14 SMTP Per Media Size Declaration November 2003 11.2. Registration Template In the following template, a pipe symbol, "|", precedes instructions or other helpful material. Be sure to replace "" with the media context name you are defining. Media Context name: |Referenced Message-Context value Default measurement unit: | Name of default measurement unit for the media (US-ASCII | string not longer than 10 characters) Possible measurement units: | List of possible names of measurement unit for the media | type (each name MUST be US-ASCII string not longer than 10 | characters) Person & email address to contact for further information: | Name & e-mail 12. References [SMTP] Klensin J, "Simple Mail Transfer Protocol", STD 10, RFC 2821, AT&T Laboratories, April 2001. [RFC2822] P. Resnick, Editor, "Internet Message Format", RFC 2822, QUALCOMM Incorporated, April 2001. [SIZE] J. Klensin, WG Chair, N. Freed, Editor, K. Moore, "SMTP Service Extension for Message Size Declaration", STD10, RFC1870, University of Tennessee, November 1995. [MIME1] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC2045, Innosoft, First Virtual, November 1996. [MIME2] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC2045, Innosoft, First Virtual, November 1996. [MSG-CONTEXT] E. Burger, C. Eliot, G. Klyne, E. Candell, "Message Context for Internet Mail", RFC 3458 SnowShore Networks, Microsoft, Nine by Nine, Comverse, , January 2003. Shveidel/Erev Internet draft - Expires May 15, 2004 15 SMTP Per Media Size Declaration November 2003 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LEMONADE-GOALS] J.K. Wong (Ed.), "Goals for Internet Messaging to Support Diverse Service Environments". http://www.ietf.org/internet-drafts/draft-ietf-lemonade-goals- 00.txt [BNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2476] R. Gellens, J. Klensin, "Message Submission", RFC 2476, December 1998 [LMTP] J. Myers, "Local Mail Transfer Protocol", RFC2033, Carnegie Mellon, October 1996. [DSN] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC3464, University of Tennessee, Lucent Technologies, January 2003. [RFC3463] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC3463, Lucent Technologies, January 2003. 13. Author's Addresses Vladimir Shveidel Comverse 29 Habarzel St. Tel-Aviv 69710 Israel 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: Shveidel/Erev Internet draft - Expires May 15, 2004 16 SMTP Per Media Size Declaration November 2003 - 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 [MSG-CONTEXT]). - As a result, the central repository for well-known media contexts 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). Changes to version 03: - Limit the use to SMTP-Submit cases (RFC 2476), ase per feedback received in IETF-Lemonade meeting (IETF 57, Vienna, 2003) - Add the main benefit of using this extension (Client-server coordination prior to actual data transfer). - Other minor typos. Changes to version 04: Mainly thanks to Chris Newman's review: - ID_nits compliance. - Update reference to 822 to 2822, and 1428 to 1870. - Changed 1425,1869 references to 2821. - Added note about increase in MAIL FROM maximum length. - Applicability to LMTP. - Added error condition when length greater than max 32-bit integer. - Added that media size limits can be different after authentication. - Changed ABNF so that it can be validated. - Added discussion in security considerations chapter. Shveidel/Erev Internet draft - Expires May 15, 2004 17 SMTP Per Media Size Declaration November 2003 - Added reference to DSN enhanced status codes (RFC 3463) - Added limitation that media name should appear only once in EHLO. - Changed all occurances of "Extended MAIL command" to "MAIL command with extended SIZE parameter". - Added references to MIME specs. - Measurement unit names should be US-ASCII. - Fixed typos. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. 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 May 15, 2004 18