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

[Paul Kyzivat <[e-mail]>]

Inline...

On 9/29/15 6:27 PM, Roman Shpount wrote:
> On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>         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?
>
>
> I am concerned about existing implementations which are currently in the
> wild. There are plenty of implementations that do support "setup"
> attribute for DTLS (including all the WebRTC enabled browsers). If
> existing "setup" attribute would be extended to include the protocol
> suffix it will not be properly handled by current implementations.

Yes, that is a potential issue with extending the syntax of an existing 
attribute that wasn't specified with a hook for extensions.

> If
> setup attribute is used with protocol prefix, it is unclear if it will
> be correctly recognized by the remote party.

Am I right that there is no rfc specifying use of the setup attribute 
with dtls? (The IANA registry only has rfc4145 covering TCP.)

Once we get RFCs in place for this we can assume that those who conform 
to the RFCs will support whatever is specified. Those that don't support 
the rfc defining the new attribute should must it.

I do recognize that there are pre-rfc implementations in the field and 
we need to avoid breaking them. But I think that could be handled by 
having existing implementations start using *both* for awhile to handle 
the transition.

> On the other hand we can definitely use protocol attribute syntax for
> the connection attribute for DTLS, since this behavior is not defined
> anywhere yet.
>
> Also, please let me know if you need a more detailed explanation of
> dtls_ufrag option and its rational or if you simply need more time to
> get it sorted out.

I haven't seen a clear explanation - just a couple of sentences in an email.

But as best I understand it, I find it disturbing. It entangles dtls 
with ICE, even though the two are separate layers.

	Thanks,
	Paul