[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: SDP attribute for qualifying Media Formats withGeneric Parameters to a Proposed Standard



--> ned.freed@mrochek.com writes:
> > The IESG has received a request from Individual Submissions WG to
> > consider the following Internet-Draft(s) as a Proposed Standard. This
> > has been reviewed in the IETF but is not the product of an IETF Working
> > Group. o Individual Submissions (NONE): SDP attribute for qualifying
> > Media
> >   Formats with Generic Parameters
> >     <draft-rajeshkumar-mmusic-gpmd-03.txt>
> >     Proposed Standard
> 
> This looks to me like a substantive duplication of the media features
> facility defined in RFC 2533 and elaborated on in RFCs 2506, 2530, 2534,
> 2738, 2912, 2913, 2938, and 2987. Not only does this set of documents
> provide a full-featured media feature tagging and content negotiation
> facility, the relationship to MIME media types and parameters has also
> been worked out.

This draft adds a new namespace within the existing feature description
syntax (RFC 2327) and parameter negotiation (RFC 3264) model of SDP. It
is intentionally independent of MIME types, and their parameters, which
are mapped onto SDP in other ways (typically through RTP Payload Type
registrations).

> Although the media features facility defined in these various RFCs is
> perhaps too elaborate for SDP's needs, it should at least be possible to
> reuse the basic descriptive elements of media features and the
> corresponding media features registry.
> 
> At a minimum this draft needs to explain why the existing media features
> facility is unsuitable for SDP's use and another, similar facility needs
> to be defined.

That's an issue for SDP in general, which has a feature description and
negotiation mechanism incompatible with - and to large extent predating -
the RFCs you mention, but is out of scope of this draft. 

The SDPng work in MMUSIC references the RFCs you mention, and is looking to
reuse as much as possible from them. I think it's too late for SDP to adopt
them, because of the need to maintain backwards compatibility with a large
installed base.

Colin