Re: [MMUSIC] Draft new version: draft-dtls-sdp-23

[Paul Kyzivat <[e-mail]>]

(retargeting to mmusic)

On 4/18/17 3:08 PM, Roman Shpount wrote:
> On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Section 8 has a number of normative requirements around the use of
>     'tls-id'. This seems to break interoperability with existing
>     implementations that follow RFC4572.
>
>     What is the intent here regarding interoperability with RFC4572?
>     Perhaps this doc should now also be a formal update to that.
>
>
> Should we reword those requirements that they only apply when tls-id is
> used?
>
> So instead of
>
> If an offerer or answerer inserts an SDP 'connection' attribute with a
> 'new' value in the offer/answer, the offerer/answerer MUST also insert
> an SDP 'tls-id' attribute with a new unique value.
>
> We would say:
>
> If an offerer or answerer inserts an SDP 'connection' attribute with a
> 'new' value in the offer/answer and also provides SDP 'tls-id'
> attribute, the value of tls-id' attribute MUST be new and unique.
>
> And instead of
>
> If an offerer or answerer inserts an SDP 'connection' attribute with a
> 'existing' value in the offer/answer, and if a previously established
> TLS connection exists, the offerer/answerer MUST also insert an SDP
> 'tls-id' attribute with the previously assigned value in the offer/answer.
>
> We would say
>
> If an offerer or answerer inserts an SDP 'connection' attribute with a
> 'existing' value in the offer/answer, if a previously established TLS
> connection exists, and if the offerer/answerer provided 'tls-id' value
> in the previous offer/answer which established this TLS connection,
> the offerer/answerer MUST also insert an SDP 'tls-id' attribute with the
> previously assigned value in the offer/answer.

I think that would do the trick.

> If we reword these statements like this, do we still need to specify
> that this document updates RFC4572?

In that case I think not.

	Thanks,
	Paul