Subject: [AVT] RFC 4585 BNF issues/problems

From: Randell Jesup <[email-masked]>
Date: Thu, 15 May 2008 11:10:05 -0400

[ Note: I tried to send this over a week ago, and the avt reflector never
seemed to take delivery.  Eventually my MTA stopped trying and sent it
back.]

I'm resending this message from a month ago because of the gaping lack of
any response at all.  There is a problematic hole in the BNF for rtcp-fb
that means that people writing parsers for it will hit incompatibilities
and/or break when faced with extensions (the first of which is probably
the CCM RFC).

We need to decide how people should handle this, and also find out from
anyone who has already written an RFC 4585 parser (Polycom/Tandberg/etc)
how they handled this, and if that will cause problems with whatever
solution we suggest.

It also points out that the SDP attribute syntax design in most drafts is
very "loose"; there either isn't a good "example", or people don't know
where to go to find one.  Something about this should be worked into the
draft on "how to write an AVT payload draft".

   Randell

I was recently re-reading RFC 4585 (RTP/AVPF), and I found a possible
problem when it's extended by future RFCs (like CCM).

The BNF is a series of items with spaces, some of which have qualifiers 
separated by spaces.  For example:
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* nack ack
a=rtcp-fb:* nack pli ack
a=rtcp-fb:* nack pli ack rpsi

All of those are reasonably well-defined and parseable, modulo the "SP
token [SP bytestring]" parameter entries for ack and nack.  What token
would mean in this case is nowhere defined; the BNF is the only place
'token' appears in the RFC.

For extensions, it defines rtcp-fb-id and rtcp-fb-param.

It also says that you must ignore and remove any items you don't
understand or aren't willing to support.

The problem is that rtcp-fb-param can be "SP 'app' [SP byte-string]",
"SP token [SP byte-string]" or empty.  If a baseline rfc 4585 parser sees
an unknown token (which matches rtcp-fb-id), how does it know how far
ahead to skip?  For example

a=rtcp-fb:* foo

is obvious.  This is also easy to deal with, though the parser doesn't know
if 'bar' is an rtcp-fb-param or and rtcp-fb-id.

a=rtcp-fb:* foo bar

But what about this:

a=rtcp-fb:* foo nack
or
a=rtcp-fb:* foo bar nack
or 
a=rtcp-fb:* foo nack bar
or 
a=rtcp-fb:* foo bar nack bar
or 
a=rtcp-fb:* foo bar nack pli bar
or
a=rtcp-fb:* foo bar nack bar ack

Is 'nack' an rfc4585 'nack', a parameter to foo, a parameter to bar, etc?
Is 'bar' an rtcp-fb-id, a 'token' expanding nack, is the following 'ack'
an ack or a parameter to (rtcp-fb-id) bar or a bytestring to (nack token)
bar? 

The parser has no way to scope which variant of rtcp-fb-param is being
used.  There's no delimitation available (like a syntax of "rtcp-fb-id [SP
bytestring] ';'" or "rtcp-fb-id['=' bytestring]".  At minimum, we'd need to
make sure in any extension of rtcp-fb that it can't match any valid prior
rtcp-fb parameter.  And if there are multiple extensions, it gets more
complicated.

I suspect strongly that existing implementations make very simple
assumptions about how to parse, and when they see a string they don't
recognize they throw it away and start parsing again after the space.
Given the ambiguous BNF, there may not be a better choice anyways.

So, questions:
1) what does "token" mean for ack and nack?  What is the optional
   bytestring for that case?  It appears that 'token' is there for future
   expansion with other RFCs.
2) How does an earlier implementation distinguish between "token" additions
   to ack and nack, and when it sees an rtcp-fb-id how does it know what to
   do with following values?
3) If we specify (or more likely document) how rfc 4585 parsers work, then
   we can make sure there's no ambiguity in how following RFCs define their
   syntax. 
4) Can anyone who's implemented an RFC 4585 parser comment on how they'd
   handle cases like the above examples?  How does your parser deal with
   unknown tokens?

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

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

---

From: Colin Perkins <[email-masked]>
Date: Sun, 25 May 2008 20:40:19 +0100

Randell,

These are good questions - it would be good if people with  
implementations can comment. I also have one minor comment below.

Colin

> 'token' appears in the RFC.

I assume 'token' is as defined in RFC 4566? This should clearly be  
specified though.

-- 
Colin Perkins
http://csperkins.org/

---

From: Randell Jesup <[email-masked]>
Date: Tue, 27 May 2008 17:07:25 -0400

Colin Perkins <[email-masked]> writes:
>These are good questions - it would be good if people with  implementations
>can comment. I also have one minor comment below.

Please, anyone using AVPF (RFC 4585) and CCM (RFC 5104) PLEASE comment on
how your parsers handle the examples in the message (included below to make
it easier on you; normally I'd clip the quote.

As for 'token', I assume (now that you point it out) it's per RFC 4566 also,
though it isn't specified.  Annoyingly, they specified token-char in hex
values for RFC 4566, so it's a pain to read.

>> anyone who has already written an RFC 4585 parser (Polycom/Tandberg/ etc)

---

From: Colin Perkins <[email-masked]>
Date: Tue, 27 May 2008 23:36:46 +0100

On 27 May 2008, at 22:07, Randell Jesup wrote:
> As for 'token', I assume (now that you point it out) it's per RFC  
> 4566 also, though it isn't specified.  Annoyingly, they specified  
> token-char in hex values for RFC 4566, so it's a pain to read.

The ABNF syntax requires the hex values, if one is to specify case  
sensitive values and ranges.

-- 
Colin Perkins
http://csperkins.org/