Re: [MMUSIC] New version of SDP UKS draft

[Christer Holmberg <[e-mail]>]

Hi,

I agree with Roman.

I suggest splitting the draft into two main parts: one parts which describes the concept in general, and another “Usage with SDP Offer/Answer” part which describes the SDP specific parts.

It then makes it easier for others to reference the generic part, and then add their “Usage with ORTC/Jingle/H.323/whatever” part.

Regards,

Christer

From: mmusic <[e-mail]<mailto:[e-mail]>> on behalf of Roman Shpount <[e-mail]<mailto:[e-mail]>>
Date: Tuesday 25 April 2017 at 01:04
To: Martin Thomson <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [MMUSIC] New version of SDP UKS draft


On Sun, Apr 23, 2017 at 7:08 PM, Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
On 22 April 2017 at 03:44, Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
> I have already mentioned that I prefer not to call this extension
> sdp_tls_id. Since this extension applies to Jingle and ORTC, this extension
> is not SDP specific. It should be called simply tls_id or tls_helo_id.

I apologize for missing this.  I've updated my copy of the draft.
I've named it external_session_id/ExternalSessionId so that it can be
used in some other context without issues.

Making this generic means that this document needs to either define
how the attribute is used generically, or it needs to state that
things other than SDP aren't in scope.

I've chosen to limit this to SDP.  If another protocol wants to fix
this problem, then they need to define the a=tls-id equivalent anyway;
they can define the hook into using this extension at the same time.

I think we can say that this document is limited to SDP with other protocols out of scope. ORT and Jingle can define how to signal tls-id in separate documents.

Regards,
_____________
Roman Shpount