[AVT] Comments on draft-ietf-avt-rfc3555bis-01

[Magnus Westerlund <magnus.westerlund at ericsson.com>]

Hi Steve,

I have reviewed the MIME registration rules draft and have some comments.

1. First of all the title should be changed. Instead of MIME Type I 
think it should read "Media Type". And in general I think most usage of 
MIME should be replaced with media type.

2. Abstract: "This document also registers all the RTP payload
     formats defined in the RTP Profile for Audio and Video Conferences
     as MIME subtypes." Is really all registered here? I think some has 
been registered in other places.

3. Section 1.1, IANA consideration. The action to IANA should probably 
be clarified that this specification updates these registered media types.

4. Section 2.1. Should we recommend a specific RTP suffix? So that all 
RTP payload formats that have a companion file format with another 
format would use similar structure? A "+rtp" may be suitable.

5. Section 3. It should be clarified that in the parameter=value pair 
there MUST be a value to follow the ABNF defined in RFC 2045.

6. Section 3. Should a default offer/answer section be written into the 
specification? If we defines a default policy, then we can also document 
the need to define the exceptions from that policy. I also think we 
might need to consider the most common alternative policies and their 
impact on offer/answer.

7. Section 4, all media types registrations. The Author/change 
controller does not follow the new template. And the change controller 
should probably be the IETF rather than any specific individual. 
Therefore I propose that we use the by the IESG recommend sentence:
"IETF Audio/Video Transport working group delegated from the IESG."
We might even write in that into the rules as a recommendation that all 
media types belonging to IETF standards track documents should use that 
particular phrase.

8. Section 4.1.14: The channels parameter does not refer to a particular 
channel order. I assume they are following the channel order of AVP, but 
that could be spelled out in the registration. It is probably good to do 
this in section 2 as a default policy for the channels parameters. That 
way also the use of channels in the other media types will be covered.

9. Section 4.1.15: The "emphasis" parameter is not a receiver 
configuration parameter, it seems to be a stream property parameter. 
Thus it will apply to the stream(s) the declaring party sends. It might 
be worth clarifying the issues and the offer/answer implications with this.

10. Section 4.1.17. The "sampelrate" parameter does not defines in which 
unit the rate is measured.

11. As Roni pointed out. Section 4.2.4 should be removed from this 
specification. For informative usage a reference to the updated H261 
specification may be useful. May belong in the change section.

12. Section 4.2.8: The "type" parameter:
"The mapping to a=fmtp is identity." Why is this sentence here? Is the 
intention saying that this parameter is mapped as any other parameter 
into a=fmtp or is something other meant in which case I don't understand it.

13. Section 5. The comment about RFC 3555 co-author Philipp Hoschka seem 
to belong to the Contributor section.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt