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

[Paul Kyzivat <[e-mail]>]

Thomas,

Comments inline...

On 7/24/15 6:46 AM, Thomas Stach wrote:
> 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.

This whole issue is aggravated by the obtuse way that the ABNF syntax of 
SDP is constructed. It makes it easy to miss seeing why there is a 
problem here. (It was only recently that I realized the complex 
relationship of t=,r=,z= and I've been studying this syntax for years.) 
It also complicates writing an ABNF for sdpfrag using references to 
rules in the SDP draft.

Since we have an SDPbis in progress, it might be worth discussing if we 
should clean up the ABNF used to define the SDP syntax, in a way that 
would make it clearer to a reader what is going on, and also simplify 
what you are looking for. For that matter, we might consider defining 
sdpfrag in sdpbis.

If we did this, we would have to be careful that the new abnf is 
equivalent to the old one, for backward compatibility. That should be 
quite straightforward to do.

There is a possibility that such a change could invalidate some other 
existing rfc or draft that references one of the affected rules. That 
would require some research.

>> 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 .

That would be helpful.

> 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.

My concern here is that this really means nobody needs/uses the syntax 
of sdpfrag. Everybody must define a new syntax, such that every body 
that matches the protocol-specific syntax also matches the sdpfrag 
syntax. This is in addition to the rule that every body that matches the 
sdp syntax must also match the sdpfrag syntax.

IIUC, the "value" of sdpfrag is that a single content-type can be 
defined and used for all these different protocols. But then the 
content-type isn't really precise, since not all bodies that conform to 
its syntax are value for any particular usage of it. ISTM that having a 
content-type that is specific to the allowed content would be 
preferable. If that is done, then there ceases to be any real need for 
sdpfrag.

>> 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.

I agree that it *can* be fixed as you say. The question is whether that 
is the best way forward.

	Thanks,
	Paul