Re: [MMUSIC] SCTP AppID

[Paul Kyzivat <[e-mail]>]

(Disclaimer - ALPN is new to me. I just read the latest draft on it.)

Based on an initial reading, I question the applicability of ALPN to our 
situation. IIUC the "application layer protocols" described in this 
registry are intended to be appropriate candidates for use over TLS. I 
think that means they are defined to be used over a reliable byte single 
byte stream protocol. Certainly that is so for the ones in the initial 
registration.

It would make *no* sense to offer to run data channels over TLS. The 
definition requires SCTP as the underlying transport protocol.

And what we are defining isn't a single "protocol" in the conventional 
sense. It is a convention for using multiple SCTP streams, including the 
negotiation of an individual protocol for each one.

Arguably, ALPN would be more appropriate for declaring/negotiating the 
protocol on individual data channels. (But not really, since they are 
message oriented, not stream oriented, and reliability is optional, etc.)

I suppose ALPN could be generalized to be more widely applicable. But 
that would simply complicate it for its current intended use.

IMO we have something new here.

	Thanks,
	Paul

On 3/10/14 8:26 AM, Harald Alvestrand wrote:
> On 03/07/2014 12:22 PM, Martin Thomson wrote:
>> On 7 March 2014 11:10, Harald Alvestrand <[e-mail]> wrote:
>>> One irritating case in our particular use case is that we actually don't
>>> know the lowest layers ahead of time.
>> The fact that we are using wired Ethernet vs. WiFi is generally not
>> visible at the level we're doing this identification either.
>>
>> If it does not matter to the protocol semantics, then I believe it to
>> be safe to use the same identifier for two similar-but-not-identical
>> stacks.
>>
>> Yes, one might argue that TURN-TCP encapsulation is tangibly different
>> to non-encapsulated SRTP.  We can talk about those distinctions and
>> whether they require different identifiers, but in this case, I don't
>> see any need for distinction.
> I think we're both arguing that a tag should only identify
> SCTP-over-DTLS as the protocol stack. If so, we agree,
>
> No opinion on whether ALPN is useful for our use case; I don't
> understand it yet (haven't read the spec), so haven't formed one.
>
>            Harald
>