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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Nov 2005 05:49:45 +0100

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: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 Nov 2005 16:13:00 +0100

Hi,

One more comment:

The registrations all (except the ones that has file formats) include 
the following statement:
Restrictions on usage:
           This type is only defined for transfer via RTP [RFC 3550].

I wonder if for all types for which it is applicable this should be 
changed to:

         This media type depends on RTP framing, and hence is only
         defined for transfer via RTP [RFC3550]. Transport within other
         framing protocols is not defined at this time.

I think it is more informative. However I think one of the main issues 
is if we should be clearer on the question of if it only can and never 
will be registered for some other usage. The current sentence is quite 
unclear if it will be possible or not to add something if applicable.

Or am I over specifying things?

Cheers

Magnus Westerlund

---

From: Stephen Casner <[email-masked]>
Date: Thu, 10 Nov 2005 10:23:23 -0800 (PST)

Magnus and Aurelien,

Thanks for your helpful comments.  I'll respond to them all together
inline.

First I'd like to call out one point that is a question for the
working group:  Colin has verbally repeated to me his suggestion
posted in response to the previous draft revision, namely that we
remove all the media type registrations from this document and simply
have it specify the registration procedures.  I replied that I had
considered this, but had decided against it for a few reasons:

  - The registrations should probably be updated to conform to the new
    format requirements, so that means the whole document needs
    updating.

  - The text at the beginning makes a couple of forward references to
    the registrations as examples.

  - It's probably better to have the revised document obsolete 3555
    rather than update it, and to do that the revision needs to
    provide the equivalent content.

I still think we want the new document to obsolete 3555, but I now
have a couple of other options we can consider:

1.  I have confirmed with the RFC Editor that an RFC can be obsoleted
    by a set of new RFCs rather than just one.

2.  Alternatively, perhaps we don't really need to update the
    registrations.  The content is not really changing, just the
    format.  They were valid registrations at the time they were
    registered.  The RFC Editor said that the revised specification
    can still obsolete 3555 by stating that the registrations included
    in 3555 are in the IANA registry and not repeated in the revision.

Anyone have comments on keeping the document in its current form or
choosing one of these alternatives?

The problem of forward references to the registrations as examples I
can manage by extracting a portion inline or including a whole fake
example registration.

Now my responses to the comments ---

> MIME should be replaced with media type.

Good point, given that we are arguing for keeping a single registry
for various uses of media types including RTP and MIME.

> been registered in other places.

This was to cover all the payload formats listed in the profile but
not registered elsewhere, whether the payload format itself was
defined in the profile document or a separate one.

> be clarified that this specification updates these registered media types.

Yes, that's a good correction.  This might be removed from the spec if
we decide the registrations don't need to be updated.

> format would use similar structure? A "+rtp" may be suitable.

That is a reasonable suggestion.  This is for the case when the file
format and the RTP payload format require separate media types.  So,
if the file format is registered as "foo", the payload format would be
registered as "foo+rtp".  Anyone have any objection to the specific
suggestion "+rtp"?

> there MUST be a value to follow the ABNF defined in RFC 2045.

I think this is implicit in the existing text, but making it explicit
is fine.

> might need to consider the most common alternative policies and their

This is the only one of your comments about which I am unsure.
Offer/answer is an aspect of SDP usage more than media type
registration.  It might be expanding the role of this specification
too much.  We need to talk about this in more detail.

> media types belonging to IETF standards track documents should use that

The registrations may not all go through AVT, in particular if there
are specifications made by other SDOs.  However, the suggested phrase
could be included for cases where it applies.  If we decide not to
include updated registrations, then the first part of this comment
becomes moot.  I think we should not change the Change Controller for
registrations that have already been established as a particular
individual other myself as RFC 3555 author.

> way also the use of channels in the other media types will be covered.

OK.

> be worth clarifying the issues and the offer/answer implications with this.

Your assumptions are correct.  How much we say about offer/answer is
related to my reply to your comment #6.

> unit the rate is measured.

Good point.

> specification may be useful. May belong in the change section.

Right.  Again, we might remove all of them.

> into a=fmtp or is something other meant in which case I don't understand it.

I was speaking mathematically.  It simply means that this parameter is
mapped into SDP following the practice suggested in Section 3 to copy
the parameter directly from the media type format as a parameter=value
pair.

> to belong to the Contributor section.

I could put in a separae Contributor section, but I don't think this
is needed.  The formatting rules are not strict in this regard.  I put
the note in the Changes section because it is a change.

On Wed, 9 Nov 2005, SOLLAUD Aurelien RD-TECH-LAN wrote:

> Hi
>
> I would add a little reference issue:
> In section 2, in the "Optional parameter" part, it reads
>   The "ptime" and "maxptime" parameters are defined in the Session
>   Description Protocol (SDP) [6]."
>
> but "maxptime" is not in [6]=RFC2327, it is in the sdp-new draft.

Good catch.  The Internet-Draft that became RFC 3555 originally
referred to the sdp-new draft with the expectation that they would be
processed at the about the same time.  Obviously, that did not come to
pass, and the reference had to be changed back to 2327.

Maybe this time sdp-new will be published first???

> Or am I over specifying things?

Your expanded wording is fine.  I guess I was just trying to be a bit
more concises since there were many replications of this line.

                                                        -- Steve