Re: [rtcweb] ALPN question - other labels?

[Paul Kyzivat <[e-mail]>]

On 8/7/14 7:25 PM, Martin Thomson wrote:
> On 7 August 2014 14:24, Paul Kyzivat <[e-mail]> wrote:
>>     Only one of these labels can be used for any given session.  A peer
>>     acting in the client role MUST NOT offer both identifiers.  A peer in
>>     the server role that receives a ClientHello containing both labels
>>     MUST reject the session, though it MAY accept the confidential option
>>     and protect content accordingly.
>>
>> This does not quite say that a peer in a server role must reject a session
>> that contains some *other* label. It doesn't even explicitly forbid a peer
>> in a client role from offering some other label. Does it intend to do so?
>
> That's actually old, incorrect text.  I need to update the draft, but
> don't want to do every time that I make a change (I'm not looking to
> top Ian Hickson's record here).
>
> Here's what my copy says:
>
> """A peer that is not aware of whether it needs to request
> confidentiality can use either form. A peer in the client role MUST
> offer both identifiers if it is not aware of a need for
> confidentiality. A peer in the server role SHOULD select webrtc if it
> does not prefer either.""
> -- https://martinthomson.github.io/drafts/draft-ietf-rtcweb-alpn.html#rfc.section.2
>
> As to whether a completely different protocol is acceptable, the
> intent was to only cover the interaction of the two labels that are
> defined in the document.  If you want to do webrtc OR some other
> protocol, I see no reason not to permit that.

My primary question is how is a browser expected to behave if some other 
label is offered? Will it still support use of the JSEP APIs?

And, for interop reasons, will there be a way to get a browser to offer 
another label and still support the JSEP APIs if the other end accepts it?

	Thanks,
	Paul