Subject: [rtcweb] Review of draft-ietf-rtcweb-alpn-00

From: Michael Procter <[email-masked]>
Date: Thu, 24 Jul 2014 08:12:37 -0400

As promised, here is my review of the alpn draft.  There is one issue
that is not editorial in nature.

The final paragraph in section 2 reads:

   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.

I'm not sure of the reason behind insisting that the client only
offers one of the identifiers.  Is the intent to invoke
confidentiality negotiated elsewhere (i.e. in SDP) or is this
essentially the negotiation?  I can't find such a negotiation in other
documents.

The use case I have in mind is when I am trying to create a simple
session.  I am happy to have confidentiality at my end (the JS I am
using has no plans to access the media), but I can't insist on
confidentiality at your end, because I don't know if I will reach you
on a browser, or via some legacy comms network to your mobile phone.
It would seem reasonable to offer both c-webrtc and webrtc, and allow
the remote end to pick either, hoping that sometimes I will get
confidentiality.

Editorial tweaks:
The one-sentence paragraph beginning "A more thorough definition" is duplicated.

The penultimate paragraph in section 2 reads:
   There is no functional difference between the identifiers except with
   respect to the promise that an endpoint makes with respect to the
   confidentiality of session content.  An endpoint negotiating
   "c-webrtc" makes a promise to preserve the confidentiality of the
   data it receives.

I found this slightly confusing.  I think the following wording is
simpler but still captures the intent of the paragraph:
   There is no functional difference between the identifiers except
   that an endpoint negotiating
   "c-webrtc" makes a promise to preserve the confidentiality of the
   data it receives.

Best regards,

Michael

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Jul 2014 10:42:39 -0700

> essentially the negotiation?  I can't find such a negotiation in other

That's an error on my part.

I wrote that before I implemented it.  The code that I have permits
both tokens to be configured into clients. This is in fact necessary
in the case where a peer doesn't know whether confidentiality is
required, which is the default case.

Thanks for the editorial tweaks.