[AVTCORE] AD Review: draft-ietf-avtcore-srtp-encrypted-header-ext-03

[Robert Sparks <[e-mail]>]

Summary: There is one issue to adjust with a revised ID before 
proceeding to IETF LC.

(Based on a brief voice conversation with Jonathan Lennox)

The ABNF in Figure 3 is recursive as written. It allows productions like

a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt 
urn:ietf:params:rtp-hdrext:toffset 
urn:ietf:params:rtp-hdrext:ssrc-audio-level
and worse
a=extmap:1 urn:ietf:params:rtp-hdrext:encrypt 
urn:ietf:params:rtp-hdrext:toffset token1 token 2 
urn:ietf:params:rtp-hdrext:ssrc-audio-level

etc.

I suggest to avoid this instead extend the rule for extmap in RFC5285 
(please explicitly call out that's where to look for the base
definition of extmap, extensionname, and extensionattributes) as follows:

extmap /= mapentry SP "urn:ietf:params:rtp-hdrext:encrypt" extensionname 
[SP extensionattributes]

Jonathan notes that RFC5234's quoted-strings are by definition case 
insensitive. If extensionnames are intended to be case-sensitive
(RFC5285 is silent on that point), the quoted string above would need to 
be replaced with hex expansions for the individual characters:

 >>> [hex(ord(ch)) for ch in list('urn:ietf:params:rtp-hdrext:encrypt')]
['0x75', '0x72', '0x6e', '0x3a', '0x69', '0x65', '0x74', '0x66', '0x3a', 
'0x70', '0x61', '0x72', '0x61', '0x6d', '0x73', '0x3a', '0x72', '0x74', 
'0x70', '0x2d', '0x68', '0x64', '0x72', '0x65', '0x78', '0x74', '0x3a', 
'0x65', '0x6e', '0x63', '0x72', '0x79', '0x70', '0x74']


Nits:

In the abstract, I suggest s/require that all SRTP/require that all 
future SRTP/

Introduction, 1st paragraph, s/using of the Real-Time/using the Real-Time/