idnits 2.17.1 

draft-vaudreuil-esmtp-binary2-03.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** Looks like you're using RFC 2026 boilerplate.  This must be updated to
     follow RFC 3978/3979, as updated by RFC 4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  ** Missing expiration date.  The document expiration date should appear on
     the first and last page.

  ** The document seems to lack a 1id_guidelines paragraph about
     Internet-Drafts being working documents. 

  ** The document seems to lack a 1id_guidelines paragraph about 6 months
     document validity. 

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  == The page length should not exceed 58 lines per page, but there was 12
     longer pages, the longest (page 2) being 61 lines


  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** The document seems to lack an IANA Considerations section.  (See Section
     2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
     when there are no actions for IANA.)

  ** The document seems to lack separate sections for Informative/Normative
     References.  All references will be assumed normative when checking for
     downward references.

  ** There are 111 instances of too long lines in the document, the longest
     one being 3 characters in excess of 72.

  ** The abstract seems to contain references ([RFC2119]), which it
     shouldn't.  Please replace those with straight textual mentions of the
     documents in question.

  == There are 6 instances of lines with non-RFC2606-compliant FQDNs in the
     document.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  == Line 448 has weird spacing: '...for the  purpo...'

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (October 19, 2000) is 8589 days in the past.  Is this
     intentional?

  -- Found something which looks like a code comment -- if you have code
     sections in the document, please surround them with '<CODE BEGINS>' and
     '<CODE ENDS>' lines.


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'Submit' is mentioned on line 257, but not defined

  == Missing Reference: '8bit' is mentioned on line 305, but not defined

  == Unused Reference: 'BINARY' is defined on line 402, but no explicit
     reference was found in the text

  == Unused Reference: 'SUBMIT' is defined on line 415, but no explicit
     reference was found in the text

  ** Obsolete normative reference: RFC 1830 (ref. 'BINARY') (Obsoleted by RFC
     3030)

  ** Obsolete normative reference: RFC  821 (Obsoleted by RFC 2821)

  ** Obsolete normative reference: RFC  822 (Obsoleted by RFC 2822)

  ** Obsolete normative reference: RFC 2476 (ref. 'SUBMIT') (Obsoleted by RFC
     4409)

  ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC
     2821)

  ** Obsolete normative reference: RFC 1652 (ref. '8BIT') (Obsoleted by RFC
     6152)


     Summary: 14 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------

1	     Internet Draft                                       Greg Vaudreuil
2	     Expires in six months                           Lucent Technologies
3	                                                        October 19, 2000

5	                            SMTP Service Extensions
6	                           for Transmission of Large
7	                            and Binary MIME Messages

9	                     <draft-vaudreuil-esmtp-binary2-03.txt

11	  Status of this Memo

13	     This document is an Internet-Draft and is in full conformance with all
14	     provisions of Section 10 of RFC 2026.

16	     This document is an Internet Draft.  Internet Drafts are working
17	     documents of the Internet Engineering Task Force (IETF), its Areas,
18	     and its Working Groups.  Note that other groups may also distribute
19	     working documents as Internet Drafts.

21	     Internet Drafts are valid for a maximum of six months and may be
22	     updated, replaced, or obsoleted by other documents at any time.  It is
23	     inappropriate to use Internet Drafts as reference material or to cite
24	     them other than as a "work in progress".

26	     The list of current Internet-Drafts can be accessed at
27	     http://www.ietf.org/ietf/1id-abstracts.txt

29	     The list of Internet-Draft Shadow Directories can be accessed at
30	     http://www.ietf.org/shadow.html.

32	     To learn the current status of any Internet-Draft, please check the
33	     "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
34	     Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
35	     munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
36	     ftp.isi.edu (US West Coast).

38	  Copyright Notice

40	     Copyright (C) The Internet Society (2000).  All Rights Reserved.

42	     This Internet-Draft is in conformance with Section 10 of RFC 2026.

44	  Abstract

46	     This memo defines two extensions to the SMTP service.  The first
47	     extension enables a SMTP client and server to negotiate the use of an
48	     alternative to the DATA command, called "BDAT", for efficiently
49	     sending large MIME messages.  The second extension takes advantage of
50	     the BDAT command to permit the negotiated sending of MIME messages
51	     that employ the binary transfer encoding. This document is intended to
52	     update and obsolete RFC1830.

54	  Working Group Summary

56	     This protocol is not the product of an IETF working group, however the
57	     specification resulted from discussions within the ESMTP working
58	     group.  The resulting protocol documented in RFC1830 was classified as
59	     experimental at that time due to questions about the robustness of the
60	     Binary Content-Transfer-Encoding deployed in then existent MIME
61	     implementations.  As MIME has matured and other uses of the Binary
62	     Content-Transfer-Encoding have been deployed, these concerns have been
63	     allayed.  With this document, Binary ESMTP is expected to become
64	     standards-track.

66	  Document Conventions

68	     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
69	     "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
70	     document are to be interpreted as described in RFC-2119 [RFC2119].

72	  Table of Contents

74	  1.   OVERVIEW ..........................................................2
75	  2.   FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3
76	  3.   FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................6
77	  4.   EXAMPLES ..........................................................8
78	    4.1  Simple Chunking .................................................8
79	    4.2  Pipelining BINARYMIME ...........................................9
80	  5.   SECURITY CONSIDERATIONS ..........................................10
81	  6.   REFERENCES .......................................................10
82	  7.   COPYRIGHT NOTICE .................................................10
83	  8.   AUTHOR'S ADDRESS .................................................11
84	  9.   APPENDIX A - CHANGES FROM RFC1830 ................................12

86	  1. Overview

88	     The MIME extensions to the Internet message format provides for the
89	     transmission of many kinds of data that were previously unsupported in
90	     Internet mail.  Anticipating the need to transport the new media more
91	     efficiently, the SMTP protocol has been extended to provide transport
92	     for new message types.  RFC 1652 defines one such extension for the
93	     transmission of unencoded 8-bit MIME messages [8BIT].  This service
94	     extension permits the receiver SMTP to declare support for 8-bit body
95	     parts and the sender to request 8-bit transmission of a particular
96	     message.

98	     One expected result of the use of MIME is that the Internet mail
99	     system will be expected to carry very large mail messages.  In such
100	     transactions, there is a performance-based desire to eliminate the
101	     requirement that the message be scanned for "CR LF . CR LF" sequences
102	     upon sending and receiving to detect the end of message.

104	     Independent of the need to send large messages, Internet mail is
105	     increasingly multimedia.  There is a need to avoid the overhead of
106	     base64 and quoted-printable encoding of binary objects sent using the
107	     MIME message format over SMTP between hosts that support binary
108	     message processing.

110	     This memo uses the mechanism defined in [ESMTP] to define two
111	     extensions to the SMTP service whereby an SMTP server ("receiver-
112	     SMTP") may declare support for the message chunking transmission mode
113	     and support for the receiption of Binary messages, which the SMTP
114	     client ("sender-SMTP") is then free to use.

116	  2. Framework for the Large Message Extensions

118	     The following service extension is hereby defined:

120	     1) The name of the data chunking service extension is "CHUNKING".

122	     2) The EHLO keyword value associated with this extension is
123	     "CHUNKING".

125	     3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA"
126	     command of [RFC821]. The BDAT verb takes two arguments.  The first
127	     argument indicates the length, in octets, of the binary data chunk.
128	     The second optional argument indicates that the data chunk is the
129	     last.

131	        bdat-cmd   ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
132	        chunk-size ::= 1*DIGIT
133	        end-marker ::= "LAST"

135	     4) This extension may be used for SMTP message submission. [Submit]

137	     5) Servers that offer the BDAT extension MUST continue to support the
138	     regular SMTP DATA command. Clients are free to use DATA to transfer
139	     appropriately encoded to servers that support the CHUNKING extension
140	     if they wish to do so.

142	     The CHUNKING service extension enables the use of the BDAT alternative
143	     to the DATA command.  This extension can be used for any message,
144	     whether 7-bit, 8BITMIME or BINARYMIME.

146	     When a sender-SMTP wishes to send (using the MAIL command) a large
147	     message using the CHUNKING extension, it first issues the EHLO command
148	     to the receiver-SMTP.  If the receiver-SMTP responds with code 250 to
149	     the EHLO command and the response includes the EHLO keyword value
150	     CHUNKING, then the receiver-SMTP is indicating that it supports the
151	     BDAT command and will accept the sending of messages in chunks.

153	     After all MAIL and RCPT responses are collected and processed, the
154	     message is sent using a series of BDAT commands.  The BDAT command
155	     takes one required argument, the exact length of the data segment in
156	     octets.  The message data is sent immediately after the trailing <CR>
157	     <LF> of the BDAT command line.  Once the receiver-SMTP receives the
158	     specified number of octets, it will return a 250 reply code.

160	     The optional LAST parameter on the BDAT command indicates that this is
161	     the last chunk of message data to be sent.  The last BDAT command MAY
162	     have a byte-count of zero indicating there is no additional data to be
163	     sent. Any BDAT command sent after the BDAT LAST is illegal and MUST be
164	     replied to with a 503 "Bad sequence of commands" reply code. The state
165	     resulting from this error is indeterminate.  A RSET command MUST be
166	     sent to clear the transaction before continuing.

168	     A 250 response MUST be sent to each successful BDAT data block within
169	     a mail transaction.  If a failure occurs after a BDAT command is
170	     received, the receiver-SMTP MUST accept and discard the associated
171	     message data before sending the appropriate 5XX or 4XX code.  If a 5XX
172	     or 4XX code is received by the sender-SMTP in response to a BDAT
173	     chunk, the transaction should be considered failed and the sender-SMTP
174	     MUST NOT send any additional BDAT segments. If the receiver-SMTP has
175	     declared support for command pipelining [PIPE], the receiver SMTP MUST
176	     be prepared to accept and discard additional BDAT chunks already in
177	     the pipeline after the failed BDAT.

179	          Note: An error on the receiver-SMTP such as disk full or imminent
180	          shutdown can only be reported after the BDAT segment has been
181	          received.  It is therefore important to choose a reasonable chunk
182	          size given the expected end-to-end bandwidth.

184	          Note:  Because the receiver-SMTP does not acknowledge the BDAT
185	          command before the message data is sent, it is important to send
186	          the BDAT only to systems that have declared their capability to
187	          accept BDAT commands. Illegally sending a BDAT command and
188	          associated message data to a non-CHUNKING capable system will
189	          result in the receiver-SMTP parsing the associated message data
190	          as if it were a potentially very long, ESMTP command line
191	          containing binary data.

193	     The resulting state from a failed BDAT command is indeterminate.  A
194	     RSET command MUST be issued to clear the transaction before additional
195	     commands may be sent. The RSET command, when issued after the first
196	     BDAT and before the BDAT LAST, clears all segments sent during that
197	     transaction and resets the session.

199	     DATA and BDAT commands cannot be used in the same transaction.  If a
200	     DATA statement is issued after a BDAT for the current transaction, a
201	     503 "Bad sequence of commands" MUST be issued.  The state resulting
202	     from this error is indeterminate.  A RSET command MUST be sent to
203	     clear the transaction before continuing.  There is no prohibition on
204	     using DATA and BDAT in the same session, so long as they are not mixed
205	     in the same transaction.

207	     The local storage size of a message may not accurately reflect the
208	     actual size of the message sent due to local storage conventions.  In
209	     particular, text messages sent with the BDAT command MUST be sent in
210	     the canonical MIME format with lines delimited with a <CR><LF>.  It
211	     may not be possible to convert the entire message to the canonical
212	     format at once. CHUNKING provides a mechanism to convert the message
213	     to canonical form, accurately count the bytes, and send the message a
214	     single chunk at a time.

216	          Note: Correct byte counting is essential.  If the sender-SMTP
217	          indicates a chunk-size larger than the actual chunk-size, the
218	          receiver-SMTP will continue to wait for the remainder of the
219	          data or when using streaming, will read the subsequent command
220	          as additional message data.  In the case where a portion of the
221	          previous command was read as data, the parser will return a
222	          syntax error when the incomplete command is read.

224	          If the sender-SMTP indicates a chunk-size smaller than the
225	          actual chunk-size, the receiver-SMTP will interpret the
226	          remainder of the message data as invalid commands.  Note that
227	          the remainder of the message data may be binary and as such
228	          lexicographical parsers MUST be prepared to receive, process,
229	          and reject lines of arbitrary octets.

231	  3. Framework for the Binary Service Extension

233	     The following service extension is hereby defined:

235	     1) The name of the binary service extension is "BINARYMIME".

237	     2) The EHLO keyword value associated with this extension is
238	     "BINARYMIME".

240	     3) The BINARYMIME service extension can only be used with the
241	     "CHUNKING" service extension.

243	     4) No parameter is used with the BINARYMIME keyword.

245	     5) [8BIT] defines the BODY parameter for the MAIL command.  This
246	     extension defines an additional value for the BODY parameter,
247	     "BINARYMIME". The value "BINARYMIME" associated with this parameter
248	     indicates that this message is a Binary MIME message (in strict
249	     compliance with [MIME]) with arbitrary octet content being sent. The
250	     revised syntax of the value is as follows, using the ABNF notation of
251	     [RFC822]:

253	                 body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"

255	     6) No new verbs are defined for the BINARYMIME extension.

257	     7) This extension may be used for SMTP message submission. [Submit]

259	     8) The maximum length of a MAIL FROM command line is increased by 16
260	     characters by the possible addition of the BODY=BINARYMIME keyword and
261	     value;.

263	     A sender-SMTP may request that a binary MIME message be sent without
264	     transport encoding by sending a BODY parameter with a value of
265	     "BINARYMIME" with the MAIL command.  When the receiver-SMTP accepts a
266	     MAIL command with the BINARYMIME body-value, it agrees to preserve all
267	     bits in each octet passed using the BDAT command. Once a receiver-SMTP
268	     supporting the BINARYMIME service extension accepts a message
269	     containing binary material, the receiver-SMTP MUST deliver or relay
270	     the message in such a way as to preserve all bits in each octet.

272	     BINARYMIME cannot be used with the DATA command.  If a DATA command is
273	     issued after a MAIL command containing the body-value of "BINARYMIME",
274	     a 503 "Bad sequence of commands" response MUST be sent.  The resulting
275	     state from this error condition is indeterminate and the transaction
276	     MUST be reset with the RSET command.

278	     It is especially important when using BINARYMIME to ensure that the
279	     MIME message itself is properly formed.  In particular, it is
280	     essential that text be canonically encoded with each line properly
281	     terminated with <CR><LF>.  Any transformation of text into non-
282	     canonical MIME to observe local storage conventions MUST be reversed
283	     before sending as BINARYMIME.  Some line-oriented shortcuts will break
284	     if used with BINARYMIME. A sender-SMTP MUST use the canonical encoding
285	     for a given MIME content-type.  In particular, text/* MUST be sent
286	     with <CR><LF> terminated lines.

288	     Note: Although CR and LF do not necessarily represent ends of text
289	     lines in BDAT chunks and use of the binary transfer encoding is
290	     allowed, the RFC 2781 prohibition against using a UTF-16 charset
291	     within the text top-level media type remains.

293	     The syntax of the extended MAIL command is identical to the MAIL
294	     command in [RFC821], except that a BODY=BINARYMIME parameter and value
295	     MUST be added. The complete syntax of this extended command is defined
296	     in [ESMTP].

298	     If a receiver-SMTP does not indicate support the BINARYMIME message
299	     format then the sender-SMTP MUST NOT, under any circumstances, send
300	     binary data.

302	     If the receiver-SMTP does not support BINARYMIME and the message to be
303	     sent is a MIME object with a binary encoding, a sender-SMTP has three
304	     options with which to forward the message. First, if the receiver-SMTP
305	     supports the 8bit-MIMEtransport extension [8bit] and the content is
306	     amenable to being encoded in 8bit, the sender-SMTP may implement a
307	     gateway transformation to convert the message into valid 8bit-encoded
308	     MIME. Second, it may implement a gateway transformation to convert the
309	     message into valid 7bit-encoded MIME. Third, it may treat this as a
310	     permanent error and handle it in the usual manner for delivery
311	     failures. The specifics of MIME content-transfer-encodings, including
312	     transformations from Binary MIME to 8bit or 7bit MIME are not
313	     described by this RFC; the conversion is nevertheless constrained in
314	     the following ways:

316	          1. The conversion MUST cause no loss of information;  MIME
317	     transport encodings MUST be employed as needed to insure this is the
318	     case.

320	          2. The resulting message MUST be valid 7bit or 8bit MIME.  In
321	     particular, the transformation MUST NOT result in nested Base-64 or
322	     Quoted-Printable content-transfer-encodings.

324	     Note that at the time of this writing there are no mechanisms for
325	     converting a binary MIME object into an 8-bit MIME object. Such a
326	     transformation will require the specification of a new MIME content-
327	     transfer-encoding.

329	     If the MIME message contains a "Binary" content-transfer-encoding and
330	     the BODY parameter does not indicate BINARYMIME, the message MUST be
331	     accepted.  The message SHOULD be returned to the sender with an
332	     appropriate DSN.  The message contents MAY be returned to the sender
333	     if the offending content can be mangled into a legal DSN structure.
334	     "Fixing" and forwarding the offending content is beyond the scope of
335	     this document.

337	  4. Examples

339	  4.1 Simple Chunking

341	     The following simple dialogue illustrates the use of the large message
342	     extension to send a short pseudo-RFC822 message to one recipient using
343	     the CHUNKING extension:

345	     R: <wait for connection on TCP port 25>
346	     S: <open connection to server>
347	     R: 220 cnri.reston.va.us SMTP service ready
348	     S: EHLO ymir.claremont.edu
349	     R: 250-cnri.reston.va.us says hello
350	     R: 250 CHUNKING
351	     S: MAIL FROM:<Sam@Random.com>
352	     R: 250 <Sam@Random.com> Sender ok
353	     S: RCPT TO:<Susan@Random.com>
354	     R: 250 <Susan@random.com> Recipient ok
355	     S: BDAT 86 LAST
356	     S: To: Susan@random.com<CR><LF>
357	     S: From: Sam@random.com<CR><LF>
358	     S: Subject: This is a bodyless test message<CR><LF>
359	     R: 250 Message OK, 86 octets received
360	     S: QUIT
361	     R: 221 Goodbye

363	  4.2 Pipelining BINARYMIME

365	     The following dialogue illustrates the use of the large message
366	     extension to send a BINARYMIME object to two recipients using the
367	     CHUNKING and PIPELINING extensions:

369	     R: <wait for connection on TCP port
370	     S: <open connection to server>
371	     R: 220 cnri.reston.va.us SMTP service ready
372	     S: EHLO ymir.claremont.edu
373	     R: 250-cnri.reston.va.us says hello
374	     R: 250-PIPELINING
375	     R: 250-BINARYMIME
376	     R: 250 CHUNKING
377	     S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
378	     S: RCPT TO:<gvaudre@cnri.reston.va.us>
379	     S: RCPT TO:<jstewart@cnri.reston.va.us>
380	     R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
381	     R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
382	     R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
383	     S: BDAT 100000
384	     S: (First 10000 octets of canonical MIME message data)
385	     S: BDAT 324
386	     S: (Remaining 324 octets of canonical MIME message data)
387	     S: BDAT 0 LAST
388	     R: 250 100000 octets received
389	     R: 250 324 octets received
390	     R: 250 Message OK, 100324 octets received
391	     S: QUIT
392	     R: 221 Goodbye

394	  5. Security Considerations

396	     This extension is not known to present any additional security issues
397	     not already endemic to electronic mail and present in fully conforming
398	     implementations of [RFC821], or otherwise made possible by [MIME].

400	  6. References

402	     [BINARY] Vaudreuil, G, " SMTP Service Extensions for Transmission of
403	     Large and Binary MIME Messages", RFC 1830, August 1995.

405	     [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
406	     USC/Information Sciences Institute, August 1982.

408	     [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
409	     Messages", STD 11, RFC 822, UDEL, August 1982.

411	     [MIME] N. Borenstein, and N. Freed, "Multipurpose Internet Mail
412	     Extensions (MIME) Part One: Format of Internet Message Bodies", RFC
413	     2045, Bellcore, Innosoft, November 1996.

415	     [SUBMIT] R. Gellens, and J. Klensin, "Message Submission", RFC 2476,
416	     Qualcomm, MCI, December 1998.

418	     [ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
419	     E., and D. Crocker, "SMTP Service Extensions" RFC 1869, United Nations
420	     University, Innosoft International, Inc., Dover Beach Consulting,
421	     Inc., Network Management Associates, Inc., The Branch Office, November
422	     1995.

424	     [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
425	     E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport"
426	     RFC 1652, United Nations University, Innosoft International, Inc.,
427	     Dover Beach Consulting, Inc., Network Management Associates, Inc., The
428	     Branch Office, July 1994.

430	     [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining",
431	     RFC 2920, Innosoft, September 2000.

433	     [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
434	     Requirement Levels", RFC 2119, Harvard, March 1997.

436	  7. Copyright Notice

438	     "Copyright (C) The Internet Society (2000). All Rights Reserved.

440	     This document and translations of it may be copied and furnished to
441	     others, and derivative works that comment on or otherwise explain it
442	     or assist in its implementation may be prepared, copied, published and
443	     distributed, in whole or in part, without restriction of any kind,
444	     provided that the above copyright notice and this paragraph are
445	     included on all such copies and derivative works.  However, this
446	     document itself may not be modified in any way, such as by removing
447	     the copyright notice or references to the Internet Society or other
448	     Internet organizations, except as needed for the  purpose of
449	     developing Internet standards in which case the procedures for
450	     copyrights defined in the Internet Standards process MUST be followed,
451	     or as required to translate it into languages other than English.

453	     The limited permissions granted above are perpetual and will not be
454	     revoked by the Internet Society or its successors or assigns.

456	     This document and the information contained herein is provided on an
457	     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
458	     TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
459	     NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
460	     WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
461	     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

463	  8. Author's Address

465	     Gregory M. Vaudreuil
466	     Lucent Technologies
467	     17080 Dallas Parkway
468	     Dallas, TX 75248-1905
469	     Voice/Fax: +1-972-733-2722
470	     GregV@ieee.org

472	  9. Appendix A - Changes from RFC1830

474	     Numerous editorial changes including required intellectual property
475	     boilerplate and revised authors contact information

477	     Corrected the simple chunking example to use the correct number of
478	     bytes.  Updated the pipelining example to illustrate use of the BDAT 0
479	     LAST construct.