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

Martin Thomson <[email protected]>
Newsgroups gmane.ietf.mmusic
Message-ID <CABkgnnVLA8KfAZ6DiU6PyAHeT1mfa32RgohTXr62UUjjD+ddvQ@mail.gmail.com>
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
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.