Subject: [AVT] Comments on draft-ietf-text-red-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Wed, 21 Jan 2004 16:31:12 +0100

Hi Paul,

Here are some comments on the text/RED mime registration:

1. Section 3: rate parameter: I think the "may" in the last sentence 
should be a normative one.

2. Section 3: The "pt" list is not motivated, one does not understand 
the purpose of it. I think you should add a little text to make it 
clear. Expanding the first sentence like this may be sufficient: "a 
comma-separated list of RTP payload types that MAY occur in the 
redundancy payload."

3. Section 3: Security considerations: Referencing the wrong chapter. I 
think you could also should rewrite it so that it becomes more 
standalone. Proposal: "see section 5 of RFC XXXX." Do also put in a 
RFC-editor note about replacing XXXX with the documents number.

4. Section 4, second bullet. The rate parameter is not explicitly 
stated. I think the second sentence should be: "The rate parameter's 
value goes as rate in the "a=rtpmap" attribute." The MUST statement 
belongs to the MIME type parameter in general and should be moved there 
instead.

5. Section 4, the last bullet for the "pt" list. This is under 
specified, the following problems exist:
-  The removal or not of <"> quoting etc. is not defined.
- How to handle any "dynamic-payload-type "=" content-type" string is 
also not explained.

6. Section 4, the "pt" example. I think it can be improved with stating 
what the 99 is.

7. Section 5: A proposal for how to handle the security problem is 
always good. Proposal: "To prevent modification of the primary, 
secondary or header information, payload integrity protection over at 
least the complete RTP packet is recommend, for example using SRTP []."

8. Section 6, The first reference is an informative one, please move it 
to an informative reference list. Also reference 7 is not used at all, 
please remove.

I expect that the when these things are addressed the document is ready 
for WG last call.

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: Thu, 22 Jan 2004 10:01:02 +0100

Hi Paul,

[CCing the AVT list as there are issues here that needs open discussion]

Response inline.

Paul E. Jones wrote:

>Magnus,
>
>I'll try to make these changes.  I have questions for clarification:
>
>  
>
>What do you mean by "normative"?
>

You should use normative language, in other words the MAY normative word 
that you use through reference to RFC 2119.

>Are you suggesting that people would not necessarily know if the quotes
>are
>part of the syntax or not?
>  
>
You are stripping the outer quotation marks, are you leaving the inner 
in place, in there converted form, or do you change to standard quotation?

>I do not understand your concern.  Can you explain further?
>  
>

When you are in the SDP domain, you SHOULD NOT / SHALL NOT use the 
pt=content-type structure at all. As the information is available in the 
SDP as defined PT. Therefore you only need to reference these PTs. So 
when having SDP should you in fact remove all of these pt=content-type 
declarations and only use PTs in the list?

I would also like to point out that the this declaration of 
"dynamic-payload-type "=" content-type" is not sufficiently clear. For 
RTP payload formats using parameters to configure this, this string is 
insufficient unless the parameter list can be included in the 
content-type part.

>>least the complete RTP packet is recommend, for example using SRTP
>>    
>>
>[]."
>
>I agree with the added text, but concerned about referencing SRTP
>explicitly.  Will the RFC be published before this document?  I do not
>want
>to hold up progress due to a reference.  Would be be OK to leave off
>"for
>example using SRTP"?
>

The SRTP is in the RFC editors queue, so yes, it will be available 
before this document. Put SRTP into the informative reference list and 
write an RFC editors note that request that he replace the draft 
reference with the RFC number when it becomes available.

>
>  
>
>>8. Section 6, The first reference is an informative one, please move
>>    
>>
>it
>  
>
>I can do that.  What about 7, as well (RFC 3555)?
>
>  
>
>>I expect that the when these things are addressed the document is
>>    
>>
>ready
>  
>
>>for WG last call.
>>    
>>
>
>I've got all changes made, except those that are questions above.
>Looking
>forward to your reply... and thank you very much for your careful
>review.
>  
>

Great!

Magnus Westerlund

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 22 Jan 2004 05:51:45 -0500

Magnus,

> that you use through reference to RFC 2119.

Got it.. it's now MAY.  As a general question, why would capitalization
suggest a different meaning?

> in place, in there converted form, or do you change to standard quotation?

Well, this is a good question.  Clearly, I know what the end result is to
be, but how should this be written?  The text I am using was borrowed from
RFC 3555, which uses the same notation.  Please suggest specific changes to
clarify this.

> insufficient unless the parameter list can be included in the

Ah, I understand.  As I mentioned above, this follows the example in RFC
3555, which also does not go into discussion on this (as far as I know).  I
assume the reason for that was simply that the entire focus was on SDP,
anyway, with little focus on MIME, really.

In any case, I can add text in this regard, but I need some guidance as to
what we should have inserted to make this clearer.

> reference with the RFC number when it becomes available.

OK.. no problem.

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 22 Jan 2004 13:10:18 +0100

Paul,

Comments inline.

>suggest a different meaning?
This is due to that you have defined to have a separate meaning when you 
include the following statement in regards to RFC 2119.
      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

The reason why you do this is that in most case you desire to separate 
the cases when something really must be followed, i.e. being normative, 
and when it is only for information and does not carry necessary the 
same strict meaning. You really should read RFC 2119, its only 3 pages.

>RFC 3555, which uses the same notation.  Please suggest specific changes

I think we need to resolve what discrepancy we have between RFC 2198 and 
RFC 3555 before being able to close this issue. However I don't think 
that much text is required, just being explicit about it.

>>pt=content-type structure at all. As the information is available in
>>    
>>
>the
>  
>
I would definitely like to have some more input from Colin and others 
about how this problem should be resolved.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 26 Jan 2004 10:15:41 +0100

Hi,

I have had some off-line discussion regarding the MIME registration 
problem for text/RED. Know understanding the intention having the 
ordering requirement on RFC 2198 being firm for the "pt" list, I would 
propose the following text change for the "pt" list:

"pt: a comma-separated ordered list enumerating the primary, secondary, 
etc., encoding's RTP payload types in accordance with RFC 2198.  Because 
comma is ..."

Then one addition to the SDP section (4) is also needed in my opinion. 
Please add the following text where appropriate.

"For each redundancy payload type defined the ordering of the primary, 
and redundancy encoding(s) are fixed. If more than one combination of 
primary, and redundancy encoding(s) are desired, multiple redundancy 
payload types needs to be defined."

Then only the last issue below remains to be resolved as I see it.

Cheers

Magnus

-- 

Magnus Westerlund

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 26 Jan 2004 08:15:34 -0500

Magnus,

> etc., encoding's RTP payload types in accordance with RFC 2198.  Because

There was a desire early on not to explicitly tie the MIME registration to
RFC 2198.  Certainly, it is the main driver for producing the document, but
it was viewed as not the only potential user of this registration.  Thus, do
we really want this text or just leave it as it is in the current draft?

> payload types needs to be defined."

Perhaps you can educate me here, but why would the order matter?  The
payload format defined in RFC 2198 allows for the PT of the redundant data
to be specified along with the payload.  Thus, it seems that the ordering of
is not so important.  Of course, a distinction must be made between primary
versus redundant, but it is not clear to me why this strict clause is
needed. Please clarify.

> Then only the last issue below remains to be resolved as I see it.

And, how can we close on that issue below?

Paul

> >> 3555, which also does not go into discussion on this (as far as I
know).
> >> I

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 27 Jan 2004 09:51:31 +0100

Hi Paul,

comments inline:

Paul E. Jones wrote:

>>"pt: a comma-separated ordered list enumerating the primary,
>>    
>>
>secondary,
>  
>
>>etc., encoding's RTP payload types in accordance with RFC 2198.
>>    
>>
>Because
>  
>
>>comma is ..."
>>    
>>
>

No, It must be tied to RFC 2198. In my recollection the opinion 
expressed was to not tie it to RFC 2793. I think we should go with the 
new text, because I find the old text confusing as it does not inform 
explicitly that about the semantics of the parameter.

>>Then only the last issue below, remains to be resolved as I see it.
>>    
>>
>

I don't know really, it seems that we should be compatible with what is 
used for audio/RED. However what is really used here is not totally 
clear. Based on the examples in RFC 2198 one does rely on having dynamic 
PTs to be declared through "a=rtpmap".

What is you others opinion about this?

Cheers

Magnus

>>>>>pt=content-type structure at all. As the information is available
>>>>>          
>>>>>
>in
>  
>
>>>>the
>>>>
>>>>
>>>>        
>>>>
>>>>>SDP as defined PT. Therefore you only need to reference these PTs.
>>>>>          
>>>>>
>So
>  
>
>>>>>when having SDP should you in fact remove all of these
>>>>>          
>>>>>
>pt=content-type
>  
>
>>>>>"dynamic-payload-type "=" content-type" is not sufficiently clear.
>>>>>          
>>>>>
>For
>  
>
>>>>>RTP payload formats using parameters to configure this, this
>>>>>          
>>>>>
>string is
>  
>
>>>>Ah, I understand.  As I mentioned above, this follows the example
>>>>        
>>>>
>in
>RFC
>  
>
>>>>assume the reason for that was simply that the entire focus was on
>>>>        
>>>>
>SDP,
>  
>
>>>>In any case, I can add text in this regard, but I need some
>>>>        
>>>>
>guidance as
>  
>
>>>>to
>>>I would definitely like to have some more input from Colin and
>>>      
>>>
>others
>  
>

-- 

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 Jan 2004 09:21:13 +0000

--> Magnus Westerlund <[email-masked]> writes:
... 
> What is you others opinion about this?

RFC 2198 requires strict ordering so the sender knows which is the primary
encoding, and which is the redundant. 

Colin

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Jan 2004 04:13:59 -0500

Magnus,

> explicitly that about the semantics of the parameter.

Sorry... I had the RFC numbers mixed up when I was responding.  Yes, you're
correct-- it was RFC 2793 that was the concern... no problem with your
proposed text.  I'll make those changes.

> What is you others opinion about this?

Perhaps pointing out a concrete problem that might result in SDP might help
lead to text that resolves the concerns.

Paul

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Jan 2004 12:35:59 +0100

Hi Paul,

Good, that resolves all but the last issue. Which I will try to 
recapitulate here:

The MIME type parameter declaration declares that any dynamic payload 
type is to be expressed in the form "PT=content-type". However when 
mapping this into a SDP it seems strange to use this form, as any 
dynamic PT is already declared in the SDP using "a=rtpmap". So I think 
the mapping to SDP text should explain how this should be done in the 
best way.

My proposal would be to add something like the following into the bullet 
about how to handle the "pt" parameter in section 4.

"Any dynamic payload type in the list, SHALL NOT include its 
content-type, only the payload type number. The mapping of payload types 
to the content-type is done using the normal SDP procedures with 
"a=rtpmap". "

Would this be satisfactory?

Cheers

Magnus Westerlund

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 28 Jan 2004 07:36:46 -0500

Magnus,

That sounds fine to me.  I'll insert that and make the complete text
available again as a TD within a week or so.  Of course, further input is
certainly welcome.

Paul