Re: Unknown key shares in MMUSIC

Martin Thomson <[email protected]>
Newsgroups gmane.ietf.mmusic
Message-ID <CABkgnnVrx8qfD0AfOVb7AfS_7+8tGyohc8cSZ79dkBaReC8R_Q@mail.gmail.com>
On 17 March 2017 at 03:14, Roman Shpount <[email protected]> wrote:
> Alternatively we can keep dtls-id the way it is currently defined and define
> tls-id to be used for TLS-over-TCP  in the new draft.

I could accept tls-id.  But if tls-id and dtls-id are the same and
have similar semantics, then one attribute makes more sense.  Using a
"tls"-named attribute in DTLS isn't going to cause any real problems.

> I would also prefer a more generic name for the TLS extension itself. It
> does not have to be related to SDP, so some sort of endpoint_id would work
> better then sdp_dtls_id.

The point is to explicitly tie the TLS negotiation to the SDP.  I was
operating on the basis that SDP has a somewhat unique authentication
arrangement and that there weren't many other examples like it.

If you think that this could be made more general and applied to
protocols that don't use SDP, that's probably true.  But I can't think
of a protocol that uses the same basic mechanisms for authentication.

I'd be open to a change if you could name an example.  I don't like
building a general purpose mechanism with exactly one user; an example
would help in choosing the right semantics.
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.