This is a general comment, but applies here, too. It would be extremely useful if the MIME type registration contained some indication of what the subtype name (in this case "red") stands for. Even in the full draft I didn't find this. In the specific case at hand, it may be better to choose a more descriptive name (my guess is that "red" is supposed to stand for "redundant"). Also, the draft at http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-05.txt has serious formatting problems (undecoded quoted printable garbage). Regards, Martin. At 06:11 05/03/24, Allison Mankin wrote:
The Transport Area requests a Media Type review for the proposed type text/red, intended for the IETF tree, as a Proposed Standard. The specification is http://www.ietf.org/internet-drafts/draft-ietf-avt-text-red-05.txt.
This document had both a formal Applications AD Review and an active IETF Last Call discussion to date. During the latter, an approach of defining a "Restrictions on Usage" field for a sub-type in major type such as text that will be transported only by RTP was devised. The description of this field is found in draft-freed-media-reg-02.txt, currently in IETF Last Call itself.
As the result of this, please review the following media registration for text/red instead of the one in the i-d (but read other sections in the i-d as needed):
MIME media type name: text
MIME subtype name: red
Required parameters: rate: the RTP clock rate of the payload carried within the RTP packet. Typically, this rate is 1000, but other rates MAY be specified. This parameter MUST be set equal to the clock rate of the text payload format carried as the primary encoding.
pt: a comma-separated ordered list of RTP payload types enumerating the primary, secondary, etc., in accordance with RFC 2198. Because comma is a special character, the list MUST be a quoted-string (enclosed in double quotes). For static payload types, each list element is simply the type number. For dynamic payload types, each list element is a mapping of the dynamic payload type number to an embedded MIME content- type specification for the payload format corresponding to the dynamic payload type. The format of the mapping is:
dynamic-payload-type = content-type
If the content-type string includes a comma, then the content- type string MUST be a quoted-string. If the content-type string does not include a comma, it MAY still be quoted. Since it is part of the list which must itself be a quoted-string, that means the quotation marks MUST be quoted with backslash quoting as specified in RFC 2045 [4]. If the content-type string itself contains a quoted-string, then the requirement for backslash quoting is recursively applied.
Optional parameters: ptime, maxptime (these attributes are originally defined in RFC 2327 and RFC 3267 respectively)
Restrictions on Usage: This type is defined only for transfer for RTP. It shall not be defined for a storage format.
Encoding considerations: See Restrictions on Usage above; this section is included per the requirements in RFC 3555.
Security considerations: Refer to section 5 of RFC XXXX. (XXXX is a reference to the RFC number to be assigned to draft-ietf-avt-text-red-0t.txt)
Interoperability considerations: none
Published specification: RFC XXXX.
Applications which use this media type: Text streaming and conferencing tools.
Additional information: none
Person & email address to contact for further information: Paul E. Jones E-mail: paulej@packetizer.com
Intended usage: COMMON
Author: Paul E. Jones paulej@packetizer.com
Change Controller: AVT Working Group delegated from the IESG
Please provide any comments before 6 April 2005.
Thanks,
Allison