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

Hi,

I agree that the draft should be an update to 8122 (not 4572). That was
actually my intention, but I forgot about it.

The changes suggested by Paul look good.

Regards,

Christer



On 19/04/17 02:39, "Martin Thomson" <[email protected]> wrote:

>I agree with Roman, we can and should just ensure that this is a new
>feature, not a rewrite.  I don't think that we need to invalidate RFC
>4572 implementations.  This is an enhancement (a very useful one, but
>an enhancement only).
>
>p.s., Any updating should be done to RFC 8122 now, if at all.  That
>probably removes any heat from the discussion as pertains to updating
>of old specs.
>
>On 19 April 2017 at 05:17, Roman Shpount <[email protected]> wrote:
>> 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
>>