SDP attribute for qualifying Media Formats with Generic Parameters
draft-rajeshkumar-mmusic-gpmd-03

This draft probably shouldn't be sitting in the External Party state, as we are not expecting it to be revised under its current title at any future time.

[Ballot comment]
I've moved to abstain, with this comment retained for clarity.


I'd like to discuss what happens when this sort of parameter gets used in the presence of
something like audio/3gpp (draft-singer-avt-3gpp-mime-01.tx.)  3gpp has asked for
both audio and video mime types that are essentially "bucket" mime types that may contain
data using different codecs.  One of the results of this is that the parameters don't
work all that well to indicate interoperability in advance of downloading the data (not
fun in these environments).  I'd like to understand how gpmd might work in those contexts.
(This might affect, for example, the ability to use this on a per-session basis effectively)

[Ballot discuss]
This seems to be another case where we're duplicating the functionality provided
by media feature tagging. Having a multitude of separate and probably incompatible media tagging facilities in our various protocols does not strike me as being a good idea.

I believe I mentioned this previously and was told that media feature tagging
could not be retrofitted into the existing content type negotiation framework
used here. However, this appears to be an entirely new facility and one not
related to stream content negotiation, so I really don''t see why we need to
reinvent this particular wheel here.

Randy, in answer to your question as to why this isn't best done using MIME
paramaters, the issue of using media type parameters to provide essential
external information versus using them to provide descriptive information
was discussed at great length when MIME was first defined. It was finally
decided that media type parameters were really intended for essential
external information and that using them to provide descriptive information
could lead to silly states. This then led to work being done to define the
very powerful and very general media feature tagging facility (RFCs 2533, 2534, 2912, 2938, and 2987).

[Ballot discuss]
I'd like to discuss what happens when this sort of parameter gets used in the presence of
something like audio/3gpp (draft-singer-avt-3gpp-mime-01.tx.)  3gpp has asked for
both audio and video mime types that are essentially "bucket" mime types that may contain
data using different codecs.  One of the results of this is that the parameters don't
work all that well to indicate interoperability in advance of downloading the data (not
fun in these environments).  I'd like to understand how gpmd might work in those contexts.
(This might affect, for example, the ability to use this on a per-session basis effectively)

[Ballot discuss]
The IANA considerations should use the language from rfc 2434, I suspect.  It's also a bit odd to require a standards track rfc here, when a mime subtype does not, but if the WG feels strongly about this I won't argue.

This is fixable with an RFC editor's note.

[Ballot discuss]
color me discuss, but expect me to be no-ob when my lack of
understanding is addressed. i.e., my issues are not fundamental.

---

what is the need/rationale for avoiding mime registration? if
there is a real need, and i assume there is, then the document
should make it clear.

---

      2.2 Offer/Answer Support
      ...

        A bilateral gpmd parameter ...
                                                    In all other cases, operation MUST be as if
      the gpmd parameter had not been included in the first place. The
      only exception to this rule is in the period between the offer being
      issued and the answer being received; during that time, the offerer
      MAY use the operation associated with the offered gpmd parameter for
      any media received for that offer.

does this mean that O could make an offer with gpmd X, and send
data which assumes successful negotiation of X before answerer A
has a chance to say "no thanks?" therefore

                                                                                                                        Correct
      operation of a given media stream MUST NOT depend on one or more
      participants either supporting or not supporting a given gpmd
      parameter.

must be true in a very absolute sense. how is that ensured?

or, put another way, during the negotiation gap, how is this
different from a unilateral gpmd?

---

      6.2 Creation of New SDP Sub-Registry for "gpmd" Parameters

omits whether the parm is bi or unilateral, and it would seem to be
best if the iana registry contained that information.