Subject: [AVT] draft-ietf-avt-rtp-hdrext-09.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 19 Feb 2007 22:16:07 -0500

I write this in some embarrassment for the lateness of the day.

I was reviewing draft-ietf-avt-rtp-hdrext-09.txt one last time for the 
PROTO write-up and noted several places where I might have said things 
differently. No show stoppers until I came to the formal ABNF (section 
7), which I believe has two errors due to the use of parentheses rather 
than square brackets (which denote optionality in ABNF).

First: the direction attribute is supposed to be optional. That means 
("/" direction) should be ["/" direction], as it is in section 5.

Second: the existing specification of mapattrs makes a space mandatory 
at the end of the a=extmap line if there are no extension attributes. 
This is because the expression

   (space extensionattributes)

evaluates to (space) if extensionattributes is a null string. You get 
what you want by using square brackets around the above expression 
instead of parentheses.

Now that the draft needs fixing anyway, here are my nits. These can be 
ignored if you don't have time to follow up.

1. The abstract mildly contradicts the IANA considerations, in that it 
says flatly that extensions are unregistered. May I suggest saying 
instead: "in general unregistered" or "unregistered except for those 
defined by the IETF", with the latter perhaps preferred?

2. Drop "to" at the end of the first line of the Introduction.

3. I don't understand the one-sentence paragraph at the end of the 
Introduction. What "value"? Are you really saying:

"This specification applies to extensions of the RTP/AVP profile."

or is the sentence misplaced?

4. In section 4, I would rephrase:

"The 4-bit length is the length minus one of the data bytes of this
    header extension element (excluding this one-byte header)."

to read instead:

"The 4-bit length is the number minus one of data bytes of this
    header extension element following the one-byte header."

5. In section 6, second paragraph (immediately after the bullets), I 
think the first occurrence of the word "may" should be an RFC 2119 
"MAY", and the second occurrence should be an RFC 2119 "MUST":

"A direction attribute MAY be included in an extmap ..." and

"The direction MUST be one of ...".

6. The last paragraph on page 10 before the example reads:

"Note that either party may include extensions in the stream other
    than those negotiated, or those negotiated as "inactive", for example
    for the benefit of intermediate nodes.  Only extensions with an
    identifier in the range 1-14, and with a declaration, can be sent."

In that last line, "and with a declaration" seems to contradict "other 
than those negotiated" in the preceding lines. What is meant here? I 
also think that "may" in the first line should be an RFC 2119 "MAY".

Again, apologies for being so last-minute.

Tom Taylor

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

---

From: Dave Singer <[email-masked]>
Date: Tue, 20 Feb 2007 10:56:30 -0800

At 22:16  -0500 19/02/07, Tom-PT Taylor wrote:
>First: the direction attribute is supposed to be optional. That 
>means ("/" direction) should be ["/" direction], as it is in section 
>5.
>
>Second: the existing specification of mapattrs makes a space 
>mandatory at the end of the a=extmap line if there are no extension 
>attributes. This is because the expression
>
>evaluates to (space) if extensionattributes is a null string. You 
>get what you want by using square brackets around the above 
>expression instead of parentheses.

thanks.  not an abnf expert, myself...

>
>Now that the draft needs fixing anyway, here are my nits. These can 
>be ignored if you don't have time to follow up.
>
>1. The abstract mildly contradicts the IANA considerations, in that 
>it says flatly that extensions are unregistered. May I suggest 
>saying instead: "in general unregistered" or "unregistered except 
>for those defined by the IETF", with the latter perhaps preferred?

actually, any body could make a registration authority for their URN 
space, so I said "registration is de-centralized".

>2. Drop "to" at the end of the first line of the Introduction.

done

>or is the sentence misplaced?

the word "value" seems mis-placed.  deleted.

>    header extension element following the one-byte header."

ok

>"The direction MUST be one of ...".

done

>In that last line, "and with a declaration" seems to contradict 
>"other than those negotiated" in the preceding lines. What is meant 
>here? I also think that "may" in the first line should be an RFC 
>2119 "MAY".

Ok, "MAY" changed.  The point of the last sentence is that even if 
you don't offer to receive an extension, I might send it;  but if I 
send it, I have to include its declaration.

How about

<t>Either party MAY include extensions in the stream other than those 
offered, for example for the benefit of intermediate nodes.  For the 
RTP packets to include the extension, it must have been declared with 
an identifier in the range 1-14.</t>

?

-- 
David Singer
Apple Computer/QuickTime

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 20 Feb 2007 14:47:20 -0500

Just one open item at the end.

> At 22:16  -0500 19/02/07, Tom-PT Taylor wrote:
...
> an identifier in the range 1-14.</t>
[PTT] I'm left to infer from this that the declaration happens in the 
answer, since the first sentence says it wasn't in the offer. Is this 
what you intended?

---

From: Ron Frederick <[email-masked]>
Date: Tue, 20 Feb 2007 14:35:28 -0800

>>    header extension element following the one-byte header."

Since the discussion got reopened, was there ever a reply to the review 
comment that we should allow for zero-length elements here, as 
effectively "boolean" value where their presence was enough to indicate 
something? I actually like that idea, and think that's useful enough to 
justify reducing the maximum length to 15 bytes (from 16). It also 
happens to clean up something that I suspect a lot of people will likely 
implement wrong, by eliminating the need to remember to subtract one 
from the length before encoding it.
-- 
Ron Frederick
[email-masked]

---

From: Dave Singer <[email-masked]>
Date: Tue, 20 Feb 2007 14:43:56 -0800

At 14:35  -0800 20/02/07, Ron Frederick wrote:
>Since the discussion got reopened, was there ever a reply to the 
>review comment that we should allow for zero-length elements here, 
>as effectively "boolean" value where their presence was enough to 
>indicate something? I actually like that idea, and think that's 
>useful enough to justify reducing the maximum length to 15 bytes 
>(from 16). It also happens to clean up something that I suspect a 
>lot of people will likely implement wrong, by eliminating the need 
>to remember to subtract one from the length before encoding it.

Yes, I was keen to allow the storage of 16-byte elements, such as 
UUIDs, SMPTE standard labels, and SMPTE universal material IDs 
(UMIDs).  Since a zero-byte element by itself would take 3 bytes of 
padding, unless there were multiple it wouldn't gain any space, 
anyway, because of the need to pad.  So, given that it probably 
wouldn't often change the packet size, but would awkwardly remove the 
possibility of 16-byte values, I felt that the current design of 
length-1 was the right balance...

-- 
David Singer
Apple Computer/QuickTime

---

From: Ron Frederick <[email-masked]>
Date: Tue, 20 Feb 2007 15:10:51 -0800

Dave Singer wrote:
>> review comment that we should allow for zero-length elements here, as 
>> effectively "boolean" value where their presence was enough to 
>> indicate something? I actually like that idea, and think that's useful 
>> enough to justify reducing the maximum length to 15 bytes (from 16). 
>> It also happens to clean up something that I suspect a lot of people 
>> will likely implement wrong, by eliminating the need to remember to 
>> subtract one from the length before encoding it.
> 
> Yes, I was keen to allow the storage of 16-byte elements, such as UUIDs, 
> SMPTE standard labels, and SMPTE universal material IDs (UMIDs).  Since 
> a zero-byte element by itself would take 3 bytes of padding, unless 
> there were multiple it wouldn't gain any space, anyway, because of the 
> need to pad.  So, given that it probably wouldn't often change the 
> packet size, but would awkwardly remove the possibility of 16-byte 
> values, I felt that the current design of length-1 was the right balance...

Do we think we'd ever need anything longer? Should we be considering a 
non-linear mapping of the length field? For instance, values 0-7 could 
represent lengths 0-7 as-is, but values 8-15 could be a length of 
(value-4)*2 (allowing lengths of 8, 10, 12, 14, 16, 18, 20, or 22), or 
we could even divide things further and support even longer values, 
mapping 12-15 as (value-8)*4 (making the last four values correspond to 
lengths of 16, 20, 24, and 28). This would be easy to implement either 
as logic or a simple lookup table.

I'm still ok with the current proposal to support lengths of 1-16 and 
just say that these boolean elements should be encoded as 1-byte values, 
but it seems like we have enough bits here to allow both zero-length and 
longer items if that's the only issue. I could imagine getting a lot of 
benefit out of multiple of these zero-length values being packed 
together. Even if you have a mixture of zero-length and non-zero length 
values, not all over those non-zero length values will insist on 
alignment, so you could still get an overall space benefit.
-- 
Ron Frederick
[email-masked]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Feb 2007 09:44:43 -0500

I am wondering if what you really meant for this paragraph was:

  "Note that either party may include extensions in the stream other
   than those negotiated, or those negotiated as "inactive", for example
   for the benefit of intermediate nodes.  Only extensions that appeared
   with an identifier in the range 1-14 in SDP originated by the sender
   can be sent."

---

From: Dave Singer <[email-masked]>
Date: Wed, 21 Feb 2007 09:26:33 -0800

>   with an identifier in the range 1-14 in SDP originated by the sender

that would also be fine.

>>>>"other than those negotiated" in the preceding lines. What is 
>>>>meant here? I also think that "may" in the first line should be 
>>>>an RFC 2119 "MAY".
>>>you don't offer to receive an extension, I might send it;  but if 
>>>I send it, I have to include its declaration.
>>>
>>>How about
>>>
>>><t>Either party MAY include extensions in the stream other than 
>>>those offered, for example for the benefit of intermediate nodes. 
>>>For the RTP packets to include the extension, it must have been 
>>>declared with an identifier in the range 1-14.</t>
>>>
>>>?
>>>
>>[PTT] I'm left to infer from this that the declaration happens in 
>>the answer, since the first sentence says it wasn't in the offer. 
>>Is this what you intended?
>>

-- 
David Singer
Apple Computer/QuickTime