Should draft-dtls-sdp-23 be a normative update to RFC4572

Re-sending to mmusic list and changing the title:

On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat <[email protected]>
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.

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

Regards,
_____________
Roman Shpount

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic