Subject: [AVT] Technical comments on draft-ietf-avt-rtp-hdrext-12

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2007 11:47:03 +0200

Hi,

Sorry for not having read this in WGLC. However I think there is a 
serious error in the spec that needs to be fixed before this going further.

7.  BNF Syntax

    The syntax element 'URI-reference' is as defined in [RFC3986], except
    that only absolute URIs are permitted here.  The syntax element
    'extmap' is an attribute as defined in [RFC4566].
    Extensionattributes are not defined here, but by the specification
    that defines a specific extension name; there may be several.

      digit = "0"/"1"/"2"/"3"/"4"/"5"/"6"/"7"/"8"/"9"

      integer = 1*digit

      space = " "

      extensionname = URI-reference

      direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"

      mapentry = "extmap:" integer ["/" direction]

      mapattrs = [space extensionattributes]

      extmap = mapentry space extensionname mapattrs

There are two serious issues with this. First RFC 4234 is not referenced 
to define that your using that type of BNF. Secondly and really 
seriously, the "extensionattributes" syntax is not defined. Unless one 
defines the form of it this exercise is useless as no parsers pre 
extension can handle and ignore the extension anyway.

I would propose to rewrite this section to the following:

7.  ABNF Syntax

The below syntax definition uses ABNF according to [RFC4234]. The syntax 
element 'URI' is as defined in [RFC3986]. The syntax element 'extmap' is 
an SDP attribute as defined in [RFC4566], i.e "a=" precede the extmap 
definition.

      extmap = mapentry SP extensionname mapattrs

      extensionname = URI

      URI = <Defined in RFC 3986>

      direction = "sendonly" / "recvonly" / "sendrecv" / "inactive"

      mapentry = "extmap:" 1*5DIGIT ["/" direction]

      mapattrs = *(SP extensionattribute)

      extensionattribute = non-ws-string

      non-ws-string = <Defined in RFC 4566>

      SP = <Defined in RFC 4234>

      DIGIT = <Defined in RFC 4234>

Some comments on this ABNF compared to the original one.
1. It limits the number of digits for the temporary identifier to 5, 
i.e. up to 16 bits supported if this ever is extended.

2. The extension can now be basically any string as long as it doesn't 
contain spaces. In addition there might be multiple additions with 
spaces in between them. The alternative would be to demand a space and 
then use byte-string (from rfc4566) to allow for any separators.

3. Uses RFC 4234 base syntax.

4. Uses URI rule instead of URI-Reference so that relative ones are not 
possible.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
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: Dave Singer <[email-masked]>
Date: Wed, 20 Jun 2007 12:10:37 +0200

>serious error in the spec that needs to be fixed before this going 

Thank you;  I do not claim BNF expertise...

>There are two serious issues with this. First RFC 4234 is not 
>referenced to define that your using that type of BNF.

OK

>Secondly and really seriously, the "extensionattributes" syntax is 
>not defined.

well, it consumes everything to end of line.  we could make it 
tighter, I guess.

>Unless one defines the form of it this exercise is useless as no 
>parsers pre extension can handle and ignore the extension anyway.
>
>The below syntax definition uses ABNF according to [RFC4234]. The 
>syntax element 'URI' is as defined in [RFC3986]. The syntax element 
>'extmap' is an SDP attribute as defined in [RFC4566], i.e "a=" 
>precede the extmap definition.
>
>2. The extension can now be basically any string as long as it 
>doesn't contain spaces. In addition there might be multiple 
>additions with spaces in between them. The alternative would be to 
>demand a space and then use byte-string (from rfc4566) to allow for 
>any separators.
>
>4. Uses URI rule instead of URI-Reference so that relative ones are 
>not possible.
>
>
>Cheers
>
>Magnus Westerlund
>
>

-- 
David Singer
Apple/QuickTime

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2007 13:59:54 +0200

Dave Singer skrev:

> 
>> Secondly and really seriously, the "extensionattributes" syntax is not 
>> defined.
> 
> well, it consumes everything to end of line.  we could make it tighter, 
> I guess.
> 

No, it didn't because the label "extensionattributes" was not defined. 
It needs to be either explicitly or by an explicit import.

Cheers

Magnus Westerlund