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

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Tue, 15 Nov 2005 10:28:03 +0100

Hi

About media types registration, I wonder why (for audio) we specify ptime and maxptime as optional parameters, with always the same definition.
Since it is generic SDP params, it seems useless to have it in (almost) every audio type registration.
Can you please clarify the need?

Aurelien

-----Message d'origine-----
De : Stephen Casner [mailto:[email-masked]] 
Envoyé : jeudi 10 novembre 2005 19:23
À : Magnus Westerlund; SOLLAUD Aurelien RD-TECH-LAN
Cc : IETF AVT WG
Objet : Re: [AVT] Comments on draft-ietf-avt-rfc3555bis-01

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 ---

On Mon, 7 Nov 2005, Magnus Westerlund wrote:

> 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.

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

> 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.

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.

> 3. Section 1.1, IANA consideration. The action to IANA should probably 
> 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.

> 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.

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"?

> 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.

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

> 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.

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.

> 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.

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.

> 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.

OK.

> 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.

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

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

Good point.

> 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.

Right.  Again, we might remove all of them.

> 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.

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.

> 13. Section 5. The comment about RFC 3555 co-author Philipp Hoschka 
> seem 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???

On Wed, 9 Nov 2005, Magnus Westerlund wrote:

> 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?

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

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Nov 2005 10:39:10 +0100

> Can you please clarify the need?
Hi,

The reason for actually explicitly state the usage of ptime and maxptime 
is that they are not generally applicable. The media format needs to be 
able to support them. Sure they are almost generally applicable to audio 
formats but not to all media formats. So if you have a format that ptime 
and maxptime would not apply to you would not include them. One could 
have gone the other way and stated for audio formats that not support 
them to explicitly indicate this. However positive statements rather 
than negative one is to prefer.

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]