Re: [MMUSIC] Some issues with draft-ietf-mmusic-trickle-ice-sip-02

[Thomas Stach <[e-mail]>]

Paul,
thanks for looking into this and pointing out the issues
I think they can be fixed quite easily.
More below

Am 23.07.2015 um 01:58 schrieb Paul Kyzivat:
> This is not a complete review of the document - I'm focusing only on 
> the sdpfrag related stuff.
>
> Section 8.1 says:
>
>    A valid application/sdpfrag part could be obtained by starting with
>    some valid SDP session description [I-D.ietf-mmusic-rfc4566bis] and
>    deleting any number of lines.
>
> Then section 8.2 says:
>
>    The ABNF of an 'application/sdpfrag' body is based on
>    [I-D.ietf-mmusic-rfc4566bis] with the following modification
>
>       ; SDPfrag Syntax
>              sdp-frag = *1proto-version
>                         *1origin-field
>                         *1session-name-field
>                         *1information-field
>                         *1uri-field
>                         *1email-fields
>                         *1phone-fields
>                         *1connection-field
>                         *1bandwidth-fields
>                         *1time-fields
>                         *1key-field
>                         *1attribute-fields
>                         *1media-descriptions
>
> Those two sections are inconsistent. Some of the individual elements 
> above (media-descriptions and time-fields) expand into more than one 
> line. This leads to the possibility that you could take valid SDP body 
> and delete some lines, leading to something that doesn't match the 
> above syntax.
I'll propose a more elaborate ABNF that will address this in the updated 
draft. I think it will just need a few tweaks.
>
> For example, media-descriptions allows a variety of other lines 
> following an m= line. If you take a valid SDP and delete the m= lines 
> you can get something that has a c= following an a=.
>
> Similarly, time-fields only allows an r= line following a t= line. 
> According to 8.1 you could take an SDP containing t=,r= and delete the 
> t=, leaving a "naked" r= line. But the sdp-frag syntax in 8.2 can't 
> generate that.
Will be fixed.
>
> Beyond that, both of those introduce context-sensitivity. E.g., an a= 
> following an m= has a different significance than one preceding the 
> first m=. If you removed all the m= lines from an SDP the result would 
> be incomprehensible. So the notion of stripping arbitrary lines from 
> and SDP and making sense of the result is nonsense.
I agree that you can generate nonsense by removing arbitray lines from 
SDP. However, I don't intent to prevent that in general.
In the next update I can put some warning text around this .
The draft already says "The exact content of an 'application/sdpfrag' 
body MUST be specified the using protocol."
Section 9.6 defines the necessary contraints for trickle-ice. Other 
future application will need to do something similar.
>
> It does turn out that the definition of trickle-ice-sdpfrag is 
> consistent with the syntax of sdp-frag. So there isn't a big problem. 
> If you remove/replace the textual definition of sipfrag in 8.1 then 
> things are consistent and make sense.
>
> But is there any need for application/sdpfrag? Wouldn't it be more 
> straightforward to define application/trickle-ice-sdpfrag?
My understanding from IETF90 was that there was consensus that the 
principle of taking vaild SDP and remove arbitrary lines should be kept,
but there need to be application-specific contraints that define the 
semantics of a specific sdpfrag body.
Since your issues can be fixed quite easily there isn't need to deviate 
from that concept.
Regards
Thomas
>
>     Thanks,
>     Paul
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic