From nobody Mon Oct 25 15:20:17 2021 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 20DC43A0DD6; Mon, 25 Oct 2021 15:20:13 -0700 (PDT) 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: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtcweb@ietf.org Message-ID: <163520041310.2930.2864537375349795065@ietfa.amsl.com> Date: Mon, 25 Oct 2021 15:20:13 -0700 Archived-At: Subject: [rtcweb] I-D Action: draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 25 Oct 2021 22:20:13 -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 : JavaScript Session Establishment Protocol (JSEP) Authors : Justin Uberti Cullen Jennings Eric Rescorla Filename : draft-uberti-rtcweb-rfc8829bis-01.txt Pages : 106 Date : 2021-10-25 Abstract: This document describes the mechanisms for allowing a JavaScript application to control the signaling plane of a multimedia session via the interface specified in the W3C RTCPeerConnection API and discusses how this relates to existing signaling protocols. This specification obsoletes RFC 8829. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-uberti-rtcweb-rfc8829bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-uberti-rtcweb-rfc8829bis-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-uberti-rtcweb-rfc8829bis-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Oct 26 03:55:12 2021 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 2DBEC3A0ECB for ; Tue, 26 Oct 2021 03:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 F7_u-dMZHZFH for ; Tue, 26 Oct 2021 03:55:09 -0700 (PDT) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0D43A0EC6 for ; Tue, 26 Oct 2021 03:55:09 -0700 (PDT) Received: by mail-oi1-x232.google.com with SMTP id o83so19966828oif.4 for ; Tue, 26 Oct 2021 03:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=5fukz9UNw77D+qVuQBugcIhX7Ror+fm6ZWrM51A8sz8=; b=KLJMjmebMRRudaExHLEfNV0PPmj4C7wzskkb4ECd/oQ0aQicJLdK1zJXsJFM84UPEZ Nm6QEknQPGQQMryulGVJ+dL1Al9KjS5VTua+RY8WOTTA/+l1+3OW7bu+s1yt29fv+LZ+ EkR8LYj1tIGu0URg8XMcXB+yWiciQ8pz2FRf9cdc/4l1QscZh92pRssbxGFO/2gPCdze AO0HVY8B5YbzWmNDXs/q0MdixdWMAxTnVRC+E6ly6SBFEbOKuTtvrPswLUxU41n3JZ4B /GBHDXDxf9t8hvrlC353Zprlqdf5u7Cop18kpC1U4KtNeZFblqqC47gcHqrcjio+ea// PKNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5fukz9UNw77D+qVuQBugcIhX7Ror+fm6ZWrM51A8sz8=; b=TQGz3ie6j3/0J4Yn+FdNdII36e1eUcBjyESgs7uED2HQZeAqUIHGW+vKM3bxuzi/z+ tLd1EvVNzVqF6eJf0e+PaWrx0uiPAqwvvvM0XRoTFNolkiF7em6R+IPo7u4MVPnpEZvA 2ITEwl4MS3m91Sr8ZsNBLk3U/ee/rn0Rc86omRM3V5gJBilKo3Q1vqRSGyphjonTF/kl whgEgbyvJdzDAnT411AFzDo3FwVpiZmXMr1jwoAo6atm/iiLyp/9Cy1iYehCXsUUj/WN 0Nw+qRM+NnNrugxM03KzaPt3HWtc7nYm0aQmKkr8v2PLIYXPJ+g2GnH9E0HJ95I9tPQY TLzQ== X-Gm-Message-State: AOAM530a7O0JYr2bH/vuwDRnvW6/61iboRxiGs6WbjfEXyIePWgZqzKB e1e9o/n4TOXTJjeGrc4cTWW1+0w7FR8PQC8qk5Z72akbSWI= X-Google-Smtp-Source: ABdhPJzPgmd24q0aonTRaxE5a7y8OVQUTIoGTQppOKrd5KL4qCdMTPGVflPfcRA2IHCthFxg5stxK1jZacOsGc30QPs= X-Received: by 2002:aca:5bd6:: with SMTP id p205mr16102409oib.35.1635245707567; Tue, 26 Oct 2021 03:55:07 -0700 (PDT) MIME-Version: 1.0 From: Ted Hardie Date: Tue, 26 Oct 2021 11:54:41 +0100 Message-ID: To: RTCWeb IETF , Justin Uberti , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="0000000000008524ff05cf3f4faf" Archived-At: Subject: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 10:55:11 -0000 --0000000000008524ff05cf3f4faf Content-Type: text/plain; charset="UTF-8" This email serves as the start of a working group last call for draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF meeting, it will be slightly longer than normal, ending on November 16, 2021. Please send comments to the list. thanks, Ted and Sean --0000000000008524ff05cf3f4faf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thi= s email serves as the start of a working group last call for draft-uberti-r= tcweb-rfc8829bis-01.txt.=C2=A0 Because of the upcoming IETF meeting, it wil= l be slightly longer than normal, ending on November 16, 2021.

Please send comments to the list.

thanks,

Ted and Sean
--0000000000008524ff05cf3f4faf-- From nobody Tue Oct 26 04:15:21 2021 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 DB8683A0F44 for ; Tue, 26 Oct 2021 04:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpRAAeKq4_BD for ; Tue, 26 Oct 2021 04:15:15 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2080.outbound.protection.outlook.com [40.107.20.80]) (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 7E9F73A102E for ; Tue, 26 Oct 2021 04:15:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PO04V2+iDUG6Na0XXAn8Dl5bZZkGKfXE93+1H4LJHTBukc/PU9iaiOwjwxUjjr+pERzQOAgsIQWGu4XfFBo2AwejoKOq9TEi//phW94ZbpYYmvMa3bHdN31VWhQdPiAJG2gpf1Vn5XNK1EZaA0WqJgnHZ36Twvp52UPNgO9W43tDQ486QXx6I7uXNgW2AcWeoOc7cFO1x42F0P+/hRAbFAxAteGNDZxs6uHgoXy7BaBNm0cxi1HGZg8qryZqNWw41uFmz7jBcQRkMWIW4/iLmRnVAcK3NqFdOMYVzcz57Kb4GxK14YabEEnpdF+Nqub8zGK4gwVr0Y3sanx171kQPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ra6oYztxgbQcB/oGiMCnCO+omLxTpV7TvUnUFbZcur0=; b=hqQonOPoqiyRh5m0F1F0/5NbgT44NGnM0L0eVXxyrgLztrJ8eo24CYtu3AIdF9yFYaaS5/5SdFKss5ywUG3Xb0TNm1EXhdPILSi4dgtmb/1HMhIswGQx3gFqZqn17/F87Knd8jDJ1ya7QYggZ8ZHVe/7F9H00mQkRVbaqCVDJjjPsEE1J5NONqbzxyF97lwjZ7bIjM9Nl7BtbelFzEGan8h2SCAjLDj2B7rurTeMQZxEu3avf6ASLRnS2KpYwemdMFFTbJuEUjCnwJs1I/Q0aGoKVbFRo3hypcUh0JEgn7YKaUYei+HuthJ0b7vyuTAeqAO3LJc+a2zUJOARXAX8+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ra6oYztxgbQcB/oGiMCnCO+omLxTpV7TvUnUFbZcur0=; b=lBnHNz6JNSGzxorWZ35fIV451PZPwmvBDBUQM6KexwXAHH3uUlAP0/s+BTQODGmReaXA4aS/g0pyimkF1SUOxFkeOyQ92SvjD9SNH+MMHTPR+Md48gL7ZvHHt79PA/GfMdNuv8XCTKKH9DfHAZf/nsy8rZtQIDzSAOaURMkUt0s= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0701MB2540.eurprd07.prod.outlook.com (2603:10a6:3:75::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.12; Tue, 26 Oct 2021 11:15:00 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 11:15:00 +0000 From: Christer Holmberg To: Ted Hardie , RTCWeb IETF , Justin Uberti , Cullen Jennings , Eric Rescorla , Sean Turner Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlIFMg Date: Tue, 26 Oct 2021 11:15:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6255c1d9-d475-4d82-148c-08d99871d9f3 x-ms-traffictypediagnostic: HE1PR0701MB2540: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7HMZQs29ep2FTmdA1zTxS3vvh5a8gNOkhx2UoDY2pfqpZeulY2ABT+iEK5MsNKRYKm2a3Cn1hhP7e0MlPZykBNcYe9A5952QT0RsAfyU5y3unjqKjf04PfKVS19EkvzjN10xEtN5GTRmSkkJnQWZVRM4gVT5JJ4oGA2VNANdCP3tOA5sgTSgZ3Riw7dU+584IrFdIbfCRaStOBwiXTj3VnhNRm1X5qfI5t1Kfvw8t4cXPh/4RQ29cO1OLQxJqn0IWikVHQYjU4H+Moi9jvMTqcStiO80kXPJaz98fQb7NPw970Ey8TCN5zqzrvl90rJFncdv8xypS8VvhprFx1rOiJ/gb8SMS04/Ns+gSLNzyU7dSf8ty4DDINPxXwGL9GSFHE6VaVgQr0/xn6QcaQqdc7sQ6Mnfdz9p9/DKmNlKtYrC3wAIBUueA+PfoIUBRrE06gusFQWYMYJwtih1PZRYsmqxsO14lJ/h9P15yYknTs8FFVJel5ikmZj6VyU1QDwDbv6JtDH131CGXvHGgaQqfECasxhpKlPTMKOdty4xqTDCL23ftBWvVmmBWrOGhYXvo5j1rD+C6waCsk6v80R53FKbjIYYnLu5nm/rQU3pDEERvqI8DruyZbydeN7E2/PywcPmXHDOqG9CMq9FbPobix4CfgVvxQqkubVfLbr4aotE0iqais3sC7zYAiC+3g3A4PZo0xu/eq1lC1a1eXIA/g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(55016002)(33656002)(83380400001)(122000001)(110136005)(2906002)(9686003)(316002)(8676002)(508600001)(86362001)(82960400001)(66476007)(7696005)(5660300002)(66946007)(52536014)(71200400001)(8936002)(4744005)(66446008)(64756008)(76116006)(6506007)(66556008)(38100700002)(26005)(186003)(38070700005)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?c0t4UDVsVUtuSXA1V01xZ2xjTEdHRzZVc2lMcVBDbGVaYXB6NDVXTXhQaHl5?= =?utf-8?B?Ri9oV2ZJMVJDdm1wQ3VMOXZtbW5JNVovcWNxYjFzOUZEajNEMWIrK3FGdUw4?= =?utf-8?B?eSs0a3RLaFlUT1pibmNhRmJJYXVHOHgzakhvUXU3Zzc0d21UUXRZMWVObW5x?= =?utf-8?B?OU4yd25QVHhjNDlXSHdBZU9IbEpoZ1g2S3MrZnZKQi9ub0FVZ3locjBpNGtX?= =?utf-8?B?MnlGSGZMbFBIQ0xVRDNNV2d3SHhvT2hRd2V1MCtLU05XNlBwVHJNMC95SXRn?= =?utf-8?B?SkFtMlUvYWVsclVicXpyU09WNkFvTEhHR1NxTW1FQ1l1YytXU0dvMzVpN0N4?= =?utf-8?B?M05XejlyUk14Unh2Z2F3SmUwZmo0Z2doNmZyUmJ5MEpoQ1pJUklmeUM1WUFP?= =?utf-8?B?NXJPZ0xtZVMxVldPaG9sSFpXR0svTjFReXM3SVZMNXNJK3hYbUExOHpUMTRC?= =?utf-8?B?OXR6eUVWUmFnZjBBRzY4YVV2dlBKYTlrWmVEUGh2RVhmcVFPbDd5ZHJpdVJJ?= =?utf-8?B?T3kySjI1dCsrc1JQejRjWXVPQ3Nma2hwWmwyNXArckkvMDJ6dkhCWjJWMVVP?= =?utf-8?B?UW1LaTVZRU01ME5BS01vTlJIYVJhSHZoTjhKdmxoQ0tyVUx3RDRUaXZlQlVN?= =?utf-8?B?ejBSNVJJWm9rV2hUQllCUzR4WFRDaURPZ3d5dVo0V205cWhISDdBMm03TnNY?= =?utf-8?B?Y2grK1JjNVgxQ3ZYQ0tzOUFkMjhiOUJFS3NVZEEvZE5ySUhTYlo5QTY2Wmtq?= =?utf-8?B?NSt4ZGtKaDQ4byt2MlUzL3FXWXU3QjQrRDJWQmh5V1paYXFIWGNnL25sNk1r?= =?utf-8?B?T3pXTXBUekZyeXJsUjRWaUlOT01Pa2haWXcxbk9MRUovSnZkQ3NIbXI0RUM2?= =?utf-8?B?ZE45am1BakUxL3lUYzdld2ltaDlZOHhzYzNRVGhZWXp5OGpJT0lJeVBrNUxB?= =?utf-8?B?Nks2QmM2bVZ5bnVBalplYnZBMUZlMkUzRndYL3hkd3RFSHBxYlFaYWVld20y?= =?utf-8?B?K0JET0Z4cFZkaGM1c3VkQ3ljTXBqU0FtNXVIVnNZZmM0MUxCdkdLL0RncmNG?= =?utf-8?B?by9sa2tDKzJXNHRDVDVkeE5saThhdUwxT0MrenVqMWFVTjlOcVVKNzV3Qi9G?= =?utf-8?B?cEZMY0FMMTJLdVMxWWFxanlzTnRwRG1SWEVpRjBURTJGNWxpNGY4WmM5MStk?= =?utf-8?B?ZGF3TWswQ3lDci84NGFBODA0YkpsUExieDRTMUtBTVRSaW8vNy95dU5kODJE?= =?utf-8?B?NGhpcWpKRGhLbUc1M0F2YUt6RnhXbXVxZjRvcnRqYVRVQjg5R1Y0Y2EzQ2Vh?= =?utf-8?B?VXkzWXk0U1dJZ0w2bFRrWEpONUJLMnZ0THBTTlJEcmJqRktpNFl5TmZOWUhz?= =?utf-8?B?cUVNb0wyY1p5TTlzeERwWUVaTjJVSWJLNmxRT1ZqVlE1RW1ZUnRnOTEwZFR0?= =?utf-8?B?WU5UcHJIenkxUEhOR3luaVRNTUh3Z1FpMDE4bW5tdEN1T1BvamdiNG1XT2c1?= =?utf-8?B?YjFXZXl0TFQ3TlFReGVBKzVlVHNXcVc1eG1aRmd1ODA3MDcyM0lNcGRhakFk?= =?utf-8?B?YXEwRW8zSERqcWRXV3NqZmsxMmE4NkoyNXpvd1RpR0dQdjBFOHZkaUhCQkI4?= =?utf-8?B?akcwdVJVeksrM2orNXdES0EvWkJHZFIxQmo1UllEa2RlMlh2M0s5YWlPbHVz?= =?utf-8?B?Umo5cDkycWVnQmUzZ2crNDg4QVJJaVFzNkNuWTYyV2VCamVTL2VRSnFKelhq?= =?utf-8?B?SGg5S2IrSU1oa2grY3lOM0hpY0tiYzQ3cFVJb2Z0eURXTzRrdFF6MVFBK0Vi?= =?utf-8?B?WHRiUUFnUDNPREFFemNyZVhxU1FBU0VuczJKZXd3Q3E4ZlFVS1JyUUo4aGVI?= =?utf-8?B?bElsMWljR3FUaHFZblljQnllOWx4UkJLblVyR2Y0STZVb20wMXpaZ0I5ak1n?= =?utf-8?B?NTFtY1dCbllTZ2ZsSzFycmF1NFJWVjRKSUZqc3YwV3FYRm1PdG5WQnZNTG1M?= =?utf-8?B?N1dFZk9XT1hRZlQxd1lab2pvMWd6c1F1Vm5WSk1kdjlHUm84WUxmZXF5b1JS?= =?utf-8?B?WFA1dWI2QndsV0NpYlErc1Z6UUt2VjBEVWI1QTU5RFpnVm5jYkt1SWd2dDdH?= =?utf-8?B?R3NtbkxsTFpzU2lLV2gyWkg1WWpreCtnK3d5VVp3YnlnNWt4Y21OZ3Z6SHBB?= =?utf-8?B?elp5bFZZRlBzcXppMm0xRk5ISXhtb1ZqY09EYUw1Wm8wMkQyY1pzRHdneE1x?= =?utf-8?B?MDNDSmNBVVVtdzNham15SWtxcE9RPT0=?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB444125C6AA71606BC036AFA593849HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6255c1d9-d475-4d82-148c-08d99871d9f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 11:15:00.3599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: hZ+S1WhZMUEJ4ZbXu2d9/sc5ZWuwMLOQp8h7emZEHwPNzpChQKajTTQSqCxPKyl1HjnGUAjTpZFycM28mqaYxfIkm+W4Dr9j0A2qizCWHKc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2540 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 11:15:20 -0000 --_000_HE1PR07MB444125C6AA71606BC036AFA593849HE1PR07MB4441eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYWxyZWFkeSBlYXJsaWVyIGNvbW1lbnRlZCB0aGF0IHRoZSBkcmFmdCBzdGlsbCBy ZWZlcmVuY2VzIFJGQyA4ODQzLCBldmVudGhvdWdoIGl0IHNob3VsZCBiZSB1cGRhdGVkIHRvIGRy YWZ0LTg4NDNiaXMuDQoNCkJ1dCwgYXMgZHJhZnQtODg0M2JpcyBpcyBub3cgaW4gdGhlIFJGQyBl ZGl0b3JzIHF1ZXVlLCBJIGd1ZXNzIHRoYXQgdXBkYXRlIGNhbiBiZSBkb25lIG9uY2UgdGhlIFJG QyBudW1iZXIgZm9yIDg4NDNiaXMgaGFzIGJlZW4gYXNzaWduZWQuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCkZyb206IHJ0Y3dlYiA8cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFs ZiBPZiBUZWQgSGFyZGllDQpTZW50OiB0aWlzdGFpIDI2LiBsb2tha3V1dGEgMjAyMSAxMy41NQ0K VG86IFJUQ1dlYiBJRVRGIDxydGN3ZWJAaWV0Zi5vcmc+OyBKdXN0aW4gVWJlcnRpIDxqdXN0aW5A dWJlcnRpLm5hbWU+OyBDdWxsZW4gSmVubmluZ3MgPGZsdWZmeUBpaWkuY2E+OyBFcmljIFJlc2Nv cmxhIDxla3JAcnRmbS5jb20+OyBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+DQpTdWJqZWN0 OiBbcnRjd2ViXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dl Yi1yZmM4ODI5YmlzLTAxLnR4dA0KDQpUaGlzIGVtYWlsIHNlcnZlcyBhcyB0aGUgc3RhcnQgb2Yg YSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dlYi1yZmM4ODI5 YmlzLTAxLnR4dC4gIEJlY2F1c2Ugb2YgdGhlIHVwY29taW5nIElFVEYgbWVldGluZywgaXQgd2ls bCBiZSBzbGlnaHRseSBsb25nZXIgdGhhbiBub3JtYWwsIGVuZGluZyBvbiBOb3ZlbWJlciAxNiwg MjAyMS4NCg0KUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gdGhlIGxpc3QuDQoNCnRoYW5rcywNCg0K VGVkIGFuZCBTZWFuDQo= --_000_HE1PR07MB444125C6AA71606BC036AFA593849HE1PR07MB4441eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJGSSIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6 YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkkgYWxyZWFkeSBlYXJsaWVyIGNvbW1lbnRlZCB0aGF0IHRoZSBkcmFmdCBz dGlsbCByZWZlcmVuY2VzIFJGQyA4ODQzLCBldmVudGhvdWdoIGl0IHNob3VsZCBiZSB1cGRhdGVk IHRvIGRyYWZ0LTg4NDNiaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QnV0LCBh cyBkcmFmdC04ODQzYmlzIGlzIG5vdyBpbiB0aGUgUkZDIGVkaXRvcnMgcXVldWUsIEkgZ3Vlc3Mg dGhhdCB1cGRhdGUgY2FuIGJlIGRvbmUgb25jZSB0aGUgUkZDIG51bWJlciBmb3IgODg0M2JpcyBo YXMgYmVlbiBhc3NpZ25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHJ0Y3dlYiAm bHQ7cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBI YXJkaWU8YnI+DQo8Yj5TZW50OjwvYj4gdGlpc3RhaSAyNi4gbG9rYWt1dXRhIDIwMjEgMTMuNTU8 YnI+DQo8Yj5Ubzo8L2I+IFJUQ1dlYiBJRVRGICZsdDtydGN3ZWJAaWV0Zi5vcmcmZ3Q7OyBKdXN0 aW4gVWJlcnRpICZsdDtqdXN0aW5AdWJlcnRpLm5hbWUmZ3Q7OyBDdWxsZW4gSmVubmluZ3MgJmx0 O2ZsdWZmeUBpaWkuY2EmZ3Q7OyBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7OyBT ZWFuIFR1cm5lciAmbHQ7c2VhbkBzbjNyZC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFty dGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC11YmVydGktcnRjd2ViLXJm Yzg4MjliaXMtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQiPlRoaXMgZW1haWwgc2Vy dmVzIGFzIHRoZSBzdGFydCBvZiBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBkcmFmdC11 YmVydGktcnRjd2ViLXJmYzg4MjliaXMtMDEudHh0LiZuYnNwOyBCZWNhdXNlIG9mIHRoZSB1cGNv bWluZyBJRVRGIG1lZXRpbmcsIGl0IHdpbGwgYmUgc2xpZ2h0bHkgbG9uZ2VyIHRoYW4gbm9ybWFs LCBlbmRpbmcgb24gTm92ZW1iZXIgMTYsDQogMjAyMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE4LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQiPlBsZWFzZSBz ZW5kIGNvbW1lbnRzIHRvIHRoZSBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+dGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTguMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE4LjBwdCI+VGVkIGFuZCBTZWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR07MB444125C6AA71606BC036AFA593849HE1PR07MB4441eurp_-- From nobody Tue Oct 26 05:40:08 2021 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 0A5FA3A1141 for ; Tue, 26 Oct 2021 05:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 vTXSfTduGZ5o for ; Tue, 26 Oct 2021 05:40:02 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::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 E33BD3A0896 for ; Tue, 26 Oct 2021 05:40:01 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id y207so20313714oia.11 for ; Tue, 26 Oct 2021 05:40:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=688AKVkb50vAPsCegzqQ8tCxabCwP12kJyQywdAy7LU=; b=Fz+zZyxd+2DgjgSvF0L/0usZ0s9bHRB/+RBz00AXzlRQBHw7OlfBgzlqS7rYYLMjhG fdj2cSzz7PjF+5RF8As7GDGPOsEm/LcAQApUwTNnjFcwO2sz+9NBRpSRqqeWFwBICPbP jlXOVWjQbyjL0kIofGL93B06cBt2L4fyt6WR0QLHsyxsyq9ONBEjngri2otZltDdd4cr bd2+mud5Mcz39HOaAMmolJJvejsgR6Twbtk6O4uge1MP8BbREaCiOTaNhOB1MmG9d/a1 v4aFJsDcJsYFrsfYMpFg7hNCI02vZT/t7KEvSyYdIRsvkwQYJN6mlrEqQb9CR5szZrc2 SoCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=688AKVkb50vAPsCegzqQ8tCxabCwP12kJyQywdAy7LU=; b=TvfmGjNCoVicVnYrKEuWUQ18XfPvFS42d4WUMgIYx8yyW4cW1BAHmwdjFuhMaNfUlZ jmTtUtRYH/uvk/Dq69XeE48/PQUbyigpvDXuhOyheybdzYu3HdB5OHkNbCpHzTLMWBMH fy+/E/9DgB/veMXlKPBO5hKq9x2YvjlEJNmcjbQm6CEm8fxYwmUKBDzv95VajwBQYpP6 sDR/eDPMVPCINbpuqI/E/02LnMlHaMt7UWEwgu3IdrJcHvk1Noz+5Q2A2HdAmzUg75sM t2RHcVc5Gj7AJz3VZuV55Lo/aGaILmpl4lOiVuygliLxV2tXGSG2t3y1ANFLNpGzRgAY Y4Og== X-Gm-Message-State: AOAM533fhX528DpVEYsXR4wVQ7mRI+rThxISbzyllk1K42r4vxdHKqBL QgbNlXArT50Uxr5YKQ/gZI0qJbmKKaTYkygizfQ= X-Google-Smtp-Source: ABdhPJw7gsq/+fvkEKSCSm3yKFE6DPRbUVWzZN85i2Fehlialh2mtPMtR719GkUwgLNPT+CU/MrGtgMw3knsmhlp4iM= X-Received: by 2002:a05:6808:205:: with SMTP id l5mr2281340oie.167.1635251997867; Tue, 26 Oct 2021 05:39:57 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Tue, 26 Oct 2021 13:39:31 +0100 Message-ID: To: Christer Holmberg Cc: RTCWeb IETF , Justin Uberti , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="00000000000073818305cf40c6c4" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 12:40:07 -0000 --00000000000073818305cf40c6c4 Content-Type: text/plain; charset="UTF-8" Thanks, Christer. I've added an issue to the tracker for this. When you get the RFC number, can you please let the author team know, so that they can update? thanks, Ted On Tue, Oct 26, 2021 at 12:15 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > I already earlier commented that the draft still references RFC 8843, > eventhough it should be updated to draft-8843bis. > > > > But, as draft-8843bis is now in the RFC editors queue, I guess that update > can be done once the RFC number for 8843bis has been assigned. > > > > Regards, > > > > Christer > > > > *From:* rtcweb *On Behalf Of *Ted Hardie > *Sent:* tiistai 26. lokakuuta 2021 13.55 > *To:* RTCWeb IETF ; Justin Uberti ; > Cullen Jennings ; Eric Rescorla ; Sean > Turner > *Subject:* [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > This email serves as the start of a working group last call for > draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF > meeting, it will be slightly longer than normal, ending on November 16, > 2021. > > > > Please send comments to the list. > > > > thanks, > > > > Ted and Sean > --00000000000073818305cf40c6c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tha= nks, Christer.=C2=A0 I've added an issue to the tracker for this.=C2=A0= When you get the RFC number, can you please let the author team know, so t= hat they can update?

= thanks,

Ted

On T= ue, Oct 26, 2021 at 12:15 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=

Hi,

=C2=A0

I already earlier commented tha= t the draft still references RFC 8843, eventhough it should be updated to d= raft-8843bis.

=C2=A0

But, as draft-8843bis is now in= the RFC editors queue, I guess that update can be done once the RFC number= for 8843bis has been assigned.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Ted Hardie
Sent: tiistai 26. lokakuuta 2021 13.55
To: RTCWeb IETF <rtcweb@ietf.org>; Justin Uberti <justin@uberti.name>; Cullen Jennings &l= t;fluffy@iii.ca>;= Eric Rescorla <ekr@rt= fm.com>; Sean Turner <sean@sn3rd.com>
Subject: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rf= c8829bis-01.txt

=C2=A0

This email serves as = the start of a working group last call for draft-uberti-rtcweb-rfc8829bis-0= 1.txt.=C2=A0 Because of the upcoming IETF meeting, it will be slightly long= er than normal, ending on November 16, 2021.

=C2=A0<= /span>

Please send comments = to the list.

=C2=A0<= /span>

thanks,=

=C2=A0<= /span>

Ted and Sean

--00000000000073818305cf40c6c4-- From nobody Tue Oct 26 10:01:19 2021 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 3B1DD3A1512 for ; Tue, 26 Oct 2021 10:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 SCt2CzIdhQ5d for ; Tue, 26 Oct 2021 10:01:12 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 835F63A150A for ; Tue, 26 Oct 2021 10:01:12 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id t1so10025368qvb.1 for ; Tue, 26 Oct 2021 10:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JFDePD2tetHjDcOgobHXWcZat3UZ8fUqZ5RULscIUCA=; b=t33OxY1702rMemtRnLFrNdhUg6sKyHHzuD0bSPOQ8UBluOC819NDdV3KAOh1hYux1m FxxlloBULDavC+pUAR1VlXyM7h4iuP0qNVBXUQrjKVrCSdkEfyVFzyEoeCbEEHnFFluR qfKR8yTnES/2g9zQuUXDWCPd5ab9RChLyxscs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JFDePD2tetHjDcOgobHXWcZat3UZ8fUqZ5RULscIUCA=; b=Xs1UdT8qQJyvlHFN6MNAQg40RrH/sIFndHCaZXXpLNEUPSSVoNjyTmZjTxstNhlV7i qCmxQ2O4OHkIAT+a8Fl/L/Tw1zjnHPF1xYl3dJ8gkZ55hiqx6sghwVQB3c/XZ8w2XwCr GoJd20IfSld2ZgcCnZlzpNDP/SzzTFhL7+0494M+ta6WGoQiU24LOlSzX14oIcSaOvcO nbxDSe+nzacU9xuM3eenoYqQA1AxnOWn5+upBHTisbb6TpkliIs/CO3LjAalpgIiRo7A wGjR6dXKUUYGYt013Ovq6JpLtnLGGXZM7YP/vRlI/K21qj0LbEqC0P5Rbkh7CtSr6OMz 9Z8w== X-Gm-Message-State: AOAM531OCUEtIi06YZaIeb7/0igol1uN4KPkPjSsVtwU1q1yISyGEZ+I e4SuCzcj8CPMrNNhka1sbLNCX57IUogdPw== X-Google-Smtp-Source: ABdhPJz/X2REdHDsR08wrKkqdEymUbaFTwGeAdsBloHc9U3k9Lh+O9p4kalgC+8AW2QZmWxnyS+jeA== X-Received: by 2002:a05:6214:301b:: with SMTP id ke27mr23687779qvb.42.1635267669666; Tue, 26 Oct 2021 10:01:09 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id f23sm10552609qtq.40.2021.10.26.10.01.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 10:01:09 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id m63so36523330ybf.7 for ; Tue, 26 Oct 2021 10:01:08 -0700 (PDT) X-Received: by 2002:a25:c608:: with SMTP id k8mr21228993ybf.22.1635267668581; Tue, 26 Oct 2021 10:01:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 26 Oct 2021 13:00:57 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Cc: RTCWeb IETF , Justin Uberti , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="0000000000007fa4b205cf446cb6" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 17:01:17 -0000 --0000000000007fa4b205cf446cb6 Content-Type: text/plain; charset="UTF-8" Hi Ted, I have mentioned on git that: 1. The reference to RFC 8843bis is missing 2. The following language is factually incorrect: This is by design, but could cause issues in the rare case of sending a subsequent offer as an initial offer to a non-bundle-aware endpoint via Third Party Call Control (3PCC). Primarily, this will cause issues if a subsequent offer is used as an initial even with bundle-aware end points. An offer with no bundle-only attributes for bundled m= lines might not get processed correctly. Second, I would not comment on how frequent this call scenario is going to be unless we have to. My suggested language was: This is by design, but could cause issues in case of sending a subsequent offer as an initial offer due to Third Party Call Control (3PCC). In such cases, the signaling application is responsible for adding bundle-only attributes to the offer so that it can be used as an initial offer. Best Regards, _____________ Roman Shpount On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie wrote: > This email serves as the start of a working group last call for > draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF > meeting, it will be slightly longer than normal, ending on November 16, > 2021. > > Please send comments to the list. > > thanks, > > Ted and Sean > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --0000000000007fa4b205cf446cb6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

I have mentioned on git that:
1. The reference to RFC 8843bis=C2=A0is missing

2. The following language is factually incorrect:

This is by design, but could cause issues in the rare case of sendin= g a subsequent offer as an initial offer to a non-bundle-aware endpoint via= Third Party Call Control (3PCC).

Primarily, this = will cause issues if a subsequent offer is used as an initial even with bun= dle-aware end points. An offer with no bundle-only attributes for bundled= =C2=A0m=3D lines might=C2=A0not get processed correctly. Second, I would no= t comment on how frequent=C2=A0this call scenario is going to be unless we = have to.

My suggested language=C2=A0was:

This is by design, but could cause issues in case of = sending a subsequent offer as an initial offer due to Third Party Call Cont= rol (3PCC). In such cases, the signaling application is responsible for add= ing bundle-only attributes to the offer so that it can be used as an initia= l offer.

Best Regards,
_____________
Roman Shpount


On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie <ted.ietf@gmail.com> wrote:
This email serves as the start of= a working group last call for draft-uberti-rtcweb-rfc8829bis-01.txt.=C2=A0= Because of the upcoming IETF meeting, it will be slightly longer than norm= al, ending on November 16, 2021.

Please send comments to the list.

thanks,

= Ted and Sean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000007fa4b205cf446cb6-- From nobody Tue Oct 26 10:15:31 2021 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 2DD443A15E7 for ; Tue, 26 Oct 2021 10:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 yvZxS6vTxns7 for ; Tue, 26 Oct 2021 10:15:21 -0700 (PDT) Received: from mail-il1-f180.google.com (mail-il1-f180.google.com [209.85.166.180]) (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 7C5243A15DB for ; Tue, 26 Oct 2021 10:15:19 -0700 (PDT) Received: by mail-il1-f180.google.com with SMTP id j10so21868ilu.2 for ; Tue, 26 Oct 2021 10:15:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOUpJWydJhXBvoMqTpkUipcA6aFkLVLbvpPENiwdpDY=; b=CB9LH8AhOhrj3RVZk1tCWgG/hTgZM8paMUt5jY7eWzgDHN2uEZdJj9r6khBpVpgf9+ e0GHabmww9HOxXx2zrjACIFLRuxOWAH6loLudVa2bzWkfOLp+ROuv4bqPLH9KilY+TxM c99D6TNxcY6VHhx8CHo68c1BIynJTCd93kP0j3S61gqaLhUn+u8DNXXRwu99zpoHcRYy UmHQcImoIT3pHeeaK2zBFUzSQ2VPR4rsTq0K+2beAhXrGIy4Nw8cfTsTgcMtLWe8r/E1 7Ldqa8Oiq26iTm7t4xJituST0kXx/n2nfUPImgab49gPeqEHTsB5Ttj2MfiDL/WZDPfF Eylg== X-Gm-Message-State: AOAM5301yvXNktPnxaNXgMvdThC+jmI9UhJ7/XF4/jWNbBSmRS/184a6 qy2FXGiApycZNyITcongLg1hQARKkVg/AxrBSOA= X-Google-Smtp-Source: ABdhPJwGq1KKvfmTtn51WbrsqLm0cy2baMQ7yYkj3v5tShNoSUjRZE19HMXE25dJETasJBcwg+98wyrjq7oIVWDo8kw= X-Received: by 2002:a92:8e53:: with SMTP id k19mr14822862ilh.236.1635268518483; Tue, 26 Oct 2021 10:15:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Tue, 26 Oct 2021 10:15:02 -0700 Message-ID: To: Roman Shpount Cc: Ted Hardie , RTCWeb IETF , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="000000000000281ad605cf449f16" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 17:15:28 -0000 --000000000000281ad605cf449f16 Content-Type: text/plain; charset="UTF-8" Agree we should add a reference to 8843-bis. I assume we can do that in the endgame as (I believe) no text in 8829bis needs to change. Regarding 3PCC: - bundle clients should be able to accept initial offers without bundle-only. If not, we should fix that in 8843bis, as this seems like an unnecessary limitation - current implementations seem to be managing this OK. - the stats on BUNDLE show that it has been widely adopted (99.999% usage when there is more than 1 a/v stream), and these numbers are only increasing. If "rare" seems overly opinionated, we could use "uncommon" instead. Regarding the suggested workaround: - adding a=bundle-only is insufficient, the application would also need to insert zero ports for the bundled m= lines. It's also not clear that this would lead to a good outcome, as the non-bundle endpoint would only be able to accept the first bundled m= line. So I would suggest that if 3PCC with non-bundle-aware endpoints is likely, the application should just eat the a=group attribute for bundle to prevent bundling in the first place. On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount wrote: > Hi Ted, > > I have mentioned on git that: > 1. The reference to RFC 8843bis is missing > > 2. The following language is factually incorrect: > > This is by design, but could cause issues in the rare case of sending a > subsequent offer as an initial offer to a non-bundle-aware endpoint via > Third Party Call Control (3PCC). > > Primarily, this will cause issues if a subsequent offer is used as an > initial even with bundle-aware end points. An offer with no bundle-only > attributes for bundled m= lines might not get processed correctly. Second, > I would not comment on how frequent this call scenario is going to be > unless we have to. > > My suggested language was: > > This is by design, but could cause issues in case of sending a subsequent > offer as an initial offer due to Third Party Call Control (3PCC). In such > cases, the signaling application is responsible for adding bundle-only > attributes to the offer so that it can be used as an initial offer. > > Best Regards, > _____________ > Roman Shpount > > > On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie wrote: > >> This email serves as the start of a working group last call for >> draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF >> meeting, it will be slightly longer than normal, ending on November 16, >> 2021. >> >> Please send comments to the list. >> >> thanks, >> >> Ted and Sean >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >> > --000000000000281ad605cf449f16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree we should add a reference to 8843-bis. I assume we c= an do that in the endgame as (I believe) no text in 8829bis needs to change= .

Regarding 3PCC:
- bundle clients should be a= ble to accept initial offers without bundle-only. If not, we should fix tha= t in 8843bis, as this seems like an unnecessary limitation - current implem= entations seem to be managing this OK.
- the stats on BUNDLE show= that it has been widely adopted (99.999% usage when there is more than 1 a= /v stream), and these numbers are only increasing. If "rare" seem= s overly opinionated, we could use "uncommon" instead.
=
Regarding the suggested workaround:
- adding a=3Db= undle-only is insufficient, the application would also need to insert zero = ports for the bundled m=3D lines. It's also not clear that this would l= ead to a good outcome, as the non-bundle endpoint would only be able to acc= ept the first bundled m=3D line. So I would suggest that if 3PCC with non-b= undle-aware endpoints is likely, the application should just eat the a=3Dgr= oup attribute for bundle to prevent bundling in the first place.
=

On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount <roman@telurix.com> wrote:
Hi Ted,

I have mentioned on git that:
1. The reference to RFC 88= 43bis=C2=A0is missing

2. The following language is= factually incorrect:

This is by design, but could= cause issues in the rare case of sending a subsequent offer as an initial = offer to a non-bundle-aware endpoint via Third Party Call Control (3PCC).

Primarily, this will cause issues if a subsequent o= ffer is used as an initial even with bundle-aware end points. An offer with= no bundle-only attributes for bundled=C2=A0m=3D lines might=C2=A0not get p= rocessed correctly. Second, I would not comment on how frequent=C2=A0this c= all scenario is going to be unless we have to.

My = suggested language=C2=A0was:

This is by design, but could cause issues in case of sending a= subsequent offer as an initial offer due to Third Party Call Control (3PCC= ). In such cases, the signaling application is responsible for adding bundl= e-only attributes to the offer so that it can be used as an initial offer.<= /div>

Best Regards,
__= ___________
Roman Shpount


On Tue, Oct 26, 2021 at 6= :55 AM Ted Hardie <ted.ietf@gmail.com> wrote:
This email serves as the start of a working group last ca= ll for draft-uberti-rtcweb-rfc8829bis-01.txt.=C2=A0 Because of the upcoming= IETF meeting, it will be slightly longer than normal, ending on November 1= 6, 2021.

Please send comm= ents to the list.

thanks,=

Ted and Sean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--000000000000281ad605cf449f16-- From nobody Tue Oct 26 15:06:52 2021 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 0AB083A12FD for ; Tue, 26 Oct 2021 15:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 TtPuqoETQOvD for ; Tue, 26 Oct 2021 15:06:46 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 0859B3A040A for ; Tue, 26 Oct 2021 15:06:45 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id h65so664159qke.0 for ; Tue, 26 Oct 2021 15:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8++sLyf19++E2B3BKiRoy9q3TxdyFWuNhOUrHdaxsPw=; b=NeB8a+udyg/nH+TqGxgDcsEjWG++1q/1rujarwKK28WEwugIfcc/Wbm1aB65vh54Ru h2GLltFwf4zIgJ+Smcz+pMgpNHUeuYt/9SIacVGjP+cLHQUkC614pmyzsEaieUnIy8XG H48PSdxa4fAqBkhy0XegDeFsC9xCBBBy8lSHQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8++sLyf19++E2B3BKiRoy9q3TxdyFWuNhOUrHdaxsPw=; b=DeVS9kbHwB8gdA7CS1tw59AzVXMHt6ZkuVblH8tQDUrDKAUuVpYiUIlQdH+CMKZDUx 77MWmfbOt9AmZqCH5YjiKcPcpBr7sL+eaIE4GPcBM5KcX22+Id/cTTx3XfhqMp0J78sW QSEH6qbFTKdPue2wSZC3v4bwzdKznjSpRJ753Md2tqyqyzAlGqHn8YawoC7ebcX2tgTD VNgLXDBVba221sjVaa+kvz52YDLoDgFKREeXyDTNU+wVfPYsY2eM/D5WBVvIeHM6TvaG 2b1CCbLyS2IcVb4IXAMeKce/ay+aRF6edghL5uuhTmKCdtNhumZph0E9nVBCYK2MOQqA 3HXw== X-Gm-Message-State: AOAM530YToVrwJUM0fo7/2yWWQ1Zd4fuRA+185cLZu5GOJ/nRq5H+SyH ndzSPYU/selyU1S81GDIX8382D08QguL7Q== X-Google-Smtp-Source: ABdhPJw6c5nh8A4XTsnazroORfkzLdkKxOqtJ6J5pSP8RPs8cc14BH/Pf4BYiQJSkwBdFjfLSFd0Qw== X-Received: by 2002:a37:6213:: with SMTP id w19mr155557qkb.408.1635286003560; Tue, 26 Oct 2021 15:06:43 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com. [209.85.219.170]) by smtp.gmail.com with ESMTPSA id l3sm11667149qkj.110.2021.10.26.15.06.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 15:06:43 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id r184so1194988ybc.10 for ; Tue, 26 Oct 2021 15:06:42 -0700 (PDT) X-Received: by 2002:a5b:f04:: with SMTP id x4mr26995594ybr.396.1635286002160; Tue, 26 Oct 2021 15:06:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 26 Oct 2021 18:06:31 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Ted Hardie , RTCWeb IETF , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="00000000000043da2c05cf48b12c" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 26 Oct 2021 22:06:51 -0000 --00000000000043da2c05cf48b12c Content-Type: text/plain; charset="UTF-8" Regarding 3PCC, bundle clients should be able to accept the initial offer without bundle-only. Unfortunately there is nothing there that prevents them from moving an m= line out of the bundle unless it is marked with bundle-only. I was not thinking about the frequency of use of 3PCC with non-bundle endpoints (extremely rare) but about the use of 3PCC in general (more common and hard to identify). I agree that a=bundle-only is insufficient. We do need to add port zero. This will ensure that a bundle-aware endpoint will not take the m= line out of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the application should create a new PeerConnection instead with an appropriate bundle policy. _____________ Roman Shpount On Tue, Oct 26, 2021 at 1:15 PM Justin Uberti wrote: > Agree we should add a reference to 8843-bis. I assume we can do that in > the endgame as (I believe) no text in 8829bis needs to change. > > Regarding 3PCC: > - bundle clients should be able to accept initial offers without > bundle-only. If not, we should fix that in 8843bis, as this seems like an > unnecessary limitation - current implementations seem to be managing this > OK. > - the stats on BUNDLE show that it has been widely adopted (99.999% usage > when there is more than 1 a/v stream), and these numbers are only > increasing. If "rare" seems overly opinionated, we could use "uncommon" > instead. > > Regarding the suggested workaround: > - adding a=bundle-only is insufficient, the application would also need to > insert zero ports for the bundled m= lines. It's also not clear that this > would lead to a good outcome, as the non-bundle endpoint would only be able > to accept the first bundled m= line. So I would suggest that if 3PCC with > non-bundle-aware endpoints is likely, the application should just eat the > a=group attribute for bundle to prevent bundling in the first place. > > > On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount wrote: > >> Hi Ted, >> >> I have mentioned on git that: >> 1. The reference to RFC 8843bis is missing >> >> 2. The following language is factually incorrect: >> >> This is by design, but could cause issues in the rare case of sending a >> subsequent offer as an initial offer to a non-bundle-aware endpoint via >> Third Party Call Control (3PCC). >> >> Primarily, this will cause issues if a subsequent offer is used as an >> initial even with bundle-aware end points. An offer with no bundle-only >> attributes for bundled m= lines might not get processed correctly. Second, >> I would not comment on how frequent this call scenario is going to be >> unless we have to. >> >> My suggested language was: >> >> This is by design, but could cause issues in case of sending a subsequent >> offer as an initial offer due to Third Party Call Control (3PCC). In such >> cases, the signaling application is responsible for adding bundle-only >> attributes to the offer so that it can be used as an initial offer. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie wrote: >> >>> This email serves as the start of a working group last call for >>> draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF >>> meeting, it will be slightly longer than normal, ending on November 16, >>> 2021. >>> >>> Please send comments to the list. >>> >>> thanks, >>> >>> Ted and Sean >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> --00000000000043da2c05cf48b12c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regarding 3PCC, bundle clients should be able to accept th= e initial offer without bundle-only. Unfortunately there is nothing=C2=A0th= ere that prevents them from moving an m=3D line out of the bundle unless it= is marked with bundle-only.

I was=C2=A0not thinking abo= ut the frequency=C2=A0of use of 3PCC with non-bundle endpoints (extremely r= are) but about the use of 3PCC in general (more common and hard to identify= ).

I agree that a=3Dbundle-only=C2=A0is insufficie= nt. We do need to add port zero. This will ensure that a bundle-aware endpo= int will not take the m=3D line out of the bundle. If 3PCC with a non-bundl= e-aware endpoint is likely, the application should create a new PeerConnect= ion instead with an appropriate bundle policy.
___= __________
Roman Shpount


On Tue, Oct 26, 2021 at 1:= 15 PM Justin Uberti <justin@uberti= .name> wrote:
Agree we should add a reference to 8843-bis. I assume= we can do that in the endgame as (I believe) no text in 8829bis needs to c= hange.

Regarding 3PCC:
- bundle clients should= be able to accept initial offers without bundle-only. If not, we should fi= x that in 8843bis, as this seems like an unnecessary limitation - current i= mplementations seem to be managing this OK.
- the stats on BUNDLE= show that it has been widely adopted (99.999% usage when there is more tha= n 1 a/v stream), and these numbers are only increasing. If "rare"= seems overly opinionated, we could use "uncommon" instead.
=

Regarding the suggested workaround:
- adding = a=3Dbundle-only is insufficient, the application would also need to insert = zero ports for the bundled m=3D lines. It's also not clear that this wo= uld lead to a good outcome, as the non-bundle endpoint would only be able t= o accept the first bundled m=3D line. So I would suggest that if 3PCC with = non-bundle-aware endpoints is likely, the application should just eat the a= =3Dgroup attribute for bundle to prevent bundling in the first place.
=


On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount <roman@telurix.com> w= rote:
Hi Ted,

I have mentioned on git that:
1. The reference to RFC 8843bis=C2=A0is missing

2= . The following language is factually incorrect:

T= his is by design, but could cause issues in the rare case of sending a subs= equent offer as an initial offer to a non-bundle-aware endpoint via Third P= arty Call Control (3PCC).

Primarily, this will cau= se issues if a subsequent offer is used as an initial even with bundle-awar= e end points. An offer with no bundle-only attributes for bundled=C2=A0m=3D= lines might=C2=A0not get processed correctly. Second, I would not comment = on how frequent=C2=A0this call scenario is going to be unless we have to.

My suggested language=C2=A0was:

This is by design, but could cause = issues in case of sending a subsequent offer as an initial offer due to Thi= rd Party Call Control (3PCC). In such cases, the signaling application is r= esponsible for adding bundle-only attributes to the offer so that it can be= used as an initial offer.

Best Regard= s,
_____________
Roman Shpount


On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie <ted.ietf@gmail.com> wrote:
This email serves as the start= of a working group last call for draft-uberti-rtcweb-rfc8829bis-01.txt.=C2= =A0 Because of the upcoming IETF meeting, it will be slightly longer than n= ormal, ending on November 16, 2021.

Please send comments to the list.

thanks,

Ted and Sean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--00000000000043da2c05cf48b12c-- From nobody Wed Oct 27 00:47:54 2021 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 8A8093A073D for ; Wed, 27 Oct 2021 00:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 XODRfz545pwU for ; Wed, 27 Oct 2021 00:47:48 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 8DDE33A0691 for ; Wed, 27 Oct 2021 00:47:48 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id y15-20020a9d460f000000b0055337e17a55so2386043ote.10 for ; Wed, 27 Oct 2021 00:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jseGOZk8jqZTBw7hEKX4PN/Pr2B4qWHhjKL9zr7o1jg=; b=bOJfm1nyoGgsdXqql5Y0fqsM9brrkLboCptbhgxtfM6VbmDF168U0oF8HlMnABS0aY fZKmDSlOIIhN6ROg6Qc98Emc4newGRMcEF2EZv8GKf8Hqa7g3261fJkEQRU9FHDfSDoG iLUiH+dzrOnbZTw+6qUFN+bmCUWhK1+hY3R2Du9NQcFJM7lOZDsEx/ZNYke08E8NzD/6 k4doFNiseJGgcnK4JhdHNFeg4nVp1Dfmj3upH15hsEmoBQwE5NxlmGaM1RsXXbPyWoft DGG4YlsJcVwDUqcuaTn8rLbiNY6NWe++D4weYYh2vUF1kH28oYDBz2sNSqrZTWmmKa44 Z8xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jseGOZk8jqZTBw7hEKX4PN/Pr2B4qWHhjKL9zr7o1jg=; b=EwOWGirUJFNZKZNLtCGn71Vz+JuloZLnguqdQaLit4gWmi8QvM/R9Adeuh93rrp5FA cP6K0J2pN0N+ii8KQFLfJad7l1i2evxZR/QhBCWaAYMhNz2q6dMEFtK5NiHrStM156Rv SmjhMT2+79dfYDngrfzonvY8loHkbNt81XNBrq6ixrxQ1AoOI0kyI9oqP0yCllSXfOFd 5oDckQ1N5SscXkz99wyJd2puDWXGn352S3nnML1PelljHK9lqdJpI+bfQ4dg3tS9On8Y 0mc+rmmKyFV1MSyIQAC3FSxEjAv5v88hJUzKjVMeSa7m3h2DiVv20vJ1EKrz9SHJOwU2 8cew== X-Gm-Message-State: AOAM531bocgpmsA1qnD+zMWW2so4oP2obqkyJ9ohVI9lAEl3ZwQQfFd7 vePH1HRtNUnbUNqv4fI7O8k4WDZl+4Wpimkn7jg= X-Google-Smtp-Source: ABdhPJzAGVSSCFd7+6vwvsDfmOTx5fT0c3hTMTTcbE8UkfKTUsf1NPVV8BR/VHY+3poM21XsyezsXqEujrOvVzIRQ8I= X-Received: by 2002:a05:6830:1045:: with SMTP id b5mr24066854otp.338.1635320866377; Wed, 27 Oct 2021 00:47:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Hardie Date: Wed, 27 Oct 2021 08:47:20 +0100 Message-ID: To: Justin Uberti Cc: Roman Shpount , RTCWeb IETF , Cullen Jennings , Eric Rescorla , Sean Turner Content-Type: multipart/alternative; boundary="0000000000005591ee05cf50cf79" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 27 Oct 2021 07:47:53 -0000 --0000000000005591ee05cf50cf79 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 26, 2021 at 6:15 PM Justin Uberti wrote: > Agree we should add a reference to 8843-bis. I assume we can do that in > the endgame as (I believe) no text in 8829bis needs to change. > > Yes, it can be done later; if the RFC number is available before IETF last call, in the version that goes to IETF last call. regards, Ted > Regarding 3PCC: > - bundle clients should be able to accept initial offers without > bundle-only. If not, we should fix that in 8843bis, as this seems like an > unnecessary limitation - current implementations seem to be managing this > OK. > - the stats on BUNDLE show that it has been widely adopted (99.999% usage > when there is more than 1 a/v stream), and these numbers are only > increasing. If "rare" seems overly opinionated, we could use "uncommon" > instead. > > Regarding the suggested workaround: > - adding a=bundle-only is insufficient, the application would also need to > insert zero ports for the bundled m= lines. It's also not clear that this > would lead to a good outcome, as the non-bundle endpoint would only be able > to accept the first bundled m= line. So I would suggest that if 3PCC with > non-bundle-aware endpoints is likely, the application should just eat the > a=group attribute for bundle to prevent bundling in the first place. > > > On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount wrote: > >> Hi Ted, >> >> I have mentioned on git that: >> 1. The reference to RFC 8843bis is missing >> >> 2. The following language is factually incorrect: >> >> This is by design, but could cause issues in the rare case of sending a >> subsequent offer as an initial offer to a non-bundle-aware endpoint via >> Third Party Call Control (3PCC). >> >> Primarily, this will cause issues if a subsequent offer is used as an >> initial even with bundle-aware end points. An offer with no bundle-only >> attributes for bundled m= lines might not get processed correctly. Second, >> I would not comment on how frequent this call scenario is going to be >> unless we have to. >> >> My suggested language was: >> >> This is by design, but could cause issues in case of sending a subsequent >> offer as an initial offer due to Third Party Call Control (3PCC). In such >> cases, the signaling application is responsible for adding bundle-only >> attributes to the offer so that it can be used as an initial offer. >> >> Best Regards, >> _____________ >> Roman Shpount >> >> >> On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie wrote: >> >>> This email serves as the start of a working group last call for >>> draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF >>> meeting, it will be slightly longer than normal, ending on November 16, >>> 2021. >>> >>> Please send comments to the list. >>> >>> thanks, >>> >>> Ted and Sean >>> _______________________________________________ >>> rtcweb mailing list >>> rtcweb@ietf.org >>> https://www.ietf.org/mailman/listinfo/rtcweb >>> >> --0000000000005591ee05cf50cf79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Oct 26, 2021 at 6:15 PM Justin Uberti <justin@uberti.name> wrote:
Agree we should add a reference to 8843-bis. I assume w= e can do that in the endgame as (I believe) no text in 8829bis needs to cha= nge.

Yes, it can be done later; if the RFC number is avai= lable before IETF last call, in the version that goes to IETF last call.=C2= =A0

regards,

Ted

= =C2=A0
Regarding 3PCC:
- bundle clients should be ab= le to accept initial offers without bundle-only. If not, we should fix that= in 8843bis, as this seems like an unnecessary limitation - current impleme= ntations seem to be managing this OK.
- the stats on BUNDLE show = that it has been widely adopted (99.999% usage when there is more than 1 a/= v stream), and these numbers are only increasing. If "rare" seems= overly opinionated, we could use "uncommon" instead.
<= br>
Regarding the suggested workaround:
- adding a=3Dbu= ndle-only is insufficient, the application would also need to insert zero p= orts for the bundled m=3D lines. It's also not clear that this would le= ad to a good outcome, as the non-bundle endpoint would only be able to acce= pt the first bundled m=3D line. So I would suggest that if 3PCC with non-bu= ndle-aware endpoints is likely, the application should just eat the a=3Dgro= up attribute for bundle to prevent bundling in the first place.
<= br>

On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount <roman@telurix.com> wrote:
H= i Ted,

I have mentioned on git that:
1. The re= ference to RFC 8843bis=C2=A0is missing

2. The foll= owing language is factually incorrect:

This is by = design, but could cause issues in the rare case of sending a subsequent off= er as an initial offer to a non-bundle-aware endpoint via Third Party Call = Control (3PCC).

Primarily, this will cause issues = if a subsequent offer is used as an initial even with bundle-aware end poin= ts. An offer with no bundle-only attributes for bundled=C2=A0m=3D lines mig= ht=C2=A0not get processed correctly. Second, I would not comment on how fre= quent=C2=A0this call scenario is going to be unless we have to.
<= br>
My suggested language=C2=A0was:

This is by design, but could cause issues in = case of sending a subsequent offer as an initial offer due to Third Party C= all Control (3PCC). In such cases, the signaling application is responsible= for adding bundle-only attributes to the offer so that it can be used as a= n initial offer.

Best Regards,
_____________
Roman Shpount

On Tue, = Oct 26, 2021 at 6:55 AM Ted Hardie <ted.ietf@gmail.com> wrote:
This email serves as the start of a working group last call for = draft-uberti-rtcweb-rfc8829bis-01.txt.=C2=A0 Because of the upcoming IETF m= eeting, it will be slightly longer than normal, ending on November 16, 2021= .

Please send comments to the list.
<= br>
thanks,

Ted and Sean
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb
--0000000000005591ee05cf50cf79-- From nobody Fri Oct 29 10:35:38 2021 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 5078D3A14CC for ; Fri, 29 Oct 2021 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=alphaexplorationco.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 uj7wrPoZlMjU for ; Fri, 29 Oct 2021 10:35:32 -0700 (PDT) Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 96FFE3A13DA for ; Fri, 29 Oct 2021 10:35:32 -0700 (PDT) Received: by mail-oo1-xc2b.google.com with SMTP id y133-20020a4a458b000000b002bb71084420so2038081ooa.6 for ; Fri, 29 Oct 2021 10:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RiAeyRrGdUkHfPLBhmqvO0YlvJB5k1tJ8BL7mdFIybc=; b=diQuAU+DDT8fnZL6cAh27/kBNSemGAJGbGvBRsQelnTJf7OUzlVdnRiXssbj81P6fk AiWOcMXctMBw6EYQdJRAI0hDfaJigWn8a+e9V1gej4xVYJgEXjgyuVU4Sv9QYE4JSzH6 +HqWlPPN8TFGvUVpbf1ODieRQWfZ72zwbkyV+PIDfGsPM1tP8UBg3ldVlUZVTOb448Db nLOUuT1gse0Pbeb0slb9SyTfADrL7kdNULy9pfE5jJTF3lbj3Tsg2molvjA1XX2lKReR wk6fDL27Z5V5cc0rHpzmGWOJW8VLkKXDX1mJVAEkttIgX4YhnPrF1ncMSHYu+1IQAP+z hezg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RiAeyRrGdUkHfPLBhmqvO0YlvJB5k1tJ8BL7mdFIybc=; b=SRAQRbp05pA9Y62WydCITweig7cqz8FtLsatlUphqwxhgVKPJrmcf7Y0eLBtHmQVac 4er0BaGInmX5wHOXkL2ocgYA3w0aW9ozQYhXzWHPyWpWXWUV5iRTywhg32IlCQ2qWb4C LBMHqR+CdPOz/Dw8jqviKG0nfXfPBsp4TZ9/uuzpraQANEeRB/t6T/zYRayZChKT9yJM F7KZb0EzAgOzhlcQU4SAIottbJqqs34aaB6ZK9i2V4nJ8BvUm+c1KTZErfNm8yKdBWR4 4PNXrFnei7tXn/bws52HzEQPSEQmHQ0E0QmK4Uf4gxSAULrGOoIahB9xAMZlTbM4vxQW KmXg== X-Gm-Message-State: AOAM532/BpTYgTHK3aCE7PUlojIfQPwoLhvtl4QDM1mLjhXu2h++dGUJ dz+40MXSZZo7Yo/D9BbJ5R9GWUU8LlOlgKu16JHDqw== X-Google-Smtp-Source: ABdhPJy6vZlTtNN90J2/I9rqc540ucLXJ/qrf0otAO/ufAq4O16L9dE/u2iE6cc/lQ3xBbpOjDCR9A//jCkIP1cT6jc= X-Received: by 2002:a4a:e9b5:: with SMTP id t21mr2019393ood.59.1635528927674; Fri, 29 Oct 2021 10:35:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 29 Oct 2021 10:35:17 -0700 Message-ID: To: Roman Shpount Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000c1183405cf81401a" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 29 Oct 2021 17:35:37 -0000 --000000000000c1183405cf81401a Content-Type: text/plain; charset="UTF-8" On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount wrote: > Regarding 3PCC, bundle clients should be able to accept the initial offer > without bundle-only. Unfortunately there is nothing there that prevents > them from moving an m= line out of the bundle unless it is marked with > bundle-only. > If it's already bundled, I don't think it can be unbundled, since there is no other transport to move it to. This is the same situation as in subsequent o/a exchanges. > > I was not thinking about the frequency of use of 3PCC with non-bundle > endpoints (extremely rare) but about the use of 3PCC in general (more > common and hard to identify). > > I agree that a=bundle-only is insufficient. We do need to add port zero. > This will ensure that a bundle-aware endpoint will not take the m= line out > of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the > application should create a new PeerConnection instead with an appropriate > bundle policy. > As noted above I don't think taking an m= line out of the bundle is allowed when a shared port is already in use. > _____________ > Roman Shpount > > > On Tue, Oct 26, 2021 at 1:15 PM Justin Uberti wrote: > >> Agree we should add a reference to 8843-bis. I assume we can do that in >> the endgame as (I believe) no text in 8829bis needs to change. >> >> Regarding 3PCC: >> - bundle clients should be able to accept initial offers without >> bundle-only. If not, we should fix that in 8843bis, as this seems like an >> unnecessary limitation - current implementations seem to be managing this >> OK. >> - the stats on BUNDLE show that it has been widely adopted (99.999% usage >> when there is more than 1 a/v stream), and these numbers are only >> increasing. If "rare" seems overly opinionated, we could use "uncommon" >> instead. >> >> Regarding the suggested workaround: >> - adding a=bundle-only is insufficient, the application would also need >> to insert zero ports for the bundled m= lines. It's also not clear that >> this would lead to a good outcome, as the non-bundle endpoint would only be >> able to accept the first bundled m= line. So I would suggest that if 3PCC >> with non-bundle-aware endpoints is likely, the application should just eat >> the a=group attribute for bundle to prevent bundling in the first place. >> >> >> On Tue, Oct 26, 2021 at 10:01 AM Roman Shpount wrote: >> >>> Hi Ted, >>> >>> I have mentioned on git that: >>> 1. The reference to RFC 8843bis is missing >>> >>> 2. The following language is factually incorrect: >>> >>> This is by design, but could cause issues in the rare case of sending a >>> subsequent offer as an initial offer to a non-bundle-aware endpoint via >>> Third Party Call Control (3PCC). >>> >>> Primarily, this will cause issues if a subsequent offer is used as an >>> initial even with bundle-aware end points. An offer with no bundle-only >>> attributes for bundled m= lines might not get processed correctly. Second, >>> I would not comment on how frequent this call scenario is going to be >>> unless we have to. >>> >>> My suggested language was: >>> >>> This is by design, but could cause issues in case of sending a >>> subsequent offer as an initial offer due to Third Party Call Control >>> (3PCC). In such cases, the signaling application is responsible for adding >>> bundle-only attributes to the offer so that it can be used as an initial >>> offer. >>> >>> Best Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie wrote: >>> >>>> This email serves as the start of a working group last call for >>>> draft-uberti-rtcweb-rfc8829bis-01.txt. Because of the upcoming IETF >>>> meeting, it will be slightly longer than normal, ending on November 16, >>>> 2021. >>>> >>>> Please send comments to the list. >>>> >>>> thanks, >>>> >>>> Ted and Sean >>>> _______________________________________________ >>>> 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 > --000000000000c1183405cf81401a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 26, 2021 at 3:06 PM Roman= Shpount <roman@telurix.com>= wrote:
Regarding 3PCC, bundle clients should be able to accept the initia= l offer without bundle-only. Unfortunately there is nothing=C2=A0there that= prevents them from moving an m=3D line out of the bundle unless it is mark= ed with bundle-only.

If it's alre= ady bundled, I don't think it can be unbundled, since there is no other= transport to move it to. This is the same situation as in subsequent o/a e= xchanges.=C2=A0

I was=C2=A0not thinking about the frequenc= y=C2=A0of use of 3PCC with non-bundle endpoints (extremely rare) but about = the use of 3PCC in general (more common and hard to identify).
I agree that a=3Dbundle-only=C2=A0is insufficient. We do need = to add port zero. This will ensure that a bundle-aware endpoint will not ta= ke the m=3D line out of the bundle. If 3PCC with a non-bundle-aware endpoin= t is likely, the application should create a new PeerConnection instead wit= h an appropriate bundle policy.
<= div>
As noted above I don't think taking an m=3D line out= of the bundle is allowed when a shared port is already in use.=C2=A0
=
_____________
Roman Shpount


On T= ue, Oct 26, 2021 at 1:15 PM Justin Uberti <justin@uberti.name> wrote:
Agree we shou= ld add a reference to 8843-bis. I assume we can do that in the endgame as (= I believe) no text in 8829bis needs to change.

Regarding= 3PCC:
- bundle clients should be able to accept initial offers w= ithout bundle-only. If not, we should fix that in 8843bis, as this seems li= ke an unnecessary limitation - current implementations seem to be managing = this OK.
- the stats on BUNDLE show that it has been widely adopt= ed (99.999% usage when there is more than 1 a/v stream), and these numbers = are only increasing. If "rare" seems overly opinionated, we could= use "uncommon" instead.

Regarding the s= uggested workaround:
- adding a=3Dbundle-only is insufficient, th= e application would also need to insert zero ports for the bundled m=3D lin= es. It's also not clear that this would lead to a good outcome, as the = non-bundle endpoint would only be able to accept the first bundled m=3D lin= e. So I would suggest that if 3PCC with non-bundle-aware endpoints is likel= y, the application should just eat the a=3Dgroup attribute for bundle to pr= event bundling in the first place.


On Tue, Oct 26, 2021= at 10:01 AM Roman Shpount <roman@telurix.com> wrote:
Hi Ted,

I = have mentioned on git that:
1. The reference to RFC 8843bis=C2=A0= is missing

2. The following language is factually = incorrect:

This is by design, but could cause issu= es in the rare case of sending a subsequent offer as an initial offer to a = non-bundle-aware endpoint via Third Party Call Control (3PCC).
Primarily, this will cause issues if a subsequent offer is use= d as an initial even with bundle-aware end points. An offer with no bundle-= only attributes for bundled=C2=A0m=3D lines might=C2=A0not get processed co= rrectly. Second, I would not comment on how frequent=C2=A0this call scenari= o is going to be unless we have to.

My suggested l= anguage=C2=A0was:

This is by design, but could cause issues in case of sending a subsequent= offer as an initial offer due to Third Party Call Control (3PCC). In such = cases, the signaling application is responsible for adding bundle-only attr= ibutes to the offer so that it can be used as an initial offer.

Best Regards,
_____________=
Roman Shpount


On Tue, Oct 26, 2021 at 6:55 AM Ted = Hardie <ted.ietf= @gmail.com> wrote:
This email serve= s as the start of a working group last call for draft-uberti-rtcweb-rfc8829= bis-01.txt.=C2=A0 Because of the upcoming IETF meeting, it will be slightly= longer than normal, ending on November 16, 2021.

Please send comments to= the list.

thanks,

Ted and Sean
_______________________________________________
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
--000000000000c1183405cf81401a-- From nobody Fri Oct 29 11:08:35 2021 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 530863A1532 for ; Fri, 29 Oct 2021 11:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 SvueacjKb0n1 for ; Fri, 29 Oct 2021 11:08:29 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 700973A1530 for ; Fri, 29 Oct 2021 11:08:29 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id i9so9651415qki.3 for ; Fri, 29 Oct 2021 11:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ApNoVeVyd89RwkvJyF7pUtQk+bTJO7mfDBu5vukDBs0=; b=CvOyTs5G+q8uwrrsWPu0H1p909q7i+BO2IKeBJXrHo8xsesrK7wxp/NUsImrySbAxN 5uF7tL69H6kIjlAIwovzKgpEkE8ah9GmEtc9C4SN2qBBEhC/12n4MtmQqxiN2o39LYpy GcjSNGZw55Bf00XhTcdydXIpRC6lYasqyEcaU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ApNoVeVyd89RwkvJyF7pUtQk+bTJO7mfDBu5vukDBs0=; b=AWlBSh86C+LNxdbsSzcEvIvDCKB3NafKqOncXwQaftdyS2ohripdi/c+KyeY519ie0 uhGgySPHH+gxGVeRyMFyRkPda2ZoWh1RWKWIJsK+iPpD+FlFoPHwUvWqYD2yfFuS7lhX df0FTQkxEFZQHAwG/J8871rpxIcyBYsZmNzr7cANNOFKsdOTHo58Avojmb8gVkUoqx6/ DFaXapVckTX1mUygrDldiBaSzxER+HaedhR+ha+dsem6Wm493MP9K+EkH2+QOqeapJpU 8jAc+cG14JbQEDL44XUpi3IPQ2ij6z9ZV3bDlekRcQMzxsGrjb0gl1v250VDzStoPjij UrJw== X-Gm-Message-State: AOAM533PUekFQW/I63hiv4CJFaxauxRBNH/MJSuIyNcuAWzfTmjJGNvS ETbQw11O452QYgStyoH7o4YiMx4ALe1a1Q== X-Google-Smtp-Source: ABdhPJxzTMgwVyNEalHOEsdzj4MJLm9RFa3AodLl3FLqqYZoC+6pEOkN++jmT2YqHdf6T2hV1TVqEQ== X-Received: by 2002:a05:620a:4706:: with SMTP id bs6mr10147321qkb.122.1635530906890; Fri, 29 Oct 2021 11:08:26 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id i22sm4777982qkn.80.2021.10.29.11.08.26 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 11:08:26 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id d10so15392416ybe.3 for ; Fri, 29 Oct 2021 11:08:26 -0700 (PDT) X-Received: by 2002:a25:f205:: with SMTP id i5mr13372357ybe.61.1635530905879; Fri, 29 Oct 2021 11:08:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Fri, 29 Oct 2021 14:08:15 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000aa074405cf81b682" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 29 Oct 2021 18:08:34 -0000 --000000000000aa074405cf81b682 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 29, 2021 at 1:35 PM Justin Uberti wrote: > On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount wrote: > >> Regarding 3PCC, bundle clients should be able to accept the initial offer >> without bundle-only. Unfortunately there is nothing there that prevents >> them from moving an m= line out of the bundle unless it is marked with >> bundle-only. >> > > If it's already bundled, I don't think it can be unbundled, since there is > no other transport to move it to. This is the same situation as in > subsequent o/a exchanges. > It is correct that m= line cannot be unbundled once it is bundled. If this offer is received as a result of 3PCC, there is nothing in the offer that indicates that the m= line cannot be unbundled. Per draft-ietf-mmusic-rfc8843bis section 7.3.2 ( https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-moving-a-media-description- ): - In the corresponding offer, the "m=" section is within a previously negotiated BUNDLE group, and - In the corresponding offer, the "m=" section contains an SDP 'bundle-only' attribute. If either criterion above is fulfilled, the answerer cannot move the "m=" section out of the BUNDLE group in the answer. For subsequent offers processed as initial offers neither of those criteria are true. There are no previously negotiated BUNDLE groups (it is an initial offer). There is no 'bundle-only' attribute. Because of this, even a bundle aware endpoint can move the m= line out. There is no requirement to check that bundled m= lines are using the same address/port. > I was not thinking about the frequency of use of 3PCC with non-bundle >> endpoints (extremely rare) but about the use of 3PCC in general (more >> common and hard to identify). >> >> I agree that a=bundle-only is insufficient. We do need to add port zero. >> This will ensure that a bundle-aware endpoint will not take the m= line out >> of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the >> application should create a new PeerConnection instead with an appropriate >> bundle policy. >> > > As noted above I don't think taking an m= line out of the bundle is > allowed when a shared port is already in use. > As I am trying to explain, there is nothing in the offer that would prevent the compliant implementation from moving the m= line out. This is not obvious but can cause grief. _____________ Roman Shpount --000000000000aa074405cf81b682 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 29, 2021 at 1:35 PM J= ustin Uberti <juberti@alphaexplorationco.com> wrote:
On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount = <roman@telurix.co= m> wrote:
Regarding 3PCC, bundle clients= should be able to accept the initial offer without bundle-only. Unfortunat= ely there is nothing=C2=A0there that prevents them from moving an m=3D line= out of the bundle unless it is marked with bundle-only.
=

If it's already bundled, I don't think it can b= e unbundled, since there is no other transport to move it to. This is the s= ame situation as in subsequent o/a exchanges.=C2=A0

It is correct that m=3D line cannot be unbundled= once it is bundled. If this offer is received as a result of 3PCC, there i= s nothing in the offer that indicates that the m=3D line cannot be unbundle= d. Per=C2=A0draft-ietf-mmusic-rfc8843bis section 7.3.2 (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc88= 43bis-05.html#name-moving-a-media-description- ):

<= div>
    In the corresponding offer, the "m=3D" secti= on is within a previously negotiated BUNDLE group, and
  • I= n the corresponding offer, the "m=3D" section contains an SDP = 9;bundle-only' attribute.
<= div>

If either criterion above is fulfilled, the answerer cannot move the &qu= ot;m=3D" section out of the BUNDLE group in the answer.=C2=A0

For subsequent offers proces= sed as initial offers neither of those criteria are true. There are no prev= iously negotiated BUNDLE groups (it is an initial offer). There is no '= bundle-only' attribute. Because of this, even a bundle aware endpoint c= an move the m=3D line out. There is no requirement to check that bundled m= =3D lines are using the same address/port.
=C2=A0
= I was=C2=A0not thinking about the frequency=C2=A0of use of 3PCC with non-bu= ndle endpoints (extremely rare) but about the use of 3PCC in general (more = common and hard to identify).

I agree that a= =3Dbundle-only=C2=A0is insufficient. We do need to add port zero. This will= ensure that a bundle-aware endpoint will not take the m=3D line out of the= bundle. If 3PCC with a non-bundle-aware endpoint is likely, the applicatio= n should create a new PeerConnection instead with an appropriate bundle pol= icy.

As noted= above I don't think taking an m=3D line out of the bundle is allowed w= hen a shared port is already in use.=C2=A0

As I am trying to explain, there is nothing in the offer = that would prevent=C2=A0the=C2=A0compliant=C2=A0implementation from moving = the=C2=A0m=3D line out. This is not obvious but can cause grief.
_____= ________
Roman Shpount
=C2=A0
--000000000000aa074405cf81b682-- From nobody Fri Oct 29 11:17:01 2021 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 512B43A1552 for ; Fri, 29 Oct 2021 11:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=alphaexplorationco.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 0EbOpO1SwQBp for ; Fri, 29 Oct 2021 11:16:54 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 BDD5B3A1550 for ; Fri, 29 Oct 2021 11:16:54 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id w12-20020a056830410c00b0054e7ceecd88so14780998ott.2 for ; Fri, 29 Oct 2021 11:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KYRyTzhA/yjonSFisDZLxcxOpaEUYHwx5XvFz7bNdEU=; b=Ml0N1DPNXfSlHxOlBGuhvduJhNffb9ymndZ2rRN69QNRR9pHpcPYzxwIp/OSeIpRta vIZ9rzbvteaGsmTYuLta+5FO5cHivcRhKH8c+gkKTL1FdBCWW1Z9ZmODcCx+bAkq6rdp KcjZjJoc5PhVmipKvg1F84WWBdygO5rdrOaXhANW3m/dbSrriDTSLiYfbqC1INIsinj2 B1mO+G63TKXRpZeeIFE0+b8bIW+fNFqfQYpA3lQeByim3kKI1HTxZJh2spQjU2rmjdZM GyK/fd5Vue7Lrh71fvMmmWjMoppk8beBpnA/ojmwHtHJm6pM9pLgVVU6RtxLxX+ZqQrk 0AmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KYRyTzhA/yjonSFisDZLxcxOpaEUYHwx5XvFz7bNdEU=; b=7Nq5VrHyeMxtsJNKxYwSl+0rCn+zdbfTLMkrZiYmJ/8B90dyMsjvxspihqvut/tql0 gJZvMZQ4f+E8LPPQZVtNuhHc/OMoHlYZczog9lGsP/qRr3oSh2oXoZ6PZJZ99/rzt9Du Ceg2Ycp/UCtlaG/fIVpcDJcqfTLkg9CZpP427VjQKBNOH5hOJ3+nKsrC6t4GSdsFf/fN v+fjFJnblDug2Z6Gwe5sRBinf3UZqss2UfRmIXn6Nisk00tK7BFFKCBsV00yzym3vB+2 ZsTXJ0wRQP6sRKAbzoPm8khQUmrVmlwaus9B5/0rbS4/Poa44fiV7b4o2zjcF50qio17 fSQg== X-Gm-Message-State: AOAM530TJo7TZ24gkqZ4cidB6qC2jg95JQJFTAGFXNdB4fvYfJe/BOI7 rDuqAHu6CChbfrvAWYLcZ4BeLQfnmydvC5SIXFwepQ== X-Google-Smtp-Source: ABdhPJxGZ4ekI9hH9Ig102MP+qnbMPKKTvseg2d6jlDBTDne2asKIQv4XlBJTyXHK7KQ5u2J0N/AtmnGlotAVMSJvxc= X-Received: by 2002:a9d:6e16:: with SMTP id e22mr9519256otr.77.1635531411960; Fri, 29 Oct 2021 11:16:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 29 Oct 2021 11:16:41 -0700 Message-ID: To: Roman Shpount Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000d447f305cf81d499" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 29 Oct 2021 18:16:59 -0000 --000000000000d447f305cf81d499 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 29, 2021 at 11:08 AM Roman Shpount wrote: > On Fri, Oct 29, 2021 at 1:35 PM Justin Uberti > wrote: > >> On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount wrote: >> >>> Regarding 3PCC, bundle clients should be able to accept the initial >>> offer without bundle-only. Unfortunately there is nothing there that >>> prevents them from moving an m= line out of the bundle unless it is marked >>> with bundle-only. >>> >> >> If it's already bundled, I don't think it can be unbundled, since there >> is no other transport to move it to. This is the same situation as in >> subsequent o/a exchanges. >> > > It is correct that m= line cannot be unbundled once it is bundled. If this > offer is received as a result of 3PCC, there is nothing in the offer that > indicates that the m= line cannot be unbundled. > Per draft-ietf-mmusic-rfc8843bis section 7.3.2 ( > https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-moving-a-media-description- > ): > > > - In the corresponding offer, the "m=" section is within a previously > negotiated BUNDLE group, and > - In the corresponding offer, the "m=" section contains an SDP > 'bundle-only' attribute. > > If either criterion above is fulfilled, the answerer cannot move the "m=" > section out of the BUNDLE group in the answer. > > For subsequent offers processed as initial offers neither of those > criteria are true. There are no previously negotiated BUNDLE groups (it is > an initial offer). There is no 'bundle-only' attribute. Because of this, > even a bundle aware endpoint can move the m= line out. There is no > requirement to check that bundled m= lines are using the same address/port. > > >> I was not thinking about the frequency of use of 3PCC with non-bundle >>> endpoints (extremely rare) but about the use of 3PCC in general (more >>> common and hard to identify). >>> >>> I agree that a=bundle-only is insufficient. We do need to add port zero. >>> This will ensure that a bundle-aware endpoint will not take the m= line out >>> of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the >>> application should create a new PeerConnection instead with an appropriate >>> bundle policy. >>> >> >> As noted above I don't think taking an m= line out of the bundle is >> allowed when a shared port is already in use. >> > > As I am trying to explain, there is nothing in the offer that would > prevent the compliant implementation from moving the m= line out. This is > not obvious but can cause grief. > The problem is that it is not possible, as there is no other transport to move the unbundled line to. As noted in the section you cite: "NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section cannot be moved out of the BUNDLE group in an answer. Instead, an offer is needed.:" Generally, I think that if there is a shared address, that signifies that a BUNDLE group has already been negotiated, even if that decision was made elsewhere. Perhaps a note should be added to bundle-bis to explicitly state this. --000000000000d447f305cf81d499 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 29, 2021 at 11:08 AM Roma= n Shpount <roman@telurix.com>= ; wrote:
On Fri, Oct 29, 2021 at 1:= 35 PM Justin Uberti <juberti@alphaexplo= rationco.com> wrote:
On Tue, Oct 26, 2021 at 3:06 PM Roman Shpount <roman@telurix.com> wrote:=
Regarding 3PCC, bundle clients should be able = to accept the initial offer without bundle-only. Unfortunately there is not= hing=C2=A0there that prevents them from moving an m=3D line out of the bund= le unless it is marked with bundle-only.

<= div>If it's already bundled, I don't think it can be unbundled, sin= ce there is no other transport to move it to. This is the same situation as= in subsequent o/a exchanges.=C2=A0

=
It is correct that m=3D line cannot be unbundled once it is bund= led. If this offer is received as a result of 3PCC, there is nothing in the= offer that indicates that the m=3D line cannot be unbundled. Per=C2=A0draf= t-ietf-mmusic-rfc8843bis section 7.3.2 (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc= 8843bis-05.html#name-moving-a-media-description- ):

    • In the corresponding offer, the "m=3D" section is within a pr= eviously negotiated BUNDLE group, and
    • In the corresp= onding offer, the "m=3D" section contains an SDP 'bundle-only= ' attribute.

If either criterion above is fulfilled, the answerer c= annot move the "m=3D" section out of the BUNDLE group in the answ= er.=C2=A0

For subseq= uent offers processed as initial offers neither of those criteria are true.= There are no previously negotiated BUNDLE groups (it is an initial offer).= There is no 'bundle-only' attribute. Because of this, even a bundl= e aware endpoint can move the m=3D line out. There is no requirement to che= ck that bundled m=3D lines are using the same address/port.
=C2=A0
I was=C2=A0not thinking about the frequency=C2=A0of use of= 3PCC with non-bundle endpoints (extremely rare) but about the use of 3PCC = in general (more common and hard to identify).

I agree that a=3Dbundle-only=C2=A0is insufficient. We do need to add port = zero. This will ensure that a bundle-aware endpoint will not take the m=3D = line out of the bundle. If 3PCC with a non-bundle-aware endpoint is likely,= the application should create a new PeerConnection instead with an appropr= iate bundle policy.

As noted above I don't think taking an m=3D line out of the bund= le is allowed when a shared port is already in use.=C2=A0
=

As I am trying to explain, there is nothin= g in the offer that would prevent=C2=A0the=C2=A0compliant=C2=A0implementati= on from moving the=C2=A0m=3D line out. This is not obvious but can cause gr= ief.

The problem is that = it is not possible, as there is no other transport to move the unbundled li= ne to. As noted in the section you cite:

=C2=A0"NOTE: One consequence of the ru= les above is that, once a BUNDLE group has been negotiated, a bundled "= ;m=3D" section cannot be moved out of the BUNDLE group in an answer. I= nstead, an offer is needed.:"
Generally, I think that if there is a shared address, t= hat signifies that a BUNDLE group has already been negotiated, even if that= decision was made elsewhere. Perhaps a note should be added to bundle-bis = to explicitly state this.
--000000000000d447f305cf81d499-- From nobody Fri Oct 29 15:30:04 2021 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 575713A1960 for ; Fri, 29 Oct 2021 15:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 d-n4oP3FxXSL for ; Fri, 29 Oct 2021 15:29:57 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 86F763A194D for ; Fri, 29 Oct 2021 15:29:57 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id bk22so4128916qkb.6 for ; Fri, 29 Oct 2021 15:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o7TLsMblA2y6XpKjjgYT0cM+3AtLVnXTuI87aUwOKlw=; b=JVHJ2tBArU4clc18A9OoZD+MMeEOTpfTwCk27hE5TGH+9nyijrf7vzCOhBHAL6PQUM ErjJmfT9Bi2QUaPzHeut3Mo3JpLqQe7cQTC4WfAPde/eeTtkPtdTbYlpiXF1m521tSvw lTnMdTvSqsBoBRlV7WNgRT6/Dlt0Gpd1Y4bck= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o7TLsMblA2y6XpKjjgYT0cM+3AtLVnXTuI87aUwOKlw=; b=WmQho78NPm3IsB1/Bt3MQpUNEHJolQb+LLFV3sd5cTppUOo4a8F5siuZbIlTFHWJzz Asc2Zh/GMD/Ha4k5xI+j+yWqfwK6kfs+BMRZPzWitOwJ6E/7zT0NsRPDNf5CjTR9NVOp F1rrwzvXwI0N5/SM77aBnhhFGGvs9oVpW0qiW3xNWZaEcyc+k4fQTOWQsgd/liabMcy0 69iBDTig9USRRwHn9A0BYE70/AQB0CTGNoq6lqK64fP7F7WgbZfVufl2VIsY995/4lVG lL8uE5hDmkD1W1JWKgD1lIleIUUmDNlmkKiM3MxpOPAW9mtg0SUGmTcciTHShRDoHtFU oMOQ== X-Gm-Message-State: AOAM530Rd9KkzKQDNiVTiSNbmYItJ1HLRHk056ayprMdkcrlujhajr0y d2aEotfF511GhJu+hkhypHkzaq4FohgSIw== X-Google-Smtp-Source: ABdhPJxmU8DsJ18/+wyM9nmj7VjH9IGiU5C2p3kqiFSWhiPFEHUv1QVAvsmAYpkwaQ8nDmoY1l1byQ== X-Received: by 2002:a37:f902:: with SMTP id l2mr11126538qkj.511.1635546593602; Fri, 29 Oct 2021 15:29:53 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com. [209.85.219.175]) by smtp.gmail.com with ESMTPSA id t11sm4727519qkm.92.2021.10.29.15.29.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 15:29:52 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id j75so53312ybj.6 for ; Fri, 29 Oct 2021 15:29:52 -0700 (PDT) X-Received: by 2002:a5b:482:: with SMTP id n2mr14098801ybp.514.1635546591926; Fri, 29 Oct 2021 15:29:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Fri, 29 Oct 2021 18:29:41 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000a01e6405cf855da7" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 29 Oct 2021 22:30:03 -0000 --000000000000a01e6405cf855da7 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti < juberti@alphaexplorationco.com> wrote: > >> As I am trying to explain, there is nothing in the offer that would >> prevent the compliant implementation from moving the m= line out. This is >> not obvious but can cause grief. >> > > The problem is that it is not possible, as there is no other transport to > move the unbundled line to. As noted in the section you cite: > > "NOTE: One consequence of the rules above is that, once a BUNDLE group > has been negotiated, a bundled "m=" section cannot be moved out of the > BUNDLE group in an answer. Instead, an offer is needed.:" > > Generally, I think that if there is a shared address, that signifies that > a BUNDLE group has already been negotiated, even if that decision was made > elsewhere. Perhaps a note should be added to bundle-bis to explicitly state > this. > When discussing bundle-bis the understanding was that it is generally known when an offer is generated for 3pcc. Because of this, it was decided that when the offer is generated for 3pcc it should be generated using the same rules as the initial offer (i.e. with port zero and bundle-only). This was considered to be both backwards compatible with RBF 8843 and safe to use as an initial offer for non-bundle aware, bundle, and bundle-bis endpoints. For whatever reason, inspecting transport addresses was not considered a valid mechanism to detect that m= lines are already bundled and cannot be unbundled in the future. If we want to switch to inspecting transport addresses when deciding which m= lines can be unbundled, this deserves a lot more than a note in bundle-bis. I would still argue that a safe way to generate an offer for 3PCC is to do SDP manipulation and set ports to 0 with attribute bundle-only. Everything else would not be compatible with either bundle-bis or RFC 8843. _____________ Roman Shpount --000000000000a01e6405cf855da7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 29, 2021 at 2:16 PM J= ustin Uberti <juberti@= alphaexplorationco.com> wrote:

As I a= m trying to explain, there is nothing in the offer that would prevent=C2=A0= the=C2=A0compliant=C2=A0implementation from moving the=C2=A0m=3D line out. = This is not obvious but can cause grief.

The problem is that it is not possible, as there is no othe= r transport to move the unbundled line to. As noted in the section you cite= :

=C2=A0&= quot;NOTE: One consequence of the rules above is that, once a BUNDLE group = has been negotiated, a bundled "m=3D" section cannot be moved out= of the BUNDLE group in an answer. Instead, an offer is needed.:"

Generally, I think = that if there is a shared address, that signifies that a BUNDLE group has a= lready been negotiated, even if that decision was made elsewhere. Perhaps a= note should be added to bundle-bis to explicitly state this.

When discussing bundle-bis the und= erstanding=C2=A0was that it is generally known when an offer is generated f= or 3pcc. Because of this, it was decided that when the offer is generated f= or 3pcc it should be generated using the same rules as the initial offer (i= .e. with port zero and bundle-only). This was considered to be both backwar= ds compatible with RBF 8843 and safe to use as an initial offer for non-bun= dle=C2=A0aware, bundle, and bundle-bis endpoints. For whatever reason, insp= ecting transport addresses was not considered a valid mechanism to detect t= hat m=3D lines are already bundled and cannot be unbundled in the future. I= f we want to switch to inspecting transport addresses when deciding which m= =3D lines can be unbundled, this deserves a lot more than a note in bundle-= bis.

I would still argue that a safe way to genera= te an offer for 3PCC is to do SDP manipulation and set ports to 0 with attr= ibute bundle-only. Everything else would not be compatible with either bund= le-bis or RFC 8843.
_____________
Roman Shpount
=C2=A0
--000000000000a01e6405cf855da7-- From nobody Fri Oct 29 15:49:10 2021 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 D8CC13A1986 for ; Fri, 29 Oct 2021 15:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=alphaexplorationco.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 Fmn4d210bcwZ for ; Fri, 29 Oct 2021 15:49:03 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 2FD323A1983 for ; Fri, 29 Oct 2021 15:49:03 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id t17-20020a056830083100b00553ced10177so15423442ots.1 for ; Fri, 29 Oct 2021 15:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HBW2KtnGL9y3A2htV6AaqttVemkHUGxyD8aIWzf699M=; b=fYIxsS/tpD47hvYiqfifjsay8W1AJz+J7p+/mUU2fl7xganFn5c5YipS/k/XUfM23V srb+HeLnqFO0NREi4DZOwsvBNdZabXi+PJcBFcHlIprVWkic4Bq4qqQXwqQm5eh1wNUS yYcNt7ev8GMpxBjfUwiCwR6/hOdiJX/A7hOMbuOiLoBTE5rh/Sp6Jf5ZNM3bxgBjx4Og lcxm2z9Vg3y1NzugLcELCMDz06f+ryycJbyj60Q6hT1YZ6ah9cu0WrJtRe2UTK66e47D 3vl4jl+LdynrzRNKCJFxVWlD10Q8zEKudCxbLddcshY6a3I01h4X7kSo77XwCii5g+Yw 8s4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HBW2KtnGL9y3A2htV6AaqttVemkHUGxyD8aIWzf699M=; b=vs1GGYcq9YGJcJOZHT4jbiD5+lPzFCr+CWKlRXVaCMhTxAil3lTKR+ODyu2ByUK7gv ncaI9ciHQ4AjDoPsLeHpNpq3t+vIpqFX4iBgRNfA27W9kESNOHLDIiLhgIycmAVSAVw6 YQCzuM8Po+QNpUji+a1N89qcAdbxbD8VeXuWrB60PVAxPesF+1sbdMs0JYH7JsPBKzO0 flhvVSFRnGCbCEmD7O60zrfM8mr5o9I/VW/+tygnbXp6+3EBDkLM/WvZPXxjwfdPPq0X nV+GdppFZjqAGm/Pp0oGkIdQi51tA8LTxPm3HL+kjMtcmyw5K58XxnyypkrTI/uJTbfx bhjw== X-Gm-Message-State: AOAM5332Umx4oQ7gncv3Q26AIlSn2UO9mkxlTDLHwQMED26dK+sV6wFj JbEQ/xr8uU/tURu9011t3N62fi2JJiuQBNrg9t5sUg== X-Google-Smtp-Source: ABdhPJzye+AOGiPIlg9FIc1RQA4D0mKaRpXkvKjTSq6rs5LhgRLJwkyYYfG1dn7N1NWY1ageCvtDvXkSnEmdO4QlaXk= X-Received: by 2002:a9d:6e16:: with SMTP id e22mr10433500otr.77.1635547740221; Fri, 29 Oct 2021 15:49:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Fri, 29 Oct 2021 15:48:49 -0700 Message-ID: To: Roman Shpount Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000011c67405cf85a2e8" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 29 Oct 2021 22:49:09 -0000 --00000000000011c67405cf85a2e8 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount wrote: > On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > >> >>> As I am trying to explain, there is nothing in the offer that would >>> prevent the compliant implementation from moving the m= line out. This is >>> not obvious but can cause grief. >>> >> >> The problem is that it is not possible, as there is no other transport to >> move the unbundled line to. As noted in the section you cite: >> >> "NOTE: One consequence of the rules above is that, once a BUNDLE group >> has been negotiated, a bundled "m=" section cannot be moved out of the >> BUNDLE group in an answer. Instead, an offer is needed.:" >> >> Generally, I think that if there is a shared address, that signifies that >> a BUNDLE group has already been negotiated, even if that decision was made >> elsewhere. Perhaps a note should be added to bundle-bis to explicitly state >> this. >> > > When discussing bundle-bis the understanding was that it is generally > known when an offer is generated for 3pcc. Because of this, it was decided > that when the offer is generated for 3pcc it should be generated using the > same rules as the initial offer (i.e. with port zero and bundle-only). This > was considered to be both backwards compatible with RBF 8843 and safe to > use as an initial offer for non-bundle aware, bundle, and bundle-bis > endpoints. For whatever reason, inspecting transport addresses was not > considered a valid mechanism to detect that m= lines are already bundled > and cannot be unbundled in the future. If we want to switch to inspecting > transport addresses when deciding which m= lines can be unbundled, this > deserves a lot more than a note in bundle-bis. > This logic needs to be applied on subsequent offers already though, so I don't understand why asking endpoints to also consider it on initial offers is an issue. Perhaps Christer could weigh in here. > > I would still argue that a safe way to generate an offer for 3PCC is to do > SDP manipulation and set ports to 0 with attribute bundle-only. Everything > else would not be compatible with either bundle-bis or RFC 8843. > I am fine to include this as a consideration for non-BUNDLE endpoints but it seems error-prone and unnecessary to do this for BUNDLE-aware endpoints. --00000000000011c67405cf85a2e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Oct 29, 2021 at 3:29 PM Roman= Shpount <roman@telurix.com>= wrote:
On Fri, Oct 29, 2021 at 2:1= 6 PM Justin Uberti <juberti@alphaexplorationco.com> wrote:
<= div>
As I am trying to explain, there is nothing in the offer= that would prevent=C2=A0the=C2=A0compliant=C2=A0implementation from moving= the=C2=A0m=3D line out. This is not obvious but can cause grief.

The problem is that it is not poss= ible, as there is no other transport to move the unbundled line to. As note= d in the section you cite:

=C2=A0"NOTE: One consequence of the rules above is t= hat, once a BUNDLE group has been negotiated, a bundled "m=3D" se= ction cannot be moved out of the BUNDLE group in an answer. Instead, an off= er is needed.:"

Generally, I think that if there is a shared address, that signifies = that a BUNDLE group has already been negotiated, even if that decision was = made elsewhere. Perhaps a note should be added to bundle-bis to explicitly = state this.

When disc= ussing bundle-bis the understanding=C2=A0was that it is generally known whe= n an offer is generated for 3pcc. Because of this, it was decided that when= the offer is generated for 3pcc it should be generated using the same rule= s as the initial offer (i.e. with port zero and bundle-only). This was cons= idered to be both backwards compatible with RBF 8843 and safe to use as an = initial offer for non-bundle=C2=A0aware, bundle, and bundle-bis endpoints. = For whatever reason, inspecting transport addresses was not considered a va= lid mechanism to detect that m=3D lines are already bundled and cannot be u= nbundled in the future. If we want to switch to inspecting transport addres= ses when deciding which m=3D lines can be unbundled, this deserves a lot mo= re than a note in bundle-bis.

=
This logic needs to be applied on subsequent offers already though, so= I don't understand why asking endpoints to also consider it on initial= offers is an issue. Perhaps Christer could weigh in here.=C2=A0

I would still argue that a safe way to ge= nerate an offer for 3PCC is to do SDP manipulation and set ports to 0 with = attribute bundle-only. Everything else would not be compatible with either = bundle-bis or RFC 8843.
=C2= =A0
I am fine to include this as a consideration for non-BUNDLE e= ndpoints but it seems error-prone and unnecessary to do this for BUNDLE-awa= re endpoints.=C2=A0
--00000000000011c67405cf85a2e8-- From nobody Fri Oct 29 19:27:32 2021 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 BD3353A1A89 for ; Fri, 29 Oct 2021 19:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 AjVxZ5ExNOLO for ; Fri, 29 Oct 2021 19:27:24 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 A10C63A1A88 for ; Fri, 29 Oct 2021 19:27:24 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id az8so59982qkb.2 for ; Fri, 29 Oct 2021 19:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mn73xvea1nucTr4XSXtQnCVjXeYD7AEAZ43cj2wrswg=; b=OOTq0jsJbEV+iHe1Zn77aONy/85b4BSvizCBTsuBegqu7KvNJzzZ322v6yjcTZjWE7 10kFtpLIrS28SrH8OuQH5ZkJYL7ahGzYmim8V3S+72DVkVzjpu+6GyfIC+HES29sRu4I Hdbpuy9iB8FOxv/PFjwZf5ivKJsxCD4hht/ZM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mn73xvea1nucTr4XSXtQnCVjXeYD7AEAZ43cj2wrswg=; b=utVRZZ666dXTj7RjMePJoGlps9ggDKM/n34AKS6iXDAwOGzBQYGBNcKEWKBLsb/G0b 14JFSjrizeN34qb5kBzPikf5cExV5W9/1pmPOeKzET5R7Vo40JnkMTMz7OTppPJGIXqu IhlVa7viB8TLa7oGNcM3gLdOwubJV21QPt9b+f1OLS3NiKvQ7wIEEEpSQt91vGvoBf7V VyKZcd2lWGpyjc+JjZmNHyfqXIIxxfkemya7P1WM4G07+aYcPWVKe5EvAP+HgpBMetdw 8iJArSV4HOdJ/UzBxyGSTNy2a6G2T1+AhQrp4uWEbfmr2SBTK3GMqEhVNRQSE9Y0bC8P csJQ== X-Gm-Message-State: AOAM532M6MGmJ9IbE6UTMJ8fp1Cio4Q9U7hXzGGzl4KkoTEyS56T6sR7 QXJ5M6Rexz3rZXyt1kPExOR3+WXczDRqvg== X-Google-Smtp-Source: ABdhPJwscp0ietTXnRU79h9D/nBke2u7PlU9iXf8maeRcmDJCE7RGE+AjFpweJVzDCo00DA5s5kKqA== X-Received: by 2002:a05:620a:28ce:: with SMTP id l14mr12108960qkp.85.1635560842389; Fri, 29 Oct 2021 19:27:22 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com. [209.85.219.173]) by smtp.gmail.com with ESMTPSA id v22sm4500946qta.74.2021.10.29.19.27.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 19:27:21 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id t127so28742013ybf.13 for ; Fri, 29 Oct 2021 19:27:21 -0700 (PDT) X-Received: by 2002:a25:5846:: with SMTP id m67mr15465117ybb.231.1635560840714; Fri, 29 Oct 2021 19:27:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Fri, 29 Oct 2021 22:27:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000eb605605cf88ae02" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 30 Oct 2021 02:27:30 -0000 --000000000000eb605605cf88ae02 Content-Type: text/plain; charset="UTF-8" On Fri, Oct 29, 2021 at 6:49 PM Justin Uberti < juberti@alphaexplorationco.com> wrote: > > > On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount wrote: > >> On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti < >> juberti@alphaexplorationco.com> wrote: >> >>> >>>> As I am trying to explain, there is nothing in the offer that would >>>> prevent the compliant implementation from moving the m= line out. This is >>>> not obvious but can cause grief. >>>> >>> >>> The problem is that it is not possible, as there is no other transport >>> to move the unbundled line to. As noted in the section you cite: >>> >>> "NOTE: One consequence of the rules above is that, once a BUNDLE group >>> has been negotiated, a bundled "m=" section cannot be moved out of the >>> BUNDLE group in an answer. Instead, an offer is needed.:" >>> >>> Generally, I think that if there is a shared address, that signifies >>> that a BUNDLE group has already been negotiated, even if that decision was >>> made elsewhere. Perhaps a note should be added to bundle-bis to explicitly >>> state this. >>> >> >> When discussing bundle-bis the understanding was that it is generally >> known when an offer is generated for 3pcc. Because of this, it was decided >> that when the offer is generated for 3pcc it should be generated using the >> same rules as the initial offer (i.e. with port zero and bundle-only). This >> was considered to be both backwards compatible with RBF 8843 and safe to >> use as an initial offer for non-bundle aware, bundle, and bundle-bis >> endpoints. For whatever reason, inspecting transport addresses was not >> considered a valid mechanism to detect that m= lines are already bundled >> and cannot be unbundled in the future. If we want to switch to inspecting >> transport addresses when deciding which m= lines can be unbundled, this >> deserves a lot more than a note in bundle-bis. >> > > This logic needs to be applied on subsequent offers already though, so I > don't understand why asking endpoints to also consider it on initial offers > is an issue. Perhaps Christer could weigh in here. > During the initial offer end point does not have already negotiated bundle groups. Once the endpoint has already negotiated bundle groups, m= lines cannot be removed from them. > I would still argue that a safe way to generate an offer for 3PCC is to do >> SDP manipulation and set ports to 0 with attribute bundle-only. Everything >> else would not be compatible with either bundle-bis or RFC 8843. >> > > I am fine to include this as a consideration for non-BUNDLE endpoints but > it seems error-prone and unnecessary to do this for BUNDLE-aware endpoints. > Your logic only works if bundle-aware endpoints were not allowed to remove m= lines from a bundle group. Looking at the addresses to determine what is already grouped is insufficient, since an offer can also be an offer with ice restart and trickle. No addresses will be present, so the endpoint will have to look at ice parameters as well. This gets complicated and no one wanted to describe this when 8843bis was written. This is why rfc 8843bis specifies that subsequent offers for 3PCC should be valid initial offers. There are, potentially, two solutions to this: 1. Change bundle so that endpoints are required to inspect initial offers for transport addresses and ice parameters. Do not allow m= lines to be removed from the bundle group if they share the transport address. This would require pulling RFC 8843bis and writing the appropriate language. 2. Change JSEP note to specify that the application needs to make sure that in case of 3PCC and remote endpoints either potentially removing m= lines from the bundle or not being bundle-aware, bundled m= lines need to be modified to have port 0 and bundle-only attribute. Considering that most bundle-aware endpoints do not remove m= lines from the bundle, this option would cause the least amount of specification work. 3. If we want to completely avoid applications messing with SDP, change JSEP to specify that when ice-restart is specified and a new offer is generated, already bundled m= lines should be marked with port 0 and bundle-only. This would also result in the least number of surprises for developers. Best Regards, _____________ Roman Shpount --000000000000eb605605cf88ae02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Oct 29, 2021 at 6:49 PM J= ustin Uberti <juberti@= alphaexplorationco.com> wrote:


On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <<= a href=3D"mailto:roman@telurix.com" target=3D"_blank">roman@telurix.com= > wrote:
On Fri, Oct 29, 2021 at= 2:16 PM Justin Uberti <juberti@alphaexplorationco.com> wrote:
=

As I am trying to explain, there is nothing in the of= fer that would prevent=C2=A0the=C2=A0compliant=C2=A0implementation from mov= ing the=C2=A0m=3D line out. This is not obvious but can cause grief.
<= /div>

The problem is that it is not p= ossible, as there is no other transport to move the unbundled line to. As n= oted in the section you cite:

<= div>=C2=A0"NOTE: One consequence of the rules above i= s that, once a BUNDLE group has been negotiated, a bundled "m=3D"= section cannot be moved out of the BUNDLE group in an answer. Instead, an = offer is needed.:"

Generally, I think that if there is a shared address, that signifi= es that a BUNDLE group has already been negotiated, even if that decision w= as made elsewhere. Perhaps a note should be added to bundle-bis to explicit= ly state this.

When d= iscussing bundle-bis the understanding=C2=A0was that it is generally known = when an offer is generated for 3pcc. Because of this, it was decided that w= hen the offer is generated for 3pcc it should be generated using the same r= ules as the initial offer (i.e. with port zero and bundle-only). This was c= onsidered to be both backwards compatible with RBF 8843 and safe to use as = an initial offer for non-bundle=C2=A0aware, bundle, and bundle-bis endpoint= s. For whatever reason, inspecting transport addresses was not considered a= valid mechanism to detect that m=3D lines are already bundled and cannot b= e unbundled in the future. If we want to switch to inspecting transport add= resses when deciding which m=3D lines can be unbundled, this deserves a lot= more than a note in bundle-bis.

This logic needs to be applied on subsequent offers already though,= so I don't understand why asking endpoints to also consider it on init= ial offers is an issue. Perhaps Christer could weigh in here.=C2=A0

During the initial offer end poi= nt does not have already negotiated bundle groups. Once the endpoint has al= ready negotiated bundle groups, m=3D lines cannot be removed from them.
=C2=A0
I would still= argue that a safe way to generate an offer for 3PCC is to do SDP manipulat= ion and set ports to 0 with attribute bundle-only. Everything else would no= t be compatible with either bundle-bis or RFC 8843.
=C2=A0
I am fine to include this as a = consideration for non-BUNDLE endpoints but it seems error-prone and unneces= sary to do this for BUNDLE-aware endpoints.=C2=A0

Your logic only works if bundle-aware endpoints we= re not allowed to remove m=3D lines from a bundle group. Looking at the add= resses to determine what is already grouped is insufficient, since an offer= can also be an offer with ice restart and trickle. No addresses will be pr= esent, so the endpoint will have to look at ice parameters as well. This ge= ts complicated and no one wanted to describe this when 8843bis=C2=A0was wri= tten.=C2=A0 This is why rfc 8843bis=C2=A0specifies that subsequent offers for 3PCC shou= ld be valid initial offers.

There are, potentially, two solutions to this:

1. Change bundle so that endpoints are required to i= nspect initial=C2=A0offers for transport addresses and ice parameters. Do n= ot allow m=3D lines to be removed from the bundle group if they share the t= ransport address. This would require pulling RFC 8843bis and writing the ap= propriate language.

2. Change JSEP note to specify= that the application needs to make sure that in case of 3PCC and remote en= dpoints either potentially removing m=3D lines from the bundle or not being= bundle-aware, bundled m=3D lines need to be modified to have port 0 and bu= ndle-only attribute. Considering that most bundle-aware endpoints do not re= move m=3D lines from the bundle, this option would cause the least amount o= f specification work.

3. If we want to completely = avoid applications messing with SDP, change JSEP to specify that when ice-r= estart is specified and a new offer is generated, already bundled m=3D line= s should be marked with port 0 and bundle-only. This would also result in t= he least number of surprises for developers.

Best = Regards,
_____________
Roman Shpount
=C2=A0
--000000000000eb605605cf88ae02-- From nobody Sat Oct 30 15:44:46 2021 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 BDB4A3A142C for ; Sat, 30 Oct 2021 15:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiuD_iSNfsTv for ; Sat, 30 Oct 2021 15:44:37 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40050.outbound.protection.outlook.com [40.107.4.50]) (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 A3EB33A142B for ; Sat, 30 Oct 2021 15:44:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RrYTQtckHRaaogWDsuqAoaMGhJQWzn+LZdW57IOtaMo/FTnzM7ybv648IlnC+mgdkuGhrm9EH+xz51gfvAY2CMtGhTB0M9ET1Q70dCh5QrcPTA56GUBVuXGZb+T19A7Y8Wcq/KD/jeg3u8xMEXRYzicnrONVwghRZhzcobRrE+an24KIAq4VcAz4h1oA44VPzc2PrvKHSe6F+Z6jhEH6PMXCAYbfvCKeAQb/Pm9oeNQnZr8YrgoYriV1kJ0wqvZi5pg0kSz7GLfF5yQoov3W/s9rWckVF8pIrRDyznD8iIlIBp3rryJkSvvE9+LOdad8P6jM9D+FLDtABZq1D0BPeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=f62nL5UMrphkyzGB351yfZJ5OL/rr4bdYNY+fqL0X0I=; b=nH8AKHtHts5Y6ynRm0TssfF9U2HZt/IXTTh8h6VtWve2rDTn0QKiO1gwr/le+bxO0gL7RgkQ/bhDTm42TT1KCvJhdCGFXbufoLZIzrzhP9vK+vXsk9hNCdHgYLB8YC3FMEMWxBINw5GnKvhwxJCD+CU7eVzoxu0jTe33ZTTw7bPz98p2b62YDnvx/RBxryLL8rZrL8zl8pZXr2ZwOZLFzsBpQaQBAzcbulvNu1CLsn1cWyKXBWJKTTRbyESiyZHwq2rH76IobuvgZJCd/hkY5taeLLInGjyqTpFwL1KYHwvzpN+uRqZ5UQoPvEHF+PfVMnFqT+yLxwUYX+VvnWnXMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f62nL5UMrphkyzGB351yfZJ5OL/rr4bdYNY+fqL0X0I=; b=R8/1xefyvXfQ/qoKU2ptRfDCPuhFkRg/+rGi/dyHHlU6iHH7Y/B2pR+Wq/e3ma1INkLxNvVHN+YWSQbPriF2KJz9I65yMNO4dNsF3uymU8q5B4+c6K3oREaSjf/ujsFo4iHNa2jmjx4O4d9xqu+Ove8J/pHn3HOXv836zUsr7iU= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR0701MB3036.eurprd07.prod.outlook.com (2603:10a6:3:52::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.4; Sat, 30 Oct 2021 22:44:32 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.008; Sat, 30 Oct 2021 22:44:32 +0000 From: Christer Holmberg To: Roman Shpount , Justin Uberti CC: Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQ Date: Sat, 30 Oct 2021 22:44:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c0573cb8-876b-42d0-ff2b-08d99bf6d74e x-ms-traffictypediagnostic: HE1PR0701MB3036: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Sywlv7JF1vx4Ql5RqwMv7iTLKUvL9QwCC3y9hknzGYztrw6ArAitoju+WGNigzAxynvGWSt7J7HpHog5jTv3y4ZUBLPD65bTMzyqeOxAYhuIgrJvrvGpgALuLtYJZxH10RsC6SNhpiCKvaDCxSfLG8r9CoZjMnMgbnWx8/TGVJHT1BoBxpyLDkiNSBgPuNesxitIsomR/udvyAbyIdGFsO96QZnWLLjvw9uG5BGp7po/sg4TMH5f2lw9H+iHD7zRKYaohtdyu4ajfWxsiA1Ue+I81zeL0lgEVTIEAE+M3mK3cD7bUlw19SyZsd8Sk8gbERB6wO6VnKUodeXeSs/8ENQEtZMbBoo1mZgNhyhPJ1xXxTpRJo5DPUVR2wm3AMs75DpzeHVEl1GuKPVY83pzIO6FppcDAM8DRA7dbXOBSNp1+qaPavSKQcBEcEfcPbJ094VAVAbUc3ldWUvk9vwbGayjiCQfqCQeM4opOwd/RYmWP57QzTun/SOcU13WVF2OHdrMmTlOovEAXWzQ7HQINVYMqzMt85G/p+KbbfK8GWALBJzGUvuqVIdHZr2l4rj/WPfQPpzoGd/slryOfKa8E3Fc3qGoaS5epba+PgS1vo3kvZzQc+gonS8WprtP1ULBvr1z0ASr17AcpFSUqJY35FMCIhYfQLF8CO5wS04mhEJHtJnNYJSQLCEgZY6JSxqkEGSApJC20KGsj/77hLDPPw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(86362001)(44832011)(33656002)(9686003)(52536014)(55016002)(110136005)(38070700005)(82960400001)(54906003)(508600001)(83380400001)(316002)(71200400001)(4326008)(26005)(8936002)(122000001)(66946007)(2906002)(8676002)(53546011)(6506007)(186003)(38100700002)(76116006)(7696005)(66446008)(66476007)(64756008)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?U1JQWGpxdzNUOUxuVGxnMHhHaUp4SXloOWtDL2tLMzI1eWowbUJLYUxnRlFM?= =?utf-8?B?SUhGSjlISVM2bUdlSEwvSm9WdTBTTTFXQXRyWEVSVGhVWTZEMW1ZQ2hvcUNz?= =?utf-8?B?aVdtM3hBdkFBQ01wKzlKa2VCTEt3ZE5sc200Q1JIOGtSVi9tZVk0bWVzTWJ0?= =?utf-8?B?SG1OVjduaDR0MldnRTFibnQ2T2dOQXpxRGM2czFuSThhcFJMbTdHVDE5c2V3?= =?utf-8?B?bDM1ZEZ0cjZnYXhndVYyOUhNcGFVQ1lsZC96eWx0NUk0cXRiencyR2d4dU91?= =?utf-8?B?Ri80QWJiclM0OXl2cjBQaXpOWVJFaWU1L3MwaUhjUE4rUEhnTDhtZXdhdEg5?= =?utf-8?B?RGRKZ3Q5b2N0M2QvVC82QTd5bEdJVVdpSVVjL1ZLTHFIT0l6UDdhRFFHYklP?= =?utf-8?B?TWNQZXZzY3VNdU9IcysvV0I4NFYvUTFnNEdpTXE4Q1pab0lLTnFxb2lTYW0z?= =?utf-8?B?bWlmSUFxRzBnd3YrdG9iaE0zUTUxYjMzZ01ZZWNIbTRlcU0zb3VRY0x2ak9H?= =?utf-8?B?ZWhPWmw4d0htVzJyV21LcHR2RFhQcUxzUVkxc09lTXh3TzVkaTY1ajRUZzNX?= =?utf-8?B?RnRFTWVaS2FFZkZGYm01UFFORnd3cGY1RkthNmxMWms2L3JJNUZ6eEc0Z3Fz?= =?utf-8?B?SDdUQlkwMzNhOUV6T2J6MnlHNnp3SFR6SElWUWs5Um9EdGVheWJIWlNGRktw?= =?utf-8?B?UVBzMlRZT0ZDdUZvMkNCajA2VjRoK2N2c1lPQmtPbUVTSzBaZ2dtT3JSUEtS?= =?utf-8?B?U240b3NEWGNhUm96bjhOWHJycXA3SCtDRTNibU1WdUVqcjhTZXB3bWNHcG1J?= =?utf-8?B?ZzQ0cytQRStEbXN0TlJqaHJHZURuKzRzTFlyZTFNKzJrSC9hcmNDcDZ6WEkz?= =?utf-8?B?R0x1c2phNStTUnhJQ2FKU0YzZm5hdEJjeHNOZnhHMnlLK2N5UXRNZElNbmww?= =?utf-8?B?cW5pM1Q2SUt5TEs5aDFVUlZSWGc5UGx5WUtSR0MzODNzTGJIUXdlT1NTZE91?= =?utf-8?B?dFhIMlN2Rmk4QzMwZGZUQkJwYlJvN1RsaHY0TkRNaGVSd2djS2ZJMlRhNkV6?= =?utf-8?B?U0VGaDFSa2F6akQvQ0ZoZjlzUDR2a2ZxdmdXMGdlNjRReTN6Tjd4d3N2ck9k?= =?utf-8?B?RVFvWTRVVVFXMkRVUFNEakdEczRsTUJKcTc5QVBnZEE1dUlvdUJIbEdtaDNG?= =?utf-8?B?bndZMnk1TDhPQ2hxZXBkbGo1TXRTMDV2aHFDMmRIckkybGFBUWtKSlBrM1RE?= =?utf-8?B?R3hROVliZkNqcHd6YllnYXRQWU9sSlJvTGVjL0pOVDNyb3NTd0xRVFlENW5U?= =?utf-8?B?WkNxZW9hT0JXcjMyUXcvZkh2N1pjTlFFVStZdkwyVU8wcXltRDIwUS9weGRi?= =?utf-8?B?Q3BJSXdXMzRNdWFPSTFYZ2lQdk91ZHN4YWppVS9Sa1JFcUd6cW1OUmJxeDVF?= =?utf-8?B?djBvL0M2SWNBd05tMGZaLzJRSXhkZy9mSXVvbHdmbXlRV3p5dnBDZzNTam5Q?= =?utf-8?B?OWY3S0JYZytZR1JDNytqM050bjErRXoxWjR2WURqK2JtR2toNjFEMWcrRi84?= =?utf-8?B?cXQyeGRRTnk3bUNLTTM0cGlzcmg2bW1pZGdScWx4U1ZQblNrMnJFU3VseE1z?= =?utf-8?B?WE4wYm9GUkE4Q0JlMS9rcFJmM3BMaTlNNFBzOGVzbFhadHNlbVphRVNnS1pQ?= =?utf-8?B?U1BzRjZ3bmZBMTlzcVJ0eGFOT3pUZDhvdVQ1aWFrWktzTGtiQndHa010cjdy?= =?utf-8?B?Q0dDTWUyYUZiRFJ5VGFyT2RXd0loM0dPcTN5K2lYWERMZW82Vy9ZL1E5Uml0?= =?utf-8?B?ako1eVdYU2tGM2Y0bk5hU0x6L0xSNERKWE1zeGRNMGFYZnlrVTF1MEw2b3NP?= =?utf-8?B?T1h5elhpWUhOblpOckl3YWJaWHRmMDZCUVpaRGpOMkNWK0NHdDhmRXRJVTlh?= =?utf-8?B?TXBKZkNFK1JGc3E1WTVhU1hpT3RwTW5KVEdRRmY5NGVLNXNGMFJOZFZEZVJs?= =?utf-8?B?N2tnTkZGMFlSVlpjT09obmtBSTk2dzlsZ3ZRNWY0TThjZTVuWEV1UExGcGMv?= =?utf-8?B?bEdZQUVVTEVlNGIxUWUzeFk4UDErb3l2ckkzTHZFcFF2eWYzQWpZWmowZ3p1?= =?utf-8?B?c2FHZDhmS215eWEyT0VyOTJ2Q2pZSFBXc29VVXZPM293UENDZy9DRzNsenFh?= =?utf-8?B?Y3R1Ly9DSHZnekVlRzRzakhZaURNL1VzL1h6Z3V3blY5R2tOM3Y3UFlycmZT?= =?utf-8?B?WEdHMnA3MjJiM2txMC84VlhxaFF3PT0=?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB44413791A6AC8D20349BEBF793889HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c0573cb8-876b-42d0-ff2b-08d99bf6d74e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2021 22:44:32.4435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7Kr46gEYLM3g8lOjFt3PjEKCJzkcTOhYAxYnZHqDiFRWEERhqdWa4OgopPhD/uHjIOjx1znvv/nVz7VYlwx4NkQpKxOc5osCTSOBrOgo6c0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3036 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 30 Oct 2021 22:44:43 -0000 --_000_HE1PR07MB44413791A6AC8D20349BEBF793889HE1PR07MB4441eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkZpcnN0LCBpdCB3b3VsZCBoYXZlIGJlZW4gbmljZSB0byBzZWUgYSBjYWxsLWZsb3cg dGhhdCBzaG93cyBleGFjdGx5IHdoZXJlIHRoZSBpc3N1ZSBhcmlzZXMsIGFzIHRoZXJlIGFyZSBk aWZmZXJlbnQgd2F5cyBvZiBkb2luZyAzUENDLg0KDQpBbHJlYWR5IGF0IHRoZSBlYXJseSBkYXlz IG9mIEJVTkRMRSwgd2UgYWdyZWVkIHRoYXQgYW4gaW5pdGlhbCBvZmZlciB3aWxsIE5PVCBjb250 YWluIGEgc2hhcmVkIGFkZHJlc3MsIGJlY2F1c2UgaXQgaXMgbm90IGJhY2t3YXJkIGNvbXBhdGli bGUgd2l0aCBub24tYnVuZGxlIGF3YXJlIGVuZHBvaW50cy4gU29tZSBwZW9wbGUgKGluY2x1ZGlu ZyBlLmcuLCBteXNlbGYgYW5kIEN1bGxlbikgd2VyZSB2ZXJ5IGtlZW4gb24gdGhhdC4gSW5zdGVh ZCB3ZSB3aWxsIHVzZSBwb3J0IHplcm8gKyBidW5kbGUtb25seSBmb3IgbS0gbGluZXMgdGhhdCBh cmUgb25seSBiZSBhY2NlcHRlZCBpZiBwYXJ0IG9mIGEgQlVORExFIGdyb3VwLiBJIGRvIG5vdCBh Z3JlZSB0byBhZGRpbmcgdGV4dCB0byA4ODQzYmlzIHNheWluZyB0aGVyZSBhcmUgY2FzZXMgd2hl cmUgdGhlIHNwZWNpZmllZCBwcm9jZWR1cmVzIGZvciBpbml0aWFsIG9mZmVycyBkb27igJl0IGFw cGx5LCBvciBkb27igJl0IGhhdmUgdG8gYmUgZm9sbG93ZWQuDQoNClllcywgd2UgZGlkIGFkZCBz b21lIDNQQ0MgY2xhcmlmaWNhdGlvbiB0ZXh0ICAod2hpY2ggYW55b25lIGNvdWxkIGhhdmUgY29t bWVudGVkIG9uKSBpbiA4ODQzYmlzLCBidXQgd2UgZGlkIG5vdCBjaGFuZ2UgdGhlIHByb2NlZHVy ZXMgZm9yIGluaXRpYWwgb2ZmZXJzLg0KDQpBbHNvIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gYW4gaW5pdGlhbCBvZmZlciBhbmQgYSBzdWJzZXF1ZW50IG9mZmVyIGlz IG5vdCByZWxhdGVkIG9ubHkgdGhlIEJVTkRMRS1yZWxhdGVkIGluZm9ybWF0aW9uLiBGb3IgZXhh bXBsZSwgYW4gaW5pdGlhbCBvZmZlciBtdXN0IGFsc28gY29udGFpbiB1bmlxdWUgSUNFIGNhbmRp ZGF0ZXMgaW4gZWFjaCBub24tYnVuZGxlLW9ubHkgbS0gbGluZS4NCg0KTXkgdW5kZXJzdGFuZGlu ZyBvZiB0aGUgdGV4dCBpbiA4ODI5YmlzIGlzIHRoYXQgSlNFUCBkb2VzIE5PVCBzdXBwb3J0IChv ciwgaWYgd2Ugd2FudCB0byB3b3JkIGl0IGRpZmZlcmVudGx5LCBpcyBub3QgYWJsZSB0byBkZXRl Y3QpIHRoZSAzUENDIGNhc2VzIHJlZmVyZW5jZWQgYnkgUm9tYW4gKGFnYWluLCBjYWxsIGZsb3dz IHdvdWxkIGhhdmUgYmVlbiBuaWNlKSwgc28gYSBKU0VQIGVuZHBvaW50IHdpbGwgYWx3YXlzIHNl bmQgYSBzdWJzZXF1ZW50IG9mZmVyIGFjY29yZGluZyB0byB0aGUgcnVsZXMgZm9yIHNlbmRpbmcg YSBzdWJzZXF1ZW50IG9mZmVyLg0KDQpSZWdhcmRpbmcgUm9tYW7igJlzIHN1Z2dlc3RlZCBzb2x1 dGlvbnMgIzIgYW5kICMzLCBzZW5kaW5nIEFMTCBidW5kbGVkIG0tIGxpbmVzIHdpdGggcG9ydCB6 ZXJvIGFuZCBidW5kbGUtb25seSB3b3VsZCBiZSBzb21ldGhpbmcgY29tcGxldGVseSBuZXcsIGFz IHRoZXJlIHdvdWxkIGJlIG5vIG9mZmVyZXItdGFnZ2VkIG0tIHNlY3Rpb24uIEkgZG9u4oCZdCB0 aGluayB0aGF0IGlzIGEgZ29vZCBpZGVhLiBXZSB3aXRoZXIgc2VuZCBhbiBpbml0aWFsIG9mZmVy LCB1c2luZyB0aGUgcHJvY2VkdXJlcyBmb3IgaW5pdGlhbCBvZmZlcnMsIG9yIHdlIHNlbmQgYSBz dWJzZXF1ZW50IG9mZmVyLCB1c2luZyB0aGUgcHJvY2VkdXJlcyBmb3Igc3Vic2VxdWVudCBvZmZl cnMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogcnRjd2ViIDxydGN3ZWItYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJvbWFuIFNocG91bnQNClNlbnQ6IGxhdWFudGFp IDMwLiBsb2tha3V1dGEgMjAyMSA1LjI3DQpUbzogSnVzdGluIFViZXJ0aSA8anViZXJ0aUBhbHBo YWV4cGxvcmF0aW9uY28uY29tPg0KQ2M6IEp1c3RpbiBVYmVydGkgPGp1c3RpbkB1YmVydGkubmFt ZT47IFJUQ1dlYiBJRVRGIDxydGN3ZWJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3J0Y3dlYl0g V29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LXViZXJ0aS1ydGN3ZWItcmZjODgyOWJp cy0wMS50eHQNCg0KT24gRnJpLCBPY3QgMjksIDIwMjEgYXQgNjo0OSBQTSBKdXN0aW4gVWJlcnRp IDxqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb208bWFpbHRvOmp1YmVydGlAYWxwaGFleHBs b3JhdGlvbmNvLmNvbT4+IHdyb3RlOg0KDQoNCk9uIEZyaSwgT2N0IDI5LCAyMDIxIGF0IDM6Mjkg UE0gUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb208bWFpbHRvOnJvbWFuQHRlbHVyaXgu Y29tPj4gd3JvdGU6DQpPbiBGcmksIE9jdCAyOSwgMjAyMSBhdCAyOjE2IFBNIEp1c3RpbiBVYmVy dGkgPGp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbTxtYWlsdG86anViZXJ0aUBhbHBoYWV4 cGxvcmF0aW9uY28uY29tPj4gd3JvdGU6DQoNCkFzIEkgYW0gdHJ5aW5nIHRvIGV4cGxhaW4sIHRo ZXJlIGlzIG5vdGhpbmcgaW4gdGhlIG9mZmVyIHRoYXQgd291bGQgcHJldmVudCB0aGUgY29tcGxp YW50IGltcGxlbWVudGF0aW9uIGZyb20gbW92aW5nIHRoZSBtPSBsaW5lIG91dC4gVGhpcyBpcyBu b3Qgb2J2aW91cyBidXQgY2FuIGNhdXNlIGdyaWVmLg0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IGl0 IGlzIG5vdCBwb3NzaWJsZSwgYXMgdGhlcmUgaXMgbm8gb3RoZXIgdHJhbnNwb3J0IHRvIG1vdmUg dGhlIHVuYnVuZGxlZCBsaW5lIHRvLiBBcyBub3RlZCBpbiB0aGUgc2VjdGlvbiB5b3UgY2l0ZToN Cg0KICJOT1RFOiBPbmUgY29uc2VxdWVuY2Ugb2YgdGhlIHJ1bGVzIGFib3ZlIGlzIHRoYXQsIG9u Y2UgYSBCVU5ETEUgZ3JvdXAgaGFzIGJlZW4gbmVnb3RpYXRlZCwgYSBidW5kbGVkICJtPSIgc2Vj dGlvbiBjYW5ub3QgYmUgbW92ZWQgb3V0IG9mIHRoZSBCVU5ETEUgZ3JvdXAgaW4gYW4gYW5zd2Vy LiBJbnN0ZWFkLCBhbiBvZmZlciBpcyBuZWVkZWQuOiINCg0KR2VuZXJhbGx5LCBJIHRoaW5rIHRo YXQgaWYgdGhlcmUgaXMgYSBzaGFyZWQgYWRkcmVzcywgdGhhdCBzaWduaWZpZXMgdGhhdCBhIEJV TkRMRSBncm91cCBoYXMgYWxyZWFkeSBiZWVuIG5lZ290aWF0ZWQsIGV2ZW4gaWYgdGhhdCBkZWNp c2lvbiB3YXMgbWFkZSBlbHNld2hlcmUuIFBlcmhhcHMgYSBub3RlIHNob3VsZCBiZSBhZGRlZCB0 byBidW5kbGUtYmlzIHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcy4NCg0KV2hlbiBkaXNjdXNzaW5n IGJ1bmRsZS1iaXMgdGhlIHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgaXQgaXMgZ2VuZXJhbGx5IGtu b3duIHdoZW4gYW4gb2ZmZXIgaXMgZ2VuZXJhdGVkIGZvciAzcGNjLiBCZWNhdXNlIG9mIHRoaXMs IGl0IHdhcyBkZWNpZGVkIHRoYXQgd2hlbiB0aGUgb2ZmZXIgaXMgZ2VuZXJhdGVkIGZvciAzcGNj IGl0IHNob3VsZCBiZSBnZW5lcmF0ZWQgdXNpbmcgdGhlIHNhbWUgcnVsZXMgYXMgdGhlIGluaXRp YWwgb2ZmZXIgKGkuZS4gd2l0aCBwb3J0IHplcm8gYW5kIGJ1bmRsZS1vbmx5KS4gVGhpcyB3YXMg Y29uc2lkZXJlZCB0byBiZSBib3RoIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGggUkJGIDg4NDMg YW5kIHNhZmUgdG8gdXNlIGFzIGFuIGluaXRpYWwgb2ZmZXIgZm9yIG5vbi1idW5kbGUgYXdhcmUs IGJ1bmRsZSwgYW5kIGJ1bmRsZS1iaXMgZW5kcG9pbnRzLiBGb3Igd2hhdGV2ZXIgcmVhc29uLCBp bnNwZWN0aW5nIHRyYW5zcG9ydCBhZGRyZXNzZXMgd2FzIG5vdCBjb25zaWRlcmVkIGEgdmFsaWQg bWVjaGFuaXNtIHRvIGRldGVjdCB0aGF0IG09IGxpbmVzIGFyZSBhbHJlYWR5IGJ1bmRsZWQgYW5k IGNhbm5vdCBiZSB1bmJ1bmRsZWQgaW4gdGhlIGZ1dHVyZS4gSWYgd2Ugd2FudCB0byBzd2l0Y2gg dG8gaW5zcGVjdGluZyB0cmFuc3BvcnQgYWRkcmVzc2VzIHdoZW4gZGVjaWRpbmcgd2hpY2ggbT0g bGluZXMgY2FuIGJlIHVuYnVuZGxlZCwgdGhpcyBkZXNlcnZlcyBhIGxvdCBtb3JlIHRoYW4gYSBu b3RlIGluIGJ1bmRsZS1iaXMuDQoNClRoaXMgbG9naWMgbmVlZHMgdG8gYmUgYXBwbGllZCBvbiBz dWJzZXF1ZW50IG9mZmVycyBhbHJlYWR5IHRob3VnaCwgc28gSSBkb24ndCB1bmRlcnN0YW5kIHdo eSBhc2tpbmcgZW5kcG9pbnRzIHRvIGFsc28gY29uc2lkZXIgaXQgb24gaW5pdGlhbCBvZmZlcnMg aXMgYW4gaXNzdWUuIFBlcmhhcHMgQ2hyaXN0ZXIgY291bGQgd2VpZ2ggaW4gaGVyZS4NCg0KRHVy aW5nIHRoZSBpbml0aWFsIG9mZmVyIGVuZCBwb2ludCBkb2VzIG5vdCBoYXZlIGFscmVhZHkgbmVn b3RpYXRlZCBidW5kbGUgZ3JvdXBzLiBPbmNlIHRoZSBlbmRwb2ludCBoYXMgYWxyZWFkeSBuZWdv dGlhdGVkIGJ1bmRsZSBncm91cHMsIG09IGxpbmVzIGNhbm5vdCBiZSByZW1vdmVkIGZyb20gdGhl bS4NCg0KSSB3b3VsZCBzdGlsbCBhcmd1ZSB0aGF0IGEgc2FmZSB3YXkgdG8gZ2VuZXJhdGUgYW4g b2ZmZXIgZm9yIDNQQ0MgaXMgdG8gZG8gU0RQIG1hbmlwdWxhdGlvbiBhbmQgc2V0IHBvcnRzIHRv IDAgd2l0aCBhdHRyaWJ1dGUgYnVuZGxlLW9ubHkuIEV2ZXJ5dGhpbmcgZWxzZSB3b3VsZCBub3Qg YmUgY29tcGF0aWJsZSB3aXRoIGVpdGhlciBidW5kbGUtYmlzIG9yIFJGQyA4ODQzLg0KDQpJIGFt IGZpbmUgdG8gaW5jbHVkZSB0aGlzIGFzIGEgY29uc2lkZXJhdGlvbiBmb3Igbm9uLUJVTkRMRSBl bmRwb2ludHMgYnV0IGl0IHNlZW1zIGVycm9yLXByb25lIGFuZCB1bm5lY2Vzc2FyeSB0byBkbyB0 aGlzIGZvciBCVU5ETEUtYXdhcmUgZW5kcG9pbnRzLg0KDQpZb3VyIGxvZ2ljIG9ubHkgd29ya3Mg aWYgYnVuZGxlLWF3YXJlIGVuZHBvaW50cyB3ZXJlIG5vdCBhbGxvd2VkIHRvIHJlbW92ZSBtPSBs aW5lcyBmcm9tIGEgYnVuZGxlIGdyb3VwLiBMb29raW5nIGF0IHRoZSBhZGRyZXNzZXMgdG8gZGV0 ZXJtaW5lIHdoYXQgaXMgYWxyZWFkeSBncm91cGVkIGlzIGluc3VmZmljaWVudCwgc2luY2UgYW4g b2ZmZXIgY2FuIGFsc28gYmUgYW4gb2ZmZXIgd2l0aCBpY2UgcmVzdGFydCBhbmQgdHJpY2tsZS4g Tm8gYWRkcmVzc2VzIHdpbGwgYmUgcHJlc2VudCwgc28gdGhlIGVuZHBvaW50IHdpbGwgaGF2ZSB0 byBsb29rIGF0IGljZSBwYXJhbWV0ZXJzIGFzIHdlbGwuIFRoaXMgZ2V0cyBjb21wbGljYXRlZCBh bmQgbm8gb25lIHdhbnRlZCB0byBkZXNjcmliZSB0aGlzIHdoZW4gODg0M2JpcyB3YXMgd3JpdHRl bi4gIFRoaXMgaXMgd2h5IHJmYyA4ODQzYmlzIHNwZWNpZmllcyB0aGF0IHN1YnNlcXVlbnQgb2Zm ZXJzIGZvciAzUENDIHNob3VsZCBiZSB2YWxpZCBpbml0aWFsIG9mZmVycy4NCg0KVGhlcmUgYXJl LCBwb3RlbnRpYWxseSwgdHdvIHNvbHV0aW9ucyB0byB0aGlzOg0KDQoxLiBDaGFuZ2UgYnVuZGxl IHNvIHRoYXQgZW5kcG9pbnRzIGFyZSByZXF1aXJlZCB0byBpbnNwZWN0IGluaXRpYWwgb2ZmZXJz IGZvciB0cmFuc3BvcnQgYWRkcmVzc2VzIGFuZCBpY2UgcGFyYW1ldGVycy4gRG8gbm90IGFsbG93 IG09IGxpbmVzIHRvIGJlIHJlbW92ZWQgZnJvbSB0aGUgYnVuZGxlIGdyb3VwIGlmIHRoZXkgc2hh cmUgdGhlIHRyYW5zcG9ydCBhZGRyZXNzLiBUaGlzIHdvdWxkIHJlcXVpcmUgcHVsbGluZyBSRkMg ODg0M2JpcyBhbmQgd3JpdGluZyB0aGUgYXBwcm9wcmlhdGUgbGFuZ3VhZ2UuDQoNCjIuIENoYW5n ZSBKU0VQIG5vdGUgdG8gc3BlY2lmeSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBuZWVkcyB0byBtYWtl IHN1cmUgdGhhdCBpbiBjYXNlIG9mIDNQQ0MgYW5kIHJlbW90ZSBlbmRwb2ludHMgZWl0aGVyIHBv dGVudGlhbGx5IHJlbW92aW5nIG09IGxpbmVzIGZyb20gdGhlIGJ1bmRsZSBvciBub3QgYmVpbmcg YnVuZGxlLWF3YXJlLCBidW5kbGVkIG09IGxpbmVzIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gaGF2 ZSBwb3J0IDAgYW5kIGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZS4gQ29uc2lkZXJpbmcgdGhhdCBtb3N0 IGJ1bmRsZS1hd2FyZSBlbmRwb2ludHMgZG8gbm90IHJlbW92ZSBtPSBsaW5lcyBmcm9tIHRoZSBi dW5kbGUsIHRoaXMgb3B0aW9uIHdvdWxkIGNhdXNlIHRoZSBsZWFzdCBhbW91bnQgb2Ygc3BlY2lm aWNhdGlvbiB3b3JrLg0KDQozLiBJZiB3ZSB3YW50IHRvIGNvbXBsZXRlbHkgYXZvaWQgYXBwbGlj YXRpb25zIG1lc3Npbmcgd2l0aCBTRFAsIGNoYW5nZSBKU0VQIHRvIHNwZWNpZnkgdGhhdCB3aGVu IGljZS1yZXN0YXJ0IGlzIHNwZWNpZmllZCBhbmQgYSBuZXcgb2ZmZXIgaXMgZ2VuZXJhdGVkLCBh bHJlYWR5IGJ1bmRsZWQgbT0gbGluZXMgc2hvdWxkIGJlIG1hcmtlZCB3aXRoIHBvcnQgMCBhbmQg YnVuZGxlLW9ubHkuIFRoaXMgd291bGQgYWxzbyByZXN1bHQgaW4gdGhlIGxlYXN0IG51bWJlciBv ZiBzdXJwcmlzZXMgZm9yIGRldmVsb3BlcnMuDQoNCkJlc3QgUmVnYXJkcywNCl9fX19fX19fX19f X18NClJvbWFuIFNocG91bnQNCg0K --_000_HE1PR07MB44413791A6AC8D20349BEBF793889HE1PR07MB4441eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTm90byBTYW5zIjt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4w cHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjc0ODIyOTg5MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6NjU0ODg4NTI2IDY3ODI5Nzc3IDY3ODI5Nzg1IDY3ODI5Nzg3 IDY3ODI5Nzc1IDY3ODI5Nzg1IDY3ODI5Nzg3IDY3ODI5Nzc1IDY3ODI5Nzg1IDY3ODI5Nzg3O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3Jh cDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZpcnN0LCBpdCB3b3VsZCBoYXZlIGJlZW4gbmlj ZSB0byBzZWUgYSBjYWxsLWZsb3cgdGhhdCBzaG93cyBleGFjdGx5IHdoZXJlIHRoZSBpc3N1ZSBh cmlzZXMsIGFzIHRoZXJlIGFyZSBkaWZmZXJlbnQgd2F5cyBvZiBkb2luZyAzUENDLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFscmVhZHkgYXQgdGhlIGVhcmx5IGRheXMgb2YgQlVO RExFLCB3ZSBhZ3JlZWQgdGhhdCBhbiBpbml0aWFsIG9mZmVyIHdpbGwgTk9UIGNvbnRhaW4gYSBz aGFyZWQgYWRkcmVzcywgYmVjYXVzZSBpdCBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRo IG5vbi1idW5kbGUgYXdhcmUgZW5kcG9pbnRzLiBTb21lIHBlb3BsZQ0KIChpbmNsdWRpbmcgZS5n LiwgbXlzZWxmIGFuZCBDdWxsZW4pIHdlcmUgdmVyeSBrZWVuIG9uIHRoYXQuIEluc3RlYWQgd2Ug d2lsbCB1c2UgcG9ydCB6ZXJvICsgYnVuZGxlLW9ubHkgZm9yIG0tIGxpbmVzIHRoYXQgYXJlIG9u bHkgYmUgYWNjZXB0ZWQgaWYgcGFydCBvZiBhIEJVTkRMRSBncm91cC4gSSBkbyBub3QgYWdyZWUg dG8gYWRkaW5nIHRleHQgdG8gODg0M2JpcyBzYXlpbmcgdGhlcmUgYXJlIGNhc2VzIHdoZXJlIHRo ZSBzcGVjaWZpZWQgcHJvY2VkdXJlcw0KIGZvciBpbml0aWFsIG9mZmVycyBkb27igJl0IGFwcGx5 LCBvciBkb27igJl0IGhhdmUgdG8gYmUgZm9sbG93ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+WWVzLCB3ZSBkaWQgYWRkIHNvbWUgM1BDQyBjbGFyaWZpY2F0aW9uIHRleHQgJm5i c3A7KHdoaWNoIGFueW9uZSBjb3VsZCBoYXZlIGNvbW1lbnRlZCBvbikgaW4gODg0M2JpcywgYnV0 IHdlIGRpZCBub3QgY2hhbmdlIHRoZSBwcm9jZWR1cmVzIGZvciBpbml0aWFsIG9mZmVycy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFsc28ga2VlcCBpbiBtaW5kIHRoYXQgdGhl IGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBpbml0aWFsIG9mZmVyIGFuZCBhIHN1YnNlcXVlbnQgb2Zm ZXIgaXMgbm90IHJlbGF0ZWQgb25seSB0aGUgQlVORExFLXJlbGF0ZWQgaW5mb3JtYXRpb24uIEZv ciBleGFtcGxlLCBhbiBpbml0aWFsIG9mZmVyIG11c3QgYWxzbyBjb250YWluDQogdW5pcXVlIElD RSBjYW5kaWRhdGVzIGluIGVhY2ggbm9uLWJ1bmRsZS1vbmx5IG0tIGxpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+TXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGV4dCBpbiA4ODI5 YmlzIGlzIHRoYXQgSlNFUCBkb2VzIE5PVCBzdXBwb3J0IChvciwgaWYgd2Ugd2FudCB0byB3b3Jk IGl0IGRpZmZlcmVudGx5LCBpcyBub3QgYWJsZSB0byBkZXRlY3QpIHRoZSAzUENDIGNhc2VzIHJl ZmVyZW5jZWQgYnkgUm9tYW4gKGFnYWluLCBjYWxsIGZsb3dzDQogd291bGQgaGF2ZSBiZWVuIG5p Y2UpLCBzbyBhIEpTRVAgZW5kcG9pbnQgd2lsbCBhbHdheXMgc2VuZCBhIHN1YnNlcXVlbnQgb2Zm ZXIgYWNjb3JkaW5nIHRvIHRoZSBydWxlcyBmb3Igc2VuZGluZyBhIHN1YnNlcXVlbnQgb2ZmZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkaW5nIFJvbWFu4oCZcyBzdWdn ZXN0ZWQgc29sdXRpb25zICMyIGFuZCAjMywgc2VuZGluZyBBTEwgYnVuZGxlZCBtLSBsaW5lcyB3 aXRoIHBvcnQgemVybyBhbmQgYnVuZGxlLW9ubHkgd291bGQgYmUgc29tZXRoaW5nIGNvbXBsZXRl bHkgbmV3LCBhcyB0aGVyZSB3b3VsZCBiZSBubyBvZmZlcmVyLXRhZ2dlZCBtLQ0KIHNlY3Rpb24u IEkgZG9u4oCZdCB0aGluayB0aGF0IGlzIGEgZ29vZCBpZGVhLiBXZSB3aXRoZXIgc2VuZCBhbiBp bml0aWFsIG9mZmVyLCB1c2luZyB0aGUgcHJvY2VkdXJlcyBmb3IgaW5pdGlhbCBvZmZlcnMsIG9y IHdlIHNlbmQgYSBzdWJzZXF1ZW50IG9mZmVyLCB1c2luZyB0aGUgcHJvY2VkdXJlcyBmb3Igc3Vi c2VxdWVudCBvZmZlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBydGN3ZWIgJmx0O3J0Y3dlYi1i b3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb21hbiBTaHBvdW50PGJy Pg0KPGI+U2VudDo8L2I+IGxhdWFudGFpIDMwLiBsb2tha3V1dGEgMjAyMSA1LjI3PGJyPg0KPGI+ VG86PC9iPiBKdXN0aW4gVWJlcnRpICZsdDtqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBKdXN0aW4gVWJlcnRpICZsdDtqdXN0aW5AdWJlcnRpLm5hbWUm Z3Q7OyBSVENXZWIgSUVURiAmbHQ7cnRjd2ViQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW3J0Y3dlYl0gV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LXViZXJ0 aS1ydGN3ZWItcmZjODgyOWJpcy0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBPY3QgMjksIDIwMjEgYXQgNjo0OSBQTSBKdXN0aW4gVWJlcnRpICZsdDs8 YSBocmVmPSJtYWlsdG86anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tIj5qdWJlcnRpQGFs cGhhZXhwbG9yYXRpb25jby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDI5LCAyMDIxIGF0IDM6MjkgUE0gUm9tYW4gU2hwb3Vu dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbWFuQHRlbHVyaXguY29tIiB0YXJnZXQ9Il9ibGFuayI+ cm9tYW5AdGVsdXJpeC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIE9jdCAyOSwgMjAyMSBhdCAyOjE2IFBNIEp1c3RpbiBVYmVydGkgJmx0Ozxh IGhyZWY9Im1haWx0bzpqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20iIHRhcmdldD0iX2Js YW5rIj5qdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BcyBJIGFtIHRyeWluZyB0byBleHBsYWluLCB0aGVyZSBpcyBub3RoaW5nIGlu IHRoZSBvZmZlciB0aGF0IHdvdWxkIHByZXZlbnQmbmJzcDt0aGUmbmJzcDtjb21wbGlhbnQmbmJz cDtpbXBsZW1lbnRhdGlvbiBmcm9tIG1vdmluZyB0aGUmbmJzcDttPSBsaW5lIG91dC4gVGhpcyBp cyBub3Qgb2J2aW91cyBidXQgY2FuIGNhdXNlIGdyaWVmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHByb2JsZW0gaXMgdGhhdCBpdCBpcyBub3QgcG9zc2libGUsIGFzIHRoZXJlIGlz IG5vIG90aGVyIHRyYW5zcG9ydCB0byBtb3ZlIHRoZSB1bmJ1bmRsZWQgbGluZSB0by4gQXMgbm90 ZWQgaW4gdGhlIHNlY3Rpb24geW91IGNpdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O05vdG8gU2FucyZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmcXVvdDtO T1RFOiBPbmUgY29uc2VxdWVuY2Ugb2YgdGhlIHJ1bGVzIGFib3ZlIGlzIHRoYXQsIG9uY2UgYSBC VU5ETEUgZ3JvdXAgaGFzIGJlZW4gbmVnb3RpYXRlZCwgYSBidW5kbGVkICZxdW90O209JnF1b3Q7 IHNlY3Rpb24gY2Fubm90IGJlIG1vdmVkIG91dCBvZiB0aGUgQlVORExFIGdyb3VwIGluIGFuIGFu c3dlci4NCiBJbnN0ZWFkLCBhbiBvZmZlciBpcyBuZWVkZWQuOiZxdW90Ozwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJhbGx5 LCBJIHRoaW5rIHRoYXQgaWYgdGhlcmUgaXMgYSBzaGFyZWQgYWRkcmVzcywgdGhhdCBzaWduaWZp ZXMgdGhhdCBhIEJVTkRMRSBncm91cCBoYXMgYWxyZWFkeSBiZWVuIG5lZ290aWF0ZWQsIGV2ZW4g aWYgdGhhdCBkZWNpc2lvbiB3YXMgbWFkZSBlbHNld2hlcmUuIFBlcmhhcHMgYSBub3RlIHNob3Vs ZCBiZSBhZGRlZCB0byBidW5kbGUtYmlzIHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhpcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gZGlzY3Vzc2luZyBidW5kbGUtYmlzIHRoZSB1bmRl cnN0YW5kaW5nJm5ic3A7d2FzIHRoYXQgaXQgaXMgZ2VuZXJhbGx5IGtub3duIHdoZW4gYW4gb2Zm ZXIgaXMgZ2VuZXJhdGVkIGZvciAzcGNjLiBCZWNhdXNlIG9mIHRoaXMsIGl0IHdhcyBkZWNpZGVk IHRoYXQgd2hlbiB0aGUgb2ZmZXIgaXMgZ2VuZXJhdGVkIGZvciAzcGNjIGl0IHNob3VsZCBiZSBn ZW5lcmF0ZWQgdXNpbmcgdGhlIHNhbWUgcnVsZXMgYXMgdGhlDQogaW5pdGlhbCBvZmZlciAoaS5l LiB3aXRoIHBvcnQgemVybyBhbmQgYnVuZGxlLW9ubHkpLiBUaGlzIHdhcyBjb25zaWRlcmVkIHRv IGJlIGJvdGggYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBSQkYgODg0MyBhbmQgc2FmZSB0byB1 c2UgYXMgYW4gaW5pdGlhbCBvZmZlciBmb3Igbm9uLWJ1bmRsZSZuYnNwO2F3YXJlLCBidW5kbGUs IGFuZCBidW5kbGUtYmlzIGVuZHBvaW50cy4gRm9yIHdoYXRldmVyIHJlYXNvbiwgaW5zcGVjdGlu ZyB0cmFuc3BvcnQgYWRkcmVzc2VzDQogd2FzIG5vdCBjb25zaWRlcmVkIGEgdmFsaWQgbWVjaGFu aXNtIHRvIGRldGVjdCB0aGF0IG09IGxpbmVzIGFyZSBhbHJlYWR5IGJ1bmRsZWQgYW5kIGNhbm5v dCBiZSB1bmJ1bmRsZWQgaW4gdGhlIGZ1dHVyZS4gSWYgd2Ugd2FudCB0byBzd2l0Y2ggdG8gaW5z cGVjdGluZyB0cmFuc3BvcnQgYWRkcmVzc2VzIHdoZW4gZGVjaWRpbmcgd2hpY2ggbT0gbGluZXMg Y2FuIGJlIHVuYnVuZGxlZCwgdGhpcyBkZXNlcnZlcyBhIGxvdCBtb3JlIHRoYW4gYSBub3RlDQog aW4gYnVuZGxlLWJpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbG9naWMgbmVl ZHMgdG8gYmUgYXBwbGllZCBvbiBzdWJzZXF1ZW50IG9mZmVycyBhbHJlYWR5IHRob3VnaCwgc28g SSBkb24ndCB1bmRlcnN0YW5kIHdoeSBhc2tpbmcgZW5kcG9pbnRzIHRvIGFsc28gY29uc2lkZXIg aXQgb24gaW5pdGlhbCBvZmZlcnMgaXMgYW4gaXNzdWUuIFBlcmhhcHMgQ2hyaXN0ZXIgY291bGQg d2VpZ2ggaW4gaGVyZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkR1cmluZyB0 aGUgaW5pdGlhbCBvZmZlciBlbmQgcG9pbnQgZG9lcyBub3QgaGF2ZSBhbHJlYWR5IG5lZ290aWF0 ZWQgYnVuZGxlIGdyb3Vwcy4gT25jZSB0aGUgZW5kcG9pbnQgaGFzIGFscmVhZHkgbmVnb3RpYXRl ZCBidW5kbGUgZ3JvdXBzLCBtPSBsaW5lcyBjYW5ub3QgYmUgcmVtb3ZlZCBmcm9tIHRoZW0uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQg c3RpbGwgYXJndWUgdGhhdCBhIHNhZmUgd2F5IHRvIGdlbmVyYXRlIGFuIG9mZmVyIGZvciAzUEND IGlzIHRvIGRvIFNEUCBtYW5pcHVsYXRpb24gYW5kIHNldCBwb3J0cyB0byAwIHdpdGggYXR0cmli dXRlIGJ1bmRsZS1vbmx5LiBFdmVyeXRoaW5nIGVsc2Ugd291bGQgbm90IGJlIGNvbXBhdGlibGUg d2l0aCBlaXRoZXIgYnVuZGxlLWJpcyBvciBSRkMgODg0My48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgYW0gZmluZSB0byBpbmNsdWRlIHRoaXMgYXMgYSBjb25zaWRlcmF0aW9uIGZvciBu b24tQlVORExFIGVuZHBvaW50cyBidXQgaXQgc2VlbXMgZXJyb3ItcHJvbmUgYW5kIHVubmVjZXNz YXJ5IHRvIGRvIHRoaXMgZm9yIEJVTkRMRS1hd2FyZSBlbmRwb2ludHMuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3VyIGxvZ2ljIG9ubHkgd29ya3MgaWYgYnVuZGxlLWF3YXJl IGVuZHBvaW50cyB3ZXJlIG5vdCBhbGxvd2VkIHRvIHJlbW92ZSBtPSBsaW5lcyBmcm9tIGEgYnVu ZGxlIGdyb3VwLiBMb29raW5nIGF0IHRoZSBhZGRyZXNzZXMgdG8gZGV0ZXJtaW5lIHdoYXQgaXMg YWxyZWFkeSBncm91cGVkIGlzIGluc3VmZmljaWVudCwgc2luY2UgYW4gb2ZmZXIgY2FuIGFsc28g YmUgYW4gb2ZmZXIgd2l0aCBpY2UgcmVzdGFydA0KIGFuZCB0cmlja2xlLiBObyBhZGRyZXNzZXMg d2lsbCBiZSBwcmVzZW50LCBzbyB0aGUgZW5kcG9pbnQgd2lsbCBoYXZlIHRvIGxvb2sgYXQgaWNl IHBhcmFtZXRlcnMgYXMgd2VsbC4gVGhpcyBnZXRzIGNvbXBsaWNhdGVkIGFuZCBubyBvbmUgd2Fu dGVkIHRvIGRlc2NyaWJlIHRoaXMgd2hlbiA4ODQzYmlzJm5ic3A7d2FzIHdyaXR0ZW4uJm5ic3A7 IFRoaXMgaXMgd2h5IHJmYyA4ODQzYmlzJm5ic3A7c3BlY2lmaWVzIHRoYXQgc3Vic2VxdWVudCBv ZmZlcnMgZm9yIDNQQ0Mgc2hvdWxkDQogYmUgdmFsaWQgaW5pdGlhbCBvZmZlcnMuIDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUs IHBvdGVudGlhbGx5LCB0d28gc29sdXRpb25zIHRvIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIENoYW5nZSBidW5kbGUgc28gdGhh dCBlbmRwb2ludHMgYXJlIHJlcXVpcmVkIHRvIGluc3BlY3QgaW5pdGlhbCZuYnNwO29mZmVycyBm b3IgdHJhbnNwb3J0IGFkZHJlc3NlcyBhbmQgaWNlIHBhcmFtZXRlcnMuIERvIG5vdCBhbGxvdyBt PSBsaW5lcyB0byBiZSByZW1vdmVkIGZyb20gdGhlIGJ1bmRsZSBncm91cCBpZiB0aGV5IHNoYXJl IHRoZSB0cmFuc3BvcnQgYWRkcmVzcy4gVGhpcyB3b3VsZCByZXF1aXJlIHB1bGxpbmcNCiBSRkMg ODg0M2JpcyBhbmQgd3JpdGluZyB0aGUgYXBwcm9wcmlhdGUgbGFuZ3VhZ2UuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIENoYW5nZSBKU0VQ IG5vdGUgdG8gc3BlY2lmeSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBuZWVkcyB0byBtYWtlIHN1cmUg dGhhdCBpbiBjYXNlIG9mIDNQQ0MgYW5kIHJlbW90ZSBlbmRwb2ludHMgZWl0aGVyIHBvdGVudGlh bGx5IHJlbW92aW5nIG09IGxpbmVzIGZyb20gdGhlIGJ1bmRsZSBvciBub3QgYmVpbmcgYnVuZGxl LWF3YXJlLCBidW5kbGVkIG09IGxpbmVzIG5lZWQgdG8gYmUgbW9kaWZpZWQgdG8gaGF2ZQ0KIHBv cnQgMCBhbmQgYnVuZGxlLW9ubHkgYXR0cmlidXRlLiBDb25zaWRlcmluZyB0aGF0IG1vc3QgYnVu ZGxlLWF3YXJlIGVuZHBvaW50cyBkbyBub3QgcmVtb3ZlIG09IGxpbmVzIGZyb20gdGhlIGJ1bmRs ZSwgdGhpcyBvcHRpb24gd291bGQgY2F1c2UgdGhlIGxlYXN0IGFtb3VudCBvZiBzcGVjaWZpY2F0 aW9uIHdvcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjMuIElmIHdlIHdhbnQgdG8gY29tcGxldGVseSBhdm9pZCBhcHBsaWNhdGlvbnMgbWVz c2luZyB3aXRoIFNEUCwgY2hhbmdlIEpTRVAgdG8gc3BlY2lmeSB0aGF0IHdoZW4gaWNlLXJlc3Rh cnQgaXMgc3BlY2lmaWVkIGFuZCBhIG5ldyBvZmZlciBpcyBnZW5lcmF0ZWQsIGFscmVhZHkgYnVu ZGxlZCBtPSBsaW5lcyBzaG91bGQgYmUgbWFya2VkIHdpdGggcG9ydCAwIGFuZCBidW5kbGUtb25s eS4gVGhpcyB3b3VsZCBhbHNvDQogcmVzdWx0IGluIHRoZSBsZWFzdCBudW1iZXIgb2Ygc3VycHJp c2VzIGZvciBkZXZlbG9wZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR07MB44413791A6AC8D20349BEBF793889HE1PR07MB4441eurp_-- From nobody Sat Oct 30 21:02:00 2021 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 499B73A085D for ; Sat, 30 Oct 2021 21:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 MeUk8jK6FjWO for ; Sat, 30 Oct 2021 21:01:53 -0700 (PDT) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 E13203A085C for ; Sat, 30 Oct 2021 21:01:52 -0700 (PDT) Received: by mail-qk1-x732.google.com with SMTP id x123so13492168qke.7 for ; Sat, 30 Oct 2021 21:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ejQS3wSlyrGS85fnKuYgnJfY/j4QT/208S43LJGh25c=; b=AnyUr3uLZUHPZ6YuzlmJ3X/uwB62N5M6+HGHfXykydOkJz5nv4znwbPThp0JxwlEee q6drXwAOAnYRDaqkuMV0eEhDDWUgPwtHumWNrOynleVIr7oxHHkiG6rSDSzcQLVykfyi 4/Mywmu5JAszFjQsnlvgHradWKWd6A+vpYKwI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ejQS3wSlyrGS85fnKuYgnJfY/j4QT/208S43LJGh25c=; b=oJF1Ypq51Fblg7hNXq2+54LC1pdGEtLINHmVKmwwmMn5sFUa91nFPsDRCgrzD28V7Z alBOXynSpw7Vn7+28qQdbw36BXfrxw7szmkARM0h1HEsBH5Sil8kvh9p7oOdsAV7MCUN fNQ2zquDo1n+zqC7wAgjzGl4vPGB+3o+9iMElrx40RhfWYoZFy45A4NcNpaYN/glin9B EXYUpcGn87DEhylzxVX2TKhEvg0WPRnsig8dAuu72Hm84Eb+pY60Kk7pWPbo/95FrT9R DjW3MVz4n/nS4BUu6Rn4bfeVRs/oAjQzT2Od0jSNZvfMUrM0Co9XuBM5VFOX+N5vZ6aj Q9Bg== X-Gm-Message-State: AOAM530L+QpjHEI3D8Hfnfn7OEL0rf2JM6JzayAhQup9rxxLbky/KkTz Bo4c6PrNcQWBaTcGFXmOC/9Yxl6+MQ+mrg== X-Google-Smtp-Source: ABdhPJzhH6uT82najaj+MYuALzK6RMiBiIbXoXq8062P8s1vd+J3qVBdX363sS2cne2KpkfZd0bgEw== X-Received: by 2002:ae9:f408:: with SMTP id y8mr10165657qkl.178.1635652910775; Sat, 30 Oct 2021 21:01:50 -0700 (PDT) Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com. [209.85.219.182]) by smtp.gmail.com with ESMTPSA id z19sm7190267qts.96.2021.10.30.21.01.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 30 Oct 2021 21:01:50 -0700 (PDT) Received: by mail-yb1-f182.google.com with SMTP id d10so24562061ybe.3 for ; Sat, 30 Oct 2021 21:01:49 -0700 (PDT) X-Received: by 2002:a5b:482:: with SMTP id n2mr22208245ybp.514.1635652909151; Sat, 30 Oct 2021 21:01:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Sun, 31 Oct 2021 00:01:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000a03ac705cf9e1eb7" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 31 Oct 2021 04:01:58 -0000 --000000000000a03ac705cf9e1eb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, I can try to explain the issue. If you need I can provide a more detailed call flow with SDP examples but here is the basic scenario for nonw: 1. 3PCC application requests an offer from client A. 2. Client A generates an offer with audio, video, and data m=3D lines which are part of a single bundle group. It does not matter for this case if they are bundle-only or can be unbundled 3. Signaling application sends the offer received from client A to client B= . 4. Client B supports bundle so it generates an answer where all m=3D lines are bundled 5. 3PCC sends the answer to Client A. At this point all m=3D lines are bundled and cannot be unbundled. 6. 3PCC application requests another offer from client A within the same session. This offer is a subsequent offer so it would have all 3 m=3D lines bundled. 7. 3PCC sends the generated offer to client C. 8. Client C is generating an answer to the offer it received. Client C is bundle aware but decides that it wants to unbundle data m=3D line. As far a= s Client C is concerned, there are no pre-negotiated bundle groups. If there are no bundle-only attributes on m=3D lines, there is nothing stopping clie= nt C from unbundling. Per draft 8843 bis, SIP consideration section ( https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-s= ip-considerations), ofer in step 6 should be generated as an initial offer, i.e. with port 0 and bundle-only in bundled m=3D lines. This is done specifically to avoid problems in step 8. What I am suggesting is not to always generate subsequent offers with port zero and bundle-only. I am suggesting only do this, when this offer is intended for 3PCC. There is already a similar feature for ICE which triggers ice restart for the offer which can be used for 3PCC. It can also trigger generation of an offer with bundle-only for all bundled m=3D lines.= I would even be fine with webrtc endpoint not doing anything and adding a note to JSEP telling the 3PCC application to "fix" the offer and add m=3D port zero and bundle-only attributes when it is sending subsequent offers as initial offers to a new end point. In any case, the subsequent offer generated in step 6 is not a valid initial offer according to the bundle specification. We have two choices: 1. Make subsequent offers valid initial offers. This means adding some language explaining how the endpoint processing initial offer can detect that m=3D lines cannot be unbundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented it. 2. Make endpoints generate subsequent offers that are valid initial offers in 3PCC scenarios. This is what draft 8843 bis does. Please let me know if you need more details. _____________ Roman Shpount On Sat, Oct 30, 2021 at 6:44 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > First, it would have been nice to see a call-flow that shows exactly wher= e > the issue arises, as there are different ways of doing 3PCC. > > > > Already at the early days of BUNDLE, we agreed that an initial offer will > NOT contain a shared address, because it is not backward compatible with > non-bundle aware endpoints. Some people (including e.g., myself and Culle= n) > were very keen on that. Instead we will use port zero + bundle-only for m= - > lines that are only be accepted if part of a BUNDLE group. I do not agree > to adding text to 8843bis saying there are cases where the specified > procedures for initial offers don=E2=80=99t apply, or don=E2=80=99t have = to be followed. > > > > Yes, we did add some 3PCC clarification text (which anyone could have > commented on) in 8843bis, but we did not change the procedures for initia= l > offers. > > > > Also keep in mind that the difference between an initial offer and a > subsequent offer is not related only the BUNDLE-related information. For > example, an initial offer must also contain unique ICE candidates in each > non-bundle-only m- line. > > > > My understanding of the text in 8829bis is that JSEP does NOT support (or= , > if we want to word it differently, is not able to detect) the 3PCC cases > referenced by Roman (again, call flows would have been nice), so a JSEP > endpoint will always send a subsequent offer according to the rules for > sending a subsequent offer. > > > > Regarding Roman=E2=80=99s suggested solutions #2 and #3, sending ALL bund= led m- > lines with port zero and bundle-only would be something completely new, a= s > there would be no offerer-tagged m- section. I don=E2=80=99t think that i= s a good > idea. We wither send an initial offer, using the procedures for initial > offers, or we send a subsequent offer, using the procedures for subsequen= t > offers. > > > > Regards, > > > > Christer > > > > > > *From:* rtcweb *On Behalf Of *Roman Shpount > *Sent:* lauantai 30. lokakuuta 2021 5.27 > *To:* Justin Uberti > *Cc:* Justin Uberti ; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > On Fri, Oct 29, 2021 at 6:49 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > > > > > > On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount wrote: > > On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > > > > As I am trying to explain, there is nothing in the offer that would > prevent the compliant implementation from moving the m=3D line out. This = is > not obvious but can cause grief. > > > > The problem is that it is not possible, as there is no other transport to > move the unbundled line to. As noted in the section you cite: > > > > "NOTE: One consequence of the rules above is that, once a BUNDLE group > has been negotiated, a bundled "m=3D" section cannot be moved out of the > BUNDLE group in an answer. Instead, an offer is needed.:" > > > > Generally, I think that if there is a shared address, that signifies that > a BUNDLE group has already been negotiated, even if that decision was mad= e > elsewhere. Perhaps a note should be added to bundle-bis to explicitly sta= te > this. > > > > When discussing bundle-bis the understanding was that it is generally > known when an offer is generated for 3pcc. Because of this, it was decide= d > that when the offer is generated for 3pcc it should be generated using th= e > same rules as the initial offer (i.e. with port zero and bundle-only). Th= is > was considered to be both backwards compatible with RBF 8843 and safe to > use as an initial offer for non-bundle aware, bundle, and bundle-bis > endpoints. For whatever reason, inspecting transport addresses was not > considered a valid mechanism to detect that m=3D lines are already bundle= d > and cannot be unbundled in the future. If we want to switch to inspecting > transport addresses when deciding which m=3D lines can be unbundled, this > deserves a lot more than a note in bundle-bis. > > > > This logic needs to be applied on subsequent offers already though, so I > don't understand why asking endpoints to also consider it on initial offe= rs > is an issue. Perhaps Christer could weigh in here. > > > > During the initial offer end point does not have already negotiated bundl= e > groups. Once the endpoint has already negotiated bundle groups, m=3D line= s > cannot be removed from them. > > > > I would still argue that a safe way to generate an offer for 3PCC is to d= o > SDP manipulation and set ports to 0 with attribute bundle-only. Everythin= g > else would not be compatible with either bundle-bis or RFC 8843. > > > > I am fine to include this as a consideration for non-BUNDLE endpoints but > it seems error-prone and unnecessary to do this for BUNDLE-aware endpoint= s. > > > > Your logic only works if bundle-aware endpoints were not allowed to remov= e > m=3D lines from a bundle group. Looking at the addresses to determine wha= t is > already grouped is insufficient, since an offer can also be an offer with > ice restart and trickle. No addresses will be present, so the endpoint wi= ll > have to look at ice parameters as well. This gets complicated and no one > wanted to describe this when 8843bis was written. This is why rfc > 8843bis specifies that subsequent offers for 3PCC should be valid initial > offers. > > > > There are, potentially, two solutions to this: > > > > 1. Change bundle so that endpoints are required to inspect initial offers > for transport addresses and ice parameters. Do not allow m=3D lines to be > removed from the bundle group if they share the transport address. This > would require pulling RFC 8843bis and writing the appropriate language. > > > > 2. Change JSEP note to specify that the application needs to make sure > that in case of 3PCC and remote endpoints either potentially removing m= =3D > lines from the bundle or not being bundle-aware, bundled m=3D lines need = to > be modified to have port 0 and bundle-only attribute. Considering that mo= st > bundle-aware endpoints do not remove m=3D lines from the bundle, this opt= ion > would cause the least amount of specification work. > > > > 3. If we want to completely avoid applications messing with SDP, change > JSEP to specify that when ice-restart is specified and a new offer is > generated, already bundled m=3D lines should be marked with port 0 and > bundle-only. This would also result in the least number of surprises for > developers. > > > > Best Regards, > > _____________ > Roman Shpount > > > --000000000000a03ac705cf9e1eb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Christer,

I can try to explain = the issue. If you need I can provide a more detailed call flow with SDP exa= mples but here is the basic scenario for nonw:

1. = 3PCC application requests an=C2=A0offer from client A.
2. Client = A generates an offer with audio, video, and data m=3D lines which are part = of a single bundle group. It does not matter for this case if they are bund= le-only or can be unbundled
3. Signaling application sends the of= fer received from client A to client B.
4. Client B supports bund= le so it generates an answer where all m=3D lines are bundled
5. = 3PCC sends the answer to Client A. At this point all m=3D lines are bundled= and cannot be unbundled.
6. 3PCC application requests another of= fer from client A within the same session. This offer is a subsequent offer= so it would have all 3 m=3D lines bundled.
7. 3PCC sends the gen= erated offer to client C.
8. Client C is generating an answer to = the offer it received. Client C is bundle aware but decides that it wants t= o unbundle data m=3D line. As far as Client C is concerned, there are no pr= e-negotiated bundle groups. If there are no=C2=A0bundle-only attributes on = m=3D lines, there is nothing stopping client C from unbundling.
<= br>
Per draft 8843 bis, SIP consideration section (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bi= s-05.html#name-sip-considerations), ofer in step 6 should be generated = as an initial offer, i.e. with port 0 and bundle-only in bundled=C2=A0m=3D = lines. This is done specifically to avoid problems in step 8.
What I am suggesting is not to always generate subsequent offer= s with port zero and bundle-only. I am suggesting only do this, when this o= ffer is intended for 3PCC. There is already a similar feature for ICE which= triggers ice restart for the offer which can be used for 3PCC. It can also= trigger generation of an offer with bundle-only for all bundled=C2=A0m=3D = lines. I would even be fine with webrtc endpoint not doing anything and add= ing a note to JSEP telling the 3PCC application to "fix" the offe= r and add m=3D port zero and bundle-only attributes when it is sending subs= equent offers as initial offers to a new end point.

In any case, the subsequent offer generated in step 6 is not a valid init= ial offer according to the bundle specification. We have two choices:
=

1. Make subsequent offers valid initial offers. This me= ans adding some language explaining how the endpoint processing=C2=A0initia= l offer can detect that m=3D lines cannot be unbundled. Even if we add this= language it will have backwards compatibility issues with anything that ha= s not implemented it.

2. Make endpoints generate s= ubsequent offers that are valid initial offers in 3PCC scenarios. This is w= hat draft 8843 bis does.

Please let me know if you= need more details.
_____________
Roman Shpount=


On Sat, Oct 30, 2021 at 6:44 PM Christer Holmberg <= ;christer.holmberg@ericss= on.com> wrote:

Hi,

=C2=A0

First, it would have been nice = to see a call-flow that shows exactly where the issue arises, as there are = different ways of doing 3PCC.

=C2=A0

Already at the early days of BU= NDLE, we agreed that an initial offer will NOT contain a shared address, be= cause it is not backward compatible with non-bundle aware endpoints. Some p= eople (including e.g., myself and Cullen) were very keen on that. Instead we wil= l use port zero + bundle-only for m- lines that are only be accepted if par= t of a BUNDLE group. I do not agree to adding text to 8843bis saying there = are cases where the specified procedures for initial offers don=E2=80=99t apply, or don=E2=80=99t have to be follow= ed.

=C2=A0

Yes, we did add some 3PCC clari= fication text =C2=A0(which anyone could have commented on) in 8843bis, but = we did not change the procedures for initial offers.

=C2=A0

Also keep in mind that the diff= erence between an initial offer and a subsequent offer is not related only = the BUNDLE-related information. For example, an initial offer must also con= tain unique ICE candidates in each non-bundle-only m- line.

=C2=A0

My understanding of the text in= 8829bis is that JSEP does NOT support (or, if we want to word it different= ly, is not able to detect) the 3PCC cases referenced by Roman (again, call = flows would have been nice), so a JSEP endpoint will always send a subsequent of= fer according to the rules for sending a subsequent offer.

=C2=A0

Regarding Roman=E2=80=99s sugge= sted solutions #2 and #3, sending ALL bundled m- lines with port zero and b= undle-only would be something completely new, as there would be no offerer-= tagged m- section. I don=E2=80=99t think that is a good idea. We wither send an init= ial offer, using the procedures for initial offers, or we send a subsequent= offer, using the procedures for subsequent offers.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: rtcweb <rtcweb-bounces@ietf.org> On Behalf Of Roman Shpount
Sent: lauantai 30. lokakuuta 2021 5.27
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Justin Uberti <justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

=C2=A0

On Fri, Oct 29, 2021 at 6:49 PM Justin Uberti <juberti@a= lphaexplorationco.com> wrote:

=C2=A0

=C2=A0

On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <roman@telurix.com&= gt; wrote:

On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti <juberti@a= lphaexplorationco.com> wrote:

=C2=A0

As I am trying to explain, there is nothing in the o= ffer that would prevent=C2=A0the=C2=A0compliant=C2=A0implementation from mo= ving the=C2=A0m=3D line out. This is not obvious but can cause grief.

=C2=A0

The problem is that it is not possible, as there is = no other transport to move the unbundled line to. As noted in the section y= ou cite:

=C2=A0

=C2=A0"NOTE: One consequence of the rules ab= ove is that, once a BUNDLE group has been negotiated, a bundled "m=3D&= quot; section cannot be moved out of the BUNDLE group in an answer. Instead, an offer is needed.:"

=C2=A0

Generally, I think that if there is a shared address= , that signifies that a BUNDLE group has already been negotiated, even if t= hat decision was made elsewhere. Perhaps a note should be added to bundle-b= is to explicitly state this.

=C2=A0

When discussing bundle-bis the understanding=C2=A0wa= s that it is generally known when an offer is generated for 3pcc. Because o= f this, it was decided that when the offer is generated for 3pcc it should = be generated using the same rules as the initial offer (i.e. with port zero and bundle-only). This was considered t= o be both backwards compatible with RBF 8843 and safe to use as an initial = offer for non-bundle=C2=A0aware, bundle, and bundle-bis endpoints. For what= ever reason, inspecting transport addresses was not considered a valid mechanism to detect that m=3D lines are already= bundled and cannot be unbundled in the future. If we want to switch to ins= pecting transport addresses when deciding which m=3D lines can be unbundled= , this deserves a lot more than a note in bundle-bis.

=C2=A0

This logic needs to be applied on subsequent offers = already though, so I don't understand why asking endpoints to also cons= ider it on initial offers is an issue. Perhaps Christer could weigh in here= .=C2=A0

=C2=A0

During the initial offer end point does not have alr= eady negotiated bundle groups. Once the endpoint has already negotiated bun= dle groups, m=3D lines cannot be removed from them.

=C2=A0

I would still argue that a safe way to generate an o= ffer for 3PCC is to do SDP manipulation and set ports to 0 with attribute b= undle-only. Everything else would not be compatible with either bundle-bis = or RFC 8843.

=C2=A0

I am fine to include this as a consideration for non= -BUNDLE endpoints but it seems error-prone and unnecessary to do this for B= UNDLE-aware endpoints.=C2=A0

=C2=A0

Your logic only works if bundle-aware endpoints were= not allowed to remove m=3D lines from a bundle group. Looking at the addre= sses to determine what is already grouped is insufficient, since an offer c= an also be an offer with ice restart and trickle. No addresses will be present, so the endpoint will have to lo= ok at ice parameters as well. This gets complicated and no one wanted to de= scribe this when 8843bis=C2=A0was written.=C2=A0 This is why rfc 8843bis=C2= =A0specifies that subsequent offers for 3PCC should be valid initial offers.

=C2=A0

There are, potentially, two solutions to this:

=C2=A0

1. Change bundle so that endpoints are required to i= nspect initial=C2=A0offers for transport addresses and ice parameters. Do n= ot allow m=3D lines to be removed from the bundle group if they share the t= ransport address. This would require pulling RFC 8843bis and writing the appropriate language.

=C2=A0

2. Change JSEP note to specify that the application = needs to make sure that in case of 3PCC and remote endpoints either potenti= ally removing m=3D lines from the bundle or not being bundle-aware, bundled= m=3D lines need to be modified to have port 0 and bundle-only attribute. Considering that most bundle-aware endpo= ints do not remove m=3D lines from the bundle, this option would cause the = least amount of specification work.

=C2=A0

3. If we want to completely avoid applications messi= ng with SDP, change JSEP to specify that when ice-restart is specified and = a new offer is generated, already bundled m=3D lines should be marked with = port 0 and bundle-only. This would also result in the least number of surprises for developers.

=C2=A0

Best Regards,

_____________
Roman Shpount

=C2=A0

--000000000000a03ac705cf9e1eb7-- From nobody Sun Oct 31 04:46:48 2021 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 0A4F43A07F4 for ; Sun, 31 Oct 2021 04:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzNINZkgKu-A for ; Sun, 31 Oct 2021 04:46:40 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40047.outbound.protection.outlook.com [40.107.4.47]) (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 351413A07CC for ; Sun, 31 Oct 2021 04:46:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CQTCZx1OwZXx6YwZ9+DVZOp6KBElRY5TQeh1/3L6uml1vF48j1AF31bZYC92jNfbH7APwjf7Wzc6Qt8DzVCef+QzFGj5KhSVyU7pyhYbXznYCdadXwtCiKO2lPZOzHtC6OfiBAm8fR+jkzd+ThZNbihy1o6Hoh4bQECQhz2gY8fcIQ+kviSygI3qC/iZNUNAevtQhnAzBds66iULpRccByZnj91oSuSmtqHdLVB4MWAp/TBMQ85mDQBS/n7fpQUitC3xr35ZmKkDKW2p8Las6tk5YMyboJqXTAWvp+alduHpTe/WK3Y1nUWsoxEwSZDrj0e66cONwzRKhkSTnGpysw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=VJYvEOlYEanplWJ3Tow5EfV6jpMw1eXUGFEEyEYT5ck=; b=J3Tc+TUTqg1pOEQmwkEedsyCLP8W1UMH1xIQasFmbAE5//Nmfc4BXVwRRIZo4NGjhYvZxR6K6zO0SuOnPCBMUQGMBfplIizMaQDDlSHx6NfG9B+kxuG4hAwPq3xvjTJY3uxlp1jxAF7fdT6D5IIawNvVpM4cjZ9Zq4d+IA4mUEJ/MZXISejIWXZ7ER5oJSPgSfMhBDWfW1BwGcKvs20nvV5skdhXpQthtQS3cEAPuno/mbpIszqWbH0L62eKXeY30xQmaRaUVelsYx6n3VRJ3S8JrCgL9pa9dkMCcR8uyug1rBabQwKoy7zHOg3fG2lV2yQJeLGCDx4kMm2WxbdzRg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VJYvEOlYEanplWJ3Tow5EfV6jpMw1eXUGFEEyEYT5ck=; b=Zlp1qdvyi96FrqQECMdIXRriBs+2xwgGN6Jk+LbDPtPUnmE1JmmnMDG2Asxq09kg0uHF8GBFOa19lvP1fpcoRAfiXZ7pPSQIx1tR3mZF1jCyeMmyQjmh1Ul2B1LJCWIhf1VRctjjDk7cl6x3K3UzqirMw8Wk3OyLeS5Zg4cf5Uo= Received: from HE1PR07MB4441.eurprd07.prod.outlook.com (2603:10a6:7:9f::27) by HE1PR07MB4380.eurprd07.prod.outlook.com (2603:10a6:7:9a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4669.4; Sun, 31 Oct 2021 11:46:32 +0000 Received: from HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173]) by HE1PR07MB4441.eurprd07.prod.outlook.com ([fe80::44b6:1bcd:7be6:b173%2]) with mapi id 15.20.4669.009; Sun, 31 Oct 2021 11:46:32 +0000 From: Christer Holmberg To: Roman Shpount CC: Justin Uberti , Justin Uberti , RTCWeb IETF Thread-Topic: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt Thread-Index: AQHXylf+AMpeemP+/Umn4mKjUNsZYKvlgWaAgAAD7wCAAFFxgIAEazaAgAAJNoCAAAJcgIAARq+AgAAFWYCAAD0AgIABPVtQgABvX4CAAHTpwA== Date: Sun, 31 Oct 2021 11:46:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ericsson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29ff3119-360e-4c29-7650-08d99c64157a x-ms-traffictypediagnostic: HE1PR07MB4380: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6B++g/O/+mgzXJ8rRaOWoya9NiyG22TYnoC5+skDGrl4tjqFQ8j4ggUyzGlGMp09iL308x/8DWS7q/Pbmca4P4AqL+peAp/gkZyMghir2XL1Ysf731ilgf7PvKTEgO+XMElUPS1tC4K31kKauAROrKGT1RR95HJ1CvOzBUbR80BbkU4fnV/+v8EnkP8A0g2Gh37FQ+OLWp1rOJM63xkG6Ds+VjA2ltp3aSqVe72wEoKxHhZR2gnlT0GO8m3PNqSPACsEM4w2uNIdl5y9V9UpMjX/yrT7zLSuYOegTzrGDrv3TvBXlvY0B4pzSP15mQa875CCXo/E+PZW/YiG3taSkbvzWIqZ0sByYJY6jJCN5I1+DZxF/DN5OS5dEly5iSQxgfhZ9Gq6Pnw/IkopQf5/ZA3uz1TPzCxK9wQH+k4FzvoVT1fbVncn9hzHBg0awyJMCZPIuI0cYLcyBMSV7SV278AnTWyUGIz0hkZ394PiR8/bQ/xrXmvDk0iFuJ/ie2FWoeCN8u+oeX87qauOnww/YepRWXcknJIdpvnYWfNPXuCGuWZli9j4ct60MS6ygnpb8M2vPLr0N2qgpeBFd+kYIrswSJZzonSGTHGcHfBLF4ksJM3sosaduFNof8NUT3qc98bOaRkSKa2s3LILYlAdwfMZDWMQIDZaoYQN3aIPGPFobg/kxdMWF2l3jF20cAr0gpMmGZkNq29tV4m5hSkh75TDDJASE3VEn3Rf05yX4y6aHY+5BBCXkAXxOS4HdfWdIldsVWpLzd9fIl3T3DfwLGRagfQ+82/F2pOCtTW/jhg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4441.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(38100700002)(71200400001)(52536014)(76116006)(186003)(44832011)(122000001)(8676002)(8936002)(30864003)(26005)(66446008)(33656002)(64756008)(66476007)(66946007)(66556008)(6506007)(5660300002)(54906003)(316002)(53546011)(166002)(82960400001)(83380400001)(508600001)(9686003)(55016002)(86362001)(6916009)(4326008)(7696005)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Sm5DR0h0RnkzMXJVNUZXZmhIeG81eGNoeVJFaDJFVkdIaXEyWkNjeWF6eDdD?= =?utf-8?B?UHVJTVp3WHdjYndSNEZ3dk5mTHFobk42bUxBVCs5QURQY1pkRVhlRFhLMEkr?= =?utf-8?B?YzZiVFBQZlBnM3ZEUlRvcysrUjUyMkhQc0pheFVQbXZKNlErZXhMdU4rck1H?= =?utf-8?B?S1dqQ1ovRUpaM0pwajYxRHJtNldsNjBwSXNQOWRBMUJyWGsyT0wxL1VXRkh6?= =?utf-8?B?YVZsUlBsajdtc0h4RGh6ZVVxT013OXlkM2JQKzY4SGx5aGxOSnBhMGhKZnY5?= =?utf-8?B?VlVWQXg0SGhvSExmemI3aUNPTm5oSEdDbDZxR2l5a2ovNEg5ZVZ1dEFyMjBi?= =?utf-8?B?aGxTU1RrVURZckhPQWplc082K1dTQk91b3Q1VDBCWjVKM2FVeGMyQkFqRWFN?= =?utf-8?B?cVZTcWR3VHllSkVmaGxUR2hFbG0wNUN4VVVtZElpQ2F5OE43MTYzNEM1cHBp?= =?utf-8?B?YyswMHBVbjNROHdsNUhMcVNCZFo0Uis2OTN6cldpaHpvSGNMOEtCMWFLVkRO?= =?utf-8?B?SGtMRGxPNFNrMmJJYnVYZkRNbFpBSVVCU01ucTVuUFFmLzhGbnF5dWxiWUQx?= =?utf-8?B?QmxkU2Zjb2wveVZrUDMxWTZZd1pHaEtRcStyRlFubW84WlI3K2EzRUZlcWdH?= =?utf-8?B?WkMvcnlydjJsd0ZCNmlzdURPZDAvM3hMTnVMREc4ODJxNFhZQ2R0b3YrcEk0?= =?utf-8?B?VG5HLzJxdnZUbC84bXQvcnFjQnB5NGp1eG1rdTlpZFdyODZEak1FMkFKVnRz?= =?utf-8?B?WHJ3NDg2L2pyYTMzRTRYajdPdERkNS90OG9yeWU3M1lZeEFXdXJnV2MxOU05?= =?utf-8?B?akhhcEZscGNEMGI4UWR1SzBCZmhhVXpyV2hNaHZIRDFwRG50bW9hdDhUUjRC?= =?utf-8?B?SVNkYkE2S1BkclgrU0JPVjcvZnA4anBkT0d4eFJwN0FydWE2M0YvWmFhaW51?= =?utf-8?B?MTZCYjVGUGRPc2tKMDU5eitBemZRaHkwbFV4YzdBWGRWOTlSV3dhMGhaVXV1?= =?utf-8?B?ckZVanEram01TEkwckZNNVF5V20vdWdGQTFVbDgwdlQrc3hFK3ZZNVhPdlVH?= =?utf-8?B?VUE4TXhIb2loZjBmMS9uWElNU2pTSGpBRFNIODZGWHFyazh1bXRMU0JBWTBn?= =?utf-8?B?SmtrQ3J2K3JpVjJGYlVCSndEcjc4VTlzUjMwRGVuY1JrRy9MeUFoU1NkYVpU?= =?utf-8?B?OVRibGFKejVZQ2Y0OTF0L2FMVys2Z3Nqd05ueVBaTTdJNEl1SlMyaDdiMG9D?= =?utf-8?B?SitwVFVndjA5c0ZnOVp0M2VoWFdDUDcwaDI2dlZNQUwrQkZnMmk3WEd2S3Fj?= =?utf-8?B?TUNpUjV5OWpaL3FncGFDU2VPbXJ3SmtQUTI2bEtwRzJXZmV1N1hMMFM0cHIw?= =?utf-8?B?MGJ2S0s1T1ErU0JsUkRLV0NxNTU0VDNRcXVBS1NLNVFCQ2pKWlhHQ2EySFRV?= =?utf-8?B?TWVGSkNtNG1UUmFTTDNKUUpsdUtKaG13YW5YeUJIcnp2eWtFUHoxM005TFdk?= =?utf-8?B?dXB0UjAwelNZZ29FK2FIYWczQkl6U3FPLytEbGZJbUR0QVFVOCtROFpTaG9t?= =?utf-8?B?dTc1OWlBL3dPVGVsTGZtemNkOGliMGJnV216NWxFbGQ4aDdhRTNsM3JOVUpC?= =?utf-8?B?N0l3TnI3MEQ0bGVkb2l1MmRQRCsvYTB4WmF4NVdLR2ZlRENUSjdsMTRjQ1hV?= =?utf-8?B?ZFo2bjZ1dXhPdDh5cENUR0NjejlIU0RiUkZpeDFxMXNZT3RXSjlOeWZ2TU5Y?= =?utf-8?B?OEY1ZlhWKzJlS3RSK2FBUVBxbE9CeVllNERweTNCbDgyZFo1bHpUS25vT2pt?= =?utf-8?B?NmF0UXdzRjY4ZDE1ZG9BZXJvdG12NmdNeTczZGRzN0c3eXQ0aTJ4ODBKWTl5?= =?utf-8?B?YTRwNzdlUm41bWFiTHdPVm9SV0NrTExERHNVM0FKUTRDaStmWWs1MEZuSkZy?= =?utf-8?B?VnhMVWNZVUVOOGpReW9QZm1DbVlKaTdsQWtScEZNZ1VQRUhWc0EzWWkwd3FG?= =?utf-8?B?c1V4Unl3QlRYKzgyNnp4TkR2aG9ud2JpSnJPbFcyU1E2OXI1bGpuTm1EcThu?= =?utf-8?B?VjNLY1NVbDJYME43T21pT0hnbXM3Wm5FWHBHeEVkMW1MeUp5WnEzNjloVW5I?= =?utf-8?B?aDhoOFAyUTBSNEF2My85S00xN1FkN2NGK1hWUnBjOGY5U3NCQ3VwM3VKak9U?= =?utf-8?B?Mzgvd1VhTno3RTNpVkRkTFVzTjdDblpIdUg5SDBmNlVQblhYYlhCcHlydStT?= =?utf-8?B?TzdnVWNNNFhzYXVzWXFkTVFGVS9RPT0=?= Content-Type: multipart/alternative; boundary="_000_HE1PR07MB4441051506F5A2E16A2C902993899HE1PR07MB4441eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4441.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29ff3119-360e-4c29-7650-08d99c64157a X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Oct 2021 11:46:31.9066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 7I2nFtCbLIeCf+x0hoLMuwkHbgcGM0/B17JXh2SsqAAM1q109jsg4y8/6bKRfJoqnCXokCKmN3N0rR6abbXleE0NHyY8W2j5e+LDoyoIFfU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4380 Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 31 Oct 2021 11:46:46 -0000 --_000_HE1PR07MB4441051506F5A2E16A2C902993899HE1PR07MB4441eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNClRoYW5rIHlvdSBmb3IgdGhlIGNsYXJpZmljYXRpb25zIQ0KDQpJIHRoaW5r IHRoZSDigJxnZW5lcmF0aW5nIGEgc3Vic2VxdWVudCBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVy 4oCdIHdvcmRpbmcgY291bGQgYmUgY29uZnVzaW5nIHRvIHBlb3BsZS4gSSB3b3VsZCBzYXkgc29t ZXRoaW5nIGxpa2Ug4oCcZ2VuZXJhdGluZyBhIG5ldyBpbml0aWFsIG9mZmVyIHdpdGhpbiBhIHNl c3Npb27igJ0sIG9yIHNvbWV0aGluZ+KApiBIb3dldmVyLCBhcyBmYXIgYXMgdGhlIGlzc3VlcyBp dHNlbGYgaXMgY29uY2VybmVkLCB0aGF0IGlzIG5vdCByZWxldmFudCDigJMgYXMgbG9uZyBhcyB3 ZSBrbm93IHdoYXQgd2UgYXJlIHRhbGtpbmcgYWJvdXQgOikNCg0KPjEuIE1ha2Ugc3Vic2VxdWVu dCBvZmZlcnMgdmFsaWQgaW5pdGlhbCBvZmZlcnMuIFRoaXMgbWVhbnMgYWRkaW5nIHNvbWUgbGFu Z3VhZ2UgZXhwbGFpbmluZyBob3cgdGhlIGVuZHBvaW50IHByb2Nlc3NpbmcgaW5pdGlhbCBvZmZl ciBjYW4gZGV0ZWN0IHRoYXQgbT0gbGluZXMgY2Fubm90IGJlIHVuYnVuZGxlZC4gRXZlbiBpZiB3 ZSBhZGQgdGhpcyBsYW5ndWFnZSBpdCB3aWxsIGhhdmUgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkg aXNzdWVzIHdpdGggYW55dGhpbmcgdGhhdCBoYXMgbm90IGltcGxlbWVudGVkIGl0Lg0KDQpJIGRv buKAmXQgYWdyZWUgd2l0aCB0aGF0IHN1Z2dlc3Rpb24uIEJlY2F1c2UsIGluIHRoYXQgY2FzZSB3 ZSBjb3VsZCBoYXZlIGRvbmUgaXQgZnJvbSB0aGUgYmVnaW5uaW5nLCBhcyBhIGdlbmVyYWwgcnVs ZSwgd2l0aG91dCB1c2luZyBwb3J0IHplcm8uIEJ1dCB0aGVyZSB3ZXJlIHJlYXNvbiB3ZSBjaG9z ZSBub3QgdG8gYWxsb3cgc2hhcmVkIGFkZHJlc3NlcyAod2l0aCBub24temVybyBwb3J0IHZhbHVl cykgaW4gaW5pdGlhbCBvZmZlcnMuDQoNCj4yLiBNYWtlIGVuZHBvaW50cyBnZW5lcmF0ZSBzdWJz ZXF1ZW50IG9mZmVycyB0aGF0IGFyZSB2YWxpZCBpbml0aWFsIG9mZmVycyBpbiAzUENDIHNjZW5h cmlvcy4gVGhpcyBpcyB3aGF0IGRyYWZ0IDg4NDMgYmlzIGRvZXMuDQoNCkNvcnJlY3QuDQoNCkhv d2V2ZXIsIGtlZXAgaW4gbWluZCB0aGF0IGl0IGlzIG5vdCBvbmx5IGFib3V0IGhvdyB0byBlbmNv ZGUgdGhlIHBvcnQgbnVtYmVycyBhbmQgYnVuZGxlLW9ubHkgYXR0cmlidXRlcy4gU2VuZGluZyBh biBpbml0aWFsIG9mZmVyIGFsc28gY29tZXMgd2l0aCBhIHNldCBvZiBwcm9jZWR1cmVzLiBTb21l IG9mIHRob3NlIChlLmcuLCBJQ0UpICBJIGFzc3VtZSB5b3Ugd2lsbCBoYXZlIHRvIGRvIGFueXdh eSwgYXMgdGhlIHJlbW90ZSBlbmRwb2ludCBjaGFuZ2VzLg0KDQo+SSB3b3VsZCBldmVuIGJlIGZp bmUgd2l0aCB3ZWJydGMgZW5kcG9pbnQgbm90IGRvaW5nIGFueXRoaW5nIGFuZCBhZGRpbmcgYSBu b3RlIHRvIEpTRVAgdGVsbGluZyB0aGUgM1BDQyBhcHBsaWNhdGlvbiB0byAiZml4IiB0aGUgb2Zm ZXIgYW5kIGFkZCBtPSBwb3J0IHplcm8gYW5kIGJ1bmRsZS1vbmx5IGF0dHJpYnV0ZXMgd2hlbiBp dCBpcyBzZW5kaW5nIHN1YnNlcXVlbnQgb2ZmZXJzIGFzIGluaXRpYWwgb2ZmZXJzIHRvIGEgbmV3 IGVuZCBwb2ludC4NCg0KSSB3b3VsZCBiZSBmaW5lIGFkZGluZyBzdWNoIHRleHQgdG8gSlNFUC4g SXQgY291bGQgYmUgYW4gYWRkaXRpb25hbCBzZW50ZW5jZSB0byB0aGUgZXhpc3RpbmcgdGV4dC4N Cg0KKEhvd2V2ZXIsIEkgc3RpbGwgd291bGQgbm90IHNheSDigJxzZW5kaW5nIHN1YnNlcXVlbnQg b2ZmZXJzIGFzIGluaXRpYWwgb2ZmZXJz4oCdLiBJIHdvdWxkIHNheSDigJxjcmVhdGUgYW5kIHNl bmQgYW4gaW5pdGlhbCBvZmZlciBiYXNlZCBvbiBhIHJlY2VpdmVkIHN1YnNlcXVlbnQgb2ZmZXLi gJ0sIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuKQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoN Cg0KDQoNCg0KDQpGcm9tOiBSb21hbiBTaHBvdW50IDxyb21hbkB0ZWx1cml4LmNvbT4NClNlbnQ6 IHN1bm51bnRhaSAzMS4gbG9rYWt1dXRhIDIwMjEgNi4wMg0KVG86IENocmlzdGVyIEhvbG1iZXJn IDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogSnVzdGluIFViZXJ0aSA8anVi ZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPjsgSnVzdGluIFViZXJ0aSA8anVzdGluQHViZXJ0 aS5uYW1lPjsgUlRDV2ViIElFVEYgPHJ0Y3dlYkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcnRj d2ViXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtdWJlcnRpLXJ0Y3dlYi1yZmM4 ODI5YmlzLTAxLnR4dA0KDQpIaSBDaHJpc3RlciwNCg0KSSBjYW4gdHJ5IHRvIGV4cGxhaW4gdGhl IGlzc3VlLiBJZiB5b3UgbmVlZCBJIGNhbiBwcm92aWRlIGEgbW9yZSBkZXRhaWxlZCBjYWxsIGZs b3cgd2l0aCBTRFAgZXhhbXBsZXMgYnV0IGhlcmUgaXMgdGhlIGJhc2ljIHNjZW5hcmlvIGZvciBu b253Og0KDQoxLiAzUENDIGFwcGxpY2F0aW9uIHJlcXVlc3RzIGFuIG9mZmVyIGZyb20gY2xpZW50 IEEuDQoyLiBDbGllbnQgQSBnZW5lcmF0ZXMgYW4gb2ZmZXIgd2l0aCBhdWRpbywgdmlkZW8sIGFu ZCBkYXRhIG09IGxpbmVzIHdoaWNoIGFyZSBwYXJ0IG9mIGEgc2luZ2xlIGJ1bmRsZSBncm91cC4g SXQgZG9lcyBub3QgbWF0dGVyIGZvciB0aGlzIGNhc2UgaWYgdGhleSBhcmUgYnVuZGxlLW9ubHkg b3IgY2FuIGJlIHVuYnVuZGxlZA0KMy4gU2lnbmFsaW5nIGFwcGxpY2F0aW9uIHNlbmRzIHRoZSBv ZmZlciByZWNlaXZlZCBmcm9tIGNsaWVudCBBIHRvIGNsaWVudCBCLg0KNC4gQ2xpZW50IEIgc3Vw cG9ydHMgYnVuZGxlIHNvIGl0IGdlbmVyYXRlcyBhbiBhbnN3ZXIgd2hlcmUgYWxsIG09IGxpbmVz IGFyZSBidW5kbGVkDQo1LiAzUENDIHNlbmRzIHRoZSBhbnN3ZXIgdG8gQ2xpZW50IEEuIEF0IHRo aXMgcG9pbnQgYWxsIG09IGxpbmVzIGFyZSBidW5kbGVkIGFuZCBjYW5ub3QgYmUgdW5idW5kbGVk Lg0KNi4gM1BDQyBhcHBsaWNhdGlvbiByZXF1ZXN0cyBhbm90aGVyIG9mZmVyIGZyb20gY2xpZW50 IEEgd2l0aGluIHRoZSBzYW1lIHNlc3Npb24uIFRoaXMgb2ZmZXIgaXMgYSBzdWJzZXF1ZW50IG9m ZmVyIHNvIGl0IHdvdWxkIGhhdmUgYWxsIDMgbT0gbGluZXMgYnVuZGxlZC4NCjcuIDNQQ0Mgc2Vu ZHMgdGhlIGdlbmVyYXRlZCBvZmZlciB0byBjbGllbnQgQy4NCjguIENsaWVudCBDIGlzIGdlbmVy YXRpbmcgYW4gYW5zd2VyIHRvIHRoZSBvZmZlciBpdCByZWNlaXZlZC4gQ2xpZW50IEMgaXMgYnVu ZGxlIGF3YXJlIGJ1dCBkZWNpZGVzIHRoYXQgaXQgd2FudHMgdG8gdW5idW5kbGUgZGF0YSBtPSBs aW5lLiBBcyBmYXIgYXMgQ2xpZW50IEMgaXMgY29uY2VybmVkLCB0aGVyZSBhcmUgbm8gcHJlLW5l Z290aWF0ZWQgYnVuZGxlIGdyb3Vwcy4gSWYgdGhlcmUgYXJlIG5vIGJ1bmRsZS1vbmx5IGF0dHJp YnV0ZXMgb24gbT0gbGluZXMsIHRoZXJlIGlzIG5vdGhpbmcgc3RvcHBpbmcgY2xpZW50IEMgZnJv bSB1bmJ1bmRsaW5nLg0KDQpQZXIgZHJhZnQgODg0MyBiaXMsIFNJUCBjb25zaWRlcmF0aW9uIHNl Y3Rpb24gKGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1tbXVzaWMt cmZjODg0M2Jpcy0wNS5odG1sI25hbWUtc2lwLWNvbnNpZGVyYXRpb25zKSwgb2ZlciBpbiBzdGVw IDYgc2hvdWxkIGJlIGdlbmVyYXRlZCBhcyBhbiBpbml0aWFsIG9mZmVyLCBpLmUuIHdpdGggcG9y dCAwIGFuZCBidW5kbGUtb25seSBpbiBidW5kbGVkIG09IGxpbmVzLiBUaGlzIGlzIGRvbmUgc3Bl Y2lmaWNhbGx5IHRvIGF2b2lkIHByb2JsZW1zIGluIHN0ZXAgOC4NCg0KV2hhdCBJIGFtIHN1Z2dl c3RpbmcgaXMgbm90IHRvIGFsd2F5cyBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVycyB3aXRoIHBv cnQgemVybyBhbmQgYnVuZGxlLW9ubHkuIEkgYW0gc3VnZ2VzdGluZyBvbmx5IGRvIHRoaXMsIHdo ZW4gdGhpcyBvZmZlciBpcyBpbnRlbmRlZCBmb3IgM1BDQy4gVGhlcmUgaXMgYWxyZWFkeSBhIHNp bWlsYXIgZmVhdHVyZSBmb3IgSUNFIHdoaWNoIHRyaWdnZXJzIGljZSByZXN0YXJ0IGZvciB0aGUg b2ZmZXIgd2hpY2ggY2FuIGJlIHVzZWQgZm9yIDNQQ0MuIEl0IGNhbiBhbHNvIHRyaWdnZXIgZ2Vu ZXJhdGlvbiBvZiBhbiBvZmZlciB3aXRoIGJ1bmRsZS1vbmx5IGZvciBhbGwgYnVuZGxlZCBtPSBs aW5lcy4gSSB3b3VsZCBldmVuIGJlIGZpbmUgd2l0aCB3ZWJydGMgZW5kcG9pbnQgbm90IGRvaW5n IGFueXRoaW5nIGFuZCBhZGRpbmcgYSBub3RlIHRvIEpTRVAgdGVsbGluZyB0aGUgM1BDQyBhcHBs aWNhdGlvbiB0byAiZml4IiB0aGUgb2ZmZXIgYW5kIGFkZCBtPSBwb3J0IHplcm8gYW5kIGJ1bmRs ZS1vbmx5IGF0dHJpYnV0ZXMgd2hlbiBpdCBpcyBzZW5kaW5nIHN1YnNlcXVlbnQgb2ZmZXJzIGFz IGluaXRpYWwgb2ZmZXJzIHRvIGEgbmV3IGVuZCBwb2ludC4NCg0KSW4gYW55IGNhc2UsIHRoZSBz dWJzZXF1ZW50IG9mZmVyIGdlbmVyYXRlZCBpbiBzdGVwIDYgaXMgbm90IGEgdmFsaWQgaW5pdGlh bCBvZmZlciBhY2NvcmRpbmcgdG8gdGhlIGJ1bmRsZSBzcGVjaWZpY2F0aW9uLiBXZSBoYXZlIHR3 byBjaG9pY2VzOg0KDQoxLiBNYWtlIHN1YnNlcXVlbnQgb2ZmZXJzIHZhbGlkIGluaXRpYWwgb2Zm ZXJzLiBUaGlzIG1lYW5zIGFkZGluZyBzb21lIGxhbmd1YWdlIGV4cGxhaW5pbmcgaG93IHRoZSBl bmRwb2ludCBwcm9jZXNzaW5nIGluaXRpYWwgb2ZmZXIgY2FuIGRldGVjdCB0aGF0IG09IGxpbmVz IGNhbm5vdCBiZSB1bmJ1bmRsZWQuIEV2ZW4gaWYgd2UgYWRkIHRoaXMgbGFuZ3VhZ2UgaXQgd2ls bCBoYXZlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGlzc3VlcyB3aXRoIGFueXRoaW5nIHRoYXQg aGFzIG5vdCBpbXBsZW1lbnRlZCBpdC4NCg0KMi4gTWFrZSBlbmRwb2ludHMgZ2VuZXJhdGUgc3Vi c2VxdWVudCBvZmZlcnMgdGhhdCBhcmUgdmFsaWQgaW5pdGlhbCBvZmZlcnMgaW4gM1BDQyBzY2Vu YXJpb3MuIFRoaXMgaXMgd2hhdCBkcmFmdCA4ODQzIGJpcyBkb2VzLg0KDQpQbGVhc2UgbGV0IG1l IGtub3cgaWYgeW91IG5lZWQgbW9yZSBkZXRhaWxzLg0KX19fX19fX19fX19fXw0KUm9tYW4gU2hw b3VudA0KDQoNCk9uIFNhdCwgT2N0IDMwLCAyMDIxIGF0IDY6NDQgUE0gQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpIaSwNCg0KRmlyc3QsIGl0IHdvdWxkIGhhdmUgYmVl biBuaWNlIHRvIHNlZSBhIGNhbGwtZmxvdyB0aGF0IHNob3dzIGV4YWN0bHkgd2hlcmUgdGhlIGlz c3VlIGFyaXNlcywgYXMgdGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIG9mIGRvaW5nIDNQQ0MuDQoN CkFscmVhZHkgYXQgdGhlIGVhcmx5IGRheXMgb2YgQlVORExFLCB3ZSBhZ3JlZWQgdGhhdCBhbiBp bml0aWFsIG9mZmVyIHdpbGwgTk9UIGNvbnRhaW4gYSBzaGFyZWQgYWRkcmVzcywgYmVjYXVzZSBp dCBpcyBub3QgYmFja3dhcmQgY29tcGF0aWJsZSB3aXRoIG5vbi1idW5kbGUgYXdhcmUgZW5kcG9p bnRzLiBTb21lIHBlb3BsZSAoaW5jbHVkaW5nIGUuZy4sIG15c2VsZiBhbmQgQ3VsbGVuKSB3ZXJl IHZlcnkga2VlbiBvbiB0aGF0LiBJbnN0ZWFkIHdlIHdpbGwgdXNlIHBvcnQgemVybyArIGJ1bmRs ZS1vbmx5IGZvciBtLSBsaW5lcyB0aGF0IGFyZSBvbmx5IGJlIGFjY2VwdGVkIGlmIHBhcnQgb2Yg YSBCVU5ETEUgZ3JvdXAuIEkgZG8gbm90IGFncmVlIHRvIGFkZGluZyB0ZXh0IHRvIDg4NDNiaXMg c2F5aW5nIHRoZXJlIGFyZSBjYXNlcyB3aGVyZSB0aGUgc3BlY2lmaWVkIHByb2NlZHVyZXMgZm9y IGluaXRpYWwgb2ZmZXJzIGRvbuKAmXQgYXBwbHksIG9yIGRvbuKAmXQgaGF2ZSB0byBiZSBmb2xs b3dlZC4NCg0KWWVzLCB3ZSBkaWQgYWRkIHNvbWUgM1BDQyBjbGFyaWZpY2F0aW9uIHRleHQgICh3 aGljaCBhbnlvbmUgY291bGQgaGF2ZSBjb21tZW50ZWQgb24pIGluIDg4NDNiaXMsIGJ1dCB3ZSBk aWQgbm90IGNoYW5nZSB0aGUgcHJvY2VkdXJlcyBmb3IgaW5pdGlhbCBvZmZlcnMuDQoNCkFsc28g a2VlcCBpbiBtaW5kIHRoYXQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBhbiBpbml0aWFsIG9mZmVy IGFuZCBhIHN1YnNlcXVlbnQgb2ZmZXIgaXMgbm90IHJlbGF0ZWQgb25seSB0aGUgQlVORExFLXJl bGF0ZWQgaW5mb3JtYXRpb24uIEZvciBleGFtcGxlLCBhbiBpbml0aWFsIG9mZmVyIG11c3QgYWxz byBjb250YWluIHVuaXF1ZSBJQ0UgY2FuZGlkYXRlcyBpbiBlYWNoIG5vbi1idW5kbGUtb25seSBt LSBsaW5lLg0KDQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0ZXh0IGluIDg4MjliaXMgaXMgdGhh dCBKU0VQIGRvZXMgTk9UIHN1cHBvcnQgKG9yLCBpZiB3ZSB3YW50IHRvIHdvcmQgaXQgZGlmZmVy ZW50bHksIGlzIG5vdCBhYmxlIHRvIGRldGVjdCkgdGhlIDNQQ0MgY2FzZXMgcmVmZXJlbmNlZCBi eSBSb21hbiAoYWdhaW4sIGNhbGwgZmxvd3Mgd291bGQgaGF2ZSBiZWVuIG5pY2UpLCBzbyBhIEpT RVAgZW5kcG9pbnQgd2lsbCBhbHdheXMgc2VuZCBhIHN1YnNlcXVlbnQgb2ZmZXIgYWNjb3JkaW5n IHRvIHRoZSBydWxlcyBmb3Igc2VuZGluZyBhIHN1YnNlcXVlbnQgb2ZmZXIuDQoNClJlZ2FyZGlu ZyBSb21hbuKAmXMgc3VnZ2VzdGVkIHNvbHV0aW9ucyAjMiBhbmQgIzMsIHNlbmRpbmcgQUxMIGJ1 bmRsZWQgbS0gbGluZXMgd2l0aCBwb3J0IHplcm8gYW5kIGJ1bmRsZS1vbmx5IHdvdWxkIGJlIHNv bWV0aGluZyBjb21wbGV0ZWx5IG5ldywgYXMgdGhlcmUgd291bGQgYmUgbm8gb2ZmZXJlci10YWdn ZWQgbS0gc2VjdGlvbi4gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgYSBnb29kIGlkZWEuIFdlIHdp dGhlciBzZW5kIGFuIGluaXRpYWwgb2ZmZXIsIHVzaW5nIHRoZSBwcm9jZWR1cmVzIGZvciBpbml0 aWFsIG9mZmVycywgb3Igd2Ugc2VuZCBhIHN1YnNlcXVlbnQgb2ZmZXIsIHVzaW5nIHRoZSBwcm9j ZWR1cmVzIGZvciBzdWJzZXF1ZW50IG9mZmVycy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQpGcm9tOiBydGN3ZWIgPHJ0Y3dlYi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydGN3ZWItYm91 bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBSb21hbiBTaHBvdW50DQpTZW50OiBsYXVhbnRh aSAzMC4gbG9rYWt1dXRhIDIwMjEgNS4yNw0KVG86IEp1c3RpbiBVYmVydGkgPGp1YmVydGlAYWxw aGFleHBsb3JhdGlvbmNvLmNvbTxtYWlsdG86anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29t Pj4NCkNjOiBKdXN0aW4gVWJlcnRpIDxqdXN0aW5AdWJlcnRpLm5hbWU8bWFpbHRvOmp1c3RpbkB1 YmVydGkubmFtZT4+OyBSVENXZWIgSUVURiA8cnRjd2ViQGlldGYub3JnPG1haWx0bzpydGN3ZWJA aWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxs IGZvciBkcmFmdC11YmVydGktcnRjd2ViLXJmYzg4MjliaXMtMDEudHh0DQoNCk9uIEZyaSwgT2N0 IDI5LCAyMDIxIGF0IDY6NDkgUE0gSnVzdGluIFViZXJ0aSA8anViZXJ0aUBhbHBoYWV4cGxvcmF0 aW9uY28uY29tPG1haWx0bzpqdWJlcnRpQGFscGhhZXhwbG9yYXRpb25jby5jb20+PiB3cm90ZToN Cg0KDQpPbiBGcmksIE9jdCAyOSwgMjAyMSBhdCAzOjI5IFBNIFJvbWFuIFNocG91bnQgPHJvbWFu QHRlbHVyaXguY29tPG1haWx0bzpyb21hbkB0ZWx1cml4LmNvbT4+IHdyb3RlOg0KT24gRnJpLCBP Y3QgMjksIDIwMjEgYXQgMjoxNiBQTSBKdXN0aW4gVWJlcnRpIDxqdWJlcnRpQGFscGhhZXhwbG9y YXRpb25jby5jb208bWFpbHRvOmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbT4+IHdyb3Rl Og0KDQpBcyBJIGFtIHRyeWluZyB0byBleHBsYWluLCB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBv ZmZlciB0aGF0IHdvdWxkIHByZXZlbnQgdGhlIGNvbXBsaWFudCBpbXBsZW1lbnRhdGlvbiBmcm9t IG1vdmluZyB0aGUgbT0gbGluZSBvdXQuIFRoaXMgaXMgbm90IG9idmlvdXMgYnV0IGNhbiBjYXVz ZSBncmllZi4NCg0KVGhlIHByb2JsZW0gaXMgdGhhdCBpdCBpcyBub3QgcG9zc2libGUsIGFzIHRo ZXJlIGlzIG5vIG90aGVyIHRyYW5zcG9ydCB0byBtb3ZlIHRoZSB1bmJ1bmRsZWQgbGluZSB0by4g QXMgbm90ZWQgaW4gdGhlIHNlY3Rpb24geW91IGNpdGU6DQoNCiAiTk9URTogT25lIGNvbnNlcXVl bmNlIG9mIHRoZSBydWxlcyBhYm92ZSBpcyB0aGF0LCBvbmNlIGEgQlVORExFIGdyb3VwIGhhcyBi ZWVuIG5lZ290aWF0ZWQsIGEgYnVuZGxlZCAibT0iIHNlY3Rpb24gY2Fubm90IGJlIG1vdmVkIG91 dCBvZiB0aGUgQlVORExFIGdyb3VwIGluIGFuIGFuc3dlci4gSW5zdGVhZCwgYW4gb2ZmZXIgaXMg bmVlZGVkLjoiDQoNCkdlbmVyYWxseSwgSSB0aGluayB0aGF0IGlmIHRoZXJlIGlzIGEgc2hhcmVk IGFkZHJlc3MsIHRoYXQgc2lnbmlmaWVzIHRoYXQgYSBCVU5ETEUgZ3JvdXAgaGFzIGFscmVhZHkg YmVlbiBuZWdvdGlhdGVkLCBldmVuIGlmIHRoYXQgZGVjaXNpb24gd2FzIG1hZGUgZWxzZXdoZXJl LiBQZXJoYXBzIGEgbm90ZSBzaG91bGQgYmUgYWRkZWQgdG8gYnVuZGxlLWJpcyB0byBleHBsaWNp dGx5IHN0YXRlIHRoaXMuDQoNCldoZW4gZGlzY3Vzc2luZyBidW5kbGUtYmlzIHRoZSB1bmRlcnN0 YW5kaW5nIHdhcyB0aGF0IGl0IGlzIGdlbmVyYWxseSBrbm93biB3aGVuIGFuIG9mZmVyIGlzIGdl bmVyYXRlZCBmb3IgM3BjYy4gQmVjYXVzZSBvZiB0aGlzLCBpdCB3YXMgZGVjaWRlZCB0aGF0IHdo ZW4gdGhlIG9mZmVyIGlzIGdlbmVyYXRlZCBmb3IgM3BjYyBpdCBzaG91bGQgYmUgZ2VuZXJhdGVk IHVzaW5nIHRoZSBzYW1lIHJ1bGVzIGFzIHRoZSBpbml0aWFsIG9mZmVyIChpLmUuIHdpdGggcG9y dCB6ZXJvIGFuZCBidW5kbGUtb25seSkuIFRoaXMgd2FzIGNvbnNpZGVyZWQgdG8gYmUgYm90aCBi YWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIFJCRiA4ODQzIGFuZCBzYWZlIHRvIHVzZSBhcyBhbiBp bml0aWFsIG9mZmVyIGZvciBub24tYnVuZGxlIGF3YXJlLCBidW5kbGUsIGFuZCBidW5kbGUtYmlz IGVuZHBvaW50cy4gRm9yIHdoYXRldmVyIHJlYXNvbiwgaW5zcGVjdGluZyB0cmFuc3BvcnQgYWRk cmVzc2VzIHdhcyBub3QgY29uc2lkZXJlZCBhIHZhbGlkIG1lY2hhbmlzbSB0byBkZXRlY3QgdGhh dCBtPSBsaW5lcyBhcmUgYWxyZWFkeSBidW5kbGVkIGFuZCBjYW5ub3QgYmUgdW5idW5kbGVkIGlu IHRoZSBmdXR1cmUuIElmIHdlIHdhbnQgdG8gc3dpdGNoIHRvIGluc3BlY3RpbmcgdHJhbnNwb3J0 IGFkZHJlc3NlcyB3aGVuIGRlY2lkaW5nIHdoaWNoIG09IGxpbmVzIGNhbiBiZSB1bmJ1bmRsZWQs IHRoaXMgZGVzZXJ2ZXMgYSBsb3QgbW9yZSB0aGFuIGEgbm90ZSBpbiBidW5kbGUtYmlzLg0KDQpU aGlzIGxvZ2ljIG5lZWRzIHRvIGJlIGFwcGxpZWQgb24gc3Vic2VxdWVudCBvZmZlcnMgYWxyZWFk eSB0aG91Z2gsIHNvIEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgYXNraW5nIGVuZHBvaW50cyB0byBh bHNvIGNvbnNpZGVyIGl0IG9uIGluaXRpYWwgb2ZmZXJzIGlzIGFuIGlzc3VlLiBQZXJoYXBzIENo cmlzdGVyIGNvdWxkIHdlaWdoIGluIGhlcmUuDQoNCkR1cmluZyB0aGUgaW5pdGlhbCBvZmZlciBl bmQgcG9pbnQgZG9lcyBub3QgaGF2ZSBhbHJlYWR5IG5lZ290aWF0ZWQgYnVuZGxlIGdyb3Vwcy4g T25jZSB0aGUgZW5kcG9pbnQgaGFzIGFscmVhZHkgbmVnb3RpYXRlZCBidW5kbGUgZ3JvdXBzLCBt PSBsaW5lcyBjYW5ub3QgYmUgcmVtb3ZlZCBmcm9tIHRoZW0uDQoNCkkgd291bGQgc3RpbGwgYXJn dWUgdGhhdCBhIHNhZmUgd2F5IHRvIGdlbmVyYXRlIGFuIG9mZmVyIGZvciAzUENDIGlzIHRvIGRv IFNEUCBtYW5pcHVsYXRpb24gYW5kIHNldCBwb3J0cyB0byAwIHdpdGggYXR0cmlidXRlIGJ1bmRs ZS1vbmx5LiBFdmVyeXRoaW5nIGVsc2Ugd291bGQgbm90IGJlIGNvbXBhdGlibGUgd2l0aCBlaXRo ZXIgYnVuZGxlLWJpcyBvciBSRkMgODg0My4NCg0KSSBhbSBmaW5lIHRvIGluY2x1ZGUgdGhpcyBh cyBhIGNvbnNpZGVyYXRpb24gZm9yIG5vbi1CVU5ETEUgZW5kcG9pbnRzIGJ1dCBpdCBzZWVtcyBl cnJvci1wcm9uZSBhbmQgdW5uZWNlc3NhcnkgdG8gZG8gdGhpcyBmb3IgQlVORExFLWF3YXJlIGVu ZHBvaW50cy4NCg0KWW91ciBsb2dpYyBvbmx5IHdvcmtzIGlmIGJ1bmRsZS1hd2FyZSBlbmRwb2lu dHMgd2VyZSBub3QgYWxsb3dlZCB0byByZW1vdmUgbT0gbGluZXMgZnJvbSBhIGJ1bmRsZSBncm91 cC4gTG9va2luZyBhdCB0aGUgYWRkcmVzc2VzIHRvIGRldGVybWluZSB3aGF0IGlzIGFscmVhZHkg Z3JvdXBlZCBpcyBpbnN1ZmZpY2llbnQsIHNpbmNlIGFuIG9mZmVyIGNhbiBhbHNvIGJlIGFuIG9m ZmVyIHdpdGggaWNlIHJlc3RhcnQgYW5kIHRyaWNrbGUuIE5vIGFkZHJlc3NlcyB3aWxsIGJlIHBy ZXNlbnQsIHNvIHRoZSBlbmRwb2ludCB3aWxsIGhhdmUgdG8gbG9vayBhdCBpY2UgcGFyYW1ldGVy cyBhcyB3ZWxsLiBUaGlzIGdldHMgY29tcGxpY2F0ZWQgYW5kIG5vIG9uZSB3YW50ZWQgdG8gZGVz Y3JpYmUgdGhpcyB3aGVuIDg4NDNiaXMgd2FzIHdyaXR0ZW4uICBUaGlzIGlzIHdoeSByZmMgODg0 M2JpcyBzcGVjaWZpZXMgdGhhdCBzdWJzZXF1ZW50IG9mZmVycyBmb3IgM1BDQyBzaG91bGQgYmUg dmFsaWQgaW5pdGlhbCBvZmZlcnMuDQoNClRoZXJlIGFyZSwgcG90ZW50aWFsbHksIHR3byBzb2x1 dGlvbnMgdG8gdGhpczoNCg0KMS4gQ2hhbmdlIGJ1bmRsZSBzbyB0aGF0IGVuZHBvaW50cyBhcmUg cmVxdWlyZWQgdG8gaW5zcGVjdCBpbml0aWFsIG9mZmVycyBmb3IgdHJhbnNwb3J0IGFkZHJlc3Nl cyBhbmQgaWNlIHBhcmFtZXRlcnMuIERvIG5vdCBhbGxvdyBtPSBsaW5lcyB0byBiZSByZW1vdmVk IGZyb20gdGhlIGJ1bmRsZSBncm91cCBpZiB0aGV5IHNoYXJlIHRoZSB0cmFuc3BvcnQgYWRkcmVz cy4gVGhpcyB3b3VsZCByZXF1aXJlIHB1bGxpbmcgUkZDIDg4NDNiaXMgYW5kIHdyaXRpbmcgdGhl IGFwcHJvcHJpYXRlIGxhbmd1YWdlLg0KDQoyLiBDaGFuZ2UgSlNFUCBub3RlIHRvIHNwZWNpZnkg dGhhdCB0aGUgYXBwbGljYXRpb24gbmVlZHMgdG8gbWFrZSBzdXJlIHRoYXQgaW4gY2FzZSBvZiAz UENDIGFuZCByZW1vdGUgZW5kcG9pbnRzIGVpdGhlciBwb3RlbnRpYWxseSByZW1vdmluZyBtPSBs aW5lcyBmcm9tIHRoZSBidW5kbGUgb3Igbm90IGJlaW5nIGJ1bmRsZS1hd2FyZSwgYnVuZGxlZCBt PSBsaW5lcyBuZWVkIHRvIGJlIG1vZGlmaWVkIHRvIGhhdmUgcG9ydCAwIGFuZCBidW5kbGUtb25s eSBhdHRyaWJ1dGUuIENvbnNpZGVyaW5nIHRoYXQgbW9zdCBidW5kbGUtYXdhcmUgZW5kcG9pbnRz IGRvIG5vdCByZW1vdmUgbT0gbGluZXMgZnJvbSB0aGUgYnVuZGxlLCB0aGlzIG9wdGlvbiB3b3Vs ZCBjYXVzZSB0aGUgbGVhc3QgYW1vdW50IG9mIHNwZWNpZmljYXRpb24gd29yay4NCg0KMy4gSWYg d2Ugd2FudCB0byBjb21wbGV0ZWx5IGF2b2lkIGFwcGxpY2F0aW9ucyBtZXNzaW5nIHdpdGggU0RQ LCBjaGFuZ2UgSlNFUCB0byBzcGVjaWZ5IHRoYXQgd2hlbiBpY2UtcmVzdGFydCBpcyBzcGVjaWZp ZWQgYW5kIGEgbmV3IG9mZmVyIGlzIGdlbmVyYXRlZCwgYWxyZWFkeSBidW5kbGVkIG09IGxpbmVz IHNob3VsZCBiZSBtYXJrZWQgd2l0aCBwb3J0IDAgYW5kIGJ1bmRsZS1vbmx5LiBUaGlzIHdvdWxk IGFsc28gcmVzdWx0IGluIHRoZSBsZWFzdCBudW1iZXIgb2Ygc3VycHJpc2VzIGZvciBkZXZlbG9w ZXJzLg0KDQpCZXN0IFJlZ2FyZHMsDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_HE1PR07MB4441051506F5A2E16A2C902993899HE1PR07MB4441eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTm90byBTYW5zIjt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZJIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+SGkgUm9tYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5UaGFuayB5b3UgZm9yIHRo ZSBjbGFyaWZpY2F0aW9ucyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHRoaW5r IHRoZSDigJxnZW5lcmF0aW5nIGEgc3Vic2VxdWVudCBvZmZlciBhcyBhbiBpbml0aWFsIG9mZmVy 4oCdIHdvcmRpbmcgY291bGQgYmUgY29uZnVzaW5nIHRvIHBlb3BsZS4gSSB3b3VsZCBzYXkgc29t ZXRoaW5nIGxpa2Ug4oCcZ2VuZXJhdGluZyBhIG5ldyBpbml0aWFsIG9mZmVyIHdpdGhpbiBhIHNl c3Npb27igJ0sIG9yDQogc29tZXRoaW5n4oCmIEhvd2V2ZXIsIGFzIGZhciBhcyB0aGUgaXNzdWVz IGl0c2VsZiBpcyBjb25jZXJuZWQsIHRoYXQgaXMgbm90IHJlbGV2YW50IOKAkyBhcyBsb25nIGFz IHdlIGtub3cgd2hhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCA6KTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7MS4gTWFrZSBzdWJzZXF1ZW50 IG9mZmVycyB2YWxpZCBpbml0aWFsIG9mZmVycy4gVGhpcyBtZWFucyBhZGRpbmcgc29tZSBsYW5n dWFnZSBleHBsYWluaW5nIGhvdyB0aGUgZW5kcG9pbnQgcHJvY2Vzc2luZyZuYnNwO2luaXRpYWwg b2ZmZXIgY2FuIGRldGVjdCB0aGF0IG09IGxpbmVzIGNhbm5vdCBiZSB1bmJ1bmRsZWQuIEV2ZW4g aWYgd2UgYWRkIHRoaXMgbGFuZ3VhZ2UgaXQgd2lsbA0KIGhhdmUgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkgaXNzdWVzIHdpdGggYW55dGhpbmcgdGhhdCBoYXMgbm90IGltcGxlbWVudGVkIGl0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SSBkb27igJl0IGFncmVlIHdpdGggdGhhdCBzdWdnZXN0aW9uLiBC ZWNhdXNlLCBpbiB0aGF0IGNhc2Ugd2UgY291bGQgaGF2ZSBkb25lIGl0IGZyb20gdGhlIGJlZ2lu bmluZywgYXMgYSBnZW5lcmFsIHJ1bGUsIHdpdGhvdXQgdXNpbmcgcG9ydCB6ZXJvLiBCdXQgdGhl cmUgd2VyZSByZWFzb24gd2UgY2hvc2Ugbm90IHRvIGFsbG93IHNoYXJlZCBhZGRyZXNzZXMgKHdp dGggbm9uLXplcm8NCiBwb3J0IHZhbHVlcykgaW4gaW5pdGlhbCBvZmZlcnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsyLiBNYWtlIGVu ZHBvaW50cyBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVycyB0aGF0IGFyZSB2YWxpZCBpbml0aWFs IG9mZmVycyBpbiAzUENDIHNjZW5hcmlvcy4gVGhpcyBpcyB3aGF0IGRyYWZ0IDg4NDMgYmlzIGRv ZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q29ycmVjdC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhvd2V2ZXIsIGtlZXAgaW4gbWluZCB0aGF0IGl0IGlzIG5v dCBvbmx5IGFib3V0IGhvdyB0byBlbmNvZGUgdGhlIHBvcnQgbnVtYmVycyBhbmQgYnVuZGxlLW9u bHkgYXR0cmlidXRlcy4gU2VuZGluZyBhbiBpbml0aWFsIG9mZmVyIGFsc28gY29tZXMgd2l0aCBh IHNldCBvZiBwcm9jZWR1cmVzLiBTb21lIG9mIHRob3NlDQogKGUuZy4sIElDRSkgJm5ic3A7SSBh c3N1bWUgeW91IHdpbGwgaGF2ZSB0byBkbyBhbnl3YXksIGFzIHRoZSByZW1vdGUgZW5kcG9pbnQg Y2hhbmdlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0O0kgd291bGQgZXZlbiBiZSBmaW5lIHdpdGggd2VicnRjIGVuZHBvaW50IG5vdCBk b2luZyBhbnl0aGluZyBhbmQgYWRkaW5nIGEgbm90ZSB0byBKU0VQIHRlbGxpbmcgdGhlIDNQQ0Mg YXBwbGljYXRpb24gdG8gJnF1b3Q7Zml4JnF1b3Q7IHRoZSBvZmZlciBhbmQgYWRkIG09IHBvcnQg emVybyBhbmQgYnVuZGxlLW9ubHkgYXR0cmlidXRlcyB3aGVuIGl0IGlzIHNlbmRpbmcgc3Vic2Vx dWVudCBvZmZlcnMNCiBhcyBpbml0aWFsIG9mZmVycyB0byBhIG5ldyBlbmQgcG9pbnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIHdvdWxkIGJlIGZpbmUgYWRkaW5nIHN1Y2ggdGV4dCB0byBKU0VQLiBJ dCBjb3VsZCBiZSBhbiBhZGRpdGlvbmFsIHNlbnRlbmNlIHRvIHRoZSBleGlzdGluZyB0ZXh0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+KEhvd2V2ZXIsIEkgc3RpbGwgd291bGQgbm90IHNheSDigJxzZW5k aW5nIHN1YnNlcXVlbnQgb2ZmZXJzIGFzIGluaXRpYWwgb2ZmZXJz4oCdLiBJIHdvdWxkIHNheSDi gJxjcmVhdGUgYW5kIHNlbmQgYW4gaW5pdGlhbCBvZmZlciBiYXNlZCBvbiBhIHJlY2VpdmVkIHN1 YnNlcXVlbnQgb2ZmZXLigJ0sIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQuKTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20m Z3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gc3VubnVudGFpIDMxLiBsb2tha3V1dGEgMjAyMSA2LjAy PGJyPg0KPGI+VG86PC9iPiBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVzdGluIFViZXJ0aSAmbHQ7anViZXJ0 aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tJmd0OzsgSnVzdGluIFViZXJ0aSAmbHQ7anVzdGluQHVi ZXJ0aS5uYW1lJmd0OzsgUlRDV2ViIElFVEYgJmx0O3J0Y3dlYkBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtydGN3ZWJdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBk cmFmdC11YmVydGktcnRjd2ViLXJmYzg4MjliaXMtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSZuYnNwO0NocmlzdGVyLDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW4gdHJ5IHRvIGV4cGxhaW4gdGhl IGlzc3VlLiBJZiB5b3UgbmVlZCBJIGNhbiBwcm92aWRlIGEgbW9yZSBkZXRhaWxlZCBjYWxsIGZs b3cgd2l0aCBTRFAgZXhhbXBsZXMgYnV0IGhlcmUgaXMgdGhlIGJhc2ljIHNjZW5hcmlvIGZvciBu b253OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4xLiAzUENDIGFwcGxpY2F0aW9uIHJlcXVlc3RzIGFuJm5ic3A7b2ZmZXIgZnJvbSBjbGllbnQg QS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIu IENsaWVudCBBIGdlbmVyYXRlcyBhbiBvZmZlciB3aXRoIGF1ZGlvLCB2aWRlbywgYW5kIGRhdGEg bT0gbGluZXMgd2hpY2ggYXJlIHBhcnQgb2YgYSBzaW5nbGUgYnVuZGxlIGdyb3VwLiBJdCBkb2Vz IG5vdCBtYXR0ZXIgZm9yIHRoaXMgY2FzZSBpZiB0aGV5IGFyZSBidW5kbGUtb25seSBvciBjYW4g YmUgdW5idW5kbGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4zLiBTaWduYWxpbmcgYXBwbGljYXRpb24gc2VuZHMgdGhlIG9mZmVyIHJlY2VpdmVk IGZyb20gY2xpZW50IEEgdG8gY2xpZW50IEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBDbGllbnQgQiBzdXBwb3J0cyBidW5kbGUgc28gaXQg Z2VuZXJhdGVzIGFuIGFuc3dlciB3aGVyZSBhbGwgbT0gbGluZXMgYXJlIGJ1bmRsZWQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUuIDNQQ0Mgc2Vu ZHMgdGhlIGFuc3dlciB0byBDbGllbnQgQS4gQXQgdGhpcyBwb2ludCBhbGwgbT0gbGluZXMgYXJl IGJ1bmRsZWQgYW5kIGNhbm5vdCBiZSB1bmJ1bmRsZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42LiAzUENDIGFwcGxpY2F0aW9uIHJlcXVlc3Rz IGFub3RoZXIgb2ZmZXIgZnJvbSBjbGllbnQgQSB3aXRoaW4gdGhlIHNhbWUgc2Vzc2lvbi4gVGhp cyBvZmZlciBpcyBhIHN1YnNlcXVlbnQgb2ZmZXIgc28gaXQgd291bGQgaGF2ZSBhbGwgMyBtPSBs aW5lcyBidW5kbGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Ny4gM1BDQyBzZW5kcyB0aGUgZ2VuZXJhdGVkIG9mZmVyIHRvIGNsaWVudCBDLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OC4gQ2xp ZW50IEMgaXMgZ2VuZXJhdGluZyBhbiBhbnN3ZXIgdG8gdGhlIG9mZmVyIGl0IHJlY2VpdmVkLiBD bGllbnQgQyBpcyBidW5kbGUgYXdhcmUgYnV0IGRlY2lkZXMgdGhhdCBpdCB3YW50cyB0byB1bmJ1 bmRsZSBkYXRhIG09IGxpbmUuIEFzIGZhciBhcyBDbGllbnQgQyBpcyBjb25jZXJuZWQsIHRoZXJl IGFyZSBubyBwcmUtbmVnb3RpYXRlZCBidW5kbGUgZ3JvdXBzLiBJZiB0aGVyZSBhcmUgbm8mbmJz cDtidW5kbGUtb25seQ0KIGF0dHJpYnV0ZXMgb24gbT0gbGluZXMsIHRoZXJlIGlzIG5vdGhpbmcg c3RvcHBpbmcgY2xpZW50IEMgZnJvbSB1bmJ1bmRsaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXIgZHJhZnQgODg0MyBiaXMsIFNJUCBj b25zaWRlcmF0aW9uIHNlY3Rpb24gKDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hp dmUvaWQvZHJhZnQtaWV0Zi1tbXVzaWMtcmZjODg0M2Jpcy0wNS5odG1sI25hbWUtc2lwLWNvbnNp ZGVyYXRpb25zIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtbW11 c2ljLXJmYzg4NDNiaXMtMDUuaHRtbCNuYW1lLXNpcC1jb25zaWRlcmF0aW9uczwvYT4pLA0KIG9m ZXIgaW4gc3RlcCA2IHNob3VsZCBiZSBnZW5lcmF0ZWQgYXMgYW4gaW5pdGlhbCBvZmZlciwgaS5l LiB3aXRoIHBvcnQgMCBhbmQgYnVuZGxlLW9ubHkgaW4gYnVuZGxlZCZuYnNwO209IGxpbmVzLiBU aGlzIGlzIGRvbmUgc3BlY2lmaWNhbGx5IHRvIGF2b2lkIHByb2JsZW1zIGluIHN0ZXAgOC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBJ IGFtIHN1Z2dlc3RpbmcgaXMgbm90IHRvIGFsd2F5cyBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVy cyB3aXRoIHBvcnQgemVybyBhbmQgYnVuZGxlLW9ubHkuIEkgYW0gc3VnZ2VzdGluZyBvbmx5IGRv IHRoaXMsIHdoZW4gdGhpcyBvZmZlciBpcyBpbnRlbmRlZCBmb3IgM1BDQy4gVGhlcmUgaXMgYWxy ZWFkeSBhIHNpbWlsYXIgZmVhdHVyZSBmb3IgSUNFIHdoaWNoIHRyaWdnZXJzIGljZSByZXN0YXJ0 IGZvcg0KIHRoZSBvZmZlciB3aGljaCBjYW4gYmUgdXNlZCBmb3IgM1BDQy4gSXQgY2FuIGFsc28g dHJpZ2dlciBnZW5lcmF0aW9uIG9mIGFuIG9mZmVyIHdpdGggYnVuZGxlLW9ubHkgZm9yIGFsbCBi dW5kbGVkJm5ic3A7bT0gbGluZXMuIEkgd291bGQgZXZlbiBiZSBmaW5lIHdpdGggd2VicnRjIGVu ZHBvaW50IG5vdCBkb2luZyBhbnl0aGluZyBhbmQgYWRkaW5nIGEgbm90ZSB0byBKU0VQIHRlbGxp bmcgdGhlIDNQQ0MgYXBwbGljYXRpb24gdG8gJnF1b3Q7Zml4JnF1b3Q7IHRoZSBvZmZlcg0KIGFu ZCBhZGQgbT0gcG9ydCB6ZXJvIGFuZCBidW5kbGUtb25seSBhdHRyaWJ1dGVzIHdoZW4gaXQgaXMg c2VuZGluZyBzdWJzZXF1ZW50IG9mZmVycyBhcyBpbml0aWFsIG9mZmVycyB0byBhIG5ldyBlbmQg cG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIGFueSBjYXNlLCB0aGUgc3Vic2VxdWVudCBvZmZlciBnZW5lcmF0ZWQgaW4gc3RlcCA2 IGlzIG5vdCBhIHZhbGlkIGluaXRpYWwgb2ZmZXIgYWNjb3JkaW5nIHRvIHRoZSBidW5kbGUgc3Bl Y2lmaWNhdGlvbi4gV2UgaGF2ZSB0d28gY2hvaWNlczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gTWFrZSBzdWJzZXF1ZW50IG9mZmVycyB2 YWxpZCBpbml0aWFsIG9mZmVycy4gVGhpcyBtZWFucyBhZGRpbmcgc29tZSBsYW5ndWFnZSBleHBs YWluaW5nIGhvdyB0aGUgZW5kcG9pbnQgcHJvY2Vzc2luZyZuYnNwO2luaXRpYWwgb2ZmZXIgY2Fu IGRldGVjdCB0aGF0IG09IGxpbmVzIGNhbm5vdCBiZSB1bmJ1bmRsZWQuIEV2ZW4gaWYgd2UgYWRk IHRoaXMgbGFuZ3VhZ2UgaXQgd2lsbCBoYXZlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5DQogaXNz dWVzIHdpdGggYW55dGhpbmcgdGhhdCBoYXMgbm90IGltcGxlbWVudGVkIGl0LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBNYWtlIGVuZHBv aW50cyBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVycyB0aGF0IGFyZSB2YWxpZCBpbml0aWFsIG9m ZmVycyBpbiAzUENDIHNjZW5hcmlvcy4gVGhpcyBpcyB3aGF0IGRyYWZ0IDg4NDMgYmlzIGRvZXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBs ZWFzZSBsZXQgbWUga25vdyBpZiB5b3UgbmVlZCBtb3JlIGRldGFpbHMuPGJyIGNsZWFyPSJhbGwi Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFNhdCwgT2N0IDMwLCAyMDIxIGF0IDY6 NDQgUE0gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb20iPmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Rmlyc3QsIGl0IHdv dWxkIGhhdmUgYmVlbiBuaWNlIHRvIHNlZSBhIGNhbGwtZmxvdyB0aGF0IHNob3dzIGV4YWN0bHkg d2hlcmUgdGhlIGlzc3VlIGFyaXNlcywgYXMgdGhlcmUgYXJlIGRpZmZlcmVudCB3YXlzIG9mIGRv aW5nIDNQQ0MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxyZWFkeSBhdCB0aGUgZWFybHkgZGF5 cyBvZiBCVU5ETEUsIHdlIGFncmVlZCB0aGF0IGFuIGluaXRpYWwgb2ZmZXIgd2lsbCBOT1QgY29u dGFpbiBhIHNoYXJlZCBhZGRyZXNzLCBiZWNhdXNlIGl0IGlzIG5vdCBiYWNrd2FyZCBjb21wYXRp YmxlIHdpdGggbm9uLWJ1bmRsZQ0KIGF3YXJlIGVuZHBvaW50cy4gU29tZSBwZW9wbGUgKGluY2x1 ZGluZyBlLmcuLCBteXNlbGYgYW5kIEN1bGxlbikgd2VyZSB2ZXJ5IGtlZW4gb24gdGhhdC4gSW5z dGVhZCB3ZSB3aWxsIHVzZSBwb3J0IHplcm8gKyBidW5kbGUtb25seSBmb3IgbS0gbGluZXMgdGhh dCBhcmUgb25seSBiZSBhY2NlcHRlZCBpZiBwYXJ0IG9mIGEgQlVORExFIGdyb3VwLiBJIGRvIG5v dCBhZ3JlZSB0byBhZGRpbmcgdGV4dCB0byA4ODQzYmlzIHNheWluZyB0aGVyZSBhcmUNCiBjYXNl cyB3aGVyZSB0aGUgc3BlY2lmaWVkIHByb2NlZHVyZXMgZm9yIGluaXRpYWwgb2ZmZXJzIGRvbuKA mXQgYXBwbHksIG9yIGRvbuKAmXQgaGF2ZSB0byBiZSBmb2xsb3dlZC48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj5ZZXMsIHdlIGRpZCBhZGQgc29tZSAzUENDIGNsYXJpZmljYXRpb24gdGV4dCAmbmJz cDsod2hpY2ggYW55b25lIGNvdWxkIGhhdmUgY29tbWVudGVkIG9uKSBpbiA4ODQzYmlzLCBidXQg d2UgZGlkIG5vdCBjaGFuZ2UgdGhlIHByb2NlZHVyZXMgZm9yIGluaXRpYWwgb2ZmZXJzLg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWxzbyBrZWVwIGluIG1pbmQgdGhhdCB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIGFuIGluaXRpYWwgb2ZmZXIgYW5kIGEgc3Vic2VxdWVudCBvZmZlciBpcyBub3Qg cmVsYXRlZCBvbmx5IHRoZSBCVU5ETEUtcmVsYXRlZCBpbmZvcm1hdGlvbi4gRm9yIGV4YW1wbGUs IGFuIGluaXRpYWwNCiBvZmZlciBtdXN0IGFsc28gY29udGFpbiB1bmlxdWUgSUNFIGNhbmRpZGF0 ZXMgaW4gZWFjaCBub24tYnVuZGxlLW9ubHkgbS0gbGluZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5NeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSB0ZXh0IGluIDg4MjliaXMgaXMgdGhhdCBKU0VQIGRv ZXMgTk9UIHN1cHBvcnQgKG9yLCBpZiB3ZSB3YW50IHRvIHdvcmQgaXQgZGlmZmVyZW50bHksIGlz IG5vdCBhYmxlIHRvIGRldGVjdCkgdGhlIDNQQ0MgY2FzZXMgcmVmZXJlbmNlZA0KIGJ5IFJvbWFu IChhZ2FpbiwgY2FsbCBmbG93cyB3b3VsZCBoYXZlIGJlZW4gbmljZSksIHNvIGEgSlNFUCBlbmRw b2ludCB3aWxsIGFsd2F5cyBzZW5kIGEgc3Vic2VxdWVudCBvZmZlciBhY2NvcmRpbmcgdG8gdGhl IHJ1bGVzIGZvciBzZW5kaW5nIGEgc3Vic2VxdWVudCBvZmZlci48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5SZWdhcmRpbmcgUm9tYW7igJlzIHN1Z2dlc3RlZCBzb2x1dGlvbnMgIzIgYW5kICMzLCBz ZW5kaW5nIEFMTCBidW5kbGVkIG0tIGxpbmVzIHdpdGggcG9ydCB6ZXJvIGFuZCBidW5kbGUtb25s eSB3b3VsZCBiZSBzb21ldGhpbmcgY29tcGxldGVseSBuZXcsIGFzIHRoZXJlIHdvdWxkDQogYmUg bm8gb2ZmZXJlci10YWdnZWQgbS0gc2VjdGlvbi4gSSBkb27igJl0IHRoaW5rIHRoYXQgaXMgYSBn b29kIGlkZWEuIFdlIHdpdGhlciBzZW5kIGFuIGluaXRpYWwgb2ZmZXIsIHVzaW5nIHRoZSBwcm9j ZWR1cmVzIGZvciBpbml0aWFsIG9mZmVycywgb3Igd2Ugc2VuZCBhIHN1YnNlcXVlbnQgb2ZmZXIs IHVzaW5nIHRoZSBwcm9jZWR1cmVzIGZvciBzdWJzZXF1ZW50IG9mZmVycy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gcnRjd2ViICZsdDs8YSBo cmVmPSJtYWlsdG86cnRjd2ViLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ydGN3 ZWItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbWFuIFNo cG91bnQ8YnI+DQo8Yj5TZW50OjwvYj4gbGF1YW50YWkgMzAuIGxva2FrdXV0YSAyMDIxIDUuMjc8 YnI+DQo8Yj5Ubzo8L2I+IEp1c3RpbiBVYmVydGkgJmx0OzxhIGhyZWY9Im1haWx0bzpqdWJlcnRp QGFscGhhZXhwbG9yYXRpb25jby5jb20iIHRhcmdldD0iX2JsYW5rIj5qdWJlcnRpQGFscGhhZXhw bG9yYXRpb25jby5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSnVzdGluIFViZXJ0aSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmp1c3RpbkB1YmVydGkubmFtZSIgdGFyZ2V0PSJfYmxhbmsiPmp1c3Rp bkB1YmVydGkubmFtZTwvYT4mZ3Q7OyBSVENXZWIgSUVURiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ0 Y3dlYkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnJ0Y3dlYkBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbcnRjd2ViXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBm b3IgZHJhZnQtdWJlcnRpLXJ0Y3dlYi1yZmM4ODI5YmlzLTAxLnR4dDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBPY3QgMjksIDIwMjEgYXQgNjo0OSBQTSBK dXN0aW4gVWJlcnRpICZsdDs8YSBocmVmPSJtYWlsdG86anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9u Y28uY29tIiB0YXJnZXQ9Il9ibGFuayI+anViZXJ0aUBhbHBoYWV4cGxvcmF0aW9uY28uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gRnJpLCBPY3QgMjksIDIwMjEgYXQg MzoyOSBQTSBSb21hbiBTaHBvdW50ICZsdDs8YSBocmVmPSJtYWlsdG86cm9tYW5AdGVsdXJpeC5j b20iIHRhcmdldD0iX2JsYW5rIj5yb21hbkB0ZWx1cml4LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIEZyaSwgT2N0IDI5LCAyMDIxIGF0IDI6MTYgUE0gSnVzdGluIFViZXJ0aSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmp1YmVydGlAYWxwaGFleHBsb3JhdGlvbmNvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIEkgYW0gdHJ5aW5nIHRvIGV4cGxh aW4sIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIG9mZmVyIHRoYXQgd291bGQgcHJldmVudCZuYnNw O3RoZSZuYnNwO2NvbXBsaWFudCZuYnNwO2ltcGxlbWVudGF0aW9uIGZyb20gbW92aW5nIHRoZSZu YnNwO209IGxpbmUgb3V0LiBUaGlzIGlzIG5vdCBvYnZpb3VzIGJ1dCBjYW4gY2F1c2UgZ3JpZWYu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHByb2JsZW0gaXMgdGhhdCBpdCBp cyBub3QgcG9zc2libGUsIGFzIHRoZXJlIGlzIG5vIG90aGVyIHRyYW5zcG9ydCB0byBtb3ZlIHRo ZSB1bmJ1bmRsZWQgbGluZSB0by4gQXMgbm90ZWQgaW4gdGhlIHNlY3Rpb24geW91IGNpdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtOb3RvIFNhbnMm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7Tk9URTogT25lIGNvbnNlcXVlbmNlIG9mIHRo ZSBydWxlcyBhYm92ZSBpcyB0aGF0LCBvbmNlIGEgQlVORExFIGdyb3VwIGhhcyBiZWVuIG5lZ290 aWF0ZWQsIGEgYnVuZGxlZCAmcXVvdDttPSZxdW90OyBzZWN0aW9uDQogY2Fubm90IGJlIG1vdmVk IG91dCBvZiB0aGUgQlVORExFIGdyb3VwIGluIGFuIGFuc3dlci4gSW5zdGVhZCwgYW4gb2ZmZXIg aXMgbmVlZGVkLjomcXVvdDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5HZW5lcmFsbHksIEkgdGhpbmsgdGhhdCBpZiB0aGVy ZSBpcyBhIHNoYXJlZCBhZGRyZXNzLCB0aGF0IHNpZ25pZmllcyB0aGF0IGEgQlVORExFIGdyb3Vw IGhhcyBhbHJlYWR5IGJlZW4gbmVnb3RpYXRlZCwgZXZlbiBpZiB0aGF0IGRlY2lzaW9uIHdhcyBt YWRlIGVsc2V3aGVyZS4gUGVyaGFwcyBhIG5vdGUgc2hvdWxkDQogYmUgYWRkZWQgdG8gYnVuZGxl LWJpcyB0byBleHBsaWNpdGx5IHN0YXRlIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+V2hlbiBkaXNjdXNzaW5nIGJ1bmRsZS1iaXMgdGhlIHVuZGVyc3RhbmRpbmcmbmJzcDt3 YXMgdGhhdCBpdCBpcyBnZW5lcmFsbHkga25vd24gd2hlbiBhbiBvZmZlciBpcyBnZW5lcmF0ZWQg Zm9yIDNwY2MuIEJlY2F1c2Ugb2YgdGhpcywgaXQgd2FzIGRlY2lkZWQgdGhhdCB3aGVuIHRoZSBv ZmZlciBpcyBnZW5lcmF0ZWQNCiBmb3IgM3BjYyBpdCBzaG91bGQgYmUgZ2VuZXJhdGVkIHVzaW5n IHRoZSBzYW1lIHJ1bGVzIGFzIHRoZSBpbml0aWFsIG9mZmVyIChpLmUuIHdpdGggcG9ydCB6ZXJv IGFuZCBidW5kbGUtb25seSkuIFRoaXMgd2FzIGNvbnNpZGVyZWQgdG8gYmUgYm90aCBiYWNrd2Fy ZHMgY29tcGF0aWJsZSB3aXRoIFJCRiA4ODQzIGFuZCBzYWZlIHRvIHVzZSBhcyBhbiBpbml0aWFs IG9mZmVyIGZvciBub24tYnVuZGxlJm5ic3A7YXdhcmUsIGJ1bmRsZSwgYW5kIGJ1bmRsZS1iaXMN CiBlbmRwb2ludHMuIEZvciB3aGF0ZXZlciByZWFzb24sIGluc3BlY3RpbmcgdHJhbnNwb3J0IGFk ZHJlc3NlcyB3YXMgbm90IGNvbnNpZGVyZWQgYSB2YWxpZCBtZWNoYW5pc20gdG8gZGV0ZWN0IHRo YXQgbT0gbGluZXMgYXJlIGFscmVhZHkgYnVuZGxlZCBhbmQgY2Fubm90IGJlIHVuYnVuZGxlZCBp biB0aGUgZnV0dXJlLiBJZiB3ZSB3YW50IHRvIHN3aXRjaCB0byBpbnNwZWN0aW5nIHRyYW5zcG9y dCBhZGRyZXNzZXMgd2hlbiBkZWNpZGluZyB3aGljaA0KIG09IGxpbmVzIGNhbiBiZSB1bmJ1bmRs ZWQsIHRoaXMgZGVzZXJ2ZXMgYSBsb3QgbW9yZSB0aGFuIGEgbm90ZSBpbiBidW5kbGUtYmlzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgbG9naWMgbmVlZHMgdG8gYmUgYXBw bGllZCBvbiBzdWJzZXF1ZW50IG9mZmVycyBhbHJlYWR5IHRob3VnaCwgc28gSSBkb24ndCB1bmRl cnN0YW5kIHdoeSBhc2tpbmcgZW5kcG9pbnRzIHRvIGFsc28gY29uc2lkZXIgaXQgb24gaW5pdGlh bCBvZmZlcnMgaXMgYW4gaXNzdWUuIFBlcmhhcHMgQ2hyaXN0ZXINCiBjb3VsZCB3ZWlnaCBpbiBo ZXJlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkR1cmluZyB0aGUgaW5p dGlhbCBvZmZlciBlbmQgcG9pbnQgZG9lcyBub3QgaGF2ZSBhbHJlYWR5IG5lZ290aWF0ZWQgYnVu ZGxlIGdyb3Vwcy4gT25jZSB0aGUgZW5kcG9pbnQgaGFzIGFscmVhZHkgbmVnb3RpYXRlZCBidW5k bGUgZ3JvdXBzLCBtPSBsaW5lcyBjYW5ub3QgYmUgcmVtb3ZlZCBmcm9tIHRoZW0uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgd291bGQgc3RpbGwgYXJndWUgdGhhdCBhIHNhZmUgd2F5IHRvIGdlbmVyYXRlIGFu IG9mZmVyIGZvciAzUENDIGlzIHRvIGRvIFNEUCBtYW5pcHVsYXRpb24gYW5kIHNldCBwb3J0cyB0 byAwIHdpdGggYXR0cmlidXRlIGJ1bmRsZS1vbmx5LiBFdmVyeXRoaW5nIGVsc2Ugd291bGQgbm90 IGJlIGNvbXBhdGlibGUNCiB3aXRoIGVpdGhlciBidW5kbGUtYmlzIG9yIFJGQyA4ODQzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgYW0gZmluZSB0byBpbmNsdWRlIHRoaXMgYXMg YSBjb25zaWRlcmF0aW9uIGZvciBub24tQlVORExFIGVuZHBvaW50cyBidXQgaXQgc2VlbXMgZXJy b3ItcHJvbmUgYW5kIHVubmVjZXNzYXJ5IHRvIGRvIHRoaXMgZm9yIEJVTkRMRS1hd2FyZSBlbmRw b2ludHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91ciBsb2dpYyBv bmx5IHdvcmtzIGlmIGJ1bmRsZS1hd2FyZSBlbmRwb2ludHMgd2VyZSBub3QgYWxsb3dlZCB0byBy ZW1vdmUgbT0gbGluZXMgZnJvbSBhIGJ1bmRsZSBncm91cC4gTG9va2luZyBhdCB0aGUgYWRkcmVz c2VzIHRvIGRldGVybWluZSB3aGF0IGlzIGFscmVhZHkgZ3JvdXBlZCBpcyBpbnN1ZmZpY2llbnQs DQogc2luY2UgYW4gb2ZmZXIgY2FuIGFsc28gYmUgYW4gb2ZmZXIgd2l0aCBpY2UgcmVzdGFydCBh bmQgdHJpY2tsZS4gTm8gYWRkcmVzc2VzIHdpbGwgYmUgcHJlc2VudCwgc28gdGhlIGVuZHBvaW50 IHdpbGwgaGF2ZSB0byBsb29rIGF0IGljZSBwYXJhbWV0ZXJzIGFzIHdlbGwuIFRoaXMgZ2V0cyBj b21wbGljYXRlZCBhbmQgbm8gb25lIHdhbnRlZCB0byBkZXNjcmliZSB0aGlzIHdoZW4gODg0M2Jp cyZuYnNwO3dhcyB3cml0dGVuLiZuYnNwOyBUaGlzIGlzIHdoeSByZmMNCiA4ODQzYmlzJm5ic3A7 c3BlY2lmaWVzIHRoYXQgc3Vic2VxdWVudCBvZmZlcnMgZm9yIDNQQ0Mgc2hvdWxkIGJlIHZhbGlk IGluaXRpYWwgb2ZmZXJzLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZSBhcmUsIHBvdGVudGlhbGx5LCB0d28gc29sdXRpb25z IHRvIHRoaXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4xLiBDaGFuZ2UgYnVuZGxlIHNvIHRoYXQgZW5kcG9pbnRzIGFyZSByZXF1aXJl ZCB0byBpbnNwZWN0IGluaXRpYWwmbmJzcDtvZmZlcnMgZm9yIHRyYW5zcG9ydCBhZGRyZXNzZXMg YW5kIGljZSBwYXJhbWV0ZXJzLiBEbyBub3QgYWxsb3cgbT0gbGluZXMgdG8gYmUgcmVtb3ZlZCBm cm9tIHRoZSBidW5kbGUgZ3JvdXAgaWYNCiB0aGV5IHNoYXJlIHRoZSB0cmFuc3BvcnQgYWRkcmVz cy4gVGhpcyB3b3VsZCByZXF1aXJlIHB1bGxpbmcgUkZDIDg4NDNiaXMgYW5kIHdyaXRpbmcgdGhl IGFwcHJvcHJpYXRlIGxhbmd1YWdlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Mi4gQ2hhbmdlIEpTRVAgbm90ZSB0byBzcGVjaWZ5IHRo YXQgdGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIG1ha2Ugc3VyZSB0aGF0IGluIGNhc2Ugb2YgM1BD QyBhbmQgcmVtb3RlIGVuZHBvaW50cyBlaXRoZXIgcG90ZW50aWFsbHkgcmVtb3ZpbmcgbT0gbGlu ZXMgZnJvbSB0aGUgYnVuZGxlIG9yIG5vdCBiZWluZw0KIGJ1bmRsZS1hd2FyZSwgYnVuZGxlZCBt PSBsaW5lcyBuZWVkIHRvIGJlIG1vZGlmaWVkIHRvIGhhdmUgcG9ydCAwIGFuZCBidW5kbGUtb25s eSBhdHRyaWJ1dGUuIENvbnNpZGVyaW5nIHRoYXQgbW9zdCBidW5kbGUtYXdhcmUgZW5kcG9pbnRz IGRvIG5vdCByZW1vdmUgbT0gbGluZXMgZnJvbSB0aGUgYnVuZGxlLCB0aGlzIG9wdGlvbiB3b3Vs ZCBjYXVzZSB0aGUgbGVhc3QgYW1vdW50IG9mIHNwZWNpZmljYXRpb24gd29yay48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjMuIElmIHdl IHdhbnQgdG8gY29tcGxldGVseSBhdm9pZCBhcHBsaWNhdGlvbnMgbWVzc2luZyB3aXRoIFNEUCwg Y2hhbmdlIEpTRVAgdG8gc3BlY2lmeSB0aGF0IHdoZW4gaWNlLXJlc3RhcnQgaXMgc3BlY2lmaWVk IGFuZCBhIG5ldyBvZmZlciBpcyBnZW5lcmF0ZWQsIGFscmVhZHkgYnVuZGxlZCBtPSBsaW5lcw0K IHNob3VsZCBiZSBtYXJrZWQgd2l0aCBwb3J0IDAgYW5kIGJ1bmRsZS1vbmx5LiBUaGlzIHdvdWxk IGFsc28gcmVzdWx0IGluIHRoZSBsZWFzdCBudW1iZXIgb2Ygc3VycHJpc2VzIGZvciBkZXZlbG9w ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPl9fX19fX19fX19fX188YnI+DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR07MB4441051506F5A2E16A2C902993899HE1PR07MB4441eurp_-- From nobody Sun Oct 31 22:41:23 2021 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 378E93A1010 for ; Sun, 31 Oct 2021 22:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=alphaexplorationco.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 IPhI6vpsMEnc for ; Sun, 31 Oct 2021 22:41:16 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::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 3C0393A100F for ; Sun, 31 Oct 2021 22:41:16 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id n11so15333565oig.6 for ; Sun, 31 Oct 2021 22:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Nmk4tUhTHmLQ4yqw3T011Ct0+LCBiJhykEFdCtRIj2U=; b=GqprwbI5c3tXD9VIN5AxzZm9+HAkYgROKDCHqdagsjOin1y/Dv0FcNBids8ggQNs51 5Y86gsXCC2Li2EKNBgIGU/mhWl7TqJK3pCL/72AkeVj9HAXovQONVmmbOU9yXniMnKQ5 96A6Haw4/ECdS+xMZ7LWMs2C2s84easTyfp2XEl0YTzQdoe3lWnVIKa8EpzRxow2uq6K RPVo3PKhAsqqmJSvzl7LVCXQfg4JTJh64YPMHl/f4mz46XmA/8CIvezIf7XP3CNgIjX+ xdsOge4/ypdOIZ+jiYI1oB44JWR7f7LhQlEGKmVBAxFkQ1niR/GxFwb92/TEtAAC8UmN M8Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Nmk4tUhTHmLQ4yqw3T011Ct0+LCBiJhykEFdCtRIj2U=; b=nc31evnDU6syoNki3KN+Jh71oioAMAYuSK+v5gefUvOZ9GlSaMa4bD/PrGch0DbIsu gGzhBeLK5oqYWHatzLsExXwX+m/iAP+59Hd5dPk/NQD4gynpWgSccHXZFCudK4rlju5d n4cV5SS+LvU9YJZmxn/ByrCDBO06syyobMM85b+wOEsPd6Xg4hKRBIWdsp5FFTOPaKoT 0vVsdqb0d3amonLEsmAS9k3VdzXB2ASB3TdAIDt8K8xKFNcmBAFrBF5kbkPtc6smeAVp 5PvwzKPO+ZZUUTALwffhIN0brS06ixkK0FM/FCbsbypV8q6UT+oC0QeSQEgRDVknFjj3 1DFg== X-Gm-Message-State: AOAM530FJjnSI9U37B+oZHWRApqb4Vf0mQrf8X8lcUkO7oJtMSVvgEYf lhQxyjCVHEkFKYEGnuy4iFPiKRJsQSO1dMHy2/HTxymP4ohXQw== X-Google-Smtp-Source: ABdhPJyHzEW7+c7S40OLQWFGxV1rHlvOGMZMayaauB+YgqoaqCKtRPrOTDeTZOoI80RVdIYxSWsIxcU23orK117m4iE= X-Received: by 2002:a05:6808:1385:: with SMTP id c5mr620087oiw.126.1635745273059; Sun, 31 Oct 2021 22:41:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Sun, 31 Oct 2021 22:41:02 -0700 Message-ID: To: Christer Holmberg Cc: Roman Shpount , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000f1ab7505cfb39ff8" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2021 05:41:22 -0000 --000000000000f1ab7505cfb39ff8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > >1. Make subsequent offers valid initial offers. This means adding some > language explaining how the endpoint processing initial offer can detect > that m=3D lines cannot be unbundled. Even if we add this language it will > have backwards compatibility issues with anything that has not implemente= d > it. > > > > I don=E2=80=99t agree with that suggestion. Because, in that case we coul= d have > done it from the beginning, as a general rule, without using port zero. B= ut > there were reason we chose not to allow shared addresses (with non-zero > port values) in initial offers. > We did come up with a=3Dbundle-only mechanism to ensure backwards compatibility, and none of us want to revisit that decision. However, I do think that it would be consistent with Postel's Principle for the answerer to properly handle the case where a 3PCC offer ends up with a shared address, rather than failing simply because the offer does not appear to be an initial offer. > > > >2. Make endpoints generate subsequent offers that are valid initial > offers in 3PCC scenarios. This is what draft 8843 bis does. > > > > Correct. > > > > However, keep in mind that it is not only about how to encode the port > numbers and bundle-only attributes. Sending an initial offer also comes > with a set of procedures. Some of those (e.g., ICE) I assume you will ha= ve > to do anyway, as the remote endpoint changes. > > > > >I would even be fine with webrtc endpoint not doing anything and adding = a > note to JSEP telling the 3PCC application to "fix" the offer and add m=3D > port zero and bundle-only attributes when it is sending subsequent offers > as initial offers to a new end point. > > > > I would be fine adding such text to JSEP. It could be an additional > sentence to the existing text. > > > > (However, I still would not say =E2=80=9Csending subsequent offers as ini= tial > offers=E2=80=9D. I would say =E2=80=9Ccreate and send an initial offer ba= sed on a received > subsequent offer=E2=80=9D, or something like that.) > This might turn out to be the simplest option, but as noted before, it will require several SDP changes and will be somewhat error-prone as a result (assuming anyone implements this at all). Accordingly I think #1 above is the least bad choice. --000000000000f1ab7505cfb39ff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=C2=A0

>1. Make subsequent offers v= alid initial offers. This means adding some language explaining how the end= point processing=C2=A0initial offer can detect that m=3D lines cannot be un= bundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented= it.

=C2=A0

I don=E2=80=99t agree with that= suggestion. Because, in that case we could have done it from the beginning= , as a general rule, without using port zero. But there were reason we chos= e not to allow shared addresses (with non-zero port values) in initial offers.

We did come up with a=3Dbundle-only mechanism to ensure backwa= rds compatibility, and none of us want to revisit that decision. However, I= do think that it would be consistent with Postel's Principle for the a= nswerer to properly handle the case where a 3PCC offer ends up with a share= d address, rather than failing simply because the offer does not appear to = be an initial offer.

=C2=A0

>2. Make endpoints generate = subsequent offers that are valid initial offers in 3PCC scenarios. This is = what draft 8843 bis does.

=C2=A0

Correct.

=C2=A0

However, keep in mind that it i= s not only about how to encode the port numbers and bundle-only attributes.= Sending an initial offer also comes with a set of procedures. Some of thos= e (e.g., ICE) =C2=A0I assume you will have to do anyway, as the remote endpo= int changes.

=C2=A0

>I would even be fine with w= ebrtc endpoint not doing anything and adding a note to JSEP telling the 3PC= C application to "fix" the offer and add m=3D port zero and bundl= e-only attributes when it is sending subsequent offers as initial offers to a new end point.

=C2=A0

I would be fine adding such tex= t to JSEP. It could be an additional sentence to the existing text.<= u>

=C2=A0

(However, I still would not say= =E2=80=9Csending subsequent offers as initial offers=E2=80=9D. I would say= =E2=80=9Ccreate and send an initial offer based on a received subsequent o= ffer=E2=80=9D, or something like that.)

=

This might turn out to be the simplest option, but as n= oted before, it will require several SDP changes and will be somewhat error= -prone as a result (assuming anyone implements this at all). Accordingly I = think #1 above is the least bad choice.
--000000000000f1ab7505cfb39ff8-- From nobody Sun Oct 31 22:59:51 2021 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 AF5C83A1036 for ; Sun, 31 Oct 2021 22:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 geUX6IiNOOjQ for ; Sun, 31 Oct 2021 22:59:44 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 DD2763A102E for ; Sun, 31 Oct 2021 22:59:43 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id r8so1781922qkp.4 for ; Sun, 31 Oct 2021 22:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IDmFvpyTjZHjxHEnj7cLelIqGSRvnd2qpV/enmDULps=; b=ItwSPeEat1vOR0r47VJt7PUjv3GKsu2Nx1byezUK82Eluo+rt3l3RIKL++TzJdioi8 jnB/wXu21boTpMTGbHd2ux4j8kx6jxPu8AHuDgusemWgonuvDcQx/bqZDDDziEoshpQ6 BKvHdjJnuCebp5Cv3mZ7UQnwlirCBO5349wKc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IDmFvpyTjZHjxHEnj7cLelIqGSRvnd2qpV/enmDULps=; b=PJgjYYMRUNv8WGs2xJcNskl46IIlYoYcc0JRw/ppOCieI2ppTMHI/iYcpj7o34izdG MJFCXLOjgfV++Hat0JPQe7gmpqPRLNJes6YQhcMM1KEPdgIqIkcHtQQAUGb3bzj3wlbI 76VsPwJ1mzGS357zHGWhBf+5J7UQVOAmx+UH4SOjyR7bzZ/npmNYvQRw0b6fnYLiD6+S pJRklmR8UA5rbTCXX69SK4Y7laMMwmovi33bIrQZccxxo+qfZ+EE/50T0scbChDkb2AS iV28DRRj8KwdjC5wY3wE4hccJuzjGl0FQud6QrJksSgb3qE/HMNrY2Au7TNdzDnanSZk 67Vg== X-Gm-Message-State: AOAM532VkBYeEDRKTi8IxWwHSXhCgk6uGcNBCvYZ4xW4PZJ0uKAl6kAM Stz0ezyPWC8M4T1XYL9LJIPDvEwvaNS9Jg== X-Google-Smtp-Source: ABdhPJxe33bWV17Ne/8eafpBOeMM5RuvMUW8rPIagZV49vgeQblZiqR3HDptJp2LBXBvgBHa64NUkg== X-Received: by 2002:a05:620a:430d:: with SMTP id u13mr21183439qko.93.1635746379215; Sun, 31 Oct 2021 22:59:39 -0700 (PDT) Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com. [209.85.219.172]) by smtp.gmail.com with ESMTPSA id w5sm10090685qko.54.2021.10.31.22.59.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Oct 2021 22:59:38 -0700 (PDT) Received: by mail-yb1-f172.google.com with SMTP id d204so41986468ybb.4 for ; Sun, 31 Oct 2021 22:59:38 -0700 (PDT) X-Received: by 2002:a05:6902:110d:: with SMTP id o13mr33277141ybu.121.1635746377795; Sun, 31 Oct 2021 22:59:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 1 Nov 2021 01:59:25 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="000000000000ca8a1305cfb3e1da" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2021 05:59:49 -0000 --000000000000ca8a1305cfb3e1da Content-Type: text/plain; charset="UTF-8" On Sun, Oct 31, 2021 at 7:46 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >2. Make endpoints generate subsequent offers that are valid initial > offers in 3PCC scenarios. This is what draft 8843 bis does. > > > > Correct. > > > > However, keep in mind that it is not only about how to encode the port > numbers and bundle-only attributes. Sending an initial offer also comes > with a set of procedures. Some of those (e.g., ICE) I assume you will have > to do anyway, as the remote endpoint changes. > > > There is already PeerConnection.restartIce() which will cause the next offer created after restartIce call to initiate ICE restart, set new ufrag/pwd, and collect new candidates. This is the method an end point would call before generating an offer for 3PCC (or to recover a connection which failed due to bad connectivity). It would not be illogical to set port zero and bundle-only for all bundled m= lines in this case, when max-bundle policy is used. Best Regards, _____________ Roman Shpount --000000000000ca8a1305cfb3e1da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Oct 31,= 2021 at 7:46 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
=

>2. Make endpoints generate subsequent offers tha= t are valid initial offers in 3PCC scenarios. This is what draft 8843 bis d= oes.

=C2=A0

Correct.

=C2=A0

However, keep in mind that it i= s not only about how to encode the port numbers and bundle-only attributes.= Sending an initial offer also comes with a set of procedures. Some of thos= e (e.g., ICE) =C2=A0I assume you will have to do anyway, as the remote endpo= int changes.



There is already PeerConnection.restartIce() which will cause the next off= er created after restartIce=C2=A0call to initiate ICE restart, set new ufra= g/pwd, and collect new candidates. This is the method an end point would ca= ll before generating an offer for 3PCC (or to recover a connection which fa= iled due to bad connectivity). It would not be illogical to set port zero a= nd bundle-only for all bundled m=3D lines in this case,=C2=A0when max-bundl= e policy is used.

Best Regards,
_____________=
Roman Shpount
=C2=A0<= /div>
--000000000000ca8a1305cfb3e1da-- From nobody Sun Oct 31 23:02:42 2021 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 B48773A103D for ; Sun, 31 Oct 2021 23:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=telurix.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 rFT0AysXr0KI for ; Sun, 31 Oct 2021 23:02:35 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 62B2C3A1036 for ; Sun, 31 Oct 2021 23:02:35 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id t40so14923642qtc.6 for ; Sun, 31 Oct 2021 23:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zlC/W83pibnotNbiVTQed9UPR2TYfeWqYQdvYfihxRc=; b=F2ikEHas3ZWWKcc65m6pnLtlfl6K81zoaSq9yRfQGmEbF2rVWAxwtd1rcxei8vRNn8 emR8aBeRqTwAy+dyLKi5cT1plclDVqPv5N9gG0CEhKdSRy20T4bp8uN3CW7sUoBjHaQ4 H3f3xx1Vyc1xtxWkTyRVDHOg3xL2Kj+7+XhLU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zlC/W83pibnotNbiVTQed9UPR2TYfeWqYQdvYfihxRc=; b=1a2fqO6i7Rv27z4744c6P6utURqvJJCvGbpmNENQIC3r0JBA8CHs8+WSxWRZs9Ey/q 3G/niLBfAHQRER4M8mxxpeQEorw5S3otxtaAxFcIWJw69dbo9/WJ3fQc2o4xqVufAGye utqiNOUqdbgQswtwQnnrdL4Ip+Z+rNyBk4z0+uMRD3ZlEav/qrkQ0zrSONGD7dqf3uXU wemVwPLsxoV8dzfuw4CRwCPVvC718+kty2QMSC4vUzgKirpNrezTtSOnRByZhBA1Tzpp xXe5Bn3Uwj9Np6ezKeDi8ImdB+vuP01cdntIOsZLnTFf16SjGlDIxSqOKM79mhRYKgoa gaNA== X-Gm-Message-State: AOAM530zdwbljlzZiAY9faiDxSkeWDN23vR+3M3Y1ceA4mNhCy6jDsrF MGlOMJ7VdIykTtcvZtF0Bql/Kr2AdoJjuQ== X-Google-Smtp-Source: ABdhPJw0i6luq1snRf4o6U9HvkoOavoPfJG2uKPk4Eb/bxI7pol+aIrQHyNSclJPaJcWjNnBVarnbQ== X-Received: by 2002:a05:622a:244:: with SMTP id c4mr28246042qtx.186.1635746550637; Sun, 31 Oct 2021 23:02:30 -0700 (PDT) Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com. [209.85.219.177]) by smtp.gmail.com with ESMTPSA id v3sm11002105qtc.25.2021.10.31.23.02.30 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 31 Oct 2021 23:02:30 -0700 (PDT) Received: by mail-yb1-f177.google.com with SMTP id v64so35514408ybi.5 for ; Sun, 31 Oct 2021 23:02:30 -0700 (PDT) X-Received: by 2002:a25:f205:: with SMTP id i5mr29139857ybe.61.1635746549822; Sun, 31 Oct 2021 23:02:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 1 Nov 2021 02:02:16 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Justin Uberti Cc: Christer Holmberg , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000000b784305cfb3ec39" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2021 06:02:41 -0000 --0000000000000b784305cfb3ec39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 1, 2021 at 1:41 AM Justin Uberti wrote: > > >> >> >1. Make subsequent offers valid initial offers. This means adding some >> language explaining how the endpoint processing initial offer can detect >> that m=3D lines cannot be unbundled. Even if we add this language it wil= l >> have backwards compatibility issues with anything that has not implement= ed >> it. >> >> >> >> I don=E2=80=99t agree with that suggestion. Because, in that case we cou= ld have >> done it from the beginning, as a general rule, without using port zero. = But >> there were reason we chose not to allow shared addresses (with non-zero >> port values) in initial offers. >> > > We did come up with a=3Dbundle-only mechanism to ensure backwards > compatibility, and none of us want to revisit that decision. However, I d= o > think that it would be consistent with Postel's Principle for the answere= r > to properly handle the case where a 3PCC offer ends up with a shared > address, rather than failing simply because the offer does not appear to = be > an initial offer. > >> >> In case of trickle ICE, would shared address be detected by the absence of ICE ufrag and pwd in the bundled m=3D line definition? Best Regards, _____________ Roman Shpount --0000000000000b784305cfb3ec39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 1, 2021 at 1:41 AM Ju= stin Uberti <juberti@a= lphaexplorationco.com> wrote:

=C2=A0

>1. Make subsequent offers v= alid initial offers. This means adding some language explaining how the end= point processing=C2=A0initial offer can detect that m=3D lines cannot be un= bundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented= it.

=C2=A0

I don=E2=80=99t agree with that= suggestion. Because, in that case we could have done it from the beginning= , as a general rule, without using port zero. But there were reason we chos= e not to allow shared addresses (with non-zero port values) in initial offers.

We did come up with a=3Dbundle-only mechanism to ensure backwa= rds compatibility, and none of us want to revisit that decision. However, I= do think that it would be consistent with Postel's Principle for the a= nswerer to properly handle the case where a 3PCC offer ends up with a share= d address, rather than failing simply because the offer does not appear to = be an initial offer.


=

In case of trickle ICE, would shared address be detecte= d by the absence of ICE ufrag and pwd in the bundled=C2=A0m=3D line definit= ion?

Best Regards,
_____________
Roman Shp= ount
=C2=A0
--0000000000000b784305cfb3ec39-- From nobody Sun Oct 31 23:06:02 2021 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 5D77D3A103E for ; Sun, 31 Oct 2021 23:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=alphaexplorationco.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 rTujYz3aLVQI for ; Sun, 31 Oct 2021 23:05:55 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 465BF3A1038 for ; Sun, 31 Oct 2021 23:05:55 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id n11so15402913oig.6 for ; Sun, 31 Oct 2021 23:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UfMh4nW85ImLeqGX+GOnBliwDEDju/GXRHVUDL73wLE=; b=T42Xu/TXDThCvlnZgTh4rAgcJfqwASv80n7F3tAy1DZYsSva7QAb8Pf8+4NclkNCLp PPZvRTMW9cv6HXFoXhEwW8s9sZxyRfPWHRoxIquPm76QLWTwzUZpT3hVMIeckN1Ejqe9 34XbOyJ8tKyCSMVfZyqAw4FkYTlMuFF5yjQr8l7FfA1ApSzpEsdMa/sRR9VcZvS6YY5Q 4xvbJgUk+fcO4+tpBM88H5EMgzpx0omxHwkL4pg6nWo4y3z2ttJqagbfevzlf0K3p4/m Ld12ChJN/+n8Y4JipT9GURxAgDQ2TQjPIY2Gz4jJoD14TvujvpEROiZQgjIeX4+E+j1s 4CCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UfMh4nW85ImLeqGX+GOnBliwDEDju/GXRHVUDL73wLE=; b=XoIyJNHIxnB9kKene0eZMMHcwK4SYbRuJM1IA3QK3ltga5vWJKNhQu04TtaHUlB3lP NpDPct9PyZxHRIvg/rmB1VRIr9d+woDvXVmyrncwHv2MqRLA6Wabxdp/aiaxj0J19H/0 yomE2gBd3ewnml6AhkvMeERkfPIaYrwjyJTWsVqsT8DTG90LqBlwtSsd47Mia7FkKVEm 2iWFNnmAXPIyJI6RnNVaVUnvnA9MIlFfxKeP/s8aTEei4BDc/Q9jR/1RHbLq9Y2xLb+i p97duruOu4sRiralnqjOkUeO6yBjK/IeWhpxYkodLGBti2UvRHqWQYAP88uz/77YNy7o Kqyw== X-Gm-Message-State: AOAM53196/Jg/1UXD9OmqwYFkI73fJXVvjEmvcVutbGIaOdMfOidAJ8w HrDSX3229DAIT1i1SeRyakernYd7lz3xrO5+Ix0+CppSc8KiOBcL X-Google-Smtp-Source: ABdhPJzQni+Au5p/AO+iVE53Kj/EH+DR+khKs590VNMZb9F/AFS+OR0WNFwHriRA2GcVW91HWpMFtf0eKGpBxc3yRqc= X-Received: by 2002:a05:6808:1385:: with SMTP id c5mr673828oiw.126.1635746752800; Sun, 31 Oct 2021 23:05:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Sun, 31 Oct 2021 23:05:42 -0700 Message-ID: To: Roman Shpount Cc: Christer Holmberg , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000024b8da05cfb3f85f" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2021 06:05:59 -0000 --00000000000024b8da05cfb3f85f Content-Type: text/plain; charset="UTF-8" On Sun, Oct 31, 2021 at 10:59 PM Roman Shpount wrote: > > On Sun, Oct 31, 2021 at 7:46 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > >> >2. Make endpoints generate subsequent offers that are valid initial >> offers in 3PCC scenarios. This is what draft 8843 bis does. >> >> >> >> Correct. >> >> >> >> However, keep in mind that it is not only about how to encode the port >> numbers and bundle-only attributes. Sending an initial offer also comes >> with a set of procedures. Some of those (e.g., ICE) I assume you will have >> to do anyway, as the remote endpoint changes. >> >> >> > There is already PeerConnection.restartIce() which will cause the next > offer created after restartIce call to initiate ICE restart, set new > ufrag/pwd, and collect new candidates. This is the method an end point > would call before generating an offer for 3PCC (or to recover a connection > which failed due to bad connectivity). It would not be illogical to set > port zero and bundle-only for all bundled m= lines in this case, when > max-bundle policy is used. > Right, but that could happen for normal ICE restarts, in which case it would be an invalid subsequent offer. --00000000000024b8da05cfb3f85f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Sun, Oct 31, 2021 at 10:59 PM Roman Sh= pount <roman@telurix.com> wr= ote:

On Sun, Oct = 31, 2021 at 7:46 AM Christer Holmberg <christer.holmberg@ericsson.com> w= rote:

>2. Make endpoints generate subsequent offers tha= t are valid initial offers in 3PCC scenarios. This is what draft 8843 bis d= oes.

=C2=A0

Correct.

=C2=A0

However, keep in mind that it i= s not only about how to encode the port numbers and bundle-only attributes.= Sending an initial offer also comes with a set of procedures. Some of thos= e (e.g., ICE) =C2=A0I assume you will have to do anyway, as the remote endpo= int changes.



There is already PeerConnection.restartIce() which will cause the next off= er created after restartIce=C2=A0call to initiate ICE restart, set new ufra= g/pwd, and collect new candidates. This is the method an end point would ca= ll before generating an offer for 3PCC (or to recover a connection which fa= iled due to bad connectivity). It would not be illogical to set port zero a= nd bundle-only for all bundled m=3D lines in this case,=C2=A0when max-bundl= e policy is used.

Right, but t= hat could happen for normal ICE restarts, in which case it would be an inva= lid subsequent offer.
=C2= =A0
--00000000000024b8da05cfb3f85f-- From nobody Sun Oct 31 23:06:35 2021 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 77B673A103E for ; Sun, 31 Oct 2021 23:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=alphaexplorationco.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 8WxConFJxrWQ for ; Sun, 31 Oct 2021 23:06:29 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::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 897AA3A1038 for ; Sun, 31 Oct 2021 23:06:29 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id o4so23479513oia.10 for ; Sun, 31 Oct 2021 23:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphaexplorationco.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UQIsUqBGCx+K3TFCFEPo1HfPQc7WqECA1fnWM5PCmMo=; b=j3pbwwJRZbnTU4yJg0cn+RuRPADVqj2yPiBGy0dxQZ4HvE7G2du/m9qyld4DpWJqAJ RI5s+r1yTZputVg7NATh1gPgt0vBOClob5iH8LhbDHWnBWK9+6xAGZ9Dpuui1ehEjvgM 9kC8jy7+V5dGe3TblVROXr3mU8iscRdimwdBSkf8MujjI2V70bGQO64JqZdQid190TgK SyC+vz7kdfBhoarR4hARBwWeVnr8JTgIbKwzwd2WhSN0NiiKmpFt6hJS3eq8lmyZZxn1 y3VeCCWQu8lHelfGhcFKxyuyiyJc6K3h2kQTg2GotgNwmBQYHQkApu5tAAL6uLy/RtoY YleQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UQIsUqBGCx+K3TFCFEPo1HfPQc7WqECA1fnWM5PCmMo=; b=5cQ6HBZMCrlD1VVZrUzRTRPIVA30e+nHInqNhRic0MQaDgGK7K49PwTkA+4Fldcwyd f6cGMpVnaDZvsSag81X6vdFOcuf+Qcne37ygIjsURSYhXzXF3qX0WWHRSHcXZWVUwc// 4moVJlvnWr/HREW1m/O+fa1Pq1k/R/WgLijuJ7tB8b2XNC8UR4a7cmMvGELrHSbpSrOd u5Q8Teq2x4wslJ7TeY5R0P7BRpxfo4UBxgAzoR3rHqPLQ7WvOt0c/SHCmANR2sMEJ/qA SYcLmAGYjzx1AEMR9s7BPW/ZMxBZMwESglo/yEi3qM89NXq4db/E9Dp6EujkQvL2aELR zWFg== X-Gm-Message-State: AOAM530nBb9nhnBTaAV7wGH7PD2xDReJn60zZR3XZOtLJ4yqpIZHy4um T6FYA8ZWdbLw4kPbuBbGVHJrUx6B0cYAq41yv9Heuxm3IN3mxQ== X-Google-Smtp-Source: ABdhPJzLZXi/xAClBk2L8LWnRL3x6x3rg9wuky35IsWEHk958PX0HFQGJpEX+DobMKpxl61rbImigHQtRD+jk3yk/wk= X-Received: by 2002:aca:ac0f:: with SMTP id v15mr15245302oie.46.1635746785998; Sun, 31 Oct 2021 23:06:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Sun, 31 Oct 2021 23:06:15 -0700 Message-ID: To: Roman Shpount Cc: Christer Holmberg , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="0000000000001f540f05cfb3fa57" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 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, 01 Nov 2021 06:06:34 -0000 --0000000000001f540f05cfb3fa57 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 31, 2021 at 11:02 PM Roman Shpount wrote: > On Mon, Nov 1, 2021 at 1:41 AM Justin Uberti < > juberti@alphaexplorationco.com> wrote: > >> >> >>> >>> >1. Make subsequent offers valid initial offers. This means adding some >>> language explaining how the endpoint processing initial offer can detec= t >>> that m=3D lines cannot be unbundled. Even if we add this language it wi= ll >>> have backwards compatibility issues with anything that has not implemen= ted >>> it. >>> >>> >>> >>> I don=E2=80=99t agree with that suggestion. Because, in that case we co= uld have >>> done it from the beginning, as a general rule, without using port zero.= But >>> there were reason we chose not to allow shared addresses (with non-zero >>> port values) in initial offers. >>> >> >> We did come up with a=3Dbundle-only mechanism to ensure backwards >> compatibility, and none of us want to revisit that decision. However, I = do >> think that it would be consistent with Postel's Principle for the answer= er >> to properly handle the case where a 3PCC offer ends up with a shared >> address, rather than failing simply because the offer does not appear to= be >> an initial offer. >> >>> >>> > In case of trickle ICE, would shared address be detected by the absence o= f > ICE ufrag and pwd in the bundled m=3D line definition? > yes, exactly. --0000000000001f540f05cfb3fa57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Oct 31, 2021 at 11:02 PM Roma= n Shpount <roman@telurix.com>= ; wrote:
On Mon, Nov 1, 2021 at 1:4= 1 AM Justin Uberti <juberti@alphaexplorationco.com> wrote:

<= div>

=C2=A0

>1. Make subsequent offers v= alid initial offers. This means adding some language explaining how the end= point processing=C2=A0initial offer can detect that m=3D lines cannot be un= bundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented= it.

=C2=A0

I don=E2=80=99t agree with that= suggestion. Because, in that case we could have done it from the beginning= , as a general rule, without using port zero. But there were reason we chos= e not to allow shared addresses (with non-zero port values) in initial offers.

We did come up with a=3Dbundle-only mechanism to ensure backwa= rds compatibility, and none of us want to revisit that decision. However, I= do think that it would be consistent with Postel's Principle for the a= nswerer to properly handle the case where a 3PCC offer ends up with a share= d address, rather than failing simply because the offer does not appear to = be an initial offer.


=

In case of trickle ICE, would shared address be detecte= d by the absence of ICE ufrag and pwd in the bundled=C2=A0m=3D line definit= ion?

yes, exactly.=C2=A0<= /div>
--0000000000001f540f05cfb3fa57--