Subject: [dispatch] Fwd: New Version Notification for draft-gellens-mime-bucket-bis-03

From: David Singer <[email-masked]>
Date: Fri, 4 Mar 2011 15:57:37 -0800

Friends

this is a minor update to the previous mime-bucket-bis, which in turn is a minor update to RFC 4281.  It adds a profiles parameter in addition to the codecs parameter, and tries to make it clearer what files these parameters apply to.

We'll be trying to finish this revision sometime soon, so, if you would like to, please review and comment soon!  Thanks

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 4, 2011 15:54:07 PST
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: New Version Notification for draft-gellens-mime-bucket-bis-03
> 
> 
> A new version of I-D, draft-gellens-mime-bucket-bis-03.txt has been successfully submitted by David Singer and posted to the IETF repository.
> 
> Filename:	 draft-gellens-mime-bucket-bis
> Revision:	 03
> Title:		 The Codecs and Profiles Parameters for "Bucket" Media Types
> Creation_date:	 2011-03-04
> WG ID:		 Independent Submission
> Number_of_pages: 23
> 
> Abstract:
> Several MIME type/subtype combinations exist that can contain
> different media formats.  A receiving agent thus needs to examine the
> details of such media content to determine if the specific elements
> can be rendered given an available set of codecs.  Especially when
> the end system has limited resources, or the connection to the end
> system has limited bandwidth, it is helpful to know from the Content-
> Type alone if the content can be rendered.
> 
> This document specifies two parameters, "codecs" and "profiles",
> which are used with various MIME types or type/subtype combinations
> to allow for unambiguous specification of the codecs and/or profiles
> employed by the media formats contained within.
> 
> By labeling content with the specific codecs indicated to render the
> contained media, receiving systems can determine if the codecs are
> supported by the end system, and if not, can take appropriate action
> (such as rejecting the content, sending notification of the
> situation, transcoding the content to a supported type, fetching and
> installing the required codecs, further inspection to determine if it
> will be sufficient to support a subset of the indicated codecs, etc.)
> 
> Similarly, the profiles can provide an overall indication, to the
> receiver, of the specifications with which the content complies.  The
> receiver may be able to work out the extent to which it can handle
> and render the content by examining to see which of the declared
> profiles it supports, and what they mean.
> 
> 
> 
> The IETF Secretariat.
> 
> 

David Singer
Multimedia and Software Standards, Apple Inc.

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 04 Mar 2011 18:18:53 -0600

This I-D offers IMO a most interesting alternative to the SIP/SDP codec
negotiation and needless to say is working very well.
Just wondering (naively no doubt) what may also be applicable to the media
component for the RTC-Web.

Disclaimer: Just another rant against using SDP in the signaling component.

Thanks, Henry

On 3/4/11 5:57 PM, "David Singer" <[email-masked]> wrote:

> Friends
> 
> this is a minor update to the previous mime-bucket-bis, which in turn is a
> minor update to RFC 4281.  It adds a profiles parameter in addition to the
> codecs parameter, and tries to make it clearer what files these parameters
> apply to.
> 
> We'll be trying to finish this revision sometime soon, so, if you would like
> to, please review and comment soon!  Thanks
> 
> 
> Begin forwarded message:
> 
>> A new version of I-D, draft-gellens-mime-bucket-bis-03.txt has been
>> successfully submitted by David Singer and posted to the IETF repository.
>> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch