From nobody Tue Jan 2 15:36:29 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA2D1200F3; Tue, 2 Jan 2018 15:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwnWi9vubfsb; Tue, 2 Jan 2018 15:36:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18311120721; Tue, 2 Jan 2018 15:36:22 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w02NaHEL007056 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jan 2018 17:36:18 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <18FD1FCB-84D3-484A-81A4-FAB9A1A8A412@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5E465AB8-F1BF-4B60-8DFC-04E532E78AB2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 2 Jan 2018 17:36:16 -0600 In-Reply-To: Cc: The IESG , draft-ietf-rtcweb-jsep@ietf.org, RTCWeb IETF , rtcweb-chairs@ietf.org To: Justin Uberti References: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 23:36:24 -0000 --Apple-Mail=_5E465AB8-F1BF-4B60-8DFC-04E532E78AB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >=20 >=20 >> On Dec 21, 2017, at 8:31 PM, Justin Uberti = wrote: >>=20 [=E2=80=A6] >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> I'm balloting "yes", but I have some minor comments and nits: >>=20 >> Substantive: >>=20 >> - General: >> I still find the edges around where SDP is and isn't required a bit = vague. >> Section 3.3 says that the JSEP implementation internal representation = is SDP. >> While I have trouble imagining implementing this otherwise, do we = really mean >> to mandate the internals? Is there an assumption that said internal >> representation is _serialized_ SDP vs some abstract internal = representation? >>=20 > I suppose this could be restated to say that we can *think* of = SessionDescriptions > as SDP containers, but the internal representation could be > anything, as long as it can roundtrip to SDP. Would that be = preferable? I think that would be more accurate. >=20 >> Section 3.1 says that the signaling model is not specified. Is there = an >> implicit assumption that, however things are signaled, the signaling = process >> moves around serialized SDP? Or is it envisioned that one could write = an >> application without serialized SDP occurring anywhere above the API? >>=20 > The API does move around session descriptions, and, as mentioned = above, they > can be thought of as SDP containers. However, the application = signaling > protocol need not involve SDP at all, as mentioned: >=20 > JSEP does not specify a particular signaling model or state > machine, other than the generic need to exchange session > descriptions in the fashion described by > (offer/answer) >=20 > IOW, the app signaling model is not specified, but the API interaction > model does involve the use of SDP containers. The clarification you proposed to my previous comment helps here, too. >=20 >> -5, throughout: There are a number of normative keywords used in = constructions >> like "... MUST foo, as described in RFCXXX". That construction is = ambiguous >> about whether it defines a normative requirement to do something, and = the doing >> of that something is described in the RFC, or if describes the = referenced RFC >> as defining the MUST. >>=20 >> In general, it's best to avoid using 2119/8174 keywords to talk about = external >> requirements, except as a direct quote. I think this is especially = true here >> given the interdependencies between drafts in cluster 238. If in the = future we >> update a dependency to change a normative requirement, we risk = creating >> conflicts, and we make it unclear which text is authoritative. >>=20 > Generally, this is pointing the reader at a particular normative = section, > and saying that yeah, you MUST follow that section as written. = Perhaps > the use of 2119 language here isn't ideal, but I don't see this as > confusing. Do you have a suggestion about how this should be = handled instead? It=E2=80=99s a technicality, but it can create confusion about which = text is authoritative. That=E2=80=99s not an issue as long as both are = in agreement, but future updates to either this or that spec can easily = mess up that agreement. My personal preference is to reserve 2119/8174 keywords for the text = that is authoritative for the requirement, and to have other text that = refers to that requirement do it descriptively. For example, =E2=80=9CRFC = XXXX mandates foo=E2=80=9D. >=20 >> -5.1.1: I think the operative requirement is "MUST support" rather = than "MUST >> indicate support". (While indication may also be required, it seems a >> consequence of "MUST support".) >>=20 > Session descriptions can't really support these specs, but they can > indicate support by including the appropriate lines. I tend to = think > this is correct as written. To clarify, it seems like the root requirement is that JSEP = implementations MUST support ICE and DTLS/DTLS-SRTP. The requirement = for session descriptions to indicate support is a consequence of that. >=20 >> -5.1.2: " Any profile in the offer matching one of the following MUST = be >> accepted:" Isn't the real requirement that any of the following must = be >> interpreted the same, or otherwise in some specified way? I assume = there may be >> completely unrelated reasons to reject an m-section, but the "MUST be = accepted" >> language seems to overrule that. >>=20 > Yes, perhaps we could be clearer and say > "MUST be considered valid" (in reference to the profile). That would help, thanks. >=20 >> -5.4: "The SDP returned from createOffer or createAnswer MUST NOT be = changed >> before passing it to setLocalDescription." >> Is that a requirement on the JSEP implementation, or the javascript >> application? If the latter, is it appropriate to put normative = requirements on >> the application? It seems like it would be better to normatively = state the JSEP >> implementations's behavior when the application does something = incorrect. >> (Which seems to be done further down the page.) >>=20 > This section is, as you mention, application guidance. Perhaps RFC2119 > language doesn't make sense here, but the guidance here seems = like a good > summary for how the application should behave. My personal preference would be to avoid use of 2119 keywords for things = the JSEP implementation does not control. >=20 >> -5.7: " The effect of rollback MUST be the same regardless of whether >> setLocalDescription or setRemoteDescription is called." Does that = mean if I >> call setLocalDescription, then rollback with a call to = setRemoteDescription, >> _both_ are rolled back? >>=20 > Well, there is only a pending local at this point, and it is rolled = back by setRD. Okay. >=20 >> -5.8.3: The MUSTs in this section seem to be putting requirements on = the SDP >> being parsed. Shouldn't they instead describe the parser's behavior = based on >> that SDP input? The correctness of the SDP being parsed seems beyond = the >> control of the implementation. >>=20 > Yes, the correctness of the SDP is beyond the control of the impl, = but, > the handling of broken SDP is spelled out in the beginning of this = section: >=20 > If any line is not well-formed, or cannot be parsed as > described, the parser MUST stop with an error and reject the > session description, even if the value is to be discarded. = This > ensures that implementations do not accidentally misinterpret > ambiguous SDP. >=20 > Saying that a specific line MUST have X and Y is then a shorthand for > repeatedly saying that if the line cannot be parsed properly, the impl = MUST > stop with an error. Again, I don=E2=80=99t think the use of 2119/8174 keywords for things = beyond the control of the implementation fits the sense of those = documents. I suggest either stating these without 2119/8174 keywords, or = adding something to the boilerplate to the effect of =E2=80=9CWhen used = in to describe requirements for SDP inputs, these terms indicate = requirements for that SDP to be considered well-formed=E2=80=9D. >=20 >=20 >> -8, second paragraph: When describing how the javascript is = untrusted, it may >> be worth mentioning that it may have been downloaded from an = untrusted source. >>=20 > yes, we could simply say that it is untrustworthy as a result of being > downloaded from an untrusted source >=20 >>=20 >> Editorial and Nits: >>=20 >>=20 [=E2=80=A6] >> -3.6.2, 2nd paragraph: s/"may be producing"/"may produce" >>=20 > "may be producing" seems OK to me. Did you have a specific concern? >=20 Just a grammar nit. =E2=80=9Cmay be producing=E2=80=9D uses the = progressive aspect. That indicates temporary action ongoing at some = point of time. Is that the intent? >> -4.1.2: Please expand LS on first mention. (I can guess from context. = Please >> don't make me :-) ) >>=20 >> - 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP" >> "for each SDP line, the generation of the SDP will follow the process = defined >> for generating an initial offer from the document that specifies the = given SDP >> line." While I worked out what that means, I found "document" to be = ambiguous. >> At first I interpreted it as the "SDP document" rather than "the = RFC". (Note >> this occurs several times in subsequent sections.) >>=20 >> -4.1.8, third paragraph: ""pranswer" indicates that a description = should be >> parsed as an >> answer, but not a final answer" >> I think it would be more clear to say "... parsed as a provisional = answer, >> rather than a final answer". >>=20 > Parsing has only 2 modes, offers and answers; the provisionality of = the > answer only affects how it is handled once parsed. I think this = should > stay as-is. The existing text already talks about parsing as a final answer. If = parsing is the same either way, perhaps it should say =E2=80=9Ctreated = as=E2=80=9D rather than =E2=80=9Cparsed as=E2=80=9D? >=20 >=20 >> -5.2.1: Paragraph starting with: " Each m=3D section, provided it is = not marked >> as bundle-only, MUST generate..." The m=3D section is not the real = actor here, is >> it? >>=20 >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >=20 --Apple-Mail=_5E465AB8-F1BF-4B60-8DFC-04E532E78AB2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpMF3AACgkQgFZKbJXz 1A1RQg//asefve8eb25AlpyCmwCCbvz9G60lxI0cxJjkqV6v1Sf1kT9RUfhg/Kvw l3bYuBFe3yg00SesBfMPg1el/I+EIBgU6FT5ml2JuxIio6xmZngR8w50xTKrd1Ej 3H9b4oNkHCvaJcsmSBIry0/r1ED9PDs3yMcwHn3sa1RQsusPUeol8sL+kQZQFkdb BTrFv+yn2Cd1nUnpILP4pIrsiBRUZ+H0ExtYyDUM9LbyCLHbzeRhWNLLgQor6jLP L9RAtxkkouM6lN+R/CTU7C/D6PWQPkqfuAydsgHIq/ylEwlGIHMwpuBJCl0HMHaV Lh0zdHnJZNuaIKfRUrh1t+ROBEwENoKsH8HpkJ4YQg02ot8fnxwYPWcoiNPBcNGx jgkw/sN0JpsIN6PTY2H198E08nabsuxUJ2Orcn8CONeShf+1NFc8YAJw5y7WvV8o FzyVzsVsahe5tT4FYxb4/EIexYdlObXPNpWS3mwg+nS8DChzn1U+ktPqpOL540Vg b4enr/MXLpiBvxaAk+Tt6Dp1pU+8L7mx5U/ZKN1C8sI3b8vpu6y4houkj6sV9Ruj 61x9QckUQ8hgax8VbWEcgqAAqxsiTpGmRafCrWlKepu+NCIkBDdpxt6WOIRs5a6O mojyT6w4gnuINcUvotq9SrbQ4jAi1CjBt54j5qBWPr5nVnkVbPk= =dQwF -----END PGP SIGNATURE----- --Apple-Mail=_5E465AB8-F1BF-4B60-8DFC-04E532E78AB2-- From nobody Tue Jan 2 15:45:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B23112D84E for ; Tue, 2 Jan 2018 15:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hqL2UmhwAbP for ; Tue, 2 Jan 2018 15:45:14 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA15C1200F3 for ; Tue, 2 Jan 2018 15:45:13 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id g191so14823ywe.7 for ; Tue, 02 Jan 2018 15:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OB55bH81wm2Yba6OvOTO9a/gPZIot1dqAbz0UjdJl+A=; b=ejAcUI9i/kXlwIxeFI52dX1OH9cSYN5rVABH7s9zxJiJsZpzJy4QZPSwY0JRK05Pyv vBPYa6o+70F8JZmyiRVAsqAr/6mAA8ALghBMWF5EpMLCLrDtEImHHUN1kVoB5A5uEktH GKceXCHgjLveChB35WGAC5UHubUcaRXZRf6KUi8RiRcNPv7rPGzJnU0yWUs9jmv1NX35 kaFokeVrNKx+RyyQLaF3BcLjReH01K1WJOlz2u9FeosszW5QSeHsQemGK18A46qKdxqa O+otcc0V35esovU2zbSF8vDGbZBpfsZX7QzQzrZOOMQmOD219FzcBO+20QD3cB6od6t+ Npfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OB55bH81wm2Yba6OvOTO9a/gPZIot1dqAbz0UjdJl+A=; b=NZfsJvqaNrvs645VMEmP3nBW6J8Yk2X4cZjJJaCnUsAfF6PAjHLnNjnhMZFsunFRGL 4rgm/T0PvvqJ+zCiM9Gidwgkm4RRliuTzeGixI7xBeJZa0sWruagdcmZnXBg25OwKMV6 /PBTDco1wH36tg5+YI7XVKxPK7Hjo+FzfHRxQ6DewPxB3tXMsftEY5ngNYpvN7bbE3pH vyOfAOVFDZtsFa7lFUm4nGjA1xkEDXi7wuUcKIp12256yP+2+HLxurCxMpzePvJNAdlG iqJ/J8bXtN2+bkzt53L58SLBR5SSRfYyH30XK9Z8noYpOHzpEwvZr2OvLxMekmS0Y+qO DBiA== X-Gm-Message-State: AKGB3mJoxc3wd2Te5dXcolIgsOik729NRhemAp+oonL0SUyNVv/f8ukf EGtKqIwVAmf7IPNhKv44g69g3GixtHVFOigC5ed1sjxk X-Google-Smtp-Source: ACJfBouwfkF8bdC4eFjZqtvDLLMj1A92NltQTIhZnIqFcmRjZmIXlfFfcQIhDhMCab2N0UeAcyfmFZ/t+Tul8zaFaVE= X-Received: by 10.129.48.202 with SMTP id w193mr34907381yww.378.1514936712851; Tue, 02 Jan 2018 15:45:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 15:44:32 -0800 (PST) In-Reply-To: <18FD1FCB-84D3-484A-81A4-FAB9A1A8A412@nostrum.com> References: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com> <18FD1FCB-84D3-484A-81A4-FAB9A1A8A412@nostrum.com> From: Eric Rescorla Date: Tue, 2 Jan 2018 15:44:32 -0800 Message-ID: To: Ben Campbell Cc: Justin Uberti , The IESG , draft-ietf-rtcweb-jsep@ietf.org, RTCWeb IETF , rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a11409cfaa08a180561d3b03d" Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 23:45:17 -0000 --001a11409cfaa08a180561d3b03d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jan 2, 2018 at 3:36 PM, Ben Campbell wrote: > > > > > >> On Dec 21, 2017, at 8:31 PM, Justin Uberti wrote: > >> > > [=E2=80=A6] > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> I'm balloting "yes", but I have some minor comments and nits: > >> > >> Substantive: > >> > >> - General: > >> I still find the edges around where SDP is and isn't required a bit > vague. > >> Section 3.3 says that the JSEP implementation internal representation > is SDP. > >> While I have trouble imagining implementing this otherwise, do we > really mean > >> to mandate the internals? Is there an assumption that said internal > >> representation is _serialized_ SDP vs some abstract internal > representation? > >> > > I suppose this could be restated to say that we can *think* of > SessionDescriptions > > as SDP containers, but the internal representation could be > > anything, as long as it can roundtrip to SDP. Would that be preferable? > > I think that would be more accurate. > > > > >> Section 3.1 says that the signaling model is not specified. Is there a= n > >> implicit assumption that, however things are signaled, the signaling > process > >> moves around serialized SDP? Or is it envisioned that one could write = an > >> application without serialized SDP occurring anywhere above the API? > >> > > The API does move around session descriptions, and, as mentioned above, > they > > can be thought of as SDP containers. However, the application signaling > > protocol need not involve SDP at all, as mentioned: > > > > JSEP does not specify a particular signaling model or state > > machine, other than the generic need to exchange session > > descriptions in the fashion described by > > (offer/answer) > > > > IOW, the app signaling model is not specified, but the API interaction > > model does involve the use of SDP containers. > > The clarification you proposed to my previous comment helps here, too. > > > > >> -5, throughout: There are a number of normative keywords used in > constructions > >> like "... MUST foo, as described in RFCXXX". That construction is > ambiguous > >> about whether it defines a normative requirement to do something, and > the doing > >> of that something is described in the RFC, or if describes the > referenced RFC > >> as defining the MUST. > >> > >> In general, it's best to avoid using 2119/8174 keywords to talk about > external > >> requirements, except as a direct quote. I think this is especially tru= e > here > >> given the interdependencies between drafts in cluster 238. If in the > future we > >> update a dependency to change a normative requirement, we risk creatin= g > >> conflicts, and we make it unclear which text is authoritative. > >> > > Generally, this is pointing the reader at a particular normative sectio= n, > > and saying that yeah, you MUST follow that section as written. Perha= ps > > the use of 2119 language here isn't ideal, but I don't see this as > > confusing. Do you have a suggestion about how this should be handled > instead? > > It=E2=80=99s a technicality, but it can create confusion about which text= is > authoritative. That=E2=80=99s not an issue as long as both are in agreeme= nt, but > future updates to either this or that spec can easily mess up that > agreement. > > My personal preference is to reserve 2119/8174 keywords for the text that > is authoritative for the requirement, and to have other text that refers = to > that requirement do it descriptively. For example, =E2=80=9CRFC XXXX mand= ates foo=E2=80=9D. > I guess this is a matter of opinion. I think that it's useful to list the rules here using 2119 language. I think the text makes clear that in this construction it's the RFC that we are pointing to that's authoritative. > > > > > > >> -5.1.2: " Any profile in the offer matching one of the following MUST = be > >> accepted:" Isn't the real requirement that any of the following must b= e > >> interpreted the same, or otherwise in some specified way? I assume > there may be > >> completely unrelated reasons to reject an m-section, but the "MUST be > accepted" > >> language seems to overrule that. > >> > > Yes, perhaps we could be clearer and say > > "MUST be considered valid" (in reference to the profile). > > That would help, thanks. > > > > >> -5.4: "The SDP returned from createOffer or createAnswer MUST NOT be > changed > >> before passing it to setLocalDescription." > >> Is that a requirement on the JSEP implementation, or the javascript > >> application? If the latter, is it appropriate to put normative > requirements on > >> the application? It seems like it would be better to normatively state > the JSEP > >> implementations's behavior when the application does something > incorrect. > >> (Which seems to be done further down the page.) > >> > > This section is, as you mention, application guidance. Perhaps RFC2119 > > language doesn't make sense here, but the guidance here seems like > a good > > summary for how the application should behave. > > My personal preference would be to avoid use of 2119 keywords for things > the JSEP implementation does not control. > > > > >> -5.7: " The effect of rollback MUST be the same regardless of whether > >> setLocalDescription or setRemoteDescription is called." Does that mean > if I > >> call setLocalDescription, then rollback with a call to > setRemoteDescription, > >> _both_ are rolled back? > >> > > Well, there is only a pending local at this point, and it is rolled bac= k > by setRD. > > Okay. > > > > >> -5.8.3: The MUSTs in this section seem to be putting requirements on > the SDP > >> being parsed. Shouldn't they instead describe the parser's behavior > based on > >> that SDP input? The correctness of the SDP being parsed seems beyond t= he > >> control of the implementation. > >> > > Yes, the correctness of the SDP is beyond the control of the impl, but, > > the handling of broken SDP is spelled out in the beginning of this > section: > > > > If any line is not well-formed, or cannot be parsed as > > described, the parser MUST stop with an error and reject the > > session description, even if the value is to be discarded. This > > ensures that implementations do not accidentally misinterpret > > ambiguous SDP. > > > > Saying that a specific line MUST have X and Y is then a shorthand for > > repeatedly saying that if the line cannot be parsed properly, the impl > MUST > > stop with an error. > > Again, I don=E2=80=99t think the use of 2119/8174 keywords for things bey= ond the > control of the implementation fits the sense of those documents. I sugges= t > either stating these without 2119/8174 keywords, or adding something to t= he > boilerplate to the effect of =E2=80=9CWhen used in to describe requiremen= ts for SDP > inputs, these terms indicate requirements for that SDP to be considered > well-formed=E2=80=9D. > I'm comfortable with the current language.... -Ekr > > > > > >> -8, second paragraph: When describing how the javascript is untrusted, > it may > >> be worth mentioning that it may have been downloaded from an untrusted > source. > >> > > yes, we could simply say that it is untrustworthy as a result of being > > downloaded from an untrusted source > > > >> > >> Editorial and Nits: > >> > >> > > [=E2=80=A6] > > >> -3.6.2, 2nd paragraph: s/"may be producing"/"may produce" > >> > > "may be producing" seems OK to me. Did you have a specific concern? > > > > Just a grammar nit. =E2=80=9Cmay be producing=E2=80=9D uses the progressi= ve aspect. That > indicates temporary action ongoing at some point of time. Is that the > intent? > > >> -4.1.2: Please expand LS on first mention. (I can guess from context. > Please > >> don't make me :-) ) > >> > >> - 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP" > >> "for each SDP line, the generation of the SDP will follow the process > defined > >> for generating an initial offer from the document that specifies the > given SDP > >> line." While I worked out what that means, I found "document" to be > ambiguous. > >> At first I interpreted it as the "SDP document" rather than "the RFC". > (Note > >> this occurs several times in subsequent sections.) > >> > >> -4.1.8, third paragraph: ""pranswer" indicates that a description > should be > >> parsed as an > >> answer, but not a final answer" > >> I think it would be more clear to say "... parsed as a provisional > answer, > >> rather than a final answer". > >> > > Parsing has only 2 modes, offers and answers; the provisionality of the > > answer only affects how it is handled once parsed. I think this > should > > stay as-is. > > The existing text already talks about parsing as a final answer. If > parsing is the same either way, perhaps it should say =E2=80=9Ctreated as= =E2=80=9D rather > than =E2=80=9Cparsed as=E2=80=9D? > > > > > > >> -5.2.1: Paragraph starting with: " Each m=3D section, provided it is n= ot > marked > >> as bundle-only, MUST generate..." The m=3D section is not the real act= or > here, is > >> it? > >> > >> > >> _______________________________________________ > >> rtcweb mailing list > >> rtcweb@ietf.org > >> https://www.ietf.org/mailman/listinfo/rtcweb > >> > > > --001a11409cfaa08a180561d3b03d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 2, 2018 at 3:36 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>
>> On Dec 21, 2017, at 8:31 PM, Justin Uberti <juberti@google.com> wrote:
>>

[=E2=80=A6]


>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> I'm balloting "yes", but I have some minor comments = and nits:
>>
>> Substantive:
>>
>> - General:
>> I still find the edges around where SDP is and isn't required = a bit vague.
>> Section 3.3 says that the JSEP implementation internal representat= ion is SDP.
>> While I have trouble imagining implementing this otherwise, do we = really mean
>> to mandate the internals? Is there an assumption that said interna= l
>> representation is _serialized_ SDP vs some abstract internal repre= sentation?
>>
> I suppose this could be restated to say that we can *think* of Session= Descriptions
> as SDP containers, but the internal representation could be
> anything, as long as it can roundtrip to SDP. Would that be preferable= ?

I think that would be more accurate.

>
>> Section 3.1 says that the signaling model is not specified. Is the= re an
>> implicit assumption that, however things are signaled, the signali= ng process
>> moves around serialized SDP? Or is it envisioned that one could wr= ite an
>> application without serialized SDP occurring anywhere above the AP= I?
>>
> The API does move around session descriptions, and, as mentioned above= , they
> can be thought of as SDP containers. However, the application signalin= g
> protocol need not involve SDP at all, as mentioned:
>
>=C2=A0 =C2=A0 =C2=A0 JSEP does not specify a particular signaling model= or state
>=C2=A0 =C2=A0 =C2=A0 machine, other than the generic need to exchange s= ession
>=C2=A0 =C2=A0 =C2=A0 descriptions in the fashion described by
>=C2=A0 =C2=A0 =C2=A0 <xref target=3D"RFC3264"></xref= > (offer/answer)
>
> IOW, the app signaling model is not specified, but the API interaction=
> model does involve the use of SDP containers.

The clarification you proposed to my previous comment helps here, to= o.

>
>> -5, throughout: There are a number of normative keywords used in c= onstructions
>> like "... MUST foo, as described in RFCXXX". That constr= uction is ambiguous
>> about whether it defines a normative requirement to do something, = and the doing
>> of that something is described in the RFC, or if describes the ref= erenced RFC
>> as defining the MUST.
>>
>> In general, it's best to avoid using 2119/8174 keywords to tal= k about external
>> requirements, except as a direct quote. I think this is especially= true here
>> given the interdependencies between drafts in cluster 238. If in t= he future we
>> update a dependency to change a normative requirement, we risk cre= ating
>> conflicts, and we make it unclear which text is authoritative.
>>
> Generally, this is pointing the reader at a particular normative secti= on,
>=C2=A0 =C2=A0 and saying that yeah, you MUST follow that section as wri= tten. Perhaps
>=C2=A0 =C2=A0 the use of 2119 language here isn't ideal, but I don&= #39;t see this as
>=C2=A0 =C2=A0 confusing. Do you have a suggestion about how this should= be handled instead?

It=E2=80=99s a technicality, but it can create confusion about which= text is authoritative. That=E2=80=99s not an issue as long as both are in = agreement, but future updates to either this or that spec can easily mess u= p that agreement.

My personal preference is to reserve 2119/8174 keywords for the text that i= s authoritative for the requirement, and to have other text that refers to = that requirement do it descriptively. For example, =E2=80=9CRFC XXXX mandat= es foo=E2=80=9D.

I guess this is a matt= er of opinion. I think that it's useful to list the rules here using
2119 language. I think the text makes clear that in this constructi= on it's the
RFC that we are pointing to that's authoritat= ive.
=C2=A0



>
>> -5.1.2: " Any profile in the offer matching one of the follow= ing MUST be
>> accepted:" Isn't the real requirement that any of the fol= lowing must be
>> interpreted the same, or otherwise in some specified way? I assume= there may be
>> completely unrelated reasons to reject an m-section, but the "= ;MUST be accepted"
>> language seems to overrule that.
>>
> Yes, perhaps we could be clearer and say
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 "MUST be considered valid" (in re= ference to the profile).

That would help, thanks.

>
>> -5.4: "The SDP returned from createOffer or createAnswer MUST= NOT be changed
>>=C2=A0 =C2=A0 before passing it to setLocalDescription."
>> Is that a requirement on the JSEP implementation, or the javascrip= t
>> application? If the latter, is it appropriate to put normative req= uirements on
>> the application? It seems like it would be better to normatively s= tate the JSEP
>> implementations's behavior when the application does something= incorrect.
>> (Which seems to be done further down the page.)
>>
> This section is, as you mention, application guidance. Perhaps RFC2119=
>=C2=A0 =C2=A0 =C2=A0 language doesn't make sense here, but the guid= ance here seems like a good
>=C2=A0 =C2=A0 =C2=A0 summary for how the application should behave.

My personal preference would be to avoid use of 2119 keywords for th= ings the JSEP implementation does not control.

>
>> -5.7: " The effect of rollback MUST be the same regardless of= whether
>> setLocalDescription or setRemoteDescription is called." Does = that mean if I
>> call setLocalDescription, then rollback with a call to setRemoteDe= scription,
>> _both_ are rolled back?
>>
> Well, there is only a pending local at this point, and it is rolled ba= ck by setRD.

Okay.

>
>> -5.8.3: The MUSTs in this section seem to be putting requirements = on the SDP
>> being parsed. Shouldn't they instead describe the parser's= behavior based on
>> that SDP input? The correctness of the SDP being parsed seems beyo= nd the
>> control of the implementation.
>>
> Yes, the correctness of the SDP is beyond the control of the impl, but= ,
> the handling of broken SDP is spelled out in the beginning of this sec= tion:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If any line is not well-formed, or ca= nnot be parsed as
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0described, the parser MUST stop with = an error and reject the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session description, even if the valu= e is to be discarded. This
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ensures that implementations do not a= ccidentally misinterpret
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ambiguous SDP.
>
> Saying that a specific line MUST have X and Y is then a shorthand for<= br> > repeatedly saying that if the line cannot be parsed properly, the impl= MUST
> stop with an error.

Again, I don=E2=80=99t think the use of 2119/8174 keywords for thing= s beyond the control of the implementation fits the sense of those document= s. I suggest either stating these without 2119/8174 keywords, or adding som= ething to the boilerplate to the effect of =E2=80=9CWhen used in to describ= e requirements for SDP inputs, these terms indicate requirements for that S= DP to be considered well-formed=E2=80=9D.

I'm comfortable with the current language....

-Ekr


>
>
>> -8, second paragraph: When describing how the javascript is untrus= ted, it may
>> be worth mentioning that it may have been downloaded from an untru= sted source.
>>
> yes, we could simply say that it is untrustworthy as a result of being=
> downloaded from an untrusted source
>
>>
>> Editorial and Nits:
>>
>>

[=E2=80=A6]

>> -3.6.2, 2nd paragraph: s/"may be producing"/"may pr= oduce"
>>
> "may be producing" seems OK to me. Did you have a specific c= oncern?
>

Just a grammar nit. =E2=80=9Cmay be producing=E2=80=9D uses the prog= ressive aspect. That indicates temporary action ongoing at some point of ti= me. Is that the intent?

>> -4.1.2: Please expand LS on first mention. (I can guess from conte= xt. Please
>> don't make me :-)=C2=A0 )
>>
>> - 4.1.6: s/"codec/RTP/RTCP"/"codec, RTC, or RTCP&qu= ot;
>> "for each SDP line, the generation of the SDP will follow the= process defined
>> for generating an initial offer from the document that specifies t= he given SDP
>> line." While I worked out what that means, I found "docu= ment" to be ambiguous.
>> At first I interpreted it as the "SDP document" rather t= han "the RFC". (Note
>> this occurs several times in subsequent sections.)
>>
>> -4.1.8, third paragraph: ""pranswer" indicates that= a description should be
>> parsed as an
>>=C2=A0 =C2=A0 answer, but not a final answer"
>> I think it would be more clear to say "... parsed as a provis= ional answer,
>> rather than a final answer".
>>
> Parsing has only 2 modes, offers and answers; the provisionality of th= e
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 answer only affects how it is handled once = parsed. I think this should
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 stay as-is.

The existing text already talks about parsing as a final answer. If = parsing is the same either way, perhaps it should say =E2=80=9Ctreated as= =E2=80=9D rather than =E2=80=9Cparsed as=E2=80=9D?

>
>
>> -5.2.1: Paragraph starting with: " Each m=3D section, provide= d it is not marked
>> as bundle-only, MUST generate..." The m=3D section is not the= real actor here, is
>> it?
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcw= eb
>>
>

--001a11409cfaa08a180561d3b03d-- From nobody Tue Jan 2 16:29:46 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A4B120721; Tue, 2 Jan 2018 16:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPmQP9rB6KYE; Tue, 2 Jan 2018 16:29:39 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2262D127137; Tue, 2 Jan 2018 16:29:38 -0800 (PST) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w030TZ8W012737 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Jan 2018 18:29:36 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_A7C02BCB-4F25-44F0-9023-3D65A856F0F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 2 Jan 2018 18:29:34 -0600 In-Reply-To: Cc: Justin Uberti , The IESG , draft-ietf-rtcweb-jsep@ietf.org, RTCWeb IETF , rtcweb-chairs@ietf.org To: Eric Rescorla References: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com> <18FD1FCB-84D3-484A-81A4-FAB9A1A8A412@nostrum.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:29:41 -0000 --Apple-Mail=_A7C02BCB-4F25-44F0-9023-3D65A856F0F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [=E2=80=A6] > > >> >> -5, throughout: There are a number of normative keywords used in = constructions >> >> like "... MUST foo, as described in RFCXXX". That construction is = ambiguous >> >> about whether it defines a normative requirement to do something, = and the doing >> >> of that something is described in the RFC, or if describes the = referenced RFC >> >> as defining the MUST. >> >> >> >> In general, it's best to avoid using 2119/8174 keywords to talk = about external >> >> requirements, except as a direct quote. I think this is especially = true here >> >> given the interdependencies between drafts in cluster 238. If in = the future we >> >> update a dependency to change a normative requirement, we risk = creating >> >> conflicts, and we make it unclear which text is authoritative. >> >> >> > Generally, this is pointing the reader at a particular normative = section, >> > and saying that yeah, you MUST follow that section as written. = Perhaps >> > the use of 2119 language here isn't ideal, but I don't see this = as >> > confusing. Do you have a suggestion about how this should be = handled instead? >>=20 >> It=E2=80=99s a technicality, but it can create confusion about which = text is authoritative. That=E2=80=99s not an issue as long as both are = in agreement, but future updates to either this or that spec can easily = mess up that agreement. >>=20 >> My personal preference is to reserve 2119/8174 keywords for the text = that is authoritative for the requirement, and to have other text that = refers to that requirement do it descriptively. For example, =E2=80=9CRFC = XXXX mandates foo=E2=80=9D. >>=20 > I guess this is a matter of opinion. > I think that it's useful to list the rules here using > 2119 language. I think the text makes clear that in this construction = it's the > RFC that we are pointing to that's authoritative. >=20 Well, yes, I stated my opinion. To further clarify that opinion: Having = a given MUST/SHOULD/etc in more than one place makes updates error = prone. If we update the language in dependency in the future, we may = also need to update this draft. People updating the dependency may not = even be aware of this draft. And yes, I realize this concern is highly = dependent on the =E2=80=9Cwhat does it mean to update an RFC=E2=80=9D = philosophical discussion that never seems to resolve. In any case, it=E2=80=99s not a blocking comment; people are free to = ignore it. >> > >> >> -5.8.3: The MUSTs in this section seem to be putting requirements = on the SDP >> >> being parsed. Shouldn't they instead describe the parser's = behavior based on >> >> that SDP input? The correctness of the SDP being parsed seems = beyond the >> >> control of the implementation. >> >> >> > Yes, the correctness of the SDP is beyond the control of the impl, = but, >> > the handling of broken SDP is spelled out in the beginning of this = section: >> > >> > If any line is not well-formed, or cannot be parsed as >> > described, the parser MUST stop with an error and reject = the >> > session description, even if the value is to be discarded. = This >> > ensures that implementations do not accidentally = misinterpret >> > ambiguous SDP. >> > >> > Saying that a specific line MUST have X and Y is then a shorthand = for >> > repeatedly saying that if the line cannot be parsed properly, the = impl MUST >> > stop with an error. >>=20 >> Again, I don=E2=80=99t think the use of 2119/8174 keywords for things = beyond the control of the implementation fits the sense of those = documents. I suggest either stating these without 2119/8174 keywords, or = adding something to the boilerplate to the effect of =E2=80=9CWhen used = in to describe requirements for SDP inputs, these terms indicate = requirements for that SDP to be considered well-formed=E2=80=9D. >>=20 > I'm comfortable with the current language=E2=80=A6. Again, non-blocking comment=E2=80=A6. Ben. --Apple-Mail=_A7C02BCB-4F25-44F0-9023-3D65A856F0F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlpMI+4ACgkQgFZKbJXz 1A3wmxAAgB0ASnyF2lnszoAh1aO5+QVOMToJw7hJuea8OgeLI/5fnIdDZxw7Vtwk WGSVvXLmTann1IrGfllW/Bmz+Bxl66nVa8UG1By8F7Fug4CGS6x+V0x6np+QpwWO IJB8eI9Y8nXSUF3p+DP/HC+6fNg/eA8F9iCyyLEDjYx/a9yB+woytjN2FPJtCcUF zlt/oIkVR7hfHosgyaS3mNr2jow/onjoN8JUaZbNsbWX1xpsDTQB35QmLLKYh+XZ bsd7ezndmS3GBv9bcwfNCWeIZc6f4JdDuuPbVz5W6NhGVeKTnRFfQelcqX4q3uXM vfVoUUIJ3FVkK5HRIPmJVHNdDA2AUgfn3MFH4Ba8/Tu2p94BRJ/YhZiV7tBmVymp hubvJhYHraYZvBEw48d2Ux9+eRy/tbbthiwpjkz31gIGWVXLbNXbwYlmBu2JcmLW H4fPerQLxjZ9sOOjfKlCV8nxWy+Z68ysy/MjNc1sh7ynLrBRGB25XBwkSicS1enc 9ZrRiKlxSIdd7ZZMadbL/lDmJmiJP2IHz8hUyFK5VJ1C9Jndaf5OqaUy6aj0loHL D/a/dQ+iaxXjgjP8pQEj+qMqQ8kUaJK99eid22C1V0EEEBbkS1pPHxNMbYxPaM9k 03BX8IaPfcDzJDYbAGCYcvc56y5I9w6kRIJNDbTnw7W4O0nlwSE= =lKsg -----END PGP SIGNATURE----- --Apple-Mail=_A7C02BCB-4F25-44F0-9023-3D65A856F0F2-- From nobody Tue Jan 2 16:36:50 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AFF1200F3 for ; Tue, 2 Jan 2018 16:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bPA0twfwpWo for ; Tue, 2 Jan 2018 16:36:47 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590CB1271DF for ; Tue, 2 Jan 2018 16:36:45 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id a82so54627ybg.1 for ; Tue, 02 Jan 2018 16:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4pIIko8g+MRHvQX9HVLKjZwqMTLHyXx71KIxBbubdOc=; b=g4cshB2SFZ3NCstk87THz9YTQ2XZSwY3pYdpTkLjyv0+L6eV7Tqp+SE11B+kVb4nGC F3yhodRgrHsRT80jB1WqMtI8HU+zEokWs5Y1Mr0+YJS6hTBVVsnBP9Ew+JvLOXeKyGRT k536XnNfstCrcvV5M/Gw4OrSaZaRw0XJAR/4VKsPK/duu/6JBsz94q9ByMSu+JdqBkpm TV3IEf+dpMW+uhtl/paIAl8BdCuvQnR4TquUkVDMvyJ23Ksm7maLzJP565qsroLPiX4q 7Jp7xpkHP8nZxANQExaxKJ+RQRUd0qcD2r4MTJqzaeUDpA0HmofwG9W22s9RxXwwWUlN osRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4pIIko8g+MRHvQX9HVLKjZwqMTLHyXx71KIxBbubdOc=; b=g7Tsp2ynSWe4kuRiuiUVu4NWK2Z3RbTwzp3ApyETNOf0EsHh7GgGswjD4+KOugcL0S TFIUdl4j+HzEIJp+hZfekppe55jV2l5UE5sVOnKcP0tvprEfEtpPoeVcLRIc7bOZv1Yt KSgMuii2ZSwrZUErh1RIspDV4Vd+/JrI5hrnaugOyMpzlpPvsDLsGBnb4UD99dTegt8x jm42N0VK/qoB/5Bg1KtBdKM5UF1/zS4PY96q+CJ8zUDEHABE7eq1XhLTzrX/goKUw5Qz gtiB4Q/XkPV30elZLHAkq6TLvZeAP8JFbIgg83e0vEOvtGcQdF2dx2pBU7M/9c1GBEXy KSOw== X-Gm-Message-State: AKGB3mILTyyy3hzgR2KJ96lIhPGoGxSNIXaczoqWfdYUVKj27EcJLrgS Jh4Pl94pQfVKpo/NYLiv4CpL+dfcRpPMogecoky/HuAw X-Google-Smtp-Source: ACJfBosLMhOlrmV3zWEL05pfYhEfU2xLttKK3VbeIzqCzv3nOLjGFSv632eQV84pdRbwpc5Dc7P1RTx/rWbCKUAQ6BQ= X-Received: by 10.37.224.4 with SMTP id x4mr36619748ybg.200.1514939804362; Tue, 02 Jan 2018 16:36:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Tue, 2 Jan 2018 16:36:03 -0800 (PST) In-Reply-To: References: <151305054509.20498.9053592362460423618.idtracker@ietfa.amsl.com> <18FD1FCB-84D3-484A-81A4-FAB9A1A8A412@nostrum.com> From: Eric Rescorla Date: Tue, 2 Jan 2018 16:36:03 -0800 Message-ID: To: Ben Campbell Cc: Justin Uberti , The IESG , draft-ietf-rtcweb-jsep@ietf.org, RTCWeb IETF , rtcweb-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c084a94e53f690561d46822" Archived-At: Subject: Re: [rtcweb] Ben Campbell's Yes on draft-ietf-rtcweb-jsep-24: (with COMMENT) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jan 2018 00:36:49 -0000 --94eb2c084a94e53f690561d46822 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just for maximum clarity: given that these comments are non-blocking, my intent is to leave the document as-is, subject to strong opinions by my co-authors. On Tue, Jan 2, 2018 at 4:29 PM, Ben Campbell wrote: > > [=E2=80=A6] > > > > > >> >> -5, throughout: There are a number of normative keywords used in > constructions > >> >> like "... MUST foo, as described in RFCXXX". That construction is > ambiguous > >> >> about whether it defines a normative requirement to do something, > and the doing > >> >> of that something is described in the RFC, or if describes the > referenced RFC > >> >> as defining the MUST. > >> >> > >> >> In general, it's best to avoid using 2119/8174 keywords to talk > about external > >> >> requirements, except as a direct quote. I think this is especially > true here > >> >> given the interdependencies between drafts in cluster 238. If in th= e > future we > >> >> update a dependency to change a normative requirement, we risk > creating > >> >> conflicts, and we make it unclear which text is authoritative. > >> >> > >> > Generally, this is pointing the reader at a particular normative > section, > >> > and saying that yeah, you MUST follow that section as written. > Perhaps > >> > the use of 2119 language here isn't ideal, but I don't see this a= s > >> > confusing. Do you have a suggestion about how this should be > handled instead? > >> > >> It=E2=80=99s a technicality, but it can create confusion about which t= ext is > authoritative. That=E2=80=99s not an issue as long as both are in agreeme= nt, but > future updates to either this or that spec can easily mess up that > agreement. > >> > >> My personal preference is to reserve 2119/8174 keywords for the text > that is authoritative for the requirement, and to have other text that > refers to that requirement do it descriptively. For example, =E2=80=9CRFC= XXXX > mandates foo=E2=80=9D. > >> > > I guess this is a matter of opinion. > > I think that it's useful to list the rules here using > > 2119 language. I think the text makes clear that in this construction > it's the > > RFC that we are pointing to that's authoritative. > > > > Well, yes, I stated my opinion. To further clarify that opinion: Having a > given MUST/SHOULD/etc in more than one place makes updates error prone. I= f > we update the language in dependency in the future, we may also need to > update this draft. People updating the dependency may not even be aware o= f > this draft. And yes, I realize this concern is highly dependent on the > =E2=80=9Cwhat does it mean to update an RFC=E2=80=9D philosophical discus= sion that never > seems to resolve. > > In any case, it=E2=80=99s not a blocking comment; people are free to igno= re it. > > >> > > >> >> -5.8.3: The MUSTs in this section seem to be putting requirements o= n > the SDP > >> >> being parsed. Shouldn't they instead describe the parser's behavior > based on > >> >> that SDP input? The correctness of the SDP being parsed seems beyon= d > the > >> >> control of the implementation. > >> >> > >> > Yes, the correctness of the SDP is beyond the control of the impl, > but, > >> > the handling of broken SDP is spelled out in the beginning of this > section: > >> > > >> > If any line is not well-formed, or cannot be parsed as > >> > described, the parser MUST stop with an error and reject the > >> > session description, even if the value is to be discarded. > This > >> > ensures that implementations do not accidentally misinterpre= t > >> > ambiguous SDP. > >> > > >> > Saying that a specific line MUST have X and Y is then a shorthand fo= r > >> > repeatedly saying that if the line cannot be parsed properly, the > impl MUST > >> > stop with an error. > >> > >> Again, I don=E2=80=99t think the use of 2119/8174 keywords for things = beyond > the control of the implementation fits the sense of those documents. I > suggest either stating these without 2119/8174 keywords, or adding > something to the boilerplate to the effect of =E2=80=9CWhen used in to de= scribe > requirements for SDP inputs, these terms indicate requirements for that S= DP > to be considered well-formed=E2=80=9D. > >> > > I'm comfortable with the current language=E2=80=A6. > > Again, non-blocking comment=E2=80=A6. > > Ben. > --94eb2c084a94e53f690561d46822 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just for maximum clarity: given that these comments are no= n-blocking, my intent is to leave the document as-is, subject to strong opi= nions by my co-authors.

On Tue, Jan 2, 2018 at 4:29 PM, Ben Campbell = <ben@nostrum.com> wrote:

[=E2=80=A6]

> >
>> >> -5, throughout: There are a number of normative keywords = used in constructions
>> >> like "... MUST foo, as described in RFCXXX". Th= at construction is ambiguous
>> >> about whether it defines a normative requirement to do so= mething, and the doing
>> >> of that something is described in the RFC, or if describe= s the referenced RFC
>> >> as defining the MUST.
>> >>
>> >> In general, it's best to avoid using 2119/8174 keywor= ds to talk about external
>> >> requirements, except as a direct quote. I think this is e= specially true here
>> >> given the interdependencies between drafts in cluster 238= . If in the future we
>> >> update a dependency to change a normative requirement, we= risk creating
>> >> conflicts, and we make it unclear which text is authorita= tive.
>> >>
>> > Generally, this is pointing the reader at a particular normat= ive section,
>> >=C2=A0 =C2=A0 and saying that yeah, you MUST follow that secti= on as written. Perhaps
>> >=C2=A0 =C2=A0 the use of 2119 language here isn't ideal, b= ut I don't see this as
>> >=C2=A0 =C2=A0 confusing. Do you have a suggestion about how th= is should be handled instead?
>>
>> It=E2=80=99s a technicality, but it can create confusion about whi= ch text is authoritative. That=E2=80=99s not an issue as long as both are i= n agreement, but future updates to either this or that spec can easily mess= up that agreement.
>>
>> My personal preference is to reserve 2119/8174 keywords for the te= xt that is authoritative for the requirement, and to have other text that r= efers to that requirement do it descriptively. For example, =E2=80=9CRFC XX= XX mandates foo=E2=80=9D.
>>
> I guess this is a matter of opinion.
> I think that it's useful to list the rules here using
> 2119 language. I think the text makes clear that in this construction = it's the
> RFC that we are pointing to that's authoritative.
>

Well, yes, I stated my opinion. To further clarify that opinion: Hav= ing a given MUST/SHOULD/etc in more than one place makes updates error pron= e. If we update the language in dependency in the future, we may also need = to update this draft. People updating the dependency may not even be aware = of this draft. And yes, I realize this concern is highly dependent on the = =E2=80=9Cwhat does it mean to update an RFC=E2=80=9D philosophical discussi= on that never seems to resolve.

In any case, it=E2=80=99s not a blocking comment; people are free to ignore= it.

>> >
>> >> -5.8.3: The MUSTs in this section seem to be putting requ= irements on the SDP
>> >> being parsed. Shouldn't they instead describe the par= ser's behavior based on
>> >> that SDP input? The correctness of the SDP being parsed s= eems beyond the
>> >> control of the implementation.
>> >>
>> > Yes, the correctness of the SDP is beyond the control of the = impl, but,
>> > the handling of broken SDP is spelled out in the beginning of= this section:
>> >
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If any line is not well-form= ed, or cannot be parsed as
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0described, the parser MUST s= top with an error and reject the
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0session description, even if= the value is to be discarded. This
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ensures that implementations= do not accidentally misinterpret
>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ambiguous SDP.
>> >
>> > Saying that a specific line MUST have X and Y is then a short= hand for
>> > repeatedly saying that if the line cannot be parsed properly,= the impl MUST
>> > stop with an error.
>>
>> Again, I don=E2=80=99t think the use of 2119/8174 keywords for thi= ngs beyond the control of the implementation fits the sense of those docume= nts. I suggest either stating these without 2119/8174 keywords, or adding s= omething to the boilerplate to the effect of =E2=80=9CWhen used in to descr= ibe requirements for SDP inputs, these terms indicate requirements for that= SDP to be considered well-formed=E2=80=9D.
>>
> I'm comfortable with the current language=E2=80=A6.

Again, non-blocking comment=E2=80=A6.

Ben.

--94eb2c084a94e53f690561d46822-- From nobody Wed Jan 3 16:16:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDF6126C2F for ; Wed, 3 Jan 2018 16:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0CwxNNxXALS for ; Wed, 3 Jan 2018 16:16:09 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907E9126BF0 for ; Wed, 3 Jan 2018 16:16:08 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w040G71d071005 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Jan 2018 18:16:08 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: "rtcweb@ietf.org" , draft-ietf-rtcweb-security-arch@tools.ietf.org From: Adam Roach Message-ID: <42423a79-9f63-5eea-1de9-922a997dad9a@nostrum.com> Date: Wed, 3 Jan 2018 18:16:02 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [rtcweb] Reference nits on draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 00:16:11 -0000 [as a participant] I'm combing through references in Cluster 238, and noticed that the following need to be updated in the RTCWEB security architecture document: draft-ietf-avtcore-6222bis has been published as RFC7022 draft-ietf-tsvwg-sctp-dtls-encaps has been published as RFC8261 draft-muthu-behave-consent-freshness has been published as RFC7675 Thanks. /a From nobody Thu Jan 4 05:12:27 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE9F126D45 for ; Thu, 4 Jan 2018 05:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWrjPPR_WYWz for ; Thu, 4 Jan 2018 05:12:24 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226E1126CD6 for ; Thu, 4 Jan 2018 05:12:23 -0800 (PST) X-AuditID: c1b4fb30-d31ff70000006bc7-92-5a4e28361105 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 69.A1.27591.6382E4A5; Thu, 4 Jan 2018 14:12:22 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Thu, 4 Jan 2018 14:12:21 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [MMUSIC] BUNDLE: media-level c= lines in bundle-only m= sections? Thread-Index: AQHThV2nhxfovOF59ESXeedV+yo54A== Date: Thu, 4 Jan 2018 13:12:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.147] Content-Type: multipart/mixed; boundary="_004_D673F6F2284FAchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEIsWRmVeSWpSXmKPExsUyM2K7ja6Zhl+UQet5AYu1/9rZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsXXRNeaCn6YV819PZ2lgXK/XxcjJISFgIjGh9xJrFyMXh5DA YUaJGW3f2SCcxYwSy6b8Y+xi5OBgE7CQ6P6nDdIgIqAucfnhBXYQW1ggQOLulqeMEPFAiaf9 T6BsPYnJL76D2SwCKhI/j7xmBrF5Bawltj/+yQJiMwqISXw/tYYJxGYWEJe49WQ+E8RBIhIP L55mg7BFJV4+/scKYosCzdxw4jY7yDkSAkoS07amQbRGSfx5epEJYrygxMmZT1gmMArNQjJ1 FpKyWUjKIOIJEnN2HWeHsA0k3p+bzwxha0ssW/gaytaX2PjlLCOEbS2xYn0XE6YaXYkj549B zVGUaNvezDYLGIrMAisYJRof/mCFaV50aCULTNGU7ofsCxj5VjGKFqcWJ+WmGxnppRZlJhcX 5+fp5aWWbGIExu7BLb8NdjC+fO54iFGAg1GJh7dc1i9KiDWxrLgy9xCjCtCcRxtWX2CUYsnL z0tVEuH1ee0bJcSbklhZlVqUH19UmpNafIhRmoNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNT qoFxIosj6+Gte2X+3d7z1tmW1/ejvpMxm+5NSTeZHa8brS/lnu5tO7DZK2/KlevuB04FejUr v7y+vuJK3QwxH+fjgWIs6xQy9i+ImXFpl5uCHovH2skXJm0KLW2veH9h5vny/1lXqljeGchM KMy7Uy/Hx83pe+PwDq5Jj+J8nn6f4tn+4ef8KwfclViKMxINtZiLihMBquUCp+UCAAA= Archived-At: Subject: [rtcweb] FW: [MMUSIC] BUNDLE: media-level c= lines in bundle-only m= sections? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 13:12:26 -0000 --_004_D673F6F2284FAchristerholmbergericssoncom_ Content-Type: multipart/alternative; boundary="_000_D673F6F2284FAchristerholmbergericssoncom_" --_000_D673F6F2284FAchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, This also impacts JSEP, which currently specifies that media-level c=3D lin= es are added to ALL bundled m=3D sections =96 including bundle-only ones. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Thursday 4 January 2018 at 15:08 To: "mmusic@ietf.org" > Cc: Ben Campbell > Subject: [MMUSIC] BUNDLE: media-level c=3D lines in bundle-only m=3D sectio= ns? Hi, BUNDLE doesn=92t say much about c=3D lines, the assumption being that there= are no BUNDLE-specific rules related to c=3D lines: one can use a session-= level c=3D line, or media-level c=3D lines, also with BUNDLE. The BUNDLE ad= dress will use whatever IP address is associated (implicitly or explicitly)= with the tagged m=3D section. So far so good. Now, Ekr raised a JSEP GitHub issue regarding media-level c=3D lines in bun= dle-only m=3D sections. As we know, BUNDLE currently specifies that a zero = port value is assigned to bundle-only m=3D sections, but nothing is said ab= out media-level c=3D lines. https://github.com/rtcweb-wg/jsep/issues/843 (The GitHub issue was initially created because of another issue, but if yo= u follow the discussion it will end up in this) My suggestion would be that an offerer/answerer MUST NOT assign media-level= c=3D lines to bundle-only m=3D sections. Would people be ok with this? Does someone suggest something else? Whatever the outcome, I think it would be good to clarify it in BUNDLE. I d= on't think we need to bring the document back to the WG in order to do that= =96 if we can agree on the text I will implement it in a future update (e.= g., based on the IESG reviews) of the draft. Regards, Christer --_000_D673F6F2284FAchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
FYI,

This also impacts JSEP, which currently specifies that media-level c= =3D lines are added to ALL bundled m=3D sections =96 inc= luding bundle-only ones.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Thursday 4 January 2018 at 15= :08
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Cc: Ben Campbell <ben@nostrum.com>
Subject: [MMUSIC] BUNDLE: media-lev= el c=3D lines in bundle-only m=3D sections?

Hi,

BUNDLE doesn=92t say much about c=3D lines, the assumption being that = there are no BUNDLE-specific rules related to c=3D lines: one can use a ses= sion-level c=3D line, or media-level c=3D lines, also with BUNDLE. The BUND= LE address will use whatever IP address is associated (implicitly or explicitly) with the tagged m=3D section.

So far so good.

Now, Ekr raised a JSEP GitHub issue regarding media-level c=3D lines i= n bundle-only m=3D sections. As we know, BUNDLE currently specifies that a = zero port value is assigned to bundle-only m=3D sections, but nothing is sa= id about media-level c=3D lines.


(The GitHub issue was initially created because of another issue, but = if you follow the discussion it will end up in this)

My suggestion would be that an offerer/answerer MUST NOT assign media-= level c=3D lines to bundle-only m=3D sections.

Would people be ok with this? Does someone suggest something else?

Whatever the outcome, I think it would be good to clarify it in BUNDLE= . I don't think we need to bring the document back to the WG in order to do= that =96 if we can agree on the text I will implement it in a future updat= e (e.g., based on the IESG reviews) of the draft.

Regards,

Christer
 


--_000_D673F6F2284FAchristerholmbergericssoncom_-- --_004_D673F6F2284FAchristerholmbergericssoncom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Thu, 04 Jan 2018 13:12:20 GMT"; modification-date="Thu, 04 Jan 2018 13:12:20 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_D673F6F2284FAchristerholmbergericssoncom_-- From nobody Thu Jan 4 10:24:12 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1112D7EC for ; Thu, 4 Jan 2018 10:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeWRY4MYQo84 for ; Thu, 4 Jan 2018 10:24:09 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A74812AF6E for ; Thu, 4 Jan 2018 10:24:09 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id q14so3026932qke.7 for ; Thu, 04 Jan 2018 10:24:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R0Iwml2b8l5gEcWlWERi+S0ZGKtsRCNwXSM7ibqLtq0=; b=cB/V3ZCWw/g/EIh6HCtgUy6YrGKpgPldVfuMHL9rZVshxJTOxdYVTUn8eNweU+ceCp 95x8mvitc5iDi8Kpf7H0EDdYZ55ZlaurpLXSsJEWNMYf2o2dQcEpLBFuQfkzQe/qFDXb uRQFUhmrAalRUWkYjrt3br943voN+WRG/SE1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R0Iwml2b8l5gEcWlWERi+S0ZGKtsRCNwXSM7ibqLtq0=; b=lgygQBHcI8CplKpm6489jQVCz6ixg+xh/JHKd2LA4jqR8He7AIaHOYcD4wkWzGmeAZ yZDqPqwe8628XiVetaghLM5MOfDWVoJDtc5tb9C27CK0q9hFF7UCsxuulu4qkt0h7yBx ydkeXRjrrfTEd+nEhTQCRmwkfaQ5u8Tcn1AVO4ZUDMmu+f/scV18fRqBP3Zbp6wxLrCG r6vDiX0NCuPXIvgGbttsnrlmeKlsXMkir6WRvWTNh90Ag8tNzMPxcRlkE4393h2YzebN e7jYGDmUtlIpRivuRR27XGGl0kWassHmgLS9jSAnlXpym4DDSGAl4YrCx25J1KZKwjDr vISQ== X-Gm-Message-State: AKwxyteIE9d6m8jNHZXKN6ZA5TF1BY6/vNsgGxShQLEpCSa0v1qlA31h mOinPyABIePsTiHj722CjSfPSkAVEVs= X-Google-Smtp-Source: ACJfBoudaHa4NXTRH+gqFXr0gCboaS9RYuZ/QagTpXWvGHVDogJtZncHiUroGRBdnlcUE5VUYRhs+g== X-Received: by 10.55.16.219 with SMTP id 88mr632384qkq.151.1515090248679; Thu, 04 Jan 2018 10:24:08 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id v50sm2464570qta.0.2018.01.04.10.24.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jan 2018 10:24:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <42423a79-9f63-5eea-1de9-922a997dad9a@nostrum.com> Date: Thu, 4 Jan 2018 13:24:07 -0500 Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-security-arch@tools.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4EC9EF25-AB0A-4E70-B34B-F5CCF228B54D@sn3rd.com> References: <42423a79-9f63-5eea-1de9-922a997dad9a@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Reference nits on draft-ietf-rtcweb-security-arch X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:24:11 -0000 PR created: https://github.com/rtcweb-wg/security-arch/pull/51 Note the 7675 was already update in the repo. spt > On Jan 3, 2018, at 19:16, Adam Roach wrote: >=20 > [as a participant] >=20 > I'm combing through references in Cluster 238, and noticed that the = following need to be updated in the RTCWEB security architecture = document: >=20 > draft-ietf-avtcore-6222bis has been published as RFC7022 > draft-ietf-tsvwg-sctp-dtls-encaps has been published as RFC8261 > draft-muthu-behave-consent-freshness has been published as RFC7675 >=20 > Thanks. >=20 > /a >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jan 4 10:46:20 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAC01275C5; Thu, 4 Jan 2018 10:46:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: adam@nostrum.com, rtcweb@ietf.org, fluffy@iii.ca, rtcweb-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151509157893.23706.606882268441113195.idtracker@ietfa.amsl.com> Date: Thu, 04 Jan 2018 10:46:18 -0800 Archived-At: Subject: [rtcweb] rtcweb - Not having a session at IETF 101 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jan 2018 18:46:19 -0000 Cullen Jennings, a chair of the rtcweb working group, indicated that the rtcweb working group does not plan to hold a session at IETF 101. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Mon Jan 8 03:39:14 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196F11273E2 for ; Mon, 8 Jan 2018 03:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJLR7L0lO_ag for ; Mon, 8 Jan 2018 03:39:08 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 717831204DA for ; Mon, 8 Jan 2018 03:39:07 -0800 (PST) X-AuditID: c1b4fb25-859119c00000341b-cf-5a53585a5dfb Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E0.6A.13339.A58535A5; Mon, 8 Jan 2018 12:39:06 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 8 Jan 2018 12:39:05 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: JSEP-24: canTrickleIceCandidiates question Thread-Index: AQHTiHVJfsza7oN7hkaBd7kzQH4cEg== Date: Mon, 8 Jan 2018 11:39:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8999B41A63BC2B46BA15A6007343EDF6@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7qG5URHCUQV+TuMXaf+3sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWH1hKXvBG96KORveszUw3ufqYuTgkBAwkeiaE9nFyMUhJHCY UeLJrkesEM5iRolnPz8xgRSxCVhIdP/T7mLk5BARUJe4/PACO0hYWMBY4tU/LYiwhcSZyz9Z IWw9iR+3ToDZLAIqEtfPnWQEsXkFrCU2TVjBBGIzCohJfD+1BsxmFhCXuPVkPpgtISAgsWTP eWYIW1Ti5eN/YHNEgWZuOHGbHSKuKHF1+nKoXgOJ9+fmM0PY1hJPWrawQNjaEssWvmaG2Cso cXLmE5YJjCKzkKybhaR9FpL2WUjaZyFpX8DIuopRtDi1OCk33chYL7UoM7m4OD9PLy+1ZBMj MB4ObvmtuoPx8hvHQ4wCHIxKPLzHQoOjhFgTy4orcw8xSnAwK4nw/vEBCvGmJFZWpRblxxeV 5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBaBJNl4uCUamDsUl+X05jr6XfpN/8X+X/39v8R fnmsa/d+29cC5uHPs5k0Y7WuVB582B+WteLsba2tN4K1X/9TbhfsPC5lNiW6ryu1r37n0eX/ yteECJ+fyzIvUF0+d/6VZ1tiMhI7Vtuof/pxy+PjLqlpOt/PmDP9qv7KtSB3Qr3MO3vXwDlp Ko1vvBdkblqsxFKckWioxVxUnAgAbwF/0oMCAAA= Archived-At: Subject: [rtcweb] JSEP-24: canTrickleIceCandidiates question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 11:39:12 -0000 Hi, The W3C WebRTC spec says: "The canTrickleIceCandidates attribute indicates whether the remote peer is able to accept trickled ICE candidates [TRICKLE-ICE ]. The value is determined based on whether a remote description indicates support for trickle ICE, as defined in [JSEP ] (section 4.1.15. =20 ). Prior to the completion of setRemoteDescription , =20 this value is null.=B2 JSEP-24 says: "null: No SDP has been received from the other side, so it is not known if it can handle trickle. This is the initial value before setRemoteDescription() is called.=B2 (Basically repeating the W3C text) =8Aand: "However, applications can use the canTrickleIceCandidates property to determine whether their peer can actually do Trickle ICE, i.e., whether it is safe to send an initial offer or answer followed later by candidates as they are gathered. As "true" is the only value that definitively indicates remote Trickle ICE support, an application which compares canTrickleIceCandidates against "true" will by default attempt Half Trickle on initial offers and Full Trickle on subsequent interactions with a Trickle ICE-compatible agent.=B2 QUESTION: Since the value will be NULL before completion of setRemoteDescription (before SDP has been received from the other side) how can the value be used by applications for initial offers? Regards, Christer From nobody Mon Jan 8 04:13:11 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFD412778E for ; Mon, 8 Jan 2018 04:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAdMQZDVYHgg for ; Mon, 8 Jan 2018 04:13:07 -0800 (PST) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14356124BAC for ; Mon, 8 Jan 2018 04:13:06 -0800 (PST) Received: from [192.168.1.146] ([88.151.161.10]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id w08CD6ro017696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 8 Jan 2018 13:13:08 +0100 To: rtcweb@ietf.org References: From: Philipp Hancke Message-ID: <8a4f9180-3de5-3ceb-5dae-156488e72910@goodadvice.pages.de> Date: Mon, 8 Jan 2018 13:13:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [rtcweb] JSEP-24: canTrickleIceCandidiates question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 12:13:10 -0000 [...] > QUESTION: Since the value will be NULL before completion of > setRemoteDescription (before SDP has been received from the other side) > how can the value be used by applications for initial offers? https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/canTrickleIceCandidates shows some of the thinking around this. The code *should* work for the offerer side as well and will create a half-trickle offer. From nobody Mon Jan 8 04:22:09 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CB612778E for ; Mon, 8 Jan 2018 04:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbvYhfpGtWba for ; Mon, 8 Jan 2018 04:22:04 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33241124BAC for ; Mon, 8 Jan 2018 04:22:04 -0800 (PST) X-AuditID: c1b4fb30-d49ff70000006bc7-bf-5a53626a8ae4 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 24.D0.27591.A62635A5; Mon, 8 Jan 2018 13:22:02 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.206]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0352.000; Mon, 8 Jan 2018 13:22:01 +0100 From: Christer Holmberg To: Philipp Hancke , "rtcweb@ietf.org" Thread-Topic: [rtcweb] JSEP-24: canTrickleIceCandidiates question Thread-Index: AQHTiHVJfsza7oN7hkaBd7kzQH4cEqNp0l4AgAAm/wA= Date: Mon, 8 Jan 2018 12:22:01 +0000 Message-ID: References: <8a4f9180-3de5-3ceb-5dae-156488e72910@goodadvice.pages.de> In-Reply-To: <8a4f9180-3de5-3ceb-5dae-156488e72910@goodadvice.pages.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.7.170905 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EE73DB94DF5A24E942F7A96733A1CD1@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7qG5WUnCUwe5+fou3r6cyW6z9187u wORxe+IWFo8lS34yBTBFcdmkpOZklqUW6dslcGW8e3aZsWAJW8XO/Z1MDYwTWbsYOTkkBEwk Xn9rY+5i5OIQEjjMKLFoxiUoZzGjxMUXC1m6GDk42AQsJLr/aYM0iAiESrzuucYOYgsLOEj0 Lmxkh4g7Skw+9ZcRwraSmLXhEhOIzSKgItH4aBMzyBheAWuJvstRIGEhgQqJVxvPsIDYnALu ElcutbOB2IwCYhLfT60Ba2UWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/gd2v6iAnsSGE7fZIeKK Eh9f7WOE6NWRWLD7ExuEbS2x4nYTVFxbYtnC12BzeAUEJU7OfMIygVFsFpJ1s5C0z0LSPgtJ +ywk7QsYWVcxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbVwS2/DXYwvnzueIhRgINRiYc3 JzQ4Sog1say4MvcQowQHs5IIr1A0UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvSU/eKCGB9MSS 1OzU1ILUIpgsEwenVANjo+aPiV5Ztcw5P6Zsm5whZJIszG7x1yvkwlPbykMub8v7/+5aIbiU 62dQ+OONwc2r66xv3NngPnX390WvRZ5/8d/pzLnqxYlsw36OjXujlt1Yu03hw5816es+GW1u XNtxb6atQLf4Qvm7Utsyd11bX+hV66ln1vhqfcmSV/N/BYYExKqd/CGfq8RSnJFoqMVcVJwI AHD+uy2mAgAA Archived-At: Subject: Re: [rtcweb] JSEP-24: canTrickleIceCandidiates question X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 12:22:07 -0000 Hi Philipp, >[...] > >> QUESTION: Since the value will be NULL before completion of >> setRemoteDescription (before SDP has been received from the other side) >> how can the value be used by applications for initial offers? > >https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/canTric >kleIceCandidates >shows some of the thinking around this. Correct. But, the page also covers the case when a remote offer has been received (the application acts as answerer), and setRemoteDescription() is called. > The code *should* work for the offerer side as well and will create a >half-trickle offer. My understanding is that the value will be NULL when the offerer creates the initial offer, as setRemoteDescription() has not yet been called. Regards, Christer From nobody Mon Jan 8 08:29:19 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9712D7EF; Mon, 8 Jan 2018 08:29:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ted Hardie To: X-Test-IDTracker: no X-IETF-IDTracker: 6.68.2 Auto-Submitted: auto-generated Precedence: bulk Cc: Ted Hardie , ted.ietf@gmail.com, iesg-secretary@ietf.org, rtcweb@ietf.org, rtcweb-chairs@ietf.org Message-ID: <151542895702.11265.10110797049761785878.idtracker@ietfa.amsl.com> Date: Mon, 08 Jan 2018 08:29:17 -0800 Archived-At: Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-fec-07 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 16:29:17 -0000 Ted Hardie has requested publication of draft-ietf-rtcweb-fec-07 as Proposed Standard on behalf of the RTCWEB working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/ From nobody Mon Jan 22 18:34:37 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD712D940; Mon, 22 Jan 2018 18:34:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtcweb@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151667487591.29600.4880043729452865026@ietfa.amsl.com> Date: Mon, 22 Jan 2018 18:34:36 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-security-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 02:34:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Real-Time Communication in WEB-browsers WG of the IETF. Title : Security Considerations for WebRTC Author : Eric Rescorla Filename : draft-ietf-rtcweb-security-10.txt Pages : 25 Date : 2018-01-22 Abstract: WebRTC is a protocol suite for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document defines the WebRTC threat model and analyzes the security threats of WebRTC in that model. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-security-10 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-security-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 22 18:35:42 2018 Return-Path: X-Original-To: rtcweb@ietf.org Delivered-To: rtcweb@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4212D882; Mon, 22 Jan 2018 18:35:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner To: X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Cc: iesg-secretary@ietf.org, Sean Turner , rtcweb@ietf.org, sean@sn3rd.com, rtcweb-chairs@ietf.org Message-ID: <151667494173.29702.2978952436604317916.idtracker@ietfa.amsl.com> Date: Mon, 22 Jan 2018 18:35:41 -0800 Archived-At: Subject: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 02:35:42 -0000 Sean Turner has requested publication of draft-ietf-rtcweb-security-10 as Proposed Standard on behalf of the RTCWEB working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ From nobody Mon Jan 22 18:37:14 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C298212D892 for ; Mon, 22 Jan 2018 18:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1J9Ber3am9r for ; Mon, 22 Jan 2018 18:37:11 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC8512D88F for ; Mon, 22 Jan 2018 18:37:08 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id e11so8622218pff.6 for ; Mon, 22 Jan 2018 18:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NVAm7iqlPYFjF1v0LpQ2T4RM3RC4fCu5lYNJmGmfFug=; b=dp7+hMB4EbxJBNNYVCGb5NRm4xUEKIgpVnbWJ1ko5b4pGlyPXzyw01/UGCBsWTiVet KyTrZYCuPJ9JIQI4C6gnqV3vdlBbtNfHqNJ6FuRBovJ1qtw5WUi1YSLMfXykFyn0HrMU cxTTqYQ+/kJjbJyAfff2r5/FeDZ5lVYLrZbaY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NVAm7iqlPYFjF1v0LpQ2T4RM3RC4fCu5lYNJmGmfFug=; b=kLv8xUfNsBbXuPPjv9ZqvqG0+FP/wcp2PIeJp+RnpQ6t/nWjC+w/TiMIypcQ8DmQp5 Ch+q+QDKHUdE06zsqHETR0Ics9eEb4umx5giUrwTLnNKUEtF/A3uEuJxnsZHShd+EGMX p+eBqjxG4Y8q1VCeF13m541Q7gTKzzdmfB+n6zp/YpQf7j9OmJftKn0YzvxGba3tR2ez YJUzilRCmlljf0dmwbAUCm7GhRUXa+5jinX5luV/l/VU2BNG+gO71mw0weW7f3d2pb+h QxR7Hfy/Ve876gHXNbTmh2BZB4//zArdu0lYCpQI5fqDpBMHZ3VgUHfMpLIpw1ngQn9i lOlg== X-Gm-Message-State: AKwxytfBkwgvJeOw5Slm33HdDCSHA/P9TRnB2oWn9NZB73gB7NYxkGLm Ngzyn6H3gBuhJsOF8RZ8OK/6kw== X-Google-Smtp-Source: AH8x224MxHRA5Y+eArlOIbnZ8+5hulP67J+bOtDULdFMZDaXDMCASpKHjIazOdxmsAuGfDQnYh32/w== X-Received: by 2002:a17:902:828c:: with SMTP id y12-v6mr4341187pln.145.1516675028037; Mon, 22 Jan 2018 18:37:08 -0800 (PST) Received: from [5.5.33.23] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id m83sm2314302pfk.107.2018.01.22.18.37.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 18:37:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151667494173.29702.2978952436604317916.idtracker@ietfa.amsl.com> Date: Tue, 23 Jan 2018 13:36:56 +1100 Cc: IESG Secretary , RTCWeb IETF , rtcweb-chairs@ietf.org, Alissa Cooper Content-Transfer-Encoding: quoted-printable Message-Id: References: <151667494173.29702.2978952436604317916.idtracker@ietfa.amsl.com> To: Adam Roach X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 02:37:13 -0000 Adam, You should probably make yourself responsible AD at this point. Note - I=E2=80=99m just pushing it towards you it=E2=80=99s not really = going anyway until the other two show up. spt > On Jan 23, 2018, at 13:35, Sean Turner wrote: >=20 > Sean Turner has requested publication of draft-ietf-rtcweb-security-10 = as Proposed Standard on behalf of the RTCWEB working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >=20 From nobody Mon Jan 22 18:38:04 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE25D12D88F for ; Mon, 22 Jan 2018 18:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0eJIvJHiTTy for ; Mon, 22 Jan 2018 18:37:52 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FBD12D893 for ; Mon, 22 Jan 2018 18:37:36 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id m26so8617828pfj.11 for ; Mon, 22 Jan 2018 18:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KgMVOK5+kXPsGiiekMm8rh6cWdvj7rj9bVErtVvDsBo=; b=iw6q8mvLi+RlT0/j8Me1cX8yZswcdwrCHPW8VIm7758E6hqmfSsHgbMZmwroo8aHwS Kmmt1F0pB13DprM/X2ZKmL85fcicJ8lLuUE9z5Ryta80bwJrLJLyJyO5vXnsw7DVWzNy Mt/I4wYdzerWBXYdtOmWmH/WFyDyIHuXkOYT0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KgMVOK5+kXPsGiiekMm8rh6cWdvj7rj9bVErtVvDsBo=; b=DJU/mjnRj7HZVaCDK49zqUBAjH4s7EK5EzxC5B6CU7I3JKbj7lMNtDtJ/EecJ7HzTC GrvRWzRFPZwPhaNV94yTuD4dnqpiP/Ch34sP0oQDWoqG2Ivh9PWrn/8Q7g4SQUhxF2W+ WWzICkvdUgPNt3klT5ofGackqGFSsGYi/Z5MvJhITMNESOTXDK97jB26cWCYoyoBabmV BqlSV4qIe3feJl7y27FrvNSY7VEUaZ7MlkGSWE7r6Z0ImKdNxeDToXzy3gk5mKknY442 3b2JLQswUfDmMOcrt+O1uMe0O5J2snxWtey95O+gMkbcUgd/7vIqN//QAMs3f01tcFTJ xwiA== X-Gm-Message-State: AKwxytc1VsV7E84OrOdLtcx14I90Z/gIc682Lf3SmMPAIb65cLlh1ZMg X83guek80DSCYnJp0zXCTmtZQA== X-Google-Smtp-Source: AH8x227GwGXylYYQydaQgaWX6G2+iPMsl1ZalhgkqD6uhSVslMsjFOTRqpq5xE1MpktQVUy5JlKl9w== X-Received: by 10.98.112.4 with SMTP id l4mr9262267pfc.8.1516675055586; Mon, 22 Jan 2018 18:37:35 -0800 (PST) Received: from [5.5.33.23] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id m83sm2314302pfk.107.2018.01.22.18.37.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 18:37:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Sean Turner In-Reply-To: <151667487591.29600.4880043729452865026@ietfa.amsl.com> Date: Tue, 23 Jan 2018 13:37:31 +1100 Cc: i-d-announce@ietf.org, rtcweb@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <82C5BA34-F9E5-4E22-8257-2C4CD237012E@sn3rd.com> References: <151667487591.29600.4880043729452865026@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-security-10.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 02:38:03 -0000 This version incorporates some I-D nits noted after WGLC. I=E2=80=99ve = forwarded it to Adam. spt > On Jan 23, 2018, at 13:34, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Real-Time Communication in = WEB-browsers WG of the IETF. >=20 > Title : Security Considerations for WebRTC > Author : Eric Rescorla > Filename : draft-ietf-rtcweb-security-10.txt > Pages : 25 > Date : 2018-01-22 >=20 > Abstract: > WebRTC is a protocol suite for use with real-time applications that > can be deployed in browsers - "real time communication on the Web". > This document defines the WebRTC threat model and analyzes the > security threats of WebRTC in that model. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-rtcweb-security-10 > https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-security-10 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rtcweb-security-10 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Mon Jan 22 18:43:55 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC68812D941; Mon, 22 Jan 2018 18:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnQlYW2LKSCF; Mon, 22 Jan 2018 18:43:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F91112D88F; Mon, 22 Jan 2018 18:43:51 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0N2hk9c037331 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Jan 2018 20:43:47 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Sean Turner Cc: IESG Secretary , RTCWeb IETF , rtcweb-chairs@ietf.org, Alissa Cooper References: <151667494173.29702.2978952436604317916.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Mon, 22 Jan 2018 20:43:41 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Publication has been requested for draft-ietf-rtcweb-security-10 X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 02:43:54 -0000 Sweet! Thanks. The secretariat was supposed to do a bulk reassignment of Alissa's documents to me back in March. I guess this one got missed. /a On 1/22/18 8:36 PM, Sean Turner wrote: > Adam, > > You should probably make yourself responsible AD at this point. > > Note - I’m just pushing it towards you it’s not really going anyway until the other two show up. > > spt > >> On Jan 23, 2018, at 13:35, Sean Turner wrote: >> >> Sean Turner has requested publication of draft-ietf-rtcweb-security-10 as Proposed Standard on behalf of the RTCWEB working group. >> >> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/ >> From nobody Wed Jan 24 03:28:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03A112DA29 for ; Wed, 24 Jan 2018 03:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKME3-vqzQy6 for ; Wed, 24 Jan 2018 03:28:11 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B01112DA27 for ; Wed, 24 Jan 2018 03:28:06 -0800 (PST) Received: (qmail 30499 invoked from network); 24 Jan 2018 11:28:04 -0000 X-APM-Authkey: 255286/0(159927/0) 679 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 24 Jan 2018 11:28:04 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 9751C18A04B3; Wed, 24 Jan 2018 11:28:04 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DkWt6Cdyh6Cv; Wed, 24 Jan 2018 11:28:04 +0000 (GMT) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7286C18A0493; Wed, 24 Jan 2018 11:28:04 +0000 (GMT) From: T H Panton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> Date: Wed, 24 Jan 2018 11:28:03 +0000 Cc: dispatch@ietf.org To: RTCWeb IETF X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [rtcweb] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 11:28:13 -0000 There has been talk over on the w3c list about the scarcity and = unsuitability of free-standing WebRTC datachannel implementations. I wonder if this is a suitable target for the IETF 101 hackathon?=20 The challenge would be to throw up one or 2 free standing datachannel = implementations based on existing open source with APIs that might suit authors of networked games or SFUs. Comments? Thoughts? T. From nobody Wed Jan 24 07:23:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2BC126C22 for ; Wed, 24 Jan 2018 07:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obkytz8sooht for ; Wed, 24 Jan 2018 07:23:56 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A18F5126C0F for ; Wed, 24 Jan 2018 07:23:56 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id 141so9270265wme.3 for ; Wed, 24 Jan 2018 07:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tqztPJviPH5PPwh8SnUYcN6Vz9/S7kY8/jJeSwBGWCo=; b=EQB7O/+RmkuFk3YeYwZqVxLLXr9HLexqX3G9oEzY7dRoeHHuQj+i97ZQ1ralWTm4qF 872VAQfmy1COvQ6oBvSYPCV+Z8fgrPqntJZokmI3iWgSPgX7B7OmRIGpVsmuwQmRG1Xv Z48le1tVFqoYmPIW/KscTa8rRsz7sdnLMUydUeb88dIEYnmo+bioVD2EZ/qt9n2VtMfo 28cdy2D/RpNmlZ2rHezDmwjM3nov8Bk4NfpN63aYVK8mcdjHNjUaReAMXCbqfZqo0g/W ZFSac6fk3Sz1M4QEEbB2lauQKjN0PV/L3XlRLDeerIch7wFRmnj8gHyy58o9kTpiUsyE uAWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tqztPJviPH5PPwh8SnUYcN6Vz9/S7kY8/jJeSwBGWCo=; b=HgRkNYjcEZ1o1dWkuQFtC41SAlMdt/3Pdr9ENKzdFNnASEJdR2PXxEw177ZL+kfc70 QAKWw3jFVQ+DkiWa53i1gOQilX67QQXSIpaWK02CX2SIqjb1KqoPzANHSYDS4ixWySyk oqxTOQWTRIAn5aOs2kZ4WQeU1WFYk0WizBCPyQ+auaMOAamaYjKVfcBtg+MhU95TjhER //u4lEnMRsQJJSAZ3Sj2Qvthh6Z9K2xBrV191js6no2QoxulIKXD/wc900zPvplVgncT ZdBtjZ6xwzl/SakoPZY8GsCf7uamMPFaliZ+LRTtAjopu9V57FegphDgQlr1opvXANXj zhKg== X-Gm-Message-State: AKwxyte2i1IjvtdI13may1u9cDuemZ0c5FoP+si3lc+eQix4eFNU6GOY ZCHIZYf1I9MSV9LA0iSz3mdElxmje6l1dXa6PITvbi9r X-Google-Smtp-Source: AH8x225aKhTKfHJ0ZKNfKJuwNOQgPEf4aNCvPFLActeexMXUi4G6u6KdH3Shu9+izESpIwCa3kRVWML4+MWOAADkvP0= X-Received: by 10.28.118.15 with SMTP id r15mr5701465wmc.88.1516807434967; Wed, 24 Jan 2018 07:23:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.20.66 with HTTP; Wed, 24 Jan 2018 07:23:54 -0800 (PST) In-Reply-To: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> From: Richard Barnes Date: Wed, 24 Jan 2018 10:23:54 -0500 Message-ID: To: T H Panton Cc: RTCWeb IETF , DISPATCH Content-Type: multipart/alternative; boundary="089e082f274c5ac92e0563874039" Archived-At: Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 15:23:59 -0000 --089e082f274c5ac92e0563874039 Content-Type: text/plain; charset="UTF-8" Seems worthwhile to me, if you can find some people to do it. On Wed, Jan 24, 2018 at 6:28 AM, T H Panton wrote: > There has been talk over on the w3c list about the scarcity and > unsuitability of free-standing WebRTC datachannel implementations. > > I wonder if this is a suitable target for the IETF 101 hackathon? > > The challenge would be to throw up one or 2 free standing datachannel > implementations based on existing open > source with APIs that might suit authors of networked games or SFUs. > > Comments? Thoughts? > > T. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e082f274c5ac92e0563874039 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Seems worthwhile to me, if you can find some people to do = it.

On W= ed, Jan 24, 2018 at 6:28 AM, T H Panton <thp@westhawk.co.uk> wrote:
There has been talk over on the = w3c list about the scarcity and unsuitability of free-standing WebRTC datac= hannel implementations.

I wonder if this is a suitable target for the IETF 101 hackathon?

The challenge would be to throw up one or 2 free standing datachannel imple= mentations based on existing open
source with APIs that might suit authors of networked games or SFUs.

Comments? Thoughts?

T.

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e082f274c5ac92e0563874039-- From nobody Wed Jan 24 07:28:59 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83623126C26; Wed, 24 Jan 2018 07:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m57EmtLXGGgr; Wed, 24 Jan 2018 07:28:51 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FA3126C0F; Wed, 24 Jan 2018 07:28:50 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id b21so9358765wme.4; Wed, 24 Jan 2018 07:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=uIW05NAFxm6eD0Ts2fANQ5NvFVCJBI76KsFmuhUa6C8=; b=mVuHPAH6f+SriJrPhUDH0+tms6ocfqM8gc5dLWA8dfpsqnWq2D5jnb6m6BJFjayetC Om29DxtS7acIOXXdnnRQKaPCfC6NbSidvsE3CGwjVlCUds7tP/Z29tH4DItqxgUkBc1o eR+ipE5MNAb/6S/s5CV5znyH1qDR2DJBIy5NMAM0t4jTOG8A+dq9Wkdz8HpXTbFSURhT rPTxoslzjPH12kJD5DhCnS8iR+r/z6ojJOdCzIPVpfrgzwEwXs6677ejPviECwylGscg Sbi11Ij0t1o9/IWlNr2rMRm1+X8JZFDjH+uwCuYhdjexASJafIB5fYUBiSX+ctiIU+Xg bVcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=uIW05NAFxm6eD0Ts2fANQ5NvFVCJBI76KsFmuhUa6C8=; b=WXi0wPWgZQlGbXrDQ5HngHxSJOQIdpzyz8V0b6QHXo6TIx+C4lOXSGj2C5Tws29xS1 48UIrYohTn73iZ4KZEk3qb8Sj0QKAESmdkMD1yDK0XUm11y+6dbOcUlLDPNkY6JcBxMT 4fFPBXvdHnLV68OfgYKAWpcq9u/hsPy0syQdt696EWJxew0/QUhSlDrE6aKPJGbyxWrZ XP4UqSmMRMZKapAn+tVpMfU8kUlbqaummj5TGiJ0rDgrfFE2RxISFPmQHjgDV/EBQzjJ cCUKJdUZztEi2GG/P7H42BUxYl8eE3qL/f/QPuNPx756p1SLXSKwDkBA0K+52drQSe93 vVWQ== X-Gm-Message-State: AKwxytf6vNZoNpUXO+lIQwhfT41IYXk4R13tQweYT4TTbpqgOhnD5GmH p1wua7mrARUdcuzhM/vxMUQgFN0k X-Google-Smtp-Source: AH8x226UfAFIeZYb9DIVLyME7KDTwmt47wv8BYG79O+aVBdFeQWbnOEAnCL75qcDYn1CnCD7qqCv6Q== X-Received: by 10.80.145.79 with SMTP id f15mr25296226eda.283.1516807728695; Wed, 24 Jan 2018 07:28:48 -0800 (PST) Received: from [192.168.1.48] (37.red-80-28-109.staticip.rima-tde.net. [80.28.109.37]) by smtp.googlemail.com with ESMTPSA id r15sm352900edi.23.2018.01.24.07.28.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 07:28:47 -0800 (PST) To: T H Panton , RTCWeb IETF Cc: dispatch@ietf.org References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> From: Sergio Garcia Murillo Message-ID: <30e70fe8-abee-44da-59ec-bdd3ec82dde4@gmail.com> Date: Wed, 24 Jan 2018 16:28:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 15:28:54 -0000 I will not be attending this IETF meeting physically, but I would be interested in collaborating (either helping to implement the datachannel libraries or integrating them on my media server for testing) Best regards Sergio On 24/01/2018 12:28, T H Panton wrote: > There has been talk over on the w3c list about the scarcity and unsuitability of free-standing WebRTC datachannel implementations. > > I wonder if this is a suitable target for the IETF 101 hackathon? > > The challenge would be to throw up one or 2 free standing datachannel implementations based on existing open > source with APIs that might suit authors of networked games or SFUs. > > Comments? Thoughts? > > T. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 25 09:46:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E689A127010; Thu, 25 Jan 2018 09:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aApH7W8KJ7bo; Thu, 25 Jan 2018 09:46:44 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190FB124D68; Thu, 25 Jan 2018 09:46:44 -0800 (PST) Received: from [IPv6:2a02:c6a0:4015:12:4da4:4a7d:8bb3:d066] (unknown [IPv6:2a02:c6a0:4015:12:4da4:4a7d:8bb3:d066]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 5DFE3721E280C; Thu, 25 Jan 2018 18:46:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> Date: Thu, 25 Jan 2018 18:46:39 +0100 Cc: RTCWeb IETF , dispatch@ietf.org, Felix Weinrank Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> To: T H Panton X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 17:46:47 -0000 > On 24. Jan 2018, at 12:28, T H Panton wrote: >=20 > There has been talk over on the w3c list about the scarcity and = unsuitability of free-standing WebRTC datachannel implementations. >=20 > I wonder if this is a suitable target for the IETF 101 hackathon?=20 >=20 > The challenge would be to throw up one or 2 free standing datachannel = implementations based on existing open > source with APIs that might suit authors of networked games or SFUs. >=20 > Comments? Thoughts? We are participating and could use the Firefox WebRTC implementation. We = would be able to debug SCTP issues and possibly some issues in the WebRTC implementation = of Firefox. Best regards Michael >=20 > T. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Thu Jan 25 10:14:48 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8235D1270B4; Thu, 25 Jan 2018 10:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKXQfN0Rqr_K; Thu, 25 Jan 2018 10:14:44 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D39D126D0C; Thu, 25 Jan 2018 10:14:44 -0800 (PST) X-AuditID: c1b4fb3a-335ff700000037f2-59-5a6a1e92dc94 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.1F.14322.29E1A6A5; Thu, 25 Jan 2018 19:14:42 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0352.000; Thu, 25 Jan 2018 19:14:41 +0100 From: Christer Holmberg To: Michael Tuexen , T H Panton CC: Felix Weinrank , "dispatch@ietf.org" , RTCWeb IETF Thread-Topic: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? Thread-Index: AQHTlgR7q7S26JKvSkKDGt0Xw0pNE6OE47Vw Date: Thu, 25 Jan 2018 18:14:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se> References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7ve4kuawog1nvlCyWTlrAanGxaQmj xdp/7ewW694fY7GY2rqC3YHVo2fKaVaPJUt+MnlsaNnB5HFx2n6mAJYoLpuU1JzMstQifbsE roxLTy6yFlzjrZi/qYGpgXEZdxcjJ4eEgInE+m0TWboYuTiEBA4zSpxraGCGcJYwSmx8Px3I 4eBgE7CQ6P6nDdIgIhAhseNhMyNImFmgTOLScheQsLCAi8Te9Y9YIUpcJZ79XsgOYRtJvJ18 GMxmEVCVuHR+A5jNK+Ar8b9tIhOILSRQIzH/WzsjiM0J1Hv00AI2EJtRQEzi+6k1YDXMAuIS t57MZ4K4WUBiyZ7zzBC2qMTLx/9YIWwliRXbLzFC1OtILNj9iQ3C1pZYtvA1M8ReQYmTM5+w TGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hxanFxbrqRkV5qUWZycXF+nl5easkmRmBcHdzy22oH 48HnjocYBTgYlXh4pR9nRgmxJpYVV+YeYpTgYFYS4d0plhUlxJuSWFmVWpQfX1Sak1p8iFGa g0VJnNcpzSJKSCA9sSQ1OzW1ILUIJsvEwSnVwBjYw2e/wnTRn40T90jee2DEw7qg1WOeYHOm +o6QKM7n7kficx5p/Hfi4Su+tXyd7qvU9ldGb4yPHs44sq7q2KOaVq8zajaZb/k2SP1JWnLf 6GLK9KBFYe5Bfp4FPF+ezPz48anT7xj3a3EaB01EDl3fv7JDKTjG9nLlCeVS7v3VQfOqVI2/ n1ZiKc5INNRiLipOBAB/BIYgpwIAAA== Archived-At: Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 18:14:46 -0000 Hi, If the purpose is to test different data channel stacks (in addition to jus= t establishing the SCTP-over-DTLS association), I assume there needs to be = some applications that use the data channels? It would be nice to have webpage where people could add links to their appl= ications using data channels, so that people can then click :) Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Michael Tuex= en Sent: 25 January 2018 19:47 To: T H Panton Cc: Felix Weinrank ; dispatch@ietf.org; RTCWeb IET= F Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? > On 24. Jan 2018, at 12:28, T H Panton wrote: >=20 > There has been talk over on the w3c list about the scarcity and unsuitabi= lity of free-standing WebRTC datachannel implementations. >=20 > I wonder if this is a suitable target for the IETF 101 hackathon?=20 >=20 > The challenge would be to throw up one or 2 free standing datachannel=20 > implementations based on existing open source with APIs that might suit a= uthors of networked games or SFUs. >=20 > Comments? Thoughts? We are participating and could use the Firefox WebRTC implementation. We wo= uld be able to debug SCTP issues and possibly some issues in the WebRTC imp= lementation of Firefox. Best regards Michael >=20 > T. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 25 12:27:34 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EECA12EAA4; Thu, 25 Jan 2018 12:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh9mOiDZFgXn; Thu, 25 Jan 2018 12:27:27 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FE812EA9F; Thu, 25 Jan 2018 12:27:27 -0800 (PST) Received: from [IPv6:2003:cd:6bf1:8000:4db0:9cb0:d29e:37e] (p200300CD6BF180004DB09CB0D29E037E.dip0.t-ipconnect.de [IPv6:2003:cd:6bf1:8000:4db0:9cb0:d29e:37e]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 959B8721E280C; Thu, 25 Jan 2018 21:27:24 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Michael Tuexen In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se> Date: Thu, 25 Jan 2018 21:27:05 +0100 Cc: T H Panton , Felix Weinrank , "dispatch@ietf.org" , RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 20:27:29 -0000 > On 25. Jan 2018, at 19:14, Christer Holmberg = wrote: >=20 > Hi, >=20 > If the purpose is to test different data channel stacks (in addition = to just establishing the SCTP-over-DTLS association), I assume there = needs to be some applications that use the data channels? >=20 > It would be nice to have webpage where people could add links to their = applications using data channels, so that people can then click :) Some examples can be found at: https://github.com/nplab/WebRTC-Data-Channel-Playground Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Michael = Tuexen > Sent: 25 January 2018 19:47 > To: T H Panton > Cc: Felix Weinrank ; dispatch@ietf.org; = RTCWeb IETF > Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? >=20 >> On 24. Jan 2018, at 12:28, T H Panton wrote: >>=20 >> There has been talk over on the w3c list about the scarcity and = unsuitability of free-standing WebRTC datachannel implementations. >>=20 >> I wonder if this is a suitable target for the IETF 101 hackathon?=20 >>=20 >> The challenge would be to throw up one or 2 free standing datachannel=20= >> implementations based on existing open source with APIs that might = suit authors of networked games or SFUs. >>=20 >> Comments? Thoughts? > We are participating and could use the Firefox WebRTC implementation. = We would be able to debug SCTP issues and possibly some issues in the = WebRTC implementation of Firefox. >=20 > Best regards > Michael >>=20 >> T. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 25 13:22:34 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6289212946D; Thu, 25 Jan 2018 13:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6LfmxN0FinF; Thu, 25 Jan 2018 13:22:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6E012EABC; Thu, 25 Jan 2018 13:22:25 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-18-5a6a4a8f3918 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 59.04.14322.F8A4A6A5; Thu, 25 Jan 2018 22:22:24 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0352.000; Thu, 25 Jan 2018 22:22:23 +0100 From: Christer Holmberg To: Michael Tuexen CC: T H Panton , Felix Weinrank , "dispatch@ietf.org" , RTCWeb IETF Thread-Topic: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? Thread-Index: AQHTlgR7q7S26JKvSkKDGt0Xw0pNE6OE47VwgAAVOYCAAB+c0A== Date: Thu, 25 Jan 2018 21:22:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6C13FAB1@ESESSMB109.ericsson.se> References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUyM2K7t+4Er6wog89L2C2WTlrAanGxaQmj xdp/7ewW694fY7GY2rqC3YHVo2fKaVaPJUt+MnlsaNnB5HFx2n6mAJYoLpuU1JzMstQifbsE rozZfd+ZChaLVMw49Z25gfGNQBcjJ4eEgInE6nWzmbsYuTiEBA4zSlxuOsEIkhASWMIo8XtW chcjBwebgIVE9z9tkLCIgKnEweXzWEDqmQWmM0qcWfKcCSQhLOAisXf9I1aIIleJZ78XskPY ThKfzi4Gs1kEVCVONExgA5nJK+ArsfhsKMTe34wSnxq+sIHUcAL1rn7ZAHYDo4CYxPdTa8Dm MwuIS9x6Mp8J4mgBiSV7zjND2KISLx//Y4WwlSRWbL/ECFGvI7Fg9yc2CFtbYtnC12D1vAKC EidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypG0eLU4uLcdCMjvdSizOTi4vw8vbzUkk2MwMg6 uOW31Q7Gg88dDzEKcDAq8fBeM8qKEmJNLCuuzD3EKMHBrCTCK6gLFOJNSaysSi3Kjy8qzUkt PsQozcGiJM7rlGYRJSSQnliSmp2aWpBaBJNl4uCUamCc+7xk46alHDt1d59+vDhw4e78tbwW vGp89beWJx3+9TrD288inONfmM7OsyvFn2vNOn48OmTP5v0s615lrns9yaiIi+llxLQD28St 3N5w/WSbbGYgylEjm7fT96NZe8Di+wFBS5MeTlbKX8xi62is3ftASMxj4wau1bdu3ntau+SH 8vGwpyyCSizFGYmGWsxFxYkATNjcbqgCAAA= Archived-At: Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 21:22:33 -0000 Thanks! It would also be interesting to see some cool killer apps (other than file = transfers) using data channels :) Regards, Christer -----Original Message----- From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 Sent: 25 January 2018 22:27 To: Christer Holmberg Cc: T H Panton ; Felix Weinrank ; dispatch@ietf.org; RTCWeb IETF Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? > On 25. Jan 2018, at 19:14, Christer Holmberg wrote: >=20 > Hi, >=20 > If the purpose is to test different data channel stacks (in addition to j= ust establishing the SCTP-over-DTLS association), I assume there needs to b= e some applications that use the data channels? >=20 > It would be nice to have webpage where people could add links to their=20 > applications using data channels, so that people can then click :) Some examples can be found at: https://github.com/nplab/WebRTC-Data-Channel-Playground Best regards Michael >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Michael=20 > Tuexen > Sent: 25 January 2018 19:47 > To: T H Panton > Cc: Felix Weinrank ; dispatch@ietf.org;=20 > RTCWeb IETF > Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? >=20 >> On 24. Jan 2018, at 12:28, T H Panton wrote: >>=20 >> There has been talk over on the w3c list about the scarcity and unsuitab= ility of free-standing WebRTC datachannel implementations. >>=20 >> I wonder if this is a suitable target for the IETF 101 hackathon?=20 >>=20 >> The challenge would be to throw up one or 2 free standing datachannel=20 >> implementations based on existing open source with APIs that might suit = authors of networked games or SFUs. >>=20 >> Comments? Thoughts? > We are participating and could use the Firefox WebRTC implementation. We = would be able to debug SCTP issues and possibly some issues in the WebRTC i= mplementation of Firefox. >=20 > Best regards > Michael >>=20 >> T. >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Jan 25 14:29:53 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B3C12EACF for ; Thu, 25 Jan 2018 14:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo1wXV6CG3CI for ; Thu, 25 Jan 2018 14:29:45 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72CA12EADC for ; Thu, 25 Jan 2018 14:29:30 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id g16so5984749pgn.7 for ; Thu, 25 Jan 2018 14:29:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=RVVK1hRSaCILlMzG//20Ia6jRnKeQCxJ8gZKwshLHdg=; b=WYXas088cxUrvs4JPrDcrkNmjd+NHcK1VC7ukv7QqRxnBbQ9TiLu6yAl78LFRK7tDm 6JWhpFdQpm+MkI435uRoR5ISTeZGETFDjppViu0lnWYD35FH2ABAv9uSBO/kfbAIjnct SMgZS3TELYP0f9ylJ5ju/ST8NXWAZqXCI+G1o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=RVVK1hRSaCILlMzG//20Ia6jRnKeQCxJ8gZKwshLHdg=; b=BGDQZNkwl6ZByOy5yj1UrNwidEho7EMIv4bDWrII942/bw857LLTasAiQeVTrKfcxm 6GcJD7mO3/4Sj2CbvLlWWI0QJYO8nXMpxm8ihDJ2Vg4D32VHFXmtLX2SAId/Jw7ZYR3t I7QtXJ53UQ5YYh+kD/ej8mP8W5YqlWWkBF8TML9a3YEOPsyvUSjgJ13SEzmnlcmjYhiG OktgfIdkR0tbKhSUJbk5MwqrbFhbBDENR0l2dGtNvX5aMKogMl0sxcWYpn2inF5XP3ge byv5teQEZyMkc7YX0Mhamp77gOPYufuwdSEFhLGFoZzCdXf1w6qPTX6dvYoLMNxFIM9z /HgA== X-Gm-Message-State: AKwxyte2XS6mMuGiG8zVM8ijD2Ahuga3YphUubNo6gXA75OT2wzwddE7 64mOsqrTKm4WF+s8+hf14q0fGw== X-Google-Smtp-Source: AH8x224SfF+TYZtcOkf0sSVtTP1a6Ks6OjdJTXVK1B+mzEH9Q8BjazGz1q5OylhWCRTzUdhO6RSH2w== X-Received: by 10.99.150.25 with SMTP id c25mr11572556pge.136.1516919370027; Thu, 25 Jan 2018 14:29:30 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:f9a6:ac1f:1113:381d? ([2601:647:4600:3f31:f9a6:ac1f:1113:381d]) by smtp.gmail.com with ESMTPSA id f78sm15718374pfk.144.2018.01.25.14.29.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 14:29:28 -0800 (PST) From: Nils Ohlmeier Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_83CA49CC-27E2-4B01-B8FB-940C94F36D9E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 25 Jan 2018 14:29:26 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6C13FAB1@ESESSMB109.ericsson.se> Cc: Michael Tuexen , Felix Weinrank , "dispatch@ietf.org" , RTCWeb IETF To: Christer Holmberg References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6C13FAB1@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ? X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 22:29:48 -0000 --Apple-Mail=_83CA49CC-27E2-4B01-B8FB-940C94F36D9E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christer, While I totally agree that it would be awesome to find killer apps for = data channels I don=E2=80=99t think an IETF Hackathon is a) the place to = find new killer aps and b) creating something at an IETF Hackathon = requires an app idea to exist already. It was my understanding that Mr. Panton was proposing to solve the = chicken and egg problem of people complaining that creating data channel = apps (outside of browsers) is too complicated by hacking together an = easily integratabtle data channel lib. I would totally be up to = participate in that. Once we have such a lib we and other then can start playing around and = maybe until the next IETF we will have =E2=80=9Csome cool killer = apps=E2=80=9D. Best Nils Ohlmeier > On Jan 25, 2018, at 13:22, Christer Holmberg = wrote: >=20 > Thanks! >=20 > It would also be interesting to see some cool killer apps (other than = file transfers) using data channels :) >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > Sent: 25 January 2018 22:27 > To: Christer Holmberg > Cc: T H Panton ; Felix Weinrank = ; dispatch@ietf.org; RTCWeb IETF = > Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? >=20 >> On 25. Jan 2018, at 19:14, Christer Holmberg = wrote: >>=20 >> Hi, >>=20 >> If the purpose is to test different data channel stacks (in addition = to just establishing the SCTP-over-DTLS association), I assume there = needs to be some applications that use the data channels? >>=20 >> It would be nice to have webpage where people could add links to = their >> applications using data channels, so that people can then click :) > Some examples can be found at: > https://github.com/nplab/WebRTC-Data-Channel-Playground >=20 > Best regards > Michael >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = Michael >> Tuexen >> Sent: 25 January 2018 19:47 >> To: T H Panton >> Cc: Felix Weinrank ; dispatch@ietf.org; >> RTCWeb IETF >> Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ? >>=20 >>> On 24. Jan 2018, at 12:28, T H Panton wrote: >>>=20 >>> There has been talk over on the w3c list about the scarcity and = unsuitability of free-standing WebRTC datachannel implementations. >>>=20 >>> I wonder if this is a suitable target for the IETF 101 hackathon? >>>=20 >>> The challenge would be to throw up one or 2 free standing = datachannel >>> implementations based on existing open source with APIs that might = suit authors of networked games or SFUs. >>>=20 >>> Comments? Thoughts? >> We are participating and could use the Firefox WebRTC implementation. = We would be able to debug SCTP issues and possibly some issues in the = WebRTC implementation of Firefox. >>=20 >> Best regards >> Michael >>>=20 >>> T. >>>=20 >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_83CA49CC-27E2-4B01-B8FB-940C94F36D9E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlpqWkYACgkQY2o/VmzJ +KFlpQ//VTOX3SH2trAjB3wgitKkCU5pmXOko7lOfNMV18T79gKDpSJtKmkDTsYn gxqNAfuActu2DlgL1RlheizOHmGkhrcnrLzYZb0xd2eoJ2Q4SnfH8ugwSCVcrcXl 6SZgfaoCMtrptXWaENbabx/VT+OPuvRCxI2cXwz1alD4gYw9myl8hBBBnyl/kV+r LvDm7x/eI7CqhKAFsBcpLHzl4EDTdW6S7VC0d36V6Qm+v5URQEDtblOuQ/h4/U4b cGCd1x3NLoLLP24NR1pdI3OSc0vWZ9QvJ+I3GF4vv62hue8RYLUJJOTaBVSxTSB8 CSQY4PjIKQUcfJTDJFDZ8d8aCtOZ2ppGax8v1l9Y9a036uTnKbY1huviqSvbiu1F sjCTp2w/lwXRSi3j7qZ06SUnbet10fPCyeGrV/5XRLv1gA/8Jc6sGr6rvoSDMiwL re7tbpIX9OuXvTlOn4fsGbbfgmk0xa/i/yfNpR0W9VsInxdLXy1za9P8aDl+pnQ5 +M0LBJe/pe+miYr2nnF8wJIpIHTmjqSJMhW5a2h0/WmaByqPf9dyKUVvSibRDTr+ k6bsY0YDRBxT/6vvHgx/YHZx+7RICyQ4SiwSg+7Uh0tuLT7bST3vYeGZcC/o0x50 KPD+mi3ZmMjPmr1t5lrCo+v5X8i7UhrPi0jrci/p/lr95+CG8A0= =2dNW -----END PGP SIGNATURE----- --Apple-Mail=_83CA49CC-27E2-4B01-B8FB-940C94F36D9E-- From nobody Tue Jan 30 06:04:58 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD22313186C; Tue, 30 Jan 2018 06:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-t1r_dwMaf5; Tue, 30 Jan 2018 06:04:54 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E829112EB31; Tue, 30 Jan 2018 06:03:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4E98D7C37BA; Tue, 30 Jan 2018 15:03:25 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zMV0q3MJYFN; Tue, 30 Jan 2018 15:02:33 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::f95] (unknown [IPv6:2001:470:de0a:1::f95]) by mork.alvestrand.no (Postfix) with ESMTPSA id 410F27C3237; Tue, 30 Jan 2018 14:59:23 +0100 (CET) To: T H Panton , RTCWeb IETF Cc: dispatch@ietf.org References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> From: Harald Alvestrand Message-ID: Date: Tue, 30 Jan 2018 14:59:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [rtcweb] Identity? (Re: [dispatch] Datachannel Hackathon at IETF 101 ?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 14:04:57 -0000 Speaking of features that have received little love from deployment .... would anyone be interested in hacking on the identity API? It seems to have received little love from implementors so far, but there's been strong pushback against removing it too. We need either it or something like it to satisfy the security requirements we set out to satisfy. Harald On 01/24/2018 12:28 PM, T H Panton wrote: > There has been talk over on the w3c list about the scarcity and unsuitability of free-standing WebRTC datachannel implementations. > > I wonder if this is a suitable target for the IETF 101 hackathon? > > The challenge would be to throw up one or 2 free standing datachannel implementations based on existing open > source with APIs that might suit authors of networked games or SFUs. > > Comments? Thoughts? > > T. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Surveillance is pervasive. Go Dark. From nobody Tue Jan 30 15:37:18 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5483127023 for ; Tue, 30 Jan 2018 15:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSI8ivppyqkc for ; Tue, 30 Jan 2018 15:37:14 -0800 (PST) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2121F12E86D for ; Tue, 30 Jan 2018 15:37:13 -0800 (PST) Received: by mail-pf0-x243.google.com with SMTP id i66so10661770pfd.7 for ; Tue, 30 Jan 2018 15:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mWBW0kGp3iXTj3guATZgQwqHT+GATsfbkwG4TvXDEd8=; b=JXwIPxTLvEhn7ZvHw+WpUWD4JvlGvycHX8g0ZmPngN1pGk3cYohilvTvalBUR/i2EW M0l0zfv9PoduGHurh3AjwG8gaEA9uz/LNk9+KWMWU+ekIXJjdszIIfbYgNLaSR2weo+P heXV1UxADaA4mrRPlGFHHOuKyr/xZcIeEKrTU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mWBW0kGp3iXTj3guATZgQwqHT+GATsfbkwG4TvXDEd8=; b=mXKVc15gWFwlU4W7ePsCXM/tYZWyedgv6vGkcMcPtDe2H/0MJsYtF+TpnHqEKss/AD MecmfcItrnNmYqSbx8ifY2JW7MWO5okyMQA6hclAbWhPeo6VjgiFGWHYtOl9u6KaNPIn hmCOmG8dMuInqwBYfSBdFqtjO1GYojarT30RBsh4mwZk2n1LWplbuAgdylQMK/I1m/dD icmKk9M9klq7MldRLHsE4Dy5T6+oAeVlnyq2B7TSlA2MRfosYS64/FOhPVeGsZg/DYSW u5Mo7MHv9eG50iD3sU7hl4TEhg4b2r4gWpui/CaunSyumfV5GeUFo3rrTgaduOKJzqqx EbIg== X-Gm-Message-State: AKwxytdrKH1YUdQJ58+4j+9le1mB0hw7aB8A7Y0rPvinJAla8FmJOcr9 5SLoOHomiETOP+ZbKEYSfVQsKQ== X-Google-Smtp-Source: AH8x225OqPftHKsEee6s/CjL/q1/rch02Vf/EdJ/AjaGs1JUwBRZu2OKJF1cdp7SwU408tXTLae3eg== X-Received: by 10.98.130.142 with SMTP id w136mr29352109pfd.236.1517355433413; Tue, 30 Jan 2018 15:37:13 -0800 (PST) Received: from ?IPv6:2620:101:80fc:224:34cb:53c7:da30:1ac7? ([2620:101:80fc:224:34cb:53c7:da30:1ac7]) by smtp.gmail.com with ESMTPSA id j13sm35602890pfk.112.2018.01.30.15.37.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 15:37:12 -0800 (PST) From: Nils Ohlmeier Message-Id: <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2F403906-8AD4-413B-A4CB-3D3661E1413C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Tue, 30 Jan 2018 15:37:06 -0800 In-Reply-To: Cc: T H Panton , RTCWeb IETF , dispatch@ietf.org To: Harald Alvestrand References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [rtcweb] Identity? (Re: [dispatch] Datachannel Hackathon at IETF 101 ?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 23:37:17 -0000 --Apple-Mail=_2F403906-8AD4-413B-A4CB-3D3661E1413C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes I would love to test it against the Firefox Identity implementation. Were you thinking about adding it to JS code of an open source = bridge/SFU, or standing up an identity service, or both? Best Nils > On Jan 30, 2018, at 05:59, Harald Alvestrand = wrote: >=20 > Speaking of features that have received little love from deployment = .... > would anyone be interested in hacking on the identity API? >=20 > It seems to have received little love from implementors so far, but > there's been strong pushback against removing it too. We need either = it > or something like it to satisfy the security requirements we set out = to > satisfy. >=20 > Harald >=20 >=20 > On 01/24/2018 12:28 PM, T H Panton wrote: >> There has been talk over on the w3c list about the scarcity and = unsuitability of free-standing WebRTC datachannel implementations. >>=20 >> I wonder if this is a suitable target for the IETF 101 hackathon? >>=20 >> The challenge would be to throw up one or 2 free standing datachannel = implementations based on existing open >> source with APIs that might suit authors of networked games or SFUs. >>=20 >> Comments? Thoughts? >>=20 >> T. >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > -- > Surveillance is pervasive. Go Dark. >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_2F403906-8AD4-413B-A4CB-3D3661E1413C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEQ5rmmyEsAeItlZquY2o/VmzJ+KEFAlpxAaIACgkQY2o/VmzJ +KEWkRAAjeDlZz15z0d5OysmCdfnM/8ygzki4mopFq5C9CPUV1kO3f8EOhXW5Q9o 6uj8MqQea0zVK8qOeV0nN1tPkRJcM6Kr+OW6QrzwmmXHZgHjN7Z6oTZ4W52auS80 MlVzS9wkLxAxvNOtZAveRUwNCemYp4LVYGOpoJ7l9A9v1VVniJbu6yHghjkBvv3/ WiUEwBoeNj7/XgAR0Skz4pNA7u5CmcFV1ul/4UvH3MuLpNpDAkG4SPoTVQKLip4i XrKwjJ/DoNre97EFLFohaVLpmz1eFvIl+olfe4qr9aDRX7uLi7k93sLaS4A1a3dx fZbJ9BVcNll8ydM8QZ/dzUvxbFWHA00UvLI7V4VFMBDrQ9jpYoVtq1Seep6hzLu/ LT7PCJYM9poeIPR1zSSUwnIUzdpS5I8ab/YYkurUOGj3VQpOVYELAFmxCdKxr2k3 Y1DtRfgZYDDlxLzH4WdEleTJTi1fEN2rUphGcDUhX4ZDPYLKUvDrIIIb80r/3p9G 4vK+cHIaYY1BfPSfa7p1I/yTI4o9THMV9cLLtHqLic406rQqJ3bpbtiFPxs/J8t1 gmOVhdDEFGdHA5/vaPNNj3laBuO1OdSAmOvnaZ9E9gc0wiiqG2sfV7BPg5+5UIR8 aaTBFxh5zJlFjTBb0OxmUL6rQf0xvzmvw4ivBPa1BDhix1KVmtE= =eBcP -----END PGP SIGNATURE----- --Apple-Mail=_2F403906-8AD4-413B-A4CB-3D3661E1413C-- From nobody Tue Jan 30 23:50:32 2018 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC2131981; Tue, 30 Jan 2018 23:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOV4TP_z1WWT; Tue, 30 Jan 2018 23:50:28 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1709D131975; Tue, 30 Jan 2018 23:50:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 9E1027C3961; Wed, 31 Jan 2018 08:50:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at alvestrand.no Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kKf62YekKQR; Wed, 31 Jan 2018 08:50:22 +0100 (CET) Received: from [IPv6:2001:470:de0a:1::6bb] (unknown [IPv6:2001:470:de0a:1::6bb]) by mork.alvestrand.no (Postfix) with ESMTPSA id 670277C394A; Wed, 31 Jan 2018 08:50:22 +0100 (CET) To: Nils Ohlmeier Cc: dispatch@ietf.org, RTCWeb IETF References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> From: Harald Alvestrand Message-ID: <76f85272-32dc-5282-bd4f-6adbded028bf@alvestrand.no> Date: Wed, 31 Jan 2018 08:50:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lqcngquFUDlYSYCclTaKWJQ73VoCpV9WO" Archived-At: Subject: Re: [rtcweb] [dispatch] Identity? (Re: Datachannel Hackathon at IETF 101 ?) X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 07:50:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lqcngquFUDlYSYCclTaKWJQ73VoCpV9WO Content-Type: multipart/mixed; boundary="N7cpxCIFVPDK2edDSYPG8oiuQr878FUvN"; protected-headers="v1" From: Harald Alvestrand To: Nils Ohlmeier Cc: dispatch@ietf.org, RTCWeb IETF Message-ID: <76f85272-32dc-5282-bd4f-6adbded028bf@alvestrand.no> Subject: Re: [dispatch] [rtcweb] Identity? (Re: Datachannel Hackathon at IETF 101 ?) References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk> <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> In-Reply-To: <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> --N7cpxCIFVPDK2edDSYPG8oiuQr878FUvN Content-Type: multipart/alternative; boundary="------------A39A8567CA1E6CDB67124B38" Content-Language: en-US This is a multi-part message in MIME format. --------------A39A8567CA1E6CDB67124B38 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/31/2018 12:37 AM, Nils Ohlmeier wrote: > Yes I would love to test it against the Firefox Identity implementation= =2E > > Were you thinking about adding it to JS code of an open source bridge/S= FU, or standing up an identity service, or both? Whatever can be shown to work. The point would be to show by demonstration that it's (relatively) easy to provide and use identity service and that Firefox browsers can use it with different backends / services. (I don't see any chance to get identity into Chrome by London - if we can build a convincing story in London, the next IETF might be more hopeful.) > > Best > Nils > >> On Jan 30, 2018, at 05:59, Harald Alvestrand wr= ote: >> >> Speaking of features that have received little love from deployment ..= =2E. >> would anyone be interested in hacking on the identity API? >> >> It seems to have received little love from implementors so far, but >> there's been strong pushback against removing it too. We need either i= t >> or something like it to satisfy the security requirements we set out t= o >> satisfy. >> >> Harald >> >> >> On 01/24/2018 12:28 PM, T H Panton wrote: >>> There has been talk over on the w3c list about the scarcity and unsui= tability of free-standing WebRTC datachannel implementations. >>> >>> I wonder if this is a suitable target for the IETF 101 hackathon? >>> >>> The challenge would be to throw up one or 2 free standing datachannel= implementations based on existing open >>> source with APIs that might suit authors of networked games or SFUs. >>> >>> Comments? Thoughts? >>> >>> T. >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> -- >> Surveillance is pervasive. Go Dark. >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=20 Surveillance is pervasive. Go Dark. --------------A39A8567CA1E6CDB67124B38 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On 01/31/2018 12:37 AM, Nils Ohlmeier wrote:
Yes I would love to test it against the Firefox Iden=
tity implementation.

Were you thinking about adding it to JS code of an open source bridge/SFU=
, or standing up an identity service, or both?

Whatever can be shown to work. The point would be to show by demonstration that it's (relatively) easy to provide and use identity service and that Firefox browsers can use it with different backends / services.

(I don't see any chance to get identity into Chrome by London - if we can build a convincing story in London, the next IETF might be more hopeful.)


Best
  Nils


On Jan 30, 2018, at 05:59, Harald Alvestrand <ha=
rald@alvestrand.no> wrote:

Speaking of features that have received little love from deployment ....
would anyone be interested in hacking on the identity API?

It seems to have received little love from implementors so far, but
there's been strong pushback against removing it too. We need either it
or something like it to satisfy the security requirements we set out to
satisfy.

Harald


On 01/24/2018 12:28 PM, T H Panton wrote:

There has been talk over on the w3c list about t=
he scarcity and unsuitability of free-standing WebRTC datachannel impleme=
ntations.

I wonder if this is a suitable target for the IETF 101 hackathon?

The challenge would be to throw up one or 2 free standing datachannel imp=
lementations based on existing open
source with APIs that might suit authors of networked games or SFUs.

Comments? Thoughts?

T.

_______________________________________________
dispatch mailing list
d=
ispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtc=
web@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb


      

      

      

      
_______________________________________________
dispatch mailing list
d=
ispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


    

    


    

    
--=20
Surveillance is pervasive. Go Dark.


  


--------------A39A8567CA1E6CDB67124B38--

--N7cpxCIFVPDK2edDSYPG8oiuQr878FUvN--

--lqcngquFUDlYSYCclTaKWJQ73VoCpV9WO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEb4QYyvC+S5akmU3BawFW3omifDQFAlpxdT0ACgkQawFW3omi
fDSXwBAAgfV1Fm9PoDqiBrWfdwMVCYhj4s288jJayPuToyHfyCS44v5WysIZV/27
B1oUmNNmigk9FptfRQcJkucAT+vecQjcHuB0XlxRKlkCGkS9Odgnif7D8W5Ohpj5
yX0Vef+QZaFsGIw94BDKMpCDYp1PL5KLKesIYTOg/XcrZX0aFEdtycZzKQfU0F7H
v/+Psse9TK6RStEFnomQ1SYoOLjbYCvNaljGnqOsYLOFKEr0vVzF9ATrVEPojsTJ
hYO1oCABNxhsS2CeoDomT2lsdoFtZh0srl/GFCUPKX2Ixt6LEPfVJYANSxL/cmUp
+mi7/mrSBfh6sKeKLHyScbYsJOMN0lohqt+0R2UKDzEeXWvkqZmQKi3o56jDVR3K
4lh55tKqdA7ac3Meh3SdzSkiPZdjpYRuggGmL90nqsl5bgVSUT1bVTgt2IVoFDaQ
c16ndZDd7DuJwrOnS7/cJZflU2lU6+G276gzf4BzIy9ycJGr1otYlqss/wNatwG9
CMDt9KXdA0Bku9sZ6xL6gnEIbiQcOJgkquS+Mzxi5lc8KqkhLwnt7mKit8T4qC7R
nbPuXSAc7JCbfzvE7dCEh6cpTDI2Zk/spgp8+VGWmqyuKOwhsdgYW7gVQdKJhrdj
E1mZbb6G/rwOCIHX6JQUIHLZgGqzdhePqzmqVZt8itOIyww4/x4=
=oQMx
-----END PGP SIGNATURE-----

--lqcngquFUDlYSYCclTaKWJQ73VoCpV9WO--


From nobody Wed Jan 31 00:05:52 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764DC13168E for ; Wed, 31 Jan 2018 00:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnDuI09C4EC8 for ; Wed, 31 Jan 2018 00:05:48 -0800 (PST)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45FCC131A11 for ; Wed, 31 Jan 2018 00:03:39 -0800 (PST)
Received: by mail-oi0-x231.google.com with SMTP id m83so9886297oik.8 for ; Wed, 31 Jan 2018 00:03:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g+QzjmSjjI4NtOne4o8rmkKn0DzQ6FFER98ue6d3mSg=; b=jNQt9QbvhlskB3Yr5LAoA5DDKpKrHuwDWYW6G/mznUxkx8+EH867mJAc7A0csJyJNJ M0M7lpo/WV5Tk96sAUOov/cpCsZPwZED9izpOPXqmWFqT3TwDTERloaixEnXlP6uCyuN 90N4BAoDpbrRpJquAvlBcHbAHrMbwZdkpYQu05JbPNP9EsGVxE11AT1JS2E+DZr3XEJd gvLTcVbcKc8DCHITybHi3AbMLUzj4SwrmWiSdto8IE2dy1shGS2IzbkQT2QBffHca3Ls ND2OKL7RmmotKLaK/qgoGmwzENp43XtNQ7zSFoNlCVByFLdWtyXuy+h9Y1fy3V1TkUU7 vlRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g+QzjmSjjI4NtOne4o8rmkKn0DzQ6FFER98ue6d3mSg=; b=VCH/Xoa89cmVmQiIke0Ftq0tvBB4ET4KeMGvPZ1SiU7rpCjSJuuOsa/5dxwoQJG23F A4fjn5TFzbl3/SN4hW5JT3PCR4cXZdU0dX2BAebPQR9KXXLFveAn2ohrmCuG3O0evqfL ewnRDEsZdq1nybe+Q8LyhSgUQw2HRhwKT9l6xNt2W/fpKpWck8gQ84nYlve3QciaHtMD LS6cbJlOm54Qbgw5dgkm960tshOIorSJNUlP2tdmzcrJRLCwRbzYaIBasr4Z1d56QrxB +qBdRgTPLGKi1tZMy3QiX81Qp+4QvV7DW8lCg1Rlvhr88eEDz+sWqDlT6w0I5tutQdTE STZw==
X-Gm-Message-State: AKwxytdZhtft+rnW3x8YKbKC8LNwZJFXFXPyrSsjRkyF8u282T4wcaNf bI5nzRwu+9f4/2QSw4xG+Y/+2nduNqrj6W1V/qmaKg==
X-Google-Smtp-Source: AH8x227lxEu6a/ugvYCjqUpkPvgnkKeH3wJyDVdpkrhMCoK/3BwE603YzR9SLETikKVpcydnSP1SRSb4T7CWecz5qms=
X-Received: by 10.202.192.214 with SMTP id q205mr22315663oif.313.1517385818333;  Wed, 31 Jan 2018 00:03:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.157.52.249 with HTTP; Wed, 31 Jan 2018 00:03:37 -0800 (PST)
In-Reply-To: <76f85272-32dc-5282-bd4f-6adbded028bf@alvestrand.no>
References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk>  <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> <76f85272-32dc-5282-bd4f-6adbded028bf@alvestrand.no>
From: Martin Thomson 
Date: Wed, 31 Jan 2018 19:03:37 +1100
Message-ID: 
To: Harald Alvestrand 
Cc: Nils Ohlmeier , RTCWeb IETF 
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
Subject: Re: [rtcweb] [dispatch] Identity? (Re: Datachannel Hackathon at IETF 101 ?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 08:05:51 -0000

(-dispatch)

I'll be at the hackathon and am willing to assist.  I have an identity
provider, but it is garbage.  It would be nice to see something a
little more fully thought out.

On Wed, Jan 31, 2018 at 6:50 PM, Harald Alvestrand  wrote:
> On 01/31/2018 12:37 AM, Nils Ohlmeier wrote:
>
> Yes I would love to test it against the Firefox Identity implementation.
>
> Were you thinking about adding it to JS code of an open source bridge/SFU,
> or standing up an identity service, or both?
>
>
> Whatever can be shown to work. The point would be to show by demonstration
> that it's (relatively) easy to provide and use identity service and that
> Firefox browsers can use it with different backends / services.
>
> (I don't see any chance to get identity into Chrome by London - if we can
> build a convincing story in London, the next IETF might be more hopeful.)
>
>
>
> Best
>   Nils
>
> On Jan 30, 2018, at 05:59, Harald Alvestrand  wrote:
>
> Speaking of features that have received little love from deployment ....
> would anyone be interested in hacking on the identity API?
>
> It seems to have received little love from implementors so far, but
> there's been strong pushback against removing it too. We need either it
> or something like it to satisfy the security requirements we set out to
> satisfy.
>
> Harald
>
>
> On 01/24/2018 12:28 PM, T H Panton wrote:
>
> There has been talk over on the w3c list about the scarcity and
> unsuitability of free-standing WebRTC datachannel implementations.
>
> I wonder if this is a suitable target for the IETF 101 hackathon?
>
> The challenge would be to throw up one or 2 free standing datachannel
> implementations based on existing open
> source with APIs that might suit authors of networked games or SFUs.
>
> Comments? Thoughts?
>
> T.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> --
> Surveillance is pervasive. Go Dark.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>


From nobody Wed Jan 31 00:31:37 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A1712711E for ; Wed, 31 Jan 2018 00:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50cpYl45fZZs for ; Wed, 31 Jan 2018 00:31:28 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 093AB12D94D for ; Wed, 31 Jan 2018 00:31:28 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id 143so6255177wma.5 for ; Wed, 31 Jan 2018 00:31:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=d/k8os45lvbUPmEj4Zg9Ownc1zWz3x8WynUHTQTssh0=; b=vD7ShQ+h+unHxuIpBtXRb2TD1Bf8stl6C8AWVL5vkXU5CqpNPd5wiSBH8FT0AKUPAs eOrXnYtFUigd1rrtem6xMzXRigXs6u9E/nQFD8mtdv1No+ic79/JTbJBSv3nDdHdqZBS bjP0WZRsocSoZIqylhjqP+tY5giE3ccsWaYApCajJn1y8Kyq/iuSejp45oSm281ivNsP VojMXDy/nEVkjevnr7j/wuMAx4X3FeOGFjOUMAy7wzoNuf0lj+TO2S+h3YB6DX5YVNGT 4AhscHWCAAJ71hlSbpIseZLS9iZRXZP3NG1l5P6rQN17BJf46mhza23QSFwnOXJjPy/R eaKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=d/k8os45lvbUPmEj4Zg9Ownc1zWz3x8WynUHTQTssh0=; b=QA2a8MOoByU76jrUwrSVkK7p8GjthiWNGeSDhjEFnSlnXojUQOJ3M5cDK9TdaA8YCS nbinOAb0HdiaHBOwCNwj0TbLV5I0IGLYwimIKCulwf8LRW8aP6RWfi2lkthqIzSzibhV 5cRg8H4mz0dPGPnz0/0AFSvV1hCCNAeILIT+L9/xYjzDPb202kIf0BxCGGmerEmpoI9h Brtybw+zJvKG255CL8vI5Ri9GxwyUQB0IOpRZMkCKR6yq2r8ejycXAe1zomMh4xI8kUQ 7FPlUV+RXZv4YxlgFKW4eTz54gL/Gh7kS+1A6mCMBHYNkkfuGvaKZU/dLmyZ5VpUJ3aR v86A==
X-Gm-Message-State: AKwxytdl3k5T+Y42T676NUVYo9sLj7QCTpHxgN8xXLe23reT48z4f3+Q 6MqKp0YrJhB25e3yj+JupN8mtdQD
X-Google-Smtp-Source: AH8x2253d910e5LVIAMc5RJ/SLSln+UiOXzv+f2l2F0XQb4zMTXVlG4vPxzg/7Xhe/zgjwkMotAKnA==
X-Received: by 10.80.155.7 with SMTP id o7mr42644792edi.105.1517387486203; Wed, 31 Jan 2018 00:31:26 -0800 (PST)
Received: from [192.168.0.11] (213.37.16.193.dyn.user.ono.com. [213.37.16.193]) by smtp.googlemail.com with ESMTPSA id d20sm8165726ede.16.2018.01.31.00.31.25 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Jan 2018 00:31:25 -0800 (PST)
To: rtcweb@ietf.org
References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk>  <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com> <76f85272-32dc-5282-bd4f-6adbded028bf@alvestrand.no> 
From: Sergio Garcia Murillo 
Message-ID: <9e26c867-8a7c-6770-63ae-8f7819435ad8@gmail.com>
Date: Wed, 31 Jan 2018 09:31:25 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [rtcweb] [dispatch] Identity? (Re: Datachannel Hackathon at IETF 101 ?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 08:31:35 -0000

I would be also happy to collaborate and implement it server side.

Best regards
Sergio
On 31/01/2018 9:03, Martin Thomson wrote:
> (-dispatch)
>
> I'll be at the hackathon and am willing to assist.  I have an identity
> provider, but it is garbage.  It would be nice to see something a
> little more fully thought out.
>
> On Wed, Jan 31, 2018 at 6:50 PM, Harald Alvestrand  wrote:
>> On 01/31/2018 12:37 AM, Nils Ohlmeier wrote:
>>
>> Yes I would love to test it against the Firefox Identity implementation.
>>
>> Were you thinking about adding it to JS code of an open source bridge/SFU,
>> or standing up an identity service, or both?
>>
>>
>> Whatever can be shown to work. The point would be to show by demonstration
>> that it's (relatively) easy to provide and use identity service and that
>> Firefox browsers can use it with different backends / services.
>>
>> (I don't see any chance to get identity into Chrome by London - if we can
>> build a convincing story in London, the next IETF might be more hopeful.)
>>
>>
>>
>> Best
>>    Nils
>>
>> On Jan 30, 2018, at 05:59, Harald Alvestrand  wrote:
>>
>> Speaking of features that have received little love from deployment ....
>> would anyone be interested in hacking on the identity API?
>>
>> It seems to have received little love from implementors so far, but
>> there's been strong pushback against removing it too. We need either it
>> or something like it to satisfy the security requirements we set out to
>> satisfy.
>>
>> Harald
>>
>>
>> On 01/24/2018 12:28 PM, T H Panton wrote:
>>
>> There has been talk over on the w3c list about the scarcity and
>> unsuitability of free-standing WebRTC datachannel implementations.
>>
>> I wonder if this is a suitable target for the IETF 101 hackathon?
>>
>> The challenge would be to throw up one or 2 free standing datachannel
>> implementations based on existing open
>> source with APIs that might suit authors of networked games or SFUs.
>>
>> Comments? Thoughts?
>>
>> T.
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> --
>> Surveillance is pervasive. Go Dark.
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>> --
>> Surveillance is pervasive. Go Dark.
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb



From nobody Wed Jan 31 08:34:44 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058E312EC6B; Wed, 31 Jan 2018 08:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP77JG94mWZF; Wed, 31 Jan 2018 08:34:34 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899E2131622; Wed, 31 Jan 2018 08:34:17 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id o89so21632499lfg.10; Wed, 31 Jan 2018 08:34:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cnasQpj3KBexmylcmUmgomNKclWu+8s2W6rRL+m2R9c=; b=suO+2HlaGU55iTXur0+aCdieqp0rrcjeSBSCh4t0vSDfaqfxDIA2SZwPqsqZVVqZOQ gsnR0mjmcf1eSAUsSWGvrkoGeNZmamd3HQ0sTwH5W1m7IFHT62pw867vk4HHhkeB/Po0 Q2MkLU857tpofLOtGhj7f8okg/uidYDQo//kO0cXWDhEa7TmcPmsGnoJFg9G/Js3ExU7 SL4i/fXJLXpdNCKeASoc0416EsmYz8uvCGEZfld5/Lc6geydpfko6cZOJvr6jBcAdF2I y4+dHZoBZvQ014mwfBivs84CNnphsOVVeGe9GmLKvReP1Ket88ARDHa9ccfPnP2+Far6 E02A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cnasQpj3KBexmylcmUmgomNKclWu+8s2W6rRL+m2R9c=; b=KI85SiDiL/DEzlC0T/Q+qHX1NENOH5OlcvdrgJMzIiO5O62xtAxDdyMOcTZQNmoiN1 9kxIM01WkHyLsBOJbbIDLWIogtx4Is0V28sUs7d40lPwfst97xonLBeye6mqXh/Wi69I 2L4SYqi1ich0Cmt2OJe109V+HQIjxYFkzSchR8i1mznzsWy7RpoIOZmWQUCRyMDxtKrt SqdZAh7NLYzC6wInBJvXJoXCVwAPOoxtCWk28k3xlLOkYsEPmHH78ES4abtlZD97b1ik 2e1Sr7yEsSoZGzAqlQ6c5lhuWkm3XYBjZ/6e4x6cRwpKTT3TYoOsAGc45k3XmnzSpvMY TAXg==
X-Gm-Message-State: AKwxytdv0Mkmut3HPDI704V9zVLBzRN+V+M8SoA4kwRSmuN0+s155K0b UcGW4uogGizLpMyDoBnU2s4kYirAnrm0/wB0rVE=
X-Google-Smtp-Source: AH8x226DloAJTPAFI+Rwgjs5B4ieRZcclunCZCj2US+RbBYDgw92dF+gVwNWNEVTXotpiyabp4Aq3FsXRcVa6TJLN6w=
X-Received: by 10.25.80.13 with SMTP id e13mr3405065lfb.72.1517416455870; Wed, 31 Jan 2018 08:34:15 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.160.81 with HTTP; Wed, 31 Jan 2018 08:34:15 -0800 (PST)
In-Reply-To: 
References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk>  <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C13FAB1@ESESSMB109.ericsson.se> 
From: Alexandre GOUAILLARD 
Date: Wed, 31 Jan 2018 08:34:15 -0800
Message-ID: 
To: Nils Ohlmeier 
Cc: Christer Holmberg , "dispatch@ietf.org" ,  RTCWeb IETF , Felix Weinrank 
Content-Type: multipart/alternative; boundary="94eb2c1cb0ded41d930564150c95"
Archived-At: 
Subject: Re: [rtcweb] [dispatch] Datachannel Hackathon at IETF 101 ?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 16:34:38 -0000

--94eb2c1cb0ded41d930564150c95
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

depending on which day this happens, I would join.

On Thu, Jan 25, 2018 at 2:29 PM, Nils Ohlmeier 
wrote:

> Hi Christer,
>
> While I totally agree that it would be awesome to find killer apps for
> data channels I don=E2=80=99t think an IETF Hackathon is a) the place to =
find new
> killer aps and b) creating something at an IETF Hackathon requires an app
> idea to exist already.
>
> It was my understanding that Mr. Panton was proposing to solve the chicke=
n
> and egg problem of people complaining that creating data channel apps
> (outside of browsers) is too complicated by hacking together an easily
> integratabtle data channel lib. I would totally be up to participate in
> that.
>
> Once we have such a lib we and other then can start playing around and
> maybe until the next IETF we will have =E2=80=9Csome cool killer apps=E2=
=80=9D.
>
> Best
>   Nils Ohlmeier
>
> > On Jan 25, 2018, at 13:22, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >
> > Thanks!
> >
> > It would also be interesting to see some cool killer apps (other than
> file transfers) using data channels :)
> >
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]
> > Sent: 25 January 2018 22:27
> > To: Christer Holmberg 
> > Cc: T H Panton ; Felix Weinrank <
> weinrank@fh-muenster.de>; dispatch@ietf.org; RTCWeb IETF 
> > Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ?
> >
> >> On 25. Jan 2018, at 19:14, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >>
> >> Hi,
> >>
> >> If the purpose is to test different data channel stacks (in addition t=
o
> just establishing the SCTP-over-DTLS association), I assume there needs t=
o
> be some applications that use the data channels?
> >>
> >> It would be nice to have webpage where people could add links to their
> >> applications using data channels, so that people can then click :)
> > Some examples can be found at:
> > https://github.com/nplab/WebRTC-Data-Channel-Playground
> >
> > Best regards
> > Michael
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >> -----Original Message-----
> >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Michael
> >> Tuexen
> >> Sent: 25 January 2018 19:47
> >> To: T H Panton 
> >> Cc: Felix Weinrank ; dispatch@ietf.org;
> >> RTCWeb IETF 
> >> Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ?
> >>
> >>> On 24. Jan 2018, at 12:28, T H Panton  wrote:
> >>>
> >>> There has been talk over on the w3c list about the scarcity and
> unsuitability of free-standing WebRTC datachannel implementations.
> >>>
> >>> I wonder if this is a suitable target for the IETF 101 hackathon?
> >>>
> >>> The challenge would be to throw up one or 2 free standing datachannel
> >>> implementations based on existing open source with APIs that might
> suit authors of networked games or SFUs.
> >>>
> >>> Comments? Thoughts?
> >> We are participating and could use the Firefox WebRTC implementation.
> We would be able to debug SCTP issues and possibly some issues in the
> WebRTC implementation of Firefox.
> >>
> >> Best regards
> >> Michael
> >>>
> >>> T.
> >>>
> >>> _______________________________________________
> >>> rtcweb mailing list
> >>> rtcweb@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/rtcweb
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


--=20
Alex. Gouaillard, PhD, PhD, MBA
---------------------------------------------------------------------------=
---------
President - CoSMo Software Consulting, Singapore
---------------------------------------------------------------------------=
---------
sg.linkedin.com/agouaillard

   -

--94eb2c1cb0ded41d930564150c95
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


depending on which day this happens, I would join.

On Thu, Jan 25, 201=
8 at 2:29 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrot=
e:
Hi Christer,



While I totally agree that it would be awesome to find killer apps for data=
 channels I don=E2=80=99t think an IETF Hackathon is a) the place to find n=
ew killer aps and b) creating something at an IETF Hackathon requires an ap=
p idea to exist already.



It was my understanding that Mr. Panton was proposing to solve the chicken =
and egg problem of people complaining that creating data channel apps (outs=
ide of browsers) is too complicated by hacking together an easily integrata=
btle data channel lib. I would totally be up to participate in that.



Once we have such a lib we and other then can start playing around and mayb=
e until the next IETF we will have =E2=80=9Csome cool killer apps=E2=80=9D.=




Best

=C2=A0 Nils Ohlmeier




> On Jan 25, 2018, at 13:22, Christer Holmberg <christer.holmberg@ericsson.com> wr=
ote:

>

> Thanks!

>

> It would also be interesting to see some cool killer apps (other than =
file transfers) using data channels :)

>

> Regards,

>

> Christer

>

> -----Original Message-----

> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]

> Sent: 25 January 2018 22:27

> To: Christer Holmberg <christer.holmberg@ericsson.com>

> Cc: T H Panton <thp@westhawk.=
co.uk>; Felix Weinrank <weinrank@fh-muenster.de>; dis=
patch@ietf.org; RTCWeb IETF <rtcw=
eb@ietf.org>

> Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101 ?
>

>> On 25. Jan 2018, at 19:14, Christer Holmberg <christer.holmberg@ericsson.com>=
; wrote:

>>

>> Hi,

>>

>> If the purpose is to test different data channel stacks (in additi=
on to just establishing the SCTP-over-DTLS association), I assume there nee=
ds to be some applications that use the data channels?

>>

>> It would be nice to have webpage where people could add links to t=
heir

>> applications using data channels, so that people can then click :)=


> Some examples can be found at:

> https://github.com/nplab/WebRTC-Dat=
a-Channel-Playground

>

> Best regards

> Michael

>>

>> Regards,

>>

>> Christer

>>

>>

>> -----Original Message-----

>> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Michael

>> Tuexen

>> Sent: 25 January 2018 19:47

>> To: T H Panton <thp@westh=
awk.co.uk>

>> Cc: Felix Weinrank <=
weinrank@fh-muenster.de>; dispa=
tch@ietf.org;

>> RTCWeb IETF <rtcweb@ietf.org=
>

>> Subject: Re: [dispatch] [rtcweb] Datachannel Hackathon at IETF 101=
 ?

>>

>>> On 24. Jan 2018, at 12:28, T H Panton <thp@westhawk.co.uk> wrote:

>>>

>>> There has been talk over on the w3c list about the scarcity an=
d unsuitability of free-standing WebRTC datachannel implementations.

>>>

>>> I wonder if this is a suitable target for the IETF 101 hackath=
on?

>>>

>>> The challenge would be to throw up one or 2 free standing data=
channel

>>> implementations based on existing open source with APIs that m=
ight suit authors of networked games or SFUs.

>>>

>>> Comments? Thoughts?

>> We are participating and could use the Firefox WebRTC implementati=
on. We would be able to debug SCTP issues and possibly some issues in the W=
ebRTC implementation of Firefox.

>>

>> Best regards

>> Michael

>>>

>>> T.

>>>

>>> _______________________________________________

>>> rtcweb mailing list

>>> rtcweb@ietf.org

>>> https://www.ietf.org/mailman/listinf=
o/rtcweb

>>

>> _______________________________________________

>> dispatch mailing list

>> dispatch@ietf.org

>> https://www.ietf.org/mailman/listinfo/di=
spatch

>

> _______________________________________________

> rtcweb mailing list

> rtcweb@ietf.org

> https://www.ietf.org/mailman/listinfo/rtcweb





_______________________________________________

rtcweb mailing list

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb




-- 
=

Alex. Gouaillard, P=
hD, PhD, MBA
----------------------------------------------------------=
--------------------------
President - CoSMo Software Consulting,=
 Singapore
------------------------------------------------------=
------------------------------

    • 

    

--94eb2c1cb0ded41d930564150c95--


From nobody Wed Jan 31 08:36:57 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626A81252BA; Wed, 31 Jan 2018 08:36:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id civGmAFKRjzZ; Wed, 31 Jan 2018 08:36:53 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776D812EB0F; Wed, 31 Jan 2018 08:36:36 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id q17so21644577lfa.9; Wed, 31 Jan 2018 08:36:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y7K0EEWLLWqN+J9J9SiyjRed94GPJupNWBCg5Xr2MwU=; b=Rvn5sdasKpvAd+SoXY6EAnsc208OXxYudxE/D2VfHlmpri0LEfyJzzRSWsb2PF6JHW 8X9F0zKcEqLfBynsNxr+29ipzJ7H4QcVz+O4C0YQTYtlQEeVAgg+MoCe+G4bRSXR9MTi N9XQxrYG5EFcTJofDK9nQuv10YepjQr+5RBwrcsWTfftxuGha9fj0ydgk6OcbiTbCTAs 5SkMEovEJ/rMKxK3SPI6zOXRVvUowbsKHRaOwVjecoLmpFGrnIvgj+g6bH6EEPnI4Axx OEWe8nHJKZqbL8d2rGl5zOeSyDDZLGMhQotMgvGilNx+/TuumxIvXkn3dObq/LXGpXbQ wuxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y7K0EEWLLWqN+J9J9SiyjRed94GPJupNWBCg5Xr2MwU=; b=msoHaRN2EXkNSYzbibuKP//DlYee6XtvhUwLa4I0rv6DVdvYcrcv74WxAtLuCPh1yY tff1IaODMAnLmMIB7MgR/OfMnye+BWPNHsl+BBzyLoZTwhHBjoH/oRY/mJ/abC6XxSVC vtEQtcBEOe2e+563DdlFo8Vc+KnXNjgJuhetDFgEQU6Ma5LFHt6W9fVV24dQ6IBoAiMr ORPd6pjhNOGwjcMbskwQgpy8WDhHWGxyQk9PZFsyveO8kxrxxIGwAn9gWaOu3/ImGNao 3B752Ij6zp2KjLrwMOmGk1y6cmsVIWHGt0jlFpHtv3QvPv49ULRRFRVqfwrA5MAEvOlK 8F+w==
X-Gm-Message-State: AKwxyteUUqMpnFGcmRHX9tcy1lkB5GiZ2+C4dCtlQ1oFtJGb0x3mg8HH xfsFPDgeZVksH1yL0s3YLUKYeYKcKxRruBN1UwA=
X-Google-Smtp-Source: AH8x227PIyykTDx5NEiqPfYGFw5H9WV3lPP4JObTPeVkLL3QNRLyeYvatbwStw78oQp3pbSbTQns1I4Osaw2Zb+6XDg=
X-Received: by 10.46.80.88 with SMTP id v24mr3312605ljd.86.1517416594789; Wed, 31 Jan 2018 08:36:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.160.81 with HTTP; Wed, 31 Jan 2018 08:36:34 -0800 (PST)
In-Reply-To: <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com>
References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk>  <1F301D9F-B778-422C-81F7-98F4121A11D8@mozilla.com>
From: Alexandre GOUAILLARD 
Date: Wed, 31 Jan 2018 08:36:34 -0800
Message-ID: 
To: Nils Ohlmeier 
Cc: Harald Alvestrand , dispatch@ietf.org, RTCWeb IETF 
Content-Type: multipart/alternative; boundary="f403045fb74e1bec320564151502"
Archived-At: 
Subject: Re: [rtcweb] Identity? (Re: [dispatch] Datachannel Hackathon at IETF 101 ?)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 16:36:55 -0000

--f403045fb74e1bec320564151502
Content-Type: text/plain; charset="UTF-8"

I might have a use case with block chain, and bandwidth to hack something
there in march.
if I understand correctly, you need *one* implementation of the concept to
play well with the webrtc spec, correct?

On Tue, Jan 30, 2018 at 3:37 PM, Nils Ohlmeier 
wrote:

> Yes I would love to test it against the Firefox Identity implementation.
>
> Were you thinking about adding it to JS code of an open source bridge/SFU,
> or standing up an identity service, or both?
>
> Best
>   Nils
>
> > On Jan 30, 2018, at 05:59, Harald Alvestrand 
> wrote:
> >
> > Speaking of features that have received little love from deployment ....
> > would anyone be interested in hacking on the identity API?
> >
> > It seems to have received little love from implementors so far, but
> > there's been strong pushback against removing it too. We need either it
> > or something like it to satisfy the security requirements we set out to
> > satisfy.
> >
> > Harald
> >
> >
> > On 01/24/2018 12:28 PM, T H Panton wrote:
> >> There has been talk over on the w3c list about the scarcity and
> unsuitability of free-standing WebRTC datachannel implementations.
> >>
> >> I wonder if this is a suitable target for the IETF 101 hackathon?
> >>
> >> The challenge would be to throw up one or 2 free standing datachannel
> implementations based on existing open
> >> source with APIs that might suit authors of networked games or SFUs.
> >>
> >> Comments? Thoughts?
> >>
> >> T.
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> dispatch@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> >
> > --
> > Surveillance is pervasive. Go Dark.
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>


-- 
Alex. Gouaillard, PhD, PhD, MBA
------------------------------------------------------------------------------------
President - CoSMo Software Consulting, Singapore
------------------------------------------------------------------------------------
sg.linkedin.com/agouaillard

   -

--f403045fb74e1bec320564151502
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    I might have a use case with block chain, and bandwidth to=
 hack something there in march.
    if I understand correctly, you need *on=
e* implementation of the concept to play well with the webrtc spec, correct=
?

    On T=
ue, Jan 30, 2018 at 3:37 PM, Nils Ohlmeier <nohlmeier@mozilla.com&=
gt; wrote:
    Yes I would love to tes=
t it against the Firefox Identity implementation.
    

    
Were you thinking about adding it to JS code of an open source bridge/SFU, =
or standing up an identity service, or both?
    

    
Best
    
=C2=A0 Nils
    


    
> On Jan 30, 2018, at 05:59, Harald Alvestrand <harald@alvestrand.no> wrote:
    
>
    
> Speaking of features that have received little love from deployment ..=
..
    
> would anyone be interested in hacking on the identity API?
    
>
    
> It seems to have received little love from implementors so far, but
> there's been strong pushback against removing it too. We need eith=
er it
    
> or something like it to satisfy the security requirements we set out t=
o
    
> satisfy.
    
>
    
> Harald
    
>
    
>
    
> On 01/24/2018 12:28 PM, T H Panton wrote:
    
>> There has been talk over on the w3c list about the scarcity and un=
suitability of free-standing WebRTC datachannel implementations.
    
>>
    
>> I wonder if this is a suitable target for the IETF 101 hackathon?<=
br>
>>
    
>> The challenge would be to throw up one or 2 free standing datachan=
nel implementations based on existing open
    
>> source with APIs that might suit authors of networked games or SFU=
s.
    
>>
    
>> Comments? Thoughts?
    
>>
    
>> T.
    
>>
    
>> _______________________________________________
    
>> dispatch mailing list
    
>> dispatch@ietf.org
    
>> https://www.ietf.org/mailman/listinfo/di=
spatch
    
>
    
>
    
> --
    
> Surveillance is pervasive. Go Dark.
    
>
    
> _______________________________________________
    
> rtcweb mailing list
    
> rtcweb@ietf.org
    
> https://www.ietf.org/mailman/listinfo/rtcweb
    

    


    _______________________________________________
    
rtcweb mailing list
    
    rtcweb@ietf.org
    
https://www.ietf.org/mailman/listinfo/rtcweb




    -- 
    =

    Alex. Gouaillard, P=
hD, PhD, MBA
    ----------------------------------------------------------=
--------------------------
    President - CoSMo Software Consulting,=
 Singapore
    ------------------------------------------------------=
------------------------------

    • 

    

--f403045fb74e1bec320564151502--


From nobody Wed Jan 31 08:49:12 2018
Return-Path: 
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9619812EBE1 for ; Wed, 31 Jan 2018 08:49:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Level: 
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4shOMvpWZ6BX for ; Wed, 31 Jan 2018 08:49:09 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A87C112EB23 for ; Wed, 31 Jan 2018 08:49:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517417346; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=LSAc2hyLAki5be7Z+/vmLf6uTL0e8LBSlOX56Gq0CS0=; b=Tl3wZv3AQOMlq9t0PF2FjEDOdth3hwDiUOsF8+1spWKb8oa3lL3icijReEOPaIbZ PDcwOnW/6fn6uOsjgP5o1VkHSPMlwMe+TjeZ4TZDO7giiQqcHyIW0dZqx6P/bd3f xVAoBALAStO6higG3S0ZjEkuozNRuFY7zm17NmRRjfA=;
X-AuditID: c1b4fb30-d49ff70000006bc7-95-5a71f3829bb5
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 92.2E.27591.283F17A5; Wed, 31 Jan 2018 17:49:06 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.195]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0352.000; Wed, 31 Jan 2018 17:49:06 +0100
From: Christer Holmberg 
To: Nils Ohlmeier 
CC: Michael Tuexen , Felix Weinrank , "dispatch@ietf.org" , "RTCWeb IETF" 
Thread-Topic: [rtcweb] [dispatch]  Datachannel Hackathon at IETF 101 ?
Thread-Index: AQHTliv5urSBOFf32Uic+hg3oehF36OON9RQ
Date: Wed, 31 Jan 2018 16:49:05 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B6C14BE0B@ESESSMB109.ericsson.se>
References: <4B65832E-7BD6-4515-9C09-0C392BC85BC9@westhawk.co.uk>  <7594FB04B1934943A5C02806D1A2204B6C13F489@ESESSMB109.ericsson.se>  <7594FB04B1934943A5C02806D1A2204B6C13FAB1@ESESSMB109.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2J7oG7T58Iog9lPjC2WTlrAanGxaQmj xfV5kxkt1v5rZ7eY2rqC3YHVo2fKaVaPJUt+MnlsaNnB5NF3oIs1gCWKyyYlNSezLLVI3y6B K2P5p6OMBYsMK1p3LWRsYGww6GLk5JAQMJFoaz/J3MXIxSEkcJhRov3kZxYIZwmjxMaGNexd jBwcbAIWEt3/tEFMEQFNiRMb+UBKmAXWMkpM2PqWDWSQsICrxPY3y5hBbBEBN4mndz+xQthG Em3bpoDVsAioSjxYfosFxOYV8JWYuXQFI8SuL0wSk69sASviFLCXOLTvITuIzSggJvH91Bom EJtZQFzi1pP5TBBXC0gs2XOeGcIWlXj5+B8rhK0ksfbwdhaQQ5mBDl2/Sx+iVVFiSjfESF4B QYmTM5+wTGAUnYVk6iyEjllIOmYh6VjAyLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCu Dm75bbCD8eVzx0OMAhyMSjy8B+8VRgmxJpYVV+YeYpTgYFYS4d1zESjEm5JYWZValB9fVJqT WnyIUZqDRUmc96Qnb5SQQHpiSWp2ampBahFMlomDU6qBccOteR9kN59q1nt55p/wV5kjDzPF ajTKTv07dvl3ceDF/9ztjgX7tK3brjBvYzS2n6HOaXcltv6TteMxb5cCzdn3boe/ffWgcufr DTWm5cHZ2ubpt/U0jXqSzp/7JZ5r95E/8NwVwUIf7u6wb45RrqXrP5ZGdzPcf/VF8lFF+z37 B+x92yJslViKMxINtZiLihMB6bjaGKcCAAA=
Archived-At: 
Subject: Re: [rtcweb] [dispatch]  Datachannel Hackathon at IETF 101 ?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 31 Jan 2018 16:49:11 -0000

SGksDQoNCkkgYWdyZWUgdGhhdCB0aGUgbWFpbiBwdXJwb3NlIG9mIHRoZSBoYWNrYXRob24gaXMg
bm90IHRvIG1ha2UgYXBwcy4NCg0KQnV0LCB3aGF0IHByZXZlbnRzIHBlb3BsZSBmcm9tIHNob3dp
bmcgdGhlaXIgYXBwcywgYW5kIGRpc2N1c3MgZGF0YSBjaGFubmVsIHJlbGF0ZWQgcHJvYmxlbXMg
dGhhdCB0aGV5IG1heSBoYXZlIHJhbiBpbnRvPyBBbHNvLCBoYXZpbmcgYSAic2hvdyBjYXNlIiBt
YXkgdHJpZ2dlciB3aWRlciBpbnRlcmVzdCA6KQ0KDQpGb3IgZXhhbXBsZSwgd2hlbiBJIGRpZCBh
IGZpbGUgdHJhbnNmZXIgYXBwIHNvbWUgdGltZSBhIGZldyB5ZWFycyBhZ28sIEkgbm90ZWQgdGhh
dCB0aGUgZGF0YSBjaGFubmVsIGtlcHQgZ29pbmcgZG93bi4gT24gdGhlIE1vemlsbGEoPykgZGV2
ZWxvcGVyIHNpdGUgSSBmaWd1cmVkIG91dCB0aGF0IG9uZSBoYWQgdG8gaW5jbHVkZSBhcHBsaWNh
dGlvbiBsZXZlbCBwYXVzZXMgYmV0d2VlbiBzZW5kaW5nIGZyYWdtZW50cyBmcm9tIHByZXZlbnRp
bmcgdGhhdCB0byBoYXBwZW4uIERvbid0IGtub3cgaWYgdGhhdCBpcyBzdGlsbCBhbiBpc3N1ZSwg
YnV0IGp1c3QgdG8gZ2l2ZSBhbiBleGFtcGxlLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5pbHMgT2hsbWVpZXIgW21haWx0
bzpub2hsbWVpZXJAbW96aWxsYS5jb21dIA0KU2VudDogMjYgSmFudWFyeSAyMDE4IDAwOjI5DQpU
bzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNj
OiBNaWNoYWVsIFR1ZXhlbiA8TWljaGFlbC5UdWV4ZW5AbHVyY2hpLmZyYW5rZW4uZGU+OyBGZWxp
eCBXZWlucmFuayA8d2VpbnJhbmtAZmgtbXVlbnN0ZXIuZGU+OyBkaXNwYXRjaEBpZXRmLm9yZzsg
UlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBbZGlz
cGF0Y2hdIERhdGFjaGFubmVsIEhhY2thdGhvbiBhdCBJRVRGIDEwMSA/DQoNCkhpIENocmlzdGVy
LA0KDQpXaGlsZSBJIHRvdGFsbHkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBhd2Vzb21lIHRvIGZp
bmQga2lsbGVyIGFwcHMgZm9yIGRhdGEgY2hhbm5lbHMgSSBkb27igJl0IHRoaW5rIGFuIElFVEYg
SGFja2F0aG9uIGlzIGEpIHRoZSBwbGFjZSB0byBmaW5kIG5ldyBraWxsZXIgYXBzIGFuZCBiKSBj
cmVhdGluZyBzb21ldGhpbmcgYXQgYW4gSUVURiBIYWNrYXRob24gcmVxdWlyZXMgYW4gYXBwIGlk
ZWEgdG8gZXhpc3QgYWxyZWFkeS4NCg0KSXQgd2FzIG15IHVuZGVyc3RhbmRpbmcJdGhhdCBNci4g
UGFudG9uIHdhcyBwcm9wb3NpbmcgdG8gc29sdmUgdGhlIGNoaWNrZW4gYW5kIGVnZyBwcm9ibGVt
IG9mIHBlb3BsZSBjb21wbGFpbmluZyB0aGF0IGNyZWF0aW5nIGRhdGEgY2hhbm5lbCBhcHBzIChv
dXRzaWRlIG9mIGJyb3dzZXJzKSBpcyB0b28gY29tcGxpY2F0ZWQgYnkgaGFja2luZyB0b2dldGhl
ciBhbiBlYXNpbHkgaW50ZWdyYXRhYnRsZSBkYXRhIGNoYW5uZWwgbGliLiBJIHdvdWxkIHRvdGFs
bHkgYmUgdXAgdG8gcGFydGljaXBhdGUgaW4gdGhhdC4NCg0KT25jZSB3ZSBoYXZlIHN1Y2ggYSBs
aWIgd2UgYW5kIG90aGVyIHRoZW4gY2FuIHN0YXJ0IHBsYXlpbmcgYXJvdW5kIGFuZCBtYXliZSB1
bnRpbCB0aGUgbmV4dCBJRVRGIHdlIHdpbGwgaGF2ZSDigJxzb21lIGNvb2wga2lsbGVyIGFwcHPi
gJ0uDQoNCkJlc3QNCiAgTmlscyBPaGxtZWllcg0KDQo+IE9uIEphbiAyNSwgMjAxOCwgYXQgMTM6
MjIsIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdy
b3RlOg0KPiANCj4gVGhhbmtzIQ0KPiANCj4gSXQgd291bGQgYWxzbyBiZSBpbnRlcmVzdGluZyB0
byBzZWUgc29tZSBjb29sIGtpbGxlciBhcHBzIChvdGhlciB0aGFuIA0KPiBmaWxlIHRyYW5zZmVy
cykgdXNpbmcgZGF0YSBjaGFubmVscyA6KQ0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVy
DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWNoYWVsIFR1ZXhl
biBbbWFpbHRvOk1pY2hhZWwuVHVleGVuQGx1cmNoaS5mcmFua2VuLmRlXQ0KPiBTZW50OiAyNSBK
YW51YXJ5IDIwMTggMjI6MjcNCj4gVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xt
YmVyZ0Blcmljc3Nvbi5jb20+DQo+IENjOiBUIEggUGFudG9uIDx0aHBAd2VzdGhhd2suY28udWs+
OyBGZWxpeCBXZWlucmFuayANCj4gPHdlaW5yYW5rQGZoLW11ZW5zdGVyLmRlPjsgZGlzcGF0Y2hA
aWV0Zi5vcmc7IFJUQ1dlYiBJRVRGIA0KPiA8cnRjd2ViQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS
ZTogW2Rpc3BhdGNoXSBbcnRjd2ViXSBEYXRhY2hhbm5lbCBIYWNrYXRob24gYXQgSUVURiAxMDEg
Pw0KPiANCj4+IE9uIDI1LiBKYW4gMjAxOCwgYXQgMTk6MTQsIENocmlzdGVyIEhvbG1iZXJnIDxj
aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IHdyb3RlOg0KPj4gDQo+PiBIaSwNCj4+IA0K
Pj4gSWYgdGhlIHB1cnBvc2UgaXMgdG8gdGVzdCBkaWZmZXJlbnQgZGF0YSBjaGFubmVsIHN0YWNr
cyAoaW4gYWRkaXRpb24gdG8ganVzdCBlc3RhYmxpc2hpbmcgdGhlIFNDVFAtb3Zlci1EVExTIGFz
c29jaWF0aW9uKSwgSSBhc3N1bWUgdGhlcmUgbmVlZHMgdG8gYmUgc29tZSBhcHBsaWNhdGlvbnMg
dGhhdCB1c2UgdGhlIGRhdGEgY2hhbm5lbHM/DQo+PiANCj4+IEl0IHdvdWxkIGJlIG5pY2UgdG8g
aGF2ZSB3ZWJwYWdlIHdoZXJlIHBlb3BsZSBjb3VsZCBhZGQgbGlua3MgdG8gDQo+PiB0aGVpciBh
cHBsaWNhdGlvbnMgdXNpbmcgZGF0YSBjaGFubmVscywgc28gdGhhdCBwZW9wbGUgY2FuIHRoZW4g
Y2xpY2sgDQo+PiA6KQ0KPiBTb21lIGV4YW1wbGVzIGNhbiBiZSBmb3VuZCBhdDoNCj4gaHR0cHM6
Ly9naXRodWIuY29tL25wbGFiL1dlYlJUQy1EYXRhLUNoYW5uZWwtUGxheWdyb3VuZA0KPiANCj4g
QmVzdCByZWdhcmRzDQo+IE1pY2hhZWwNCj4+IA0KPj4gUmVnYXJkcywNCj4+IA0KPj4gQ2hyaXN0
ZXINCj4+IA0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogZGlz
cGF0Y2ggW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+
PiBNaWNoYWVsIFR1ZXhlbg0KPj4gU2VudDogMjUgSmFudWFyeSAyMDE4IDE5OjQ3DQo+PiBUbzog
VCBIIFBhbnRvbiA8dGhwQHdlc3RoYXdrLmNvLnVrPg0KPj4gQ2M6IEZlbGl4IFdlaW5yYW5rIDx3
ZWlucmFua0BmaC1tdWVuc3Rlci5kZT47IGRpc3BhdGNoQGlldGYub3JnOyANCj4+IFJUQ1dlYiBJ
RVRGIDxydGN3ZWJAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBbcnRjd2Vi
XSBEYXRhY2hhbm5lbCBIYWNrYXRob24gYXQgSUVURiAxMDEgPw0KPj4gDQo+Pj4gT24gMjQuIEph
biAyMDE4LCBhdCAxMjoyOCwgVCBIIFBhbnRvbiA8dGhwQHdlc3RoYXdrLmNvLnVrPiB3cm90ZToN
Cj4+PiANCj4+PiBUaGVyZSBoYXMgYmVlbiB0YWxrIG92ZXIgb24gdGhlIHczYyBsaXN0IGFib3V0
IHRoZSBzY2FyY2l0eSBhbmQgdW5zdWl0YWJpbGl0eSBvZiBmcmVlLXN0YW5kaW5nIFdlYlJUQyBk
YXRhY2hhbm5lbCBpbXBsZW1lbnRhdGlvbnMuDQo+Pj4gDQo+Pj4gSSB3b25kZXIgaWYgdGhpcyBp
cyBhIHN1aXRhYmxlIHRhcmdldCBmb3IgdGhlIElFVEYgMTAxIGhhY2thdGhvbj8NCj4+PiANCj4+
PiBUaGUgY2hhbGxlbmdlIHdvdWxkIGJlIHRvIHRocm93IHVwIG9uZSBvciAyIGZyZWUgc3RhbmRp
bmcgDQo+Pj4gZGF0YWNoYW5uZWwgaW1wbGVtZW50YXRpb25zIGJhc2VkIG9uIGV4aXN0aW5nIG9w
ZW4gc291cmNlIHdpdGggQVBJcyB0aGF0IG1pZ2h0IHN1aXQgYXV0aG9ycyBvZiBuZXR3b3JrZWQg
Z2FtZXMgb3IgU0ZVcy4NCj4+PiANCj4+PiBDb21tZW50cz8gVGhvdWdodHM/DQo+PiBXZSBhcmUg
cGFydGljaXBhdGluZyBhbmQgY291bGQgdXNlIHRoZSBGaXJlZm94IFdlYlJUQyBpbXBsZW1lbnRh
dGlvbi4gV2Ugd291bGQgYmUgYWJsZSB0byBkZWJ1ZyBTQ1RQIGlzc3VlcyBhbmQgcG9zc2libHkg
c29tZSBpc3N1ZXMgaW4gdGhlIFdlYlJUQyBpbXBsZW1lbnRhdGlvbiBvZiBGaXJlZm94Lg0KPj4g
DQo+PiBCZXN0IHJlZ2FyZHMNCj4+IE1pY2hhZWwNCj4+PiANCj4+PiBULg0KPj4+IA0KPj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gcnRjd2Vi
IG1haWxpbmcgbGlzdA0KPj4+IHJ0Y3dlYkBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vcnRjd2ViDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4+
IGRpc3BhdGNoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2Rpc3BhdGNoDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPiBydGN3ZWIgbWFpbGluZyBsaXN0DQo+IHJ0Y3dlYkBpZXRmLm9yZw0KPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J0Y3dlYg0KDQo=