Browse Prior Art Database

Indicating Supported Media Features Using Extensions to DSN and MDN (RFC2530)

IP.com Disclosure Number: IPCOM000003116D
Original Publication Date: 1999-Mar-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Wing: AUTHOR

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 text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 42% of the total text.

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].

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 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...