Subject: [AVTCORE] Media Types Registry

From: Adam Roach <[email-masked]>
Date: Wed, 27 Jul 2011 09:37:56 -0400

I'm not entirely sure what consensus the chairs took away from the room 
regarding the "RTP Payload Format media types" IANA registry, but I do 
want to make sure we consider the following before we call the topic 
resolved:

Has anyone asked Steve Casner?

I would appear that he put in the work to get an RFC published on the 
topic as recently as four years ago. This isn't an easy task, so I would 
assume he had some pretty good reasons for putting in the effort. I 
imagine that those reasons would be very relevant input to this 
conversation.

/a

---

From: Stephen Casner <[email-masked]>
Date: Wed, 27 Jul 2011 08:36:35 -0700 (PDT)

What was the question?

                      -- Steve

On Wed, 27 Jul 2011, Adam Roach wrote:

> regarding the "RTP Payload Format media types" IANA registry, but I do want to
> make sure we consider the following before we call the topic resolved:
>
> I would appear that he put in the work to get an RFC published on the topic as
> recently as four years ago. This isn't an easy task, so I would assume he had
> some pretty good reasons for putting in the effort. I imagine that those
> reasons would be very relevant input to this conversation.
>
> /a
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Roni Even <[email-masked]>
Date: Wed, 27 Jul 2011 19:23:56 +0300

Hi Steve,
We got a question from IANA about RTP Payload Format media types
(http://www.iana.org/assignments/rtp-parameters ) registry which is not
current and is not well maintained. 

The payload subtype are registered in the main registry that avoids
collision etc. http://www.iana.org/assignments/media-types/index.html .

The question was if we see value in keeping it since the uniqueness is based
on the main registry. We were not sure why it was created and how it was
supposed to be updated.
We have two choices, update it and define the procedure to keep it current
or cancel it.
Regards
Roni Even

RTP Payload Types are identified by Media Types:
The main registry that avoids collision etc. 
http://www.iana.org/assignments/media-types/index.html
Registration in this registry is required, and works as intended
There is a second registry:
RTP Payload Format media types
http://www.iana.org/assignments/rtp-parameters
This registry is intended to contain all media types that have RTP Payload
formats
The issue with the second registry:
Poorly maintained, and a lot of formats are missing
Limited extra value, only usable if you want to know all RTP payload formats
Unknown that it exist

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Casner
> Sent: Wednesday, July 27, 2011 6:37 PM
> To: Adam Roach
> Cc: AVT (Audio/Video Transport) WG
> Subject: Re: [AVTCORE] Media Types Registry
> 
> What was the question?
> 
>                       -- Steve
> 
> topic as

---

From: Stephen Casner <[email-masked]>
Date: Wed, 27 Jul 2011 10:44:14 -0700 (PDT)

Roni and AVT,

I created the RTP Payload Format Media Types table initially because I
felt that the limited table of static payload types needed to be
accompanied by the more extensive list of payload formats that were
available using dynamic payload types.  As noted below, the expected
value was that it identified the subset of registered media subtypes
that were defined for transport via RTP.

For audio and video, many of the subtypes in the main registry are
defined as part of an RTP payload format, but not all.  And for the
text subtypes in the RTP Payload Format Media Types table, finding
those in the main table or realizing that they exist would be harder.

Clearly the value of this table depends upon it being maintained.  Is
IANA willing to establish a practice that when new media subtypes are
defined for RTP they would automatically go into this table?  I would
hope so.  Or would IANA require that the IANA Considerations section
of each payload format RFC explicitly mention this?

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 27 Jul 2011 18:22:34 -0400

Hi,

I think one of the reason this registry are missing so much is that we
don't have put this into the IANA consideration section or had clear
process established with IANA.

I have talked with Michelle and it might be possible to a default
process into place. RFC 4288 is apparently under way to do revisions.

https://datatracker.ietf.org/doc/draft-freed-media-type-regs/

Something we should discuss around this document is if there should be a
question in the registration template "Does the media type have an RTP
payload type" that thus should result in the media type being added to
this registry automatically.

But, I think the low work solution is to instruct IANA to add this to
their checklist. Have the PAYLOAD WG chairs try to ensure that the IANA
section contains the right instruction. And that someone spends the 2-4
hours going through the documents to find all missing RTP payload types.

I do think there is some value with this registry, as it is difficult to
find the sub-set of media types that has RTP payload formats.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephen Casner <[email-masked]>
Date: Wed, 27 Jul 2011 15:50:08 -0700 (PDT)

Magnus,

> this registry automatically.

Please be careful with terminology.  An "RTP Payload Type" is a
number, for which a small set has been defined statically, but most
are assigned dynamically.  So the question you suggested for the
template is not correct.

In RFC 3555, it was specified that the encoding considerations should
be explicit about RTP transport:

    2. Procedure For Registering MIME Types for RTP Payload Types

       [snip]

	  Encoding considerations
	     The fact that the type can be transferred via RTP MUST be
	     noted.

In RFC 4855, that instruction is changed, but I don't remember why.
Instead, the same fact is noted in under "Restrictions on usage":

     Restrictions on usage:
	  The fact that the media type is defined for transfer via RTP
	  MUST be noted, in particular, if the transfer depends on RTP
	  framing and hence the media type is only defined for transfer
	  via RTP.

Thus, if these procedures have been followed, there should already be
sufficient information for IANA to take the additional step.

> find the sub-set of media types that has RTP payload formats.

That is my opinion as well.

                                                        -- Steve

> F?r?gatan 6                | Mobile +46 73 0949079

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Jul 2011 11:19:42 -0400

> are assigned dynamically.  So the question you suggested for the

Yes, you are correct. it should say "RTP Payload Format".

> sufficient information for IANA to take the additional step.

Yes, I think it has been followed. I think who ever gets to do a bit of
digging through the RFCs will find if it is solid or have been missed
some times.

But, I think it is probably safer to have this instruction in the IANA
consideration section to avoid that IANA misses this.

Cheers

Magnus Westerlund