summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2530.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2530.txt')
-rw-r--r--doc/rfc/rfc2530.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc2530.txt b/doc/rfc/rfc2530.txt
new file mode 100644
index 0000000..810ef30
--- /dev/null
+++ b/doc/rfc/rfc2530.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group D. Wing
+Request for Comments: 2530 Cisco Systems
+Category: Standards Track March 1999
+
+
+ Indicating Supported Media Features Using
+ Extensions to DSN and MDN
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+1. Abstract
+
+ There is a need in Internet mail and Internet fax for a recipient to
+ indicate the media features it supports so that messages can be
+ generated by senders without exceeding the recipient's abilities.
+
+ This memo describes a format for generating Message Disposition
+ Notifications [RFC2298] and Delivery Status Notifications [RFC1894]
+ which contain such information. This information can be used by
+ senders to avoid exceeding the recipient's capabilities when sending
+ subsequent messages.
+
+2. Introduction
+
+ The extensions described in this document can be used in Message
+ Disposition Notifications [RFC2298] or Delivery Status Notifications
+ [RFC1894], as appropriate for the implementation.
+
+ Note that both DSNs and MDNs have drawbacks: DSNs are not available
+ between all senders and receivers, and MDNs require the receiver to
+ disclose message disposition information (or, if using the "denied"
+ disposition-type, the time the disposition notification was
+ generated).
+
+ 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].
+
+
+
+
+Wing Standards Track [Page 1]
+
+RFC 2530 Media Features using DSN and MDN March 1999
+
+
+3. Extensions for use by DSN and MDN
+
+ The following extension is available to both DSN [RFC1894] and MDN
+ [RFC2298] messages.
+
+ For a DSN message, the following per-recipient fields are defined
+ (section 2.3 of [RFC1894]). For an MDN message, the following
+ extension fields are defined (section 3.1 of [RFC2298]). Using the
+ language of [RFC2234]:
+
+ extension-field = media-features CRLF
+
+ media-features = "Media-Accept-Features" ":"
+ media-feature-tags
+ media-feature-tags = <*text as defined below,
+ with LWSP wrapping>
+
+ The <media-feature-tags> are defined in separate schema documents
+ which MUST utilize the language described in [SYNTAX]. The schema
+ MUST be registered following the registration requirements of
+ [RFC2506].
+
+3.1. Examples
+
+ The following examples assume there is a schema document which
+ defines the tags shown.
+
+3.1.1. Paper-size and Color
+
+ Assuming there is a schema document which describes the tags paper-
+ size and color, the following example is valid:
+
+ Media-Accept-Features: (& (paper-size=a4) (color=binary) )
+
+3.1.2. UA-Media, Paper-size, and Color
+
+ Assuming there is a schema document which describes the tags paper-
+ size, color, and grey:
+
+ Media-Accept-Features: (& (| (paper-size=a4) (paper-size=letter) )
+ (| (& (color=grey) (dpi=200) (dpi-xyratio=200/100) )
+ (& (color=limited) (dpi=200) (dpi-xy=200/100) ) )
+
+4. MTA Implmentation Recommendation
+
+ If the recipient's MTA determines that a message cannot be processed,
+ the recipient's MTA is strongly encouraged to reject the message with
+ a status code of 5.6.1 [RFC1893]. This status code may be returned
+
+
+
+Wing Standards Track [Page 2]
+
+RFC 2530 Media Features using DSN and MDN March 1999
+
+
+ in response to the end-of-mail-data indicator if the MTA supports
+ reporting of enhanced error codes [RFC2034], or after message
+ reception by generating a delivery failure DSN ("bounce").
+
+5. Security Considerations
+
+ Inaccurate media feature information could cause a denial of service,
+ causing subsequent messages to be sent which the recipient is unable
+ to process.
+
+ The media feature information could be inaccurate due to a malicious
+ attack (spoofed DSN or MDN) or misconfiguration.
+
+6. Acknowledgments
+
+ The author thanks the members of the Internet Fax working group for
+ assistance with this document, and especially Larry Masinter, Graham
+ Klyne, and Ned Freed.
+
+7. References
+
+ [RFC2506] Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
+ Registration Procedure", BCP 31, RFC 2506, March 1999.
+
+ [RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format
+ for Delivery Status Notifications", RFC 1894, January 1996.
+
+ [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
+ Error Codes", RFC 2034, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2298] Fajman, R., "An Extensible Message Format for Message
+ Disposition Notifications", RFC 2298, March 1998.
+
+ [SYNTAX] Klyne, G., "A Syntax for Describing Media Feature Sets",
+ RFC 2533, March 1999.
+
+
+
+
+
+
+
+
+
+
+Wing Standards Track [Page 3]
+
+RFC 2530 Media Features using DSN and MDN March 1999
+
+
+8. Author's Address
+
+ Dan Wing
+ Cisco Systems, Inc.
+ 101 Cooper Street
+ Santa Cruz, CA 95060 USA
+
+ Phone: +1 831 457 5200
+ Fax: +1 831 457 5208
+ EMail: dwing@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wing Standards Track [Page 4]
+
+RFC 2530 Media Features using DSN and MDN March 1999
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wing Standards Track [Page 5]
+