Subject: [rtcweb] ALPN question - other labels?

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2014 17:24:30 -0400

Section 2 says:

    The following identifiers are defined for use in ALPN:
...
    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?

This could be an issue in interoperation. For instance, if CLUE 
endpoints want to be capable of interoperating with WebRTC devices must 
they always use one of the webrtc ALPN values?

This could be handled saying that any other ALPN value is to be treated 
by browsers as equivalent to "webrtc".

(Note: we haven't worked out in detail how to interoperate CLUE and 
WebRTC, but we are trying to ensure we don't do anything to preclude it.)

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Aug 2014 16:25:56 -0700

On 7 August 2014 14:24, Paul Kyzivat <[email-masked]> wrote:
> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Aug 2014 22:25:33 -0400

> 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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Aug 2014 19:41:43 -0700

ALPN requires that a peer in the server role reject the connection if it
can't select a protocol. That is what Firefox will do, though it will
tolerate no ALPN extension as long as it doesn't have confidential media.

That is an interesting question. You would need to teach the browser that
other protocol, I guess.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Aug 2014 12:12:54 -0400

On 8/7/14 10:41 PM, Martin Thomson wrote:
>
> On Aug 7, 2014 7:25 PM, "Paul Kyzivat" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  > 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?
>

Are you saying that the offering and acceptance of ALPN values is 
controlled totally by the browser, without any influence by the JS app?

>  > 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?
>
> That is an interesting question. You would need to teach the browser
> that other protocol, I guess.

IMO this would only be interesting if other values can also be used in 
the server role.

For now I think it is more important that you be very clear what you 
intend.

I think it means that CLUE implementations will always need to use 
"webrtc" as the ALPN for the CLUE data channel, so that it will be right 
when interoperating with WebRTC. That is possible, though it seems weird 
when not interoperating.

(I'm struggling to figure out what c-webrtc means for a native clue 
device, such as an MCU.)

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Aug 2014 09:43:18 -0700

On 8 August 2014 09:12, Paul Kyzivat <[email-masked]> wrote:
> Are you saying that the offering and acceptance of ALPN values is controlled
> totally by the browser, without any influence by the JS app?

Well, for the confidential media use case, it has to be.

> IMO this would only be interesting if other values can also be used in the
> server role.

Do you mean the server can pick something that the client didn't offer?

> For now I think it is more important that you be very clear what you intend.
>
> I think it means that CLUE implementations will always need to use "webrtc"
> as the ALPN for the CLUE data channel, so that it will be right when
> interoperating with WebRTC. That is possible, though it seems weird when not
> interoperating.

If the intent is to interoperate with WebRTC, by effectively sitting
on top of the WebRTC stack, then I don't find that to be particularly
strange.  That doesn't mean that you can't define a "clue" token,
which may or may not be identical or at least very similar to
"webrtc".

---

From: Christian Groves <[email-masked]>
Date: Tue, 12 Aug 2014 13:09:29 +1000

> which may or may not be identical or at least very similar to

I think it would be simpler to offer a "webrtc-datachannel" ALPN in 
addition to the ones defined that allows an endpoint to indicate that it 
is only using datachannel .

>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>