--RAA14128.773615765/mega.edu
content-type: message/disposition-notification
Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@mega.edu
Final-Recipient: rfc822;Joe_Recipient@mega.edu
Original-Message-ID: <199509192301.23456@huge.com>
Disposition: manual-action/MDN-sent-manually; displayed
--RAA14128.773615765/mega.edu
content-type: message/rfc822
[original message goes here]
--RAA14128.773615765/mega.edu--
10. IANA Registration Forms
The forms below are for use when registering a new parameter name for
the Disposition-Notification-Options header, a new disposition
modifier name, or a new MDN extension field. Each piece of
information required by a registration form may be satisfied either
by providing the information on the form itself, or by including a
reference to a published, publicly available specification that
includes the necessary information. IANA MAY reject registrations
because of incomplete registration forms, imprecise specifications,
or inappropriate names.
To register, complete the applicable form below and send it via
electronic mail to <IANA@IANA.ORG>.
10.1 IANA registration form for Disposition-Notification-Options header
parameter names
A registration for a Disposition-Notification-Options header
parameter name MUST include the following information:
(a) The proposed parameter name.
(b) The syntax for parameter values, specified using BNF, ABNF,
regular expressions, or other non-ambiguous language.
(c) If parameter values are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how they
are to be encoded as graphic US-ASCII characters in a Disposition-
Notification-Options header.
(d) A reference to a standards track RFCor experimental RFCapproved
by the IESG that describes the semantics of the parameter values.
10.2 IANA registration form for disposition modifer names
A registration for a disposition-modifier name MUST include the
following information:
(a) The proposed disposition-modifier name.
(b) A reference to a standards track RFCor experimental RFCapproved
by the IESG that describes the semantics of the disposition modifier.
10.3 IANA registration form for MDN extension field names
A registration for an MDN extension field name MUST include the
following information:
(a) The proposed extension field name.
(b) The syntax for extension values, specified using BNF, ABNF,
regular expressions, or other non-ambiguous language.
(c) If extension field values are not composed entirely of graphic
characters from the US-ASCII repertoire, a specification for how they
are to be encoded as graphic US-ASCII characters in a Disposition-
Notification-Options header.
(d) A reference to a standards track RFCor experimental RFCapproved
by the IESG that describes the semantics of the extension field.
11. Acknowledgments
This document is based on the Delivery Status Notifications document,
RFC1894 [9], by Keith Moore and Greg Vaudreuil. Contributions were
made by members of the IETF Receipt Working Group, including Harald
Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned
Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell,
Pete Resnick, Chuck Shih.
12. References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, August 1982.
[3] Braden, R. (ed.), "Requirements for Internet Hosts -
Application and Support", STD 3, RFC1123, October 1989.
[4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC2045, November 1996.
[5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046, November
1996.
[6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part
Three: Message Header Extensions for Non-Ascii Text", RFC
2047, November 1996.
[7] Vaudreuil, G., "The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages", RFC1892,
January 1996.
[8] Moore, K., "SMTP Service Extension for Delivery Status
Notifications", RFC1891, January 1996.
[9] Moore, K., and G. Vaudreuil, "An Extensible Format for
Delivery Status Notifications, RFC1894, January 1996.
[10] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
13. Author's Address
Roger Fajman
National Institutes of Health
Building 12A, Room 3063
12 South Drive MSC 5659
Bethesda, Maryland 20892-5659
USA
EMail: raf@cu.nih.gov
Phone: +1 301 402 4265
Fax: +1 301 480 6241
14. Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.