< draft-ietf-avt-fecmime-00.txt		draft-ietf-avt-fecmime-01.txt >
	Internet Engineering Task Force AVT WG		Internet Engineering Task Force AVT WG
	Internet Draft J.Rosenberg,H.Schulzrinne		Internet Draft J.Rosenberg,H.Schulzrinne
	draft-ietf-avt-fecmime-00.txt dynamicsoft,Columbia U.		draft-ietf-avt-fecmime-01.txt dynamicsoft,Columbia U.
	January 3, 2000		March 10, 2000
	Expires: July 2, 2000		Expires: September, 2000
	Registration of parityfec MIME types		Registration of parityfec MIME types
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 37 ¶
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	The RTP payload format for generic forward error correction allows		The RTP payload format for generic forward error correction allows
	RTP participants to improve loss resiliency through the use of		RTP participants to improve loss resiliency through the use of
	traditional parity based channel codes. This payload format requires		traditional parity based channel codes. This payload format requires
	two new MIME types, audio/parityfec and video/parityfec. This		four new MIME types, audio/parityfec, video/parityfec, text/parityfec
	document serves as the MIME type registration for those formats.		and application/parityfec. This document serves as the MIME type
			registration for those formats.
	1 Introduction		1 Introduction
	The RTP payload format for generic forward error correction [1]		The RTP payload format for generic forward error correction [1]
	allows RTP participants to improve loss resiliency through the use of		allows RTP participants to improve loss resiliency through the use of
	traditional parity based channel codes. This payload format requires		traditional parity based channel codes. This payload format requires
	two new MIME types, audio/parityfec and video/parityfec. RFC 2048 [2]		four new MIME types, audio/parityfec, video/parityfec,
	defines procedures for registration of new MIME types within the IETF		text/paritfyfec and application/parityfec. RFC 2048 [2] defines
	tree. Furthermore, the Audio/Video Transport working group has		procedures for registration of new MIME types within the IETF tree.
	defined additional procedures that must be followed when registering		Furthermore, the Audio/Video Transport working group has defined
	RTP payload formats [3]. This document serves as the MIME type		additional procedures that must be followed when registering RTP
			payload formats [3]. This document serves as the MIME type
	registration for those formats based on those procedures.		registration for those formats based on those procedures.
	2 Registration of audio/parityfec		2 Registration of audio/parityfec
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type audio/parityfec		Subject: Registration of MIME media type audio/parityfec
	MIME media type name: audio		MIME media type name: audio
	skipping to change at page 3, line 34 ¶		skipping to change at page 3, line 35 ¶
	registration tree.		registration tree.
	RTP and SDP Issues: Usage of this format within RTP and the		RTP and SDP Issues: Usage of this format within RTP and the
	Session Description Protocol (SDP) [6] are fully specified		Session Description Protocol (SDP) [6] are fully specified
	within RFC 2733 [1].		within RFC 2733 [1].
	3 Registration of video/parityfec		3 Registration of video/parityfec
	To: ietf-types@iana.org		To: ietf-types@iana.org
	Subject: Registration of MIME media type audio/parityfec		Subject: Registration of MIME media type video/parityfec
	MIME media type name: video		MIME media type name: video
	MIME subtype name: parityfec		MIME subtype name: parityfec
	Required parameters: none		Required parameters: none
	Note that [3] mandates that RTP payload formats without a		Note that [3] mandates that RTP payload formats without a
	defined rate must define a rate parameter as part of their		defined rate must define a rate parameter as part of their
	MIME registration. The payload format for generic forward		MIME registration. The payload format for generic forward
	error correction [1] does not specify a rate parameter.		error correction [1] does not specify a rate parameter.
	However, the rate for FEC data is equal to the rate of the		However, the rate for FEC data is equal to the rate of the
	media data it protects.		media data it protects.
	Optional parameters: none		Optional parameters: none
	Typical optional parameters [3], such as the number of		Typical optional parameters [3], such as the number of
	channels, and the duration of audio per packet, do not		channels, and the duration of audio per packet, do not
	apply to FEC data. The number of channels is effectively		apply to FEC data. The number of channels is effectively
	the same as the media data it protects; the same is true		the same as the media data it protects; the same is true
	for the duration of audio per packet.		for the duration of video per packet.
	Encoding considerations: This format is only defined for		Encoding considerations: This format is only defined for
	transport within the Real Time Transport protocol (RTP)		transport within the Real Time Transport protocol (RTP)
	[4,5]. Its transport within RTP is fully specified with RFC		[4,5]. Its transport within RTP is fully specified with RFC
	2733 [1].		2733 [1].
	Security considerations: none		Security considerations: none
	Interoperability considerations: none		Interoperability considerations: none
	skipping to change at page 5, line 14 ¶		skipping to change at page 5, line 17 ¶
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This registration is part of the IETF		Author/Change controller: This registration is part of the IETF
	registration tree.		registration tree.
	RTP and SDP Issues: Usage of this format within RTP and the		RTP and SDP Issues: Usage of this format within RTP and the
	Session Description Protocol (SDP) [6] are fully specified		Session Description Protocol (SDP) [6] are fully specified
	within RFC 2733 [1].		within RFC 2733 [1].
	4 Security Considerations		4 Registration of text/parityfec
			To: ietf-types@iana.org
			Subject: Registration of MIME media type text/parityfec
			MIME media type name: text
			MIME subtype name: parityfec
			Required parameters: none
			Note that [3] mandates that RTP payload formats without a
			defined rate must define a rate parameter as part of their
			MIME registration. The payload format for generic forward
			error correction [1] does not specify a rate parameter.
			However, the rate for FEC data is equal to the rate of the
			media data it protects.
			Optional parameters: none
			Typical optional parameters [3], such as the number of
			channels, and the duration of audio per packet, do not
			apply to FEC data. The number of channels is effectively
			the same as the media data it protects; the same is true
			for the duration of text per packet.
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[4,5]. Its transport within RTP is fully specified with RFC
			2733 [1].
			Security considerations: none
			Interoperability considerations: none
			Published specification: This MIME typed is described fully
			within RFC 2733 [1].
			Applications which use this media type: Audio, video and text
			streaming tools which seek to improve resiliency to loss by
			sending additional data with the media stream.
			Additional information: none
			Person & email address to contact for further information:
			Jonathan Rosenberg
			dynamicsoft
			200 Executive Drive
			Suite 120
			West Orange, NJ 07046
			email: jdrosen@dynamicsoft.com
			jdrosen@alum.mit.edu
			Intended usage: COMMON
			Author/Change controller: This registration is part of the IETF
			registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) [6] are fully specified
			within RFC 2733 [1].
			5 Registration of application/parityfec
			To: ietf-types@iana.org
			Subject: Registration of MIME media type application/parityfec
			MIME media type name: application
			MIME subtype name: parityfec
			Required parameters: none
			Note that [3] mandates that RTP payload formats without a
			defined rate must define a rate parameter as part of their
			MIME registration. The payload format for generic forward
			error correction [1] does not specify a rate parameter.
			However, the rate for FEC data is equal to the rate of the
			media data it protects.
			Optional parameters: none
			Typical optional parameters [3], such as the number of
			channels, and the duration of audio per packet, do not
			apply to FEC data. The number of channels is effectively
			the same as the media data it protects; the same is true
			for the duration of application data per packet.
			Encoding considerations: This format is only defined for
			transport within the Real Time Transport protocol (RTP)
			[4,5]. Its transport within RTP is fully specified with RFC
			2733 [1].
			Security considerations: none
			Interoperability considerations: none
			Published specification: This MIME typed is described fully
			within RFC 2733 [1].
			Applications which use this media type: Audio, video and
			application streaming tools which seek to improve
			resiliency to loss by sending additional data with the
			media stream.
			Additional information: none
			Person & email address to contact for further information:
			Jonathan Rosenberg
			dynamicsoft
			200 Executive Drive
			Suite 120
			West Orange, NJ 07046
			email: jdrosen@dynamicsoft.com
			jdrosen@alum.mit.edu
			Intended usage: COMMON
			Author/Change controller: This registration is part of the IETF
			registration tree.
			RTP and SDP Issues: Usage of this format within RTP and the
			Session Description Protocol (SDP) [6] are fully specified
			within RFC 2733 [1].
			6 Security Considerations
	This MIME registration does not introduce any addititional security		This MIME registration does not introduce any addititional security
	considerations.		considerations.
	5 Author's Addresses		7 Author's Addresses
	Jonathan Rosenberg		Jonathan Rosenberg
	dynamicsoft		dynamicsoft
	200 Executive Drive		200 Executive Drive
	Suite 120		Suite 120
	West Orange, NJ 07052		West Orange, NJ 07052
	email: jdrosen@dynamicsoft.com		email: jdrosen@dynamicsoft.com
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	M/S 0401		M/S 0401
	1214 Amsterdam Ave.		1214 Amsterdam Ave.
	New York, NY 10027-7003		New York, NY 10027-7003
	email: schulzrinne@cs.columbia.edu		email: schulzrinne@cs.columbia.edu
	6 Bibliography		8 Bibliography
	[1] J. Rosenberg and H. Schulzrinne, "An RTP payload format for		[1] J. Rosenberg and H. Schulzrinne, "An RTP payload format for
	generic forward error correction," Request for Comments (Proposed		generic forward error correction," Request for Comments (Proposed
	Standard) 2733, Internet Engineering Task Force, Dec. 1999.		Standard) 2733, Internet Engineering Task Force, Dec. 1999.
	[2] N. Freed, J. Klensin, and J. Postel, "Multipurpose internet mail		[2] N. Freed, J. Klensin, and J. Postel, "Multipurpose internet mail
	extensions (MIME) part four: Registration procedures," Request for		extensions (MIME) part four: Registration procedures," Request for
	Comments (Best Current Practice) 2048, Internet Engineering Task		Comments (Best Current Practice) 2048, Internet Engineering Task
	Force, Nov. 1996.		Force, Nov. 1996.
End of changes. 10 change blocks.
	16 lines changed or deleted		147 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/