Re: [MMUSIC] Comments on ABNF in draft-petithuguenin-mmusic-ice-sip-sdp-01

[Ari Keränen <[e-mail]>]

Hi Magnus,

Good point. That ABNF indeed seems to be overly liberal on the extension attribute names and values. Perhaps e.g., token would be more appropriate at least for the extension-att-name (like att-field in RFC4566). 

For extension-att-value, are there any reasonable use cases where e.g., VCHAR would not be sufficient? Are RFC4566 att-values with non-printable characters used somewhere?


Cheers,
Ari

On 22 Jan 2014, at 11:35, Magnus Westerlund <[e-mail]> wrote:

> Hi,
> 
> As part of the RTSP for NAT work I actually noticed an issue with the
> ABNF that is defined for ICE in SDP.
> 
> From Section 8.1:
> 
>   candidate-attribute   = "candidate" ":" foundation SP component-id SP
>                           transport SP
>                           priority SP
>                           connection-address SP     ;from RFC 4566
>                           port         ;port from RFC 4566
>                           SP cand-type
>                           [SP rel-addr]
>                           [SP rel-port]
>                           *(SP extension-att-name SP
>                                extension-att-value)
> 
>   foundation            = 1*32ice-char
>   component-id          = 1*5DIGIT
>   transport             = "UDP" / transport-extension
>   transport-extension   = token              ; from RFC 3261
>   priority              = 1*10DIGIT
>   cand-type             = "typ" SP candidate-types
> 
> 
> 
> Petit-Huguenin & KeranenExpires August 29, 2013                 [Page 9]
> 
> Internet-Draft             ICE SIP/SDP Usage               February 2013
> 
> 
>   candidate-types       = "host" / "srflx" / "prflx" / "relay" / token
>   rel-addr              = "raddr" SP connection-address
>   rel-port              = "rport" SP port
>   extension-att-name    = byte-string    ;from RFC 4566
>   extension-att-value   = byte-string
>   ice-char              = ALPHA / DIGIT / "+" / "/"
> 
> The issue is what is allowed in extension-att-name and
> extension-att-value. They are listed here as byte-string. That is an
> extremely wide allowance in what values to be included.
> 
> First of all it includes SP the character used for delimiting the
> -att-name against the -att-value and the next set of name and value. I
> can't see that one can allow that, and if one have values that includes
> space, then they must be escaped.
> 
> Further I wonder if it wise to include the non-visible values from the
> below 128 range of the byte. It might be okay, but some thought needs to
> be put into this.
> 
> Cheers
> 
> Magnus Westerlund
> 
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  [phone]
> Färögatan 6                 | Mobile [phone]
> SE-164 80 Stockholm, Sweden | mailto: [e-mail]
> ----------------------------------------------------------------------
>