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.