From nobody Wed Nov 1 10:52:19 2017 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 ADBFD13FDA9 for ; Wed, 1 Nov 2017 10:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 21xwdmYfoXJz for ; Wed, 1 Nov 2017 10:52:14 -0700 (PDT) Received: from mail-ua0-x244.google.com (mail-ua0-x244.google.com [IPv6:2607:f8b0:400c:c08::244]) (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 AAB7F13FA2D for ; Wed, 1 Nov 2017 10:52:14 -0700 (PDT) Received: by mail-ua0-x244.google.com with SMTP id u32so2126634uau.0 for ; Wed, 01 Nov 2017 10:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=65lT0WHvwMJoIeJKHfF/0GuiKNox10bUKrNdYOuUCAo=; b=dQYWVjatbgT9rGHuusBSRojK+R8oOBxgBCitWHSRWSAJFq1aUtY+tkmWX6II9LGfA8 SRFB5w0FxUU4qS+k6uM9hMIPBRGy6qRBk+/qEovsx42xf8JMiuGCwVnZGrBVF3mq0Y57 5xqDYwyVdxZUd+o1g3hZ5cbmr/8dJ9PA4yFCeJRo2bWPcJx3A4HSwGzh1TsGc4yG9Kew +Gag2n9bpM7vHoiub/gzKrOOwEvGiWZjJb5mR6LtiaMk3Xc0PRiF7Km+hUEsPVZA1zQ8 vB/YbfuCg50YVVJIlRNs5c/jZXSiemY0RgExLBRAsGnW8iQAA/dAXyMimCMzqcuUTDe3 k/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=65lT0WHvwMJoIeJKHfF/0GuiKNox10bUKrNdYOuUCAo=; b=jA3BJ+CkcQXGUyYKTstHbDKkqN1PR5SOTMF6lP7tBxfNkmVvpDubLAi1MPU93WAZY3 rh1pgtl3Wuu+actSBv/9s72TpxBzaVtcLnaNgQ7F87gA5zUHmmhwwqlFQRF354IPPzE4 ApKa8eECP37Ye7Hcm9Kbzx6RJOmUb9HeK74KX4LZzkR9Jb4BhbcCrPTeYlWI8q9uyM5B KRvpOowFWx7Rr15WvfsbgduKPpbr3K2MOcdAxsSXZU0lIEFwRMC/VgloJSKL4jq0krmo OOLeC6lE9iGL7J6/ZJkau95RuPzDq+efUvgCTJaRfwNgK2VFmw8R9DJ7GmsHR0fJMdfB rg9A== X-Gm-Message-State: AMCzsaVqr6ugWdS9eVV3VtQGmAympsUs+BOyKHNhwWH4qHtsVn1993bV statMXKcS4Y23TiTM7i+D4an7/4+4Li0p6Md3m+P0UYI X-Google-Smtp-Source: ABhQp+Q9j+S0HAeGPZtuDIlXAw8TkylIoo8wXilR/70Qtp+AlC62UVrP9MBnrqHBShbBa5yuircNcMzdV7W+pR0ArYI= X-Received: by 10.176.64.131 with SMTP id i3mr513144uad.195.1509558733265; Wed, 01 Nov 2017 10:52:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Wed, 1 Nov 2017 10:51:52 -0700 (PDT) From: Bernard Aboba Date: Wed, 1 Nov 2017 10:51:52 -0700 Message-ID: To: "rtcweb@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12370e106035055cef8818" Archived-At: Subject: [rtcweb] WebRTC Testing Session: November 6, 2017 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, 01 Nov 2017 17:52:17 -0000 --94eb2c12370e106035055cef8818 Content-Type: text/plain; charset="UTF-8" On Monday, November 6, the W3C WebRTC WG will be hosting a public session on WebRTC testing that will be open to remote participation. The purpose of this session (held in conjunction with the WebRTC WG meeting at TPAC 2017) is to introduce WebRTC testing (and associated tools) to a wider audience. The session will describe the Karoshi Interoperability Testing Engine (KITE) test framework and will include a tutorial describing how to write tests for the framework. If you have an interest in improving WebRTC interoperability, you are encouraged to attend this session, which will be recorded for later viewing by those who can't attend it live. Time: 9 AM - 10:30 AM Pacific Time Presenters: Dr. Alex Gouaillard, Huib Kleinhout, Soares Chen WebEx details: https://www.w3.org/2011/04/webrtc/wiki/Public_session_on_WebRTC_testing_November_6 KITE link: https://github.com/webrtc/KITE --94eb2c12370e106035055cef8818 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, November 6, the W3C WebRTC WG will be hosting a= public session on WebRTC testing that will be open to remote participation= .=C2=A0

The purpose of this session (held in conjunction= with the WebRTC WG meeting at TPAC 2017) is to introduce WebRTC testing (a= nd associated tools) to a wider audience.=C2=A0 The session will describe t= he Karoshi Interoperability Testing Engine (KITE) test framework and will i= nclude a tutorial describing how to write tests for the framework.

If you have an interest in improving WebRTC interoperabili= ty, you are encouraged to attend this session, which will be recorded for l= ater viewing by those who can't attend it live.=C2=A0
Time: 9 AM - 10:30 AM Pacific Time
Presenters: Dr. Al= ex Gouaillard, Huib Kleinhout, Soares Chen

--94eb2c12370e106035055cef8818-- From nobody Thu Nov 2 02:11:01 2017 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 487DD13F47C for ; Thu, 2 Nov 2017 02:11:00 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 dhRlW02p_ZOJ for ; Thu, 2 Nov 2017 02:10:57 -0700 (PDT) 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 20B0513F848 for ; Thu, 2 Nov 2017 02:10:52 -0700 (PDT) X-AuditID: c1b4fb25-debff70000000c94-f6-59fae11b231b Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FB.8F.03220.B11EAF95; Thu, 2 Nov 2017 10:10:51 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 2 Nov 2017 10:10:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9SKeez6bHsyGPo54WooItHT17pAwek+T+TMlVHpOFa8=; b=IA/YNCKmKO3UHpsayYprvL/+1iovsAq6VRaa7KEtn0ILpg22WbZh8ZLG1PRzliiar+KK2OWbOKMXg1OluHJW8y8VOtbQmVbDZN1D+ZcugRcjbjpgJzR1tLSIPLpUaloCdB96st/JkYUug8k/M7w9XVMHJet6mFalXCwUSdSgpo4= Received: from HE1PR07MB3418.eurprd07.prod.outlook.com (10.170.247.33) by HE1PR07MB3417.eurprd07.prod.outlook.com (10.170.247.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Thu, 2 Nov 2017 09:10:48 +0000 Received: from HE1PR07MB3418.eurprd07.prod.outlook.com ([fe80::2988:5229:680c:5bf8]) by HE1PR07MB3418.eurprd07.prod.outlook.com ([fe80::2988:5229:680c:5bf8%13]) with mapi id 15.20.0197.014; Thu, 2 Nov 2017 09:10:48 +0000 From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= To: Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Issue with "priority" defined in rtcweb-transports Thread-Index: AQHTQraQlfDbNaaI7EiLfsBp+xqE3A== Date: Thu, 2 Nov 2017 09:10:48 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=stefan.lk.hakansson@ericsson.com; x-originating-ip: [192.176.1.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3417; 6:VkoCeAltJXwMkFW583UAHx98lZQ1NZaW/RozqCROk+ixe20Wsp0OBVyaHiqTKzg/MtcRBeNM8+oCZfcd6Ah9LG2gX/kPNLFvP0z314kc87aVvBtLZyYFVEen3C89ODbr/v67eEHFNW24LOhD7dLG7pBi73tpmR9KzYTQcWS0yM099wRqXtYS4ZsBcSe5Rtx9sfDE58YYE55jLk+iqUmhu6SxszpMGq2syaFAQ8oCCri3JXpaKVO/Nk5MnXCk5xH2cMePRcn0313XbBr9pN5k/3xfDirjOokSSdxdFxkghc4SB7EvaBg4wBbgIuMQx+y7qtTITalkJtGE9BqPY/cXZUXpWMNIYtcH0HRdkyItqh0=; 5:bxn9D3zyEYlaC3d+l6ZuKQNCTT8/M1uFeh7ErdKS3Qi5r/BlPD1BeKv2xxn/vOccbZCRJ565egygrECvYxvkwbxGYgFQQMPCUv8zNLyD1NlCcn0xIU32nFsKFy3U0iQYdGrmIaoReL9QUWmZB3io+5sjTmoFQ17ovSBHCtzRKLU=; 24:AxKnb0HddSG4V/Q1sNoL8GEAuhVKLajhe/acmvgSfGCbsQD4gziVkDqt1etlhXDUi0uSztf3+FwJrh7HajGHBWCW3be7OnNI3CuqGFC+DmI=; 7:e0hw7h2QjWdl83BGMMUISG8b4tcFz03qt36uq/3NzIno4QyuYjWNfTBpdSMs6dfuDLtJ/+AvRUJKGXVRY3RuOL3qVZqA+lDCnB+4hSS5S9AiEaZ4aMWOE+XsDHtiNVnDledKo6658e2HCOyi/ULPnlvWxOLFSsifbIcVuKsGQaoZH9zI4iQVdRc8lgYwQCb+p9O6XtVGEX6RlrOo3jclzcyTvvLW+J8yMwfv/l1QVjZ6Ic74YADJ68mMDshy6tGp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2ab7207e-d5df-4292-735e-08d521d19b93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3417; x-ms-traffictypediagnostic: HE1PR07MB3417: x-exchange-antispam-report-test: UriScan:(166708455590820); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3231020)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3417; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3417; x-forefront-prvs: 047999FF16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(189002)(24454002)(199003)(53936002)(6306002)(9686003)(53546010)(97736004)(966005)(55016002)(99286004)(478600001)(81166006)(81156014)(2906002)(5660300001)(8676002)(7696004)(106356001)(105586002)(3846002)(6116002)(102836003)(33656002)(101416001)(74316002)(305945005)(189998001)(110136005)(86362001)(7736002)(316002)(5890100001)(14454004)(66066001)(6436002)(2900100001)(6506006)(25786009)(8936002)(229853002)(6246003)(3280700002)(3660700001)(5250100002)(68736007)(76176999)(54356999)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3417; H:HE1PR07MB3418.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2ab7207e-d5df-4292-735e-08d521d19b93 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2017 09:10:48.3556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3417 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGebd7t+tq8LpcntQiVuJSW1YGohEZJAYVSlQqUS296FKn7c6h /dPEzNRMV36gRZsxsvyIJqlROWpbltkyVEpMKHWC+RFlkqVLc7sL+u/3PM85vDyHl+KKLpJ+ lEKpplVKeYaEJyBqEzpgq//IQmKY42pARP/dETKiZamIv5cTa2jNiTUaf3PiOEmC3Sl0hkJD q7btOS1Iu/3tIz+7akOuU9fF0aInviWIogCHgz0flyABJcJWBG1GLZ8VLxG0f6ojXYLAZVyo LHZ4kioOzNTqPGIUwaDVxi1BXhQPx0Ob2cBzsQ8+CJPOX25/DY6FOV0/n/UPwPD7eQ7LMqgx lbmZwJvhivka6WIhPgHt1fnuXRGOA6fNSbgY4bUw/7rZPc/FvjDk0LsZMAbj014uy2L4MrZE urohnAw1hTGsvRGKn017xtdDn74UsWzhQ/fnIyzLoE034/EPQcey0d0ecC2CgolLnuVg6Cyw 8lmOAkNhq+fddPjxOJ/PLgyQsFjdSbJBAAx/6CPYoIcE7ZQJsc1oaGgpRBUotO6/QizLYLCq ksdyCNypn+LWuQ/jDd21DsKAiEYkZmjmTGbqjp0yWqVIZpgspUxJq1vRyt94/nAx8BHqn462 IEwhyWqh1LaQKCLlGiYv04KA4kp8hJOvVixhijzvPK3KOqXKyaAZC/KnCImvMNr8LkGEU+Vq Op2ms2nVv5RDeflpUe7Rcy8eiLFjLsjbWjM0O/YHSwsqQqRbQo8fa2Ia7+kN5faw3NLZ+gua VU0ipSZSG7SvXNwTc9kePd78c53e55btJMc507tfk5xiGgy3o6KEBpPorUK6a3R4ccqmPpy4 yaCeiMr6mn0z6E1XVOC41/L362dvGCfjJ8wDkfeTdBKCSZNvD+aqGPlfQXawwBcDAAA= Archived-At: Subject: Re: [rtcweb] Issue with "priority" defined in rtcweb-transports 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, 02 Nov 2017 09:11:00 -0000 Taylor,=0A= =0A= do you have any data associated to this that can be shared?=0A= =0A= It's very easy to get into a discussion where people want knobs for a =0A= lot of things (like min bitrate, desired bitrate, max bitrate, relative =0A= priority, sender queue knob, set DSCP knob, ...), but it would be good =0A= to have some observations/real data to base decisions on.=0A= =0A= --Stefan=0A= =0A= On 11/10/17 19:30, Taylor Brandstetter wrote:=0A= > (Mainly copied from https://github.com/w3c/webrtc-pc/issues/1625)=0A= > =0A= > When defining priority, rtcweb-transports says:=0A= > =0A= > The WebRTC prioritization model is that the application tells the=0A= > WebRTC endpoint about the priority of media and data that is=0A= > controlled from the API.=0A= > ...=0A= > The priority settings affect two pieces of behavior: Packet send=0A= > sequence decisions and packet markings. Each is described in its own= =0A= > section below.=0A= > =0A= > The sections below are "Local prioritization" and "Usage of Quality of Se= rvice -=0A= > DSCP and Multiplexing". The "local prioritization" section gives this gui= dance:=0A= > =0A= > When an WebRTC endpoint has packets to send on multiple streams that= =0A= > are congestion-controlled under the same congestion control regime,= =0A= > the WebRTC endpoint SHOULD cause data to be emitted in such a way=0A= > that each stream at each level of priority is being given=0A= > approximately twice the transmission capacity (measured in payload= =0A= > bytes) of the level below.=0A= > =0A= > Thus, when congestion occurs, a "high" priority flow will have the= =0A= > ability to send 8 times as much data as a "very-low" priority flow i= f=0A= > both have data to send. This prioritization is independent of the=0A= > media type. The details of which packet to send first are=0A= > implementation defined.=0A= > =0A= > For example: If there is a high priority audio flow sending 100 byte= =0A= > packets, and a low priority video flow sending 1000 byte packets, an= d=0A= > outgoing capacity exists for sending >5000 payload bytes, it would b= e=0A= > appropriate to send 4000 bytes (40 packets) of audio and 1000 bytes= =0A= > (one packet) of video as the result of a single pass of sending=0A= > decisions.=0A= > =0A= > This has two significant issues I can see:=0A= > =0A= > * It only allows ratios of 1:2:4:8. This is not granular enough to be = very=0A= > useful. Especially when balancing transmission capacity between audi= o tracks=0A= > and video tracks; in practice it's common for video tracks to use mu= ch more=0A= > than 8 times the bitrate of audio tracks.=0A= > * A single enum is used for both relative bitrate and relative QoS pri= ority.=0A= > But in my experience it's common for an application to want a flow t= hat uses=0A= > /less/ bitrate to have a /higher/ QoS priority. This may even be the= =0A= > /more/ common situation.=0A= > =0A= > So, why do we have one enum for both things? I'd propose defining the pri= ority=0A= > as something that only impacts the priority in network queues (QoS-level= =0A= > priority and SCTP priority, as previously discussed), and use something e= lse to=0A= > control the relative bitrate allocation.=0A= > =0A= > For example, a floating point value attached to each=0A= > |RTCEncodingParameters| (say, |relativeCapacity|), where an encoding with= twice=0A= > the |relativeCapacity| of another encoding will be given twice the transm= ission=0A= > capacity. If implementations can handle ratios of 1:2:4:8, I don't see an= y=0A= > reason why they shouldn't be able to handle arbitrary ratios.=0A= > =0A= =0A= From nobody Mon Nov 6 06:27:30 2017 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 07BA713FC21 for ; Mon, 6 Nov 2017 06:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 V-vJlE4XHWji for ; Mon, 6 Nov 2017 06:27:28 -0800 (PST) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (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 0F4AA13F3D5 for ; Mon, 6 Nov 2017 06:27:28 -0800 (PST) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 11B53252EC for ; Mon, 6 Nov 2017 09:27:25 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id CC0A625249 for ; Mon, 6 Nov 2017 09:27:24 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.62.96] ([UNAVAILABLE]. [128.107.241.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 06 Nov 2017 09:27:25 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Mon, 6 Nov 2017 06:28:09 -0800 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] review of draft-ietf-rtcweb-security-09 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, 06 Nov 2017 14:27:29 -0000 This document looks done to me. From nobody Mon Nov 6 06:29:17 2017 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 BD57E13FC28 for ; Mon, 6 Nov 2017 06:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 5rUSdz8ohEwk for ; Mon, 6 Nov 2017 06:29:15 -0800 (PST) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (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 E1D7113F3D5 for ; Mon, 6 Nov 2017 06:29:14 -0800 (PST) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 4F2EA25166 for ; Mon, 6 Nov 2017 09:29:14 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp23.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 1472A2516A for ; Mon, 6 Nov 2017 09:29:13 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.62.96] ([UNAVAILABLE]. [128.107.241.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 06 Nov 2017 09:29:14 -0500 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <85C5A635-278F-4178-93C8-CF88E8E909C0@iii.ca> Date: Mon, 6 Nov 2017 06:30:02 -0800 To: RTCWeb IETF Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [rtcweb] Review of draft-ietf-rtcweb-security-arch-13 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, 06 Nov 2017 14:29:16 -0000 I think this draft is done -- few trivial things. At this point, I think we should just remove Appendix A as I don't think = it adds much values. All the key parts are actually in the main text. = I'm also can live with just keeping it as is but removing the TODO at = the top of the section as I think that TODO was take care of by the = changes from -12 to -13. The refs to draft-muthu-behave-consent-freshness should be to RFC7675 At the end of section 5.5, there is mention of a NULL cipher in an = example. I don't think that is allowed and thought is not a problem the = way it is mentioned here, perhaps it should be removed from the example.=20= (yes ... I realize the state this is in in the data tracker but none the = less that my comments) From nobody Mon Nov 6 14:55:56 2017 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 26E3F13FB1C for ; Mon, 6 Nov 2017 14:55:55 -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 t-eG7FKEXFkb for ; Mon, 6 Nov 2017 14:55:53 -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 64B9213F698 for ; Mon, 6 Nov 2017 14:55:53 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id b15so13059563qkg.9 for ; Mon, 06 Nov 2017 14:55:53 -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=/WiInzICkOOUvzCyFHaz05gsESe00RbK/XDRRjVDRZU=; b=l3jTZ1OKWMRheObPgvhpX961LgiKpCTNuHZPoBHqisXmgHTwWon+lNcH1yOjDWSnVb BUssJ2usoJ+3o33QvKP/we/zneLVNFy6dqSSCjKKuOWQPyEtXk5uv+/iJ4eWWcuuo0mk VRcYxi8S2UDAog5pgFs5fEWAWCgJ4SibaEiiw= 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=/WiInzICkOOUvzCyFHaz05gsESe00RbK/XDRRjVDRZU=; b=A8dqnEvWTpqiZ8VQNghB1kJzKAhdMpD+WzzULIZyKi8Pd9aDtR3hBZmz65+YoLSnp2 q6/s7lmKRxBHBqI2T6t9xaY4Kga1Y2a4ghb+AngkHA3LeAxuePCtlEdzPsHllUitXPuG Oz6Hbo7iJw5ebZTprjIgkqJNFXqJfTZ27o3+SQw+S4SF3BhpjbLBj8OaNM0kjKUF7QvH vlj1jpqPOKWfXawd7VJ2tJJy+/kYID3PX+nKp4GdV2tp8M6svdq1AF5px+XmhH1A8pi0 C2cHAPCeTuMj1gzK5ZmS7++8QrY4eC/E+GAvmK9PxyBc+xmNsXM8ATb/906EcxlY5Mlm BBvw== X-Gm-Message-State: AJaThX5zOGLb6znb1veXE4JioqphCef5lvxfpOdoDnPiUmNw8XSlLEFg p5c91TDl+Deymmc1E7kXfzjHS1ivy5o= X-Google-Smtp-Source: ABhQp+QMUxZkpS4YKPwi1aS+h/9ab/P2oYnh9LOKRiR76CpEePisD4xbe7Fo8qavM2CCMcH57CoV6w== X-Received: by 10.55.212.80 with SMTP id l77mr24497697qki.82.1510008952516; Mon, 06 Nov 2017 14:55:52 -0800 (PST) Received: from [172.16.0.18] ([96.231.220.27]) by smtp.gmail.com with ESMTPSA id i27sm9347965qtc.91.2017.11.06.14.55.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 14:55:51 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sean Turner In-Reply-To: <85C5A635-278F-4178-93C8-CF88E8E909C0@iii.ca> Date: Mon, 6 Nov 2017 17:55:51 -0500 Cc: RTCWeb IETF Content-Transfer-Encoding: quoted-printable Message-Id: <33629DB7-4599-45C1-9022-B41CA6C89500@sn3rd.com> References: <85C5A635-278F-4178-93C8-CF88E8E909C0@iii.ca> To: Cullen Jennings X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-security-arch-13 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, 06 Nov 2017 22:55:55 -0000 I=E2=80=99ll convert this to issues in GH. spt > On Nov 6, 2017, at 09:30, Cullen Jennings wrote: >=20 > I think this draft is done -- few trivial things. >=20 > At this point, I think we should just remove Appendix A as I don't = think it adds much values. All the key parts are actually in the main = text. I'm also can live with just keeping it as is but removing the TODO = at the top of the section as I think that TODO was take care of by the = changes from -12 to -13. >=20 > The refs to draft-muthu-behave-consent-freshness should be to RFC7675 >=20 > At the end of section 5.5, there is mention of a NULL cipher in an = example. I don't think that is allowed and thought is not a problem the = way it is mentioned here, perhaps it should be removed from the example.=20= >=20 > (yes ... I realize the state this is in in the data tracker but none = the less that my comments) >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb From nobody Fri Nov 10 07:36:38 2017 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 88E59126CC4 for ; Fri, 10 Nov 2017 07:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-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 RDYsN4EVDpSY for ; Fri, 10 Nov 2017 07:36:36 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 0366E126C3D for ; Fri, 10 Nov 2017 07:36:35 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id d43so1572690qte.13 for ; Fri, 10 Nov 2017 07:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=2tUmcrK85Ut+UmyYC9/B2gnK2io0L4hJvzOuPMlcc+o=; b=T3CNM3s7lP3cDJE6/L6OsEn93iZq/1ZI2cgpp+gRpVzDosaWJBQ7VQmkrDgY/mHVSW F1AVxtyLX8MMDVvjCuJ2fO8hGPVqu1bpIXaKKvcUqPuc/SQDfQhuFBP8e+iDhz6ruDS6 mx4ZkrijjTaHRpPbz+Uk7EvH7+fH/rZcrVHMet7q/4+X+BfiMMa4y0zUtdb1PjPkfJtv ZPZiyZKE/dBr+tfVGeEHwyY3LLhMLjVWj84C+S0kMq4alIORfDc1hhU5lca+uTbf1bo2 W3LavgslXyC/2uU0qsasYTOPK0r9ZdibROr1N3Id2voioB2ba01czXtp8FE44zqYsNcv 36ow== 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; bh=2tUmcrK85Ut+UmyYC9/B2gnK2io0L4hJvzOuPMlcc+o=; b=PVvjEfTigbrIE8QVWtYYBLhPAat5scpSsuPI5PJ04DJLnJ3pqrMRJoAw6tlM0NIG6X AhvMl/Kga/8oQmyabcx15oBxvgC8azU9ZP5ue6A/YGjvr0p0rDYY9kpZ+YCP5T0VETTC IWoDXY32KeBtAWDm2uesSMm/Ye9fc6MvbEgKSj+MRtlMq/6iOcSHBWYCNScmfleILYsi ssWJQmVjo+vrixuwfJ4K8LS3pBVMYTq7a4pijDeBXPzsKP5u4vOAqrOa3PVp3D/zBu2p nU/DIOs5uvgNs2Xc/PSdSGX9WJ7b0V+4FoX9k3AmpY0FKuh3Ng2ElH9dyTHd/mhr0LoR i6yw== X-Gm-Message-State: AJaThX74s2wXqVqHULt7gaunyg17WgS8HE4Y2nIhQuuIKBzUNENvgBZI dA83l5mLdb7OUTeS5W+xw8MTY/nOBjTVd2wodnf/xg== X-Google-Smtp-Source: AGs4zMb3DLeaHy47vsrdMRMhWDogHLKHqGiylVNMLr2qR5iIQJzpOgDsGH8j8k5h5TFRqEtqXQmk2W7MpiYFa2yCL/E= X-Received: by 10.200.3.210 with SMTP id z18mr1219963qtg.26.1510328194869; Fri, 10 Nov 2017 07:36:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.248 with HTTP; Fri, 10 Nov 2017 07:36:34 -0800 (PST) In-Reply-To: <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> From: James Pearce Date: Fri, 10 Nov 2017 15:36:34 +0000 Message-ID: To: RTCWeb IETF Content-Type: multipart/alternative; boundary="f4030435cd688cbc63055da2af4e" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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: Fri, 10 Nov 2017 15:36:37 -0000 --f4030435cd688cbc63055da2af4e Content-Type: text/plain; charset="UTF-8" Hi All, Apologies for resurrecting this topic from August. Has anything been decided regarding this? Has it been rolled into other changes, or is it still being considered? Many thanks, James On 1 September 2017 at 14:57, Cullen Jennings wrote: > > > On Aug 23, 2017, at 3:06 PM, James Pearce wrote: > > > > > > The obvious solution seems to be to change the behaviour of mode 2. > Rather than using the default route in all cases, we should use the route > that was used to fetch the origin. This seems to resolve both the usability > and privacy concerns without reducing existing security. > > I agree this is a significant problem and your proposal does seems like a > better solution that the current text. We should get people to think about > the implications of that change. > > > --f4030435cd688cbc63055da2af4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,=C2=A0

Apologies for resurrectin= g this topic from August. Has anything been decided regarding this? Has it = been rolled into other changes, or is it still being considered?
=
Many thanks,

James

On 1 September 2017 at= 14:57, Cullen Jennings <fluffy@iii.ca> wrote:

> On Aug 23, 2017, at 3:06 PM, James Pearce <james@jamesandjo.com> wrote:
>
>
> The obvious solution seems to be to change the behaviour of mode 2. Ra= ther than using the default route in all cases, we should use the route tha= t was used to fetch the origin. This seems to resolve both the usability an= d privacy concerns without reducing existing security.

I agree this is a significant problem and your proposal does seems l= ike a better solution that the current text. We should get people to think = about the implications of that change.



--f4030435cd688cbc63055da2af4e-- From nobody Sat Nov 11 01:00:04 2017 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 A1C761294B9 for ; Sat, 11 Nov 2017 00:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 V0S0sU6MoZOS for ; Sat, 11 Nov 2017 00:59:55 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFACB12420B for ; Sat, 11 Nov 2017 00:59:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id B58BB7C0DBA for ; Sat, 11 Nov 2017 09:59:52 +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 jpNtbY5Nrx0g for ; Sat, 11 Nov 2017 09:59:52 +0100 (CET) Received: from [IPv6:2001:67c:1232:144:ac32:380b:71db:f30] (unknown [IPv6:2001:67c:1232:144:ac32:380b:71db:f30]) by mork.alvestrand.no (Postfix) with ESMTPSA id 406F37C0D17 for ; Sat, 11 Nov 2017 09:59:50 +0100 (CET) To: rtcweb@ietf.org References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca> <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com> <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com> From: Harald Alvestrand Message-ID: <9b49201a-ac3c-0350-ff9d-abe29dee1bd5@alvestrand.no> Date: Sat, 11 Nov 2017 09:59:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Support for RFC7728 pause indication 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: Sat, 11 Nov 2017 08:59:58 -0000 On 10/31/2017 12:27 PM, Iñaki Baz Castillo wrote: >> Nice. However, the last RTP packet sent before PAUSED may arrive after >> the PAUSED itself. Not sure how to handle that in the receiver side... >> >> When entering the state, the RTP stream sender SHALL send a PAUSED >> indication to all known RTP stream receivers, and SHALL also repeat >> PAUSED in the next two regular RTCP reports, as long as it is then >> still in paused state. > Should be enough to mitigate the issue. > > >> RFC 7728 allows partial implementation, with fine grained control about >> sending/receiving PAUSED indication: >> >> "config" allows for partial implementation of this specification >> according to the different roles in the use-cases section: >> >> 6 The implementation supports sent and received RTP streams being >> paused due to local considerations and thus supports sending >> and receiving PAUSED indications. >> >> 7 The implementation supports and desires to receive PAUSED >> indications for received RTP streams but does not pause or send >> PAUSED indications for sent RTP streams. It does not support >> any other messages defined in this specification. >> >> 8 The implementation supports pausing sent RTP streams and >> sending PAUSED indications for them but does not support >> receiving PAUSED indications for received RTP streams. It does >> not support any other messages defined in this specification. > Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) also > seem easy to implement but, despite being mandatory, better don't send > a TMMBR to Chrome in 2017. Patches welcome. > -- Surveillance is pervasive. Go Dark. From nobody Sat Nov 11 01:29:38 2017 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 D2EA4129462 for ; Sat, 11 Nov 2017 01:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 (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 5DUt6benhemh for ; Sat, 11 Nov 2017 01:29:34 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 6D431129449 for ; Sat, 11 Nov 2017 01:29:34 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id 15so10477547wrb.5 for ; Sat, 11 Nov 2017 01:29:34 -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=l7uS4/5waPBg7FaYlxbYE32ad+qmjSLHfq3OCEao+bY=; b=MX0rx02f2TqxXtw8UJieBb7+PTlFoLANMWqmJCR+JbclV2rmANUJ9n+OaXxp6iktDT 28GdP5ngSPB/PaEp+kxOxuewnqC+dk892WsLjwZtDGXUuBr/hhE7XIo84JOKIdWpRQhT Hr1oijkrpKkWaw7VQxUHnyE4Eih2Tlcq1+vFldrmPiGIc6/1CXMV2oBGNfJlX4mMYrjk pbATJO50y1SSeg85elY7/NP3qea+0+3pS6Pa/UCWKAlRr1vz4SXHdZzMjDSrHeivqVGa YAMDL7WNJMzmAAXrtdHQWlxNmwzgiNm4sNY5ucE5QuzPk3/5Potvn4/5H5jAlXnTSK05 9Yiw== 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=l7uS4/5waPBg7FaYlxbYE32ad+qmjSLHfq3OCEao+bY=; b=aOppPwscPfhi8mGpJgHMzw6LdkgycIp9vmmRi6C+SY8QpUwKjziWa5T1u/C3mCGR73 y93PoM/4plmIqnq6ep5un/7dCboDvfJMoHkBBvIKIwvVQeWCJEKZmJLbigiLT8uTjjwk p5/mQVIoBk/E/4uQ/fvrMfqIlir073/WHrW30haZI3RNFCGs5w0Qk5W/UdHcKJ59XGRp QCOpXxwWzmuxesa5YyOBwWAkRB6VwVYOyAMsB7nCtYV/a/rcr68RVLUQzwsLEn77J7U8 QWgtsUrBaozUPXcx+UvOV3QkvN6pSn+vE0LDbhXFQ2Na7AzrX/w8CEG0+G64gHT2+TPN XOnA== X-Gm-Message-State: AJaThX5xMcnkoW4qWxa+0SLNThfvYO2wlBU5wa0xk9AdQaVvrG4Yg9Vi GUlYn3HRcQ8Zrr0B6SuWoT8C7oXt3captrhG5mO7Kg== X-Google-Smtp-Source: AGs4zMaDySQvh/ivUKnmCkXSpH3r4nQaOlv0NZ/6nZ+H+4lnHK5cyQevCGXD97xoMkn6IlrfuFg286j7T2+muyZEeUA= X-Received: by 10.223.182.158 with SMTP id j30mr2323437wre.242.1510392572923; Sat, 11 Nov 2017 01:29:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.225.6 with HTTP; Sat, 11 Nov 2017 01:29:31 -0800 (PST) Received: by 10.28.225.6 with HTTP; Sat, 11 Nov 2017 01:29:31 -0800 (PST) In-Reply-To: <9b49201a-ac3c-0350-ff9d-abe29dee1bd5@alvestrand.no> References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca> <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com> <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com> <9b49201a-ac3c-0350-ff9d-abe29dee1bd5@alvestrand.no> From: Sergio Garcia Murillo Date: Sat, 11 Nov 2017 10:29:31 +0100 Message-ID: To: Harald Alvestrand Cc: rtcweb@ietf.org Content-Type: multipart/alternative; boundary="f40304388d74c7d317055db1ac93" Archived-At: Subject: Re: [rtcweb] Support for RFC7728 pause indication 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: Sat, 11 Nov 2017 09:29:37 -0000 --f40304388d74c7d317055db1ac93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure thing! But would prefer it to be in the standard, even just as a SHOULD/COULD than only libwebrtc implementation specific. Best regards Sergio El 11/11/2017 10:00, "Harald Alvestrand" escribi=C3= =B3: > On 10/31/2017 12:27 PM, I=C3=B1aki Baz Castillo wrote: > >> Nice. However, the last RTP packet sent before PAUSED may arrive after > >> the PAUSED itself. Not sure how to handle that in the receiver side... > >> > >> When entering the state, the RTP stream sender SHALL send a PAUSED > >> indication to all known RTP stream receivers, and SHALL also repeat > >> PAUSED in the next two regular RTCP reports, as long as it is then > >> still in paused state. > > Should be enough to mitigate the issue. > > > > > >> RFC 7728 allows partial implementation, with fine grained control abou= t > >> sending/receiving PAUSED indication: > >> > >> "config" allows for partial implementation of this specification > >> according to the different roles in the use-cases section: > >> > >> 6 The implementation supports sent and received RTP streams bei= ng > >> paused due to local considerations and thus supports sending > >> and receiving PAUSED indications. > >> > >> 7 The implementation supports and desires to receive PAUSED > >> indications for received RTP streams but does not pause or se= nd > >> PAUSED indications for sent RTP streams. It does not support > >> any other messages defined in this specification. > >> > >> 8 The implementation supports pausing sent RTP streams and > >> sending PAUSED indications for them but does not support > >> receiving PAUSED indications for received RTP streams. It do= es > >> not support any other messages defined in this specification. > > Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) also > > seem easy to implement but, despite being mandatory, better don't send > > a TMMBR to Chrome in 2017. > > Patches welcome. > > > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --f40304388d74c7d317055db1ac93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure thing!

= But would prefer it to be in the standard, even just as a SHOULD/COULD than= only libwebrtc implementation specific.

<= div dir=3D"auto">Best regards
Sergio

El 11/11/2017 10:00, = "Harald Alvestrand" <h= arald@alvestrand.no> escribi=C3=B3:
On 10/31/2017 12:27 PM, I=C3=B1aki Baz Castillo wrot= e:
>> Nice. However, the last RTP packet sent before PAUSED may arrive a= fter
>> the PAUSED itself. Not sure how to handle that in the receiver sid= e...
>>
>>=C2=A0 =C2=A0 When entering the state, the RTP stream sender SHALL = send a PAUSED
>>=C2=A0 =C2=A0 indication to all known RTP stream receivers, and SHA= LL also repeat
>>=C2=A0 =C2=A0 PAUSED in the next two regular RTCP reports, as long = as it is then
>>=C2=A0 =C2=A0 still in paused state.
> Should be enough to mitigate the issue.
>
>
>> RFC 7728 allows partial implementation, with fine grained control = about
>> sending/receiving PAUSED indication:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0"config" allows for partial im= plementation of this specification
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0according to the different roles in the = use-cases section:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 The implementation supports sent= and received RTP streams being
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 paused due to local consideratio= ns and thus supports sending
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and receiving PAUSED indications= .
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A07=C2=A0 The implementation supports and = desires to receive PAUSED
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indications for received RTP str= eams but does not pause or send
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PAUSED indications for sent RTP = streams.=C2=A0 It does not support
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 any other messages defined in th= is specification.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A08=C2=A0 The implementation supports paus= ing sent RTP streams and
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sending PAUSED indications for t= hem but does not support
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 receiving PAUSED indications for= received RTP streams.=C2=A0 It does
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not support any other messages d= efined in this specification.
> Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) al= so
> seem easy to implement but, despite being mandatory, better don't = send
> a TMMBR to Chrome in 2017.

Patches welcome.

>

--
Surveillance is pervasive. Go Dark.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb
--f40304388d74c7d317055db1ac93-- From nobody Sat Nov 11 15:05:34 2017 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 53EFD128B8D for ; Sat, 11 Nov 2017 15:05:33 -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, HTML_MESSAGE=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 lvi4dJVsuLv7 for ; Sat, 11 Nov 2017 15:05:31 -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 A46C7128B4E for ; Sat, 11 Nov 2017 15:05:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 1BE817C3553; Sun, 12 Nov 2017 00:05:29 +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 q39ASko_zVTM; Sun, 12 Nov 2017 00:05:27 +0100 (CET) Received: from [31.133.153.86] (dhcp-9956.meeting.ietf.org [31.133.153.86]) by mork.alvestrand.no (Postfix) with ESMTPSA id 5B2E57C0938; Sun, 12 Nov 2017 00:05:26 +0100 (CET) To: Sergio Garcia Murillo Cc: rtcweb@ietf.org References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <3BFD6388-4A07-4D9C-8F1A-CFBAF0EDB830@iii.ca> <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com> <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com> <9b49201a-ac3c-0350-ff9d-abe29dee1bd5@alvestrand.no> From: Harald Alvestrand Message-ID: Date: Sun, 12 Nov 2017 00:05:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------73DE1A996A395330FA35B04C" Content-Language: en-US Archived-At: Subject: Re: [rtcweb] Support for RFC7728 pause indication 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: Sat, 11 Nov 2017 23:05:33 -0000 This is a multi-part message in MIME format. --------------73DE1A996A395330FA35B04C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/11/2017 10:29 AM, Sergio Garcia Murillo wrote: > Sure thing! > > But would prefer it to be in the standard, even just as a SHOULD/COULD > than only libwebrtc implementation specific. Sorry, I was confused - it's TMMBN that's in the spec (-rtp-usage), PAUSED is not. (PAUSE has two RAND IPR declarations against it, which led to some reluctance to mention it in the past) > > Best regards > Sergio > > El 11/11/2017 10:00, "Harald Alvestrand" > escribi=C3=B3: > > On 10/31/2017 12:27 PM, I=C3=B1aki Baz Castillo wrote: > >> Nice. However, the last RTP packet sent before PAUSED may > arrive after > >> the PAUSED itself. Not sure how to handle that in the receiver > side... > >> > >>=C2=A0 =C2=A0 When entering the state, the RTP stream sender SHAL= L send a > PAUSED > >>=C2=A0 =C2=A0 indication to all known RTP stream receivers, and S= HALL also > repeat > >>=C2=A0 =C2=A0 PAUSED in the next two regular RTCP reports, as lon= g as it > is then > >>=C2=A0 =C2=A0 still in paused state. > > Should be enough to mitigate the issue. > > > > > >> RFC 7728 allows partial implementation, with fine grained > control about > >> sending/receiving PAUSED indication: > >> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0"config" allows for partial implementa= tion of this > specification > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0according to the different roles in th= e use-cases section: > >> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A06=C2=A0 The implementation supports se= nt and received RTP > streams being > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 paused due to local considerat= ions and thus supports > sending > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and receiving PAUSED indicatio= ns. > >> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A07=C2=A0 The implementation supports an= d desires to receive PAUSED > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 indications for received RTP s= treams but does not > pause or send > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PAUSED indications for sent RT= P streams.=C2=A0 It does not > support > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 any other messages defined in = this specification. > >> > >>=C2=A0 =C2=A0 =C2=A0 =C2=A08=C2=A0 The implementation supports pa= using sent RTP streams and > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sending PAUSED indications for= them but does not support > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 receiving PAUSED indications f= or received RTP > streams.=C2=A0 It does > >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not support any other messages= defined in this > specification. > > Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) a= lso > > seem easy to implement but, despite being mandatory, better > don't send > > a TMMBR to Chrome in 2017. > > Patches welcome. > > > > > -- > Surveillance is pervasive. Go Dark. > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --=20 Surveillance is pervasive. Go Dark. --------------73DE1A996A395330FA35B04C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 11/11/2017 10:29 AM, Sergio Garcia Murillo wrote:
Sure thing!

But would prefer it to be in the standard, even just as a SHOULD/COULD than only libwebrtc implementation specific.

Sorry, I was confused - it's TMMBN that's in the spec (-rtp-usage), PAUSED is not.

(PAUSE has two RAND IPR declarations against it, which led to some reluctance to mention it in the past)



Best regards
Sergio

El 11/11/2017 10:00, "Harald Alvestrand" <harald@alvestrand.no> escribió:
On 10/31/2017 12:27 PM, Iñaki Baz Castillo wrote:
>> Nice. However, the last RTP packet sent before PAUSED may arrive after
>> the PAUSED itself. Not sure how to handle that in the receiver side...
>>
>>    When entering the state, the RTP stream sender SHALL send a PAUSED
>>    indication to all known RTP stream receivers, and SHALL also repeat
>>    PAUSED in the next two regular RTCP reports, as long as it is then
>>    still in paused state.
> Should be enough to mitigate the issue.
>
>
>> RFC 7728 allows partial implementation, with fine grained control about
>> sending/receiving PAUSED indication:
>>
>>       "config" allows for partial implementation of this specification
>>       according to the different roles in the use-cases section:
>>
>>       6  The implementation supports sent and received RTP streams being
>>          paused due to local considerations and thus supports sending
>>          and receiving PAUSED indications.
>>
>>       7  The implementation supports and desires to receive PAUSED
>>          indications for received RTP streams but does not pause or send
>>          PAUSED indications for sent RTP streams.  It does not support
>>          any other messages defined in this specification.
>>
>>       8  The implementation supports pausing sent RTP streams and
>>          sending PAUSED indications for them but does not support
>>          receiving PAUSED indications for received RTP streams.  It does
>>          not support any other messages defined in this specification.
> Cool. Let's see how things go. BTW, TMMBR and TMMBN (2008 spec) also
> seem easy to implement but, despite being mandatory, better don't send
> a TMMBR to Chrome in 2017.

Patches welcome.

>

--
Surveillance is pervasive. Go Dark.

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


-- 
Surveillance is pervasive. Go Dark.
--------------73DE1A996A395330FA35B04C-- From nobody Sat Nov 11 22:05:17 2017 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 1915112711E; Sat, 11 Nov 2017 22:05:15 -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.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151046671503.30868.12550385666132978224@ietfa.amsl.com> Date: Sat, 11 Nov 2017 22:05:15 -0800 Archived-At: Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-overview-19.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: Sun, 12 Nov 2017 06:05:15 -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 : Overview: Real Time Protocols for Browser-based Applications Author : Harald T. Alvestrand Filename : draft-ietf-rtcweb-overview-19.txt Pages : 24 Date : 2017-11-11 Abstract: This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". It intends to serve as a starting and coordination point to make sure all the parts that are needed to achieve this goal are findable, and that the parts that belong in the Internet protocol suite are fully specified and on the right publication track. This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. This document is a work item of the RTCWEB working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-rtcweb-overview-19 https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-overview-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-overview-19 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 Sun Nov 12 17:01:37 2017 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 A85F6126D85; Sun, 12 Nov 2017 17:01:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , adam@nostrum.com, rtcweb-chairs@ietf.org, Sean Turner , rtcweb@ietf.org, draft-ietf-rtcweb-overview@ietf.org, sean@sn3rd.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <151053488868.21470.10505586128003365879.idtracker@ietfa.amsl.com> Date: Sun, 12 Nov 2017 17:01:28 -0800 Archived-At: Subject: [rtcweb] Protocol Action: 'Overview: Real Time Protocols for Browser-based Applications' to Proposed Standard (draft-ietf-rtcweb-overview-19.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: Mon, 13 Nov 2017 01:01:29 -0000 The IESG has approved the following document: - 'Overview: Real Time Protocols for Browser-based Applications' (draft-ietf-rtcweb-overview-19.txt) as Proposed Standard This document is the product of the Real-Time Communication in WEB-browsers Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ Technical Summary This document gives an overview and context of a protocol suite intended for use with real-time applications that can be deployed in browsers - "real time communication on the Web". This document is an Applicability Statement - it does not itself specify any protocol, but specifies which other specifications WebRTC compliant implementations are supposed to follow. Working Group Summary The document did not, itself, have an particularly controversial aspects, although some of the referenced documents did. There was some debate among the WG chairs regarding whether sending this document to the IESG before all of the documents it referenced had also been sent on. Ultimately, they decided to move it forward once the WG considered it finished. It is worth noting that the documents on which it relies are broadly considered stable at this time. Document Quality The general WebRTC protocols that are referenced by this document are implemented to varying degrees by several major browsers (including Chrome, Edge, Firefox, Opera, and preview editions of Safari). Further, many non-browser implementations (as that term is defined in this document) exist, including the widely-deployed Asterisk PBX, Cisco's WebEx, and the MeetEcho service used for remote participation in IETF meetings. Personnel Sean Turner is the document shepherd. Alissa Cooper was the responsible AD prior to IETF 98. The current responsible AD is Adam Roach. IESG Note This document forms a portion of RFC Editor Cluster 238. From nobody Sun Nov 12 18:24:28 2017 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 D9257126DFF for ; Sun, 12 Nov 2017 18:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 gtLI7F8ssZaO for ; Sun, 12 Nov 2017 18:24:26 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 363DD1241F5 for ; Sun, 12 Nov 2017 18:24:26 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id i5so10814611pfe.6 for ; Sun, 12 Nov 2017 18:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=Cek9qJni5yNzmO5nWjV//Rexxlhxq+8II76uIIIyUBI=; b=GMzM9GZwVGMRPM1BFb4q7PDqpPoIa03SkLjVz2pn4c4qHh9mFNR41MqAK7aCa20cxE VMdAaeoc/fmCCbuY4X2cm4IThJlwz37uj4ov9bFG0KUFBqsCZJDXuAnvasdW/K4Wl9Ih uKtYkrQbehd3mlXDDEf+xzPqqmwarIoQuB1K0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=Cek9qJni5yNzmO5nWjV//Rexxlhxq+8II76uIIIyUBI=; b=hmYHol+WgIwPu/lRq9t5UMo7abS2lwxH6rKjXk5m2YdOm9DJbBmsU+C21mkzEiBYFV bF33umLcuQ+B4BebvNEUuGs2Jk1oNQ9Sh0jaDzRiKMMfFPP8AckPGwwB348fBeE0aZN4 llz4D35US75+mmswlnuSrktHkY2Opjhp0vLB2dEqs7yd4ta51CyJ7ltJZP46Ip5cuS0J /O3wHGRxEwelTXJEjK1EMW49GieQT8YyAx0do/M0Etqrk45ERuyfAtufp6/GheDTPj/I ZU84SaKvjsua02JYFZZ0M5a4HhYJP0y+6Y2rWFGr3aS00Xw44ae/+3GSx+b1/hn79HSQ +y6g== X-Gm-Message-State: AJaThX64cGbOabcXWl/MygrXGgWDl4mV8Uy+oEtRhlVq4iP5/5wXWnTm ksohyxW0RssWGLc9FtVxWqYhOqyBbgM= X-Google-Smtp-Source: AGs4zMZ2TYbzWu0GEoWwjzOHQeNnY8sXPV1SftTnI9/cUclrFMOSssNq1FmMPbQSu8BU7zH+8ReCHg== X-Received: by 10.84.248.135 with SMTP id q7mr7375586pll.79.1510539865232; Sun, 12 Nov 2017 18:24:25 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:d812:96c4:d2c4:31e6? ([2001:67c:1232:144:d812:96c4:d2c4:31e6]) by smtp.gmail.com with ESMTPSA id 15sm22896585pfm.158.2017.11.12.18.24.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:24:23 -0800 (PST) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_B3047DC4-D62F-4072-8584-4F0F4024C847"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <2785594E-E484-4D22-9859-781D622A6D94@mozilla.com> Date: Mon, 13 Nov 2017 10:23:00 +0800 To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [rtcweb] Review of draft-ietf-rtcweb-sdp 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, 13 Nov 2017 02:24:28 -0000 --Apple-Mail=_B3047DC4-D62F-4072-8584-4F0F4024C847 Content-Type: multipart/alternative; boundary="Apple-Mail=_96E36650-453F-45FA-89DB-BF65AF9BDAF6" --Apple-Mail=_96E36650-453F-45FA-89DB-BF65AF9BDAF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Back at IETF 98 I volunteered to review draft-ietf-rtcweb-sdp. I did share my feedback with the draft authors back in July, but forgot = to make that publicly available. This is the annotated PDF I shared with the authors: = https://ohlmeier.com/ietf/draft-ietf-rtcweb-sdp-04-reviewed.pdf = I believe the authors have addressed my feedback in version 8 of their = draft. Best regards Nils Ohlmeier --Apple-Mail=_96E36650-453F-45FA-89DB-BF65AF9BDAF6 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,

Back at IETF 98 I volunteered to review draft-ietf-rtcweb-sdp.

I did share my feedback with the draft authors back in July, but forgot to make that publicly available.
This is the annotated PDF I shared with the authors: https://ohlmeier.com/ietf/draft-ietf-rtcweb-sdp-04-reviewed.pdf

I believe the authors have addressed my feedback in version 8 of their draft.

Best regards
  Nils Ohlmeier

--Apple-Mail=_96E36650-453F-45FA-89DB-BF65AF9BDAF6-- --Apple-Mail=_B3047DC4-D62F-4072-8584-4F0F4024C847 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+KEFAloJAgQACgkQY2o/VmzJ +KGlERAAtGcL9/wVJbBZUhFsXP/GNmjXZYiRWENUqIl+IvTTw9MYCf9nf2TRrdEb 6qxrHfLnFbud1j55ZQzJlRKIe76C3UV6SfnDaiqGc4RU8+CzDu8s6GfiLJnNDSWx Xybncbd1auy6O8fqKYyxsPW7iB2Ko+AbkweJ5//L+ktiJj0ubp9Oxa4QrwPfUUeX 2zGI8TG/k90Y/bo99rGrmdbZWjRjVWdc9LUM4HAQUjgXpHkfDZVKprr2WhEZJ2FO hg5OcPePWpUvijLT6tErgup5fmJlP6MP5qHp3/z9X/gza45KLbMyf9Sa3f6aSgXh TGSw/zqvQ+trV1fJeEokUhwN3lLwD9IMX1wOL+/ho+6nzvh5wEx1qEywL/KboheO HQoAxVj6izSQDCPI72xhTfLX4najerBiEIIkH+7vA7cZPSkl2BIZIgrJLmUGvO/U oGAtqNRmNG6nrpjLyve3F+Pk8PIrIcSaxDaZZqBcgajNRUKu+hvBNAey/6bq55o/ 2ch/mkDdsV7fT9HWT5ACRgsB9bK/5/OeawDj+06d3Ek4dnX/z7CAGmRQ4tdVwEV5 Se5xzLr1VDxBeIVy24h7+R2S41fnjCQjS9FbADwI6FmLC28+0qlDs1ymVXqNMUHR VzC1Jc1ry5R3w9NFaS6ZKh5f+4nwYcWLj52/u6ZE3ENPnQkWR6E= =Ku0t -----END PGP SIGNATURE----- --Apple-Mail=_B3047DC4-D62F-4072-8584-4F0F4024C847-- From nobody Sun Nov 12 18:37:45 2017 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 B93AA128B4E for ; Sun, 12 Nov 2017 18:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 Zay3DqdQzPkU for ; Sun, 12 Nov 2017 18:37:22 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (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 6FF29128BBB for ; Sun, 12 Nov 2017 18:36:36 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id d28so10841280pfe.2 for ; Sun, 12 Nov 2017 18:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:subject:message-id:date:cc:to; bh=zRRwQqqoWmtDfLk1i2bOFO43TpIYDwsv5qKJRQgVAqc=; b=f4CWy0SV107nt+XloUmdtUVIzXzmA2yUtEoAaJ3aB/S1atd3t0GAxxMqLxVo5gyVYy b+t2qSoq9wBjTFs2XnlNhOHbJYw8ClN69CwwXMRqt78rKj67p+fG6BhAICXN3ROg6gd+ vulccMRJwoRBMVJCyY+JYLVfga74kBjErsnRQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=zRRwQqqoWmtDfLk1i2bOFO43TpIYDwsv5qKJRQgVAqc=; b=P8zZcfDSCaJckxq/0RhdM7WI5BfVElJ5Bp+qDKyhtfG220ehzUWDAB/IqhKIRbvFSA d5neobVkeP4AyfsHFmZHz8RcqOE6rSZta24C0gx3b74gOBXRdgqlb600xkaozIYLTp9V 3cgytnJ0QZJLoFD71jbRKV+E2PSMSSjfnfA9IRFVxbtkmK4TEtpv+ALFEqWw13r4gpL3 Xs6wO0zVfhS7QeORnVlCqVRVGutDyynQ+Iau4mObCykkch1/Y9zRMfcmTi+7Ty962TBM WoUR24gdNnucPxy/SeTP533wt4DkHfbBS6RLbRfy/Tg5lvau2Sstc9aCAjPaMRQsW1TQ 6bCA== X-Gm-Message-State: AJaThX7RzZAvtrPEaTbIZjPfePa3dpxJH3V3yGBs5cHsgO72RAYsNDGu uCcowwRZHVXBoVMdSj3WXh2tfxRvVjA= X-Google-Smtp-Source: AGs4zMY9GY/4R53WnIS/kUbwhrWOGGSHIvIZW5pxxnXIQaakz9c5wDdKFN1fTBlHo+KzoNV9C5uy0Q== X-Received: by 10.98.71.144 with SMTP id p16mr3280522pfi.15.1510540595550; Sun, 12 Nov 2017 18:36:35 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:d812:96c4:d2c4:31e6? ([2001:67c:1232:144:d812:96c4:d2c4:31e6]) by smtp.gmail.com with ESMTPSA id k25sm25781990pgf.62.2017.11.12.18.36.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 18:36:34 -0800 (PST) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_A9E9B6A7-09C2-4730-B612-A5DA90670BDD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: Date: Mon, 13 Nov 2017 10:35:10 +0800 Cc: draft-ietf-rtcweb-sdp@ietf.org To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [rtcweb] Extmap examples in draft-ietf-rtcweb-sdp-08 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, 13 Nov 2017 02:37:24 -0000 --Apple-Mail=_A9E9B6A7-09C2-4730-B612-A5DA90670BDD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, In a quick review of the changes from 07 to 08 I noticed this issue: In several places the draft has 'a=3Dextmap:3 a=3Dextmap:3 ...=E2=80=99 = in examples. This should be replaced just with 'a=3Dextmap:3 ...=E2=80=99. Best regards Nils Ohlmeier --Apple-Mail=_A9E9B6A7-09C2-4730-B612-A5DA90670BDD 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+KEFAloJBN4ACgkQY2o/VmzJ +KFiHw/+KCZPXDLxMcTXfur7lqj5MtCnrRjHyF3ihNx6ySZ7s82b5IxNBcqEsU5y yS+Ac3/3wIpn8hF3x2YBIyqKR3lwH2MTfzxZmiSIRs7f/0VUyK7iBKg25ArFj//j Pw3S5mbh1iHKKPsDMJNZtIY43OHhz/9Xj/w8Scwor7XIzK5li1U2yYUVrR9l8Pv3 7kexmKGKpDcvKRU63aB+u429vFo7b4DumNvVhiYUfS1usXlmIUeRpV/Y/afVkpgA ICSwyo7ByGPp4IQ5JxMPsMVNTjDommN+gBVOyxdTmspfUTNzVKIJ3yA6I/E//NEi XxonkHAWoYDj4XO4tMHwgi0vGihzYmQrwkZFcgYcp3oQ3WDLk5snvKqp/iJA5cud tSyVrPYqf3sYRpTNV/IdhgHW135r38kNwfdWCzzPJCSNLnn81KBL5/1pRwTq14W3 wba1bNdqZkuqmHVkQHJyy9kKbMtW7TqSmVSULAO/IB0lPbyhdODgBWWd5EfwMNG1 Drbsr+Km5MgUcel7csJuf/7kAsCRRpHb/BsgQNs2ke2vgPVgEZ6fjoUUcDdyUJWv x/SjX9Yr3Ma5fx4lejMiW/rQW//p+F1QI3v/Lq+BqQlwDKkNotj8bZ7Anf+4dDdh HaDQzzYZ+tbAjTxNf3PXz3cfEJXvS+lWLtBSyATlKyAe5/5et8A= =/YWE -----END PGP SIGNATURE----- --Apple-Mail=_A9E9B6A7-09C2-4730-B612-A5DA90670BDD-- From nobody Sun Nov 12 21:13:06 2017 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 AC7641279EB; Sun, 12 Nov 2017 21:13:04 -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 7caTXNg8z1-K; Sun, 12 Nov 2017 21:13:03 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 E9A931270AE; Sun, 12 Nov 2017 21:13:02 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id h82so7966561vkf.7; Sun, 12 Nov 2017 21:13:02 -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=e4I9GxtwNvWZRpLLkSTASCFWVBQmKN2CU7KoaVe5pFw=; b=bZlNCr3KPEd870cSlChfDSfD/yNgw7F8HcZD1okudLDkHvx/yVQ/ERCgSKI8yYwsSn D4kpO7vjgN85JQJSMwN7Dap5Mfm52bxdXONV8OLBNgjLT25cq8New0oBiRrmmPi9hW+4 iwOijO9czugagd1dXiY9VsvFERm0QcfRicu7/eSC6Zpd2VajfplzQJXhsel9cohHCA+/ 7UqPr04UPSXH3HEJ9TfBK2esk8QcoUCcD316eGA3xTwB+V3jB8BJj3lArCDhUwJGOifs xP9EtF/MrrZgt4l3R8NX+eGMBmv4/citywAUsyU8jRy/LxAo/5Dxd5z7dgtg01dE8JY8 F6GA== 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=e4I9GxtwNvWZRpLLkSTASCFWVBQmKN2CU7KoaVe5pFw=; b=FtYzIG2RpBTco5KOclzGuaH7N0MAn2aUk0x3NNWqYmZWLSibY736bdgxlkhX9SIvIE WHqU/03zsN1XBTg83Ng07bnqaC1OSEjAEUYcdJz0wo55Z9o9HRFfV4lKIixX9OjyFB05 4J+uEVvsKw8MZm0BHMJHA4idxE0fZYRJqiZq4oaighKwY5z+gfaFpibFPIgbGAisLB1m lWhciYH4mWkH1aKu2Pt+zeekuq1DEEvEtjaWTR9orW0wEN0e8SmGF0HzNuJkY+ScMGeo uISdoqIP3XVFtHh+V2RpXgKJAbw5aOPiAzRfkmOjFGZ6PkArJezpKMY5e6CDokYN2ujo lCFQ== X-Gm-Message-State: AJaThX6stxEakpV+R3lOcHij6MD4s1Jw8hMOJ2gzyREGOZ/ymmfTGlXJ z0ezjNtEylMhXu7bgyqSFaZkYrux6N+IMowCEcs= X-Google-Smtp-Source: AGs4zMaV/yqa/b6lX+nSI/rtJxn1WyOi4UQZdSy0Ki5+mQqCPNULZsNy3m/FWGI90207de4l7nEeRv0jG9csSJWkf0U= X-Received: by 10.31.63.5 with SMTP id m5mr958945vka.105.1510549981972; Sun, 12 Nov 2017 21:13:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.17.108 with HTTP; Sun, 12 Nov 2017 21:13:01 -0800 (PST) In-Reply-To: References: From: Suhas Nandakumar Date: Sun, 12 Nov 2017 21:13:01 -0800 Message-ID: To: Nils Ohlmeier Cc: "rtcweb@ietf.org" , draft-ietf-rtcweb-sdp@ietf.org Content-Type: multipart/alternative; boundary="001a114dd780174ef3055dd65386" Archived-At: Subject: Re: [rtcweb] Extmap examples in draft-ietf-rtcweb-sdp-08 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, 13 Nov 2017 05:13:04 -0000 --001a114dd780174ef3055dd65386 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Nils. I will fix it in the next version; Cheers Suhas On Sun, Nov 12, 2017 at 6:35 PM, Nils Ohlmeier wrote: > Hello, > > In a quick review of the changes from 07 to 08 I noticed this issue: > > In several places the draft has 'a=3Dextmap:3 a=3Dextmap:3 ...=E2=80=99 i= n examples. > This should be replaced just with 'a=3Dextmap:3 ...=E2=80=99. > > Best regards > Nils Ohlmeier > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > --001a114dd780174ef3055dd65386 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Nils. I will fix it in the next version;


Cheers
Suhas

On Sun, Nov 12, 2017 at 6:35 PM, N= ils Ohlmeier <nohlmeier@mozilla.com> wrote:
Hello,

In a quick review of the changes from 07 to 08 I noticed this issue:

In several places the draft has 'a=3Dextmap:3 a=3Dextmap:3 ...=E2=80=99= in examples.
This should be replaced just with 'a=3Dextmap:3 ...=E2=80=99.

Best regards
=C2=A0 Nils Ohlmeier

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

--001a114dd780174ef3055dd65386-- From nobody Mon Nov 13 02:40:26 2017 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 D2952124BFA for ; Mon, 13 Nov 2017 02:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 (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 vSnJ2wzPSrsp for ; Mon, 13 Nov 2017 02:40:23 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 A0026120726 for ; Mon, 13 Nov 2017 02:40:22 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id a2so17752344lfh.11 for ; Mon, 13 Nov 2017 02:40:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=E88EzfpO91b5eaXEtZSIdgn6Y96v6snpPI6+kW60neA=; b=qske/6ZLQ1/SJOzBlwDoN3zu3T77NpVAjcUd6MSMuMwbPeI02pcuBOo76eWZk8IKiB x7QlujCJ4NafyVMhOmX95rBU0xN/1KASNWgDIqkfoTcw9Gb+ogy0Anq0ueq9cNTAw3nF Pm6NXg3AnEtPmPEOJLlO0rW/pqmlVzfmvg0g1E2hdubM4q44EB2z4N2IaFSRAq4cHfjO VkJ+99irexcGjo+kPaBfL6iWasXmWV2dWZVzT4DCMVlbFQ1xtBtj1sMVIb7wEWcuoVUS 6g2pqT2W3t2Q4jcOoy5vh+xRa46tfFaxnT4/CpP2PsQrPYrtR5rCdrUwsW8ozDXb9ru3 npaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=E88EzfpO91b5eaXEtZSIdgn6Y96v6snpPI6+kW60neA=; b=lcvaTdS4C2gw9cwUJef8KmNSsCK1vGAc0nkdGAAt8j5neiwd/s4Gqlv1wo7LRRwM71 I5WcehMLdsE8MjHm+FLc5WzaLPYRAaabvXOkipn9tPFeqZTNuj5PwoFIrwa4MLHxI3Cz +DkKmWlKT4x1kMA+etx8ZzLnYSv9un2h0YBIzJiAc9cYm+BpYC7EyNUBbI+XGEn66VWf ohVBcP+O3OKlZ/d8NxpgJVGcJ8TNTV+0QvKqJljLBGgbLwuXEuEjH8GlkMLfNXOhVPOa LlIVDzpkMu4Y0kMAyp7bB2t+pr8PYQQihBKiHyVqm6v7JVKhE+Aj/Ipdwmf4edYA3NFv IzWw== X-Gm-Message-State: AJaThX7zcwvgZj8fmtDihNe6pZhCNjn9jB3Ytd+0MIXOJot1nJXgH04v QWO5wv+mWNd+mzjb2NoeMJNLQP0ixQ8JX0gZe7R7oA== X-Google-Smtp-Source: AGs4zMZp0g9Zx2drS/lM3ZQu5batohDN1ClVvyGp1SgvOP0WJDQKpFMt0VCPyZHMQ2JUxYrwiLujKyZ3hNEyO01mspI= X-Received: by 10.25.213.12 with SMTP id m12mr2198506lfg.201.1510569620661; Mon, 13 Nov 2017 02:40:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.178.1 with HTTP; Mon, 13 Nov 2017 02:40:20 -0800 (PST) From: Alexandre GOUAILLARD Date: Mon, 13 Nov 2017 18:40:20 +0800 Message-ID: To: "rtcweb@ietf.org" Cc: Jordan Baucke Content-Type: multipart/alternative; boundary="001a11412efca5eb1f055ddae583" Archived-At: Subject: [rtcweb] Webrtc event on the side of IETF'100 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, 13 Nov 2017 10:40:25 -0000 --001a11412efca5eb1f055ddae583 Content-Type: text/plain; charset="UTF-8" Dar all, SingaporeJS is hosting a webrtc theme event after IETF on wednesday 15th. PayPal was nice enough to host the event across the street from IETF. https://www.meetup.com/Singapore-JS/events/244884529/ Anybody interested in mingling with web devs interested in webrt are absolutely welcome to join. Do not hesitate to let me know if you are going so I can make a shout out to every IETF expert for the audience to recognise and go discuss after the short talks. Hoping to see a lot of you there, Dr. Alex for Dan, lorenzo and Jordan. -- Alex. Gouaillard, PhD, PhD, MBA ------------------------------------------------------------------------------------ President - CoSMo Software Consulting, Singapore ------------------------------------------------------------------------------------ sg.linkedin.com/agouaillard - --001a11412efca5eb1f055ddae583 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dar all,

SingaporeJS is hosting a webrt= c theme event after IETF on wednesday 15th. PayPal was nice enough to host = the event across the street from IETF.


Anybody = interested in mingling with web devs interested in webrt are absolutely wel= come to join. Do not hesitate to let me know if you are going so I can make= a shout out to every IETF expert for the audience to recognise and go disc= uss after the short talks.

Hoping to see a lot of = you there,

Dr. Alex for Dan, lorenzo and Jordan.

--
Alex. Go= uaillard, PhD, PhD, MBA
-----------------------------------------------= -------------------------------------
President - CoSMo Software = Consulting, Singapore
-------------------------------------------= -----------------------------------------
--001a11412efca5eb1f055ddae583-- From nobody Mon Nov 13 02:58:46 2017 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 A6A98129485 for ; Mon, 13 Nov 2017 02:58:44 -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 Adsl_gF4N2Bs for ; Mon, 13 Nov 2017 02:58:43 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 9ACEC124BFA for ; Mon, 13 Nov 2017 02:58:42 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id o66so9592656lfg.0 for ; Mon, 13 Nov 2017 02:58:42 -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=xS8lMYlmXzVV8LiTsgO+ZBzg+SrNOOikcqKTvTsdl/0=; b=d+5cjm/WlRSuiIP4SxYABUi8QJoFzgeA86ZY3xa+hJwrhMxs7ZJQC7Sil0EWMEJ8yn RGOYHl0cC6MckBKUIEefpyfiwgOtKhkBlcRQmaTTHZY5WSCUd8T8kiymSi0NIMJssOaB 5wTtH88IK6QLTpW/okrNNz6aBfvGDtoFGZX9Q8Jh1Fhh4svl7Hz//zYHyVoOgFc+/eIe CznHkZAF6QDMkzfBOO241usiu29DnBgvRoDc0qXrDApUmueJfp6zxckq15RRele2w+vG DrETwKm2Oam2lgyx02lvZ4MDcV1dnUk4ioPgwvfziZJ7yFjxGKDGXmI4QkAOS3+jBzNd 7B+g== 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=xS8lMYlmXzVV8LiTsgO+ZBzg+SrNOOikcqKTvTsdl/0=; b=b6ipJDMcEhRdsCB9R57qRluXPjVaGO4dCL8BhJdWXeJrGJ1brgz4emYMJEiFPywMOV fA5H5KjTtWcHlHXZ2ZkP3/C9C38evo5x0xOFtZmqEC4h7xj39+7cH7ibgLR/ISuwx3Nd WwxzB+snOV6eZPsLeFFiELRoYSbtfHoeu0YKP8UTDL5WPGWzil0Fz5d+ldeEyqmfDBy0 JOQdd2Vo0I8Z5Ww0ITAfe83Q2NI6PNlp5jkIcJG2GiKWaeeVS7E7WKPtUX5zQoFDTDr4 R4yndTPclwLqlDQBNrN9xlu86e7cYjHSSk0bm82sCBvjm3o+0Tvu5FmsZCCAXu3te6s4 /K6Q== X-Gm-Message-State: AJaThX6lGgJJAGemCKWDBYZa+Id3WZ8GnYcDTCwyJszALyUA8jiJWlOX Z0HvfpMfV6xCQaavzo7ZTFbx4iiZ X-Google-Smtp-Source: AGs4zMYeJ9MZ9TvannMZT3BLb9JLXgz/agpBHIzNfphaW+Wra1jQNOdK1udYlRkiBPT2jZdaieQGjw== X-Received: by 10.25.83.69 with SMTP id h66mr804139lfb.258.1510570720852; Mon, 13 Nov 2017 02:58:40 -0800 (PST) Received: from [192.168.1.35] (177.red-79-152-171.dynamicip.rima-tde.net. [79.152.171.177]) by smtp.googlemail.com with ESMTPSA id f13sm2830731lfe.69.2017.11.13.02.58.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 02:58:40 -0800 (PST) To: Harald Alvestrand Cc: rtcweb@ietf.org, Cullen Jennings References: <91ddc524-6ef9-c3e1-7db5-eb4c4080bc91@gmail.com> <266e6bdb-20b5-9d98-498e-7ddc2c2379a7@gmail.com> <56b03aad-9d87-4465-0b96-1b9854d07c2a@gmail.com> <1f78b285-a9f3-6135-5e07-b9f72ac24546@gmail.com> <9b49201a-ac3c-0350-ff9d-abe29dee1bd5@alvestrand.no> From: Sergio Garcia Murillo Message-ID: <3be2e78e-1513-beb5-3225-3516ab1a8681@gmail.com> Date: Mon, 13 Nov 2017 11:58:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 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] Support for RFC7728 pause indication 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, 13 Nov 2017 10:58:44 -0000 On 12/11/2017 0:05, Harald Alvestrand wrote: > On 11/11/2017 10:29 AM, Sergio Garcia Murillo wrote: >> Sure thing! >> >> But would prefer it to be in the standard, even just as a >> SHOULD/COULD than only libwebrtc implementation specific. > > Sorry, I was confused - it's TMMBN that's in the spec (-rtp-usage), > PAUSED is not. > > (PAUSE has two RAND IPR declarations against it, which led to some > reluctance to mention it in the past) Yes, Cullen already warmed about this. I have been checking and the patent referenced on first RAND (https://datatracker.ietf.org/ipr/1641/) seems to cover the PAUSE/RESUME request and ACKs for the request, but I fail to find any reference to the unsolicited PAUSED indications sent from RTP sender when doing a local pause (which they happen to be implemented by same RTCP message than PAUSE ACKs). Luckily, I am not a patent expert, so this would have to be confirmed by someone which more knowledge than me on the subject. I can't find any more info on which patents the second one applies to (https://datatracker.ietf.org/ipr/1935/) is there a way to find further information about it? Best regards Sergio From nobody Mon Nov 13 14:04:52 2017 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 B0042126FDC for ; Mon, 13 Nov 2017 14:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 LJIXmAFxOu8U for ; Mon, 13 Nov 2017 14:04:49 -0800 (PST) Received: from smtp81.iad3a.emailsrvr.com (smtp81.iad3a.emailsrvr.com [173.203.187.81]) (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 E7DB7126B7F for ; Mon, 13 Nov 2017 14:04:40 -0800 (PST) Received: from smtp35.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp35.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0DE645B5B; Mon, 13 Nov 2017 17:04:30 -0500 (EST) X-Auth-ID: fluffy@iii.ca Received: by smtp35.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 61B325AA0; Mon, 13 Nov 2017 17:04:29 -0500 (EST) X-Sender-Id: fluffy@iii.ca Received: from [10.24.54.38] ([UNAVAILABLE]. [128.107.241.187]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:587 (trex/5.7.12); Mon, 13 Nov 2017 17:04:30 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_E95D4DCB-D59F-4E98-A962-AA9AAD0D05EE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Mon, 13 Nov 2017 12:05:35 -1000 Cc: RTCWeb IETF Message-Id: References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> To: James Pearce X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 13 Nov 2017 22:04:51 -0000 --Apple-Mail=_E95D4DCB-D59F-4E98-A962-AA9AAD0D05EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My recollection is that we agreed to do this but the draft has not been = updated with this yet.=20 > On Nov 10, 2017, at 5:36 AM, James Pearce = wrote: >=20 > Hi All,=20 >=20 > Apologies for resurrecting this topic from August. Has anything been = decided regarding this? Has it been rolled into other changes, or is it = still being considered? >=20 > Many thanks, >=20 > James >=20 > On 1 September 2017 at 14:57, Cullen Jennings > wrote: >=20 > > On Aug 23, 2017, at 3:06 PM, James Pearce > wrote: > > > > > > The obvious solution seems to be to change the behaviour of mode 2. = Rather than using the default route in all cases, we should use the = route that was used to fetch the origin. This seems to resolve both the = usability and privacy concerns without reducing existing security. >=20 > I agree this is a significant problem and your proposal does seems = like a better solution that the current text. We should get people to = think about the implications of that change. >=20 >=20 >=20 > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_E95D4DCB-D59F-4E98-A962-AA9AAD0D05EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

My recollection is that = we agreed to do this but the draft has not been updated with this = yet. 


On = Nov 10, 2017, at 5:36 AM, James Pearce <james@jamesandjo.com> wrote:

Hi All, 

Apologies for resurrecting this topic from August. Has = anything been decided regarding this? Has it been rolled into other = changes, or is it still being considered?

Many thanks,

James

On 1 = September 2017 at 14:57, Cullen Jennings <fluffy@iii.ca> wrote:

> On Aug 23, 2017, at 3:06 PM, James Pearce <james@jamesandjo.com> wrote:
>
>
> The obvious solution seems to be to change the behaviour of mode 2. = Rather than using the default route in all cases, we should use the = route that was used to fetch the origin. This seems to resolve both the = usability and privacy concerns without reducing existing security.

I agree this is a significant problem and your proposal does = seems like a better solution that the current text. We should get people = to think about the implications of that change.



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

= --Apple-Mail=_E95D4DCB-D59F-4E98-A962-AA9AAD0D05EE-- From nobody Mon Nov 13 23:10:28 2017 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 4B81D129489 for ; Mon, 13 Nov 2017 23:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 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, T_KAM_HTML_FONT_INVALID=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 3PghjwXyMIqU for ; Mon, 13 Nov 2017 23:10:23 -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 E2FFA12947F for ; Mon, 13 Nov 2017 23:10:22 -0800 (PST) X-AuditID: c1b4fb30-df9f99c000002554-f9-5a0a96dca1c7 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 11.18.09556.CD69A0A5; Tue, 14 Nov 2017 08:10:21 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0352.000; Tue, 14 Nov 2017 08:09:26 +0100 From: Christer Holmberg To: Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? - Pull Request Thread-Index: AdNdF4L9xPImCpw8QKKg08JBvmezsQ== Date: Tue, 14 Nov 2017 07:09:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C6A0F33@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B5C6A0F33ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7je7daVxRBnufsFgsvNfKYnF5xUNW i7X/2tkdmD0WbCr1WLLkJ5NH34Eu1gDmKC6blNSczLLUIn27BK6MHzcusxS8W8JUcerrTZYG xhlzmboYOTkkBEwkZrbfYO9i5OIQEjjMKHFjwk9mCGcxo8Ska3eBHA4ONgELie5/2iANIgJF EmeObQFrFhYIkrj+4RoLRDxYYtXi6YwQtp5E87KlYDUsAqoSfedvsYLYvAK+Er+ebgOrZxQQ k/h+ag1YDbOAuMStJ/OhDhKQWLLnPDOELSrx8vE/VghbSWLR7c9Q9fkSt39NhpopKHFy5hOW CYyCs5CMmoWkbBaSsllA3zALaEqs36UPUaIoMaX7ITuErSHROmcuO7L4Akb2VYyixanFSbnp RkZ6qUWZycXF+Xl6eaklmxiBMXJwy2+DHYwvnzseYhTgYFTi4X0/iStKiDWxrLgy9xCjBAez kghvSDBQiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBkY1 JqdDBWqzswPd1msIvVGc9Sa29HxOz87UB+vYZ+qoVFtcbfiaGP+jvVL7h9gsKwZvtTeNf012 RHQ/FP946MVfrkrdYt6NP+SivT+qn0pXYlzp5tJ42Xx/bcbJyzyHz85q143dwLasb96icy0v jyxgfXoz99LiHrOvlRn8l3X/bPq0YR3zC1clluKMREMt5qLiRAAZIknJjQIAAA== Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? - Pull Request 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, 14 Nov 2017 07:10:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B5C6A0F33ESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkl04oCZcyBhIHdoaWxlIHNpbmNlIHdlIGRpc2N1c3NlZCB0aGlzLCBidXQgSSBoYXZl IG5vdyBjcmVhdGVkIGEgUFIgd2hpY2ggdGFsa3MgYWJvdXQgbW92aW5nIG0tIHNlY3Rpb25zIGJl dHdlZW4gQlVORExFIGdyb3VwcywgYW5kIGhvdyBpdCBhZmZlY3RzIHRoZSBCVU5ETEUgYWRkcmVz cy4NCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvcHVsbC80Mw0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAwMSBT ZXB0ZW1iZXIgMjAxNyAxODo1OA0KVG86IEJ5cm9uIENhbXBlbiA8YmNhbXBlbkBtb3ppbGxhLmNv bT47IFRheWxvciBCcmFuZHN0ZXR0ZXIgPGRlYWRiZWVmQGdvb2dsZS5jb20+OyBSVENXZWIgSUVU RiA8cnRjd2ViQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIEFtYmlndWl0aWVzIHdp dGggQlVORExFIHdoZW4gdXNlZCB3aXRoIElDRT8NCg0KSGksDQoNCkhpLA0KDQoNCiAgICAgICBB bHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVsZSB0aGF0IHRoZSB0cmFuc3BvcnQNCg0K Zm9sbG93cw0KDQp0aGUNCg0KYnVuZGxlLCB3aGF0IGFib3V0IHRoaXM/DQoNCg0KDQphPWdyb3Vw OkJVTkRMRSBtaWQxIG1pZDINCg0KYT1ncm91cDpCVU5ETEUgbWlkMyBtaWQ0DQoNCg0KDQphbmQg aW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCg0KYT1ncm91cDpC VU5ETEUgbWlkNCBtaWQxDQoNCg0KDQogICAgICAgV2hhdCB0cmFuc3BvcnQgZ29lcyB3aGVyZT8N Cg0KSSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJl IGRvaW5nIGFib3ZlDQoNCmlzDQoNCm1vdmluZyBzdHJlYW1zIGZyb20gb25lIEJVTkRMRSBncm91 cCB0byBhbm90aGVyLCBhbmQgbWl4aW5nIHRoZQ0KDQpCVU5ETEUNCg0KZ3JvdXBzIHVwLCBhbmQg SSBkb27CuXQgdGhpbmsgdGhhdMK5cyBhIGdvb2QgaWRlYS4NCg0KDQoNClJlZ2FyZHMsDQoNCg0K DQpDaHJpc3Rlcg0KDQogICAgICBJZiB5b3Ugd2FudCB0byBjbGFzc2lmeSB0aGlzIGFzIGEgYmFk IGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlDQoNCmxhbmd1YWdlIGZvcmJpZGRpbmcgaXQuIEZvciBp bnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBpcw0KDQpwbGFjZWQNCg0KaW4gYSBidW5k bGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUgaXQgaXMgdG8gZGlzYWJsZSBpdCwgYXMgd2VsbCBh cyBhDQoNCnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dpbmc6DQoNCg0KDQphPWdyb3VwOkJVTkRM RSBtaWQyIG1pZDMNCg0KYT1taWQ6IG1pZDEgPC0tLSBub3QgYnVuZGxlZA0KDQouLi4NCg0KYT1t aWQ6IG1pZDINCg0KLi4uDQoNCmE9bWlkOiBtaWQzDQoNCg0KDQphbmQgaW4gYSByZW9mZmVyDQoN Cg0KDQphPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQoNCg0KDQogICAgICBXZSB3b3VsZCBuZWVkIHRv IGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEncywgb3INCg0KdGhlDQoN CmJ1bmRsZSdzLiBPciBwZXJoYXBzIGEgcnVsZSBmb3JiaWRkaW5nIHByZXZpb3VzbHkgdW5idW5k bGVkIG1pZHMgdG8NCg0KYmUNCg0KYWRkZWQgdG8gYSBidW5kbGUuDQoNCkkgdGhpbmsgdGhpcyBp cyBjb3ZlcmVkIGluIHNlY3Rpb24gOC41LjIgKEFkZGluZyBhIG1lZGlhIGRlc2NyaXB0aW9uDQoN CnRvDQoNCmENCg0KQlVORExFIGdyb3VwKSBvZiBCVU5ETEUuDQoNCg0KDQpBc3N1bWluZyB5b3Ug YXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9mIHRoZSBtaWQxIG0tbGluZSwgeW91DQoN CmFyZQ0KDQpzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCAo Zmlyc3QgYnVsbGV0IGluDQoNCnNlY3Rpb24NCg0KOC41LjIpLg0KDQogICAgIFJpZ2h0LCB0aGUg b2ZmZXJlciBoYXMgdGhlIGNob2ljZSBvZiByZXRhaW5pbmcgbWlkMSdzIHRyYW5zcG9ydCwNCg0K b3INCg0Ka2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFjY29yZGluZyB0byA4LjUu Mi4gSWYgd2UgZG9uJ3QgZG8NCg0Kc29tZXRoaW5nIGxpa2UgYWRkaW5nIHVmcmFnIHRvIHRoZSB0 cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjINCg0Kd291bGQgaGF2ZSB0byBiZSB0aWdo dGVuZWQgc2lnbmlmaWNhbnRseS4gQWdhaW4sIG91ciB0d28gY2hvaWNlcyBoZXJlOg0KDQoNCg0K MS4gRmluZCBhIHdheSB0byBhbGxvdyBhbiBJQ0Ugb2ZmZXJlciB0byBpbmRpY2F0ZSB3aGF0IHRy YW5zcG9ydHMgaXQgaXMNCg0KcmV0YWluaW5nIChlZzsgdWZyYWcpLg0KDQpZb3UgZG8gdGhhdCB1 c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuDQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1p ZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0DQoNCm9mDQoN Cm1pZDEgKHJlYWQ6IHlvdSBhcmUgc3VnZ2VzdGluZyBhIG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBC VU5ETEUgZ3JvdXApDQoNCg0KDQphPWdyb3VwOkJVTkVMRSBtaWQyIG1pZDMgbWllMSBtZWFucyB0 aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0DQoNCm9mDQoNCm1pZDIgKHJlYWQ6IGtl ZXAgdGhlIGV4aXN0aW5nIEJVTkRMRSBncm91cCB0cmFuc3BvcnQpLg0KDQoNCg0KTm93LCBpZiB5 b3UgSU4gQURESVRJT04gdG8gdGhhdCB3YW50cyB0byBpbmRpY2F0ZSBzb21ldGhpbmcgSUNFDQoN CnNwZWNpZmljLA0KDQplLmcsIHdoZXRoZXIgdG8gZG8gYW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3Mg eW91IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC4NCg0KQnV0LCBJIGRvbsK5dCB0aGluayB0aGF0 IGlzIEJVTkRMRSBzcGVjaWZpYywgaXMgaXQ/DQoNCiAgICBPaywgc28gd2hhdCB5b3UgYXJlIGRl c2NyaWJpbmcgaXMgInRyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiIuDQoNCkJ1dCB0aGUgYnVu ZGxlIHNwZWMgZG9lc24ndCBfcXVpdGVfIGd1YXJhbnRlZSB0aGlzIHJpZ2h0IG5vdywgYW5kIGl0 DQoNCnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3VhcmFudGVlIGl0IGVpdGhlci4gRm9yIGlu c3RhbmNlLCA4LjUuMQ0KDQpkZXNjcmliZXMgaG93IHRoZSBvZmZlcmVyIGNhbiBzdWdnZXN0IGEg bmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1bmRsZSwNCg0KYW55IHRpbWUgaXQgd2FudHMgKGFuZCBp dCBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIHByZS1leGlzdGluZyB0cmFuc3BvcnQNCg0KInN0b2xl biIgZnJvbSBzb21lIG90aGVyIGJ1bmRsZS9tLXNlY3Rpb24hKTsgd2l0aG91dCB0YWtpbmcgc29t ZXRoaW5nDQoNCmxpa2UgdWZyYWcgaW50byBhY2NvdW50LCB0aGlzIGlzIGltcG9zc2libGUgdG8g ZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS4NCg0KVGhlIEJVTkRMRSBncm91cHMgY2FuIG5vdCB1c2Ug dGhlIHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25lIGlzIHRyeWluZw0KDQp0byBvZmZlciBz dWNoIHRoaW5nIHRoZSBhbnN3ZXJlciBzaG91bGQgcmVqZWN0IHRoZSBvZmZlciwgb3IgYXQgbGVh c3Qgbm90DQoNCmFjY2VwdCB0aGUgb2ZmZXJlZCB0cmFuc3BvcnRzLg0KDQoNCg0KSG93ZXZlciwg eW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmlnaHQgaW4gc2F5aW5nICJXZWxsLCBkdWgsIHRoYXQg aXMNCg0KdHJ1ZSBmb3Igbm9uLUJVTkRMRSBhbHNvISIsIHdoaWNoIGlzIHdoeSBJIGxpa2UgdGhl IGlkZWEgb2YgZml4aW5nIHRoaXMNCg0Kd2l0aCB1ZnJhZywgc2luY2UgdGhhdCdzIGhvdyB3ZSBt YWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBjYXNlLg0KDQpJIGd1ZXNzIEkgc3RpbGwg aGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUgcHJvYmxlbSBpcy4NCg0K DQoNCkxldOKAmXMgdGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGU6DQoNCg0KDQpJbml0aWFsIG9m ZmVyL2Fuc3dlciBleGNoYW5nZToNCg0KDQoNCmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMiBtaWQz DQoNCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2DQoNCg0KDQpOb3csIHlvdSBoYXZlIHR3 byB0cmFuc3BvcnRzOiBvbmUg4oCcb3duZWTigJ0gYnkgbWlkMSBhbmQgb25lIOKAnG93bmVkIiBi eSBtaWQ0Lg0KDQoNCg0KDQoNClJlLW9mZmVyOg0KDQoNCg0KYT1ncm91cDpCVU5ETEUgbWlkNCBt aWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQ1IG1pZDYNCg0KDQoNCg0KDQpJbiB0 aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90IGNoYW5nZSB0aGUgdHJhbnNwb3J0cyBv ZiBtaWQxIGFuZA0KDQptaWQ0IC0gdGhleSBhcmUgc3RpbGwgdGhlIHNhbWUuIFRoZSBkaWZmZXJl bnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGwNCg0Kbm93IHN0YXJ0IHVzaW5nIHRoZSB0cmFu c3BvcnQgb2YgbWlkNCwgYW5kIG1pZDUgYW5kIG1pZDYgd2lsbCBzdGFydCB1c2luZw0KDQp0aGUg dHJhbnNwb3J0IG9mIG1pZDEuDQoNCiAgICBSaWdodCwgYnV0IGFzIGZhciBhcyBJIGNhbiB0ZWxs IHRoZSBidW5kbGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQgdGhpczoNCg0KYT1ncm91cDpCVU5ETEUg bWlkMSBtaWQyIG1pZDMgPC0tLSB1c2VzIHBvcnQgNTU1NQ0KYT1ncm91cDpCVU5ETEUgbWlkNCBt aWQ1IG1pZDYgPC0tLSB1c2VzIHBvcnQgNjY2Ng0KLi4uDQptPWF1ZGlvIDU1NTUgLi4uDQphPW1p ZDptaWQxDQouLi4NCm09dmlkZW8gNjY2NiAuLi4NCmE9bWlkOm1pZDQNCg0KYW5kIHRoZW4gaW4g YSByZW9mZmVyOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDIgbWlkMyA8LS0tIG1pZDQgYW5k IG1pZDEgaGF2ZSBzd2FwcGVkLi4uDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDUgbWlkNg0KLi4u DQptPWF1ZGlvIDY2NjYgLi4uIDwtLS0gYnV0IHRoZSBvZmZlcmVyIGhhcyBleHBsaWNpdGx5IGlu ZGljYXRlZCB0aGF0IDY2NjYgaXMgYXR0YWNoZWQgdG8gbWlkMSBub3cNCmE9bWlkOm1pZDENCi4u Lg0KbT12aWRlbyA1NTU1IC4uLg0KYT1taWQ6bWlkNA0KDQogICAgSWYgdGhlIGJ1bmRsZSBzcGVj IGFsbG93cyB0aGlzLCAidHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uIiBpcyBub3QgcGFydCBv ZiB0aGUgc3BlYzsgdGhlIGZ1bmRhbWVudGFsIHJ1bGUgaXMgInRyYW5zcG9ydCBpcyBzaWduYWxl ZCBleHBsaWNpdGx5IGV2ZXJ5IHRpbWUiLCB3aGljaCBpcyBpbXBvc3NpYmxlIHdpdGggSUNFIHVu bGVzcyB1ZnJhZyBpcyB0YWtlbiBpbnRvIGFjY291bnQuDQoNCg0KTWF5YmUg4oCcdHJhbnNwb3J0 IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdvcmRpbmcuIFRyYW5zcG9ydCBpcyB3aGF0 ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3VwOkJVTkRMRSBhdHRyaWJ1dGUgaW5kaWNh dGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3BvcnQgYWxyZWFkeSBleGlzdHMgdGhlcmUg aXMgbm8gbmVlZCB0byBkbyBhbiBJQ0UgcmVzdGFydC4NCg0KU28sIGluIHlvdXIgZXhhbXBsZSwg aSB0aGUgcmVvZmZlciB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCBtaWQ0LCBtaWQyIGFuZCBtaWQz IHVzZXMgdGhlICI1NTU1IHRyYW5zcG9ydCIuIFNpbmNlIHRoaXMgdHJhbnNwb3J0IGFscmVhZHkg ZXhpc3RzIChpdCB3YXMgcHJldmlvdXNseSB1c2VkIGJ5IG1pZDEsIG1pZDIgYW5kIG1pZDMpLCB5 b3UgZG9u4oCZdCBoYXZlIHRvIGRvIGFuIElDRSByZXN0YXJ0Lg0KDQpSZWdhcmRzLA0KDQpDaHJp c3Rlcg0KDQoNCg0KICAgIFJpZ2h0LiBUaGUgb2ZmZXJlciBleHBsaWNpdGx5IGluZGljYXRlZCB3 aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBpcyBhbWJpZ3VvdXMuIEkgbGlrZSB0aGlz IHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdoeSBJIHByZWZlciBjbGFyaWZ5aW5nIHRo ZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQgc2lnbmFsaW5nIGlzIHVzZWQgaW4gdGhl IElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lmeWluZyByZXN0cmljdGlvbnMgbGlrZSAi dHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uIiB0byBoYW5kbGUgdGhlIElDRSBjYXNlLg0KSSB0 b3RhbGx5IGFncmVlIOKAkyB0aGUgdHJhbnNwb3J0IGhhcyB0byBiZSBleHBsaWNpdGx5IGluZGlj YXRlZC4gQnV0LCBkb27igJl0IHRoZSBJQ0UgU0RQIGF0dHJpYnV0ZXMgYWxyZWFkeSBleHBsaWNp dGx5IGluZGljYXRlIHRoZSB0cmFuc3BvcnQ/DQoNCiAgICBTYWRseSwgbm90IHF1aXRlLCBiZWNh dXNlIHRoZXJlJ3Mgbm8gY2xlYXIgcmVxdWlyZW1lbnQgcmlnaHQgbm93IHRoYXQgdGhlIHVmcmFn IGlzIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQgKGFuZCBpbmRlZWQgaXQgaGFzIG5vdCBi ZWVuIGltcGxlbWVudGVkIHRoYXQgd2F5IGJ5IENocm9tZSBvciBGaXJlZm94KS4gVGhhdCdzIHdo YXQgSSdtIGFkdm9jYXRpbmcgZml4aW5nLCBpbnN0ZWFkIG9mIGFkZGluZyBhIGJ1bmNoIG9mIG5l dyBydWxlcyBmb3IgYnVuZGxlIHdpdGggSUNFLg0KDQpBcyBJIHdyb3RlIGluIG15IGUtbWFpbCBv biBUaHVyc2RheSwgbXkgdW5kZXJzdGFuZGluZyBvZiBSRkMgNTI0NSBpcyB0aGF0IHRoZSB1ZnJh ZyBtdXN0IGJlIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQsIGlmIHlvdSBkbyBhbiBJQ0Ug cmVzdGFydCB5b3UgbXVzdCBjaGFuZ2UgdWZyYWcsIGFuZCBhIGNoYW5nZSBvZiB1ZnJhZyB3aWxs IHRyaWdnZXIgYW4gSUNFIHJlc3RhcnQuLg0KDQpJZiBpbXBsZW1lbnRhdGlvbnMgZG9u4oCZdCBm b2xsb3cgdGhlIHNwZWNzIGl0IGRvZXNu4oCZdCByZWFsbHkgbWF0dGVyIHdoYXQgd2Ugc3BlY2lm eeKApg0KDQoNCiAgICBUaGF0IGNoYW5naW5nIHRoZSB1ZnJhZyBjYXVzZXMgYSB0cmFuc3BvcnQg Y2hhbmdlIGlzIGNsZWFyLCBidXQgdGhlcmUgaXMgcHJlc2VudGx5IG5vIGxhbmd1YWdlIHNheWlu ZyB0aGF0IHlvdSBjYW5ub3Qgc3RhcnQgb3V0IHdpdGggdGhlIHNhbWUgdWZyYWcgZm9yIGV2ZXJ5 IG0tc2VjdGlvbiwgYW5kIHRoaXMgaXMgZnVydGhlciBjb25mdXNlZCBieSB0aGUgZmFjdCB0aGF0 IGljZS11ZnJhZyBpcyBhbGxvd2VkIHRvIGJlIHNlc3Npb24gbGV2ZWwuDQpPaywgSSBoZWFyIHdo YXQgeW91IGFyZSBzYXlpbmcuIFdlIGNhbiBhbHdheXMgbWFuZGF0ZSB1bmlxdWUgdWZyYWcgdmFs dWVzIGluIEJVTkRMRSwgYW5kIG1heWJlIGFsc28gaW4gNTI0NWJpcyAodGhhdCBkaXNjdXNzaW9u IGJlbG9uZ3MgdG8gdGhlIElDRSBXRywgdGhvdWdoKS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0K --_000_7594FB04B1934943A5C02806D1A2204B5C6A0F33ESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy Ng0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXTigJlz IGEgd2hpbGUgc2luY2Ugd2UgZGlzY3Vzc2VkIHRoaXMsIGJ1dCBJIGhhdmUgbm93IGNyZWF0ZWQg YSBQUiB3aGljaCB0YWxrcyBhYm91dCBtb3ZpbmcgbS0gc2VjdGlvbnMgYmV0d2VlbiBCVU5ETEUg Z3JvdXBzLCBhbmQgaG93DQogaXQgYWZmZWN0cyB0aGUgQlVORExFIGFkZHJlc3MuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5j b20vY2RoNHUvZHJhZnQtc2RwLWJ1bmRsZS9wdWxsLzQzIj5odHRwczovL2dpdGh1Yi5jb20vY2Ro NHUvZHJhZnQtc2RwLWJ1bmRsZS9wdWxsLzQzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9h PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPiBydGN3ZWIgW21haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gMDEgU2VwdGVtYmVy IDIwMTcgMTg6NTg8YnI+DQo8Yj5Ubzo8L2I+IEJ5cm9uIENhbXBlbiAmbHQ7YmNhbXBlbkBtb3pp bGxhLmNvbSZndDs7IFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0O2RlYWRiZWVmQGdvb2dsZS5jb20m Z3Q7OyBSVENXZWIgSUVURiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gQW1iaWd1aXRpZXMgd2l0aCBCVU5ETEUgd2hlbiB1c2VkIHdpdGgg SUNFPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOnJlZCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFscmlnaHQsIGlmIHdlIHdhbnQg dG8gd3JpdGUgYSBydWxlIHRoYXQgdGhlIHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PmZvbGxvd3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5idW5kbGUsIHdoYXQgYWJvdXQgdGhpcz88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDI8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQzIG1pZDQ8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW4gYSByZW9mZmVyPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpC VU5ETEUgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlk NCBtaWQxPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoYXQgdHJhbnNwb3J0IGdv ZXMgd2hlcmU/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSB0aGluayBU YXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3Zl PG86cD48L286cD48L3ByZT4NCjxwcmU+aXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5tb3Zpbmcg c3RyZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8gYW5vdGhlciwgYW5kIG1peGluZyB0aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CVU5ETEU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5ncm91 cHMgdXAsIGFuZCBJIGRvbsK5dCB0aGluayB0aGF0wrlzIGEgZ29vZCBpZGVhLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlZ2FyZHMsPG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Q2hyaXN0ZXI8 bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgSWYgeW91IHdhbnQgdG8gY2xhc3NpZnkgdGhpcyBhcyBhIGJhZCBpZGVhLCB3 ZSBuZWVkIG5vcm1hdGl2ZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxhbmd1YWdlIGZvcmJpZGRp bmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBpczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnBsYWNlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmluIGEgYnVuZGxlLCB0 aGUgb25seSB3YXkgdG8gcmVtb3ZlIGl0IGlzIHRvIGRpc2FibGUgaXQsIGFzIHdlbGwgYXMgYTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dpbmc6PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpC VU5ETEUgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1taWQ6IG1pZDEgJmx0Oy0t LSBub3QgYnVuZGxlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPi4uLjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPmE9bWlkOiBtaWQyPG86cD48L286cD48L3ByZT4NCjxwcmU+Li4uPG86cD48L286cD48 L3ByZT4NCjxwcmU+YT1taWQ6IG1pZDM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW4gYSByZW9mZmVyPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cCBtaWQxIG1pZDIgbWlkMzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0 cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEncywgb3I8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50 aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5idW5kbGUncy4gT3IgcGVyaGFwcyBhIHJ1bGUgZm9y YmlkZGluZyBwcmV2aW91c2x5IHVuYnVuZGxlZCBtaWRzIHRvPG86cD48L286cD48L3ByZT4NCjxw cmU+YmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hZGRlZCB0byBhIGJ1bmRsZS48bzpwPjwvbzpw PjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5JIHRoaW5rIHRoaXMgaXMgY292ZXJlZCBpbiBz ZWN0aW9uIDguNS4yIChBZGRpbmcgYSBtZWRpYSBkZXNjcmlwdGlvbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnRvPG86cD48L286cD48L3ByZT4NCjxwcmU+YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PkJVTkRMRSBncm91cCkgb2YgQlVORExFLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzc3VtaW5nIHlvdSBhcmUgbm90IGNoYW5naW5nIHRoZSB0 cmFuc3BvcnQgb2YgdGhlIG1pZDEgbS1saW5lLCB5b3U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h cmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3Ig dGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluPG86cD48L286cD48L3ByZT4NCjxwcmU+ c2VjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjguNS4yKS48bzpwPjwvbzpwPjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUmlnaHQsIHRoZSBv ZmZlcmVyIGhhcyB0aGUgY2hvaWNlIG9mIHJldGFpbmluZyBtaWQxJ3MgdHJhbnNwb3J0LDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPm9yPG86cD48L286cD48L3ByZT4NCjxwcmU+a2VlcGluZyB0aGUg b2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFjY29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG88 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zb21ldGhpbmcgbGlrZSBhZGRpbmcgdWZyYWcgdG8gdGhl IHRyYW5zcG9ydCBjb21wYXJpc29uIHJ1bGVzLCA4LjUuMjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PndvdWxkIGhhdmUgdG8gYmUgdGlnaHRlbmVkIHNpZ25pZmljYW50bHkuIEFnYWluLCBvdXIgdHdv IGNob2ljZXMgaGVyZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4xLiBGaW5kIGEgd2F5IHRvIGFsbG93IGFuIElDRSBvZmZlcmVyIHRvIGluZGlj YXRlIHdoYXQgdHJhbnNwb3J0cyBpdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJldGFpbmlu ZyAoZWc7IHVmcmFnKS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5Zb3Ug ZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQy IG1pZDMgbWVhbnMgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhlIHRyYW5zcG9ydDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPm9mPG86cD48L286cD48L3ByZT4NCjxwcmU+bWlkMSAocmVhZDogeW91IGFy ZSBzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCk8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJV TkVMRSBtaWQyIG1pZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNw b3J0PG86cD48L286cD48L3ByZT4NCjxwcmU+b2Y8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5taWQy IChyZWFkOiBrZWVwIHRoZSBleGlzdGluZyBCVU5ETEUgZ3JvdXAgdHJhbnNwb3J0KS48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Ob3csIGlmIHlv dSBJTiBBRERJVElPTiB0byB0aGF0IHdhbnRzIHRvIGluZGljYXRlIHNvbWV0aGluZyBJQ0U8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5zcGVjaWZpYyw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5lLmcs IHdoZXRoZXIgdG8gZG8gYW4gSUNFIHJlc3RhcnQsIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB1ZnJh ZyBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CdXQsIEkgZG9uwrl0IHRoaW5rIHRo YXQgaXMgQlVORExFIHNwZWNpZmljLCBpcyBpdD88bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgT2ssIHNvIHdoYXQgeW91IGFyZSBkZXNjcmli aW5nIGlzICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiZxdW90Oy48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5CdXQgdGhlIGJ1bmRsZSBzcGVjIGRvZXNuJ3QgX3F1aXRlXyBndWFyYW50 ZWUgdGhpcyByaWdodCBub3csIGFuZCBpdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnByb2JhYmx5 IHNob3VsZG4ndCB0cnkgdG8gZ3VhcmFudGVlIGl0IGVpdGhlci4gRm9yIGluc3RhbmNlLCA4LjUu MTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRlc2NyaWJlcyBob3cgdGhlIG9mZmVyZXIgY2FuIHN1 Z2dlc3QgYSBuZXcgdHJhbnNwb3J0IGZvciB0aGUgYnVuZGxlLDxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPmFueSB0aW1lIGl0IHdhbnRzIChhbmQgaXQgY291bGQgcG90ZW50aWFsbHkgYmUgYSBwcmUt ZXhpc3RpbmcgdHJhbnNwb3J0PG86cD48L286cD48L3ByZT4NCjxwcmU+JnF1b3Q7c3RvbGVuJnF1 b3Q7IGZyb20gc29tZSBvdGhlciBidW5kbGUvbS1zZWN0aW9uISk7IHdpdGhvdXQgdGFraW5nIHNv bWV0aGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxpa2UgdWZyYWcgaW50byBhY2NvdW50LCB0 aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS48bzpwPjwvbzpwPjwv cHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5UaGUgQlVORExFIGdyb3VwcyBjYW4gbm90IHVzZSB0 aGUgc2FtZSB0cmFuc3BvcnQsIHNvIGlmIHNvbWVvbmUgaXMgdHJ5aW5nPG86cD48L286cD48L3By ZT4NCjxwcmU+dG8gb2ZmZXIgc3VjaCB0aGluZyB0aGUgYW5zd2VyZXIgc2hvdWxkIHJlamVjdCB0 aGUgb2ZmZXIsIG9yIGF0IGxlYXN0IG5vdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFjY2VwdCB0 aGUgb2ZmZXJlZCB0cmFuc3BvcnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+ PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmU+SG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmln aHQgaW4gc2F5aW5nICZxdW90O1dlbGwsIGR1aCwgdGhhdCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPnRydWUgZm9yIG5vbi1CVU5ETEUgYWxzbyEmcXVvdDssIHdoaWNoIGlzIHdoeSBJIGxpa2Ug dGhlIGlkZWEgb2YgZml4aW5nIHRoaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT53aXRoIHVmcmFn LCBzaW5jZSB0aGF0J3MgaG93IHdlIG1ha2UgdGhpcyB3b3JrIGluIHRoZSBub24tQlVORExFIGNh c2UuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmU+SSBndWVzcyBJIHN0aWxs IGhhdmUgc29tZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIHdoYXQgdGhlIHByb2JsZW0gaXMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+TGV04oCZ cyB0YWtlIHRoZSBmb2xsb3dpbmcgZXhhbXBsZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Jbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZTo8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdy b3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6 QlVORExFIG1pZDQgbWlkNSBtaWQ2PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Tm93LCB5b3UgaGF2ZSB0d28gdHJhbnNwb3J0czogb25lIOKAnG93 bmVk4oCdIGJ5IG1pZDEgYW5kIG9uZSDigJxvd25lZCZxdW90OyBieSBtaWQ0LjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPlJlLW9mZmVyOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkMiBtaWQzPG86cD48 L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQ1IG1pZDY8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5JbiB0aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90IGNo YW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm1p ZDQgLSB0aGV5IGFyZSBzdGlsbCB0aGUgc2FtZS4gVGhlIGRpZmZlcmVudCBpcyB0aGF0IG1pZDIg YW5kIG1pZDMgd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm5vdyBzdGFydCB1c2luZyB0aGUg dHJhbnNwb3J0IG9mIG1pZDQsIGFuZCBtaWQ1IGFuZCBtaWQ2IHdpbGwgc3RhcnQgdXNpbmc8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT50aGUgdHJhbnNwb3J0IG9mIG1pZDEuPG86cD48L286cD48L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LCBidXQgYXMgZmFyIGFzIEkgY2FuIHRlbGwg dGhlIGJ1bmRsZSBzcGVjIGRvZXMgbm90IGZvcmJpZCB0aGlzOjxicj4NCjxicj4NCmE9Z3JvdXA6 QlVORExFIG1pZDEgbWlkMiBtaWQzICZsdDstLS0gdXNlcyBwb3J0IDU1NTU8YnI+DQphPWdyb3Vw OkJVTkRMRSBtaWQ0IG1pZDUgbWlkNiAmbHQ7LS0tIHVzZXMgcG9ydCA2NjY2PGJyPg0KLi4uPGJy Pg0KbT1hdWRpbyA1NTU1IC4uLjxicj4NCmE9bWlkOm1pZDE8YnI+DQouLi48YnI+DQptPXZpZGVv IDY2NjYgLi4uPGJyPg0KYT1taWQ6bWlkNDxicj4NCjxicj4NCmFuZCB0aGVuIGluIGEgcmVvZmZl cjo8YnI+DQo8YnI+DQphPWdyb3VwOkJVTkRMRSA8Yj5taWQ0PC9iPiBtaWQyIG1pZDMgJmx0Oy0t LSBtaWQ0IGFuZCBtaWQxIGhhdmUgc3dhcHBlZC4uLjxicj4NCmE9Z3JvdXA6QlVORExFIDxiPm1p ZDE8L2I+IG1pZDUgbWlkNjxicj4NCi4uLjxicj4NCm09YXVkaW8gPGI+NjY2NjwvYj4gLi4uICZs dDstLS0gYnV0IHRoZSBvZmZlcmVyIGhhcyBleHBsaWNpdGx5IGluZGljYXRlZCB0aGF0IDY2NjYg aXMgYXR0YWNoZWQgdG8gbWlkMSBub3c8YnI+DQphPW1pZDptaWQxPGJyPg0KLi4uPGJyPg0KbT12 aWRlbyA8Yj41NTU1PC9iPiAuLi48YnI+DQphPW1pZDptaWQ0PGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IElmIHRoZSBidW5kbGUgc3BlYyBhbGxvd3MgdGhpcywgJnF1b3Q7dHJhbnNwb3J0 IGZvbGxvd3MgbS1zZWN0aW9uJnF1b3Q7IGlzIG5vdCBwYXJ0IG9mIHRoZSBzcGVjOyB0aGUgZnVu ZGFtZW50YWwgcnVsZSBpcyAmcXVvdDt0cmFuc3BvcnQgaXMgc2lnbmFsZWQgZXhwbGljaXRseSBl dmVyeSB0aW1lJnF1b3Q7LCB3aGljaCBpcyBpbXBvc3NpYmxlIHdpdGggSUNFIHVubGVzcyB1ZnJh ZyBpcyB0YWtlbiBpbnRvIGFjY291bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPk1heWJlJm5ic3A74oCcdHJh bnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdvcmRpbmcuIFRyYW5zcG9ydCBp cyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3VwOkJVTkRMRSBhdHRyaWJ1dGUg aW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3BvcnQgYWxyZWFkeSBleGlzdHMN CiB0aGVyZSBpcyBubyBuZWVkIHRvIGRvIGFuIElDRSByZXN0YXJ0LiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpy ZWQiPlNvLCBpbiB5b3VyIGV4YW1wbGUsIGkgdGhlIHJlb2ZmZXIgeW91IGFyZSBzdWdnZXN0aW5n IHRoYXQgbWlkNCwgbWlkMiBhbmQgbWlkMyB1c2VzIHRoZSAmcXVvdDs1NTU1IHRyYW5zcG9ydCZx dW90Oy4gU2luY2UgdGhpcyB0cmFuc3BvcnQgYWxyZWFkeSBleGlzdHMgKGl0IHdhcyBwcmV2aW91 c2x5IHVzZWQgYnkgbWlkMSwgbWlkMg0KIGFuZCBtaWQzKSwgeW91IGRvbuKAmXQgaGF2ZSB0byBk byBhbiBJQ0UgcmVzdGFydC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPkNo cmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LiBUaGUgb2ZmZXJlciBleHBsaWNpdGx5IGluZGlj YXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBpcyBhbWJpZ3VvdXMuIEkgbGlr ZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdoeSBJIHByZWZlciBjbGFyaWZ5 aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQgc2lnbmFsaW5nIGlzIHVzZWQg aW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lmeWluZw0KIHJlc3RyaWN0aW9u cyBsaWtlICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiZxdW90OyB0byBoYW5kbGUg dGhlIElDRSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM3MEFENDc7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgdG90 YWxseSBhZ3JlZSDigJMgdGhlIHRyYW5zcG9ydCBoYXMgdG8gYmUgZXhwbGljaXRseSBpbmRpY2F0 ZWQuIEJ1dCwgZG9u4oCZdCB0aGUgSUNFIFNEUCBhdHRyaWJ1dGVzIGFscmVhZHkgZXhwbGljaXRs eSBpbmRpY2F0ZSB0aGUgdHJhbnNwb3J0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgU2FkbHksIG5vdCBxdWl0ZSwgYmVjYXVzZSB0aGVy ZSdzIG5vIGNsZWFyIHJlcXVpcmVtZW50IHJpZ2h0IG5vdyB0aGF0IHRoZSB1ZnJhZyBpcyBkaWZm ZXJlbnQgZm9yIGVhY2ggdHJhbnNwb3J0IChhbmQgaW5kZWVkIGl0IGhhcyBub3QgYmVlbiBpbXBs ZW1lbnRlZCB0aGF0IHdheSBieSBDaHJvbWUgb3IgRmlyZWZveCkuIFRoYXQncyB3aGF0IEknbSBh ZHZvY2F0aW5nIGZpeGluZywgaW5zdGVhZCBvZiBhZGRpbmcNCiBhIGJ1bmNoIG9mIG5ldyBydWxl cyBmb3IgYnVuZGxlIHdpdGggSUNFLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBB RDQ3Ij5BcyBJIHdyb3RlIGluIG15IGUtbWFpbCBvbiBUaHVyc2RheSwgbXkgdW5kZXJzdGFuZGlu ZyBvZiBSRkMgNTI0NSBpcyB0aGF0IHRoZSB1ZnJhZyBtdXN0IGJlIGRpZmZlcmVudCBmb3IgZWFj aCB0cmFuc3BvcnQsIGlmIHlvdSBkbyBhbiBJQ0UgcmVzdGFydCB5b3UgbXVzdCBjaGFuZ2UNCiB1 ZnJhZywgYW5kIGEgY2hhbmdlIG9mIHVmcmFnIHdpbGwgdHJpZ2dlciBhbiBJQ0UgcmVzdGFydC4u IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNzBBRDQ3Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+SWYgaW1wbGVtZW50 YXRpb25zIGRvbuKAmXQgZm9sbG93IHRoZSBzcGVjcyBpdCBkb2VzbuKAmXQgcmVhbGx5IG1hdHRl ciB3aGF0IHdlIHNwZWNpZnnigKY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVGhhdCBjaGFuZ2luZyB0aGUgdWZyYWcgY2F1 c2VzIGEgdHJhbnNwb3J0IGNoYW5nZSBpcyBjbGVhciwgYnV0IHRoZXJlIGlzIHByZXNlbnRseSBu byBsYW5ndWFnZSBzYXlpbmcgdGhhdCB5b3UgY2Fubm90IHN0YXJ0IG91dCB3aXRoIHRoZSBzYW1l IHVmcmFnIGZvciBldmVyeSBtLXNlY3Rpb24sIGFuZCB0aGlzIGlzIGZ1cnRoZXIgY29uZnVzZWQg YnkgdGhlIGZhY3QgdGhhdCBpY2UtdWZyYWcgaXMgYWxsb3dlZCB0byBiZSBzZXNzaW9uIGxldmVs LjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+T2ssIEkg aGVhciB3aGF0IHlvdSBhcmUgc2F5aW5nLiBXZSBjYW4gYWx3YXlzIG1hbmRhdGUgdW5pcXVlIHVm cmFnIHZhbHVlcyBpbiBCVU5ETEUsIGFuZCBtYXliZSBhbHNvIGluIDUyNDViaXMgKHRoYXQgZGlz Y3Vzc2lvbiBiZWxvbmdzIHRvIHRoZSBJQ0UgV0csIHRob3VnaCkuDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0 NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B5C6A0F33ESESSMB109erics_-- From nobody Mon Nov 13 23:14:44 2017 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 CB83D124BE8 for ; Mon, 13 Nov 2017 23:14:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 duZok58MM9Ii for ; Mon, 13 Nov 2017 23:14:40 -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 D84EA1200E5 for ; Mon, 13 Nov 2017 23:14:39 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-24-5a0a97dd8e0a Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.FA.19528.DD79A0A5; Tue, 14 Nov 2017 08:14:38 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.84]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0352.000; Tue, 14 Nov 2017 08:14:37 +0100 From: Christer Holmberg To: Christer Holmberg , Byron Campen , Taylor Brandstetter , RTCWeb IETF Thread-Topic: [rtcweb] Ambiguities with BUNDLE when used with ICE? - Pull Request Thread-Index: AdNdF4L9xPImCpw8QKKg08JBvmezsQAAKauQ Date: Tue, 14 Nov 2017 07:14:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B5C6A0FBB@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B5C6A0F33@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B5C6A0F33@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B5C6A0FBBESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM2K7se696VxRBh1XuSwW3mtlsbi84iGr xdp/7ewOzB4LNpV6LFnyk8mj70AXawBzFJdNSmpOZllqkb5dAlfGxr3nmAp+HGGqOHGnlbmB cccepi5GTg4JAROJthWzWLoYuTiEBA4zSjy/2McO4SxmlJh54x5rFyMHB5uAhUT3P22QuIjA CkaJLRe/sYN0CwsESVz/cI0FxBYRCJZYtXg6I0i9iICRxNt9wiAmi4CqxOy+dJAKXgFficO7 9rOB2EJAdsvnx6wgNqeAn8TsT0cYQWxGATGJ76fWgN3GLCAucevJfKg7BSSW7DnPDGGLSrx8 /I8VwlaSWHT7M1R9vsSMhR1MELsEJU7OfMIygVF4FpJRs5CUzUJSNgvoUmYBTYn1u/QhShQl pnQ/ZIewNSRa58xlRxZfwMi+ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwog5u+W21g/Hg c8dDjAIcjEo8vE8mc0UJsSaWFVfmHmKU4GBWEuENCQYK8aYkVlalFuXHF5XmpBYfYpTmYFES 53XYdyFCSCA9sSQ1OzW1ILUIJsvEwSnVwOjjVsq9c9Plq3PmcoWyfpGX+aq84ar2v4LM+avP PdnCf+nE++r7T+yuV8QcqA48uFyRceGLr4/4m1be/jx7mf4PTmsH5VDpyigj/4XOpR0fhX7O W+hldjZxua5OuHXezDIvqY2rd7+IklnHI/xgr/u/sBnbO/ut2+b5Tp9sLvWq7eJM66dvum2V WIozEg21mIuKEwEYPZ80pAIAAA== Archived-At: Subject: Re: [rtcweb] Ambiguities with BUNDLE when used with ICE? - Pull Request 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, 14 Nov 2017 07:14:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B5C6A0FBBESESSMB109erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tk9URTogSWYgeW91IGhhdmUgYW55IGNvbW1lbnRzIG9uIHRoZSBQUiwgb3IgdGhlIGlzc3VlIGlu IGdlbmVyYWwsIHBsZWFzZSBwb3N0IHRoZW0gb24gdGhlIE1NVVNJQyBsaXN0Lg0KDQpUaGFua3Mh DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCkZyb206IHJ0Y3dlYiBbbWFpbHRvOnJ0Y3dlYi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDE0 IE5vdmVtYmVyIDIwMTcgMDk6MDkNClRvOiBCeXJvbiBDYW1wZW4gPGJjYW1wZW5AbW96aWxsYS5j b20+OyBUYXlsb3IgQnJhbmRzdGV0dGVyIDxkZWFkYmVlZkBnb29nbGUuY29tPjsgUlRDV2ViIElF VEYgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRjd2ViXSBBbWJpZ3VpdGllcyB3 aXRoIEJVTkRMRSB3aGVuIHVzZWQgd2l0aCBJQ0U/IC0gUHVsbCBSZXF1ZXN0DQoNCkhpLA0KDQpJ dOKAmXMgYSB3aGlsZSBzaW5jZSB3ZSBkaXNjdXNzZWQgdGhpcywgYnV0IEkgaGF2ZSBub3cgY3Jl YXRlZCBhIFBSIHdoaWNoIHRhbGtzIGFib3V0IG1vdmluZyBtLSBzZWN0aW9ucyBiZXR3ZWVuIEJV TkRMRSBncm91cHMsIGFuZCBob3cgaXQgYWZmZWN0cyB0aGUgQlVORExFIGFkZHJlc3MuDQoNCmh0 dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1zZHAtYnVuZGxlL3B1bGwvNDMNCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMDEgU2VwdGVtYmVy IDIwMTcgMTg6NTgNClRvOiBCeXJvbiBDYW1wZW4gPGJjYW1wZW5AbW96aWxsYS5jb208bWFpbHRv OmJjYW1wZW5AbW96aWxsYS5jb20+PjsgVGF5bG9yIEJyYW5kc3RldHRlciA8ZGVhZGJlZWZAZ29v Z2xlLmNvbTxtYWlsdG86ZGVhZGJlZWZAZ29vZ2xlLmNvbT4+OyBSVENXZWIgSUVURiA8cnRjd2Vi QGlldGYub3JnPG1haWx0bzpydGN3ZWJAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJd IEFtYmlndWl0aWVzIHdpdGggQlVORExFIHdoZW4gdXNlZCB3aXRoIElDRT8NCg0KSGksDQoNCkhp LA0KDQoNCiAgICAgICBBbHJpZ2h0LCBpZiB3ZSB3YW50IHRvIHdyaXRlIGEgcnVsZSB0aGF0IHRo ZSB0cmFuc3BvcnQNCg0KZm9sbG93cw0KDQp0aGUNCg0KYnVuZGxlLCB3aGF0IGFib3V0IHRoaXM/ DQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDINCg0KYT1ncm91cDpCVU5ETEUgbWlkMyBt aWQ0DQoNCg0KDQphbmQgaW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwOkJVTkRMRSBtaWQyIG1p ZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxDQoNCg0KDQogICAgICAgV2hhdCB0cmFuc3Bv cnQgZ29lcyB3aGVyZT8NCg0KSSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGll ci4gV2hhdCB5b3UgYXJlIGRvaW5nIGFib3ZlDQoNCmlzDQoNCm1vdmluZyBzdHJlYW1zIGZyb20g b25lIEJVTkRMRSBncm91cCB0byBhbm90aGVyLCBhbmQgbWl4aW5nIHRoZQ0KDQpCVU5ETEUNCg0K Z3JvdXBzIHVwLCBhbmQgSSBkb27CuXQgdGhpbmsgdGhhdMK5cyBhIGdvb2QgaWRlYS4NCg0KDQoN ClJlZ2FyZHMsDQoNCg0KDQpDaHJpc3Rlcg0KDQogICAgICBJZiB5b3Ugd2FudCB0byBjbGFzc2lm eSB0aGlzIGFzIGEgYmFkIGlkZWEsIHdlIG5lZWQgbm9ybWF0aXZlDQoNCmxhbmd1YWdlIGZvcmJp ZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25jZSBhIG1pZCBpcw0KDQpwbGFj ZWQNCg0KaW4gYSBidW5kbGUsIHRoZSBvbmx5IHdheSB0byByZW1vdmUgaXQgaXMgdG8gZGlzYWJs ZSBpdCwgYXMgd2VsbCBhcyBhDQoNCnJ1bGUgdG8gaGFuZGxlIHRoZSBmb2xsb3dpbmc6DQoNCg0K DQphPWdyb3VwOkJVTkRMRSBtaWQyIG1pZDMNCg0KYT1taWQ6IG1pZDEgPC0tLSBub3QgYnVuZGxl ZA0KDQouLi4NCg0KYT1taWQ6IG1pZDINCg0KLi4uDQoNCmE9bWlkOiBtaWQzDQoNCg0KDQphbmQg aW4gYSByZW9mZmVyDQoNCg0KDQphPWdyb3VwIG1pZDEgbWlkMiBtaWQzDQoNCg0KDQogICAgICBX ZSB3b3VsZCBuZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEn cywgb3INCg0KdGhlDQoNCmJ1bmRsZSdzLiBPciBwZXJoYXBzIGEgcnVsZSBmb3JiaWRkaW5nIHBy ZXZpb3VzbHkgdW5idW5kbGVkIG1pZHMgdG8NCg0KYmUNCg0KYWRkZWQgdG8gYSBidW5kbGUuDQoN CkkgdGhpbmsgdGhpcyBpcyBjb3ZlcmVkIGluIHNlY3Rpb24gOC41LjIgKEFkZGluZyBhIG1lZGlh IGRlc2NyaXB0aW9uDQoNCnRvDQoNCmENCg0KQlVORExFIGdyb3VwKSBvZiBCVU5ETEUuDQoNCg0K DQpBc3N1bWluZyB5b3UgYXJlIG5vdCBjaGFuZ2luZyB0aGUgdHJhbnNwb3J0IG9mIHRoZSBtaWQx IG0tbGluZSwgeW91DQoNCmFyZQ0KDQpzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhl IEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluDQoNCnNlY3Rpb24NCg0KOC41LjIpLg0KDQog ICAgIFJpZ2h0LCB0aGUgb2ZmZXJlciBoYXMgdGhlIGNob2ljZSBvZiByZXRhaW5pbmcgbWlkMSdz IHRyYW5zcG9ydCwNCg0Kb3INCg0Ka2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFj Y29yZGluZyB0byA4LjUuMi4gSWYgd2UgZG9uJ3QgZG8NCg0Kc29tZXRoaW5nIGxpa2UgYWRkaW5n IHVmcmFnIHRvIHRoZSB0cmFuc3BvcnQgY29tcGFyaXNvbiBydWxlcywgOC41LjINCg0Kd291bGQg aGF2ZSB0byBiZSB0aWdodGVuZWQgc2lnbmlmaWNhbnRseS4gQWdhaW4sIG91ciB0d28gY2hvaWNl cyBoZXJlOg0KDQoNCg0KMS4gRmluZCBhIHdheSB0byBhbGxvdyBhbiBJQ0Ugb2ZmZXJlciB0byBp bmRpY2F0ZSB3aGF0IHRyYW5zcG9ydHMgaXQgaXMNCg0KcmV0YWluaW5nIChlZzsgdWZyYWcpLg0K DQpZb3UgZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUuDQoNCg0KDQphPWdyb3Vw OkJVTkRMRSBtaWQxIG1pZDIgbWlkMyBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJh bnNwb3J0DQoNCm9mDQoNCm1pZDEgKHJlYWQ6IHlvdSBhcmUgc3VnZ2VzdGluZyBhIG5ldyB0cmFu c3BvcnQgZm9yIHRoZSBCVU5ETEUgZ3JvdXApDQoNCg0KDQphPWdyb3VwOkJVTkVMRSBtaWQyIG1p ZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0DQoNCm9mDQoN Cm1pZDIgKHJlYWQ6IGtlZXAgdGhlIGV4aXN0aW5nIEJVTkRMRSBncm91cCB0cmFuc3BvcnQpLg0K DQoNCg0KTm93LCBpZiB5b3UgSU4gQURESVRJT04gdG8gdGhhdCB3YW50cyB0byBpbmRpY2F0ZSBz b21ldGhpbmcgSUNFDQoNCnNwZWNpZmljLA0KDQplLmcsIHdoZXRoZXIgdG8gZG8gYW4gSUNFIHJl c3RhcnQsIEkgZ3Vlc3MgeW91IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC4NCg0KQnV0LCBJIGRv bsK5dCB0aGluayB0aGF0IGlzIEJVTkRMRSBzcGVjaWZpYywgaXMgaXQ/DQoNCiAgICBPaywgc28g d2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgInRyYW5zcG9ydCBmb2xsb3dzIG0tc2VjdGlvbiIu DQoNCkJ1dCB0aGUgYnVuZGxlIHNwZWMgZG9lc24ndCBfcXVpdGVfIGd1YXJhbnRlZSB0aGlzIHJp Z2h0IG5vdywgYW5kIGl0DQoNCnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3VhcmFudGVlIGl0 IGVpdGhlci4gRm9yIGluc3RhbmNlLCA4LjUuMQ0KDQpkZXNjcmliZXMgaG93IHRoZSBvZmZlcmVy IGNhbiBzdWdnZXN0IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIGJ1bmRsZSwNCg0KYW55IHRpbWUg aXQgd2FudHMgKGFuZCBpdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBhIHByZS1leGlzdGluZyB0cmFu c3BvcnQNCg0KInN0b2xlbiIgZnJvbSBzb21lIG90aGVyIGJ1bmRsZS9tLXNlY3Rpb24hKTsgd2l0 aG91dCB0YWtpbmcgc29tZXRoaW5nDQoNCmxpa2UgdWZyYWcgaW50byBhY2NvdW50LCB0aGlzIGlz IGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJQ0UgY2FzZS4NCg0KVGhlIEJVTkRMRSBncm91 cHMgY2FuIG5vdCB1c2UgdGhlIHNhbWUgdHJhbnNwb3J0LCBzbyBpZiBzb21lb25lIGlzIHRyeWlu Zw0KDQp0byBvZmZlciBzdWNoIHRoaW5nIHRoZSBhbnN3ZXJlciBzaG91bGQgcmVqZWN0IHRoZSBv ZmZlciwgb3IgYXQgbGVhc3Qgbm90DQoNCmFjY2VwdCB0aGUgb2ZmZXJlZCB0cmFuc3BvcnRzLg0K DQoNCg0KSG93ZXZlciwgeW91IHdvdWxkIGJlIGNvbXBsZXRlbHkgcmlnaHQgaW4gc2F5aW5nICJX ZWxsLCBkdWgsIHRoYXQgaXMNCg0KdHJ1ZSBmb3Igbm9uLUJVTkRMRSBhbHNvISIsIHdoaWNoIGlz IHdoeSBJIGxpa2UgdGhlIGlkZWEgb2YgZml4aW5nIHRoaXMNCg0Kd2l0aCB1ZnJhZywgc2luY2Ug dGhhdCdzIGhvdyB3ZSBtYWtlIHRoaXMgd29yayBpbiB0aGUgbm9uLUJVTkRMRSBjYXNlLg0KDQpJ IGd1ZXNzIEkgc3RpbGwgaGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQgd2hhdCB0aGUg cHJvYmxlbSBpcy4NCg0KDQoNCkxldOKAmXMgdGFrZSB0aGUgZm9sbG93aW5nIGV4YW1wbGU6DQoN Cg0KDQpJbml0aWFsIG9mZmVyL2Fuc3dlciBleGNoYW5nZToNCg0KDQoNCmE9Z3JvdXA6QlVORExF IG1pZDEgbWlkMiBtaWQzDQoNCmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2DQoNCg0KDQpO b3csIHlvdSBoYXZlIHR3byB0cmFuc3BvcnRzOiBvbmUg4oCcb3duZWTigJ0gYnkgbWlkMSBhbmQg b25lIOKAnG93bmVkIiBieSBtaWQ0Lg0KDQoNCg0KDQoNClJlLW9mZmVyOg0KDQoNCg0KYT1ncm91 cDpCVU5ETEUgbWlkNCBtaWQyIG1pZDMNCg0KYT1ncm91cDpCVU5ETEUgbWlkMSBtaWQ1IG1pZDYN Cg0KDQoNCg0KDQpJbiB0aGUgcmUtb2ZmZXIsIHRoZSBvZmZlcmVyIGRvZXMgbm90IGNoYW5nZSB0 aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZA0KDQptaWQ0IC0gdGhleSBhcmUgc3RpbGwgdGhlIHNh bWUuIFRoZSBkaWZmZXJlbnQgaXMgdGhhdCBtaWQyIGFuZCBtaWQzIHdpbGwNCg0Kbm93IHN0YXJ0 IHVzaW5nIHRoZSB0cmFuc3BvcnQgb2YgbWlkNCwgYW5kIG1pZDUgYW5kIG1pZDYgd2lsbCBzdGFy dCB1c2luZw0KDQp0aGUgdHJhbnNwb3J0IG9mIG1pZDEuDQoNCiAgICBSaWdodCwgYnV0IGFzIGZh ciBhcyBJIGNhbiB0ZWxsIHRoZSBidW5kbGUgc3BlYyBkb2VzIG5vdCBmb3JiaWQgdGhpczoNCg0K YT1ncm91cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMgPC0tLSB1c2VzIHBvcnQgNTU1NQ0KYT1ncm91 cDpCVU5ETEUgbWlkNCBtaWQ1IG1pZDYgPC0tLSB1c2VzIHBvcnQgNjY2Ng0KLi4uDQptPWF1ZGlv IDU1NTUgLi4uDQphPW1pZDptaWQxDQouLi4NCm09dmlkZW8gNjY2NiAuLi4NCmE9bWlkOm1pZDQN Cg0KYW5kIHRoZW4gaW4gYSByZW9mZmVyOg0KDQphPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDIgbWlk MyA8LS0tIG1pZDQgYW5kIG1pZDEgaGF2ZSBzd2FwcGVkLi4uDQphPWdyb3VwOkJVTkRMRSBtaWQx IG1pZDUgbWlkNg0KLi4uDQptPWF1ZGlvIDY2NjYgLi4uIDwtLS0gYnV0IHRoZSBvZmZlcmVyIGhh cyBleHBsaWNpdGx5IGluZGljYXRlZCB0aGF0IDY2NjYgaXMgYXR0YWNoZWQgdG8gbWlkMSBub3cN CmE9bWlkOm1pZDENCi4uLg0KbT12aWRlbyA1NTU1IC4uLg0KYT1taWQ6bWlkNA0KDQogICAgSWYg dGhlIGJ1bmRsZSBzcGVjIGFsbG93cyB0aGlzLCAidHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u IiBpcyBub3QgcGFydCBvZiB0aGUgc3BlYzsgdGhlIGZ1bmRhbWVudGFsIHJ1bGUgaXMgInRyYW5z cG9ydCBpcyBzaWduYWxlZCBleHBsaWNpdGx5IGV2ZXJ5IHRpbWUiLCB3aGljaCBpcyBpbXBvc3Np YmxlIHdpdGggSUNFIHVubGVzcyB1ZnJhZyBpcyB0YWtlbiBpbnRvIGFjY291bnQuDQoNCg0KTWF5 YmUg4oCcdHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25nIHdvcmRpbmcuIFRy YW5zcG9ydCBpcyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdyb3VwOkJVTkRMRSBh dHRyaWJ1dGUgaW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFuc3BvcnQgYWxyZWFk eSBleGlzdHMgdGhlcmUgaXMgbm8gbmVlZCB0byBkbyBhbiBJQ0UgcmVzdGFydC4NCg0KU28sIGlu IHlvdXIgZXhhbXBsZSwgaSB0aGUgcmVvZmZlciB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhhdCBtaWQ0 LCBtaWQyIGFuZCBtaWQzIHVzZXMgdGhlICI1NTU1IHRyYW5zcG9ydCIuIFNpbmNlIHRoaXMgdHJh bnNwb3J0IGFscmVhZHkgZXhpc3RzIChpdCB3YXMgcHJldmlvdXNseSB1c2VkIGJ5IG1pZDEsIG1p ZDIgYW5kIG1pZDMpLCB5b3UgZG9u4oCZdCBoYXZlIHRvIGRvIGFuIElDRSByZXN0YXJ0Lg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KICAgIFJpZ2h0LiBUaGUgb2ZmZXJlciBleHBsaWNp dGx5IGluZGljYXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGluZyBpcyBhbWJpZ3Vv dXMuIEkgbGlrZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlzIHdoeSBJIHByZWZl ciBjbGFyaWZ5aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGljaXQgc2lnbmFsaW5n IGlzIHVzZWQgaW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3BlY2lmeWluZyByZXN0 cmljdGlvbnMgbGlrZSAidHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uIiB0byBoYW5kbGUgdGhl IElDRSBjYXNlLg0KSSB0b3RhbGx5IGFncmVlIOKAkyB0aGUgdHJhbnNwb3J0IGhhcyB0byBiZSBl eHBsaWNpdGx5IGluZGljYXRlZC4gQnV0LCBkb27igJl0IHRoZSBJQ0UgU0RQIGF0dHJpYnV0ZXMg YWxyZWFkeSBleHBsaWNpdGx5IGluZGljYXRlIHRoZSB0cmFuc3BvcnQ/DQoNCiAgICBTYWRseSwg bm90IHF1aXRlLCBiZWNhdXNlIHRoZXJlJ3Mgbm8gY2xlYXIgcmVxdWlyZW1lbnQgcmlnaHQgbm93 IHRoYXQgdGhlIHVmcmFnIGlzIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQgKGFuZCBpbmRl ZWQgaXQgaGFzIG5vdCBiZWVuIGltcGxlbWVudGVkIHRoYXQgd2F5IGJ5IENocm9tZSBvciBGaXJl Zm94KS4gVGhhdCdzIHdoYXQgSSdtIGFkdm9jYXRpbmcgZml4aW5nLCBpbnN0ZWFkIG9mIGFkZGlu ZyBhIGJ1bmNoIG9mIG5ldyBydWxlcyBmb3IgYnVuZGxlIHdpdGggSUNFLg0KDQpBcyBJIHdyb3Rl IGluIG15IGUtbWFpbCBvbiBUaHVyc2RheSwgbXkgdW5kZXJzdGFuZGluZyBvZiBSRkMgNTI0NSBp cyB0aGF0IHRoZSB1ZnJhZyBtdXN0IGJlIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQsIGlm IHlvdSBkbyBhbiBJQ0UgcmVzdGFydCB5b3UgbXVzdCBjaGFuZ2UgdWZyYWcsIGFuZCBhIGNoYW5n ZSBvZiB1ZnJhZyB3aWxsIHRyaWdnZXIgYW4gSUNFIHJlc3RhcnQuLg0KDQpJZiBpbXBsZW1lbnRh dGlvbnMgZG9u4oCZdCBmb2xsb3cgdGhlIHNwZWNzIGl0IGRvZXNu4oCZdCByZWFsbHkgbWF0dGVy IHdoYXQgd2Ugc3BlY2lmeeKApg0KDQoNCiAgICBUaGF0IGNoYW5naW5nIHRoZSB1ZnJhZyBjYXVz ZXMgYSB0cmFuc3BvcnQgY2hhbmdlIGlzIGNsZWFyLCBidXQgdGhlcmUgaXMgcHJlc2VudGx5IG5v IGxhbmd1YWdlIHNheWluZyB0aGF0IHlvdSBjYW5ub3Qgc3RhcnQgb3V0IHdpdGggdGhlIHNhbWUg dWZyYWcgZm9yIGV2ZXJ5IG0tc2VjdGlvbiwgYW5kIHRoaXMgaXMgZnVydGhlciBjb25mdXNlZCBi eSB0aGUgZmFjdCB0aGF0IGljZS11ZnJhZyBpcyBhbGxvd2VkIHRvIGJlIHNlc3Npb24gbGV2ZWwu DQpPaywgSSBoZWFyIHdoYXQgeW91IGFyZSBzYXlpbmcuIFdlIGNhbiBhbHdheXMgbWFuZGF0ZSB1 bmlxdWUgdWZyYWcgdmFsdWVzIGluIEJVTkRMRSwgYW5kIG1heWJlIGFsc28gaW4gNTI0NWJpcyAo dGhhdCBkaXNjdXNzaW9uIGJlbG9uZ3MgdG8gdGhlIElDRSBXRywgdGhvdWdoKS4NCg0KUmVnYXJk cywNCg0KQ2hyaXN0ZXINCg0K --_000_7594FB04B1934943A5C02806D1A2204B5C6A0FBBESESSMB109erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgljb2xvcjpibGFjazt9DQpzcGFu LkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy Ng0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5PVEU6IElm IHlvdSBoYXZlIGFueSBjb21tZW50cyBvbiB0aGUgUFIsIG9yIHRoZSBpc3N1ZSBpbiBnZW5lcmFs LCBwbGVhc2UgcG9zdCB0aGVtIG9uIHRoZSBNTVVTSUMgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 Ij4gcnRjd2ViIFttYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IDE0IE5vdmVtYmVyIDIw MTcgMDk6MDk8YnI+DQo8Yj5Ubzo8L2I+IEJ5cm9uIENhbXBlbiAmbHQ7YmNhbXBlbkBtb3ppbGxh LmNvbSZndDs7IFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0O2RlYWRiZWVmQGdvb2dsZS5jb20mZ3Q7 OyBSVENXZWIgSUVURiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3J0Y3dlYl0gQW1iaWd1aXRpZXMgd2l0aCBCVU5ETEUgd2hlbiB1c2VkIHdpdGggSUNF PyAtIFB1bGwgUmVxdWVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkl04oCZ cyBhIHdoaWxlIHNpbmNlIHdlIGRpc2N1c3NlZCB0aGlzLCBidXQgSSBoYXZlIG5vdyBjcmVhdGVk IGEgUFIgd2hpY2ggdGFsa3MgYWJvdXQgbW92aW5nIG0tIHNlY3Rpb25zIGJldHdlZW4gQlVORExF IGdyb3VwcywgYW5kIGhvdw0KIGl0IGFmZmVjdHMgdGhlIEJVTkRMRSBhZGRyZXNzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL2NkaDR1L2RyYWZ0LXNkcC1idW5kbGUvcHVsbC80MyI+aHR0cHM6Ly9naXRodWIuY29tL2Nk aDR1L2RyYWZ0LXNkcC1idW5kbGUvcHVsbC80MzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gcnRjd2ViIFs8YSBocmVmPSJtYWlsdG86 cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpydGN3ZWItYm91bmNlc0BpZXRmLm9yZzwv YT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGVyIEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8 L2I+IDAxIFNlcHRlbWJlciAyMDE3IDE4OjU4PGJyPg0KPGI+VG86PC9iPiBCeXJvbiBDYW1wZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGVuQG1vemlsbGEuY29tIj5iY2FtcGVuQG1vemlsbGEu Y29tPC9hPiZndDs7IFRheWxvciBCcmFuZHN0ZXR0ZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpkZWFk YmVlZkBnb29nbGUuY29tIj5kZWFkYmVlZkBnb29nbGUuY29tPC9hPiZndDs7IFJUQ1dlYiBJRVRG ICZsdDs8YSBocmVmPSJtYWlsdG86cnRjd2ViQGlldGYub3JnIj5ydGN3ZWJAaWV0Zi5vcmc8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3J0Y3dlYl0gQW1iaWd1aXRpZXMgd2l0aCBC VU5ETEUgd2hlbiB1c2VkIHdpdGggSUNFPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3O21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnJlZCI+SGksPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEFscmlnaHQsIGlmIHdlIHdhbnQgdG8gd3JpdGUgYSBydWxlIHRoYXQgdGhlIHRyYW5zcG9ydDxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPmZvbGxvd3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGU8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5idW5kbGUsIHdoYXQgYWJvdXQgdGhpcz88bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRM RSBtaWQxIG1pZDI8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQzIG1p ZDQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5h bmQgaW4gYSByZW9mZmVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxw cmU+YT1ncm91cDpCVU5ETEUgbWlkNCBtaWQxPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFdoYXQgdHJhbnNwb3J0IGdvZXMgd2hlcmU/PG86cD48L286cD48L3ByZT4NCjwvYmxvY2tx dW90ZT4NCjxwcmU+SSB0aGluayBUYXlsb3IgcmFpc2VkIHRoaXMgaXNzdWUgZWFybGllci4gV2hh dCB5b3UgYXJlIGRvaW5nIGFib3ZlPG86cD48L286cD48L3ByZT4NCjxwcmU+aXM8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5tb3Zpbmcgc3RyZWFtcyBmcm9tIG9uZSBCVU5ETEUgZ3JvdXAgdG8gYW5v dGhlciwgYW5kIG1peGluZyB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CVU5ETEU8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5ncm91cHMgdXAsIGFuZCBJIGRvbsK5dCB0aGluayB0aGF0wrlzIGEg Z29vZCBpZGVhLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPlJlZ2FyZHMsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgeW91IHdhbnQgdG8gY2xhc3NpZnkg dGhpcyBhcyBhIGJhZCBpZGVhLCB3ZSBuZWVkIG5vcm1hdGl2ZTxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPmxhbmd1YWdlIGZvcmJpZGRpbmcgaXQuIEZvciBpbnN0YW5jZSwgYSBydWxlIHRoYXQgb25j ZSBhIG1pZCBpczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBsYWNlZDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPmluIGEgYnVuZGxlLCB0aGUgb25seSB3YXkgdG8gcmVtb3ZlIGl0IGlzIHRvIGRpc2Fi bGUgaXQsIGFzIHdlbGwgYXMgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnJ1bGUgdG8gaGFuZGxl IHRoZSBmb2xsb3dpbmc6PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxw cmU+YT1taWQ6IG1pZDEgJmx0Oy0tLSBub3QgYnVuZGxlZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pi4uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9bWlkOiBtaWQyPG86cD48L286cD48L3ByZT4N CjxwcmU+Li4uPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1taWQ6IG1pZDM8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgaW4gYSByZW9mZmVy PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1n cm91cCBtaWQxIG1pZDIgbWlkMzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBXZSB3b3VsZCBu ZWVkIHRvIGRlZmluZSB3aGljaCB0cmFuc3BvcnQgaXMgcmV0YWluZWQ7IG1pZDEncywgb3I8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT50aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5idW5kbGUncy4g T3IgcGVyaGFwcyBhIHJ1bGUgZm9yYmlkZGluZyBwcmV2aW91c2x5IHVuYnVuZGxlZCBtaWRzIHRv PG86cD48L286cD48L3ByZT4NCjxwcmU+YmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hZGRlZCB0 byBhIGJ1bmRsZS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5JIHRoaW5r IHRoaXMgaXMgY292ZXJlZCBpbiBzZWN0aW9uIDguNS4yIChBZGRpbmcgYSBtZWRpYSBkZXNjcmlw dGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRvPG86cD48L286cD48L3ByZT4NCjxwcmU+YTxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPkJVTkRMRSBncm91cCkgb2YgQlVORExFLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkFzc3VtaW5nIHlvdSBh cmUgbm90IGNoYW5naW5nIHRoZSB0cmFuc3BvcnQgb2YgdGhlIG1pZDEgbS1saW5lLCB5b3U8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT5hcmU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zdWdnZXN0aW5n IGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhlIEJVTkRMRSBncm91cCAoZmlyc3QgYnVsbGV0IGluPG86 cD48L286cD48L3ByZT4NCjxwcmU+c2VjdGlvbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjguNS4y KS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgUmlnaHQsIHRoZSBvZmZlcmVyIGhhcyB0aGUgY2hvaWNlIG9mIHJldGFpbmluZyBt aWQxJ3MgdHJhbnNwb3J0LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9yPG86cD48L286cD48L3By ZT4NCjxwcmU+a2VlcGluZyB0aGUgb2xkIGJ1bmRsZSB0cmFuc3BvcnQsIGFjY29yZGluZyB0byA4 LjUuMi4gSWYgd2UgZG9uJ3QgZG88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zb21ldGhpbmcgbGlr ZSBhZGRpbmcgdWZyYWcgdG8gdGhlIHRyYW5zcG9ydCBjb21wYXJpc29uIHJ1bGVzLCA4LjUuMjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPndvdWxkIGhhdmUgdG8gYmUgdGlnaHRlbmVkIHNpZ25pZmlj YW50bHkuIEFnYWluLCBvdXIgdHdvIGNob2ljZXMgaGVyZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4xLiBGaW5kIGEgd2F5IHRvIGFsbG93IGFu IElDRSBvZmZlcmVyIHRvIGluZGljYXRlIHdoYXQgdHJhbnNwb3J0cyBpdCBpczxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnJldGFpbmluZyAoZWc7IHVmcmFnKS48bzpwPjwvbzpwPjwvcHJlPg0KPC9i bG9ja3F1b3RlPg0KPHByZT5Zb3UgZG8gdGhhdCB1c2luZyB0aGUgYT1ncm91cCBhdHRyaWJ1dGUu PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+YT1n cm91cDpCVU5ETEUgbWlkMSBtaWQyIG1pZDMgbWVhbnMgdGhhdCB5b3Ugd2FudCB0byB1c2UgdGhl IHRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPm9mPG86cD48L286cD48L3ByZT4NCjxw cmU+bWlkMSAocmVhZDogeW91IGFyZSBzdWdnZXN0aW5nIGEgbmV3IHRyYW5zcG9ydCBmb3IgdGhl IEJVTkRMRSBncm91cCk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5hPWdyb3VwOkJVTkVMRSBtaWQyIG1pZDMgbWllMSBtZWFucyB0aGF0IHlvdSB3 YW50IHRvIHVzZSB0aGUgdHJhbnNwb3J0PG86cD48L286cD48L3ByZT4NCjxwcmU+b2Y8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5taWQyIChyZWFkOiBrZWVwIHRoZSBleGlzdGluZyBCVU5ETEUgZ3Jv dXAgdHJhbnNwb3J0KS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5Ob3csIGlmIHlvdSBJTiBBRERJVElPTiB0byB0aGF0IHdhbnRzIHRvIGluZGlj YXRlIHNvbWV0aGluZyBJQ0U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zcGVjaWZpYyw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5lLmcsIHdoZXRoZXIgdG8gZG8gYW4gSUNFIHJlc3RhcnQsIEkgZ3Vl c3MgeW91IGNvdWxkIHVzZSB1ZnJhZyBmb3IgdGhhdC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5C dXQsIEkgZG9uwrl0IHRoaW5rIHRoYXQgaXMgQlVORExFIHNwZWNpZmljLCBpcyBpdD88bzpwPjwv bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsgT2ssIHNv IHdoYXQgeW91IGFyZSBkZXNjcmliaW5nIGlzICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2Vj dGlvbiZxdW90Oy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5CdXQgdGhlIGJ1bmRsZSBzcGVjIGRv ZXNuJ3QgX3F1aXRlXyBndWFyYW50ZWUgdGhpcyByaWdodCBub3csIGFuZCBpdDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnByb2JhYmx5IHNob3VsZG4ndCB0cnkgdG8gZ3VhcmFudGVlIGl0IGVpdGhl ci4gRm9yIGluc3RhbmNlLCA4LjUuMTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmRlc2NyaWJlcyBo b3cgdGhlIG9mZmVyZXIgY2FuIHN1Z2dlc3QgYSBuZXcgdHJhbnNwb3J0IGZvciB0aGUgYnVuZGxl LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmFueSB0aW1lIGl0IHdhbnRzIChhbmQgaXQgY291bGQg cG90ZW50aWFsbHkgYmUgYSBwcmUtZXhpc3RpbmcgdHJhbnNwb3J0PG86cD48L286cD48L3ByZT4N CjxwcmU+JnF1b3Q7c3RvbGVuJnF1b3Q7IGZyb20gc29tZSBvdGhlciBidW5kbGUvbS1zZWN0aW9u ISk7IHdpdGhvdXQgdGFraW5nIHNvbWV0aGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmxpa2Ug dWZyYWcgaW50byBhY2NvdW50LCB0aGlzIGlzIGltcG9zc2libGUgdG8gZGV0ZWN0IGluIHRoZSBJ Q0UgY2FzZS48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT5UaGUgQlVORExF IGdyb3VwcyBjYW4gbm90IHVzZSB0aGUgc2FtZSB0cmFuc3BvcnQsIHNvIGlmIHNvbWVvbmUgaXMg dHJ5aW5nPG86cD48L286cD48L3ByZT4NCjxwcmU+dG8gb2ZmZXIgc3VjaCB0aGluZyB0aGUgYW5z d2VyZXIgc2hvdWxkIHJlamVjdCB0aGUgb2ZmZXIsIG9yIGF0IGxlYXN0IG5vdDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmFjY2VwdCB0aGUgb2ZmZXJlZCB0cmFuc3BvcnRzLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SG93ZXZlciwgeW91IHdv dWxkIGJlIGNvbXBsZXRlbHkgcmlnaHQgaW4gc2F5aW5nICZxdW90O1dlbGwsIGR1aCwgdGhhdCBp czxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRydWUgZm9yIG5vbi1CVU5ETEUgYWxzbyEmcXVvdDss IHdoaWNoIGlzIHdoeSBJIGxpa2UgdGhlIGlkZWEgb2YgZml4aW5nIHRoaXM8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT53aXRoIHVmcmFnLCBzaW5jZSB0aGF0J3MgaG93IHdlIG1ha2UgdGhpcyB3b3Jr IGluIHRoZSBub24tQlVORExFIGNhc2UuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4N CjxwcmU+SSBndWVzcyBJIHN0aWxsIGhhdmUgc29tZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIHdo YXQgdGhlIHByb2JsZW0gaXMuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+TGV04oCZcyB0YWtlIHRoZSBmb2xsb3dpbmcgZXhhbXBsZTo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Jbml0aWFsIG9m ZmVyL2Fuc3dlciBleGNoYW5nZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5hPWdyb3VwOkJVTkRMRSBtaWQxIG1pZDIgbWlkMzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExFIG1pZDQgbWlkNSBtaWQ2PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Tm93LCB5b3UgaGF2ZSB0d28g dHJhbnNwb3J0czogb25lIOKAnG93bmVk4oCdIGJ5IG1pZDEgYW5kIG9uZSDigJxvd25lZCZxdW90 OyBieSBtaWQ0LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJlLW9mZmVyOjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmE9Z3JvdXA6QlVORExF IG1pZDQgbWlkMiBtaWQzPG86cD48L286cD48L3ByZT4NCjxwcmU+YT1ncm91cDpCVU5ETEUgbWlk MSBtaWQ1IG1pZDY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5JbiB0aGUgcmUtb2ZmZXIsIHRo ZSBvZmZlcmVyIGRvZXMgbm90IGNoYW5nZSB0aGUgdHJhbnNwb3J0cyBvZiBtaWQxIGFuZDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPm1pZDQgLSB0aGV5IGFyZSBzdGlsbCB0aGUgc2FtZS4gVGhlIGRp ZmZlcmVudCBpcyB0aGF0IG1pZDIgYW5kIG1pZDMgd2lsbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl Pm5vdyBzdGFydCB1c2luZyB0aGUgdHJhbnNwb3J0IG9mIG1pZDQsIGFuZCBtaWQ1IGFuZCBtaWQ2 IHdpbGwgc3RhcnQgdXNpbmc8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGUgdHJhbnNwb3J0IG9m IG1pZDEuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LCBidXQg YXMgZmFyIGFzIEkgY2FuIHRlbGwgdGhlIGJ1bmRsZSBzcGVjIGRvZXMgbm90IGZvcmJpZCB0aGlz Ojxicj4NCjxicj4NCmE9Z3JvdXA6QlVORExFIG1pZDEgbWlkMiBtaWQzICZsdDstLS0gdXNlcyBw b3J0IDU1NTU8YnI+DQphPWdyb3VwOkJVTkRMRSBtaWQ0IG1pZDUgbWlkNiAmbHQ7LS0tIHVzZXMg cG9ydCA2NjY2PGJyPg0KLi4uPGJyPg0KbT1hdWRpbyA1NTU1IC4uLjxicj4NCmE9bWlkOm1pZDE8 YnI+DQouLi48YnI+DQptPXZpZGVvIDY2NjYgLi4uPGJyPg0KYT1taWQ6bWlkNDxicj4NCjxicj4N CmFuZCB0aGVuIGluIGEgcmVvZmZlcjo8YnI+DQo8YnI+DQphPWdyb3VwOkJVTkRMRSA8Yj5taWQ0 PC9iPiBtaWQyIG1pZDMgJmx0Oy0tLSBtaWQ0IGFuZCBtaWQxIGhhdmUgc3dhcHBlZC4uLjxicj4N CmE9Z3JvdXA6QlVORExFIDxiPm1pZDE8L2I+IG1pZDUgbWlkNjxicj4NCi4uLjxicj4NCm09YXVk aW8gPGI+NjY2NjwvYj4gLi4uICZsdDstLS0gYnV0IHRoZSBvZmZlcmVyIGhhcyBleHBsaWNpdGx5 IGluZGljYXRlZCB0aGF0IDY2NjYgaXMgYXR0YWNoZWQgdG8gbWlkMSBub3c8YnI+DQphPW1pZDpt aWQxPGJyPg0KLi4uPGJyPg0KbT12aWRlbyA8Yj41NTU1PC9iPiAuLi48YnI+DQphPW1pZDptaWQ0 PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IElmIHRoZSBidW5kbGUgc3BlYyBhbGxvd3Mg dGhpcywgJnF1b3Q7dHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9uJnF1b3Q7IGlzIG5vdCBwYXJ0 IG9mIHRoZSBzcGVjOyB0aGUgZnVuZGFtZW50YWwgcnVsZSBpcyAmcXVvdDt0cmFuc3BvcnQgaXMg c2lnbmFsZWQgZXhwbGljaXRseSBldmVyeSB0aW1lJnF1b3Q7LCB3aGljaCBpcyBpbXBvc3NpYmxl IHdpdGggSUNFIHVubGVzcyB1ZnJhZyBpcyB0YWtlbiBpbnRvIGFjY291bnQuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpy ZWQiPk1heWJlJm5ic3A74oCcdHJhbnNwb3J0IGZvbGxvd3MgbS1zZWN0aW9u4oCdIGlzIHdyb25n IHdvcmRpbmcuIFRyYW5zcG9ydCBpcyB3aGF0ZXZlciB0aGUgZmlyc3QgbWlkIGluIHRoZSBhPWdy b3VwOkJVTkRMRSBhdHRyaWJ1dGUgaW5kaWNhdGVzIGl0IHRvIGJlLCBhbmQgaWYgdGhhdCB0cmFu c3BvcnQgYWxyZWFkeSBleGlzdHMNCiB0aGVyZSBpcyBubyBuZWVkIHRvIGRvIGFuIElDRSByZXN0 YXJ0LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpyZWQiPlNvLCBpbiB5b3VyIGV4YW1wbGUsIGkgdGhlIHJlb2Zm ZXIgeW91IGFyZSBzdWdnZXN0aW5nIHRoYXQgbWlkNCwgbWlkMiBhbmQgbWlkMyB1c2VzIHRoZSAm cXVvdDs1NTU1IHRyYW5zcG9ydCZxdW90Oy4gU2luY2UgdGhpcyB0cmFuc3BvcnQgYWxyZWFkeSBl eGlzdHMgKGl0IHdhcyBwcmV2aW91c2x5IHVzZWQgYnkgbWlkMSwgbWlkMg0KIGFuZCBtaWQzKSwg eW91IGRvbuKAmXQgaGF2ZSB0byBkbyBhbiBJQ0UgcmVzdGFydC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6cmVkIj5SZWdh cmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpyZWQiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpZ2h0LiBUaGUgb2Zm ZXJlciBleHBsaWNpdGx5IGluZGljYXRlZCB3aGF0IGl0IHdhbnRzIHRvIGRvLCBhbmQgbm90aGlu ZyBpcyBhbWJpZ3VvdXMuIEkgbGlrZSB0aGlzIHdheSBvZiBkb2luZyB0aGluZ3MuIFdoaWNoIGlz IHdoeSBJIHByZWZlciBjbGFyaWZ5aW5nIHRoZSBzcGVjIHRvIHNheSB0aGF0IHRoaXMgZXhwbGlj aXQgc2lnbmFsaW5nIGlzIHVzZWQgaW4gdGhlIElDRSBjYXNlIHRvbywgcmF0aGVyIHRoYW4gc3Bl Y2lmeWluZw0KIHJlc3RyaWN0aW9ucyBsaWtlICZxdW90O3RyYW5zcG9ydCBmb2xsb3dzIG0tc2Vj dGlvbiZxdW90OyB0byBoYW5kbGUgdGhlIElDRSBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDc7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkkgdG90YWxseSBhZ3JlZSDigJMgdGhlIHRyYW5zcG9ydCBoYXMgdG8g YmUgZXhwbGljaXRseSBpbmRpY2F0ZWQuIEJ1dCwgZG9u4oCZdCB0aGUgSUNFIFNEUCBhdHRyaWJ1 dGVzIGFscmVhZHkgZXhwbGljaXRseSBpbmRpY2F0ZSB0aGUgdHJhbnNwb3J0Pzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj NzBBRDQ3O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgU2FkbHksIG5v dCBxdWl0ZSwgYmVjYXVzZSB0aGVyZSdzIG5vIGNsZWFyIHJlcXVpcmVtZW50IHJpZ2h0IG5vdyB0 aGF0IHRoZSB1ZnJhZyBpcyBkaWZmZXJlbnQgZm9yIGVhY2ggdHJhbnNwb3J0IChhbmQgaW5kZWVk IGl0IGhhcyBub3QgYmVlbiBpbXBsZW1lbnRlZCB0aGF0IHdheSBieSBDaHJvbWUgb3IgRmlyZWZv eCkuIFRoYXQncyB3aGF0IEknbSBhZHZvY2F0aW5nIGZpeGluZywgaW5zdGVhZCBvZiBhZGRpbmcN CiBhIGJ1bmNoIG9mIG5ldyBydWxlcyBmb3IgYnVuZGxlIHdpdGggSUNFLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij5BcyBJIHdyb3RlIGluIG15IGUtbWFpbCBvbiBUaHVy c2RheSwgbXkgdW5kZXJzdGFuZGluZyBvZiBSRkMgNTI0NSBpcyB0aGF0IHRoZSB1ZnJhZyBtdXN0 IGJlIGRpZmZlcmVudCBmb3IgZWFjaCB0cmFuc3BvcnQsIGlmIHlvdSBkbyBhbiBJQ0UgcmVzdGFy dCB5b3UgbXVzdCBjaGFuZ2UNCiB1ZnJhZywgYW5kIGEgY2hhbmdlIG9mIHVmcmFnIHdpbGwgdHJp Z2dlciBhbiBJQ0UgcmVzdGFydC4uIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzcwQUQ0NyI+SWYgaW1wbGVtZW50YXRpb25zIGRvbuKAmXQgZm9sbG93IHRoZSBzcGVjcyBpdCBk b2VzbuKAmXQgcmVhbGx5IG1hdHRlciB3aGF0IHdlIHNwZWNpZnnigKY8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzcwQUQ0 NyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgVGhhdCBj aGFuZ2luZyB0aGUgdWZyYWcgY2F1c2VzIGEgdHJhbnNwb3J0IGNoYW5nZSBpcyBjbGVhciwgYnV0 IHRoZXJlIGlzIHByZXNlbnRseSBubyBsYW5ndWFnZSBzYXlpbmcgdGhhdCB5b3UgY2Fubm90IHN0 YXJ0IG91dCB3aXRoIHRoZSBzYW1lIHVmcmFnIGZvciBldmVyeSBtLXNlY3Rpb24sIGFuZCB0aGlz IGlzIGZ1cnRoZXIgY29uZnVzZWQgYnkgdGhlIGZhY3QgdGhhdCBpY2UtdWZyYWcgaXMgYWxsb3dl ZCB0byBiZSBzZXNzaW9uIGxldmVsLjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzcwQUQ0NyI+T2ssIEkgaGVhciB3aGF0IHlvdSBhcmUgc2F5aW5nLiBXZSBjYW4gYWx3 YXlzIG1hbmRhdGUgdW5pcXVlIHVmcmFnIHZhbHVlcyBpbiBCVU5ETEUsIGFuZCBtYXliZSBhbHNv IGluIDUyNDViaXMgKHRoYXQgZGlzY3Vzc2lvbiBiZWxvbmdzIHRvIHRoZSBJQ0UgV0csIHRob3Vn aCkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzcwQUQ0NyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3MEFENDciPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3MEFENDciPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNzBBRDQ3Ij5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNzBBRDQ3Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B5C6A0FBBESESSMB109erics_-- From nobody Tue Nov 14 11:21:20 2017 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 408A7128799 for ; Tue, 14 Nov 2017 11:21:18 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 WMtl3LkZbSf3 for ; Tue, 14 Nov 2017 11:21:16 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 0EB77124BAC for ; Tue, 14 Nov 2017 11:21:15 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id q18so13647070uaa.0 for ; Tue, 14 Nov 2017 11:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=75WNKqS1i4Jwc38BhNx2dMg6phP64qV+elZghSrn+GE=; b=ceOfdmMIriT4Tghn9seorks9w4BVY+bPASBO0RbjRYd7Hp2QR5uYdDS5/idbnvTVf8 eJkj+q9CuJOneQwUmjlY6izNe3f5FTpMsnQnIUnuLCwUd/oQoaUfWPZyYDkwlHmJyOKw NNEXyBDYHRQ2QjcByZvh+ssbaSpU+3vDLhW4/BDrqdJuM34GgP4uNN0J8luHX4XkgtKN 0WVNVUfuiYLa6NsCGdrj4Bdi5M1SnLNLbQHtJEqQPvR3+AnTEvsd9hRwv6/IGn1EgIGH 4uwriMGn0psWieE9yWBLjh4CdpcEw8XMIVsrFvkV7YM2uUCmcVIcAbfy8Q6v/BDDTUaP wa2A== 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=75WNKqS1i4Jwc38BhNx2dMg6phP64qV+elZghSrn+GE=; b=p6o7tRvonRi6ECpFWjOd+sPgYBf5GgpAt7lbSXM2mWf7ML69MEoev6CvWZVgHSfXH9 Oi+2lddakF4h46DYE00qwteTghyAxfBA8srgpqEmgEvlFSfFROxCpEBQbpYtsxczL/Ho 9zQrTc8GEpNozs3NbnRyoZt/ZlWTlKBEhZKYUCc1w8jpisg++BXlraM+/bVgi2+5H7iZ m4tsNNSBsDXckVI/XKXGR9ho/6Lh/AbqXfYtitZgaRTa/YbFXl8w2uQe7bwNCPt38AlU zkVHNxkIVNsFP+XKmrMeuE/HuUEd3y/I/l4OnYLKVYlp6l3P1/6q+rpEDEtVSCDZh95y CykQ== X-Gm-Message-State: AJaThX4Yh4h4GFpuSpeOAsdFAqFFjFXH+G4q6SXOX7yi/GpINIskPwPQ pWVk9AOuncQkPYY+MfEP4ZaEkYbr9d3HoM0ZeB2UBtUBJwQ= X-Google-Smtp-Source: AGs4zMbMzJkwvNNON4xM0o/phheNct58iEMykTnIdnz1fREnVvIwhqQEq7qoyh5MO3PrxyB66CYghNmzHQnBsQmFOyU= X-Received: by 10.176.80.2 with SMTP id b2mr8405970uaa.198.1510687274497; Tue, 14 Nov 2017 11:21:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.174.215 with HTTP; Tue, 14 Nov 2017 11:20:53 -0800 (PST) In-Reply-To: References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> From: Justin Uberti Date: Tue, 14 Nov 2017 11:20:53 -0800 Message-ID: To: Cullen Jennings Cc: James Pearce , RTCWeb IETF Content-Type: multipart/alternative; boundary="94eb2c18ee445d8657055df64aea" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 14 Nov 2017 19:21:18 -0000 --94eb2c18ee445d8657055df64aea Content-Type: text/plain; charset="UTF-8" Yes - tracked in https://github.com/juberti/draughts/issues/87. On Mon, Nov 13, 2017 at 2:05 PM, Cullen Jennings wrote: > > My recollection is that we agreed to do this but the draft has not been > updated with this yet. > > > On Nov 10, 2017, at 5:36 AM, James Pearce wrote: > > Hi All, > > Apologies for resurrecting this topic from August. Has anything been > decided regarding this? Has it been rolled into other changes, or is it > still being considered? > > Many thanks, > > James > > On 1 September 2017 at 14:57, Cullen Jennings wrote: > >> >> > On Aug 23, 2017, at 3:06 PM, James Pearce wrote: >> > >> > >> > The obvious solution seems to be to change the behaviour of mode 2. >> Rather than using the default route in all cases, we should use the route >> that was used to fetch the origin. This seems to resolve both the usability >> and privacy concerns without reducing existing security. >> >> I agree this is a significant problem and your proposal does seems like a >> better solution that the current text. We should get people to think about >> the implications of that change. >> >> >> > _______________________________________________ > 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 > > --94eb2c18ee445d8657055df64aea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes - tracked in=C2=A0https://github.com/juberti/draughts/issues/87.

On Mon, Nov 13= , 2017 at 2:05 PM, Cullen Jennings <fluffy@iii.ca> wrote:

My recollection is that we agreed to do this but the draft has not been= updated with this yet.=C2=A0


On Nov 10, 2017, at 5:36 AM, James Pe= arce <james@ja= mesandjo.com> wrote:

Hi All,=C2=A0

Apologies for resurrecting this topic fro= m August. Has anything been decided regarding this? Has it been rolled into= other changes, or is it still being considered?

M= any thanks,

James

On 1 September 2017 at 14:57, Cullen J= ennings <fluffy@iii.ca> wrote:

> On Aug 23, 2017, at 3:06 PM, James Pearce <james@jamesandjo.com> wrote:
>
>
> The obvious solution seems to be to change the behaviour of mode 2. Ra= ther than using the default route in all cases, we should use the route tha= t was used to fetch the origin. This seems to resolve both the usability an= d privacy concerns without reducing existing security.

I agree this is a significant problem and your proposal does seems l= ike a better solution that the current text. We should get people to think = about the implications of that change.



_______________________________________________
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

--94eb2c18ee445d8657055df64aea-- From nobody Wed Nov 15 01:48:02 2017 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 98658127337 for ; Wed, 15 Nov 2017 01:48:00 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jamesandjo-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 Gvj8QpxbTpw0 for ; Wed, 15 Nov 2017 01:47:58 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 D0B8B124205 for ; Wed, 15 Nov 2017 01:47:58 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id u42so10074464qte.7 for ; Wed, 15 Nov 2017 01:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jamesandjo-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P6oBBJX+g1xVn7u5fUdI4MzAzKRvLc8bHK4XmWgRlYw=; b=PwDgXICDlb//061GzBqz+B1UcuMdQNqhHOBNlsMpz57ScjOCMwqcLqqnSbyGhLZVd6 5Ngbb5100TX6wrsdB3H44o4dS33v67ECKwX8RKA/tE3iP7XI0jdhXAYSO6ocSBNzfI04 unQz4U2FSllTnaa6zKya+nkG/Yf7N1hnMP7V7qF+9nRPiQCjZFdrXRKD4u54fSkGPUCQ NKPJpyYErMz2wVK3HvFrbe9HtlkBb2geniKpO9SOoiA5PabZUB2rcHT/nJl3cvfNPpBx Gpt+Uz3q9X/a6BRF5w2iPmVEbgXC4twIjiUJCr/zy0uU9TnpT004vWf65ccVehC/Dh4T 3qVA== 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=P6oBBJX+g1xVn7u5fUdI4MzAzKRvLc8bHK4XmWgRlYw=; b=aQsg+aJElvglJFAgAGBVXprapCEC8RdtnW9MTBcpUrNSjWaNSNbG24rF/fK3mKFkV3 iYg78gP99h2YxYvtetSCzmWjC7DuwcLuBSptSGFRjBROgoLO7qKzYtvyW3B56xm8r7zg JcbtmHTX7rcbohuhlykH0LGTC8pHUSK+q3epSASAMbvkllRlXr1EyBIy5XSbdmsnBgnB YgSq/OSD5GPQYNJ7D8768Nosu17nTRfyEiSM6p/o8kVm/cg3g1lLl1aeWcS/nwBnIvOM FHJznDj8VrKU9932PsabB5D5TomHi10N6Ig4rPHMV0KRmNKeJRJ9CEUns1oh5bCOeqM5 ooDA== X-Gm-Message-State: AJaThX4l8MSBLfa8oC4SxDBgM+NQUSPX8KGnFQPhTDK7yrNeTevGyW41 132keooe00Yt27BwQBv59aJO/tR6K2QrirXhoq8JWg== X-Google-Smtp-Source: AGs4zMZatHvwcae375pE5ewicdY656cbxGs6j8pWr+m1UtbAAALcj9zApZrxztqAoYORewnVV5uo2oHSoavA7AW8FwM= X-Received: by 10.237.53.174 with SMTP id c43mr19800356qte.273.1510739277896; Wed, 15 Nov 2017 01:47:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.46.248 with HTTP; Wed, 15 Nov 2017 01:47:57 -0800 (PST) In-Reply-To: References: <768A1C2E-4D4A-44C4-A65D-07728F900C96@jamesandjo.com> <8AACCCBE-CB5D-420C-8B31-C3144D9634F0@iii.ca> From: James Pearce Date: Wed, 15 Nov 2017 09:47:57 +0000 Message-ID: To: Justin Uberti Cc: Cullen Jennings , RTCWeb IETF Content-Type: multipart/alternative; boundary="001a11c0041601fee4055e02669f" Archived-At: Subject: Re: [rtcweb] draft-ietf-rtcweb-ip-handling: Mode 2 and VPN scenarios 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, 15 Nov 2017 09:48:00 -0000 --001a11c0041601fee4055e02669f Content-Type: text/plain; charset="UTF-8" Perfect. Thanks! On 14 November 2017 at 19:20, Justin Uberti wrote: > Yes - tracked in https://github.com/juberti/draughts/issues/87. > > On Mon, Nov 13, 2017 at 2:05 PM, Cullen Jennings wrote: > >> >> My recollection is that we agreed to do this but the draft has not been >> updated with this yet. >> >> >> On Nov 10, 2017, at 5:36 AM, James Pearce wrote: >> >> Hi All, >> >> Apologies for resurrecting this topic from August. Has anything been >> decided regarding this? Has it been rolled into other changes, or is it >> still being considered? >> >> Many thanks, >> >> James >> >> On 1 September 2017 at 14:57, Cullen Jennings wrote: >> >>> >>> > On Aug 23, 2017, at 3:06 PM, James Pearce >>> wrote: >>> > >>> > >>> > The obvious solution seems to be to change the behaviour of mode 2. >>> Rather than using the default route in all cases, we should use the route >>> that was used to fetch the origin. This seems to resolve both the usability >>> and privacy concerns without reducing existing security. >>> >>> I agree this is a significant problem and your proposal does seems like >>> a better solution that the current text. We should get people to think >>> about the implications of that change. >>> >>> >>> >> _______________________________________________ >> 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 >> >> > --001a11c0041601fee4055e02669f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perfect. Thanks!

On 14 November 2017 at 19:20, Justin Uberti <jubert= i@google.com> wrote:

On Mon, Nov 13, 2017 at 2:05 PM,= Cullen Jennings <fluffy@iii.ca> wrote:

My recollectio= n is that we agreed to do this but the draft has not been updated with this= yet.=C2=A0


On Nov 10, 2017, at 5:36 AM, James = Pearce <james@= jamesandjo.com> wrote:

Hi All,=C2=A0

<= div>Apologies for resurrecting this topic from August. Has anything been de= cided regarding this? Has it been rolled into other changes, or is it still= being considered?

Many thanks,

James

On 1 September 2017 at 14:57, Cullen Jennings <= fluffy@iii.ca> wrote:

> On Aug 23, 2017, at 3:06 PM, James Pearce <james@jamesandjo.com> wrote:
>
>
> The obvious solution seems to be to change the behaviour of mode 2. Ra= ther than using the default route in all cases, we should use the route tha= t was used to fetch the origin. This seems to resolve both the usability an= d privacy concerns without reducing existing security.

I agree this is a significant problem and your proposal does seems l= ike a better solution that the current text. We should get people to think = about the implications of that change.



_______________________________________________
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


--001a11c0041601fee4055e02669f-- From nobody Wed Nov 15 02:29:49 2017 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 93E181294DC for ; Wed, 15 Nov 2017 02:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 rcVaxCth1XaQ for ; Wed, 15 Nov 2017 02:29:45 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 88665129447 for ; Wed, 15 Nov 2017 02:29:45 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id i15so6396929pfa.3 for ; Wed, 15 Nov 2017 02:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:subject:message-id:date:cc:to; bh=ttq6gnx/SwBoLcjF0nx83nkz/Pq9z6HF+oO/nbJbplI=; b=WYlL6+KX9T7Xv7x46O31itnAygzVC0gCDgN+UWYrQhOvV5kL6pPbxzs3oCN6vzfB1b +3T1UMCR2v0LtnAdTzzTIlYc729tThkAFeNwoQC/N21UCn8Skl+npUlNanORQanwf8tW bfDMGICR36aU7edypTliy4NOTSFalTTOMz6AE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=ttq6gnx/SwBoLcjF0nx83nkz/Pq9z6HF+oO/nbJbplI=; b=rtc3MMfOyqtUsImaqukZEczhkwX31l8BoR+BHjmT+PbUlorkjW8tbnPpTXef+qvriG s9ByM4jTuCe/gz/tOxfOxQsyaYCEsLt6XXTZulKcGmjFpXzxabpxWtYuHCB0gQvZiKA3 XsijZj7cHzTO1dSJaWkm4YFS7+r6CvCej6mgpIxcVMeM5B+IF1Sp6Sald1vUJqxqeQDI Pjf5wa6sgSJvsGs6x/JND39AWYuwGCbikU09Hj4xiNp08NxIezQGgZ6VJ3WxUAH4QzFB cJn6CSk7GPmV12OtpARGTiaDqRzkU7zeBPvb+UhMUcRlWqGrVzeb7pUZop4Tsmcyct1A w/Vw== X-Gm-Message-State: AJaThX5OUk3s8NSWokAinx54mdYXVoU9DNCxnQrjVNZr5yTcUQYkiEaO q7JoxZEw1vRFQ2pCpToIfSn7TT6PcGo= X-Google-Smtp-Source: AGs4zMZAdsLlpwnK4DrmDN4B3zYVbLmd9vaG1rPxBWhnYU4sgxGkUZpdWKu4J7pidKAHTynA2ZvWOA== X-Received: by 10.159.252.138 with SMTP id bb10mr4966837plb.163.1510741784629; Wed, 15 Nov 2017 02:29:44 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:1d7b:1f1d:98a4:b846? ([2001:67c:370:128:1d7b:1f1d:98a4:b846]) by smtp.gmail.com with ESMTPSA id r16sm33536708pgt.72.2017.11.15.02.29.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 02:29:43 -0800 (PST) From: Nils Ohlmeier Content-Type: multipart/signed; boundary="Apple-Mail=_4A1A1582-E31B-488F-99CD-2806D859CF0D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <5F4CA14A-A894-4EA4-B402-AB1B655E26CA@mozilla.com> Date: Wed, 15 Nov 2017 18:26:30 +0800 Cc: draft-ietf-rtcweb-sdp@ietf.org, Harald Alvestrand To: rtcweb@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [rtcweb] Script to extract the SDP from draft-ietf-rtcweb-sdp-08 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, 15 Nov 2017 10:29:47 -0000 --Apple-Mail=_4A1A1582-E31B-488F-99CD-2806D859CF0D Content-Type: multipart/alternative; boundary="Apple-Mail=_8699D0C6-0131-48DC-86E6-A213619A85FC" --Apple-Mail=_8699D0C6-0131-48DC-86E6-A213619A85FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I quickly created a python script to extract the SDP from = draft-ietf-rtcweb-sdp-08. You can find it here https://github.com/nils-ohlmeier/sdpextractor = But I realized that the text version of the draft actually contains = spaces in places where they don=E2=80=99t belong. I believe these are caused by lines breaks in the XML source of the = draft. Best regards Nils Ohlmeier --Apple-Mail=_8699D0C6-0131-48DC-86E6-A213619A85FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I = quickly created a python script to extract the SDP from = draft-ietf-rtcweb-sdp-08.
You can find it = here https://github.com/nils-ohlmeier/sdpextractor

But I realized that the = text version of the draft actually contains spaces in places where they = don=E2=80=99t belong.
I believe these are caused by = lines breaks in the XML source of the draft.

Best regards
  = Nils Ohlmeier

= --Apple-Mail=_8699D0C6-0131-48DC-86E6-A213619A85FC-- --Apple-Mail=_4A1A1582-E31B-488F-99CD-2806D859CF0D 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+KEFAloMFlYACgkQY2o/VmzJ +KH+cxAAxDL4l7YZ/qF4E/ySXoJl3fpZ/qypCko4UNhwcCHPj2/mnjZFKEaVBNo3 k2GZMDdNSVOLzXcYmb7CxVN0j5ZEnZFV80DMWfCpPNhhmG0El1Ny1LnBrIIZuhV8 kkHv/rOlr7staizibb8l7D/pLSNWaAOi6z3opCsHFnDAs9eeL0kUuxjW6cscXhG5 wBahNYr6YTc2PCEi0KxL6V0wE3CqXCW14dtzqTvc51J+5G/NR4dD/PEEH4nYcdmu k1cBZBjuQmKRZGkqloOxFAISXfH2VQmsfD6iS1JEcA8AWXxX/LB2hhJgXTMlJgOA y5I612dB9xzH4z31b/KSbpZnneTSWGL5lJIlfoqX3b9+xpemmJKj5RDlVT0nOyms Jk/VbbogTSsYDz1LTzDoqN9fLAD1kHQFjxKwvR1pmxj0lHhE9eHqD3HvyFXGzb1g HEcqeWXSwvz/i2nuWm1kGYRXr9KCaUqf8hU8ARND/XNfiPqVOt5WF1ld9u7VLoDj 98i/q0c143FZE18ZvARRyGBL+JiQbp/8ZealRk9honL1DIVwNizcKKnFMTkSCI6+ T12WWK5Gt5XqLfUZVFtrDncJHHQGv3bEhcd5CAbcQyf/5vdYs5+bCa61iPGC8846 MWpNAMc0duGZMXH3GP8kkNBSPqB3RvcBf7ghrTlsBKYeUD9V5+4= =ySlo -----END PGP SIGNATURE----- --Apple-Mail=_4A1A1582-E31B-488F-99CD-2806D859CF0D-- From nobody Wed Nov 15 15:36:20 2017 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 9A869128D8B; Wed, 15 Nov 2017 15:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ug-JjelcpvCd; Wed, 15 Nov 2017 15:36:17 -0800 (PST) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64BC0126CD8; Wed, 15 Nov 2017 15:36:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id CB3057C0DE4; Thu, 16 Nov 2017 00:36:12 +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 yifeZ9f2QHvT; Thu, 16 Nov 2017 00:36:11 +0100 (CET) Received: from [31.133.145.32] (dhcp-9120.meeting.ietf.org [31.133.145.32]) by mork.alvestrand.no (Postfix) with ESMTPSA id E81087C0440; Thu, 16 Nov 2017 00:36:09 +0100 (CET) To: Nils Ohlmeier , rtcweb@ietf.org Cc: draft-ietf-rtcweb-sdp@ietf.org References: <5F4CA14A-A894-4EA4-B402-AB1B655E26CA@mozilla.com> From: Harald Alvestrand Message-ID: <24a418cd-5f57-f560-f582-80c7af0500ad@alvestrand.no> Date: Thu, 16 Nov 2017 00:35:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5F4CA14A-A894-4EA4-B402-AB1B655E26CA@mozilla.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pbTwbjvI21VHUijgH5g4jRR1hsGCWVSDM" Archived-At: Subject: Re: [rtcweb] Script to extract the SDP from draft-ietf-rtcweb-sdp-08 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, 15 Nov 2017 23:36:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pbTwbjvI21VHUijgH5g4jRR1hsGCWVSDM Content-Type: multipart/mixed; boundary="eM5dGxdQenCCkBqfBKQOJbjDgmGslO45e"; protected-headers="v1" From: Harald Alvestrand To: Nils Ohlmeier , rtcweb@ietf.org Cc: draft-ietf-rtcweb-sdp@ietf.org Message-ID: <24a418cd-5f57-f560-f582-80c7af0500ad@alvestrand.no> Subject: Re: Script to extract the SDP from draft-ietf-rtcweb-sdp-08 References: <5F4CA14A-A894-4EA4-B402-AB1B655E26CA@mozilla.com> In-Reply-To: <5F4CA14A-A894-4EA4-B402-AB1B655E26CA@mozilla.com> --eM5dGxdQenCCkBqfBKQOJbjDgmGslO45e Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 11/15/2017 11:26 AM, Nils Ohlmeier wrote: > Hello, > > I quickly created a python script to extract the SDP from > draft-ietf-rtcweb-sdp-08. > You can find it here=C2=A0https://github.com/nils-ohlmeier/sdpextractor= > > But I realized that the text version of the draft actually contains > spaces in places where they don=E2=80=99t belong. > I believe these are caused by lines breaks in the XML source of the dra= ft. > > Best regards > =C2=A0 Nils Ohlmeier > Would it be easier to extract from the XML than from the text? At least we would only get spurious stuff that was present in the XML, not spurious stuff that was added during the XML to text conversion. --=20 Surveillance is pervasive. Go Dark. --eM5dGxdQenCCkBqfBKQOJbjDgmGslO45e-- --pbTwbjvI21VHUijgH5g4jRR1hsGCWVSDM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJaDM9VAAoJEGsBVt6Jonw0JSoP/12Cbd8OChFZt49U+O4A/ld1 f5pPD2wrReWgIITS3VEhYjHXJ9vwN9L+NEPTo5lvQK05q6QdbfjesrFeul0D74B/ 0cImgSY19ufFlIULaAG8XoJKdHr3DxPToEectaB94rNiAVkhqGZJwiYGqfZsEeoI Ie/kRuYaAUDFrDFenvd7MG5/Jks+8Tnyn7zYIFmaBn+1W4y2FVyWDgbDMkLvlqTa 5tjRSMrbGCL06Q2GaOgh/Y9GX0tXt6urtd4L6l3o3rvfUv4IYI/B/Ls4pSJzQuiC UTkyl+KgwllvI7Mm1AvfHikhFqyJofp7iCcuF7qit+3+2W2JWS3oBc2E0a/SIbfW Po8Zo5Q2SkkJaSx1p5kwtADffBl3aY6GQ1lcE0+bbCGT5ECJIUEXfMzQyiT+WltE 5UYuCHsfuPOEib4XsL9aBaGPVpZHRnsPg1IGoDS85gUyQOVc/72dmpb5Hitvdwix OYAl/k1QXhigqvwCFiZgxYoZNFj0V972VGJvKpkIOCLickJ8vo8xNoJDj9WCz/sW GPwgK0zLY5kUhEmOBY8DomYMpJVp66Ao32M2MQB+T+K9PpvOi+zS9ML7i+WnVLzq ew6CTbvTbppq5ZGB9oCZUbZRu+A2VREr2vl6QhOXy3ceB5/+npl2NAViAho436ox WKiwcbo3PcJyv3FdS5ma =ZSPM -----END PGP SIGNATURE----- --pbTwbjvI21VHUijgH5g4jRR1hsGCWVSDM-- From nobody Wed Nov 15 17:08:47 2017 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 601AC1292FD for ; Wed, 15 Nov 2017 17:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 0_6H3lOCoeQM for ; Wed, 15 Nov 2017 17:08:44 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 A5194120227 for ; Wed, 15 Nov 2017 17:08:44 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id l19so16752825pgo.2 for ; Wed, 15 Nov 2017 17:08:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ho3Aa1MdmKeKXA874/daJxLI9HWLkkNLLxSYPjF4SuM=; b=jnkEm7rdC2B7IeBOe2Ng+pEewFSm2T+Q6RBIHDxAFYelzflkfZUbTSEzpY8wZQZ8Ab ur5owf+RA/d0v3OMDOvVmcQNNErpnMksqpLJTG0SO288a086Zf6VKmF6Fp06B5KlMRFX wtl2+LULO7fSUyT6P5sKPUDInDTv8NZ6KeHJg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ho3Aa1MdmKeKXA874/daJxLI9HWLkkNLLxSYPjF4SuM=; b=k+HcWUusfNjTxdn3C9qTOFy2mEK2jijnrwk73AHy/Nt4yZulMH7CY0OZxTWTPz19b6 Nv8T4NVtPzMaAlwznHDBT78jtnYcFolJaRU1Bd7Wa/3Y9Gc5hYZAxexxZlq7dBq2MWmS upzl+GMRkyrI3/lsbAHpujBhzZjsy+mia+fhrjv7m+SKhPDOoggju8S4vypsIC75vzkk vDBxow6GeqRG7YReqauQsfFoCG222JF9AMmrJRpX1zlsSUCdRNenurg2Y89YprCf9d8L 6fmT+zxwmtfnWZdJtvQtDgm1V3PWxmWmCeexOxkDtxW6YQQ1H0RaC8t2sMvSeACEB1rP 755Q== X-Gm-Message-State: AJaThX6Ef09a+IavnSzRiTtC7DBRkmgdvYn3xv7nAEm5VUQgMZT2Fvua upg5mBd02BVnYMkEe4jclv0W5MizAUo= X-Google-Smtp-Source: AGs4zMZ9gwUGAdteAzW20PyvPjY2vekKPZtEf4cpTds1jT4JKn6yxfDMfpxGwt9AIu8RpSUoOsAKgg== X-Received: by 10.159.218.67 with SMTP id x3mr18414272plv.1.1510794524153; Wed, 15 Nov 2017 17:08:44 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:80bc:9e69:db5:f607? ([2001:67c:370:128:80bc:9e69:db5:f607]) by smtp.gmail.com with ESMTPSA id l1sm36048966pgp.92.2017.11.15.17.08.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 17:08:43 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <0753959C-EE92-4D64-956B-4ED1AA43513D@sn3rd.com> Date: Thu, 16 Nov 2017 09:08:40 +0800 To: RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [rtcweb] RTCWEB@IETF100: Minutes Posted 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, 16 Nov 2017 01:08:46 -0000 Thanks to Ben Schwartz for taking minutes. I=E2=80=99ve uploaded them = to the meeting material managers: https://datatracker.ietf.org/meeting/100/session/rtcweb I=E2=80=99ll incorporate any comments. spt= From nobody Wed Nov 15 17:22:09 2017 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 8072D124319 for ; Wed, 15 Nov 2017 17:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 ZMnQE8bNDKLP for ; Wed, 15 Nov 2017 17:22:06 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (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 D3F81120227 for ; Wed, 15 Nov 2017 17:22:06 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id u70so13558863pfa.7 for ; Wed, 15 Nov 2017 17:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=V29rcSy4YQCcTkh2OljaGKLmsdJcE1knuAlSIJTgbWg=; b=Labr9WQQQ6baDn90TpuLZYJX4AeZMhQKg+TCAh51k67pvRrjtYrUW1kT5y5xRUXHwR GO2bKgu1FrwjFfbwxdq32hAK/skTyi0rbgj5/jyrThflrk1uLJpBKdCZ5dvgFcAjtSiG e3FRjkQTQoEu7JiPc1iwaC9tiXtGDvWdFd+Xg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=V29rcSy4YQCcTkh2OljaGKLmsdJcE1knuAlSIJTgbWg=; b=tlvWCVvDdCrnkQJpZAF0A6czVwnXUS/xsk6cST502L0CZVhFDNWTDLyVzcVB+cQg8l 9+jh/u5/NBmKRdXkIR9WsiXRj3b6vnKrVl1lPSEXtWYQQQqyvScpyxDE5Nk3wG2WBA/t vqwQZDu5MNYl8okpiVpIL85giu1sjCB8TxT8NhIjLWixnyhpPJocumkq/eS4Oq9/FwhF DEw8/Hf18qoK1S2rugq4kqDKpb07rPZmnqnygxCUd+Upy0w9bSu5H58LeSBFu/BnsRXT XW+2mqwOL11ZCcdA5+oXOWMkVz6UTB5VkKfe6/9Y88WQVtQmY8mrBpJ/JneMJsDcZ2zF Elrg== X-Gm-Message-State: AJaThX4JY+XwjXWmnfSs3/zXIrASi3M96sYyxSmrka89dEEtaPTipDzF l1mWqt6BiCHoi3kjFW4Znxi4AtFuarU= X-Google-Smtp-Source: AGs4zMaX4gp1CSVRCW9dfzyDle8xAeg+Cfxp+AdyjWmrnS+jGiBsYGAwOoijGhXRAC9HmrMmr0UG5Q== X-Received: by 10.99.95.133 with SMTP id t127mr17407153pgb.368.1510795326348; Wed, 15 Nov 2017 17:22:06 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:80bc:9e69:db5:f607? ([2001:67c:370:128:80bc:9e69:db5:f607]) by smtp.gmail.com with ESMTPSA id v28sm312299pfl.118.2017.11.15.17.22.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 17:22:05 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <5D5D5547-9D48-496D-ACF6-6283EE8E8FF6@sn3rd.com> Date: Thu, 16 Nov 2017 09:22:03 +0800 To: RTCWeb IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [rtcweb] WGLC for draft-ietf-rtcweb-security 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, 16 Nov 2017 01:22:08 -0000 All, This is the WGLC for the "Security Considerations for WebRTC=E2=80=9D = draft available @ = https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security/. Please = review the draft and send your comments to this list by Friday, December = 1st, 2017. Thanks, C/T/S= From nobody Thu Nov 16 18:35:19 2017 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 326A5126CB6; Thu, 16 Nov 2017 18:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 m03ZyICyeBQy; Thu, 16 Nov 2017 18:35:16 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 67580126B71; Thu, 16 Nov 2017 18:35:16 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 4184A2DE3A1E6; Fri, 17 Nov 2017 02:35:14 +0000 (GMT) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 17 Nov 2017 02:35:15 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 10:35:14 +0800 From: Roni Even To: "payload@ietf.org" CC: "rtcweb@ietf.org" Thread-Topic: WGLC on RTP Payload Format for Flexible Forward Error Correction Thread-Index: AdNfS7qfdexsNmKuR5uCq/QxumH+GA== Date: Fri, 17 Nov 2017 02:35:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.42.64] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [rtcweb] WGLC on RTP Payload Format for Flexible Forward Error Correction 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: Fri, 17 Nov 2017 02:35:18 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to start a three week WGLC on RTP Payload Format for Flexible = Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05. The WGLC will end on November 7th Mo has posted some clarifications to the payload WG mailing list payload m= ailing list archives Please send comments to the payload mailing list. THe double posting is to notify RTCweb WG that the WGLC has started since = this document is needed for RTCweb Roni Even Payload WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to start a three week WGLC on RTP Payload Format for Flexible Forward Error Correction in draft-ietf-payload-flexible-fec-scheme-05.

The WGLC will end on November 7th

 

Mo has posted some clarifications to the payload WG = mailing list  payload mailing list archives

 

Please send comments to the payload mailing list.

THe double posting is to  notify RTCweb WG that the WGLC has started since this document is ne= eded for RTCweb

 =

 =

Roni Even

Payload WG co-chair=

 =

 

--_000_6E58094ECC8D8344914996DAD28F1CCD83775ADGGEMM506MBXchina_-- From nobody Fri Nov 17 21:40:42 2017 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 2B96612711A; Fri, 17 Nov 2017 21:40:34 -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 aZJ2QQmwDgbE; Fri, 17 Nov 2017 21:40:26 -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 26888124207; Fri, 17 Nov 2017 21:40:25 -0800 (PST) X-AuditID: c1b4fb30-a0dff70000002554-4d-5a0fc7c848d3 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C8.95.09556.8C7CF0A5; Sat, 18 Nov 2017 06:40:24 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0352.000; Sat, 18 Nov 2017 06:40:23 +0100 From: Christer Holmberg To: mmusic CC: RTCWeb IETF Thread-Topic: BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer Thread-Index: AdNgJ0q7n/w0ioPdQOmqfDRPNH59Dw== Date: Sat, 18 Nov 2017 05:40:22 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> 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: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM2K7uu6J4/xRBs/38FtMXf6YxWLtv3Z2 ByaPJUt+MgUwRnHZpKTmZJalFunbJXBltBw5zFbwQq7iw7pG9gbGc1JdjJwcEgImEqsamhm7 GLk4hAQOM0o07V7BCuEsYZRYN2MVSxcjBwebgIVE9z9tkAYRARmJvZs2M4PYzAKKEl+Wz2cD sYUFkiWW3XjNClGTIdHbcpoZwtaTePDjEFicRUBV4t27JWAjeQV8JV4eUQcJMwqISXw/tYYJ YqS4xK0n85kgbhOQWLLnPDOELSrx8vE/VghbSWLt4e0sEPX5Eh+alrOD2LwCghInZz5hmcAo NAvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWLU4uTctONjPRSizKT i4vz8/TyUks2MQJj4+CW3wY7GF8+dzzEKMDBqMTDO+sof5QQa2JZcWXuIUYJDmYlEd4Zy/mi hHhTEiurUovy44tKc1KLDzFKc7AoifOe9OSNEhJITyxJzU5NLUgtgskycXBKNTDOdFUz4uUM KZVg/mEbNct5Ze6cmF5hV61tm6r+iVh7f9otJsYUwMTZdCBV+dei6E3xVpOu3alLKV3ezXOt tU9wq8d7Z8GtHGJ3Wlor9i9y5GVu9uT7wHrfxedTpyLzhVyngGNnz8heSqoL2mh8vvHzUgEv 370rOvWva17vNmmIdWh9u3O2uBJLcUaioRZzUXEiAFedrimJAgAA Archived-At: Subject: [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer 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: Sat, 18 Nov 2017 05:40:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (CC:ing RTCWEB, but please reply on the MMUSIC list) Hi, Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is. Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add wi= thin the same offer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(CC:ing RTCWEB, but please reply on the MMUSIC list)=

 

Hi,

 

Would anyone object to not allowing moving m- sectio= ns between BUNDLE groups within a single O/A transaction? The documentation= of that is a little more complicated than I thought, and there is a risk t= he text becomes more confusing than it already is.

 

Note, that one could still send an offer where an m-= section is moved out of a BUNDLE group, and then send another offer where = the m- line is added to another BUNDLE group (following the normal procedur= es for adding an m- section to a BUNDLE group). But, one would not be allowed to remove and add within the same of= fer.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6BFF74CCESESSMB109erics_-- From nobody Sat Nov 18 09:17:08 2017 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 E7154124BFA; Sat, 18 Nov 2017 09:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 xEj7Hdaps8b5; Sat, 18 Nov 2017 09:17:00 -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 07209120726; Sat, 18 Nov 2017 09:16:59 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-66-5a106b09981e Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.07.19528.90B601A5; Sat, 18 Nov 2017 18:16:58 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0352.000; Sat, 18 Nov 2017 18:16:57 +0100 From: Christer Holmberg To: mmusic CC: RTCWeb IETF Thread-Topic: BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer Thread-Index: AdNgJ0q7n/w0ioPdQOmqfDRPNH59DwAaahoA Date: Sat, 18 Nov 2017 17:16:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42KZGbFdQpcrWyDK4NVFVoupyx+zWKz9187u wOSxZMlPpgDGKC6blNSczLLUIn27BK6MeUv3sxWcM6j4e/M/cwPjSa0uRk4OCQETicPXfrJ0 MXJxCAkcZpRYfuc7K4SzhFFi2pW3zF2MHBxsAhYS3f+0QRpEBGQk9m7azAxiMwsoSnxZPp8N xBYWSJfonXSACaImQ6K35TQzhG0k8a9vJQvIGBYBVYm+0yEgYV4BX4nzDWtYQWwhIPt/12dG EJtTwE9iyqJOsFZGATGJ76fWMEGsEpe49WQ+E8TNAhJL9pxnhrBFJV4+/scKYStJNC55wgpR ny+xfPtUZohdghInZz5hmcAoMgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEF jOyrGEWLU4uLc9ONjPRSizKTi4vz8/TyUks2MQJj6eCW31Y7GA8+dzzEKMDBqMTDWxUoECXE mlhWXJl7iFGCg1lJhDc3CSjEm5JYWZValB9fVJqTWnyIUZqDRUmc96Qnb5SQQHpiSWp2ampB ahFMlomDU6qBkX+eUXfaDeZg1z8J4ntj3LJ87/792T9fyiPB0n7iXcFHx9Zey97Ifdv+3t/Q BJHUXXPbuNILW/p8l/1pZM94I7H6x7mKvwKX1j/oVzxcPXtNYU7h/CfBoZ3v72btXeew/Ef0 lVqrjRqG83nEz8Zc3NMg4bMgx7pl/6/EvSx8z+fd9amdNaNwnhJLcUaioRZzUXEiACs5jf6h AgAA Archived-At: Subject: Re: [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer 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: Sat, 18 Nov 2017 17:17:02 -0000 --_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The change below would look something like this: https://github.com/cdh4u/draft-sdp-bundle/pull/44 (Also contains a few spelling fixes) Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18 November 2017 07:40 To: mmusic Cc: RTCWeb IETF Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE g= roups within a single SDP offer (CC:ing RTCWEB, but please reply on the MMUSIC list) Hi, Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is. Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add wi= thin the same offer. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The change below would= look something like this:

 

https://github.com/cdh4u/draft-sdp-= bundle/pull/44

 

(Also contains a few s= pelling fixes)

 

Regards,

 

Christer

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 18 November 2017 07:40
To: mmusic <mmusic@ietf.org>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between B= UNDLE groups within a single SDP offer

 

(CC:ing RTCWEB, but please reply on the MMUSIC list)=

 

Hi,

 

Would anyone object to not allowing moving m- sectio= ns between BUNDLE groups within a single O/A transaction? The documentation= of that is a little more complicated than I thought, and there is a risk t= he text becomes more confusing than it already is.

 

Note, that one could still send an offer where an m-= section is moved out of a BUNDLE group, and then send another offer where = the m- line is added to another BUNDLE group (following the normal procedur= es for adding an m- section to a BUNDLE group). But, one would not be allowed to remove and add within the same of= fer.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B6BFFAEE9ESESSMB109erics_-- From nobody Sat Nov 18 12:18:44 2017 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 15536126D46 for ; Sat, 18 Nov 2017 12:18:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 rdbJ5g_mIOcJ for ; Sat, 18 Nov 2017 12:18:40 -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 C84D2124C27 for ; Sat, 18 Nov 2017 12:18:40 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id 207so4386995pgc.12 for ; Sat, 18 Nov 2017 12:18:40 -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=JBcuMq9XvryopDYqxGYZT2JIZG8PCoPjfS/iPz0wbtI=; b=Bw0BVTmq08SJo476QK/VLGtImRb0dfIziCtyNcWtewICM4x8FaGaXl0Vt39aTlsWQx xzo11t6A2ao5cQGM4x+HHIrlS9My8DYilEhuUe1Vesy6XuRD3Zmw3QO1sc/cVCWpARZ3 NZjV4fr9J1xNPfa/N0NG7pb43Tr5e1E7PWSLo= 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=JBcuMq9XvryopDYqxGYZT2JIZG8PCoPjfS/iPz0wbtI=; b=IB4LDujCsRHMEvfFZSU2KmaGNcXvS1fNWaA72zXOVVGUAmok7u+9d/ly8IAZnGNmZj RBFx2W5XqU3edrvQSuBcz6CCdoffoUIkyTCb4Fyk8oi4awfT75BhRH6lmADnCECMb8Jt t2zBq68PWfF+CTGgUz0a635kE2ifcQ7klIQWcbBrFifyZzaamRs4GJ80p7PGEyATI0ue FGCKUKRtaojp5WsTebXQVRheVi/aDrBxlWp8qHxE3j9QqPLPQosQ8C7b3lHnaQ10nsYn m+mbwQAZExMNDcmk1IqTq/tP50VBiM91FMg/UC4RewWz2yo1W3eJrishtmhlokJpH4g9 TX6w== X-Gm-Message-State: AJaThX7b3SWyC2v9X9wprZeQdRZgGvuv2dAQZudNpNdmBWlBUGVsW35G I2rXXW6e61z2ILP+FMQIqCriwA== X-Google-Smtp-Source: AGs4zMa28tDgV/hKWoSCP0N8dIHeMVod2pMsy7r3DRr8c0D4Dk5mRPWGM+R04B9n33fr8n24fThyIQ== X-Received: by 10.84.128.72 with SMTP id 66mr9413542pla.119.1511036320098; Sat, 18 Nov 2017 12:18:40 -0800 (PST) Received: from ?IPv6:2601:647:4600:3f31:1d4d:1a81:316e:fdc6? ([2601:647:4600:3f31:1d4d:1a81:316e:fdc6]) by smtp.gmail.com with ESMTPSA id v64sm12775138pfi.187.2017.11.18.12.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Nov 2017 12:18:38 -0800 (PST) From: Nils Ohlmeier Message-Id: <2F4EE4D9-12CF-4FA0-A038-2EBECCCB8035@mozilla.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Sat, 18 Nov 2017 12:18:35 -0800 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se> Cc: mmusic , RTCWeb IETF To: Christer Holmberg References: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer 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: Sat, 18 Nov 2017 20:18:43 -0000 --Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83 Content-Type: multipart/alternative; boundary="Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41" --Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m in favor of your proposed change, because the use case is = small, there is a work around, and the code for handling this (hopefully = rare) use case is really complex. Best regards Nils Ohlmeier > On Nov 18, 2017, at 09:16, Christer Holmberg = wrote: >=20 > The change below would look something like this: >=20 > https://github.com/cdh4u/draft-sdp-bundle/pull/44 = >=20 > (Also contains a few spelling fixes) >=20 > Regards, >=20 > Christer > =C2=A0 <> > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer = Holmberg > Sent: 18 November 2017 07:40 > To: mmusic > Cc: RTCWeb IETF > Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between = BUNDLE groups within a single SDP offer >=20 > (CC:ing RTCWEB, but please reply on the MMUSIC list) >=20 > Hi, >=20 > Would anyone object to not allowing moving m- sections between BUNDLE = groups within a single O/A transaction? The documentation of that is a = little more complicated than I thought, and there is a risk the text = becomes more confusing than it already is. >=20 > Note, that one could still send an offer where an m- section is moved = out of a BUNDLE group, and then send another offer where the m- line is = added to another BUNDLE group (following the normal procedures for = adding an m- section to a BUNDLE group). But, one would not be allowed = to remove and add within the same offer. >=20 > Regards, >=20 > Christer > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb --Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80= =99m in favor of your proposed change, because the use case is small, = there is a work around, and the code for handling this (hopefully rare) = use case is really complex.

Best regards
  Nils Ohlmeier

On Nov 18, 2017, at 09:16, Christer Holmberg <christer.holmberg@ericsson.com> wrote:

The = change below would look something like this:
 
 
(Also = contains a few spelling fixes)
 
Regards,
 
Christer
 
From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf = Of Christer = Holmberg
Sent: 18 November 2017 07:40
To: mmusic <mmusic@ietf.org>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: [MMUSIC] BUNDLE: = Disallowing moving an m- section between BUNDLE groups within a single = SDP offer
 
(CC:ing RTCWEB, but please reply on the = MMUSIC list)
 
Hi,
 
Would anyone object to not allowing moving m- sections = between BUNDLE groups within a single O/A transaction? The documentation = of that is a little more complicated than I thought, and there is a risk = the text becomes more confusing than it already is.
 
Note, = that one could still send an offer where an m- section is moved out of a = BUNDLE group, and then send another offer where the m- line is added to = another BUNDLE group (following the normal procedures for adding an m- = section to a BUNDLE group). But, one would not be allowed to remove and = add within the same offer.
 
Regards,
 
Christer
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

= --Apple-Mail=_6F607363-A763-4B09-904E-1E61E6992E41-- --Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83 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+KEFAloQlZwACgkQY2o/VmzJ +KHZwBAAiwPw7i3BdUR8q/UdKVgSreBld+O5QGcLaqHgRiuSe/6iHemO0OWBDtOm pK8Nf5JKOHXxv29JW2aKEEvU4F/t6S+bCr8GDaQNuxPBzm72TxDughZXdoJbQvIw UtSDH0LqsA8w9yVmlJMA7pZtrEZEfB/ih5QK8QYcjbV4T7W0mlY88AC1BYlu3jfV IFGRBlntXfaz7JQYAZ53jcAIy3GktNKNiRdixd3T55GoKn3aq50p/qdMZKnl8Qpi I1gEe14gEBys3ycRlfnab5eXCXaMq54XrbXiLUVpjRGFgyYDD6O0+4Ew6FIuf+db juGTDKSrqQrdnA1nnkQxOPpcy2lDyRAreuuLmigs4VingYJI5qWnmTzPvuMh2lW2 uiAt7etf3yYgI/cxg46EhZNxaPf8hqdtD70B4xngv+mpLhXjqO0me/uG7mYMf9TL ppQCwY0AFg/MlrxAnmnyBMwnUdr2subWKH+drg1PJMx9NURkjMqfNi0TQKycgsWy uln5zsKjm/vSqTu0zCh6ehT9fIaUewpR5Cm8rAxaVUBZlZri2EIPdekWJhrgwNS6 4YU51CmO5fvDqCjBcsU7nnG9ta1GoVCY9N7YmNWqhjSNA6w1y20OoLKIrX/DfCeY Zu5pkZsnyIiU5GrLi1br4+P97Uj5/5k3HBipUdofY+WdKk4WxRM= =TpGI -----END PGP SIGNATURE----- --Apple-Mail=_C6A149C9-9EB8-4BB3-905F-5E2087FDDB83-- From nobody Sat Nov 18 20:37:55 2017 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 E4325120725; Sat, 18 Nov 2017 20:37:52 -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 gr5UFXoAAzll; Sat, 18 Nov 2017 20:37:51 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 A612E1242F5; Sat, 18 Nov 2017 20:37:50 -0800 (PST) X-AuditID: c1b4fb2d-f23ff70000001e3d-85-5a110a9c505d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 84.CC.07741.C9A011A5; Sun, 19 Nov 2017 05:37:49 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0352.000; Sun, 19 Nov 2017 05:37:48 +0100 From: Christer Holmberg To: Nils Ohlmeier CC: mmusic , RTCWeb IETF Thread-Topic: [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer Thread-Index: AdNgJ0q7n/w0ioPdQOmqfDRPNH59DwAaahoAAARFFIAAE4e8MA== Date: Sun, 19 Nov 2017 04:37:47 +0000 Message-ID: <3EF428FE-0764-4CAE-8714-2A8981E7F6CF@ericsson.com> References: <7594FB04B1934943A5C02806D1A2204B6BFF74CC@ESESSMB109.ericsson.se> <7594FB04B1934943A5C02806D1A2204B6BFFAEE9@ESESSMB109.ericsson.se>, <2F4EE4D9-12CF-4FA0-A038-2EBECCCB8035@mozilla.com> In-Reply-To: <2F4EE4D9-12CF-4FA0-A038-2EBECCCB8035@mozilla.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbHdTHcul2CUwaWbjBZTlz9msbg+bzKj xdp/7ewOzB5Llvxk8ug70MUawBTFZZOSmpNZllqkb5fAlbH49lLmgl/JFf0LH7A2ME4N72Lk 5JAQMJH4tPMeYxcjF4eQwGFGiQMP3zFBOEsYJf7OPs3cxcjBwSZgIdH9TxvEFBHQlDixkQ/E ZBawlvh2QwhkjLBAgcT/hU2sILaIQKHEgo4ZbBC2k0TXnO9MIDaLgKrEgamLwWp4BewlFu9b zgqx6QijxJzHX5lBEpxAidMnb4HZjAJiEt9PrQFrZhYQl7j1ZD4TxM0CEkv2nGeGsEUlXj7+ xwpRkyzxbtd1FogFghInZz5hmcAoPAtJ+ywkZbOQlEHEDSTen5vPDGFrSyxb+BrK1pfY+OUs I7L4Akb2VYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBcXRwy2/dHYyrXzseYhTgYFTi4T3/ XiBKiDWxrLgy9xCjBAezkghvbhJQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO9JT94oIYH0xJLU 7NTUgtQimCwTB6dUA+NapePMdc89uiYwqaRw7Zh2a8rMZQoXd67WMS4SOJL/+mTokn4j1m2L hJdtS3x75P93sXsqpzd0dWWYfS3c/OPm6azg29IfWb67F95s7Kp61ctb+nf3x8zHnRIHStZ8 W5WR7HnbxmTVs0M1GxX0KyVXL2fILNx5XaPzrnzbu6R5Vx9OTs+a0c2vxFKckWioxVxUnAgA 5fjFlp8CAAA= Archived-At: Subject: Re: [rtcweb] BUNDLE: Disallowing moving an m- section between BUNDLE groups within a single SDP offer 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: Sun, 19 Nov 2017 04:37:53 -0000 --_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Nils! Unless someone objects, the plan is to merge the PR and submit a new versio= n of the draft next week. Then we can hopefully do the pub req. Regards, Christer Sent from my iPhone On 18 Nov 2017, at 23.18, Nils Ohlmeier > wrote: I=92m in favor of your proposed change, because the use case is small, ther= e is a work around, and the code for handling this (hopefully rare) use cas= e is really complex. Best regards Nils Ohlmeier On Nov 18, 2017, at 09:16, Christer Holmberg > wrote: The change below would look something like this: https://github.com/cdh4u/draft-sdp-bundle/pull/44 (Also contains a few spelling fixes) Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 18 November 2017 07:40 To: mmusic > Cc: RTCWeb IETF > Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE g= roups within a single SDP offer (CC:ing RTCWEB, but please reply on the MMUSIC list) Hi, Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is. Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add wi= thin the same offer. Regards, Christer _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks Nils!

Unless someone objects, the plan is to merge the PR and submit a new v= ersion of the draft next week. Then we can hopefully do the pub req.

Regards,

Christer


Sent from my iPhone

On 18 Nov 2017, at 23.18, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:

I=92m in favor of your proposed change, because the use case is small,= there is a work around, and the code for handling this (hopefully rare) us= e case is really complex.

Best regards
  Nils Ohlmeier

On Nov 18, 2017, at 09:16, Christer Holmberg <christer.holmberg@ericss= on.com> wrote:

The change below would = look something like this:
 <= /o:p>
https://github.com/cdh4u/draft-sdp-b= undle/pull/44
 <= /o:p>
(Also contains a few sp= elling fixes)
 <= /o:p>
Regards,
 <= /o:p>
Christer
 
From: mmusi= c [mailto:mmusic-boun= ces@ietf.org] On Behalf Of Christer H= olmberg
Sent: 1= 8 November 2017 07:40
To: mmu= sic <mmusic@ietf.org&g= t;
Cc: RTC= Web IETF <rtcweb@ietf.org<= /a>>
Subject: [MMUSIC] BUNDLE: Disallowing moving an m- section between BUNDLE groups w= ithin a single SDP offer
 
(CC:ing RTCWEB, but please reply on the MMUSIC list)<= /div>
 
Hi,
 
Would anyone object to not allowing moving m- sections between BUNDLE group= s within a single O/A transaction? The documentation of that is a little mo= re complicated than I thought, and there is a risk the text becomes more co= nfusing than it already is.
 
Note, that one could still send an offer where an m- section is moved out o= f a BUNDLE group, and then send another offer where the m- line is added to= another BUNDLE group (following the normal procedures for adding an m- sec= tion to a BUNDLE group). But, one would not be allowed to remove and add within the same offer.
 
Regards,
 
Christer
___________________________________________= ____
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

--_000_3EF428FE07644CAE87142A8981E7F6CFericssoncom_-- From nobody Sun Nov 19 01:07:33 2017 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 454EF126BF0 for ; Sun, 19 Nov 2017 01:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=networked-media.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 ue0zX5bmfnKx for ; Sun, 19 Nov 2017 01:07:26 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 C1108120724 for ; Sun, 19 Nov 2017 01:07:25 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id a63so5496942wrc.12 for ; Sun, 19 Nov 2017 01:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networked-media.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P5NfXQpqDz2qARYU/1GLFfHUEa/Te4IKY473axZyd3Y=; b=eoTe6y2lwILxbw3aAtSPXCWEIG1smNu8bOqpf4rZrbUjHEjfclg2p33qdY2L/CdUss L2AUYXnbdKqBUTWP1L17fHmXO/IY5uRfN/RHa+HGeARYeecRIzaU/w0tx26N+GFKzfP9 D2zYjFBMO5hc9gfxxut3lhzAUBU5vihSNU0zKDF7i4FIATL9hMrD62dArbMDNRjStb/K ZK8fWgCcW3rQHqXSVsQcrgigH0z48oOwOpR7zYqCIupnSRsxwSPf0qVNckNgQtRU1jUz 76OrHzRRtxM0N2e/jyu0rcpuBmaa2x4Rw9ze9KHRduDZV9jicoaI/2w55jCKNiNMUL0k CPFg== 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=P5NfXQpqDz2qARYU/1GLFfHUEa/Te4IKY473axZyd3Y=; b=AKi3pSX3DsNA+IDmygIH5NDbqe4QnwpScLmx5GVs24frVe9F9Rqt1RUHlQn7DaR7ED GXAuZ79ijyswPGBTkXy+zPMWOpXTuBsRO5wQRHCYHzbAqMPyrVTsfhWvhjlz3zy4Y6xd VlHGgG2G2ZNb2sGoR+GPoaW8pSNG0Dl6ZoNtzv/Z1QndNtMYmsjRpBhzCkkHTjW7tV54 JE9KIYNo6LXcezY8vDj5yO1lDTaAogUhMmhbbizcatbPbFcG1OLVBdZHgXcJaV+7WZW/ 0hPVmexVaVBmutFphcjM5jVzT0vXrVc7YTpWi/YMc7xSv7usw7UmGb4c8mK5jB+tFaFD PRTQ== X-Gm-Message-State: AJaThX5GUfCTpY6cgs3IYl7vCzfpejrgZnbPm9roLeknYlYHWIAlQM36 ncjqbtRRJxBwdhjQoBvR/sigDg== X-Google-Smtp-Source: AGs4zMbj03+h4+fDREZOyjzUnf3Tss05GBNdDgi7MFibsEkwp5NFnTWtvEDiiLgxFnpjimvq+L8lZw== X-Received: by 10.223.164.22 with SMTP id d22mr9418142wra.232.1511082444120; Sun, 19 Nov 2017 01:07:24 -0800 (PST) Received: from [192.168.1.171] ([85.105.47.236]) by smtp.gmail.com with ESMTPSA id p15sm2581129wre.24.2017.11.19.01.07.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 01:07:23 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: "Ali C. Begen" In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> Date: Sun, 19 Nov 2017 12:07:20 +0300 Cc: "payload@ietf.org" , "rtcweb@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4A105783-051C-469E-8080-ED438E8DB803@networked.media> References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [rtcweb] [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction 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: Sun, 19 Nov 2017 09:07:28 -0000 Obviously the deadline for the WGLC is Dec. 7th. -acbegen > On Nov 17, 2017, at 5:35 AM, Roni Even wrote: >=20 > Hi, > I would like to start a three week WGLC on RTP Payload Format for = Flexible Forward Error Correction in = draft-ietf-payload-flexible-fec-scheme-05. > The WGLC will end on November 7th > =20 > Mo has posted some clarifications to the payload WG mailing list = payload mailing list archives > =20 > Please send comments to the payload mailing list.=20 > THe double posting is to notify RTCweb WG that the WGLC has started = since this document is needed for RTCweb > =20 > =20 > Roni Even > Payload WG co-chair > =20 > =20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From nobody Mon Nov 20 03:21:33 2017 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 2504512951F for ; Mon, 20 Nov 2017 03:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 x2HdijwswH6x for ; Mon, 20 Nov 2017 03:21:30 -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 818F8127010 for ; Mon, 20 Nov 2017 03:21:30 -0800 (PST) X-AuditID: c1b4fb3a-c73ff70000004c48-ce-5a12bab80332 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 50.6E.19528.8BAB21A5; Mon, 20 Nov 2017 12:21:28 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0352.000; Mon, 20 Nov 2017 12:21:28 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-40 Thread-Index: AQHTYfG0P6m6Ifx65ECn4eDVcweWsA== Date: Mon, 20 Nov 2017 11:21:27 +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_D638893726175christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIIsWRmVeSWpSXmKPExsUyM2K7iu6OXUJRBudajS3W/mtnd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoU1+gWXVSqWX9jK1MD4Vb6LkZNDQsBEYvG682xdjFwcQgKH GSWWbNoJ5SxhlLhzdTpLFyMHB5uAhUT3P22QBhEBdYnLDy+wg9jCAkYS9188ZIaIG0s8eLSC BcLWk+je1wMWZxFQlfg1aQMTiM0rYC2xYHc/I4jNKCAm8f3UGrA4s4C4xK0n85kgDhKReHjx NBuELSrx8vE/VhBbFGjmhhO32UHOkRBQkpi2NQ2iNUpixvSjrBDjBSVOznzCMoFRaBaSqbOQ lM1CUgYRT5D49v8BI4RtIPH+3HxmCFtbYtnC11C2vsTGL2ehaqwl5n/5x4SpRlfiyPlj7BC2 okTb9ma2WcBQZBZYwShx7tMndpjmGbN3s8IUTel+yL6AkW8Vo2hxanFxbrqRkV5qUWZycXF+ nl5easkmRmDkHtzy22oH48HnjocYBTgYlXh4b8wUihJiTSwrrsw9xKgCNOfRhtUXGKVY8vLz UpVEeNWigNK8KYmVValF+fFFpTmpxYcYpTlYlMR5T3ryRgkJpCeWpGanphakFsFkmTg4pRoY +1aIqrK8cJcrexUU1/2a50X+ca7l2tOeP30VbrrOe297enzq9v+H500Wr1JUnywrIH75+O2p y323OoRoJpw9xzL13gnbdHXHy2qZk7l1jl1YkZtjmGQk/IXr87VHUip7/SvPa4j37dhwXyM3 7Adj48X6B86LOPfqqr7USHz1fG60TM+pySVWSizFGYmGWsxFxYkANlzdOeQCAAA= Archived-At: Subject: [rtcweb] FW: [MMUSIC] Draft new version: BUNDLE-40 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, 20 Nov 2017 11:21:32 -0000 --_004_D638893726175christerholmbergericssoncom_ Content-Type: multipart/alternative; boundary="_000_D638893726175christerholmbergericssoncom_" --_000_D638893726175christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable FYI, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Monday 20 November 2017 at 13:12 To: "mmusic@ietf.org" > Subject: [MMUSIC] Draft new version: BUNDLE-40 Ladies and Gentlemen, I have submitted a new version (-40) of BUNDLE. The new version contains a number of editorial changes (based on the PRs th= at have been announced on the list). It also introduces the =93BUNDLE trans= port=94 concept. And, it clarifies that an m- section can not be directly m= oved from one group to another. I know there are still editorial changes that people would have liked to do= ne. But, we can=92t go on doing editorial changes forever, so my suggestion= is that we now do the publication request, and then we=92ll deal with what= ever changes are to be done based on the IESG reviews etc. Regards, Christer --_000_D638893726175christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
FYI,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Monday 20 November 2017 at 13= :12
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] Draft new version= : BUNDLE-40

Ladies and Gentlemen,

I have submitted a new version (-40) of BUNDLE.

The new version contains a number of editorial changes (based on the P= Rs that have been announced on the list). It also introduces the =93BUNDLE = transport=94 concept. And, it clarifies that an m- section can not be direc= tly moved from one group to another.

I know there are still editorial changes that people would have liked = to done. But, we can=92t go on doing editorial changes forever, so my sugge= stion is that we now do the publication request, and then we=92ll deal with= whatever changes are to be done based on the IESG reviews etc.

Regards,

Christer


 --_000_D638893726175christerholmbergericssoncom_-- --_004_D638893726175christerholmbergericssoncom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 20 Nov 2017 11:21:27 GMT"; modification-date="Mon, 20 Nov 2017 11:21:27 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_D638893726175christerholmbergericssoncom_-- From nobody Tue Nov 21 13:22:50 2017 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 C8B85129BD8; Tue, 21 Nov 2017 13:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, 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 DQS9a2_26yKU; Tue, 21 Nov 2017 13:22:39 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 A1868129BD5; Tue, 21 Nov 2017 13:22:38 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id q18so9262850uaa.0; Tue, 21 Nov 2017 13:22:38 -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=nEAm2z8CVUKDt2y6s5DibbJUVUhnJG9bOQu1SbTe8bs=; b=R2TRuaxHrHktVdetzPPc3lkJIdrXpH1GqGP/KrfJG/JP23skf5R8g9sakU7Y9X7HFS ftlLFuuXMNZnoktc3kor73+pX5EaNpWF2N2m5Xwfxmyufa9aWJBi7NCVqqOuIonEO0Mx NWNBnHmNFQmbP0er6CmMRdE/AbySA3LGtVRDMS80wVD8QP12iwLTs3Dnbm2vFyePM4dj qg66YIWuVv3v01cTASpdIx3TU89SAN8gjqWtFj35Fw4hRxBtF0jpsKCA1Xc2UT4/Sld+ qa0jixrlT2jnymud5lgwiXgiRyPnDvJKjy4hR4nbIgqsUudK7H01UiUB27v+Q2wYsvaC tNsQ== 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=nEAm2z8CVUKDt2y6s5DibbJUVUhnJG9bOQu1SbTe8bs=; b=O5GBWuY2NUz7zAnnUdEoXY6fYytw3TvJHwCp4Pi8GMcv4xjvhWB2Auj3vtw+Cxz+Le puYHvSWMZjBcvzHpZbWa6vCMrLnp0lk+LOxJrrvmfigzbDpdrs8yiFoIDyE1RQGVwHSl f3CRTi8jGlBxwJxZ24aXh65rWBrWGwloTg6UpxAmq4UT9jroEVHwLMDh+refVJLE6VEK +H3OgvnwGx0Es61F+fRM0w6znDUygdZZw10iCofcKTClgjEt2hjN2umF2RoJ9ElyZ4mN 50plI+ukbX2HcbmR4Lhd0BGmxGHoGBFpSowiUXI7P3gOf8pdcQyV1AF6dh9DwCR/x5In cKlQ== X-Gm-Message-State: AJaThX54APSDkXWbZWsf6ZFoVHLxnjxy1wWvJ06A77YgEAVle0Ma3fCL 5DTyh0jlacY059e94flbF31ffMy/GvPbp4Y35yo= X-Google-Smtp-Source: AGs4zMbMgARCWBVlEIhKlO/jKmoLRaDMWpDI8Gwqoj2fXALfU08yOhxz/CgYzY8bRP+C1LeOL3nFN3utmHlLChHftNw= X-Received: by 10.159.60.98 with SMTP id w34mr15789272uah.27.1511299357103; Tue, 21 Nov 2017 13:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.136.130 with HTTP; Tue, 21 Nov 2017 13:22:36 -0800 (PST) In-Reply-To: <4A105783-051C-469E-8080-ED438E8DB803@networked.media> References: <6E58094ECC8D8344914996DAD28F1CCD83775A@DGGEMM506-MBX.china.huawei.com> <4A105783-051C-469E-8080-ED438E8DB803@networked.media> From: Stephen Botzko Date: Tue, 21 Nov 2017 16:22:36 -0500 Message-ID: To: "Ali C. Begen" Cc: Roni Even , "rtcweb@ietf.org" , "payload@ietf.org" Content-Type: multipart/alternative; boundary="f40304364382545bbe055e84cd7b" Archived-At: Subject: Re: [rtcweb] [payload] WGLC on RTP Payload Format for Flexible Forward Error Correction 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, 21 Nov 2017 21:22:43 -0000 --f40304364382545bbe055e84cd7b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have reviewed it, but I don't think it is ready for publication yet. My commends follow. BR Stephen >>> Abstract >>> Overall, the purpose is to reconstruct RTP source packets that were lost in transmission, using the source and repair packets that were received. I expected that to be stated somewhere in the abstract and introduction. >>> These parity codes are systematic codes, where a number of repair symbols are generated from a set of source symbols. >>> This is of course the usual FEC jargon. But it isn=E2=80=99t clear if the symbols in this draft are bits, bytes, or the full source packets payloads. Overall, the draft generally uses the phrase =E2=80=9Csource packet=E2=80= =9D and =E2=80=9Crepair packet=E2=80=9D. =E2=80=9Crepair symbols=E2=80=9D shows up= in section 4.2, and there it seems to mean bits or bytes. The draft needs to clarify this, as the many implementers won=E2=80=99t have any real knowledge of FEC. I suggest removing references to =E2=80=9Csymbols=E2=80=9D, as the XOR cons= truction and repair mechanisms really don=E2=80=99t need to talk about =E2=80=9Csymb= ols=E2=80=9D. Also, =E2=80=9CFEC packets=E2=80=9D appears to be the same thing as =E2=80= =9Crepair packets=E2=80=9D. It would be better to use one term for both. Repair packets might be clearer (though they reconstruct lost packets, and don't actually repair them). >>> These repair symbols are sent in a repair flow separate from the source flo= w >>> The word =E2=80=9Cflow=E2=80=9D appears 19 times in the document with no ex= planation on what exactly is meant. I believe it simply means that the source and repair packets use different SSRCs (or different payload types?), but this is not as clear as it might be. FWIW, I realize that =E2=80=9Cflow=E2=80=9D is also used extensively in RFC= 6363. But RFC6363 defines flows in terms of transport identifier (such as standard 5 tuple), and that definition doesn=E2=80=99t apply here, since source and repair flows can use the same 5 tuple. >>> Moreover, alternate FEC codes may be used with the payload formats presente= d. >>> Does this mean that the FEC codes might not be XOR? If so, the document doesn=E2=80=99t say anything about how that is done (and the repair generat= ion and recovery methods in the draft are specific to XOR). So if means what is meant, the sentence should probably be removed. If it doesn=E2=80=99t mean that, then what does it mean? Section 1.1 >>> Note that the source and repair packets belong to different source and repair flows, and the sender must provide a way for the receivers to demultiplex them, even in the case they are sent in the same 5-tuple (i.e., same source/destination address/port with UDP). >>> The =E2=80=9Cdifferent source and repair flows=E2=80=9D aspect of the note = is repetitive, since it is also stated in step 3 immediately above this paragraph. =E2=80= =9CEven in the case=E2=80=9D is understated, =E2=80=9Cespecially in the case=E2=80= =9D is closer to the truth of it. It might be simpler to just say that source and repair packets MUST use different SSRCs (or different payload types?), and delete this sentence. >>> The repair packets may be sent proactively or on-demand. >>> How are they sent on demand? I don=E2=80=99t see any methods for requestin= g repair packets. Either procedures should be defined/referenced or the sentence deleted. >>> In this document, we refer to the time that spans a FEC block, which consists of the source packets and the corresponding repair packets, as the repair window. At the receiver side, the FEC decoder should wait at least for the duration of the repair window after getting the first packet in a FEC block, to allow all the repair packets to arrive. >>> Not sure if the intent is SHOULD wait or should wait. More importantly, the FEC patterns in the draft are all defined to have a fixed number of packets. The =E2=80=9Ctime that spans an FEC block=E2=80= =9D is not constant, especially for variable-rate video. The receiver has no idea how long that repair window time might be for a *specific *FEC block. At some point the receiver decides it=E2=80=99s time to deliver the source = packets =E2=80=93 either because (a) It is receiving source packets with no break in sequence number, so there is no need to wait for repair (b) It has received enough repair packets to recover the missing source packets (c) It has received all the repair packets, and they aren=E2=80=99t suf= ficient to recover the missing source packets (d) It is choosing not to wait any longer. Case (d) might be reached because it is starting to receive packets in the next FEC block, or it might be reached because of a real-time constraint The wording in the above paragraph doesn=E2=80=99t cover these cases very w= ell. And the FEC decoder doesn=E2=80=99t always need to wait for all the repair = packets to be received before it can begin the repair process. It=E2=80=99s probably more useful to point out that using flexflec does add= delay, and it needs to be clear that the repair window (in time units) is nominal. Or maybe specify the repair window in packets? >>> Suppose that we have a group of D x L source packets that have sequence numbers starting from 1 running to D x L, and a repair packet is generated by applying the XOR operation to every L consecutive packets as sketched in Figure 3. This process is referred to as 1-D non-interleaved FEC protection >>> I think the document would be clearer if this was in new section =E2=80=93 = preceded by a short into saying how flexspec provides non-interleaved (row), interleaved (column), and hybrid row+column (2-D) FEC patterns. This is a key concept in the draft, and should be more prominent. I think there should also be four use-case sections. Separate sections for row and column, and the retransmission mode (=E2=80=9CR=E2=80=9D bit) shoul= d probably have a short section too. >>> *1.1.3 **. Overhead Computation* >>> Overhead isn=E2=80=99t used much in the document, and I am not sure this pa= rticular definition adds much value. It might be better phrased as =E2=80=9CFEC Ove= rhead Considerations=E2=80=9D, since the overhead fractions really don=E2=80=99t = have much practical use, especially when the source packets are of unequal size. >>> 3.1 . Definitions >>> FEC Block, and repair window should be defined here (neither are defined in RFC6363). Parity Codes are not defined in RFC6363 either, and probably should be defined here. 1-D non-interleaved, 1-D interleaved, 2-D protection perhaps should be defined. It might be cleaner to define source block here, since the RFC6363 definition doesn=E2=80=99t precisely apply (because its definition of ADU f= low depends on 5-tuple). In general there are very few definitions in RFC6363 that are used in flexfec, so if it were my draft I=E2=80=99d just redefine them explicitly h= ere. >>> 3.2 . Notations >>> I=E2=80=99m not sure that bitmask needs to be here, though the text is ok. 4.1 . Source Packets >>> The source packets MUST contain the information that identifies the source block and the position within the source block occupied by the packet. >>> This is a meaningless MUST, since the source RTP packet is simply sent without modification. The sequence number and SSRC are used to map the packets onto the repair packets. Overall, paragraph 4.1 is confusing, because it gives the impression that something else needs to be done, and then says that there isn=E2=80=99t. P= lus, it is supposed =E2=80=9Cdefine the format of the source packet=E2=80=9D - whi= ch it doesn=E2=80=99t do. I think it=E2=80=99s better just to say earlier in the document that the so= urce packets can be any RTP packets, and leave it at that. Perhaps tie that statement to the use of systematic codes. Then focus on defining the repair packet format, which is the heart of the draft. The advantages of not modifying the source packets is better placed somewhere else in the document =E2=80=93 perhaps in section 1.1, when the F= EC encoder and Decoders are introduced. 4.2 . Repair Packets >>> o Marker (M) Bit: This bit is not used for this payload type, and SHALL be set to 0 >>> And ignored by receivers? >>> Note that this document registers new payload formats for the repair packets (Refer to Section 5 for details). According to [RFC3550 ], an RTP receiver that cannot recognize a payload type must discard it. This provides backward compatibility. If a non-FEC-capable receiver receives a repair packet, it will not recognize the payload type, and hence, will discard the repair packet. >>> This probably should be said somewhere, but I think it=E2=80=99s better mov= ed somewhere other than the repair packet format description. I believe this also requires that the CSRCs in the repair RTP header be set to the SSRCs of the source packets. That isn=E2=80=99t stated, but is impl= ied by the structure in table 10. >>> The format of the FEC header is shown in Figure 10. The FEC header consists of the following fields: >>> No. This is the first of four? possible formats, depending on R,F,M, and N, shown in figures 10-15. M is ambiguous - appears as M and M (columns). Some fields are really repair symbols (P,X,C,M, PT Recovery, Length Recovery, recovery), and are meaningless on their own. This rather important detail doesn=E2=80=99t show up until you get to 6.2. Figure 15 also affects figure 9, since the unspecified =E2=80=9CRepair symb= ols=E2=80=9D in figure 9 are replaced by the =E2=80=9Cretransmission payload=E2=80=9D In fi= gure 15. The contents of that =E2=80=9Cretransmission payload=E2=80=9D are not specified= anywhere in the draft. This whole section is a confusing mess, and needs to be restructured. I guess one approach is to change 6.2 to =E2=80=9CRepair symbol construction= =E2=80=9D, and explicitly refer to it for all fields in the FEC header that are XORed. One way or another, you need to separate out the fields that specify the FEC parameters from the embedded repair symbols mixed into the structure. >>> o The CSRC_i (32 bits) field describes the SSRC of the packets protected by this particular FEC packet. If a FEC packet contains protects multiple SSRCs (indicated by the CSRC Count > 1), there will be multiple blocks of data containing the SN base and Mask fields. >>> Does this mean that a repair flow can protect multiple RTP sources? If so, this should be clearly stated earlier. There might be other implications of supporting this (do all the sources need to have the same CNAME???) >>> If M>0, N=3D0, is Row FEC, and no column FEC will follow Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. If M>0, N=3D1, is Row FEC, and column FEC will follow. Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M. and more to come If M>0, N>1, indicates column FEC of every M packet in a group of N packets starting at SN base. Hence, FEC =3D SN+(Mx0), SN+(Mx1), ... , SN+(MxN). Figure 14: Interpreting the M and N field values >>> First, this is not a figure. Second, the names are not consistent with the 1-d non-interleaved, 1-d interleaved, and 2-d described above. The names need to be consistent. FWIW, these names are a bit more intuitive to me. >>> Note that the parsing of this packet is different. >>> =E2=80=9Cthis=E2=80=9D is indefinite. In general you should name the four(= ?) header types, I think that will make things simpler. >>> Figure 15: Protocol format for Retransmission >>> This is mis-titled. It also isn=E2=80=99t clear. The figure shows the alt= ernative FEC header format, but I believe the intent is that the retransmission payload replaces the =E2=80=9Crepair symbols=E2=80=9D shown in figure 9. T= hat isn=E2=80=99t obvious from the organization. >>> It should be noted that a mask-based approach (similar to the ones specified in [RFC2733 ] and [RFC510= 9 ]) may not be very efficient to indicate which source packets in the current source block are associated with a given repair packet. In particular, for the applications that would like to use large source block sizes, the size of the mask that is required to describe the source-repair packet associations may be prohibitively large. The 8-bit fields proposed in [SMPTE2022-1 ] indicate a systematized approach. Instead the approach in this document uses the 8-bit fields to indicate packet offsets protected by the FEC packet. The approach in [SMPTE2022-1 ] is inherently more efficient for regular patterns, it does not provide flexibility to represent other protection patterns (e.g., staircase). >>> I have no idea why this note is here. I=E2=80=99d delete it. There's no p= oint in talking about all the roads not taken. >>> 5 . Payload Format Parameters >>> If no specific FEC code is specified in the subtype, then the FEC code defaults to the parity code defined in this specification. >>> Since there is no syntax to specify the FEC code, a receiver has no way to know for certain that the parity code is being used. I *guess* that the statement in 5.2.1 *might* cover this >>> =E2=80=9CThere are no optional format parameters defined for this payload. Any unknown option in the offer MUST be ignored and deleted from the answer. If FEC is not desired by the receiver, it can be deleted from the answer. >>> For SDP at least, any FEC code in the offer would be deleted by an existing receiver, so if parity is mandatory-to-implement you=E2=80=99d get interoperability at least. But why not just specify the FEC code parameter (with Parity as a choice) now? >>> 6.2 . Repair Packet Construction The RTP header of a repair packet is formed based on the guidelines given in Section 4.2 . >>> Since 4.2 is a mess, it=E2=80=99s not surprising that 6.2 is also. The FEC header length isn=E2=80=99t limited to 28 octets in the retransmiss= ion case (which is conveniently skipped in 6.2) It would be good to specify what=E2=80=99s in the skipped bits in the heade= r, rather than making people figure it out. (=E2=80=9CV-2=E2=80=9D and Sequenc= e Number) Also phrases like =E2=80=9CThe next 4 bits of the FEC bit string are writte= n into the CC recovery field in the FEC header=E2=80=9D should be written as like =E2=80=9CThe next 4 bits of the FEC bit string are XORed into the CC recovery field in the FEC header=E2=80=9D BTW, I don=E2=80=99t think the =E2=80=9CFEC bit string=E2=80=9D nomenclatur= e is all that useful, given that you end up specifying the XOR field by field anyway. >>> The repair packet payload consists of the bits that are generated by applying the XOR operation on the payloads of the source RTP packets. If the payload lengths of the source packets are not equal, each shorter packet MUST be padded to the length of the longest packet by adding octet 0's at the end. >>> This presumably defines what is placed into the =E2=80=9Crepair symbols=E2= =80=9D back in figure 9. But it doesn=E2=80=99t say that. I believe this is incomplete. It doesn=E2=80=99t say how to handle extensi= on headers. It isn=E2=80=99t clear whether padding octets are XORed (RFC 3550= says the padding octets =E2=80=9Care not part of the payload=E2=80=9D). SRTP MKI= and authentication tag would also be recovered (which is not possible in the current draft). >>> 6.3.2 . Recovering the RTP Header This procedure recovers the header of an RTP packet up to (and including) the SSRC field. >>> But it doesn=E2=80=99t recover the full header, and that should be more cle= arly stated, FWIW, =E2=80=9Cif the repair symbols=E2=80=9D were defined as runn= ing from the first byte after the SSRC to the end of the source RTP packet, then the full RTP packet would be recovered =E2=80=93 including SRTP MKI and authent= ication tag, which cannot be recovered now. >>> 6.3.3 . Recovering the RTP Payload 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. *Note that the information of the* * first 8 octets are protected by the FEC header* >>> As is the SSRC, though in a different way. >>> 2. For each of the source packets that are successfully received in T, compute the bit string from the Y octets of data starting with the 13th octet of the packet. If any of the bit strings generated from the source packets has a length shorter than Y, pad them to that length. The padding of octet 0 MUST be added at the end of the bit string. Note that the information of the first 8 octets are protected by the FEC header. 3. For the repair packet in T, compute the FEC bit string from the repair packet payload, i.e., the Y octets of data following the FEC header. Note that the FEC header may be 12, 16, 32 octets depending on the length of the bitmask. 4. Calculate the recovered bit string as the XOR of the bit strings generated from all source packets in T and the FEC bit string generated from the repair packet in T. 5. Append the recovered bit string (Y octets) to the new packet generated in Section 6.3.2 . >>> This is close to the algorithm I suggested above (starting the =E2=80=9CRep= air symbols=E2=80=9D in figure 9 from the first octet after the SSRC). That=E2=80=99s good, but it isn=E2=80=99t consistent with the text in 6.2 (= =E2=80=9CThe repair packet payload consists of the bits that are generated by applying the XOR operation on the *payloads of the source RTP packets)*. So the text as written fails to recover (or fails to generate the repair packet correctly, depending on how you look at it). Also, any RTP padding, SRTP MKI + authentication tag in the repair packets themselves shouldn=E2=80=99t be included in the XOR. RTP Padding, RTP MKI and the authentication tag lengths that are part of the source packets do need to be taken into account when computing Y. I'm not sure the current FEC header handles that well. This section uses "FEC Bit String" to mean something different than it meant earlier in the document. Note the repair algorithms could include authentication of input packets and recovered source packets. >>> 8 . Congestion Control Considerations >>> I=E2=80=99d remove the reference to[I-D.singh-rmcat-adaptive-fec ]. >>> However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13 ][Nagy14]. >>> What does this sentence mean? The draft doesn=E2=80=99t talk about using F= EC for either bandwidth estimation or capacity probing. I suggest deleting it. >>> 9 . Security Considerations >>> Since the sender of the repair packets might not be the sender of the source packets, there is an obvious threat of injection of bogus repair packets. Authentication can be helpful in mitigating that threat. Such authentication (if possible) should be done an any packets that are used in the recovery process, and also on the reconstructed output packets. One could strengthen this into "MUST not" normative language if one wished. NITS Overall, the document frequently uses first person plural (Suppose we have, If we apply, We generate, We refer, We assume, =E2=80=A6). I think the au= thors should consider rephrasing those sentences. Section 1 >>> Situations where adaptivitiy of FEC parameters is desired, the endpoint can use the in-band mechanism, whereas when the FEC parameters are fixed, the endpoint may prefer to negotiate them out-of-band. >>> The sentence uses incorrect grammar. I suggest The in-band mechanism is advantageous when the endpoint is adapting the FEC parameters; the out-of-band mechanism may be preferable when the FEC parameters are fixed. Section 1.1 >>> In a nutshell, >>> Informal English =E2=80=93 I suggest rephrasing. >>> Section 8 However, it MAY still continue to use FEC if considered for bandwidth estimation instead of speculatively probe for additional capacity [Holmer13 ][Nagy14]. >>> Probing? On Sun, Nov 19, 2017 at 4:07 AM, Ali C. Begen wrote: > Obviously the deadline for the WGLC is Dec. 7th. > > -acbegen > > > On Nov 17, 2017, at 5:35 AM, Roni Even wrote: > > > > Hi, > > I would like to start a three week WGLC on RTP Payload Format for > Flexible Forward Error Correction in draft-ietf-payload-flexible- > fec-scheme-05. > > The WGLC will end on November 7th > > > > Mo has posted some clarifications to the payload WG mailing list > payload mailing list archives > > > > Please send comments to the payload mailing list. > > THe double posting is to notify RTCweb WG that the WGLC has started > since this document is needed for RTCweb > > > > > > Roni Even > > Payload WG co-chair > > > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload > --f40304364382545bbe055e84cd7b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed it, but I don't think it is ready for = publication yet.

My commends follow.

BR
Stephen=C2=A0

=C2=A0

>>>
Abstract
>>><=
/pre>
Overall, the purpose is to reconstruct RTP source packets that wer=
e lost in transmission, using the source and repair packets that were recei=
ved.=C2=A0 I expected that to be stated somewhere in the abstract and intro=
duction. 
=C2=A0<=
/span>
>>>=C2=A0
These parity codes are syste=
matic codes, where a number of repair
=C2=A0=C2=A0 symbols are generated from a set of sourc=
e symbols.
>&g=
t;>=C2=A0
This is of course the usual FEC jargon.=C2=A0 Bu=
t it isn=E2=80=99t clear if the symbols in this draft are bits, bytes, or t=
he full source packets payloads.=C2=A0 
Overall, the draft ge=
nerally uses the phrase =E2=80=9Csource packet=E2=80=9D and =E2=80=9Crepair=
 packet=E2=80=9D.  =E2=80=9Crepair symbols=E2=80=9D shows up in sect=
ion 4.2, and there it seems to mean bits or bytes.=C2=A0 The draft needs to=
 clarify this, as the many implementers won=E2=80=99t have any real knowled=
ge of FEC.
=C2=A0
I sug=
gest removing references to =E2=80=9Csymbols=E2=80=9D, as the XOR construct=
ion and repair mechanisms really don=E2=80=99t need to talk about =E2=80=9C=
symbols=E2=80=9D.
=C2=A0
Also, =E2=80=9CFEC packets=E2=80=9D appears to be the same thing as=
 =E2=80=9Crepair packets=E2=80=9D.=C2=A0 It would be better to use one term=
 for both.=C2=A0 Repair packets might be clearer (though they reconstruct l=
ost packets, and don't actually repair them).
=


>>>=C2=A0 
These repair symbols are=
 sent in a repair flow separate from the source flow
>>> 



The word=
 =E2=80=9Cflow=E2=80=9D appears 19 times in the document with no
explanation on what exactly is meant.=C2=A0 I
believe it simply means that the source and repair packets use different SS=
RCs
(or different payload types?), but this is not as clear as it might be.=C2=
=A0 



>>>=C2=A0



Moreover, alternate FEC codes may be used =
with the payload formats presented.



>>>=C2=A0



Does this mean that the FEC codes might not be XOR?=
=C2=A0 If so, the document doesn=E2=80=99t say anything
about how that is done (and the repair generation and recovery methods in t=
he
draft are specific to XOR).=C2=A0 So if means
what is meant, the sentence should probably be removed.



If it doesn=E2=80=99t mean that, then what does it m=
ean?



=C2=A0



Section 1.1



>>>=C2=A0



=C2=A0=C2=A0 Note that the source and repa=
ir packets belong to different source
=C2=A0=C2=A0 and repair flows, and the sender must pro=
vide a way for the receivers
=C2=A0=C2=A0 to demultiplex them, even in the case they are sen=
t in the same
=C2=
=A0=C2=A0 5-tuple (i.e., same source/destination address/port with UDP). 



>>>=C2=A0



The =E2=80=9Cdifferent source and repair flows=E2=80=
=9D aspect of the note
is repetitive, since it is also stated in step 3 immediately above this
paragraph.=C2=A0 =E2=80=9CEven in the case=E2=80=9D is
understated, =E2=80=9Cespecially in the case=E2=80=9D is closer to the trut=
h of it.=C2=A0 It might be simpler to just say that source
and repair packets MUST use different SSRCs =C2=A0(or different payload typ=
es?), and delete this
sentence.



=C2=A0



=
>>>=C2=A0



The repair packets may be sent proactively=
 or on-demand.



=
>>>=C2=A0



How are they sent on demand?=C2=A0
I don=E2=80=99t see any methods for requesting repair packets.=C2=A0 Either=
 procedures should be defined/referenced
or the sentence deleted.



>>>=C2=A0



In this document, we refer to the time tha=
t
=C2=A0=C2=A0 sp=
ans a FEC block, which consists of the source packets and the<=
/span>
=C2=A0=C2=A0 corresponding rep=
air packets, as the repair window.=C2=A0 At the receiver
=C2=A0=C2=A0 side, the FEC decoder =
should wait at least for the duration of the
=
=C2=A0=C2=A0 repair window after getting the fi=
rst packet in a FEC block, to allow
=C2=A0=C2=A0 all the repair packets to arrive.



>>>=C2=A0



Not sure if the intent is SHOULD wait or should wait=
.



More importantly, the FEC patterns in the draft are =
all
defined to have a fixed number of packets.=C2=A0
The =E2=80=9Ctime that spans an FEC block=E2=80=9D is not constant, especia=
lly for
variable-rate video.=C2=A0 The receiver has no
idea how long that repair window time might be for a specific FEC block.



At some point the receiver decides it=E2=80=99s time=
 to deliver the
source packets =E2=80=93 either because 



(a)=C2=A0=C2=A0=C2=A0
It is receiving source packets with no break in
sequence number, so there is no need to wait for repair



(b)=C2=A0=C2=A0=C2=A0
It has received enough repair packets to recover
the missing source packets



(c)=C2=A0=C2=A0=C2=A0=C2=A0
It has received all the repair packets, and they
aren=E2=80=99t sufficient to recover the missing source packets



(d)=C2=A0=C2=A0=C2=A0
It is choosing not to wait any longer.



=C2=A0



Case (d) might be reached bec=
ause it is
starting to receive packets in the next FEC block, or it might be reached
because of a real-time constraint



=C2=A0



The wording in the above paragraph doesn=E2=80=99t c=
over these cases
very well.=C2=A0 And the FEC decoder doesn=E2=80=99t
always need to wait for all the repair packets to be received before it can
begin the repair process.



It=E2=80=99s probably more useful to point out that =
using flexflec
does add delay, and it needs to be clear that the repair window (in time un=
its)
is nominal.=C2=A0 Or maybe specify the repair window in packets?=C2=A0
<=
br>


>>>=C2=A0



Suppose that we have a group of D x L sour=
ce packets that have
=C2=A0=C2=A0 sequence numbers starting from 1 running to D x L, and a r=
epair
=C2=A0=C2=
=A0 packet is generated by applying the XOR operation to every L
=C2=A0=C2=A0 consecutive pa=
ckets as sketched in Figure 3.=C2=A0 This process is
=C2=A0=C2=A0 referred to as 1-D non-int=
erleaved FEC protection



>>>=C2=A0



I think the document would be clearer if this was in=
 new
section =E2=80=93 preceded by a short into saying how flexspec provides non=
-interleaved
(row), interleaved (column), and hybrid row+column (2-D) FEC patterns.=C2=
=A0 This is a key concept in the draft, and
should be more prominent.=C2=A0 



I think there should also be four use-case sections.=
=C2=A0 Separate sections for row and column,
and the retransmission mode (=E2=80=9CR=E2=80=9D bit) should probably have =
a short section too.



>>>=C2=A0
1.1.3.=C2=A0=
 Overhead Computation
>&g=
t;>=C2=A0




Overhead isn=E2=80=99t used much in the document, an=
d I am not sure
this particular definition adds much value.=C2=A0
It might be better phrased as =E2=80=9CFEC Overhead Considerations=E2=80=9D=
, since the
overhead fractions really don=E2=80=99t have much practical use, especially=
 when the
source packets are of unequal size.



=C2=A0



>>>=C2=A0


3.1.=C2=A0
Definitions



>>>=C2=A0



FEC Block, and repair window should be defined here =
(neither
are defined in RFC6363).=C2=A0 Parity Codes
are not defined in RFC6363 either, and probably should be defined here.




1-D non-interleaved, =
1-D interleaved, 2-D protection perhaps
should be defined.




It might be cleaner t=
o define source block here, since the
RFC6363 definition doesn=E2=80=99t precisely apply (because its definition =
of ADU flow
depends on 5-tuple).=C2=A0 




In general there are =
very few definitions in RFC6363 that
are used in flexfec, so if it were my draft I=E2=80=99d just redefine them =
explicitly
here.



>>>=C2=A0



3.2.=
=C2=A0
Notations



>>>=C2=A0



I=E2=80=99m not sure that bitmask needs to be here, =
though the text is ok.



=C2=A0



=C2=A0



4.1.=C2=A0 Sour=
ce Packets



>>>=C2=A0



=C2=A0=C2=A0 The source packets MUST conta=
in the information that identifies the
=C2=A0=C2=A0 source block and the position within the=
 source block occupied by the
=C2=A0=C2=A0 packet.=C2=A0 



>>>=C2=A0



This is a meaningless MUST, since the source RTP pac=
ket is
simply sent without modification.=C2=A0 The
sequence number and SSRC are used to map the packets onto the repair
packets.=C2=A0=C2=A0
Overall, paragraph 4.1 is
confusing, because it gives the impression that something else needs to be
done, and then says that there isn=E2=80=99t.=C2=A0
Plus, it is supposed =E2=80=9Cdefine the format of the source packet=E2=80=
=9D - =C2=A0which it doesn=E2=80=99t do.=C2=A0 




I think it=E2=80=99s =
better just to say earlier in the document that
the source packets can be any RTP packets, and leave it at that.=C2=A0 Perh=
aps tie that statement to the use of
systematic codes.=C2=A0 Then focus on defining
the repair packet format, which is the heart of the draft.




The advantages of not=
 modifying the source packets is better
placed somewhere else in the document =E2=80=93 perhaps in section 1.1, whe=
n the FEC
encoder and Decoders are introduced.



=C2=A0



4.2.=
=C2=A0
Repair Packets



=C2=A0



>>>=C2=A0
=C2=A0=C2=A0 o=C2=A0 Marker (M) Bit: Thi=
s bit is not used for this payload type, and
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SHALL be set to =
0



>>>=C2=A0



And ignored by receivers?



>>>=C2=A0
Note that this document
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 re=
gisters new payload formats for the repair packets (Refer to
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
Section 5 for details).=C2=A0 According to [RFC3550], an RTP receiver
=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 that cannot recognize a payload type must discard it.=C2=A0 This
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 provides backward compatibility.=C2=A0 If a non-FEC-capable re=
ceiver
=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 receives a repair packet, it will not recognize the p=
ayload type,
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 and hence, will discard the repair packet.



>>>=C2=A0



This probably should be said somewhere, but I think =
it=E2=80=99s
better moved somewhere other than the repair packet format description.



=C2=A0



I believe this also requires that the CSRCs in the r=
epair
RTP header be set to the SSRCs of the source packets.=C2=A0 That isn=E2=80=
=99t stated, but is implied by the
structure in table 10.




>>>=C2=
=A0
The format of the FEC header=
 is shown in Figure 10.
The FEC header consists of the following fields:=




>>>=C2=A0



No.=C2=A0 This is the first
of four? possible formats, depending on R,F,M, and N, shown in figures 10-1=
5.=C2=A0 M is ambiguous - appears as M and M
(columns).=C2=A0 Some fields are really repair
symbols (P,X,C,M, PT Recovery, Length Recovery, recovery), and are meaningl=
ess
on their own.=C2=A0 This rather important
detail doesn=E2=80=99t show up until you get to 6.2.




Figure 15 also affect=
s figure 9, since the unspecified
=E2=80=9CRepair symbols=E2=80=9D in figure 9 are replaced by the =E2=80=9Cr=
etransmission payload=E2=80=9D In
figure 15.=C2=A0 The contents of that
=E2=80=9Cretransmission payload=E2=80=9D are not specified anywhere in the =
draft.




This whole section is=
 a confusing mess, and needs to be
restructured.=C2=A0 I guess one approach is to
change 6.2 to =E2=80=9CRepair symbol construction=E2=80=9D, and explicitly =
refer to it for all
fields in the FEC header that are XORed.=C2=A0
One way or another, you need to separate out the fields that specify the
FEC parameters from the embedded repair symbols mixed into the structure.



=C2=A0



>>>=C2=A0



=C2=A0=C2=A0 o=C2=A0 The CSRC_i (32 bits) =
field describes the SSRC of the packets
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protected by this par=
ticular FEC packet.=C2=A0 If a FEC packet contains
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 protects m=
ultiple SSRCs (indicated by the CSRC Count > 1), there
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wil=
l be multiple blocks of data containing the SN base and Mask
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
fields.



>>>=C2=A0



Does this mean that a repair flow can protect multip=
le RTP
sources?=C2=A0 If so, this should be clearly
stated earlier.=C2=A0 There might be other
implications of supporting this (do all the sources need to have the same
CNAME???)




>>>=C2=
=A0



If M>0, N=3D0,=C2=A0 is Row FEC, and no=
 column FEC will follow
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Hence, FEC =3D SN, SN+1, SN+2, ... , SN+(M-1), SN+M.
=C2=A0
<=
pre>=C2=A0=C2=A0 If M>0, N=3D1,=C2=A0 is Row=
 FEC, and column FEC will follow.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hence, FEC =3D SN, SN+1, SN+2, ... =
, SN+(M-1), SN+M.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and mor=
e to come
=C2=A0<=
/span>
=C2=A0=C2=A0 If M>0, N>1=
,=C2=A0 indicates column FEC of every M packet
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in a =
group of N packets starting at SN base.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hence, FEC =3D SN+(Mx0), SN+(=
Mx1), ... , SN+(MxN).
=C2=A0
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Figure 14: Interpreting the M and N field=
 values



>>>=C2=A0



First, this is not a figure. Second, the names are n=
ot
consistent with the 1-d non-interleaved, 1-d interleaved, and 2-d described
above.=C2=A0 The names need to be
consistent.=C2=A0 FWIW, these names are a bit
more intuitive to me.



=C2=A0



>>>=C2=A0



Note that the parsing of this packet is di=
fferent. 



>>>=C2=A0



=E2=80=9Cthis=E2=80=9D is indefinite.=C2=A0
In general you should name the four(?) header types, I think that will
make things simpler.=C2=A0 



=C2=A0



>>>=C2=A0



Figure 15: Protocol format for Retransmiss=
ion



>>>=C2=A0



This is mis-titled.=C2=A0
It also isn=E2=80=99t clear.=C2=A0 The figure
shows the alternative FEC header format, but I believe the intent is that t=
he
retransmission payload replaces the =E2=80=9Crepair symbols=E2=80=9D shown =
in figure 9.=C2=A0 That isn=E2=80=99t obvious from the organization.=C2=A0=
=C2=A0 




>>>=C2=
=A0



=
=C2=A0=C2=A0 It should be noted that a
mask-based approach (similar to the ones



=
=C2=A0=C2=A0 specified in [RFC2733]
and [RFC5109])
may not be very efficient to



=
=C2=A0=C2=A0 indicate which source
packets in the current source block are



=
=C2=A0=C2=A0 associated with a given
repair packet.=C2=A0 In particular, for the



=
=C2=A0=C2=A0 applications that would
like to use large source block sizes, the



=
=C2=A0=C2=A0 size of the mask that is
required to describe the source-repair



=
=C2=A0=C2=A0 packet associations may
be prohibitively large.=C2=A0 The 8-bit fields



=
=C2=A0=C2=A0 proposed in [SMPTE2022-1]
indicate a systematized approach.=C2=A0
Instead



=
=C2=A0=C2=A0 the approach in this
document uses the 8-bit fields to indicate



=
=C2=A0=C2=A0 packet offsets protected
by the FEC packet.=C2=A0 The approach in



=
=C2=A0=C2=A0 [SMPTE2022-1]
is inherently more efficient for regular patterns, it


=
=C2=A0=C2=A0 does not provide
flexibility to represent other protection patterns



=
=C2=A0=C2=A0 (e.g., staircase).



>>>=C2=A0



I have no idea why this note is here.=C2=A0 I=E2=80=
=99d delete it.=C2=A0 There's no point in talking about all the roads n=
ot taken.





>>>=C2=A0



5.=C2=A0=
 Payload
Format Parameters



>>>=C2=A0



If no specific FEC code is specified=

=C2=A0=C2=A0 in the su=
btype, then the FEC code defaults to the parity code defined
=C2=A0=C2=A0 in this specificat=
ion.



>>>=C2=A0



Since th=
ere is no syntax to specify the FEC code, a receiver has no way to know for=
 certain that the parity code is being used.=C2=A0 I guess that the =
statement in 5.2.1 might cover this 
<=
span>=C2=A0
>>>=C2=A0
=E2=
=80=9CThere are no optional format parameters d=
efined for this payload.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Any unknown option in the offer MUST=
 be ignored and deleted from
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the answer.=C2=A0 If FEC is not =
desired by the receiver, it can be
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 deleted from the answer.
>>>=
=C2=A0
For SDP at least, any FEC code in the offer wou=
ld be deleted by an existing receiver, so if parity is mandatory-to-impleme=
nt you=E2=80=99d get interoperability at least.=C2=A0 But why not just spec=
ify the FEC code parameter (with Parity as a choice) now?=

=C2=A0
>>>=C2=A0





6.2.=C2=A0 Repair Packet Construction








=C2=A0=C2=A0 The=
 RTP header of a repair packet is formed based on the guidelines
=C2=A0=C2=A0 given in Section 4.2.
>>>=C2=A0



Since 4.2 is a mess, it=E2=80=99s not surprising tha=
t 6.2 is also.



The FEC header length isn=E2=80=99t limited to 28 oc=
tets in the
retransmission case (which is conveniently skipped in 6.2)



It would be good to specify what=E2=80=99s in the sk=
ipped bits in
the header, rather than making people figure it out. (=E2=80=9CV-2=E2=80=9D=
 and Sequence
Number)



Also phr=
ases like =E2=80=9CThe next 4 bits of the FEC b=
it string are written into the CC recovery field in the FEC header=E2=80=9D=
 should be written as like =E2=80=9CThe =
next 4 bits of the FEC bit string are XORed into the CC recovery field in t=
he FEC header=E2=80=9D



=C2=A0



BTW, I don=E2=80=99t think the =E2=80=9CFEC bit stri=
ng=E2=80=9D nomenclature is all
that useful, given that you end up specifying the XOR field by field anyway=
.



=C2=A0



>>>=C2=A0



=C2=A0=C2=A0 The repair packet payload con=
sists of the bits that are generated by
=C2=A0=C2=A0 applying the XOR operation on the paylo=
ads of the source RTP packets.
=C2=A0=C2=A0 If the payload lengths of the source packets are=
 not equal, each
=
=C2=A0=C2=A0 shorter packet MUST be padded to the length of the longest pac=
ket by
=C2=A0=C2=
=A0 adding octet 0's at the end.



>>>=C2=A0



This presumably defines what is placed into the =E2=
=80=9Crepair
symbols=E2=80=9D back in figure 9.=C2=A0 But it
doesn=E2=80=99t say that.



I believe this is incomplete.=C2=A0 It doesn=E2=80=
=99t say how to handle extension
headers.=C2=A0 It isn=E2=80=99t clear whether padding
octets are XORed (RFC 3550 says the padding octets =E2=80=9Care not part of=
 the
payload=E2=80=9D). SRTP MKI and authentication tag would also be recovered =
(which is
not possible in the current draft).



=C2=A0



>>>=C2=A0



6.3.2=
.=C2=A0 Recovering the RTP Header



This procedure recovers the header of an R=
TP packet up to (and
=C2=A0=C2=A0 including) the SSRC field.



=C2=A0



>>>=C2=A0



But it doesn=E2=80=99t recover the full header, and =
that should be
more clearly stated,=C2=A0 FWIW, =E2=80=9Cif the
repair symbols=E2=80=9D were defined as running from the first byte after t=
he SSRC to
the end of the source RTP packet, then the full RTP packet would be recover=
ed =E2=80=93
including SRTP MKI and authentication tag, which cannot be recovered now.



=C2=A0



>>>=C2=A0



6.3.3=
.=C2=A0 Recovering the RTP
Payload



=C2=A0



=C2=A0=C2=A0 2.=C2=A0 For each of the sour=
ce packets that are successfully received in
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T, compute=
 the bit string from the Y octets of data starting with=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 the 13th octet of the packet.=C2=A0 If any of the bit strings=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0 generated from the source packets has a length shorter than Y,
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 pad them to that length.=C2=A0 The padding of octet 0 MU=
ST be added at
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the end of the bit string.=C2=A0 Note that the information of the
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 first 8=
 octets are protected by the FEC header



>>>=C2=A0



As is the SSRC, though in a different way.



>>>=C2=A0



=
=C2=A0=C2=A0 2.=C2=A0 For each of the source packets that are
successfully received in



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 T, compute the bit
string from the Y octets of data starting with



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the 13th octet of the
packet.=C2=A0 If any of the bit strings



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated from the
source packets has a length shorter than Y,



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pad them to that
length.=C2=A0 The padding of octet 0 MUST be
added at



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the end of the bit
string.=C2=A0 Note that the information of the



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 first 8 octets are
protected by the FEC header.



=
=C2=A0



=
=C2=A0=C2=A0 3.=C2=A0 For the repair packet in T, compute the FEC
bit string from the



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 repair packet
payload, i.e., the Y octets of data following the



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FEC header.=C2=A0 Note that the FE=
C header may be 12, 16, 32
octets



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 depending on the
length of the bitmask.



=
=C2=A0



=
=C2=A0



=
=C2=A0=C2=A0 4.=C2=A0 Calculate the recovered bit string as the XOR
of the bit strings



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated from all
source packets in T and the FEC bit string



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated from the
repair packet in T.



=
=C2=A0



=
=C2=A0=C2=A0 5.=C2=A0 Append the recovered bit string (Y octets) to
the new packet



=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 generated in =
Section
6.3.2.



>>>=C2=A0



This is close to the algor=
ithm I suggested above (starting the =E2=80=9CRepair symbols=E2=80=9D in fi=
gure 9 from the first octet after the SSRC).=C2=A0 
That=E2=80=99s good, but it isn=E2=80=
=99t consistent with the text in 6.2 (=E2=80=9C=
The repair packet payload consists of the bits that are generated by applyi=
ng the XOR operation on the payloads of the source RTP packets).=C2=A0 
So the text as written fails to recover (or=
 fails to generate the repair packet correctly, depending on how you look a=
t it).
Also, any RTP padding, SRTP MKI + authenticatio=
n tag in the repair packets themselves shouldn=E2=80=99t be included in the=
 XOR.  
RTP Padding, RTP MKI and the authentication ta=
g lengths that are part of the source packets do need to be taken into acco=
unt when computing Y.  I'm not sure the current FEC header handles that=
 well.

Th=
is section uses "FEC Bit String" to mean something different than=
 it meant earlier in the document.

Note the repair algorithms could include =
authentication of input packets and recovered source packets.=





>>>=C2=A0



.=C2=A0 Congestion Control Considerations



=C2=A0



>>>=C2=A0



I=E2=80=99d remove the reference to[I-D.singh-rmcat-adaptive-fec].<=
/span>



=C2=A0



>>>=C2=A0



However, it MAY still continue to use FEC =
if considered for bandwidth
=C2=A0=C2=A0 estimation instead of speculatively probe for addit=
ional capacity
=
=C2=A0=C2=A0 [Holmer13][Nagy14].



>>>=C2=A0



What does this sentence mean?=C2=A0 The draft doesn=
=E2=80=99t talk about using FEC for
either bandwidth estimation or capacity probing.=C2=A0 I suggest deleting i=
t.



=C2=A0



>>>=C2=A0



.=C2=A0 Security
Considerations



>>>=C2=A0





Since the sender of the repair packets might not be the sender of the sourc=
e
packets, there is an obvious threat of injection of bogus repair packets.=
=C2=A0 Authentication can be helpful in mitigating
that threat.=C2=A0=C2=A0
Such authentication (if
possible) should be done an any packets that are used in the recovery proce=
ss,
and also on the reconstructed output packets.

One could strengthen this into &qu=
ot;MUST not" normative language if one wished.



=C2=A0




NITS



Overall, the document frequently uses first person p=
lural
(Suppose we have, If we apply, We generate,=C2=A0 We refer, We assume, =E2=
=80=A6).=C2=A0 I think
the authors should consider rephrasing those sentences.



=C2=A0=C2=A0



=C2=A0



Section 1



=
>>>=C2=A0



=
Situations where adaptivitiy



=
=C2=A0=C2=A0 of FEC parameters is
desired, the endpoint can use the in-band



=
=C2=A0=C2=A0 mechanism, whereas when
the FEC parameters are fixed, the endpoint



=
=C2=A0=C2=A0 may prefer to negotiate
them out-of-band.



>>>=C2=A0



The sentence uses incorrect grammar.=C2=A0 I suggest=




The in-band mechanism is advantageous when the endpo=
int is
adapting the FEC parameters; the out-of-band mechanism may be preferable wh=
en
the FEC parameters are fixed.



=C2=A0



Section 1.1



>>>=C2=A0



In a nutshell,



>>>=C2=A0



Informal English =E2=80=93 I suggest rephrasing.



=C2=A0



>>>=C2=A0



Section 8



However, it MAY still continue to use FEC =
if considered for bandwidth
=C2=A0=C2=A0 estimation instead of speculatively probe for addit=
ional capacity
=
=C2=A0=C2=A0 [Holmer13][Nagy14].



>>>=C2=A0



Probing?



=C2=A0



=C2=A0



=C2=A0



=C2=A0

On Sun, Nov 19, 2017 at 4:07 AM, A= li C. Begen <ali.begen@networked.media> wrote:
Obviously the deadline for the WGLC is Dec. 7t= h.

-acbegen

> On Nov 17, 2017, at 5:35 AM, Roni Even <roni.even@huawei.com> wrote:
>
> Hi,
> I would like to start a three week WGLC on RTP Payload Format for Flex= ible Forward Error Correction in draft-ietf-payload-flexible-fec-schem= e-05.
> The WGLC will end on November 7th
>
> Mo has posted some clarifications to the payload WG mailing list=C2=A0= payload mailing list archives
>
> Please send comments to the payload mailing list.
> THe double posting is to=C2=A0 notify RTCweb WG that the WGLC has star= ted since this document is needed for RTCweb
>
>
> Roni Even
> Payload WG co-chair
>
>
> _______________________________________________
> payload mailing list
> payload@ietf.org
> https://www.ietf.org/mailman/listinfo/payload=

_______________________________________________
payload mailing list
payload@ietf.org
https://www.ietf.org/mailman/listinfo/payload<= br>

--f40304364382545bbe055e84cd7b-- From nobody Mon Nov 27 02:37:29 2017 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 A8D55126DC2 for ; Mon, 27 Nov 2017 02:37:27 -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 yM8ZJoCIlY5S for ; Mon, 27 Nov 2017 02:37:26 -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 A2A9C120725 for ; Mon, 27 Nov 2017 02:37:25 -0800 (PST) X-AuditID: c1b4fb25-1763d9c0000020f7-ed-5a1beae3be65 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C3.02.08439.3EAEB1A5; Mon, 27 Nov 2017 11:37:23 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.225]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0352.000; Mon, 27 Nov 2017 11:36:33 +0100 From: Christer Holmberg To: "rtcweb@ietf.org" Thread-Topic: [MMUSIC] Draft new version: BUNDLE-41 Thread-Index: AQHTZ2uXQsh4AncHfU+BEB04PfiUaA== Date: Mon, 27 Nov 2017 10:36:32 +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.16] Content-Type: multipart/mixed; boundary="_004_D641B8A426620christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyM2J7lO7jV9JRBseeS1qs/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPPXLrEWnDGouP/3OmMD41nNLkZODgkBE4m396ewdTFycQgJ HGaUaN45B8pZwihx6P9spi5GDg42AQuJ7n/aIA0iAuoSlx9eYAexhQWMJBZ/OsQMETeWODxj KpStJ3F1y1ImEJtFQFXi/+/ZYPW8AtYSM/6eA7MZBcQkvp9aA1bDLCAucevJfCaIg0QkHl48 zQZhi0q8fPyPFcQWBZq54cRtdoi4osTOs+3MEL1REtf+dTNDzBeUODnzCcsERqFZSMbOQlI2 C0kZRDxB4nz7YTYIW0diwe5PULa2xLKFr5lh7DMHHkPNsZZ4tm83O6YaXYkj549BxRUl2rY3 A83hArJXMErsubkGrvnz3glMMEVTuh+yL2DkW8UoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokR GL0Ht/xW3cF4+Y3jIUYBDkYlHt6Zj6WjhFgTy4orcw8xqgDNebRh9QVGKZa8/LxUJRFe2YdA ad6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwnPXmjhATSE0tSs1NTC1KLYLJMHJxSDYx5By7zs1/o XMxhwrhfwEWxQDY/9dIcac7iZk2vRQcfP3nQUt35+c6DXZYTtUy15/5++GFfHmeFTKnPhgtp H40eVeSsWFO92rdrQlld8t37QdePZwbc8N7eu7R/x4rnQf7HHjXcdd7jecR0z8opRz6n13HP WG3MuLNm9f4HrsrCH8pUGTfuOaCnxFKckWioxVxUnAgAamjkmuYCAAA= Archived-At: Subject: [rtcweb] FW: [MMUSIC] Draft new version: BUNDLE-41 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, 27 Nov 2017 10:37:27 -0000 --_004_D641B8A426620christerholmbergericssoncom_ Content-Type: multipart/alternative; boundary="_000_D641B8A426620christerholmbergericssoncom_" --_000_D641B8A426620christerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, Anyone authoring a draft that contains SDP (e.g., JSEP), please note that t= he BUNDLE SDP has changed a little. The bundle-only attribute is now used i= n both offers and answers. And, once a BUNDLE address has been negotiated, = it is only assigned to ONE m- section within the BUNDLE group (it was previ= ously assigned to each m- section within the BUNDLE group). In addition, once a BUNDLE group has been negotiated, there are restriction= s on how an answerer within an answer can reject/move m- sections out of a = BUNDLE group. The changes are done based on requests from people, and comments that the p= rocedures were difficult to understand. Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Monday 27 November 2017 at 12:29 To: "mmusic@ietf.org" > Subject: [MMUSIC] Draft new version: BUNDLE-41 Hi, I have submitted a new version (-41) of BUNDLE. The main technical changes are in the Offer/Answer sections: * The SDP bundle-only attribute is now used both in offers (initial and= subsequent) and answers. * If the m- section of an offer contains a BUNDLE address, the answerer= cannot reject that m- section or move the m- section out of the BUNDLE gro= up in the answer. * Some of the ICE offer/answer subsections were removed, because most o= f the text was duplications and people asked why it is needed. I have tried to address to questions/comments I have received, and I person= ally think the procedures are easier to understand now. Regards, Christer --_000_D641B8A426620christerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
FYI,

Anyone authoring a draft that contains SDP (e.g., JSEP), please note t= hat the BUNDLE SDP has changed a little. The bundle-only attribute is now u= sed in both offers and answers. And, once a BUNDLE address has been negotia= ted, it is only assigned to ONE m- section within the BUNDLE group (it was previously assigned to each m- = section within the BUNDLE group).

In addition, once a BUNDLE group has been negotiated, there are restri= ctions on how an answerer within an answer can reject/move m- sections out = of a BUNDLE group. 

The changes are done based on requests from people, and comments that = the procedures were difficult to understand.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Monday 27 November 2017 at 12= :29
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] Draft new version= : BUNDLE-41

Hi,

I have submitted a new version (-41) of BUNDLE.

The main technical changes are in the Offer/Answer sections:
  • The SDP bundle-only attribute is now used both in offers (initial and s= ubsequent) and answers.
  • If the m- section of an offer contains a BU= NDLE address, the answerer cannot reject that m- section or move the m- sec= tion out of the BUNDLE group in the answer.
  • Some of the ICE offer/a= nswer subsections were removed, because most of the text was duplications a= nd people asked why it is needed.
I have tried to address to questions/comments I have received, and I p= ersonally think the procedures are easier to understand now.

Regards,

Christer

 --_000_D641B8A426620christerholmbergericssoncom_-- --_004_D641B8A426620christerholmbergericssoncom_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 27 Nov 2017 10:36:32 GMT"; modification-date="Mon, 27 Nov 2017 10:36:32 GMT" Content-ID: <571EB305E129A946A0D674FB66AF3814@ericsson.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_D641B8A426620christerholmbergericssoncom_--