Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

BTW: in addition to the proposal Gunnar mentions:

   http://www.ietf.org/mail-archive/web/mmusic/current/msg14156.html

in a more recent message I offered another way to do same thing:

   http://mailarchive.ietf.org/arch/msg/mmusic/uhTpEitCbI9x5oIoDU4MAfcEJW0

The latter is a more general mechanism. But I think the issues are 
largely the same with either one.

	Thanks,
	Paul

On 9/29/15 5:26 PM, Paul Kyzivat wrote:
> On 9/29/15 3:40 PM, Roman Shpount wrote:
>> On Tue, Sep 29, 2015 at 4:23 AM, Schwarz, Albrecht (Albrecht)
>> <albrecht.schwarz@alcatel-lucent.com
>> <mailto:albrecht.schwarz@alcatel-lucent.com>> wrote:
>>
>>     there might be another approach by qualifying the "generic"
>>     attribute with protocol (stack) information.
>>     Paul made a good proposal as far as I remember:
>>
>>     see
>>     Re: [MMUSIC] SCTP-SDP: SDP connection attribute considerations
>>     http://www.ietf.org/mail-archive/web/mmusic/current/msg14156.html
>>
>>     => a=setup ... and "And do the same thing for a=connection."
>>
>>
>> This proposal is good except that it is unclear how to deduce which
>> version of connection or setup attribute is supported by the remote end
>> point. Without such indication there is a high chance that remote end
>> point will not be able to correctly parse and process the connection or
>> setup attribute with transport suffix.
>
> Can you clarify what situation you are concerned about?
>
> As long as we are defining behavior for cases that aren't currently
> supported at all, then it is simply a matter of writing the specs the
> way we want them.
>
> Are you concerned with backward compatibility with implementations in
> the wild?
>
>      Thanks,
>      Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>