From nobody Thu Oct 1 13:04:19 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B2F3A048A; Thu, 1 Oct 2020 13:04:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, dispatch@ietf.org, barryleiba@computer.org, dispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160158265616.2819.12555563525084459675@ietfa.amsl.com> Date: Thu, 01 Oct 2020 13:04:16 -0700 Archived-At: Subject: [dispatch] dispatch - New Meeting Session Request for IETF 109 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 20:04:17 -0000 A new meeting session request has just been submitted by Ben Campbell, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Ben Campbell Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 90 Conflicts to Avoid: Chair Conflict: rum stir sipcore mmusic ecrit avtcore cfrg quic httpbis add Technology Overlap: perc cellar capport dmarc jmap uta rmcat extra core opsarea tsvarea tsvwg tram secdispatch Key Participant Conflict: acme cose dprive lamps tls mls People who must be present: Barry Leiba Ben Campbell Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, and Bofs.. --------------------------------------------------------- From nobody Thu Oct 1 14:27:20 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6EF3A086B for ; Thu, 1 Oct 2020 14:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYUstW2-EO49 for ; Thu, 1 Oct 2020 14:27:09 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 811D83A0954 for ; Thu, 1 Oct 2020 14:27:09 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id k2so5100436ybp.7 for ; Thu, 01 Oct 2020 14:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FwMdrVMrDdv+Y53NiGwvO51/ZjO6x52D74q+xWPFEK8=; b=pVaDAKoZvKoi7gvyHfp/jmD6OAJGyukp9NSD0tqdS/0a5jpCPDzKiUC+HZrL2wUvE6 pBhvKOxYVda32ksgXrpHoKX/ATHgYj7GwS2PSzqsj2CeaUUiTClE/L4u6Cbh/mPRsvqU h+pz7PYJa/kbpa/EkZLbKwy/RAalY82ff7YylH+aLj/AdWcM1oEZBs1RftnqSmVstj9G w9xf1P7IICO6rJCRMou5Pe3PA8vSjhCXVJaom4DBFeqLZynfQVQS0YsWnEVc8XJPZcYP sbRI5j89CPrGkwPk1S40XKRr7JzNKv1EZPLhxq3+cBTXmEbvG12bnV9ghA3THEmYWk1b omzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FwMdrVMrDdv+Y53NiGwvO51/ZjO6x52D74q+xWPFEK8=; b=ILoPTs0LmfvwVcfGEWhc0IPtnd4dJ9xFZnTvHYJ9sr+xp7hAlry69N3YRGAP4SxjB9 uJCyaNCm2987AqqVVNhYJw/y5l5rzszabhVBrmwOyVdeXwTk6Ro6Rb5S8/IpaaHFxN6V ySH9w80kFz3/pOMcUBCqaibNbATRNRzIcmDGEYJkHQDY6qTIwTAYk5E2HNQwSo57bwYA 1OO9Q8q96cYDT87gca9HLl2bwl48GmwTzm7w5Y7BW83S0rPRRiXcpiWlRUn94FTb1lbk /tSpHjJIhmifTFrufLjBDAt2snrU8vZgOixBEFBt2f84ifFWIe9nV/kUlXQm5Q2HOIZq L/vw== X-Gm-Message-State: AOAM532gPhGG81MHdc/YnUo9ngZ/av3hlq5+ZMfYJqxnfSIerVUifkMk 6LhFWgz30hY7WX5QdF25j16mf6yTc5yIdUIZ07Cg X-Google-Smtp-Source: ABdhPJwi1BouAmhwE0QXr4xdPj9I7NZffFFeRiA+MuVckAhAS6fKhBJgCPtqaPqG1U1AwKRb6M+edUq0eyBV7ZZI6Aw= X-Received: by 2002:a25:c014:: with SMTP id c20mr12573421ybf.12.1601587628229; Thu, 01 Oct 2020 14:27:08 -0700 (PDT) MIME-Version: 1.0 References: <159949693494.2875.16993532753477402380@ietfa.amsl.com> <5c6c96621b29ebf4b1f84e53ae3a414c9d0ec3a5.camel@ericsson.com> <05085c6c-0c30-a407-8f41-b6c9be8100bc@gmail.com> <49b13e5efa0b2ac0a7b09842dbce8793dfcf6667.camel@ericsson.com> In-Reply-To: From: Emad Omara Date: Thu, 1 Oct 2020 14:26:55 -0700 Message-ID: To: "Murray S. Kucherawy" Cc: Magnus Westerlund , "dispatch@ietf.org" , "sframe@ietf.org" , "rlb@ipv.sx" , "sergio.garcia.murillo@gmail.com" , "iesg@ietf.org" , "sergio.garcia.murillo@cosmosoftware.io" Content-Type: multipart/alternative; boundary="000000000000a8cd9805b0a2adc8" Archived-At: Subject: Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Oct 2020 21:27:13 -0000 --000000000000a8cd9805b0a2adc8 Content-Type: text/plain; charset="UTF-8" Hi Murray, I have updated the charter Google doc here Please go ahead and copy it to the datatracker. Thanks Emad On Tue, Sep 29, 2020 at 7:38 AM Murray S. Kucherawy wrote: > On Tue, Sep 29, 2020 at 5:58 AM Magnus Westerlund 40ericsson.com@dmarc.ietf.org> wrote: > >> > Would these address your concerns so we can move forward? Please let me >> know >> > if there is anything else I missed. >> >> Yes, I belief so. >> > > OK, then please let me know when the github version has been updated, and > I'll copy it into the datatracker for the IESG to see. > > -MSK > --000000000000a8cd9805b0a2adc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Murray,

I have updated the charter G= oogle doc here=C2=A0Please go ahead= and copy it to the datatracker.

Thanks
= Emad

On Tue, Sep 29, 2020 at 7:38 AM Murray S. Kucherawy <superuser@gmail.com> wrote:
On Tue, Sep 29, 2020 at 5:58 AM Magnus Westerlund <magnus.west= erlund=3D40ericsson.com@dmarc.ietf.org> wrote:
> Would these a= ddress your concerns so we can move forward? Please let me know
> if there is anything else I missed.

Yes, I belief so.

OK, then please let = me know when the github version has been updated, and I'll copy it into= the datatracker for the IESG to see.

-MSK
--000000000000a8cd9805b0a2adc8-- From nobody Fri Oct 2 08:56:42 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280063A1067 for ; Fri, 2 Oct 2020 08:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQ951OA-SIVx for ; Fri, 2 Oct 2020 08:56:37 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::1]) (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 8E0CA3A0FCC for ; Fri, 2 Oct 2020 08:56:37 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kONQB-000I1I-LY for dispatch@ietf.org; Fri, 02 Oct 2020 17:56:35 +0200 Date: Fri, 2 Oct 2020 17:56:35 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF DISPATCH list Message-ID: User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 15:56:40 -0000 Hi, We are seeking advise from the Email community regarding the following: In the LAMPS WG we are working on so called "Header Protection" for Emails to achieve better privacy. This concerns in particular (but not only) the Subject Header Field that is often left unencrypted in otherwise encrypted email. The mechnism used for Protection of Header Fields is to wrap a whole email (including the Header Section) into another email and apply protection to the former. At the receiving side certain Email clients do not render such signed/encrypted emails correctly to the user, leading to "weired artefacts" and thus bad User Experience (UX). Such clients do not distinguish between forwarded mail and signed/encrypted emails (wrapped in a similar way as forwarded messages). Alexey came up with a proposal to help such email clients to make this distinction (with the intention to improve UX). Together with Alexey I wrote up this proposal to an early draft version: https://tools.ietf.org/html/draft-melnikov-iana-reg-forwarded-00 This I-D suggests a new Content-Type Header Field Parameter "forwarded": If set to "yes", the contained message was forwarded; if set to "no", the message was "wrapped" for signature/encryption with Header Protection. However, I am concerned that the (binary) scope of the Content-Type Header Field Parameter may be too narrow, as there a potentially more cases an email message is transported in the Body part of another email message and such a Parameter may be helpful, such as: - Rejected (non deliveries / bounces) - ML-hold (message to be assessed by a mailing list admin) - ML-discard-action (mailing list admin reply to this will discard) - ML-digest-item (mailing list digest item; digest is a collection of multiple emails) - even more? I am seeking advice (mainly from implemeters of MUAs) on: 1) Is it helpful/useful/needed to enhance such a Parameter for these additional cases? 2) Have there been problems in the past to distingish such cases from "forwarded" messages? We'd appeciate your feedback (preferably within the next 10 days)! cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology From nobody Fri Oct 2 10:19:56 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A4F3A113F for ; Fri, 2 Oct 2020 10:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=s8XaUxmZ; dkim=pass (2048-bit key) header.d=taugh.com header.b=Ag23f6yG 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 QpG3tzuid_3w for ; Fri, 2 Oct 2020 10:19:48 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 918273A1138 for ; Fri, 2 Oct 2020 10:19:46 -0700 (PDT) Received: (qmail 24126 invoked from network); 2 Oct 2020 17:19:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5e3c.5f77612f.k2010; bh=JXNGNeeqYin9yvYUB60J/A82F3SIBztKMt6D6LsqgWk=; b=s8XaUxmZfbqR1GIt9VlIODMEtMPb4F0TYgRzOHdcCSccnDJDFLRo70dHV6NmU5MepFHKx6AQDrrJcBtOvS4SEbDxAXKswNEgq0re1wdygH0PMAyXMyS1LEpAzNYLIkJpAnUp98v+wvVWCuDeTtjkpTddbIqNpbPK6t6HvA7urIPiAoq6gaXXmd0/llqwm50HEXz+slLaqQptK6VGRP4ou5fjO5LhYrhCZEpN1olFVUi+GZ/i80tS9BnpKEWNgob6zBOViNC4CEGu9/olET4+9+KX5cV6fxgUGPEhcLoTHx7B9ySYfcmmfRJSAEIsj7aU4/T5Hmuvl6RasbJ8KlGs6Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5e3c.5f77612f.k2010; bh=JXNGNeeqYin9yvYUB60J/A82F3SIBztKMt6D6LsqgWk=; b=Ag23f6yG0uVonOchdHN1Up9iB6uQ7unztYwcrvAIAGIkdQkq80c3vxZOlW5w3APmin6YonJ439uh5VwjqOopEYt+uFf+ybUgSd8v2avkiG5VPwmfgDANPomaE+CZCcLJX8Sg2f4KtFMuSf8tnH2bYGCEcMs7VXlYiJHbVmXbuF+MeCJA5X9Ha7abPHYOfZDM3aJo8s8N2+7x2JYpHiMoHI8yYMFyXK7lP55bVF4CjO6wQ+TSLfI71lx+0C194HOQrliYA6e+Mg7n6kdtZoQu8ncFZ+8RQVIlR/dWikkgiOrhbZNzlTTb3Rk4RerdVCcMGjYKd9UOGTxCTcWpkuIQiA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 02 Oct 2020 17:19:42 -0000 Received: by ary.qy (Postfix, from userid 501) id 7223822D65C8; Fri, 2 Oct 2020 13:19:42 -0400 (EDT) Date: 2 Oct 2020 13:19:42 -0400 Message-Id: <20201002171942.7223822D65C8@ary.qy> From: "John Levine" To: dispatch@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2020 17:19:55 -0000 In article you write: > https://tools.ietf.org/html/draft-melnikov-iana-reg-forwarded-00 > >This I-D suggests a new Content-Type Header Field Parameter "forwarded": >If set to "yes", the contained message was forwarded; if set to "no", the >message was "wrapped" for signature/encryption with Header Protection. >email message is transported in the Body part of another email message and >such a Parameter may be helpful, such as: ... >1) Is it helpful/useful/needed to enhance such a Parameter for these > additional cases? Probably not. Since a receiving system cannot trust senders to accurately label the messages, it's hard to see what they would do with the labels. I looked at the draft and while I have my doubts about how useful it will be, since there are implementations it seems at worst harmless. R's, John From nobody Fri Oct 2 20:45:57 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537FA3A1783 for ; Fri, 2 Oct 2020 20:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.985 X-Spam-Level: X-Spam-Status: No, score=-0.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 GYtB8w9jDIgL for ; Fri, 2 Oct 2020 20:45:55 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [69.252.207.39]) (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 DD63D3A1777 for ; Fri, 2 Oct 2020 20:45:54 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id OYRskpT0X2perOYTek4wUC; Sat, 03 Oct 2020 03:44:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1601696694; bh=atsjgTo4DgWPt861Wfgxqp+uv/JC0ZZ0cWO66RRzbAY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:MIME-Version:Content-Type; b=XcPDum6Q1uQ+c2fFbX7lQM0G+R9JuWZFyIEeG6r/2/i5xWHdMvqV31zHytGAydcEw rs0xKUOSeEGR7KIN5ON27XWzhndnXNHXsYtjCGQvlo8E7IXrczb3PmHONA8TWy7rV3 P/PT4d/znVqp93GRDTznAAQYhXt/LRwgp0/RBSYBa+TTjiDR/XBJHXBW1zp0jgihjO bkCaMotSnriC0iUjkubhOdaNRPrLwTVDV5EMLDn9KFxjcwusU+HVy3m7L3xg7x9IAM C25U6nrH/JA50p47OcRQRzkBHij7EuZ64tcA7SHX8rHyFTmki0IPDa9tWX/04XdmZ3 yZNsAgBCVTZoA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-01v.sys.comcast.net with ESMTPA id OYTckQ9HLcJbsOYTdkmLAJ; Sat, 03 Oct 2020 03:44:54 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 0933iq6R010877; Fri, 2 Oct 2020 23:44:52 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 0933iqRs010873; Fri, 2 Oct 2020 23:44:52 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Bernie Hoeneisen Cc: dispatch@ietf.org In-Reply-To: (bernie@ietf.hoeneisen.ch) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 02 Oct 2020 23:44:51 -0400 Message-ID: <875z7s55xo.fsf@hobgoblin.ariadne.com> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 03:45:56 -0000 Bernie Hoeneisen writes: > This I-D suggests a new Content-Type Header Field Parameter "forwarded": > If set to "yes", the contained message was forwarded; if set to "no", the > message was "wrapped" for signature/encryption with Header Protection. There's a category problem: What you're trying to capture is "What is the significance of this body part within the whole structure?" It does not describe the *type* of the contents of the body part. I've noticed this before in SIP, the idea that if you know the *type* of a body part, then you know its *significance*. That works in the simplest cases, but it's like saying that you can always tell which parameter in a function call means what if you know their types. What we need is a new "Content-Semantics" header for parts of multipart bodies which describes the semantics of this part within the whole. E.g., "contained encrypted content" or "forwarded message". Dale From nobody Sat Oct 3 08:08:43 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90043A0AF5 for ; Sat, 3 Oct 2020 08:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.451 X-Spam-Level: X-Spam-Status: No, score=-1.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=iecc.com header.b=o5efMu+k; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=taugh.com header.b=mW3gCmsy 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 tBRijqh2BO9Z for ; Sat, 3 Oct 2020 08:08:39 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 79BAB3A0AF3 for ; Sat, 3 Oct 2020 08:08:39 -0700 (PDT) Received: (qmail 27425 invoked by uid 100); 3 Oct 2020 15:08:37 -0000 Date: 3 Oct 2020 15:08:37 -0000 Message-ID: From: "John Levine" To: dispatch@ietf.org DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=6b19.5f7893f5.k2010; i=news@user.iecc.com; bh=ruvyNS221oOUh+eS5Prl0Tmv5zRw847pbGBCtRrc3aE=; b=o5efMu+kSVz9v7WXONe3zFzNppIlrDogb2YfAa0Yqj3hWFAHaM7ItFNahpbuSjcNCkjOonL9wPD/aASCH+OvMkNVy5/Ph+W5h70I63CV/MPBZR/k6UUr0r30TEuh7gy1cDM4lYwLihaPz2UJKQVUc/U88DHJZQqyZUDOWtdsVh7ktWwvUkXJ78sj3ncLRt2IatrvNnTcHT/HieuCoEi6sznTMwGSwzvZqIEpLdN3NjU3M5Mckht1wzUtiYZqdHamtz5NhjU/4keQ7by146eU8ew9OtZ6BsxOtSxvQ2VSiEsArpklyIHvYB1VfQtjVI5yJZgzbzK9yk4Iew1oVgX6kA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:references:in-reply-to:cleverness; s=6b19.5f7893f5.k2010; olt=news@user.iecc.com; bh=ruvyNS221oOUh+eS5Prl0Tmv5zRw847pbGBCtRrc3aE=; b=mW3gCmsytsE1R3Gwj/3wtpOfiLAInn3o9f21bOs6YATdOq1J5pXf/woqwYNLqdtaFC8Pg6jjdCjGH0YZwAYjriIa9RiOfgto9Z4lhDi4g9aQOgQlGHjx713Iq/nr1IF5GM5U44BDvAaj3nMSZxMG1kpn3rOngj3tAKtrR6A9VgP+9TbyijKfUnYT03WeqPvRpOB1w8q6WJOzhsMk/y4gS4Zemc+KiIIPuRoLoFot1cbaCCcJD7uYs0Zv1pVgqWbABlZHu5hIkK/gjEUsMqo/zFfheY6hV9kIAv8Fj1MfRtEk2G5c9P2ASkKZpKmJkSp90IxkH2+DqGZoiGBD1JyRbQ== Organization: Taughannock Networks References: <875z7s55xo.fsf@hobgoblin.ariadne.com> In-Reply-To: <875z7s55xo.fsf@hobgoblin.ariadne.com> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: johnl@iecc.com (John Levine) Archived-At: Subject: Re: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 15:08:42 -0000 In article <875z7s55xo.fsf@hobgoblin.ariadne.com>, Dale R. Worley wrote: >What we need is a new "Content-Semantics" header for parts of multipart >bodies which describes the semantics of this part within the whole. >E.g., "contained encrypted content" or "forwarded message". But you still have the problem that you can't count on senders to label their messages correctly. I can promise you that if word gets around that mail labeled "forwarded message" has a 1% better open rate than otherwise, all spam will have that label. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Oct 6 12:42:00 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C883A0DF9; Tue, 6 Oct 2020 12:41:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-hardie-dispatch-rfc3405-update@ietf.org, spencerdawkins.ietf@gmail.com, dispatch@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160201331828.15817.11413010978098286546@ietfa.amsl.com> Date: Tue, 06 Oct 2020 12:41:58 -0700 Archived-At: Subject: [dispatch] Benjamin Kaduk's No Objection on draft-hardie-dispatch-rfc3405-update-03: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Oct 2020 19:41:59 -0000 Benjamin Kaduk has entered the following ballot position for draft-hardie-dispatch-rfc3405-update-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 I suggest mentioning somehow in the prose that RFC 4395 was obsoleted by RFC 7595, to establish the last link in the chain leading to "the current process"; in the current form the RFC 7595 reference seems to lack any preceding motivation. (I also agree with the Gen-ART reviewer that spelling out "the requirement" more explicitly would be helpful; that suggestion seems to have gotten lost in the ensuing thread.) From nobody Wed Oct 7 17:22:26 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 781333A0A3A; Wed, 7 Oct 2020 17:22:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-hardie-dispatch-rfc3405-update@ietf.org, spencerdawkins.ietf@gmail.com, dispatch@ietf.org, spencerdawkins.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160211654041.6129.16890057221666014492@ietfa.amsl.com> Date: Wed, 07 Oct 2020 17:22:20 -0700 Archived-At: Subject: [dispatch] Alissa Cooper's Yes on draft-hardie-dispatch-rfc3405-update-03: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 00:22:21 -0000 Alissa Cooper has entered the following ballot position for draft-hardie-dispatch-rfc3405-update-03: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems the comment from the Gen-ART review was not addressed: "1. Introduction Part five of the Dynamic Delegation Discovery System (DDDS), RFC 3405 [RFC3405], describes the registration procedures for assignments in URI.ARPA. The document requires that registrations be in the "IETF tree" of URI registrations. The use of URI scheme name trees was defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 [RFC4395]. Since the use of trees was discontinued, there is no way in the current process set out in BCP 35 [RFC7595] to meet the requirement." This is indeed a nit, but I'd prefer s/the requirement/the above requirement/. The current text did make me briefly think "Which requirement?". From nobody Wed Oct 7 17:23:43 2020 Return-Path: X-Original-To: expand-draft-hardie-dispatch-rfc3405-update.all@virtual.ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0A38B3A0BB9; Wed, 7 Oct 2020 17:23:35 -0700 (PDT) X-Original-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Delivered-To: xfilter-draft-hardie-dispatch-rfc3405-update.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7C33A0A3A; Wed, 7 Oct 2020 17:23: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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=vXI2y+/4; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y4Y4dBeA 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 c0_CqaYjx599; Wed, 7 Oct 2020 17:23:33 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1273A0AB5; Wed, 7 Oct 2020 17:23:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 1654C602; Wed, 7 Oct 2020 20:23:32 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 07 Oct 2020 20:23:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=k zRztvwLu1W2vWawpD9fYfteYz1ikMXk3c77wVV7zKk=; b=vXI2y+/46Zea5j7E1 6+/B8qS3XxLiw5xwf1f5N0r4WEWkj/w/G9/Fx5F7/cFzRZIvM9E8ydA7WrN19N5o XWGb3GAtaS8XAKsXFjt8vVjeA2/x+WNcVnbiCK+qC6u0/bQPYZUu+wYOx0bqv6U6 AZV5VEY09vbOx2loJx4sSUTlhCzdDVuuXl6JW9qDoqTDEcuMuFM9r3+wQ+p27vo1 7kjTEHWb/ycQOPhvS8UFLuaFDwC1nB7zV5eU5f/QBbQIKIrvngD+VQebDiia73xw K0wGPzXqse17Z0Czykn+XZ2FSl2Kkc2dJIF6+aFRZR/30zr7TScuZ6w5F0iH5/m9 duFqQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=kzRztvwLu1W2vWawpD9fYfteYz1ikMXk3c77wVV7z Kk=; b=Y4Y4dBeAF6zVKpGsxHsvadf/aqzNhnUi5XMyuDo6H49NaZAwJsqztm60W tIotc9NnLFT65vAierWVJYjYQFZCLPaz4pXco+TXOJSvqvoxdCy7TwxPhf0SaC9R EzRII4xT/tgndFH1/P3CO9QtP+kz1sXy4XGE73N15K6kdvqbRm68CFxvijCbj70D Jy73r1c/0b1zrkP/trLsl/c6XyoXS2K/cRX7NO7PpW5Pn4sBCToZzj74dFI5y8d2 R3gzf8fNnLx9K4g7+qpfQJoIf66oMxPLS5h900k1afP1k/DyxVA5COM15HUcVTO5 rZw6UqVT4IHx/srsbubNWjGwnk6Ow== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeejgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepfeduhffgtefgtedvvdffiedutdekffegvdejjedtieehfefgleefuedtledv gffgnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurd elkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D5753280059; Wed, 7 Oct 2020 20:23:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <159893058662.23844.17177953972396775177@ietfa.amsl.com> Date: Wed, 7 Oct 2020 20:23:30 -0400 Cc: Review Team , draft-hardie-dispatch-rfc3405-update.all@ietf.org, last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <21E5259F-41DD-4D4E-A80F-3CE24D9F16C2@cooperw.in> References: <159893058662.23844.17177953972396775177@ietfa.amsl.com> To: Brian Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) Resent-From: Resent-To: ted.ietf@gmail.com, superuser@gmail.com, barryleiba@gmail.com, barryleiba@computer.org, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Resent-Message-Id: <20201008002335.0A38B3A0BB9@ietfa.amsl.com> Resent-Date: Wed, 7 Oct 2020 17:23:35 -0700 (PDT) Archived-At: Subject: Re: [dispatch] [Gen-art] Genart last call review of draft-hardie-dispatch-rfc3405-update-03 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 00:23:35 -0000 Brian, thanks for your review. I pointed to your comment in my Yes = ballot as it looks like it was never addressed.=20 Alissa > On Aug 31, 2020, at 11:23 PM, Brian Carpenter via Datatracker = wrote: >=20 > Reviewer: Brian Carpenter > Review result: Ready >=20 > Gen-ART Last Call review of draft-hardie-dispatch-rfc3405-update-03 >=20 > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. >=20 > For more information, please see the FAQ at > . >=20 > Document: draft-hardie-dispatch-rfc3405-update-03 > Reviewer: Brian Carpenter > Review Date: 2020-09-01 > IETF LC End Date: 2020-09-24 > IESG Telechat date: =20 >=20 > Summary: Ready (with micro-nit) > -------- >=20 > Nits: > ----- >=20 >> 1. Introduction >>=20 >> Part five of the Dynamic Delegation Discovery System (DDDS), RFC = 3405 >> [RFC3405], describes the registration procedures for assignments in >> URI.ARPA. The document requires that registrations be in the "IETF >> tree" of URI registrations. The use of URI scheme name trees was >> defined in RFC 2717 [RFC2717] but discontinued by RFC 4395 = [RFC4395]. >> Since the use of trees was discontinued, there is no way in the >> current process set out in BCP 35 [RFC7595] to meet the = requirement. >=20 > This is indeed a nit, but I'd prefer s/the requirement/the above = requirement/. > The current text did make me briefly think "Which requirement?". >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Oct 8 07:24:21 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A5F3A0922; Thu, 8 Oct 2020 07:24:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160216705942.7136.6996382418393047028@ietfa.amsl.com> Date: Thu, 08 Oct 2020 07:24:19 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 14:24:20 -0000 IESG state changed: New State: Approved-announcement to be sent::AD Followup (The previous state was IESG Evaluation) Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Tue Oct 13 00:22:48 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4D3A0EC3; Tue, 13 Oct 2020 00:22:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <160257375965.19700.2194558246070562506@ietfa.amsl.com> Date: Tue, 13 Oct 2020 00:22:40 -0700 Archived-At: Subject: [dispatch] Magnus Westerlund's No Objection on charter-ietf-sframe-00-02: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 07:22:40 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-sframe-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks, this update address my significant issues with the charter. I think the charter might be giving a slightly skewed image of the granularity question. To my understanding the application data units (ADU) combined with SFRAMEs properties and the underlying transport will in combination define what granularity that are practical to accomplish. As an example an RTP payload format for SFRAMEs that would support multiple SFRAME objects for a set of ADUs belonging to the same video frame would provide great flexibility in how many SFRAMEs the ADUs are protected in. If each ADU is split into multiple SFRAMES that could be supported but maybe unnecessary as the codec likely are unable to process sub-ADUs, at the same time putting multiple ADUs into one SFRAME requires a seperation to exist above SFRAMEs. This type of questions will be application specific and dependent on underlying layers where to support which functionality. I have the impression that the proponents for SFRAME have a desire to have minimal support for this in SFRAME and rather rely on how the application and the transport is capable of applying SFRAMEs to achieve its confidentiality goals. From nobody Tue Oct 13 13:57:20 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BF53A1128 for ; Tue, 13 Oct 2020 13:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iav90eQpaMt for ; Tue, 13 Oct 2020 13:53:27 -0700 (PDT) Received: from outbound-ip20b.ess.barracuda.com (outbound-ip20b.ess.barracuda.com [209.222.82.217]) (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 7713A3A112C for ; Tue, 13 Oct 2020 13:53:27 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) by mx8.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Oct 2020 20:53:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O+eKDcEzkqprCNigFoyYQbNq1/0Xncfx/DPWiqLLq2Tzdrsxcu+a0kUAat/tFhbJTjQ1x6pJggv19isLv1ZKzyJSJ4LXy31huoQNP4i5XCRg38PlLEw1D3WnRD6V01wZBZYypYQblbpsobZhNwne5F0BdSDA9poYB332OA7dV1Ge1BqOa8f9tpXb4WhQ75nrcb4zkhv6fdTHfn74BiRPtis32kpT3NRSzh8MuZIw+WF4FiJqCd9A5hkCNJO2xH/JmllZgRtwQ7aFy3MgbXekzi42qkriUI9fqmVuAtmP9fvG9N6FLtetvQM45rSUlhIjCLOM4BXJf1VMeiIRhSC8hQ== 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-SenderADCheck; bh=4D6JfvvGJdwfltNQ08SHynZcb75S+9JR9+SSXKjK4Fg=; b=iZkHXiQh8ZkhBNsFRiNY1tzPn2psL6Oi3Otum16EFR6JNe8F51spwqe/RS8OyStQOGcbmjM+6uvo6X7VaELboj+hrtjAcLscCumBR0P2LHI7Bnt4bkKKzgP5YQgitEOujhXKE1V+vdj8BlmxVbQw/oDIk6MI+fcWrNRRtBx5jpXE4hQ1vP8njrUu/C6Lfi9LEGEhWMAvXjoYsmLSL4NyI6+/qTngx4wZf1UUQizYdTroceFdz0hk0lTVK5ZWV7FrOWVMbpRqxXb1g62HnWw0LI+yq8VPl4hlnbar/uYwSlQlWEKcYfLo9u0wPzWlogfRxAgjKPYu/3rU3376jPUV2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4D6JfvvGJdwfltNQ08SHynZcb75S+9JR9+SSXKjK4Fg=; b=ncpBa5WJuH1YHSXjCcvkKKSbFgFjFnUmqHXPfkGjn7fc6vWz3IYtkhGl+RCK6/uRsStyE4U+1yetgiRETUpV5TR4FjBcEQvfEC5Lbqn9prkjM45aQpD2KADWaUuC+p+EBtpNyOGzgl4sOO9dIBWRLnxq6284eB5q/h78JghCRpI= Received: from MW3PR16MB3914.namprd16.prod.outlook.com (2603:10b6:303:4d::19) by MWHPR16MB1726.namprd16.prod.outlook.com (2603:10b6:301:18::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Tue, 13 Oct 2020 20:53:18 +0000 Received: from MW3PR16MB3914.namprd16.prod.outlook.com ([fe80::6d3b:98e4:6bee:b6e8]) by MW3PR16MB3914.namprd16.prod.outlook.com ([fe80::6d3b:98e4:6bee:b6e8%8]) with mapi id 15.20.3477.020; Tue, 13 Oct 2020 20:53:18 +0000 From: Yeshwant Muthusamy To: "dispatch@ietf.org" CC: Chris Ullrich Thread-Topic: draft-muthusamy-dispatch-haptics-00.txt Thread-Index: AdahodZ9K85J5defSwWFGz7671meag== Date: Tue, 13 Oct 2020 20:53:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=immersion.com; x-originating-ip: [47.188.32.225] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d92414f8-9cff-420a-c9f6-08d86fba037d x-ms-traffictypediagnostic: MWHPR16MB1726: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K4rplkBSXzlvbiF80uqZ9hAceqAyopiMGMybaoszK455+J0VYGnce9k5u5lf4jkbLQviP/QdZc2cO/pXBgPZbWMP5rea9BHR0Le9BxZi5BW1ZjKFMXDijAxL01E4eEX5icZOBjUv+aHLhqCUkYBt0b2v2Zm1oAX9t25mlpii2MEwt00kjzteuTaiSLtvdk60JRnv9zBMf3tM+B6LMm4c+ct+IGogUs1+7bm6b5c1OSHw5Q1Rc/8EUgW6SrZyrm+vRRBOVVBm5NjmZj5LwTFpsthZD6Kww29FN3wNqzQREyvQXDxv26NA6M7+av53V/pvZ5wzv0fILDy2fCU+RUD2bdnRpf5piWACCOGCmDTxHtwhyddM6+z0miJYv82uwu+KdNL2uKOdw9cEPLtAAByK6g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR16MB3914.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(376002)(346002)(39830400003)(396003)(33656002)(64756008)(166002)(66476007)(66446008)(66556008)(107886003)(6916009)(966005)(6506007)(76116006)(478600001)(7696005)(66616009)(8676002)(9686003)(186003)(66946007)(2906002)(4326008)(8936002)(26005)(86362001)(5660300002)(52536014)(83080400001)(316002)(99936003)(55016002)(4744005)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MVlshTJLCtxXEw0YSIUbndF3jat1kfRfcB8WYbGM+gNXoGwk3GAQDHvS1ICrnMsGgy5ZbuS5sFrSaGTjXA/jYSrm/AvyejDHSjePJzq5BI9T61CvhJJd3mehQ+KBh4xELXz12opbXLcd5LEnXaqmH5T+oANwbhhqEl6uWJp39U7sjA0Up+XrLcjMy7PkcMgeOWnFxEwzcRMaTxnujNQ1y0OPwb2DUughaOiz6DQzwKOXQ/zq+mkETL5DJ2aplfoeDmoaKUpAteRgXMAZVqKqUcWWtn+28r5pKqwbaZqv3bVdoqWHyezZ3ywrhmqHMZO5mexG3zH2qGK0TW4QStbag4BlY6wSaEjs2r5IpGLE0PHm9TutyUBq8v6qpaPHrFIB4cNPO434IToOqHRtAWAlYPESWZbSlToS7HpNTCblleHFBkt9J77JtQsA/Mpi5J+fRQNDtJhom/S3IUVOg5LflTepUyW9PlK9+ITJW57FtCtnF6DEwcFwY2fZ+AmeJ1zGN+xmKBzTkJlgktpq06drqKa0734zdrQ2Plk2+0IYDIr55IIxUrwQWoRHUJzCx8NNENc4xfJhgRTZzKCfAzl7gynyyiSkKbT4W0u2NcvUzWtTvFn2Tylsvee3xAS/tfmimmKWqEzkE7T6D3lsICVEjw== Content-Type: multipart/related; boundary="_004_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR16MB3914.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d92414f8-9cff-420a-c9f6-08d86fba037d X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 20:53:18.4219 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r4Qd/qtFk4KjYR5acJH1ZmtqHcxlr2y69aMdx34KHDfMUxLR7w6p/TqUSDRIYXhCSMkJCinPo4ObiLl2MEeMqzinuXJNrmPeL15QC4XDElE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1726 X-BESS-ID: 1602622402-893015-10488-9802-1 X-BESS-VER: 2019.1_20201013.1803 X-BESS-Apparent-Source-IP: 104.47.58.168 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.227532 [from cloudscan9-76.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: X-Mailman-Approved-At: Tue, 13 Oct 2020 13:57:19 -0700 Subject: [dispatch] draft-muthusamy-dispatch-haptics-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 20:53:30 -0000 --_004_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_ Content-Type: multipart/alternative; boundary="_000_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_" --_000_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to initiate discussion on draft-muthusamy-dispatch-haptics: https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ An informal (and earlier) version of this document was discussed on the Med= ia-Types mailing list (media-types@ietf.org): https://mailarchive.ietf.org/arch/msg/media-types/3cXb69ybEa65oCCIiHjl0MtGX= VY/ Look forward to your questions and comments. Thanks, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards [cid:image001.jpg@01D6A178.8A25D150] ymuthusamy@immersion.com | +1 469-583-2171 --_000_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to initiate discussion on draft-muthusa= my-dispatch-haptics:

 

https://datatracker.ietf.org/doc/draft-muthusamy= -dispatch-haptics/

 

An informal (and earlier) version of this document w= as discussed on the Media-Types mailing list (media-types@ietf.org):

 

https://mailarchive.ietf.org/arch/ms= g/media-types/3cXb69ybEa65oCCIiHjl0MtGXVY/

 

Look forward to your questions and comments.

 

Thanks,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Standar= ds

ymuthusamy@immersion.com | +1 469-583-2171

 

--_000_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_-- --_004_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5147; creation-date="Tue, 13 Oct 2020 20:53:18 GMT"; modification-date="Tue, 13 Oct 2020 20:53:18 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/4QP0aHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MSA2NC4xNDA5NDksIDIwMTAvMTIvMDctMTA6 NTc6MDEgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0idXVpZDo1RDIwODky NDkzQkZEQjExOTE0QTg1OTBEMzE1MDhDOCIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpBMEI4 RUIyQzA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpB MEI4RUIyQjA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQ aG90b3Nob3AgQ1M1LjEgV2luZG93cyI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjAxODIwNjY3NUYwNkU1MTFCQUZDQjk1NEQ4MTUyNEMyIiBzdFJlZjpkb2N1 bWVudElEPSJ4bXAuZGlkOjdlYjc0ZTdmLWMwMTAtNDUwYi1hODBhLTM4NmQ2ODUxMDQzYyIvPiA8 ZGM6dGl0bGU+IDxyZGY6QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPlByaW50PC9y ZGY6bGk+IDwvcmRmOkFsdD4gPC9kYzp0aXRsZT4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJE Rj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz7/7QBIUGhvdG9zaG9wIDMuMAA4QklN BAQAAAAAAA8cAVoAAxslRxwCAAACAAIAOEJJTQQlAAAAAAAQ/OEfici3yXgvNGI0B1h36//uAA5B ZG9iZQBkwAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAgEBAgICAQICAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIACcAkgMBEQACEQEDEQH/xACVAAAB BAIDAQAAAAAAAAAAAAAABggJCgQHAQMLBQEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAAGAgECAwII CA8AAAAAAAECAwQFBgcICQAREhMUIRUxMjQWFzcYGWEiVDW2ODkKQWIjU2MkZCVVZVZ3t3iIEQEB AQAABQMFAAAAAAAAAAAAAREhMUFxMoECQmGxEtID/9oADAMBAAIRAxEAPwCzfzV7CXrCOtWL61hy 2TdWzjmrZfClExipWpBwym1nsXbWdwfmMm1ds1H8E4VgWsc+bnOKDosmRusUyaxg6CH+u8m+RsdZ +5D9qMbtmtui867o6w6qa/0yYeSkjWLf9GZZyu3ixw8O0kWgtl3+J65G+a5b/jN5G0x51CqdgIe5 dzqLbVKvtKyRDubDQrVB3CDaT9mqzmVr0i3k2CNips/I1e0Q6jhsdRMHsLPxLhqsTv7FEh7dyiAj BlTFyqNdl6tX5+0V6EnbxJPYelwstMx0dK22WjYl7PyMZWo924Sdzj5hBxrh4sk2IqdJsidQwAQo iAKXoDoDoDoDoDoDoDoDoDoE7HW2qy9gsdTirJAydop5IZS2V2PlmDybrBLG1cPoA1gi266j2G99 sWqizT1BExcIkE5PEX29AougOgOgOgqE7aZ2yjstyCR2H80RFbx3m7jjuGd834iqVOVkntdzdjpK gM8t0SwV9zMOkZZDNFKhaXXZoqP8oykmnvFZuiwXY+ikAiS16sDalfd/y7dNhJMMI69bpb4EiFUU XbMcyUezbCMKQtKMVe6a7xeZ1ZpRVjmKJiMCJm9oJgUAuIcKuNnOOONrXNSVdLSFiyVFWXMtjlHD j1K8k/yjbJq0x7pdbxqHO5CtvGCaonMJzKpmMbsYRKAY2+8zglltrxiweUsBo5Svlpz1b08RZIJk OapDzDNgrcXVZ1WYPCRES9RyFGyj9NiqeMeOGjci8ckcTHATkEMDfjk7semOd8Ha90rV+ybGXvYC sTL2ix9WvzeryatvazBYOErasU5pk8kaKkHR/NeSYu0ixzYp1TIKEIYwWTQ26L5ms7R2RJfVO+cd uR2W+nvuBZ0rX2sZXp8zTLjWZ6AlrKreXmZQjD1Wq1utR8emV+4EJBoUVgP6kgJPCNIHu6D79v8A buWzjijKWFpnXPZTW2xQ8BlvEsrZGVwYt21hTkTQNhrdpYsYxvMR780Sv5hU0VEkSHbqJuHCLlFU 1swNCvPLnsHL7TZ/081g0Dns9ZXwVYHCb+WDNleqNTeUeOYNHD+1TDqxVGMa16Vcv5Fu1YRQvnBn oqGMkudQgN1IEdT+bfLmfqpLudTOO7K+Yb/iesubFs7UZ7I0DQo7Cj+Ol7AxXpMZMydaXkslW6UZ 1h0uyZso1tIqJ+wrJVwi4apBLNqLtvjTcPWukbN0cXNdqNpi5ZxNxlmXaNnlKmaw9exVuh5t4ByM /JhJGNWEjvumk4Z+W5ACEUAoBEjK86FkYGY56R0pyO447XmUVMVE24UtzFKScuGs4pAOr2yxcSBX kTVAJUgt0fNdpFXWTOgDkr8h48ly8uokR5C994LQnXuq7EK0E+XazYslUekKR8Nbm9aURg7hGTsw e2RUiaAsjWaMyj4QTIMxK2TeCsX+tIgHiFJbcg0rj7k7srfUDN+7mzWsF41xxFRiwMxiKDl51nPX vMFUtho+MqMijErR8AFef2exTDJugRcvpiIugceeo2IK5mccCw043L3Fz9kpKtZ34+LfrbjmyY7H J1Jyo6ypA3qGVinLiMJDVmysmUBDqxNvlW0oVYGJzpSKBElBWZJpkMoWBGal3LBlk5NOR2vUjX5H HOXKDG4QjMnZgaZHmZtpmBGegHEtHOj42VhYyv0iSjSokTcuW7h6tImTKqoYhxU8wE9sXyiZTrme sqa/aY6eWncax64V6PtOyc/E3yNoleoBJBso+a0qvqvYSZWul7dsElDFZM/G8Fds4btmjxVs7BqD 1tXdx8c7c6sw20WKGzhSHkq9YXcjUJl4i1mK1bqok6JP0ufctEXxGrlo/a9k3JUTlcMlkXaaYprE KNzjghtpvO1sTk3B8ptLj3jRt0zrli924YZ5vpc/VhQ9XeIPUTviUeNdUaJnbsyr1bfsn8g7TjiI NlXJkHHpUUfWqsu51Ep33mmpv+sZL9S/7eP5ta/UZ/MfnL6wv8j+UfxuoKzX7wTDZJ1q5FMIbe02 DZli7RjWvJRsvJMHz6tz1yoL6wQVup9nRTXbFcs5SiTMa3dNkl0DuY50cpRKYDn66fz6pTENcb3g nYd9QMc09MMA5WrmGdt8PVTF1nsU9bcX5bJsZizJULXali66TD0k3R7bAZFvJ3sLXrU4k2ku8UD+ /wD1vpmDnmq4vw02yXtfGtrCSxMXURZKVXbdiqfg5FsqxloKQxNka345Ti5iOXTSdR0mhHVtAyqC xCKpifscAN36DSHJZ+vdw2/9jssfohTetTxoRu2aZFedjitKqmRQoYk2gUAqhSnKCiOJssqpKABg EAOkqQpij8JTAAh7Q6Txo4Mmmf8AeJUzHTIcyPHOKiRjgUxklByaokKiYiAiQ4pKmL3DsPhMIfAI 9Ph6js1Q/bt8qX+0Grf/ABDiPpfGBV8f6KJuUvmlcGSSFwla9M0ElxTKKxEV8YZIOskmqJfGRJY7 ZMTlAexhTKI/FDsvjBjcOUbHx985XCsWLVoCXJ9sdGp+nbpJGJHxs0AR7EDkKBhasQcqeUn38Kfm G8IB4h7y8oGd6MupOr8CG669RQ9K8iIXehGOI0BREYtghBzzZy7ZenVQM3Vh4nzFkTFN2TMiUexg Dwjfn6hEa/aP8ge2HF7iHCEHs5rRAaw5TxJTnEdTHWG59zcIeOb2NjdkmkhaUXpwXsLG3xnmuXKZ AAzgpxIBQEO0ly6HCc2+PXOP+L/VvFNkftrM8pOa9WcfT8n5axmdgc1qhWatyj7yngncGbSyrJRT wqiJxKp2N3Hv0nOdxMDutqjVd0NXco6z2SVXqjC+Q0cSDsccyRdq1OzVmYjbLUJkkcc7cj2Pj56G bg7aEVbmdsBWbkWRFQFSJbLsEevH5t9sXQc6Bxlb5VmObZ8o+OSWTC+bq68Vc1jYbGNcTMxSkTlc N26qloZxkauqd4QqYvAYPE3bdq9aHM8gTmhX7YTmE/8AM36DO+g54TCpyFk5QrTIB59sm+RbNLWd kliFK8dNI10LuMQX7GL4UWjyZfCmmBCFTFUwF9nsLr3eQSvD2gzhcWcp9PgVzjT6pvZtBH1RkCBm bZnFpwMaybi2YGVcCwIuxjW/dHzDgTwAHcR7iNvOeg0tx9ooh+7iZ7EEkwFXXXfdVUQTL3UWTiMs kTWUHsPjVIRAgAYe4gBCgHwB1m873EAvvB/+XPP2PHu/5St8g/Ifj/I/6L4n4Ot/si8lyEak1bdb U/K+DZ+Parzz+Ae2HGUyq2TXeVbKNeZuntMm2CggCzcFZABYvQSMmdzGPHLfxAVY3XNXl1pqKIqE VSOdJVI5VElUzGIomoQwGIchyiBiHIYAEBAe4D16Eem5xS3iSyhx/wCt2TbAyTb2+9053NXiRKmZ Nzbbk0n5avWC+y34pSr2C+PYQZeQXAoeqevFVh7mUMYfOr4+52sOVM37ScdmWKI0hHFQ1rzFfbpk 9aTmUY5+0g7DX67GxykKxUTOeXcmcxqoHTIJRIAAP8PQJ7PGqGXsg8o+i+11cZwKuIcBY+zjXMhv Hc4g1nm0nfcf3+uV4kVBmSMvKIqSVibAqcpigkQTGHv4egPsn5e+95+2V6OB+hP7Hn0Leu99ofOL 58fPf396f3B5XqPdvoPb6jx+Hxfi9urvDAYH1Qy9j7lH3o2usbOBSxDn3H2Dq5jx40nEHU85k6Fj +gVywklYMqRV4tFOSrrkEjmMYFSAUwdvF1AoNT9YcqYg3g5Jc8XNpCoY/wBnbDrfJYrcR8yi/lXb bGVHu0BaRm4xNMqsMZKRnG4IAcxvOIJjB28PQHHtrDlTXG175y+S2cI1ZbB7yZqz3jk0PMoyyjnH 15kknMC5lk0k0zRcqokQfNam8Rkx9gj0Cb429NLrgbS2662bGwsC4Xvd+zk4sMLCTZJmMkqJlF65 Q9IpItCoeWs/hXihFSF7HSE3w9+gZJg7AXMponTHeo+tkLqznDBcLZ7G4wnm/MVinISZx5TrNMvp xaGulQgpOIl5J41k5Rd0mVm3lE27hVUpVF2vkNkb14h7PLTqjmTcbWeg4yw9H11zcoLP2L8jy7Wb sKcPGI1+rsrOlNi1knbRP1a6K0skCRBSTOqXuPYvYQ6S2XYHhbUqbPo4Vsi+nrfFzzOzd9AOq20z CrLpUp5GNJpk5skc49zCk5PIScIis2beNdqkVRbxiukJSmCCNrWfWDd7MO79U3t3sg8R4lkcQ4dm cU4hw1iKfd2dQJC0GfpWa122aUdzMf6ZdrNPgbt0X7g/dVuAgn6Y53Thg3Tqvqfl7EvIVyF7H3Bn BI4z2P8AoW+jJ0wnEH0y6+Y1YcRU974iSIlVifLdqACXjMbzC+0OrtzOgaveNWORDULanZ7L3HxW cLZSxbuc+a3S203KdmGsvcO5tOEgaWyKggovEtbDASMpNvZBdBqss6ei4BBZAPSIrOJ35B7GhWks rpvpw+whL2Rldst3p1kDImW7izOsSLs+WsiMytpN2ycPGrR8uwYR7CPjyOXKRFnJGfnmTS8zyUwb bqbo3nrD/DrlLSy5x9Yb5xtmHdq6XEMI+yNn9bPOZdY5AQpya9hTRI3QbLKWNt6hQSCCACbv38PV t26ImfuWt4f8Cxv+z6+zn9YUf9Zf5L8k/M/9r+J+Dq/l99FqbY5TJKeAcz/Q5FRs1lZXGV1bY8j5 mXjoGIUt7yvv2sEvJy8udOLZsGL9Yi6ouDppGIkJTHIBvGGRQC1x4rqHd7bFK7H8hOgOEcdorpK2 AkBtvg/IORnzUqoioxr0dC2xentXDlJMSi7dyYlaioQ4NnPY6Qb33/U4PQE19ruIahhDFNUwDI16 XwtWqLXYHGcrU59ja6/J1GIj0WEVIR9njXT5nYgeooeYo9IsqLpYx1DHMYwj1gbi6A6A6A6A6A6A 6A6A6A6A6A6A6A6A6A6D/9k= --_004_MW3PR16MB3914A096D819769AB0EC9382DE040MW3PR16MB3914namp_-- From nobody Tue Oct 13 14:22:58 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B7B3A113E for ; Tue, 13 Oct 2020 14:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQhX6CVrwbau for ; Tue, 13 Oct 2020 14:22:53 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::1]) (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 2D4633A0A3B for ; Tue, 13 Oct 2020 14:22:52 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kSRkw-0008jx-37; Tue, 13 Oct 2020 23:22:50 +0200 Date: Tue, 13 Oct 2020 23:22:50 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: John Levine cc: IETF DISPATCH list In-Reply-To: Message-ID: References: <875z7s55xo.fsf@hobgoblin.ariadne.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 21:22:57 -0000 Hi John IMHO the point you make can be made to almost any addition to the email standard: It may be misused by the evil side. I fail to grasp what benefit a spamer could gain by specifying whether an encapsulated message is a forwarded or a wrapped message. Marking an encapsulate messaged as "forwarded" makes it even less likely that the user gets the content to see. Explicitely marking an encapsulated message as "not-forwarded" does not make any sense, as one may as well just not encapsulate the message. There is no difference on whether or not it is displayed to the user. Have I missed anything? cheers, Bernie -- http://ucom.ch/ Modern Telephony Solutions and Tech Consulting for Internet Technology On Sat, 3 Oct 2020, John Levine wrote: > In article <875z7s55xo.fsf@hobgoblin.ariadne.com>, > Dale R. Worley wrote: >> What we need is a new "Content-Semantics" header for parts of multipart >> bodies which describes the semantics of this part within the whole. >> E.g., "contained encrypted content" or "forwarded message". > > But you still have the problem that you can't count on senders to > label their messages correctly. I can promise you that if word gets > around that mail labeled "forwarded message" has a 1% better open rate > than otherwise, all spam will have that label. > > R's, > John > -- > Regards, > John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Oct 13 14:56:33 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0103A1197 for ; Tue, 13 Oct 2020 14:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iNX2nRBsJ02 for ; Tue, 13 Oct 2020 14:56:30 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [IPv6:2a01:4f8:c0c:15fc::1]) (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 0A8B23A1196 for ; Tue, 13 Oct 2020 14:56:29 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kSSHT-0008ow-4u; Tue, 13 Oct 2020 23:56:27 +0200 Date: Tue, 13 Oct 2020 23:56:27 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: "Dale R. Worley" cc: dispatch@ietf.org In-Reply-To: <875z7s55xo.fsf@hobgoblin.ariadne.com> Message-ID: References: <875z7s55xo.fsf@hobgoblin.ariadne.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2020 21:56:32 -0000 Hi Dale On Fri, 2 Oct 2020, Dale R. Worley wrote: > Bernie Hoeneisen writes: >> This I-D suggests a new Content-Type Header Field Parameter "forwarded": >> If set to "yes", the contained message was forwarded; if set to "no", the >> message was "wrapped" for signature/encryption with Header Protection. > > There's a category problem: What you're trying to capture is "What is > the significance of this body part within the whole structure?" It does > not describe the *type* of the contents of the body part. > > I've noticed this before in SIP, the idea that if you know the *type* of > a body part, then you know its *significance*. That works in the > simplest cases, but it's like saying that you can always tell which > parameter in a function call means what if you know their types. > > What we need is a new "Content-Semantics" header for parts of multipart > bodies which describes the semantics of this part within the whole. > E.g., "contained encrypted content" or "forwarded message". No sure how exactely you suggest to apply such a header. The use case also includes situations that are not multipart, such as Content-Type: message/RFC822. In the following example, the upper part with Content-Type: message/rfc822 is an "outer" message containing a forwarded message with Content-Type: text/plain (lower part). The suggestion in the I-D would look as follows: [...] Content-Type: message/rfc822; forwarded=yes Content-Type: text/plain; charset="us-ascii" [...] Can you please clarify whether your suggestion would be to use: [...] Content-Type: message/rfc822 Content-Semantics: forwarded Content-Type: text/plain; charset="us-ascii" [...] or: [...] Content-Type: message/rfc822 Content-Type: text/plain; charset="us-ascii" Content-Semantics: forwarded [...] ? cheers, Bernie From nobody Thu Oct 15 11:47:23 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E6C3A12FE; Thu, 15 Oct 2020 11:47:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160278762498.6279.12834691771462136672@ietfa.amsl.com> Date: Thu, 15 Oct 2020 11:47:04 -0700 Archived-At: Subject: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 18:47:05 -0000 A new version (-04) has been submitted for draft-hardie-dispatch-rfc3405-update: https://www.ietf.org/archive/id/draft-hardie-dispatch-rfc3405-update-04.txt https://www.ietf.org/archive/id/draft-hardie-dispatch-rfc3405-update-04.html The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ Diff from previous version: https://www.ietf.org/rfcdiff?url2=draft-hardie-dispatch-rfc3405-update-04 Please note that it may take a couple of minutes from the time of submission until the diff is available at tools.ietf.org. IETF Secretariat. From nobody Thu Oct 15 12:31:31 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95153A1375; Thu, 15 Oct 2020 12:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 RUFIQTOECric; Thu, 15 Oct 2020 12:31:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 4368B3A1362; Thu, 15 Oct 2020 12:31:22 -0700 (PDT) Received: from oxusgaltgw01.schlund.de ([10.72.72.47]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0Lan5K-1k0NjU3nCK-00kRl6; Thu, 15 Oct 2020 21:31:20 +0200 Date: Thu, 15 Oct 2020 15:31:20 -0400 (EDT) From: Timothy Mcsweeney To: internet-drafts@ietf.org, barryleiba@gmail.com, dispatch@ietf.org, spencerdawkins.ietf@gmail.com Message-ID: <695687617.30027.1602790280802@email.ionos.com> In-Reply-To: <160278762498.6279.12834691771462136672@ietfa.amsl.com> References: <160278762498.6279.12834691771462136672@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev23 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:o3Ssoging3TvEQYHGst3oG8mab5bziAU9ZNESZzOBh1kBksFOSG yvxQ4VnxMwpM8qMg1XY2wlCrWv9sKq45KEcbGXfRPfjTUXRaW7UEyVbUW5Ua+E+USHHmleH jPtprG5ko+/hNqDAPE0L6xa1hPc5Y0lAkqLVoExF0bW3qrOPt9SVaDQtoY0HvnZINqmflV/ JRD2ero4pDy7o5HWOVn5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:CAPnUAJ29O0=:GvVPephaJCW8PrIjki3ZVj RVGDKlEi7hrP+FH/nXUhDP31m5iQ+0DSrjS6w+VYasNzeNQxu4Kx/Dg2+JAmG3aK/OD95ESlm 7kJUQV5PQSL+i4CzwgsqxQHXdy5CnM2U64GjXQmwzdOAKHQmL7A8V+yBlYtOv1Pwld1gWTF6V 3iDpyiYrvpkSrCzafXmZpCVUrGwKPYFoIGq/WrnM8X6G0TZBjlWC+C2oMu2xc71E3gJIB6KKk jsH+95/UrKCj0k4rFyP84BI+teydo3++xamMUDBlOsWq2tKIre+APx9f5Ssi7qpkQJ8Ho5utG cgjnWgTnI9CWuIGxZeAHkhbXSX4MYA+5jxXlnVaMYTnk0Kdh+AzCBNz9NswRW+dc4+RW8K40w RhW+ybnlofzu39uH0CgrOmzcffTS1OJO9XQH09ksV1dWdbMGpR1IZEqYo8x789TlYfuwynQHt MgRxPNBGVw== Archived-At: Subject: Re: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 19:31:30 -0000
I would like to see the following changes made to this version (-04) because it does not specify what will be exactly will be reviewed:

2. Updated Requirements
This document removes and replaces the normative requirements from sections 3.1.1
and section 3.1.2 of RFC3405 with:
The registration of a NAPTR record for a URI scheme MUST NOT precede registration of that scheme.  IANA will review the request against for
  1. correctness and technical soundness (eg. valid databases, service parameters etc.) and
  2. consistency with the published URI resolution application specification [RFC3404], and
  3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain.

3. IANA Considerations

This update does not change the IANA submission procedure in Section 5 of RFC 3405.


_______________________________________________
dispatch mailing list
From nobody Thu Oct 15 12:53:04 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7943A1338; Thu, 15 Oct 2020 12:53:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160279158302.14391.5535880896226418816@ietfa.amsl.com> Date: Thu, 15 Oct 2020 12:53:03 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 19:53:03 -0000 IESG state changed: New State: Approved-announcement to be sent (The previous state was Approved-announcement to be sent::AD Followup) Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Thu Oct 15 13:19:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122803A0061 for ; Thu, 15 Oct 2020 13:19:18 -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 2REkSz22f91g for ; Thu, 15 Oct 2020 13:19:16 -0700 (PDT) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 6FCC03A0045 for ; Thu, 15 Oct 2020 13:19:16 -0700 (PDT) Received: by mail-oo1-xc32.google.com with SMTP id x1so73501ooo.12 for ; Thu, 15 Oct 2020 13:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mAyeIGyGDYO0pIUiO4RIeT6BI+kGFR6NwuGMyd0Qo54=; b=tnzjpAUkoN6q0rR0/ijdqab2fHzf2grjAhI2OKvl/wpTd+9gEi9LDBN50c0xr2BJEE JhPvMpGOSJqr+5/wgw3CIQ4UekVr7weJreM4UFGy8q3/4WEmJeKp7Vm7L4WkSn8S0dml hcmWpWpWf8Agk05RI1pW1vhbmX61Py2WT+8TLcdPjW1IbIwsp5z5JzDzPiIvzG54q6cm BptHJyY/IQ99NHKhAyHVtOxxsnb4a7WHx+mVWY7Zmoga0NzpkxnO4gukrYi5YGekBrC6 /Wwi/4eDby28m87xsM53qUE8+5SuYgKA8whw6rrvo5G+SOyLCDlWlz1/y4r5X7U23x0E llXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mAyeIGyGDYO0pIUiO4RIeT6BI+kGFR6NwuGMyd0Qo54=; b=iit19m+DUXgApz7d+tPRGfyo7fiBIO07IXoc3cIc3dNcJhR6DbISZuCfIrcS1Aodg+ gyXEmay+lUlkqBmq2OY1QRwFIFWxLMOr0A4rf4CmgBst9ehf/MhxI4DlzPsBtnG+lCfx 639Znu0N40a1ksETclZs4ywvIxygS+w2c+56Bpka7bE4MxuHleN1U07xEcfU8M9FzLfd R5jpLFUsSH0LEX05Bcxo9T4dW9xrkNkWgRW2pNRH4EVaoCow1DxJnsm5zRgifbbv1522 MW1iCiFAfKK6KR5f/viKQWq+SgI7UvDlMSrweJ+TPevrpOcXwG5y63wrlrM5vFSoiGEE Lt0w== X-Gm-Message-State: AOAM530V8vhLBwP8Z50gfdGGZ4JhH2NP0j8+CZi9+gIREEvirYh0hchD Gkvkx2MrM6dN+p54y6ZFO+DxF+gn29TuO4y845M= X-Google-Smtp-Source: ABdhPJxHHqo6SQJsPUAbziej1LeYMGU/TrK1hRb7riEwRBmw2IvntwKaRd8+V1s+ETeuqwzHINQQr6oliRo/78jwv2Q= X-Received: by 2002:a4a:6f4d:: with SMTP id i13mr177903oof.25.1602793155633; Thu, 15 Oct 2020 13:19:15 -0700 (PDT) MIME-Version: 1.0 References: <160278762498.6279.12834691771462136672@ietfa.amsl.com> <695687617.30027.1602790280802@email.ionos.com> In-Reply-To: <695687617.30027.1602790280802@email.ionos.com> From: Ted Hardie Date: Thu, 15 Oct 2020 13:18:49 -0700 Message-ID: To: Timothy Mcsweeney Cc: Barry Leiba , Dispatch WG , Spencer Dawkins Content-Type: multipart/alternative; boundary="000000000000b0a8f205b1bb5c82" Archived-At: Subject: Re: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:19:18 -0000 --000000000000b0a8f205b1bb5c82 Content-Type: text/plain; charset="UTF-8" Hi Timothy, The two small changes done for this version were to respond to IESG comments which sought to improve the clarity of the existing proposal; they did not introduce new elements to the proposal in the document. I think your comments propose a much more significant change, and document updates post-IESG processing is not the time for that type of change. If you wish to see other changes, I suggest you propose them in a new document. regards, Ted Hardie On Thu, Oct 15, 2020 at 12:33 PM Timothy Mcsweeney wrote: > I would like to see the following changes made to this version (-04) > because it does not specify what will be exactly will be reviewed: > > 2. Updated Requirements > This document removes and replaces the normative requirements from > sections 3.1.1 > and section 3.1.2 of RFC3405 with: > The registration of a NAPTR record for a URI scheme MUST NOT precede > registration of that scheme. IANA will review the request against for > 1. correctness and technical soundness (eg. valid databases, service > parameters etc.) and > 2. consistency with the published URI resolution application > specification [RFC3404], and > 3. to ensure that the NAPTR record for a DNS-based URI does not delegate > resolution of the URI to a party other than the holder of the DNS name. > This last rule is to insure that a given URI's resolution hint doesn't > hijack (inadvertently or otherwise) network traffic for a given domain. > > 3. IANA Considerations > > This update does not change the IANA submission procedure in Section 5 of > RFC 3405. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --000000000000b0a8f205b1bb5c82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Timothy,

The two small ch= anges done for this version were to respond to IESG comments which sought t= o improve the clarity of the existing proposal; they did not introduce new = elements to the proposal in the document.=C2=A0 I think your comments propo= se a much more significant change, and document updates post-IESG processin= g is not the time for that type of change.=C2=A0 If you wish to see other c= hanges, I suggest you propose them in a new document.

<= div>regards,

Ted Hardie

On Thu, Oct 15, 2= 020 at 12:33 PM Timothy Mcsweeney <tim@dropnumber.com> wrote:
=20 =20 =20
I would like to see the following changes made to this version (-04) bec= ause it does not specify what will be exactly will be reviewed:

2. Updated Requirements
This document removes and replaces the normative requirements from sect= ions 3.1.1=20
and section 3.1.2 of RFC3405 with:
The registration of a NAPTR record for a URI scheme MUST NOT precede re= gistration of that scheme.=C2=A0 IANA will review the request against for
=C2=A0 1. correctness and technical soundness (eg. valid databases, ser= vice parameters etc.) and
=C2=A0 2. consistency with the published URI resolution application spe= cification [RFC3404], and
=C2=A0 3. to ensure that the NAPTR record for a DNS-based URI does not = delegate resolution of the URI to a party other than the holder of the DNS = name. This last rule is to insure that a given URI's resolution hint do= esn't hijack (inadvertently or otherwise) network traffic for a given d= omain.

3. IANA Considerations=20

This update does not change the IANA submission procedure in Sectio= n 5 of RFC 3405.


_______________________________________________
dispatch mailing list
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--000000000000b0a8f205b1bb5c82-- From nobody Thu Oct 15 13:26:47 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809D63A02BC for ; Thu, 15 Oct 2020 13:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 Ocgu7ml7eO_5 for ; Thu, 15 Oct 2020 13:26:39 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 C598F3A010A for ; Thu, 15 Oct 2020 13:26:38 -0700 (PDT) Received: from oxusgaltgw01.schlund.de ([10.72.72.47]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1N5VsU-1kMzxv06ag-016sxL; Thu, 15 Oct 2020 22:26:37 +0200 Date: Thu, 15 Oct 2020 16:26:36 -0400 (EDT) From: Timothy Mcsweeney To: Ted Hardie Cc: Barry Leiba , Dispatch WG , Spencer Dawkins Message-ID: <894177016.33315.1602793596709@email.ionos.com> In-Reply-To: References: <160278762498.6279.12834691771462136672@ietfa.amsl.com> <695687617.30027.1602790280802@email.ionos.com> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev23 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:NTprg9RD5cSIillPNB2HoR3jqxfPXc0+hiDldtJOLUvj6w/Lk16 h6Jtph4dtn9gUjWP8ISV1z6Qy1/e7rWkpoJN8KlF8gOasZbI6DqkrOJ0VAE6y6isCu5NdhY GFBroCQT3Qc65CFD+p/QfgTY4C903jQSadQTRBpBr9+MgAlnxmhnZo4N3JCAOubwvzILSJa 5QWhPkjcL71vonmEJsP6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:jg91ibTbEZI=:rLB60r8jq3lgx/hVntYjM1 i2kJobr//gWYd9tIv5Hi/K//z/SWrHDukUlhBFDcaIp/cApjh76L4s5VDjyumiOOvJ+3vnGK9 7CYSPl7/2V7qwH43RxvGvzqmW+20/9SYay1h9icQrMvvfCGuDTGDE9U640XUz6/F/Xtp9rvqS DKSZyE9Cqont/9ayoLARNQXI2vmnvMXqKXC40V5/BTaXGE23PYGTtqmICskp/kVZtY9uzbYvv 8tSpV0y5RRO+u8qOJPG4T+H1ctq0tiFf69CigjfVh7qQm/zBevjMeXMNgOYw1H/3pu4H8rL1r EIyVgceBb07ZpOmPYdPjKIymSvQv48e22WlQjRc4yXCo8TDhSI5htVYK0zKOj3M4DToeIilhW nOmnEJp3brriFGM4vnA4N6d5uUatymzEQUqEckhNX3BaS0YZNssxVBCS4NC1SnfnHyz04XHC+ SeujzxUPfQ== Archived-At: Subject: Re: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:26:41 -0000
Ted,
These changes were already proposed during the last call of your update but the Shepard did not do anything about them.  So I don't understand where you are coming from.

Tim

On 10/15/2020 4:18 PM Ted Hardie <ted.ietf@gmail.com> wrote:


Hi Timothy,

The two small changes done for this version were to respond to IESG comments which sought to improve the clarity of the existing proposal; they did not introduce new elements to the proposal in the document.  I think your comments propose a much more significant change, and document updates post-IESG processing is not the time for that type of change.  If you wish to see other changes, I suggest you propose them in a new document.

regards,

Ted Hardie

On Thu, Oct 15, 2020 at 12:33 PM Timothy Mcsweeney <tim@dropnumber.com> wrote:
I would like to see the following changes made to this version (-04) because it does not specify what will be exactly will be reviewed:

2. Updated Requirements
This document removes and replaces the normative requirements from sections 3.1.1
and section 3.1.2 of RFC3405 with:
The registration of a NAPTR record for a URI scheme MUST NOT precede registration of that scheme.  IANA will review the request against for
  1. correctness and technical soundness (eg. valid databases, service parameters etc.) and
  2. consistency with the published URI resolution application specification [RFC3404], and
  3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain.

3. IANA Considerations

This update does not change the IANA submission procedure in Section 5 of RFC 3405.


_______________________________________________
dispatch mailing list
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
From nobody Thu Oct 15 13:44:26 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A943A03F1 for ; Thu, 15 Oct 2020 13:44:24 -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, 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 Ph2rzpwodjgV for ; Thu, 15 Oct 2020 13:44:23 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 D429D3A03C9 for ; Thu, 15 Oct 2020 13:44:22 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id d19so200516vso.10 for ; Thu, 15 Oct 2020 13:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0wc0yZ+ryDs6WJRwV4BdsMFQuk8RGKU1dBdJkUtnbOw=; b=JWubw+6xI5PH3DACZJ57L7QtgyKOx3/6iuGaRXpCp57xwqVPet6mS+8cPC9vzL/+uq KQskCTlYBkrYa0HgHbcslfjPBNPw0ZY7WiaLBuP1nNtLwvv6rLR5cC6kdhkjp/KJhNas S38AQCglemJtunNQMdRMeHXV3A1qoGCpLoIAq5t/hSWxGUoXoczAqMccoZuqK0vkzzcr uJkvVkLVPWROLcZt4JTgQAQgvUNvlVUzSC4IYenGfbt+XYNA5RG5gGErSx64iVtNxU7l dKV+tNkIMf+R1iX+dse6LT8cMw/9qE345IIpbrfC2I/aWnnVFKNVAMxPyob11IXARgae tnXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0wc0yZ+ryDs6WJRwV4BdsMFQuk8RGKU1dBdJkUtnbOw=; b=qC/nCI7oCRQLcuy3+i121k2iHiMUUBJLOhgAx2nEfXI4IH7fvPrWHRWTJgJwnLoPMF xx6h0sBd5ADPu5wN+IofgezEqTq3OgIZlKZ1bNABaXTQn/ZFTDaHnJVNb3oLIGRjzpWU qp+J3E8LciAG9Dx/Ijjmc8SJYw5LWh8gn3Tx45ZCzFEgMg6P34oL3BsAvQOXa5+JdbiO Q0Vst2SuLfTCzfCOqPlhGAmL7BqyggEUm9oTeyJfRhc2xcVF4XS9GSS/kh8VHrmULpPN 0o4ao5fYQwu3XqS7XLPTBk7101s3YFz51PBsQ9WEWdq+Kvw/cknB+gVXk4cCo3a86ikB y4gw== X-Gm-Message-State: AOAM531iLUOHnZl5d5nLgbeiOEPFvZCgIkNMwwqWp34iDR3lj7nycyj9 tNp7wZkAXGLCb1jCkifwcjrMDSB/qeZEw2RI0Ik= X-Google-Smtp-Source: ABdhPJwjzKfyY1d1bs78BiJn4Q4fO35A+GPNgYSbCsIel44i4+RudisGGvCEJbSrdyA9usBKx7F75fRrxMBP1qzUFRM= X-Received: by 2002:a67:383:: with SMTP id 125mr259108vsd.9.1602794661536; Thu, 15 Oct 2020 13:44:21 -0700 (PDT) MIME-Version: 1.0 References: <160278762498.6279.12834691771462136672@ietfa.amsl.com> <695687617.30027.1602790280802@email.ionos.com> <894177016.33315.1602793596709@email.ionos.com> In-Reply-To: <894177016.33315.1602793596709@email.ionos.com> From: Barry Leiba Date: Thu, 15 Oct 2020 16:44:09 -0400 Message-ID: To: Timothy Mcsweeney Cc: Ted Hardie , Dispatch WG , Spencer Dawkins Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dispatch] New Version Notification - draft-hardie-dispatch-rfc3405-update-04.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 20:44:25 -0000 Your proposed changes are well outside the scope of the document, and there was no support for expanding the scope during discussions of the document. As Ted says, you may propose such changes in a draft of your own and bring it to DISPATCH for consideration. Barry On Thu, Oct 15, 2020 at 4:26 PM Timothy Mcsweeney wrot= e: > > Ted, > These changes were already proposed during the last call of your update b= ut the Shepard did not do anything about them. So I don't understand where= you are coming from. > > Tim > > On 10/15/2020 4:18 PM Ted Hardie wrote: > > > Hi Timothy, > > The two small changes done for this version were to respond to IESG comme= nts which sought to improve the clarity of the existing proposal; they did = not introduce new elements to the proposal in the document. I think your c= omments propose a much more significant change, and document updates post-I= ESG processing is not the time for that type of change. If you wish to see= other changes, I suggest you propose them in a new document. > > regards, > > Ted Hardie > > On Thu, Oct 15, 2020 at 12:33 PM Timothy Mcsweeney w= rote: > > I would like to see the following changes made to this version (-04) beca= use it does not specify what will be exactly will be reviewed: > > 2. Updated Requirements > This document removes and replaces the normative requirements from sectio= ns 3.1.1 > and section 3.1.2 of RFC3405 with: > The registration of a NAPTR record for a URI scheme MUST NOT precede regi= stration of that scheme. IANA will review the request against for > 1. correctness and technical soundness (eg. valid databases, service pa= rameters etc.) and > 2. consistency with the published URI resolution application specificat= ion [RFC3404], and > 3. to ensure that the NAPTR record for a DNS-based URI does not delegat= e resolution of the URI to a party other than the holder of the DNS name. T= his last rule is to insure that a given URI's resolution hint doesn't hijac= k (inadvertently or otherwise) network traffic for a given domain. > > 3. IANA Considerations > > This update does not change the IANA submission procedure in Section 5 of= RFC 3405. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Oct 15 14:23:00 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3CD3A07F9; Thu, 15 Oct 2020 14:22:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Cc: barryleiba@gmail.com, dispatch@ietf.org, rfc-editor@rfc-editor.org, The IESG , draft-hardie-dispatch-rfc3405-update@ietf.org, spencerdawkins.ietf@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160279697794.10019.482267966481380670@ietfa.amsl.com> Date: Thu, 15 Oct 2020 14:22:57 -0700 Archived-At: Subject: [dispatch] Protocol Action: 'Updated registration rules for URI.ARPA' to Best Current Practice (draft-hardie-dispatch-rfc3405-update-04.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 21:22:58 -0000 The IESG has approved the following document: - 'Updated registration rules for URI.ARPA' (draft-hardie-dispatch-rfc3405-update-04.txt) as Best Current Practice This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ Technical Summary This document removes the normative requirement from RFC 3405 for registrations in URI.ARPA to be from the IETF URI Tree. This document will be published as a Best Current Practice, as it updates BCP 35. Working Group Summary and Document Quality The draft was Dispatched at IETF 108: the decision was for it to be AD-sponsored, and Barry Leiba agreed to sponsor it. The conversation in Dispatch was broadly supportive, but there was general agreement that Dispatch should not make it a working group document. The draft is very brief and to the point. Personnel The document shepherd is Spencer Dawkins. The responsible Area Director is Barry Leiba. From nobody Thu Oct 15 15:05:14 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B543A08EB; Thu, 15 Oct 2020 15:05:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160279951339.3375.10343851029000179787@ietfa.amsl.com> Date: Thu, 15 Oct 2020 15:05:13 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 22:05:13 -0000 IANA action state changed to "In Progress" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Wed Oct 21 12:17:01 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23F33A122F for ; Wed, 21 Oct 2020 11:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64_8BCtTRKqd for ; Wed, 21 Oct 2020 11:25:17 -0700 (PDT) Received: from outbound-ip20a.ess.barracuda.com (outbound-ip20a.ess.barracuda.com [209.222.82.202]) (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 476923A1220 for ; Wed, 21 Oct 2020 11:25:16 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by mx6.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Oct 2020 18:25:12 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UQBVuQ9uMQcPXnljlQkca7KsXlI7JyPRj1jo6ekxma1u0l+qU/KOV+nucc4nxExrSXvbQC2sMATDYPFMINLnKGgkgDRpGOq73nBrMAor86y12B37TcFj0rwKAls2lr9zuqHx1RNBY0ZJcnTb+8reG/dtEJlUc9xjwviN5GMGU9Bj3yi72r6P9iwpc3anDefZu47wt3ECKrsvhK3lmXxvWF/LN0yJq2ANuK0DtcqP9rUjpHFC3Mc+9AB5AyEwiinVe03aJHqLbzPMqYw1jvtjM/UB8b00UB4dF/UEQ75YVWAKHb8bSmce7HD5TocpmkBLbCDIB0HYjfng+EZXEr/6yQ== 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-SenderADCheck; bh=S99GIjvTGb+oDL35G3b99lZLiq9uAjeJq6ApJkueCSg=; b=ERm582NjwF5ULL1OVb8/lvTv75M6eaw5RV/IY7rV7Xj8bsT3zCaza65eKRDvtCnEGvO1VwlXYEtFhNKuS0sBTJLoGHMcWPHewf0m1eSDD7xnNYlZWqbOkhBtbtJMzHHuW/9bks8DweZSpkp6EBM7Irb+x7T+cb7vTdvNTLlcTv6xGPxbFUYkv7hBCqkyDCTUfg2SQqd6E6Jgcb4dzIdyEA8fqESNSpiMrUXNCy9CPztdsG19Q71NvOejsdmmCEDxTC4PwAYCA3nU8WIBGqkMYj+vJMphUx04hRN/oqV9QDUUXZZ8VhkFohcXc/FHbqcEMW2IlpO01oTaSTC/TFBXtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S99GIjvTGb+oDL35G3b99lZLiq9uAjeJq6ApJkueCSg=; b=YhLaWhUg+e7H0a2Rt8Eg1Pc+mBbJEQ0QEwU0/9wSJYomeR52ZL1g056o6G3er6D+Wc+QrGefIXAmdeiNioRB3as4F6YQlc1jXsK5KPGO9jHgqhHjOH4Ab296XBbWjytuqWK5CMCTm0blT8ttczJxvSDGVRpr6tLKSsY9QIbAPtw= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB3768.namprd16.prod.outlook.com (2603:10b6:5:295::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 21 Oct 2020 18:25:11 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::d9a4:b285:30de:c591]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::d9a4:b285:30de:c591%6]) with mapi id 15.20.3477.028; Wed, 21 Oct 2020 18:25:11 +0000 From: Yeshwant Muthusamy To: "dispatch@ietf.org" CC: Chris Ullrich Thread-Topic: Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] Thread-Index: Adan13/BEH6yegSBSqeRStoru+9knQ== Date: Wed, 21 Oct 2020 18:25:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=immersion.com; x-originating-ip: [72.180.210.31] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f4ce011e-8584-4bd5-d31d-08d875eea5b9 x-ms-traffictypediagnostic: DM6PR16MB3768: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FFIAchcSRff4nVjqB37iqutIBEMzyRs8Hxbg/8/Aq/TnAL+6Yp693uMYGJseY2SEjQnRPYypaWKykgyv2yKp7ftr//DiTWtY0UzRrxhz+OCJFvxLpC6FK/O0//6HOUff0zw6sbP4AsO9ixeePaP7XjJ3luJjKqtO0TWqRjM3aKgWAdGFhE4SfXsInXomF30fVi2G4x3f9CVD50p9ALT1umQrZGH2sFePOaj27Q4wXPR8fwRYH2AdL7v0GVO+fQoGa6y3KvS28xG/tQQmyz09X4NDn37uaoGdD/fwW63LiMJeHQRPqT4QibkpngxPF6xCDYJHFN6uvCwSKZTG1BwDJlyDa5GvTuLCgG4Otg8CycGcnqZgEIfdViDs5WJqPPB5d3t/mfbnhNFq2Lii8/HsIg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(396003)(39840400004)(366004)(346002)(4744005)(6916009)(76116006)(2906002)(107886003)(71200400001)(9686003)(52536014)(166002)(66556008)(8676002)(66476007)(66946007)(99936003)(66616009)(64756008)(66446008)(5660300002)(6506007)(186003)(966005)(26005)(478600001)(53546011)(55016002)(86362001)(33656002)(4326008)(83730400002)(7696005)(316002)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: qsCO333ofaHSSBqaIWyt/VDwmJIRmQ1hvV0gKs+tVZR+Sg9dk+JTaMzmV2f9vILyhe7yF1XDW81z6oSWXC8yTOcD3EblEJSJFJz2ql+dRZbcADI9fGu/Lp7/2QN6DLYacn11g0od0/GLNbH7qlu3xvwb8jCbFXCSD6mLvkWgwh9zyMzYpML2WkuKUgjpbkxDXXMJJ2NiEM2DTySn5KMEbyvq3Z7cIdfd3Ro+tso8ZQ5TyLvXrjPq7EXeqBpk5CKC2Bo2D6re2pwBqGic0mmtrTx2GFIxESld5ijGAeIggcKM8iW2OXSRg8J9cGnH8lTBmMUk2vNvpwU0+yMuHwM0+nQJ/NWvPTV9b3A8Hbn9o3obnZNDWpqVbw81ZPqJqPR2uWyTDni/2WytN5dKlc1lUb7UGQsBAWP7GsFI56aXCsrEtJwDW11AKdFE42R57ADUUaqREwoAPgCklmNbPo8+VZJZ+QW+FZbDxl8peY9cemHt/Rd6X7miI0FkZcvtyFG3pvaSBe7RAGPvaHGscrE0sBjIICOKQFwJ3g6WUn9ZsWUQs7ao4hwGmQg3JsniSg9imdD861GbALnUskXeLJHffUDGApYipwOJ8BmGfUdo3SOeJ/HSbA4rEMwjgnW/sTWvha70uFjgQfPh9rKrzBnJ3Q== Content-Type: multipart/related; boundary="_004_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4ce011e-8584-4bd5-d31d-08d875eea5b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 18:25:11.4875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ATeVOGOYZXq1E86yK0QJ8LfJXccM75y6uhT1nvkT7QL9gumRs5F6tilJXw1Mu/rkjrAudphlV1hXLFf8EBtwSSntfU3S58f8rxPCHdnpThU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3768 X-BESS-ID: 1603304712-893010-6905-32022-1 X-BESS-VER: 2019.1_20201020.1810 X-BESS-Apparent-Source-IP: 104.47.70.106 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.227696 [from cloudscan10-142.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: X-Mailman-Approved-At: Wed, 21 Oct 2020 12:16:59 -0700 Subject: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 18:25:20 -0000 --_004_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_" --_000_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Re-posting with a more descriptive subjective line, since my previous post = (see below) has not engendered any comments (yet). https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ Thanks, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards [cid:image001.jpg@01D6A7AD.96E529F0] ymuthusamy@immersion.com | +1 469-583-2171 From: Yeshwant Muthusamy Sent: Tuesday, October 13, 2020 3:53 PM To: dispatch@ietf.org Cc: Chris Ullrich Subject: draft-muthusamy-dispatch-haptics-00.txt I would like to initiate discussion on draft-muthusamy-dispatch-haptics: https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ An informal (and earlier) version of this document was discussed on the Med= ia-Types mailing list (media-types@ietf.org): https://mailarchive.ietf.org/arch/msg/media-types/3cXb69ybEa65oCCIiHjl0MtGX= VY/ Look forward to your questions and comments. Thanks, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards [cid:image001.jpg@01D6A7AD.96E529F0] ymuthusamy@immersion.com | +1 469-583-2171 --_000_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Re-posting with a more descriptive subjective line, = since my previous post (see below) has not engendered any comments (yet).

 

https://datatracker.ietf.org/doc/draft-muthusamy= -dispatch-haptics/

 

Thanks,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Standar= ds

ymuthusamy@immersion.com | +1 469-583-2171=

 

From: Yeshwant Muthusamy
Sent: Tuesday, October 13, 2020 3:53 PM
To: dispatch@ietf.org
Cc: Chris Ullrich <cullrich@immersion.com>
Subject: draft-muthusamy-dispatch-haptics-00.txt

 

I would like to initiate discussion on draft-muthusa= my-dispatch-haptics:

 

https://datatracker.ietf.org/doc/draft-muthusamy= -dispatch-haptics/

 

An informal (and earlier) version of this document w= as discussed on the Media-Types mailing list (media-types@ietf.org):

 

https://mailarchive.ietf.org/arch/ms= g/media-types/3cXb69ybEa65oCCIiHjl0MtGXVY/

 

Look forward to your questions and comments.

 

Thanks,

Yeshwant

 

Yeshwant Muthusamy, Ph.D. | Senior Director, Standar= ds

=

ymuthusamy@immersion.com | +1 469-583-2171

 

--_000_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_-- --_004_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=5147; creation-date="Wed, 21 Oct 2020 18:25:11 GMT"; modification-date="Wed, 21 Oct 2020 18:25:11 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABkAAD/4QP0aHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA1LjAtYzA2MSA2NC4xNDA5NDksIDIwMTAvMTIvMDctMTA6 NTc6MDEgICAgICAgICI+IDxyZGY6UkRGIHhtbG5zOnJkZj0iaHR0cDovL3d3dy53My5vcmcvMTk5 OS8wMi8yMi1yZGYtc3ludGF4LW5zIyI+IDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiIHht bG5zOnhtcE1NPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvbW0vIiB4bWxuczpzdFJlZj0i aHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL3NUeXBlL1Jlc291cmNlUmVmIyIgeG1sbnM6eG1w PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIiB4bWxuczpkYz0iaHR0cDovL3B1cmwub3Jn L2RjL2VsZW1lbnRzLzEuMS8iIHhtcE1NOk9yaWdpbmFsRG9jdW1lbnRJRD0idXVpZDo1RDIwODky NDkzQkZEQjExOTE0QTg1OTBEMzE1MDhDOCIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRpZDpBMEI4 RUIyQzA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wTU06SW5zdGFuY2VJRD0ieG1wLmlpZDpB MEI4RUIyQjA2NUYxMUU1QTBFQ0NCQ0JDNTlGRUU3RiIgeG1wOkNyZWF0b3JUb29sPSJBZG9iZSBQ aG90b3Nob3AgQ1M1LjEgV2luZG93cyI+IDx4bXBNTTpEZXJpdmVkRnJvbSBzdFJlZjppbnN0YW5j ZUlEPSJ4bXAuaWlkOjAxODIwNjY3NUYwNkU1MTFCQUZDQjk1NEQ4MTUyNEMyIiBzdFJlZjpkb2N1 bWVudElEPSJ4bXAuZGlkOjdlYjc0ZTdmLWMwMTAtNDUwYi1hODBhLTM4NmQ2ODUxMDQzYyIvPiA8 ZGM6dGl0bGU+IDxyZGY6QWx0PiA8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1bHQiPlByaW50PC9y ZGY6bGk+IDwvcmRmOkFsdD4gPC9kYzp0aXRsZT4gPC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJE Rj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9InIiPz7/7QBIUGhvdG9zaG9wIDMuMAA4QklN BAQAAAAAAA8cAVoAAxslRxwCAAACAAIAOEJJTQQlAAAAAAAQ/OEfici3yXgvNGI0B1h36//uAA5B ZG9iZQBkwAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQECAgICAgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAgEBAgICAQICAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIACcAkgMBEQACEQEDEQH/xACVAAAB BAIDAQAAAAAAAAAAAAAABggJCgQHAQMLBQEBAQEBAQAAAAAAAAAAAAAAAAECAwQQAAAGAgECAwII CA8AAAAAAAECAwQFBgcICQAREhMUIRUxMjQWFzcYGWEiVDW2ODkKQWIjU2MkZCVVZVZ3t3iIEQEB AQAABQMFAAAAAAAAAAAAAREhMUFxMoECQmGxEtID/9oADAMBAAIRAxEAPwCzfzV7CXrCOtWL61hy 2TdWzjmrZfClExipWpBwym1nsXbWdwfmMm1ds1H8E4VgWsc+bnOKDosmRusUyaxg6CH+u8m+RsdZ +5D9qMbtmtui867o6w6qa/0yYeSkjWLf9GZZyu3ixw8O0kWgtl3+J65G+a5b/jN5G0x51CqdgIe5 dzqLbVKvtKyRDubDQrVB3CDaT9mqzmVr0i3k2CNips/I1e0Q6jhsdRMHsLPxLhqsTv7FEh7dyiAj BlTFyqNdl6tX5+0V6EnbxJPYelwstMx0dK22WjYl7PyMZWo924Sdzj5hBxrh4sk2IqdJsidQwAQo iAKXoDoDoDoDoDoDoDoDoDoE7HW2qy9gsdTirJAydop5IZS2V2PlmDybrBLG1cPoA1gi266j2G99 sWqizT1BExcIkE5PEX29AougOgOgOgqE7aZ2yjstyCR2H80RFbx3m7jjuGd834iqVOVkntdzdjpK gM8t0SwV9zMOkZZDNFKhaXXZoqP8oykmnvFZuiwXY+ikAiS16sDalfd/y7dNhJMMI69bpb4EiFUU XbMcyUezbCMKQtKMVe6a7xeZ1ZpRVjmKJiMCJm9oJgUAuIcKuNnOOONrXNSVdLSFiyVFWXMtjlHD j1K8k/yjbJq0x7pdbxqHO5CtvGCaonMJzKpmMbsYRKAY2+8zglltrxiweUsBo5Svlpz1b08RZIJk OapDzDNgrcXVZ1WYPCRES9RyFGyj9NiqeMeOGjci8ckcTHATkEMDfjk7semOd8Ha90rV+ybGXvYC sTL2ix9WvzeryatvazBYOErasU5pk8kaKkHR/NeSYu0ixzYp1TIKEIYwWTQ26L5ms7R2RJfVO+cd uR2W+nvuBZ0rX2sZXp8zTLjWZ6AlrKreXmZQjD1Wq1utR8emV+4EJBoUVgP6kgJPCNIHu6D79v8A buWzjijKWFpnXPZTW2xQ8BlvEsrZGVwYt21hTkTQNhrdpYsYxvMR780Sv5hU0VEkSHbqJuHCLlFU 1swNCvPLnsHL7TZ/081g0Dns9ZXwVYHCb+WDNleqNTeUeOYNHD+1TDqxVGMa16Vcv5Fu1YRQvnBn oqGMkudQgN1IEdT+bfLmfqpLudTOO7K+Yb/iesubFs7UZ7I0DQo7Cj+Ol7AxXpMZMydaXkslW6UZ 1h0uyZso1tIqJ+wrJVwi4apBLNqLtvjTcPWukbN0cXNdqNpi5ZxNxlmXaNnlKmaw9exVuh5t4ByM /JhJGNWEjvumk4Z+W5ACEUAoBEjK86FkYGY56R0pyO447XmUVMVE24UtzFKScuGs4pAOr2yxcSBX kTVAJUgt0fNdpFXWTOgDkr8h48ly8uokR5C994LQnXuq7EK0E+XazYslUekKR8Nbm9aURg7hGTsw e2RUiaAsjWaMyj4QTIMxK2TeCsX+tIgHiFJbcg0rj7k7srfUDN+7mzWsF41xxFRiwMxiKDl51nPX vMFUtho+MqMijErR8AFef2exTDJugRcvpiIugceeo2IK5mccCw043L3Fz9kpKtZ34+LfrbjmyY7H J1Jyo6ypA3qGVinLiMJDVmysmUBDqxNvlW0oVYGJzpSKBElBWZJpkMoWBGal3LBlk5NOR2vUjX5H HOXKDG4QjMnZgaZHmZtpmBGegHEtHOj42VhYyv0iSjSokTcuW7h6tImTKqoYhxU8wE9sXyiZTrme sqa/aY6eWncax64V6PtOyc/E3yNoleoBJBso+a0qvqvYSZWul7dsElDFZM/G8Fds4btmjxVs7BqD 1tXdx8c7c6sw20WKGzhSHkq9YXcjUJl4i1mK1bqok6JP0ufctEXxGrlo/a9k3JUTlcMlkXaaYprE KNzjghtpvO1sTk3B8ptLj3jRt0zrli924YZ5vpc/VhQ9XeIPUTviUeNdUaJnbsyr1bfsn8g7TjiI NlXJkHHpUUfWqsu51Ep33mmpv+sZL9S/7eP5ta/UZ/MfnL6wv8j+UfxuoKzX7wTDZJ1q5FMIbe02 DZli7RjWvJRsvJMHz6tz1yoL6wQVup9nRTXbFcs5SiTMa3dNkl0DuY50cpRKYDn66fz6pTENcb3g nYd9QMc09MMA5WrmGdt8PVTF1nsU9bcX5bJsZizJULXali66TD0k3R7bAZFvJ3sLXrU4k2ku8UD+ /wD1vpmDnmq4vw02yXtfGtrCSxMXURZKVXbdiqfg5FsqxloKQxNka345Ti5iOXTSdR0mhHVtAyqC xCKpifscAN36DSHJZ+vdw2/9jssfohTetTxoRu2aZFedjitKqmRQoYk2gUAqhSnKCiOJssqpKABg EAOkqQpij8JTAAh7Q6Txo4Mmmf8AeJUzHTIcyPHOKiRjgUxklByaokKiYiAiQ4pKmL3DsPhMIfAI 9Ph6js1Q/bt8qX+0Grf/ABDiPpfGBV8f6KJuUvmlcGSSFwla9M0ElxTKKxEV8YZIOskmqJfGRJY7 ZMTlAexhTKI/FDsvjBjcOUbHx985XCsWLVoCXJ9sdGp+nbpJGJHxs0AR7EDkKBhasQcqeUn38Kfm G8IB4h7y8oGd6MupOr8CG669RQ9K8iIXehGOI0BREYtghBzzZy7ZenVQM3Vh4nzFkTFN2TMiUexg Dwjfn6hEa/aP8ge2HF7iHCEHs5rRAaw5TxJTnEdTHWG59zcIeOb2NjdkmkhaUXpwXsLG3xnmuXKZ AAzgpxIBQEO0ly6HCc2+PXOP+L/VvFNkftrM8pOa9WcfT8n5axmdgc1qhWatyj7yngncGbSyrJRT wqiJxKp2N3Hv0nOdxMDutqjVd0NXco6z2SVXqjC+Q0cSDsccyRdq1OzVmYjbLUJkkcc7cj2Pj56G bg7aEVbmdsBWbkWRFQFSJbLsEevH5t9sXQc6Bxlb5VmObZ8o+OSWTC+bq68Vc1jYbGNcTMxSkTlc N26qloZxkauqd4QqYvAYPE3bdq9aHM8gTmhX7YTmE/8AM36DO+g54TCpyFk5QrTIB59sm+RbNLWd kliFK8dNI10LuMQX7GL4UWjyZfCmmBCFTFUwF9nsLr3eQSvD2gzhcWcp9PgVzjT6pvZtBH1RkCBm bZnFpwMaybi2YGVcCwIuxjW/dHzDgTwAHcR7iNvOeg0tx9ooh+7iZ7EEkwFXXXfdVUQTL3UWTiMs kTWUHsPjVIRAgAYe4gBCgHwB1m873EAvvB/+XPP2PHu/5St8g/Ifj/I/6L4n4Ot/si8lyEak1bdb U/K+DZ+Parzz+Ae2HGUyq2TXeVbKNeZuntMm2CggCzcFZABYvQSMmdzGPHLfxAVY3XNXl1pqKIqE VSOdJVI5VElUzGIomoQwGIchyiBiHIYAEBAe4D16Eem5xS3iSyhx/wCt2TbAyTb2+9053NXiRKmZ Nzbbk0n5avWC+y34pSr2C+PYQZeQXAoeqevFVh7mUMYfOr4+52sOVM37ScdmWKI0hHFQ1rzFfbpk 9aTmUY5+0g7DX67GxykKxUTOeXcmcxqoHTIJRIAAP8PQJ7PGqGXsg8o+i+11cZwKuIcBY+zjXMhv Hc4g1nm0nfcf3+uV4kVBmSMvKIqSVibAqcpigkQTGHv4egPsn5e+95+2V6OB+hP7Hn0Leu99ofOL 58fPf396f3B5XqPdvoPb6jx+Hxfi9urvDAYH1Qy9j7lH3o2usbOBSxDn3H2Dq5jx40nEHU85k6Fj +gVywklYMqRV4tFOSrrkEjmMYFSAUwdvF1AoNT9YcqYg3g5Jc8XNpCoY/wBnbDrfJYrcR8yi/lXb bGVHu0BaRm4xNMqsMZKRnG4IAcxvOIJjB28PQHHtrDlTXG175y+S2cI1ZbB7yZqz3jk0PMoyyjnH 15kknMC5lk0k0zRcqokQfNam8Rkx9gj0Cb429NLrgbS2662bGwsC4Xvd+zk4sMLCTZJmMkqJlF65 Q9IpItCoeWs/hXihFSF7HSE3w9+gZJg7AXMponTHeo+tkLqznDBcLZ7G4wnm/MVinISZx5TrNMvp xaGulQgpOIl5J41k5Rd0mVm3lE27hVUpVF2vkNkb14h7PLTqjmTcbWeg4yw9H11zcoLP2L8jy7Wb sKcPGI1+rsrOlNi1knbRP1a6K0skCRBSTOqXuPYvYQ6S2XYHhbUqbPo4Vsi+nrfFzzOzd9AOq20z CrLpUp5GNJpk5skc49zCk5PIScIis2beNdqkVRbxiukJSmCCNrWfWDd7MO79U3t3sg8R4lkcQ4dm cU4hw1iKfd2dQJC0GfpWa122aUdzMf6ZdrNPgbt0X7g/dVuAgn6Y53Thg3Tqvqfl7EvIVyF7H3Bn BI4z2P8AoW+jJ0wnEH0y6+Y1YcRU974iSIlVifLdqACXjMbzC+0OrtzOgaveNWORDULanZ7L3HxW cLZSxbuc+a3S203KdmGsvcO5tOEgaWyKggovEtbDASMpNvZBdBqss6ei4BBZAPSIrOJ35B7GhWks rpvpw+whL2Rldst3p1kDImW7izOsSLs+WsiMytpN2ycPGrR8uwYR7CPjyOXKRFnJGfnmTS8zyUwb bqbo3nrD/DrlLSy5x9Yb5xtmHdq6XEMI+yNn9bPOZdY5AQpya9hTRI3QbLKWNt6hQSCCACbv38PV t26ImfuWt4f8Cxv+z6+zn9YUf9Zf5L8k/M/9r+J+Dq/l99FqbY5TJKeAcz/Q5FRs1lZXGV1bY8j5 mXjoGIUt7yvv2sEvJy8udOLZsGL9Yi6ouDppGIkJTHIBvGGRQC1x4rqHd7bFK7H8hOgOEcdorpK2 AkBtvg/IORnzUqoioxr0dC2xentXDlJMSi7dyYlaioQ4NnPY6Qb33/U4PQE19ruIahhDFNUwDI16 XwtWqLXYHGcrU59ja6/J1GIj0WEVIR9njXT5nYgeooeYo9IsqLpYx1DHMYwj1gbi6A6A6A6A6A6A 6A6A6A6A6A6A6A6A6A6D/9k= --_004_DM6PR16MB3912ECCB07E4E1875E20245EDE1C0DM6PR16MB3912namp_-- From nobody Wed Oct 21 18:31:08 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD5D3A0EF8 for ; Wed, 21 Oct 2020 18:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 k9RhzbawgCLX for ; Wed, 21 Oct 2020 18:31:04 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [69.252.207.38]) (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 E1EF03A0C31 for ; Wed, 21 Oct 2020 18:31:03 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with ESMTP id VPFukz6SQjbDaVPQYkQ05P; Thu, 22 Oct 2020 01:30:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1603330202; bh=vk+RBNGxaIyhc9D5YjI9pdL4065pfdU2RxbKHBcTDAo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=UZAadkgvMwnV6o7Q7tO3wFMo9qH2s76pzM852YqIxsNjNk6KTf2URK8Rz9VAAtMgw 2/dTF3qbIkYoZrJwTUqsur76Q90luriRenXmBzDaYLwtHjqGNGHQ9fDZhicOuVutFm HqTBBwCEdp5VpozR3cG91eOC7beujcEGgZNcURwctfRc38nx/UWgUaBLvfTKYCEnAH EIIdlYLp/nAV58f3JpO7rDF9Y95N6b2miF2ei9U285a1E7zssZXDjh2/fjjJMfDk/4 935s/CAg6O7Mk41xjwdE4pNnyx7kbUeP8TaM0DB6FmRfpIFqsHto1pnOV47JVeG7C4 +Ug+Xz+P0c6lA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-17v.sys.comcast.net with ESMTPA id VPQWk8Hxry9YdVPQXkRWFn; Thu, 22 Oct 2020 01:30:01 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 09M1TxGU014741; Wed, 21 Oct 2020 21:30:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 09M1Txxl014736; Wed, 21 Oct 2020 21:29:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Yeshwant Muthusamy Cc: dispatch@ietf.org, cullrich@immersion.com In-Reply-To: (ymuthusamy@immersion.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 21 Oct 2020 21:29:59 -0400 Message-ID: <87tuunavzc.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 01:31:06 -0000 In general, this makes sense. Reading your proposal quickly, I can see two complications: One is that in many current usages, haptic data is incorporated into the same media stream as other media, making it questionable whether haptic data would be in a stream that could be labeled as such. I notice that combined video/audio seems to be common, so this problem is probably already being solved in that case. Another is that it seems like few of these media formats are non-secret. There are registrations of media formats that are patent-encumbered, but the specifics of those formats can be documented. What would really encourage support for a haptics data type is one or more open standards. I would probably be informative to prepare draft IANA registrations of the haptics type and two or three subtypes and see how writing up the registrations works out in practice. Dale From nobody Wed Oct 21 18:41:31 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1F93A0C94 for ; Wed, 21 Oct 2020 18:41:30 -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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=Rp3CZ0K5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Gf8TIvQf 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 d9SlFkz78xVx for ; Wed, 21 Oct 2020 18:41:29 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1791B3A08D3 for ; Wed, 21 Oct 2020 18:41:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 13FFA52A; Wed, 21 Oct 2020 21:41:28 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 21 Oct 2020 21:41:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:cc :subject:content-type; s=fm1; bh=g5WZz78zB2nKBMZeZI4eSMoRIE3ZiMB zGiL8SWeRqC4=; b=Rp3CZ0K5pHE1X2W1Zv8PW2vVH/bAoLEbMO4epuXwODjtZEb CGWKQl4nmyZCnd56k37B1pm5GLkKgI3C7XY+joqJhf5kSApxhY2KvYzzTUvuwbB2 W54rsQku8Tao36xk60l5eIU74b6IOidAeyeSOwfksamrziPqRwif1FM0F8ekZgLl vVUt0WYFywNkJ1b1h4AsU969wH/pxko7hevDhw9cnEmjiCzkQNDTMuhRCLtSlUA2 oXf9aLZBK90KtfuvgPU4wVAOYBmobSglYrI3070uafow+iBBrYZX9UGRbikpnJE6 madXWmSsI5S3IHG8IIMnNvtKegSjZNKD0ValO1Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=g5WZz78zB2nKBMZeZI4eSMoRIE3Zi MBzGiL8SWeRqC4=; b=Gf8TIvQfgSsUARl1f5pMIse2uYWqS1nHgkK3o0CpNa9ZF Bsbf/E7WzW31RaEqhkO/lz9ps+bkluSujCx4xeOD+qxEmg2p3HNs+iRIi6iAYugr LF/dsMUsO4YjjqkXMJDk7t/cP+fA9SyAHoeXl7JUZ62FB91e0QLsJ9gWMtSvzEoz OYcQPJc9mNugVorxsUA3yNzvkopt4Fjf8axfOSPVgm+ORsIrP4zPAnDnMCRQE9dq RaJFFzzJO8FjndWEA+jzieSkJAebZicV7nmfIk4TCAwU/kRq3Swp0LVy4LsVRwqg RadQPs+0X4Y7U1e7/L2DSUmyxZqggvtZlsuAqYycg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeigdegjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre erjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepuefhvddujeelfedvfe etkeeikeekkefhleegheehudeljeeugfffveeutedtgfffnecuffhomhgrihhnpehgihht hhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 832CD180187; Wed, 21 Oct 2020 21:41:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-529-g69105b1-fm-20201021.003-g69105b13 Mime-Version: 1.0 x-forwarded-message-id: Message-Id: <1909fe56-e40a-416e-805d-f4240acf1618@dogfood.fastmail.com> Date: Thu, 22 Oct 2020 12:41:02 +1100 From: "Bron Gondwana" To: dispatch@ietf.org Cc: "Ujjwal Sharma" , "Shane Carr" Content-Type: multipart/alternative; boundary=dfb6ba78496548a89affbc1e232e293c Archived-At: Subject: [dispatch] =?utf-8?q?Heads_up_-_there=27s_some_work_coming_that_?= =?utf-8?q?will_probably_become_an_update_to_RFC3339?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 01:41:30 -0000 --dfb6ba78496548a89affbc1e232e293c Content-Type: text/plain Hi Dispatch, The team behind this proposal attended the CALEXT interim meeting last week. https://github.com/tc39/proposal-temporal/blob/main/docs/iso-string-ext.md They are going to produce a draft and look to get it dispatched at IETF109. We believe that this in charter for CALEXT, but we know that RFC3339 is used by lots of others as well, so want to make sure everyone knows about this work, and that we can choose the best place for it to be done. I expect the authors (CC'd) want a few minutes on the DISPATCH agenda to present this work. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --dfb6ba78496548a89affbc1e232e293c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Dispatch,

The team behind this prop= osal attended the CALEXT interim meeting last week.

<= div dir=3D"ltr">

They are going to produce a draft and look = to get it dispatched at IETF109.  We believe that this in charter f= or CALEXT, but we know that RFC3339 is used by lots of others as well, s= o want to make sure everyone knows about this work, and that we can choo= se the best place for it to be done.

I expect the authors (CC'd) want a few minutes on= the DISPATCH agenda to present this work.

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
<= div class=3D"signature">  brong@fastmailteam.com


--dfb6ba78496548a89affbc1e232e293c-- From nobody Thu Oct 22 09:10:41 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9C183A07B7; Thu, 22 Oct 2020 09:10:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160338304068.23382.16841475627657917200@ietfa.amsl.com> Date: Thu, 22 Oct 2020 09:10:40 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:10:41 -0000 State changed to External Review (Message to Community, Selected by Secretariat). Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-sframe/ From nobody Thu Oct 22 09:14:42 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0883A0953; Thu, 22 Oct 2020 09:14:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , "The IESG" , X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160338327469.18061.13384024582218363535@ietfa.amsl.com> Date: Thu, 22 Oct 2020 09:14:34 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Telechat update notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 16:14:41 -0000 Telechat date has been changed to 2020-11-05 from 2020-09-10 Datatracker URL: https://datatracker.ietf.org/doc/charter-ietf-sframe/ From nobody Fri Oct 23 08:39:46 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7694A3A0CAC for ; Fri, 23 Oct 2020 06:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=immr.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UvUPJejfj22 for ; Fri, 23 Oct 2020 06:38:46 -0700 (PDT) Received: from outbound-ip20a.ess.barracuda.com (outbound-ip20a.ess.barracuda.com [209.222.82.202]) (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 1349C3A0A2E for ; Fri, 23 Oct 2020 06:38:34 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2055.outbound.protection.outlook.com [104.47.37.55]) by mx13.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Oct 2020 13:38:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Shr3zr4aIL7n2z1Vf1KdXqSKskO8hctpYidWNZBlunxN/yLr2mxL+r8qhQyjjC5SwU668GqkwbcW7edZltgbr0JXrdohaDQLv6JC5U1v/VRiZpD1pkKgzy61jlgyUJYyhz1wHisY/5iMYpfVZcKkAE+wxJcwPfLTakXKba1fgHcAU11SST434UsWOPL6ZmWZzH8JaS2cF9Sc2HPpvNrTT8oDB7s/cOc2z1s6VX7sG90F5ChsPW5lhkaXewCJLAK7ajETl4MQx1yKJRskhsDNs4+bVlwAKOA7dsU0mzKjQCtfa/BeVhkmj0jqNirEKDq4vL10LcgSGVARpimk3eV/RQ== 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-SenderADCheck; bh=5nNg+8opJwCaZwdR7xc+2jxfT2Hm6z1w33n8Lwl4aeI=; b=ZHnvGwBSt3DlxVu9AiiW3izgAAhbq9jm0ZUItMf6yQ83bejxS7Y6Iu9vY7mglsVmAyFWI6jUxakAA/t1wI2Sn/xwKhlO2ll0OtiRcbKHzo94hvddgWnTBr9yQ5UsIt7u+KYROi6KUUVL3Oqxw/9PXznOzQwby3DFbQUPJtVylPasQsw4MP8amQSUfjMByA9WUpDNI78to7LPMXUz+c+dRRjLEqhZDo+XpuC2dOXeVxKaLxHGFLQ8oTTa2PzkhMdQPd8I/Q9M8JHcf2BztSWOKsiZqVSlDdeb6IUmcY4j+SLTdmkFWGtCR2esnF4NQaw0447ryg2hxVGDmeZpW8GA/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=immersion.com; dmarc=pass action=none header.from=immersion.com; dkim=pass header.d=immersion.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=immr.onmicrosoft.com; s=selector2-immr-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5nNg+8opJwCaZwdR7xc+2jxfT2Hm6z1w33n8Lwl4aeI=; b=ZONLcNKqu2ImqtpIWBAY3ZyOQQm+8v4iK2YHe9soBEJ4jVEsML4w90DjYpPPaSSl+dmamfBnRakPnPIAU4bDbjv7XXAPZVzBrOODlR4w27zI8HRpHzxuV+L+MWLi9jANsjYv7VLUbTGfXj4WUxvo3lLzXsisQio3KxwVU4SzxaQ= Received: from DM6PR16MB3912.namprd16.prod.outlook.com (2603:10b6:5:2b8::23) by DM6PR16MB3548.namprd16.prod.outlook.com (2603:10b6:5:148::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Fri, 23 Oct 2020 13:38:30 +0000 Received: from DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::d9a4:b285:30de:c591]) by DM6PR16MB3912.namprd16.prod.outlook.com ([fe80::d9a4:b285:30de:c591%6]) with mapi id 15.20.3477.028; Fri, 23 Oct 2020 13:38:30 +0000 From: Yeshwant Muthusamy To: "Dale R. Worley" , "dispatch@ietf.org" CC: Chris Ullrich Thread-Topic: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] Thread-Index: AQHWqBLgt8g9y/Q8hUaDRzNLKDAxN6mlMjmw Date: Fri, 23 Oct 2020 13:38:30 +0000 Message-ID: References: (ymuthusamy@immersion.com) <87tuunavzc.fsf@hobgoblin.ariadne.com> In-Reply-To: <87tuunavzc.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ariadne.com; dkim=none (message not signed) header.d=none;ariadne.com; dmarc=none action=none header.from=immersion.com; x-originating-ip: [2603:8081:203:8200:d4a2:6890:4975:9530] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d77a3acb-f67a-4d6e-5931-08d87758ee13 x-ms-traffictypediagnostic: DM6PR16MB3548: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fJhrK5SY+DVIRY2chz0B2+4PxyXxfYfT6CMMtPDs4ZuleadZFeShgstn30iqMOVudqVZoUqw5RHKrFFcuQldloNSr4YUTkYZTmTnwmgqqGOfUTdrYEZjsdslj5HWdUIlNP/9V2NfmieJRqYRuR67zvRql9dXoQRwMST35g4ziyPWAXDh7CzdzBUbCYFJgYYuKXIk/+zN9PO9TvBAm1f0YMe6N2g8Khk6RGYfv0WtDXBrrPmIqjAZj0ND8SzKnmDLGlc977YGQcCe6C+N3BAM2ddeP8xJ1p6NjDoi36X8VQdLUXClWG37TxcXOIkXLTxM x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR16MB3912.namprd16.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39830400003)(396003)(346002)(376002)(366004)(55016002)(66476007)(66556008)(64756008)(33656002)(71200400001)(53546011)(6506007)(9686003)(7696005)(110136005)(66446008)(83380400001)(76116006)(107886003)(66946007)(8936002)(5660300002)(186003)(8676002)(478600001)(2906002)(86362001)(52536014)(4326008)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: azHvdRJMEYd9qa7AlcP+0jPSp2CUUIfjvGrCtOE6o68OtqYTgAo24D7tVMVkLuhMURvtMBzXL6hJggA8XzlSOMPfRiQWYVddcKgm/XnjRg9s8xh6DTB0ZZYYAm4lMjNI2ivM7B4uKFrEaEIQfs7qRzZpCXMbfosFXvPwH+aAWlYPzw9aJjnzkhc5gLWVIiAry3aWXMAepJnaiBgI2vzMveqGlEzDrLvlPt0ltkZWzxRHC40PqxMfBVXzETG/LADUMqazPqd4uE5xtV6YM6r17heCkXh39u+b5NJniJHbJYmbbtzStqKELORrpEWTctUpdXM0tiqhuqzPtczb79wR9P/l0B7owMMZpmY08Qv66mONN8WatSqb0XHN+mWf8/rJ6SUBjwkCpW1pnHuNNKfaFd671l0v9gfx5dYhwFmlb7jSCISdasGyKBo6rDELpTsJct8UYQIuNF2hW03K+Ee7X8V2HMcbG9pe4YJOXcWfZKlhyDdL4DKzJ+Qj3YMmM7rh5yPEYpArXq/I9sZ7iLgwelzYyiwtZvXpkzxxa8Evu+WH3+KXKNCHcunEwmubaehEo7d60SvXUmf9oube/odpat0l9BPYYXKBPq/h3txZtBaaM13jd6mGeR+8iBLbwmJepLpA/WWzcpiApbyZyKsXgbf77Ahm0ArLO2gTcUrnPyk0OSu+MAR853DpKu+my7vB6YK6SczWsHzD0aaLtvYUNQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: immersion.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR16MB3912.namprd16.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d77a3acb-f67a-4d6e-5931-08d87758ee13 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2020 13:38:30.6922 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f05e41a-59b8-413a-ae19-d5df3dfd0fb5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QP5lsYtEONoCtz2A2KN7LYMoAACNy2MRPm9jtmY1jh9WxeiGt0fqyD23InZ/u+jE7lkghcKXDBXKqzK/94NA5IBpB59sUmK01Tk43kDcveI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR16MB3548 X-BESS-ID: 1603460313-893024-7339-2369-1 X-BESS-VER: 2019.1_20201021.2259 X-BESS-Apparent-Source-IP: 104.47.37.55 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.227736 [from cloudscan17-114.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using account:ESS117783 scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: X-Mailman-Approved-At: Fri, 23 Oct 2020 08:39:45 -0700 Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 13:38:49 -0000 Dale, Thanks for the comments. Please see my responses below, prefaced by '[YKM]'= . Regards, Yeshwant Yeshwant Muthusamy, Ph.D. | Senior Director, Standards ymuthusamy@immersion.com | +1 469-583-2171 -----Original Message----- From: Dale R. Worley =20 Sent: Wednesday, October 21, 2020 8:30 PM To: Yeshwant Muthusamy Cc: dispatch@ietf.org; Chris Ullrich Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media = type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] In general, this makes sense. Reading your proposal quickly, I can see two= complications: One is that in many current usages, haptic data is incorporated into the sa= me media stream as other media, making it questionable whether haptic data = would be in a stream that could be labeled as such. I notice that combined= video/audio seems to be common, so this problem is probably already being = solved in that case. [[YKM]] 'haptics' has been proposed as a first-order media type in the ISOB= MFF standard (ISO/IEC 14496-12), at the same level as 'audio' and 'video', = so we could indeed have .mp4 files that just have haptic tracks in them. Th= e ISBOMFF Amendment containing our proposal is expected to issue in October= 2021 (the January 2022 date in the I-D is an error that will be fixed in t= he next revision). Bullet #1 in Section 2.1 talks of 'haptics/mp4' files co= ntaining just haptics tracks, likely useful for streaming games, haptic fil= es for haptic vests, belts, suits, etc. Another is that it seems like few of these media formats are non-secret. T= here are registrations of media formats that are patent-encumbered, but the= specifics of those formats can be documented. What would really encourage= support for a haptics data type is one or more open standards. [[YKM]] As we mention in Section 2.5 (Haptic Subtypes (in use)), several ha= ptic subtypes like haptics/ahap, haptics/ogg, haptics/ivt are already widel= y in use, in millions of devices around the world. It is my understanding t= hat we cannot really register a haptics/ahap or haptics/ivt format until th= e top-level media type ('haptics') is accepted and registered. Given the s= tandardization progress in MPEG, it seems most logical to use the Standards= Track RFC route to get 'haptics' registered as a top-level type first. I would probably be informative to prepare draft IANA registrations of the = haptics type and two or three subtypes and see how writing up the registrat= ions works out in practice. [[YKM]] I am not sure what you mean by 'draft IANA registrations'. The IANA= registration website does not have a provision to specify a new top-level = media type. You have to choose from a fixed drop-down list of currently app= roved top-level types in order to register a new subtype. Given that 'hapti= cs' is not part of the top-level media type list yet, I do not see how I ca= n proceed with a 'draft' registration for any of the subtypes of interest. = Am I missing something? Dale From nobody Fri Oct 23 14:19:19 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B345C3A0ADC; Fri, 23 Oct 2020 14:15:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dispatch@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348775272.5087.5169205823013496720@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:52 -0700 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 109 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:15:57 -0000 Dear Ben Campbell, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:00 requested) Monday, 16 November 2020, Session I 1200-1400 Room Name: Room 1 size: 501 --------------------------------------------- Special Note: Joint with ARTAREA iCalendar: https://datatracker.ietf.org/meeting/109/sessions/dispatch.ics Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Ben Campbell Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 90 Conflicts to Avoid: Chair Conflict: rum stir sipcore mmusic ecrit avtcore cfrg quic httpbis add Technology Overlap: perc cellar capport dmarc jmap uta rmcat extra core opsarea tsvarea tsvwg tram secdispatch Key Participant Conflict: acme cose dprive lamps tls mls People who must be present: Barry Leiba Ben Campbell Murray Kucherawy Patrick McManus Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA. Please avoid conflicts with other ART area WGs and BoFs, other area meetings, and Bofs.. --------------------------------------------------------- From nobody Sat Oct 24 09:29:12 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5DA3A0EA6 for ; Sat, 24 Oct 2020 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QK4BwOmvM9CW for ; Sat, 24 Oct 2020 09:29:08 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5190E3A0EAD for ; Sat, 24 Oct 2020 09:29:08 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kWMPe-000JdU-Dd; Sat, 24 Oct 2020 12:29:02 -0400 Date: Sat, 24 Oct 2020 12:28:56 -0400 From: John C Klensin To: Yeshwant Muthusamy cc: "Dale R. Worley" , dispatch@ietf.org, Chris Ullrich Message-ID: <5D4BA954F5D5A8C21E7CE497@PSB> In-Reply-To: References: (ymuthusamy@immersion.com) <87tuunavzc.fsf@hobgoblin.ariadne.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 16:29:11 -0000 --On Friday, October 23, 2020 13:38 +0000 Yeshwant Muthusamy wrote: > [[YKM]] 'haptics' has been proposed as a first-order media > type in the ISOBMFF standard (ISO/IEC 14496-12), at the same > level as 'audio' and 'video', so we could indeed have .mp4 > files that just have haptic tracks in them. The ISBOMFF > Amendment containing our proposal is expected to issue in > October 2021 (the January 2022 date in the I-D is an error > that will be fixed in the next revision). Bullet #1 in Section > 2.1 talks of 'haptics/mp4' files containing just haptics > tracks, likely useful for streaming games, haptic files for > haptic vests, belts, suits, etc. I think some of the confusion here is that creation of a new top-level media type is a big deal, both in terms of potential impact on the Internet and in terms of the number of details that need to be worked out. At least one of Dale's comments (below) is connected to that problem. So, I would like to encourage you to think about this a bit differently. If you are not already in close touch with, and participating in, ISO/IEC JTC1 SC29 (the body responsible for ISO/IEC 14496-12), make that connection. If you need help, you might approach Stephan Wenger, who is IETF's liaison to that SC (see https://www.ietf.org/about/liaisons/ ). If they are establishing the "real" definition for the top-level type and they (or their MA) are defining or approving the registrations, ending up with a separate registration system in the IETF -- one that might not be precisely synchronized -- would be really bad news. This may suggest a somewhat different approach to what you are trying to do. My suggestion (speaking for myself only but with some small background with IETF Media Type definitions) is that the ideal way to get the top-level type you are looking for would start with a request from JTC1 SC29 for this. The request should propose a mechanism for ensuring that everything says synchronized. One way to do that would be for the authoritative definitions to be theirs (your I-D goes a small distance in that direction) and that actual subtyppe registrations use names they have registered (presumably through their MA) and incorporate their definitions by reference. >> Another is that it seems like few of these media formats are >> non-secret. There are registrations of media formats that are >> patent-encumbered, but the specifics of those formats can be >> documented. What would really encourage support for a haptics >> data type is one or more open standards. > [[YKM]] As we mention > in Section 2.5 (Haptic Subtypes (in use)), several haptic > subtypes like haptics/ahap, haptics/ogg, haptics/ivt are > already widely in use, in millions of devices around the > world. It is my understanding that we cannot really register a > haptics/ahap or haptics/ivt format until the top-level media > type ('haptics') is accepted and registered. Given the > standardization progress in MPEG, it seems most logical to use > the Standards Track RFC route to get 'haptics' registered as a > top-level type first. But this just reinforces the suggestion above. The IETF cannot possibly prevent anyone who feels like it from defining a top-level media type of their own, putting it into use, and sharing it with their friends or admirers. In that context, the purpose of IETF standardization of media types (and IANA registration of subtypes) is to ensure uniqueness (vastly reduce the risk of two entities using the same name for different things) and that there is documentation available and how to find it. If "haptics/" with several subtypes is already in active use, then either there is an existing registration or assignment system in place on which an IETF definition and registration procedures should build or an IETF effort should start with a different name and the understanding that, unless everyone is on board, the effort could easily build confusion rather than reducing it. >> I would probably be informative to prepare draft IANA >> registrations of the haptics type and two or three subtypes >> and see how writing up the registrations works out in >> practice. [[YKM]] I am not sure what you mean by 'draft IANA >> registrations'. The IANA registration website does not have a >> provision to specify a new top-level media type. You have to >> choose from a fixed drop-down list of currently approved >> top-level types in order to register a new subtype. Given that >> 'haptics' is not part of the top-level media type list yet, I >> do not see how I can proceed with a 'draft' registration for >> any of the subtypes of interest. Am I missing something? I don't think Dale is but let me say almost the same thing from a slightly different perspective. If there is going to be a new top-level type, your defining document needs to specify exactly how subtypes will be registered and managed. If there are going to be submissions to IANA, you should provide a registration template (or incorporate an existing one by explicit reference) and I think Dale was asking for examples of that that template would look like filled in. You also need to define how registration applications will be reviewed (see RFC 8126). And that brings me back to the suggestion above: especially since there is probably not broad knowledge of haptics and practices with them in the IETF, the easiest way to write those sections (if it is possible) would be to say that me Maintenance Agency for ISOBMFF (or whatever is actually correct) will register names and then pass them to IANA for subtype registration, moving the decision-making out of the IETF's active responsibilities. good luck. john From nobody Sun Oct 25 19:12:56 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531943A17D8 for ; Sun, 25 Oct 2020 19:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net 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 T7mAgGSlNulD for ; Sun, 25 Oct 2020 19:12:53 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 D15133A17D7 for ; Sun, 25 Oct 2020 19:12:53 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-03v.sys.comcast.net with ESMTP id WrkskAAa8REhUWs0CkHDnv; Mon, 26 Oct 2020 02:12:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1603678372; bh=+LkL9qa1SHAGnU4PML/wXFB8pij898EHeypG4eOu5NQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=cMBDivV53S/Uef5MepIYLNPNz3w6ORFPfExqH9ATd4hItLabk4sIrpfAMpAI5XMnp 4YsYUZfHmN7F5Ce7lGzHWTzy2zCglu9KYQ7zN+vhkKV7H2lyDKRwlNYbEDFnd5gdbd RAiIP5H6iisQf+hlui14FHop19cBJbDPWRI3wEPKwBkdXRBDF1mr0Wppqd6JtM4D9n CZ3AZYUY7kogA/2rWuuGF3OQQf5slNx8xPJI480oJ7oTaDB8lprJGzfLCMFisH0oJQ 29Ngy6CCarrT4bdMWfYVerUSqex2U0h6CPpzZqZ3/Y652OVHsdrPmLby+xcDEklOXG sbvWqCDl1KYsQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-13v.sys.comcast.net with ESMTPA id Ws0Akyux25EocWs0Bk5E8C; Mon, 26 Oct 2020 02:12:52 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id 09Q2CoT1009711; Sun, 25 Oct 2020 22:12:50 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 09Q2CnIu009706; Sun, 25 Oct 2020 22:12:49 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Yeshwant Muthusamy Cc: dispatch@ietf.org, cullrich@immersion.com In-Reply-To: (ymuthusamy@immersion.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 25 Oct 2020 22:12:49 -0400 Message-ID: <87blgp4twe.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 02:12:55 -0000 Yeshwant Muthusamy writes: > [[YKM]] As we mention in Section 2.5 (Haptic Subtypes (in use)), > several haptic subtypes like haptics/ahap, haptics/ogg, haptics/ivt > are already widely in use, in millions of devices around the world. It > is my understanding that we cannot really register a haptics/ahap or > haptics/ivt format until the top-level media type ('haptics') is > accepted and registered. Given the standardization progress in MPEG, > it seems most logical to use the Standards Track RFC route to get > 'haptics' registered as a top-level type first. I'm sure you are right, but that's not addressing the point I made: If the details of an encoding are secret, there is going to be general antipathy in the IETF toward recognizing it as an "official" media type. Conversely, pointing to a public document describing the details of the encodings will improve your chances of getting the concept accepted by the IETF. > > I would probably be informative to prepare draft IANA registrations > > of the haptics type and two or three subtypes and see how writing up > > the registrations works out in practice. > [[YKM]] I am not sure what you mean by 'draft IANA registrations'. The > IANA registration website does not have a provision to specify a new > top-level media type. You have to choose from a fixed drop-down list > of currently approved top-level types in order to register a new > subtype. Given that 'haptics' is not part of the top-level media type > list yet, I do not see how I can proceed with a 'draft' registration > for any of the subtypes of interest. Am I missing something? You understand that you need to write a draft RFC to create the top-level type, and to get it accepted. One thing that helps get any draft RFC accepted is to provide examples of the thing you are proposing. In the case of a top-level media type, having the RFC include registrations of a number of subtypes is useful, because it shows people that there is practical benefit to be gained immediately, and also to show them what these subtype registrations look like. Ideally, these proposed registrations will point to enough information to enable the reader to implement the encoding. Dale From nobody Mon Oct 26 08:30:03 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025DB3A0C4C for ; Mon, 26 Oct 2020 08:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=mrochek.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 Ai44tYIyFmOF for ; Mon, 26 Oct 2020 08:30:00 -0700 (PDT) Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (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 3EF0A3A0C4D for ; Mon, 26 Oct 2020 08:30:00 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RR9AHALQSG00BVIR@mauve.mrochek.com> for dispatch@ietf.org; Mon, 26 Oct 2020 08:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1603725896; bh=VTl6grpsExq+mKya+sry3GgpdIlz3BzQS3Mvdvb4bPE=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=b3nG26bYgwo+vz8tGlilx1+LFllOF5VTxKCamnJwL7FIHmms4jpbEajLqK0ivXOmy ZuLs/rEG1j+NUXaYMyPeyQiXDYLjuveKvz96tpRPHAJBIZ0YRfozsRb0YLeROUG34q 6tPodZlvQbH6ieHcNWArVLBnZzeHd6fjKV9/bu14= MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RQN4TDY6V4005PTU@mauve.mrochek.com>; Mon, 26 Oct 2020 08:24:52 -0700 (PDT) Cc: Yeshwant Muthusamy , cullrich@immersion.com, dispatch@ietf.org Message-id: <01RR9AH8DZ4G005PTU@mauve.mrochek.com> Date: Mon, 26 Oct 2020 07:46:49 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 25 Oct 2020 22:12:49 -0400" <87blgp4twe.fsf@hobgoblin.ariadne.com> References: <87blgp4twe.fsf@hobgoblin.ariadne.com> To: worley@ariadne.com Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 15:30:02 -0000 > Yeshwant Muthusamy writes: > > [[YKM]] As we mention in Section 2.5 (Haptic Subtypes (in use)), > > several haptic subtypes like haptics/ahap, haptics/ogg, haptics/ivt > > are already widely in use, in millions of devices around the world. It > > is my understanding that we cannot really register a haptics/ahap or > > haptics/ivt format until the top-level media type ('haptics') is > > accepted and registered. This may be the case, but it's not the only, or most important case you need to make when justifying the creation of a top-level type. In particular, you need to explain why haptics deserve special recognition rather than living under application, as a myriad of other things (word processing formats, spreadsheet formats, automative control formats, etc.) do. I don't think this is a difficult case to make - it seems to me that haptics data represents a fundamentally different sort of data in the same way that we differentiate audio, video, etc. But I think section 2 falls short of making the case currently. > > Given the standardization progress in MPEG, > > it seems most logical to use the Standards Track RFC route to get > > 'haptics' registered as a top-level type first. > I'm sure you are right, but that's not addressing the point I made: If > the details of an encoding are secret, there is going to be general > antipathy in the IETF toward recognizing it as an "official" media type. If by "official" you mean standards tree, you can also replace "antipathy" with "not going to happen". The specification requirements for standards tree types (RFC 6838 section 4.10) are quite clear, the consensus behind those requirements was overwhelming, and I see no reason to believe that has changed. Indeed, if anything the compromise was to allow specifications for types that you have to pay to get the specifications. Of course nothing prevents you from registering a vendor tree type with a name of the form haptics/vnd.foo. There is no requirement for a publicly available specification there. And if existing practice must be catered to I suppose you could make an argument that if a name haptics/foo is already in wide use an exception could be made to allow that name to be associated with a vendor tree type. But there is also a good chance that this will be seen as an end run around the process, and even if succesful, when all is said and done the type won't be in the standards tree, appearances to the contrary notwithstanding. > Conversely, pointing to a public document describing the details of the > encodings will improve your chances of getting the concept accepted by > the IETF. While it's possible to register an initial set of media types in a top-level type proposal, it's definitely not required. And while including illustrative and noncontroversial examples can be helpful - as noted below - attempting to resolve every issue you have all at once rarely works well. As such, I recommend that any potentially problematic registrations be deferred until after you have the top level type in place. > > > I would probably be informative to prepare draft IANA registrations > > > of the haptics type and two or three subtypes and see how writing up > > > the registrations works out in practice. > > [[YKM]] I am not sure what you mean by 'draft IANA registrations'. The > > IANA registration website does not have a provision to specify a new > > top-level media type. You have to choose from a fixed drop-down list > > of currently approved top-level types in order to register a new > > subtype. Given that 'haptics' is not part of the top-level media type > > list yet, I do not see how I can proceed with a 'draft' registration > > for any of the subtypes of interest. Am I missing something? > You understand that you need to write a draft RFC to create the > top-level type, and to get it accepted. One thing that helps get any > draft RFC accepted is to provide examples of the thing you are > proposing. In the case of a top-level media type, having the RFC > include registrations of a number of subtypes is useful, because it > shows people that there is practical benefit to be gained immediately, > and also to show them what these subtype registrations look like. > Ideally, these proposed registrations will point to enough information > to enable the reader to implement the encoding. Exactly right. Ned From nobody Tue Oct 27 04:33:10 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217B13A005C for ; Tue, 27 Oct 2020 04:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvBmjTEi2ol5 for ; Tue, 27 Oct 2020 04:33:08 -0700 (PDT) Received: from smtp127.ord1d.emailsrvr.com (smtp127.ord1d.emailsrvr.com [184.106.54.127]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CBB3A0045 for ; Tue, 27 Oct 2020 04:33:08 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp8.relay.ord1d.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 29B9EC0229; Tue, 27 Oct 2020 07:33:07 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_9E6BCD14-ADE8-4358-ACA8-825C28F30D4A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Cullen Jennings In-Reply-To: Date: Tue, 27 Oct 2020 05:33:06 -0600 Cc: "dispatch@ietf.org" , Chris Ullrich Message-Id: <8A14E9C6-2530-4E17-93DC-ECB943FAB94B@iii.ca> References: To: Yeshwant Muthusamy X-Mailer: Apple Mail (2.3445.104.17) X-Classification-ID: c0282a2e-2eaf-497c-be40-b27f2afd4acc-1-1 Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 11:33:10 -0000 --Apple-Mail=_9E6BCD14-ADE8-4358-ACA8-825C28F30D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This is a very nicely written draft and I think the IETF is the best = place to discuss this topic. I hope to see it get agenda time at and = upcoming meeting.=20 The biggest question I had while reading it was, what do we even do with = top level media types at this point ? What interoperability problem are = we trying to solve? Should we deprecate top level media types ? How do = we deal with that this media type is often embedded in a video stream? = Is this really different than game controller inputs and moves in real = time settings?=20 The need for things like the hstr, hieee, henm, havc all make sense. = But I wondering about what we really need the top level type for. = Perhaps we should just have a top level type of =E2=80=9Cother=E2=80=9D. = I really have no idea of best answer to this but your draft did make me = wonder. The flips side is that if top levels don=E2=80=99t mean much, = there is no harm in defining a bunch of them.=20 > On Oct 21, 2020, at 12:25 PM, Yeshwant Muthusamy = wrote: >=20 > Folks, > =20 > Re-posting with a more descriptive subjective line, since my previous = post (see below) has not engendered any comments (yet). > =20 > https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ = > =20 > Thanks, > Yeshwant > =20 > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards > > ymuthusamy@immersion.com | +1 = 469-583-2171 > =20 > From: Yeshwant Muthusamy=20 > Sent: Tuesday, October 13, 2020 3:53 PM > To: dispatch@ietf.org > Cc: Chris Ullrich > > Subject: draft-muthusamy-dispatch-haptics-00.txt > =20 > I would like to initiate discussion on = draft-muthusamy-dispatch-haptics: > =20 > https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-haptics/ = > =20 > An informal (and earlier) version of this document was discussed on = the Media-Types mailing list (media-types@ietf.org = ): > =20 > = https://mailarchive.ietf.org/arch/msg/media-types/3cXb69ybEa65oCCIiHjl0MtG= XVY/ = > =20 > Look forward to your questions and comments. > =20 > Thanks, > Yeshwant > =20 > Yeshwant Muthusamy, Ph.D. | Senior Director, Standards > > ymuthusamy@immersion.com | +1 = 469-583-2171 > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch = --Apple-Mail=_9E6BCD14-ADE8-4358-ACA8-825C28F30D4A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

This is a very nicely written draft and = I think the IETF is the best place to discuss this topic. I hope to see = it get agenda time at and upcoming meeting. 

The biggest question I had while = reading it was, what do we even do with top level media types at this = point ?  What interoperability problem are we trying to solve? = Should we deprecate top level media types ? How do we deal with that = this media type is often embedded in a video stream?  Is this = really different than game controller inputs and moves in real time = settings? 

The need = for things like the  hstr, hieee, henm, havc all make sense. But I = wondering about what we really need the top level type for. Perhaps we = should just have a top level type of =E2=80=9Cother=E2=80=9D. I really = have no idea of best answer to this but your draft did make me wonder. = The flips side is that if top levels don=E2=80=99t mean much, there is = no harm in defining a bunch of them. 



On Oct 21, 2020, at 12:25 PM, = Yeshwant Muthusamy <ymuthusamy@immersion.com> wrote:

Folks,
 
Re-posting with a more = descriptive subjective line, since my previous post (see below) has not = engendered any comments (yet).
 
https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-hapti= cs/
 
Thanks,
Yeshwant
 
Yeshwant = Muthusamy, Ph.D. | Senior Director, Standards
<image001.jpg>
ymuthusamy@immersion.com | +1 = 469-583-2171
 
From: Yeshwant Muthusamy 
Sent: Tuesday, October 13, 2020 = 3:53 PM
To: dispatch@ietf.org
Cc: Chris Ullrich <cullrich@immersion.com>
Subject: draft-muthusamy-dispatch-hapt= ics-00.txt
 
I would like to initiate = discussion on draft-muthusamy-dispatch-haptics:
 
https://datatracker.ietf.org/doc/draft-muthusamy-dispatch-hapti= cs/
 
An informal (and earlier) = version of this document was discussed on the Media-Types mailing list = (media-types@ietf.org):
 
https://mailarchive.ietf.org/arch/msg/media-types/3cXb69ybEa65o= CCIiHjl0MtGXVY/
 
Look forward to your = questions and comments.
 
Thanks,
Yeshwant
 
Yeshwant Muthusamy, Ph.D. = | Senior Director, Standards
<image001.jpg>
ymuthusamy@immersion.com | +1 = 469-583-2171
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

= --Apple-Mail=_9E6BCD14-ADE8-4358-ACA8-825C28F30D4A-- From nobody Tue Oct 27 04:44:14 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E77B3A0061 for ; Tue, 27 Oct 2020 04:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.147 X-Spam-Level: X-Spam-Status: No, score=-2.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.247, 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=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-cZB5YV1czq for ; Tue, 27 Oct 2020 04:44:10 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410124.outbound.protection.outlook.com [40.107.141.124]) (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 574063A005D for ; Tue, 27 Oct 2020 04:44:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NkFeDYcfWq2RYOPxhXndj36kgj6bu7fVVO5sF4l7JMJRDcLDg73rEz4Ji4s6/WBfuNBay4KJeE6Ty6HdKT79wnKbvw+dk5kphm6UvXu/pXeoZn4/9nVAY0ESmB21MyrfWFZHz2eGN63czk2Fin17EcHRP9LznvRnPqqYHXXpYAkWcm+6WM9GlmFaXJEof5+vhPPQ0obQX8mPSFPP51/TkwZG7ciG+4Q113NvjJjQCJ6teiK75ik9aASk/H0nAo6Ni56ucTi/wtVgPTQibB50/Tht9OktylO4lTQMFEk0gQDkb3Saw8+9SU/WoJLvnpj1/8TtEoQvqaZuYIs3LppIPg== 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-SenderADCheck; bh=iCu/QmIzhEjOENUdJ9hXpSX2xFnRuhgkLh+YCHtw6Mg=; b=nZ9wk6NPLAI4GV/7gh9P0ZXozBToA1mD6L2tGsSpmYJBusX16HULGSTtdIZIiDUYAfOiN8Kybgex0bfBJ1dwjbCGeoWIa3OZ6zJv4e6Hhf6Oi4PurP73fSlPrkZjkr1SN13g6mfltIaxab9V3XhBLzwQLOanzplAPKLq/m/Skq1fj+08LUt4BUs9my5mOszAenWtt0K/1Hg01gMl7IbUOaVv9Wz3xSfhMWh7BOJpGEjQaHmvfzx6OajSqSlnfUzT2ER26krSpbcPaySo2orMdvzAgqOsdkMfKFXZl1A3yx3JWkJHeyeU4f1K5UYXoZWftM8+4QLVurMVgrfTgRqEMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iCu/QmIzhEjOENUdJ9hXpSX2xFnRuhgkLh+YCHtw6Mg=; b=KeVpU5ktxuSQx2kPppuCeIWUbuPjgPViWdCvVrUfSom1JabWxWYqS/rE2hoFvIlArXjzzCxU74N1zThoe2xL5W9Nk9CjAg2tEKc9oUrm7QHe4uj1NtRmoRrNH0LraXQC455PT711dvpFMMyNEPt1mwE6vKwTNnkL9jP/a/1Wn58= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) by OSAPR01MB4932.jpnprd01.prod.outlook.com (2603:1096:604:69::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.27; Tue, 27 Oct 2020 11:44:02 +0000 Received: from OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7]) by OSBPR01MB2566.jpnprd01.prod.outlook.com ([fe80::50b8:6d53:1b35:2ef7%6]) with mapi id 15.20.3477.028; Tue, 27 Oct 2020 11:44:02 +0000 To: Ned Freed , worley@ariadne.com Cc: cullrich@immersion.com, Yeshwant Muthusamy , dispatch@ietf.org References: <87blgp4twe.fsf@hobgoblin.ariadne.com> <01RR9AH8DZ4G005PTU@mauve.mrochek.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Tue, 27 Oct 2020 20:43:59 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 In-Reply-To: <01RR9AH8DZ4G005PTU@mauve.mrochek.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [114.182.253.12] X-ClientProxiedBy: TY2PR01CA0011.jpnprd01.prod.outlook.com (2603:1096:404:a::23) To OSBPR01MB2566.jpnprd01.prod.outlook.com (2603:1096:604:1c::13) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (114.182.253.12) by TY2PR01CA0011.jpnprd01.prod.outlook.com (2603:1096:404:a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Tue, 27 Oct 2020 11:44:00 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c1979733-5dd6-4cd1-ebed-08d87a6d9917 X-MS-TrafficTypeDiagnostic: OSAPR01MB4932: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kRThcUyt5mXep7cMC18RmUy/a4TRtjK0yC+pHfFOFXTy3WuPmmY0NUs8wF3uzPpNI2BIGWZUDm4TTdEmSH2lFYdOLqIz0KoOpkL0/DBvcb7wTV9lhwskGO2BgMu5HaPrzWhXS0vnzsnMnQZ1RTe1Hdyn38OehSBskyi0okXzcUIA/MQm3NY0yaO+gqsUKNoPwLgKkH1ui5TWzuy4nvsuLnXNPMsAWwkByr7XSZWJcBZuZXm0JOqURlUPPwCU1ouS/EONTFB0vhetXJiWpjvor+zFXEhLdoc0hZwTSn1QUBrjurQYl16TPV1gI6MAObyy2pmyTT6XKr3T3a8R3x0wti6hREcYFJNCvkMnJ7+LLISWV0IWVW9RB17p5/rWybmi X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:OSBPR01MB2566.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(136003)(39840400004)(396003)(31686004)(26005)(4326008)(186003)(956004)(478600001)(2616005)(6486002)(53546011)(5660300002)(316002)(86362001)(16576012)(66946007)(66556008)(2906002)(786003)(16526019)(52116002)(8676002)(66476007)(83380400001)(8936002)(31696002)(36916002)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: YZpHZ9mkcsH3oyWZIBbwmidbdaaWaWc/XHc+RGx23jAl4GzNvl1gVosxOGIovIrWdQmpTMjYa8ST5hsvJk1D8gmIodQVS+MqIUJ1gWWsFp71e/4FcQmyfZcf1Ehz5cHLqYoR/0sabX+EYMTdFB9Go0kz0JOD92910JYsDiqOsR1iwAoa6sL2qotkiUxkUHFS8AQymtzriNJ+a8kaEzrgfgshP9kEnx7FZy4Ti6bH3DeEodIBrjQMHl2hiX8TlVXF+W/b8vcYBWx6xKLEa355kfW3EB5FIyZPnOeGk/yTuMCRgSQQQAhV1t3IYSKKJ7pTxRin2roJqu9Lm0+ybooD9n6x3Insb4DlF6PQ88nVuNPwI/Kbj13BeCPqBUTiTI1pF7mew2BStJyM26X5vEUXAfla+0imcIuxZw5GZ1Bmyenb7vHTcVDq8EcZnmX2wIgkIxwru6r2DM9Lc771OxbztzpVzEUady5cBosQPuf3uH5sbSRnbWOzwKMCG0effKRWR9E52TrIjuOmMBIWP3KyxfwX1/GZq09rFC8RZdErkWjrb/OHHfL0T5Q/oA22n3x3kF66TslzK1+UifcyBxsVlHjNWqWsehN5rRM57ZJnSoW+rwk4E3EUpHkv7+f6aYb8sbNnWvMxd2ZNYCP4KGbrOA== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: c1979733-5dd6-4cd1-ebed-08d87a6d9917 X-MS-Exchange-CrossTenant-AuthSource: OSBPR01MB2566.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2020 11:44:02.1015 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: ItLTlyEqmvDSx8cfKxrzn+46Ymo1heGy8F/HIjpnedhyEM0KzRdKTYyT0xvYu2FsAeMbH4ua9FhiejQspMeEQA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSAPR01MB4932 Archived-At: Subject: Re: [dispatch] Proposal to add 'haptics' as a new top-level media type - Comments welcome [Was RE: draft-muthusamy-dispatch-haptics-00.txt] X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 11:44:12 -0000 On 26/10/2020 23:46, Ned Freed wrote: >> Yeshwant Muthusamy writes: >>> [[YKM]] I am not sure what you mean by 'draft IANA registrations'. The >>> IANA registration website does not have a provision to specify a new >>> top-level media type. You have to choose from a fixed drop-down list >>> of currently approved top-level types in order to register a new >>> subtype. Given that 'haptics' is not part of the top-level media type >>> list yet, I do not see how I can proceed with a 'draft' registration >>> for any of the subtypes of interest. Am I missing something? > >> You understand that you need to write a draft RFC to create the >> top-level type, and to get it accepted. One thing that helps get any >> draft RFC accepted is to provide examples of the thing you are >> proposing. In the case of a top-level media type, having the RFC >> include registrations of a number of subtypes is useful, because it >> shows people that there is practical benefit to be gained immediately, >> and also to show them what these subtype registrations look like. >> Ideally, these proposed registrations will point to enough information >> to enable the reader to implement the encoding. > > Exactly right. Yes. For a very good example, please look at RFC 8081, which registers 6 subtypes. In addition to the arguments Ned gave above, including non-controversial subtypes in the same document not only shows people that there is practical benefit to be gained immediately, the practical benefit will actually be gained immediately when the document is accepted. As an aside, I think delegating the registration of subtypes in a certain top-level type to some other standards organization (as alluded to by John Klensin) is a bad idea because it would create confusion and additional overhead. To have some people familiar with haptics on the media-types@ietf.org mailing list in case specific expertise is needed would be better. Regards, Martin. From nobody Tue Oct 27 12:05:21 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5D33A1509; Tue, 27 Oct 2020 12:05:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160382551930.19268.9248956922355934277@ietfa.amsl.com> Date: Tue, 27 Oct 2020 12:05:19 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 19:05:19 -0000 IANA action state changed to "Waiting on Authors" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Tue Oct 27 14:05:41 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4B03A15B3; Tue, 27 Oct 2020 14:05:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160383274012.24104.16488147715534420760@ietfa.amsl.com> Date: Tue, 27 Oct 2020 14:05:40 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 21:05:40 -0000 IANA action state changed to "In Progress" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Wed Oct 28 07:43:17 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A893A09C5; Wed, 28 Oct 2020 07:43:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: sframe-chairs@ietf.org, sframe@ietf.org, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160389619554.26154.17310005023276866720@ietfa.amsl.com> Date: Wed, 28 Oct 2020 07:43:15 -0700 Archived-At: Subject: [dispatch] Barry Leiba's No Objection on charter-ietf-sframe-00-02: (with COMMENT) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 14:43:16 -0000 Barry Leiba has entered the following ballot position for charter-ietf-sframe-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-sframe/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I wonder whether this should be chartered in the Sec Area with an ART AD (Murray) set as responsible AD. I also think the last bit: Input to the WG Proposals already existing relating to this charter proposal: https://datatracker.ietf.org/doc/html/draft-omara-sframe-00 ...shouldn't be in the final charter text (it was fine to have it there during review). The draft is referenced in the milestone, and that should cover it. From nobody Wed Oct 28 08:27:56 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BAB3A0AA1 for ; Wed, 28 Oct 2020 08:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, 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 DmFx31ov-DtM for ; Wed, 28 Oct 2020 08:27:46 -0700 (PDT) Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B543A0A9B for ; Wed, 28 Oct 2020 08:27:46 -0700 (PDT) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id D6D92E05A9; Wed, 28 Oct 2020 15:27:45 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id D3F7020364; Wed, 28 Oct 2020 15:27:45 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: drafts-approval@iana.org In-Reply-To: <160279697806.10019.3270414745568518517@ietfa.amsl.com> References: <160279697806.10019.3270414745568518517@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1180551 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: ted.ietf@gmail.com, barryleiba@gmail.com, superuser@gmail.com, barryleiba@computer.org, spencerdawkins.ietf@gmail.com, dispatch@ietf.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 28 Oct 2020 15:27:45 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [dispatch] [IANA #1180551] Protocol Action: 'Updated registration rules for URI.ARPA' to Best Current Practice (draft-hardie-dispatch-rfc3405-update-04.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 15:27:50 -0000 Dear Author: ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED We've completed the registry actions for the following RFC-to-be: draft-hardie-dispatch-rfc3405-update-04 This document has been listed as an additional reference for the following entry at https://www.iana.org/domains/arpa: uri.arpa For resolving Uniform Resource Identifiers according to the Dynamic Delegation Discovery System RFC 3405 draft-hardie-dispatch-rfc3405-update Please let us know whether this document's registry actions have been completed correctly. Once we receive your confirmation, we'll notify the RFC Editor that the actions are complete. We'll update this reference when the RFC Editor notifies us that they've assigned an RFC number. Best regards, Amanda Baber Lead IANA Services Specialist From nobody Wed Oct 28 09:05:17 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C678A3A064A; Wed, 28 Oct 2020 09:05:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160390111280.17125.10026064749055591088@ietfa.amsl.com> Date: Wed, 28 Oct 2020 09:05:12 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 16:05:13 -0000 IANA action state changed to "Waiting on Authors" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Wed Oct 28 13:09:57 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EFF3A09AC for ; Wed, 28 Oct 2020 13:09:56 -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 yCO13kR27oVf for ; Wed, 28 Oct 2020 13:09:55 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49DE03A09A8 for ; Wed, 28 Oct 2020 13:09:55 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id s21so899895oij.0 for ; Wed, 28 Oct 2020 13:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y4jmaI/4yPaXaiEFneYRIQldcmIkeZoSxy16EnatT6w=; b=E4yLxULaY0UknBHTBW2nUcDkcOsJnwZvcWK/PpNvAM2aRHTrfxaGXwCvn4PGIDyLPP +UQIsP05Dzl+SDvpQ+pefbbajdH1xQzrI9JfvB5bNKRmaTypgk0cjUSTvsM4a65zUXDT BPcwxXHylB5AafnnGKGwVrbXZnfMdMGjB7BbXKYTY4Ta/kZrfv1xNK1SsZiO2czJmark 3qqk8g6CJ05TpRdknx2lBs5niuj8KdDK8FtuJBu4hvk20iYqBN3Ja7TDNU3bvWcbvIQ8 i9HBTb5qf8O5oxM4IV5fMAABuciuPTUnTFQl82C7JvrffkCm/decKUscJAvAWtC+fcFf 1dgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y4jmaI/4yPaXaiEFneYRIQldcmIkeZoSxy16EnatT6w=; b=Co0tNR+cHtM6exhCLB/OCSqtQBYkMSOdh5/2Zp5fAO+YAH6pjVVUUj/WUMBAQRtgaR QWDBr5SMFfOnBSSQa8ugE43zoJp/CGbS/A0D7uQHQ/cS9+i2h6hQT4hAGb0fIBuHYMz8 3ts0UEGoEmiGs6NdV42cBbJpqmT8kYzvFSEBU1FtJBj0hyY8NGxGvFi74BSkJ+t8aXYl gkI5urn9Ef6KXMC05+9oa2/vo8envHoVJ4AuDFCwoEO96RPOHnbSEJE1e58lrKbIvRtw lO+uNOqNrjqahL74EcHb3OAoZJ4BhgvQJNONbdtz/O2xAKeQT1xF8L9HZ0ncQ+jd891g jJWw== X-Gm-Message-State: AOAM533iGrD4PgAXuf1LSnU4osdRgYku1xAEN/62gGJyreJU8yOhIetX vOZx+QvsWtt3/Q+jMg9OviZCCbZuohNDbZJUS4s= X-Google-Smtp-Source: ABdhPJymGRT/ymJkQJHo+kuXECt6PwcRcjs5xb7sv4bArPEyKWdPYJQZOXOWUpvV3ifiJ9cU2qbPRLda62A6V3zmf9A= X-Received: by 2002:aca:bc03:: with SMTP id m3mr514192oif.35.1603915794649; Wed, 28 Oct 2020 13:09:54 -0700 (PDT) MIME-Version: 1.0 References: <160279697806.10019.3270414745568518517@ietfa.amsl.com> In-Reply-To: From: Ted Hardie Date: Wed, 28 Oct 2020 13:09:28 -0700 Message-ID: To: drafts-approval@iana.org Cc: Barry Leiba , "Murray S. Kucherawy" , Barry Leiba , Spencer Dawkins , Dispatch WG Content-Type: multipart/alternative; boundary="0000000000003095db05b2c0bf76" Archived-At: Subject: Re: [dispatch] [IANA #1180551] Protocol Action: 'Updated registration rules for URI.ARPA' to Best Current Practice (draft-hardie-dispatch-rfc3405-update-04.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 20:09:57 -0000 --0000000000003095db05b2c0bf76 Content-Type: text/plain; charset="UTF-8" I believe these actions are correct and complete. regards, Ted Hardie On Wed, Oct 28, 2020 at 8:27 AM Amanda Baber via RT < drafts-approval@iana.org> wrote: > Dear Author: > > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > > We've completed the registry actions for the following RFC-to-be: > > draft-hardie-dispatch-rfc3405-update-04 > > This document has been listed as an additional reference for the following > entry at https://www.iana.org/domains/arpa: > > uri.arpa > For resolving Uniform Resource Identifiers according to the Dynamic > Delegation Discovery System > RFC 3405 draft-hardie-dispatch-rfc3405-update > > Please let us know whether this document's registry actions have been > completed correctly. Once we receive your confirmation, we'll notify the > RFC Editor that the actions are complete. > > We'll update this reference when the RFC Editor notifies us that they've > assigned an RFC number. > > Best regards, > > Amanda Baber > Lead IANA Services Specialist > > --0000000000003095db05b2c0bf76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe these actions are correct and complete.

regards,

Ted Hardie

On We= d, Oct 28, 2020 at 8:27 AM Amanda Baber via RT <drafts-approval@iana.org> wrote:
Dear Author:

ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED

We've completed the registry actions for the following RFC-to-be:

draft-hardie-dispatch-rfc3405-update-04

This document has been listed as an additional reference for the following = entry at https://www.iana.org/domains/arpa:

uri.arpa
For resolving Uniform Resource Identifiers according to the Dynamic Delegat= ion Discovery System
RFC 3405 draft-hardie-dispatch-rfc3405-update

Please let us know whether this document's registry actions have been c= ompleted correctly. Once we receive your confirmation, we'll notify the= RFC Editor that the actions are complete.

We'll update this reference when the RFC Editor notifies us that they&#= 39;ve assigned an RFC number.

Best regards,

Amanda Baber
Lead IANA Services Specialist

--0000000000003095db05b2c0bf76-- From nobody Wed Oct 28 13:10:19 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689B13A09AD for ; Wed, 28 Oct 2020 13:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.096 X-Spam-Level: * X-Spam-Status: No, score=1.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, MAY_BE_FORGED=2.499, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 c2FFeTH8IwlF for ; Wed, 28 Oct 2020 13:10:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19793A09A8 for ; Wed, 28 Oct 2020 13:10:15 -0700 (PDT) Received: from bens-macbook.lan (mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged)) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 09SKAB25026965 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 28 Oct 2020 15:10:12 -0500 (CDT) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1603915813; bh=m3s7ankboPAWPfqLhtFUwBkGvMmr74EHKhpsnORBhTw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=lnpO40u5DRwD2x2mmZ0xCVukbbmAmbebWqdY+iXpU6O9u/QMNcvrLSED+zIe6zol1 qQ1YFTAyI8oHo27wmMqUQsspSFEHegIcB6HnlgaA0/aM5i3tt7j+0mHcRx3Fhd62d9 TRo3X0KRO4Q1YAPMDEOBcqJonNxK3Jv2DFMoyqmQ= X-Authentication-Warning: raven.nostrum.com: Host mta-70-120-123-175.stx.rr.com [70.120.123.175] (may be forged) claimed to be bens-macbook.lan From: Ben Campbell Message-Id: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28AE3F78-E33E-41BE-9B6C-44C4E5A11FDF" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 28 Oct 2020 15:10:04 -0500 In-Reply-To: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> Cc: Alex Gouaillard , Sergio Garcia Murillo , Patrick McManus To: "dispatch@ietf.org" References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 20:10:18 -0000 --Apple-Mail=_28AE3F78-E33E-41BE-9B6C-44C4E5A11FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Everyone, Did anyone have feedback or other thoughts on Sergio=E2=80=99s proposal? Thanks! Ben. > On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo = wrote: >=20 > Hi all! >=20 >=20 >=20 > While WebRTC has been very successful in a wide range of scenarios, = its adaption in the broadcasting/streaming industry is lagging behind. = Currently there is no standard protocol (like SIP or RTSP) designed for = ingesting media in a streaming service, and content providers still rely = heavily on protocols like RTMP for it. >=20 > These protocols are much older than WebRTC and lack by default some = important security and resilience features provided by WebRTC with = minimal delay. >=20 > The media codecs used in older protocols do not always match those = being used in WebRTC, mandating transcoding on the ingest node, = introducing delay and degrading media quality. This transcoding step is = always present in traditional streaming to support e.g. ABR, and comes = at no cost. However webrtc implements client-side ABR, by means of = simulcast and SVC codecs, which otherwise alleviate the need for = server-side transcoding. Content protection and Privacy Enhancement can = be achieve with End-to-End Encryption, which preclude any server-side = media processing. >=20 > We have been working on a proposal for a simple HTTP based protocol = that will allow WebRTC endpoints to ingest content into streaming = services and/or CDNs to fill this gap and facilitate deployment: >=20 > https://tools.ietf.org/html/draft-murillo-whip-00 = > https://github.com/murillo128/webrtc-http-ingest-protocol/ = >=20 > We have already implemented it on Janus and Medooze media servers: >=20 > https://www.meetecho.com/blog/whip-janus/ = > = https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772= eba8ae7 = >=20 > And added support into a WebRTC version of OBS studio: >=20 > = https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-R= C2 = >=20 > We also plan to have an interop session on the next IETF hackhaton, = that will allow to check the interoperability between different WebRTC = implementations. >=20 >=20 >=20 > What would be the best way of moving this forward? Obviously, any = feedback will be very welcome. >=20 >=20 >=20 > Best regards >=20 > Sergio >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_28AE3F78-E33E-41BE-9B6C-44C4E5A11FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Everyone,

Did anyone = have feedback or other thoughts on Sergio=E2=80=99s proposal?

Thanks!

Ben.

On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

=20 =20

Hi all!


While WebRTC has been very successful in a wide = range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:


We have already implemented it on Janus and = Medooze media servers:


And added support into a WebRTC version of OBS = studio:


We also plan to have an interop session on the = next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.


What would be the best way of moving this forward? = Obviously, any feedback will be very welcome.


Best regards

Sergio



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

= --Apple-Mail=_28AE3F78-E33E-41BE-9B6C-44C4E5A11FDF-- From nobody Wed Oct 28 13:16:08 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6093A09DA for ; Wed, 28 Oct 2020 13:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82eiy5X8VQIu for ; Wed, 28 Oct 2020 13:16:01 -0700 (PDT) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 0BD613A09E0 for ; Wed, 28 Oct 2020 13:16:00 -0700 (PDT) Received: from pps.filterd (m0193507.ppops.net [127.0.0.1]) by m0193507.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 09SK73tN000340 for ; Wed, 28 Oct 2020 16:16:00 -0400 Received: from usecmgip001.mail.tfayd.com ([50.228.147.33]) by m0193507.ppops.net-00176a04. with ESMTP id 34cgpck7nv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 28 Oct 2020 16:16:00 -0400 IronPort-SDR: SaMLjjUWai9xFznynEHrcyMCTGwzlAU9TCmzGAjEkmMVvKFvL/b4nv3ONiJAl/UWZa8T5nX05R ABDHe34LSvSQ== Received: from unknown (HELO potemwp00002.mail.tfayd.com) ([100.124.56.26]) by USECMGIP001.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 28 Oct 2020 16:15:59 -0400 Received: from potemwp00001.mail.tfayd.com (100.124.56.25) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Wed, 28 Oct 2020 14:15:57 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (10.40.33.204) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Wed, 28 Oct 2020 14:15:57 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n7nj+0OQ9LQYbFdMQ8L0zj2dFKHHXhX90ZWUG98URQka6lFVImIfiL/Qps4VdZ6NmzkO4T2qIgllTNW3FgE98n5h24Lnt4tPNFwydLSpca90WBEuHi4u4cbXKHFM1Pm8oYgfGGP0MJ95RC1CTanJQEcD7ouFqnvwyeW4S64e6Cq5vn5zJaCNHDeiH6KkYdGkQf8gra2JWJ0TLbxFT/xtzkGR8019sqauD/Ue7ivX1+i2otw+VQA/MDMjWSZb5RNMRuCuq4GwbZFgdk+JO8MCHZBHwkGUm8YZVIoJei/G3smsxa+0rW8K76gpXGdz+yimvooWbQ2l+hS/lgA22ItF3g== 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-SenderADCheck; bh=OFU5baZo8VVQGXcJiu3MiGLwWnRMvdiexxyUpWcCZ9A=; b=Zm6OyM7CiEN6EFpWfhntEQP+ybN/SYq8ib6bw6xogFxkD5RgU+uq2WB1pufwVADR3ZiKIEjUkK+fOR7iv7aD00nFKNUx32dKJWcXFi7lFDQQ2zUO+IQnL+2OvHCgemtbYSOkbRKk38AGObK3LkmRPerzI/0uRAZl+5jsVt2TDgFVJBFzb4E060b9X+JeVI2O1aCzubUZY9r14ppRZzEkGtI3I6aNeE1+GVSzti5AwpGkrCZNgXyNVeTHR9aNxqVt6S/7EZ7iLCDeTSyuloSzfID7tuo70BIEo6BChu3n3kQfbKtcujmhYbVTGkrVkAa4dUy8zyhnUjB3e/Fj3ho05Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OFU5baZo8VVQGXcJiu3MiGLwWnRMvdiexxyUpWcCZ9A=; b=FebmwVNUADxwk7Jskb46K/3hrSiXneMV4/KJrMi+D8O4q3y/fsfIGXNK+SXMkSCtzsGDykxCLvRRgoHXT08PTzju7iMYysUbT+oGTXyglafsTfHznPNTXAEn/wQozpvbUBxBaMYavGn7AvCuruQr6Tz0DmYy26sNkhsdWw0ioGM= Received: from BYAPR14MB3094.namprd14.prod.outlook.com (2603:10b6:a03:14d::30) by SJ0PR14MB4394.namprd14.prod.outlook.com (2603:10b6:a03:2c9::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.28; Wed, 28 Oct 2020 20:15:55 +0000 Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::589e:ab56:3d14:22db]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::589e:ab56:3d14:22db%6]) with mapi id 15.20.3477.029; Wed, 28 Oct 2020 20:15:55 +0000 From: "Deen, Glenn (NBCUniversal)" To: Ben Campbell , "dispatch@ietf.org" CC: Alex Gouaillard , "Deen, Glenn (NBCUniversal)" Thread-Topic: [dispatch] WHIP - WebRTC HTTP ingestion protocol Thread-Index: AQHWrWckvc1x9VvyWE2KDOP72dVtxQ== Date: Wed, 28 Oct 2020 20:15:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;nostrum.com; dmarc=none action=none header.from=nbcuni.com; x-originating-ip: [2605:e000:141b:121:55eb:7cb0:160e:276d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 36ce2c6d-3f37-4aef-de6b-08d87b7e46ec x-ms-traffictypediagnostic: SJ0PR14MB4394: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2CP6BYrDlVI1xjkBhMIaCrJX5rVNwFRKqtqtVamrRQRec6b46smM65lNbDoVBWQA921fF22YGsVVi8AVJrglE+aHjhsKZfbDbeN5CXmtsdfOAkLT+Lcr/Y6c1x0DpvvW/z/nz7itekhYH22aR3QogjCBvrhI83G/MVBtorbAVBMws1Y0dhgiBltjWpPjWNkI+ULDJrje6fv4MopZ4bY6iHQ858hqZKFtOXqCHfIUpseDc0DASLsDwUqkEI84BkmCSUhZXepAUI4qJQNg9v3TOuxbKbsUgG9iYBy0HnjXVz/b3SMi+wOm6FIe1Jiie+wuJi83Uv+zHxMxez5v8Gh7YmbzqIJ1k5moTX2ued3mpUk7Nrvn01/J+Nlrt/7dJILQLFnckdvOHoLonieJKzBF3Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(396003)(346002)(376002)(2616005)(2906002)(966005)(478600001)(33656002)(54906003)(8936002)(66946007)(4326008)(86362001)(316002)(66556008)(110136005)(76116006)(71200400001)(66476007)(91956017)(107886003)(66446008)(64756008)(166002)(6506007)(186003)(36756003)(53546011)(6486002)(8676002)(83380400001)(6512007)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: blL7ygnH2DKAuzKLQue3FPTqYfltOHUsTZ36pZTlyu78bLSuxrBkOpTqiMTpf2i4Ti6ivdC4TBNWicS84J/OOMsqvqZCl+l3ED5kwey8JF85yobGnMVOoKhDY+b6oFTeHh8tZqWnk/98In2kMGIl2ciEFBdP3jBsjYEDnXlNriinExdkVkutGgVO6NYO/Tzawh1epDjrJgoXpHoelwgKmWHhJRJYWireO7mx6d9Oopo5+iP5jTPQsI3ON8FxtlEs7bvtB0Kg87pdskU003tUXVgDuM/P8LgJhq0QTb1IQxDdyhUk2AkG778lIUEJ4t80mG2BaaNa6zZ73ibiJvH1Tm7BmRC8sPeb9D72zrQJkL//1O07qrMHmSpOqGphT4VVDjfm6ytFUQeaG5wUY6/BI6ky4h6gP3aOX5IJE0ClwNe/G03sjxciXB67LPluMEb8cDPGCVFWeo9M6x//wjEtKfhD0OVEmh6VGqb75cOKD6TgGF9601AkQGsdO+XJaRzLejDg/I0Tyo0gekJ4JGSUHknfHOKhfxbbPKr9D2c10jR+xPlq/k4wfXM+JQLDzYUQET/Nvs+PUqzDK+gtBVBoiErfxWZCQxBKYGPs8rM0LfOcaBp3CNhSM6LLMsBcRd267gjWfIoq77wvVcV4WSDdzcszNEMu4gTqJ27fXwdwKbDWK3fvOCQVzfrbNu2iqoTkNLOkvb0qPVYMQu5dStFdZQ== Content-Type: multipart/alternative; boundary="_000_FA05D448BC31451583F50174DBB5BEAAnbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR14MB3094.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 36ce2c6d-3f37-4aef-de6b-08d87b7e46ec X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2020 20:15:55.8089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XA5Bcw18Wy63sIP2kVulm25AKsRjlWPytQkMZiYJpo2ri5VlemYkx556QXxrj8yWJ0VH5A31binyjCK1CGsHCQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR14MB4394 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-28_09:2020-10-28, 2020-10-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1011 phishscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010280125 Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 20:16:05 -0000 --_000_FA05D448BC31451583F50174DBB5BEAAnbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgbWF5IG1ha2Ugc2Vuc2UgdG8gY3Jvc3MgcG9zdCB0aGlzIHRvIHRoZSBNT1BTIG1haWxpbmcg bGlzdC4NCg0KSeKAmWxsIHBvaW50IG91dCB0aGF0IFNSVCBhbmQgUklTVCBhcmUgdHdvIGV4YW1w bGVzIG9mIHByb3RvY29scyB1c2VkIHByb2Zlc3Npb25hbGx5IHRvIHRyYW5zcG9ydCBjb250ZW50 IGR1cmluZyBhY3F1aXNpdGlvbi4NCg0KQWxzbywgdGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lvbiBp biBNT1BTIGFib3V0IHNldHRpbmcgdXAgYSBmdXR1cmUgc2lkZS1ieS1zaWRlIHNldCBvZiB0cmFu c3BvcnQgdGVzdHMgYW5kIG1lYXN1cmVtZW50cyB0byB1bmRlcnN0YW5kIHRoZSBiZWhhdmlvcnMg b2YgdGhlIGRpZmZlcmVudCB0cmFuc3BvcnRzIOKAkyBwZXJoYXBzIGF0IGEgZnV0dXJlIElFVEYg aGFja2F0aG9uIHdoZW4gZXZlcnlvbmUgY2FuIHdvcmsgdG9nZXRoZXIgaW4gdGhlIHNhbWUgcm9v bS4NCg0KLWdsZW5uDQoNCk9uIDEwLzI4LzIwLCAxOjEwIFBNLCAiZGlzcGF0Y2ggb24gYmVoYWxm IG9mIEJlbiBDYW1wYmVsbCIgPGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBiZW5Abm9zdHJ1bS5jb208bWFpbHRv OmJlbkBub3N0cnVtLmNvbT4+IHdyb3RlOg0KDQpIaSBFdmVyeW9uZSwNCg0KRGlkIGFueW9uZSBo YXZlIGZlZWRiYWNrIG9yIG90aGVyIHRob3VnaHRzIG9uIFNlcmdpb+KAmXMgcHJvcG9zYWw/DQoN ClRoYW5rcyENCg0KQmVuLg0KDQoNCk9uIFNlcCAzMCwgMjAyMCwgYXQgNToyNCBBTSwgU2VyZ2lv IEdhcmNpYSBNdXJpbGxvIDxzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tPG1haWx0bzpz ZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIGFsbCENCg0KV2hp bGUgV2ViUlRDIGhhcyBiZWVuIHZlcnkgc3VjY2Vzc2Z1bCBpbiBhIHdpZGUgcmFuZ2Ugb2Ygc2Nl bmFyaW9zLCBpdHMgYWRhcHRpb24gaW4gdGhlIGJyb2FkY2FzdGluZy9zdHJlYW1pbmcgaW5kdXN0 cnkgaXMgbGFnZ2luZyBiZWhpbmQuIEN1cnJlbnRseSB0aGVyZSBpcyBubyBzdGFuZGFyZCBwcm90 b2NvbCAobGlrZSBTSVAgb3IgUlRTUCkgZGVzaWduZWQgZm9yIGluZ2VzdGluZyBtZWRpYSBpbiBh IHN0cmVhbWluZyBzZXJ2aWNlLCBhbmQgY29udGVudCBwcm92aWRlcnMgc3RpbGwgcmVseSBoZWF2 aWx5IG9uIHByb3RvY29scyBsaWtlIFJUTVAgZm9yIGl0Lg0KDQpUaGVzZSBwcm90b2NvbHMgYXJl IG11Y2ggb2xkZXIgdGhhbiBXZWJSVEMgYW5kIGxhY2sgYnkgZGVmYXVsdCBzb21lIGltcG9ydGFu dCBzZWN1cml0eSBhbmQgcmVzaWxpZW5jZSBmZWF0dXJlcyBwcm92aWRlZCBieSBXZWJSVEMgd2l0 aCBtaW5pbWFsIGRlbGF5Lg0KDQpUaGUgbWVkaWEgY29kZWNzIHVzZWQgaW4gb2xkZXIgcHJvdG9j b2xzIGRvIG5vdCBhbHdheXMgbWF0Y2ggdGhvc2UgYmVpbmcgdXNlZCBpbiBXZWJSVEMsIG1hbmRh dGluZyB0cmFuc2NvZGluZyBvbiB0aGUgaW5nZXN0IG5vZGUsIGludHJvZHVjaW5nIGRlbGF5IGFu ZCBkZWdyYWRpbmcgbWVkaWEgcXVhbGl0eS4gVGhpcyB0cmFuc2NvZGluZyBzdGVwIGlzIGFsd2F5 cyBwcmVzZW50IGluIHRyYWRpdGlvbmFsIHN0cmVhbWluZyB0byBzdXBwb3J0IGUuZy4gQUJSLCBh bmQgY29tZXMgYXQgbm8gY29zdC4gSG93ZXZlciB3ZWJydGMgaW1wbGVtZW50cyBjbGllbnQtc2lk ZSBBQlIsIGJ5IG1lYW5zIG9mIHNpbXVsY2FzdCBhbmQgU1ZDIGNvZGVjcywgd2hpY2ggb3RoZXJ3 aXNlIGFsbGV2aWF0ZSB0aGUgbmVlZCBmb3Igc2VydmVyLXNpZGUgdHJhbnNjb2RpbmcuIENvbnRl bnQgcHJvdGVjdGlvbiBhbmQgUHJpdmFjeSBFbmhhbmNlbWVudCBjYW4gYmUgYWNoaWV2ZSB3aXRo IEVuZC10by1FbmQgRW5jcnlwdGlvbiwgd2hpY2ggcHJlY2x1ZGUgYW55IHNlcnZlci1zaWRlIG1l ZGlhIHByb2Nlc3NpbmcuDQoNCldlIGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgcHJvcG9zYWwgZm9y IGEgc2ltcGxlIEhUVFAgYmFzZWQgcHJvdG9jb2wgdGhhdCB3aWxsIGFsbG93IFdlYlJUQyBlbmRw b2ludHMgdG8gaW5nZXN0IGNvbnRlbnQgaW50byBzdHJlYW1pbmcgc2VydmljZXMgYW5kL29yIENE TnMgdG8gZmlsbCB0aGlzIGdhcCBhbmQgZmFjaWxpdGF0ZSBkZXBsb3ltZW50Og0KwrcgICAgICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbXVyaWxsby13aGlwLTAwPGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t dXJpbGxvLXdoaXAtMDBfXzshIVBJWmVlVzV3c2N5blJRITlMX0ROU2RQZWVvWExnVVdQSHhsdFcw cFpPRGhHdHk2aUVfMzJ3UGprbV8zNXQ3ZWZxUmE4TGd2VVZMSnE0SzYkPg0KwrcgICAgICAgICBo dHRwczovL2dpdGh1Yi5jb20vbXVyaWxsbzEyOC93ZWJydGMtaHR0cC1pbmdlc3QtcHJvdG9jb2wv PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovZ2l0aHViLmNvbS9tdXJpbGxvMTI4 L3dlYnJ0Yy1odHRwLWluZ2VzdC1wcm90b2NvbC9fXzshIVBJWmVlVzV3c2N5blJRITlMX0ROU2RQ ZWVvWExnVVdQSHhsdFcwcFpPRGhHdHk2aUVfMzJ3UGprbV8zNXQ3ZWZxUmE4TGd2VVY3Qlp4WU8k Pg0KDQpXZSBoYXZlIGFscmVhZHkgaW1wbGVtZW50ZWQgaXQgb24gSmFudXMgYW5kIE1lZG9vemUg bWVkaWEgc2VydmVyczoNCsK3ICAgICAgICAgaHR0cHM6Ly93d3cubWVldGVjaG8uY29tL2Jsb2cv d2hpcC1qYW51cy88aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cubWVldGVj aG8uY29tL2Jsb2cvd2hpcC1qYW51cy9fXzshIVBJWmVlVzV3c2N5blJRITlMX0ROU2RQZWVvWExn VVdQSHhsdFcwcFpPRGhHdHk2aUVfMzJ3UGprbV8zNXQ3ZWZxUmE4TGd2VWU3Yl9BV3gkPg0Kwrcg ICAgICAgICBodHRwczovL21lZGl1bS5jb20vQG1lZG9vemUvd2hpcC13ZWJydGMtbWVldHMtdGhl LWJyb2FkY2FzdGluZy13b3JsZC04Njc3MmViYThhZTc8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi9tZWRpdW0uY29tL0BtZWRvb3plL3doaXAtd2VicnRjLW1lZXRzLXRoZS1icm9h ZGNhc3Rpbmctd29ybGQtODY3NzJlYmE4YWU3X187ISFQSVplZVc1d3NjeW5SUSE5TF9ETlNkUGVl b1hMZ1VXUEh4bHRXMHBaT0RoR3R5NmlFXzMyd1Bqa21fMzV0N2VmcVJhOExndlVjWUltMmhMJD4N Cg0KQW5kIGFkZGVkIHN1cHBvcnQgaW50byBhIFdlYlJUQyB2ZXJzaW9uIG9mIE9CUyBzdHVkaW86 DQrCtyAgICAgICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9Db1NNb1NvZnR3YXJlL09CUy1zdHVkaW8t d2VicnRjL3JlbGVhc2VzL3RhZy9tODR2MjMuMi1SQzI8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi9naXRodWIuY29tL0NvU01vU29mdHdhcmUvT0JTLXN0dWRpby13ZWJydGMvcmVs ZWFzZXMvdGFnL204NHYyMy4yLVJDMl9fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdV V1BIeGx0VzBwWk9EaEd0eTZpRV8zMndQamttXzM1dDdlZnFSYThMZ3ZVYkJ5dWZFdCQ+DQoNCldl IGFsc28gcGxhbiB0byBoYXZlIGFuIGludGVyb3Agc2Vzc2lvbiBvbiB0aGUgbmV4dCBJRVRGIGhh Y2toYXRvbiwgdGhhdCB3aWxsIGFsbG93IHRvIGNoZWNrIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGJl dHdlZW4gZGlmZmVyZW50IFdlYlJUQyBpbXBsZW1lbnRhdGlvbnMuDQoNCldoYXQgd291bGQgYmUg dGhlIGJlc3Qgd2F5IG9mIG1vdmluZyB0aGlzIGZvcndhcmQ/IE9idmlvdXNseSwgYW55IGZlZWRi YWNrIHdpbGwgYmUgdmVyeSB3ZWxjb21lLg0KDQpCZXN0IHJlZ2FyZHMNClNlcmdpbw0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBt YWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3JnPG1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2g8aHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aXNwYXRjaF9fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0VzBwWk9EaEd0 eTZpRV8zMndQamttXzM1dDdlZnFSYThMZ3ZVU2ZMeFU0WCQ+DQoNCg== --_000_FA05D448BC31451583F50174DBB5BEAAnbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3E2028C5C6E80248B567A23A0A33E184@namprd14.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBDU1wpIjsNCglwYW5v c2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6SGVsdmV0aWNhOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEzMDYzNDUwMjsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTc1NDE2ODg3MDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6MTUwOTUxNzQ1NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjU4NjUwMzQ4O30NCkBs aXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyMDg4OTEzMzUzOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotNzQxOTk3NzE2O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZl dGljYSI+SXQgbWF5IG1ha2Ugc2Vuc2UgdG8gY3Jvc3MgcG9zdCB0aGlzIHRvIHRoZSBNT1BTIG1h aWxpbmcgbGlzdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpI ZWx2ZXRpY2EiPknigJlsbCBwb2ludCBvdXQgdGhhdCBTUlQgYW5kIFJJU1QgYXJlIHR3byBleGFt cGxlcyBvZiBwcm90b2NvbHMgdXNlZCBwcm9mZXNzaW9uYWxseSB0byB0cmFuc3BvcnQgY29udGVu dCBkdXJpbmcgYWNxdWlzaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkhlbHZldGljYSI+QWxzbywgdGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lvbiBpbiBNT1BT IGFib3V0IHNldHRpbmcgdXAgYSBmdXR1cmUgc2lkZS1ieS1zaWRlIHNldCBvZiB0cmFuc3BvcnQg dGVzdHMgYW5kIG1lYXN1cmVtZW50cyB0byB1bmRlcnN0YW5kIHRoZSBiZWhhdmlvcnMgb2YgdGhl IGRpZmZlcmVudCB0cmFuc3BvcnRzIOKAkyBwZXJoYXBzIGF0IGEgZnV0dXJlIElFVEYNCiBoYWNr YXRob24gd2hlbiBldmVyeW9uZSBjYW4gd29yayB0b2dldGhlciBpbiB0aGUgc2FtZSByb29tLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPi1nbGVu bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pk9uIDEwLzI4LzIwLCAxOjEwIFBNLCAmcXVvdDtkaXNwYXRjaCBvbiBiZWhhbGYgb2YgQmVuIENh bXBiZWxsJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y ZyI+ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJt YWlsdG86YmVuQG5vc3RydW0uY29tIj5iZW5Abm9zdHJ1bS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGkgRXZlcnlvbmUs PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRpZCBhbnlvbmUgaGF2ZSBm ZWVkYmFjayBvciBvdGhlciB0aG91Z2h0cyBvbiBTZXJnaW/igJlzIHByb3Bvc2FsPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoYW5rcyE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5CZW4uPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIFNlcCAzMCwgMjAyMCwgYXQgNToyNCBBTSwgU2Vy Z2lvIEdhcmNpYSBNdXJpbGxvICZsdDs8YSBocmVmPSJtYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJp bGxvQGdtYWlsLmNvbSI+c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkhpIGFsbCE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0K V2hpbGUgV2ViUlRDIGhhcyBiZWVuIHZlcnkgc3VjY2Vzc2Z1bCBpbiBhIHdpZGUgcmFuZ2Ugb2Yg c2NlbmFyaW9zLCBpdHMgYWRhcHRpb24gaW4gdGhlIGJyb2FkY2FzdGluZy9zdHJlYW1pbmcgaW5k dXN0cnkgaXMgbGFnZ2luZyBiZWhpbmQuIEN1cnJlbnRseSB0aGVyZSBpcyBubyBzdGFuZGFyZCBw cm90b2NvbCAobGlrZSBTSVAgb3IgUlRTUCkgZGVzaWduZWQgZm9yIGluZ2VzdGluZyBtZWRpYSBp biBhIHN0cmVhbWluZyBzZXJ2aWNlLCBhbmQgY29udGVudA0KIHByb3ZpZGVycyBzdGlsbCByZWx5 IGhlYXZpbHkgb24gcHJvdG9jb2xzIGxpa2UgUlRNUCBmb3IgaXQuPGJyPg0KPGJyPg0KVGhlc2Ug cHJvdG9jb2xzIGFyZSBtdWNoIG9sZGVyIHRoYW4gV2ViUlRDIGFuZCBsYWNrIGJ5IGRlZmF1bHQg c29tZSBpbXBvcnRhbnQgc2VjdXJpdHkgYW5kIHJlc2lsaWVuY2UgZmVhdHVyZXMgcHJvdmlkZWQg YnkgV2ViUlRDIHdpdGggbWluaW1hbCBkZWxheS48YnI+DQo8YnI+DQpUaGUgbWVkaWEgY29kZWNz IHVzZWQgaW4gb2xkZXIgcHJvdG9jb2xzIGRvIG5vdCBhbHdheXMgbWF0Y2ggdGhvc2UgYmVpbmcg dXNlZCBpbiBXZWJSVEMsIG1hbmRhdGluZyB0cmFuc2NvZGluZyBvbiB0aGUgaW5nZXN0IG5vZGUs IGludHJvZHVjaW5nIGRlbGF5IGFuZCBkZWdyYWRpbmcgbWVkaWEgcXVhbGl0eS4gVGhpcyB0cmFu c2NvZGluZyBzdGVwIGlzIGFsd2F5cyBwcmVzZW50IGluIHRyYWRpdGlvbmFsIHN0cmVhbWluZyB0 byBzdXBwb3J0IGUuZy4NCiBBQlIsIGFuZCBjb21lcyBhdCBubyBjb3N0LiBIb3dldmVyIHdlYnJ0 YyBpbXBsZW1lbnRzIGNsaWVudC1zaWRlIEFCUiwgYnkgbWVhbnMgb2Ygc2ltdWxjYXN0IGFuZCBT VkMgY29kZWNzLCB3aGljaCBvdGhlcndpc2UgYWxsZXZpYXRlIHRoZSBuZWVkIGZvciBzZXJ2ZXIt c2lkZSB0cmFuc2NvZGluZy4gQ29udGVudCBwcm90ZWN0aW9uIGFuZCBQcml2YWN5IEVuaGFuY2Vt ZW50IGNhbiBiZSBhY2hpZXZlIHdpdGggRW5kLXRvLUVuZCBFbmNyeXB0aW9uLA0KIHdoaWNoIHBy ZWNsdWRlIGFueSBzZXJ2ZXItc2lkZSBtZWRpYSBwcm9jZXNzaW5nLjxicj4NCjxicj4NCldlIGhh dmUgYmVlbiB3b3JraW5nIG9uIGEgcHJvcG9zYWwgZm9yIGEgc2ltcGxlIEhUVFAgYmFzZWQgcHJv dG9jb2wgdGhhdCB3aWxsIGFsbG93IFdlYlJUQyBlbmRwb2ludHMgdG8gaW5nZXN0IGNvbnRlbnQg aW50byBzdHJlYW1pbmcgc2VydmljZXMgYW5kL29yIENETnMgdG8gZmlsbCB0aGlzIGdhcCBhbmQg ZmFjaWxpdGF0ZSBkZXBsb3ltZW50OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3 PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbXVyaWxsby13aGlwLTAwX187ISFQSVpl ZVc1d3NjeW5SUSE5TF9ETlNkUGVlb1hMZ1VXUEh4bHRXMHBaT0RoR3R5NmlFXzMyd1Bqa21fMzV0 N2VmcVJhOExndlVWTEpxNEs2JCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW11 cmlsbG8td2hpcC0wMDwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi9naXRodWIuY29tL211cmlsbG8xMjgvd2VicnRjLWh0dHAtaW5nZXN0LXByb3RvY29sL19fOyEh UElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0VzBwWk9EaEd0eTZpRV8zMndQamtt XzM1dDdlZnFSYThMZ3ZVVjdCWnhZTyQiPmh0dHBzOi8vZ2l0aHViLmNvbS9tdXJpbGxvMTI4L3dl YnJ0Yy1odHRwLWluZ2VzdC1wcm90b2NvbC88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCldlIGhhdmUgYWxyZWFkeSBp bXBsZW1lbnRlZCBpdCBvbiBKYW51cyBhbmQgTWVkb296ZSBtZWRpYSBzZXJ2ZXJzOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5tZWV0ZWNoby5jb20vYmxvZy93 aGlwLWphbnVzL19fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0VzBwWk9E aEd0eTZpRV8zMndQamttXzM1dDdlZnFSYThMZ3ZVZTdiX0FXeCQiPmh0dHBzOi8vd3d3Lm1lZXRl Y2hvLmNvbS9ibG9nL3doaXAtamFudXMvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MiBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L21lZGl1bS5jb20vQG1lZG9vemUvd2hpcC13ZWJydGMtbWVldHMtdGhlLWJy b2FkY2FzdGluZy13b3JsZC04Njc3MmViYThhZTdfXzshIVBJWmVlVzV3c2N5blJRITlMX0ROU2RQ ZWVvWExnVVdQSHhsdFcwcFpPRGhHdHk2aUVfMzJ3UGprbV8zNXQ3ZWZxUmE4TGd2VWNZSW0yaEwk Ij5odHRwczovL21lZGl1bS5jb20vQG1lZG9vemUvd2hpcC13ZWJydGMtbWVldHMtdGhlLWJyb2Fk Y2FzdGluZy13b3JsZC04Njc3MmViYThhZTc8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkFuZCBhZGRlZCBzdXBwb3J0 IGludG8gYSBXZWJSVEMgdmVyc2lvbiBvZiBPQlMgc3R1ZGlvOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6L2dpdGh1Yi5jb20vQ29TTW9Tb2Z0d2FyZS9PQlMtc3R1ZGlv LXdlYnJ0Yy9yZWxlYXNlcy90YWcvbTg0djIzLjItUkMyX187ISFQSVplZVc1d3NjeW5SUSE5TF9E TlNkUGVlb1hMZ1VXUEh4bHRXMHBaT0RoR3R5NmlFXzMyd1Bqa21fMzV0N2VmcVJhOExndlViQnl1 ZkV0JCI+aHR0cHM6Ly9naXRodWIuY29tL0NvU01vU29mdHdhcmUvT0JTLXN0dWRpby13ZWJydGMv cmVsZWFzZXMvdGFnL204NHYyMy4yLVJDMjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KV2UgYWxzbyBwbGFuIHRvIGhh dmUgYW4gaW50ZXJvcCBzZXNzaW9uIG9uIHRoZSBuZXh0IElFVEYgaGFja2hhdG9uLCB0aGF0IHdp bGwgYWxsb3cgdG8gY2hlY2sgdGhlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBkaWZmZXJlbnQg V2ViUlRDIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KV2hhdCB3b3VsZCBiZSB0aGUgYmVzdCB3 YXkgb2YgbW92aW5nIHRoaXMgZm9yd2FyZD8gT2J2aW91c2x5LCBhbnkgZmVlZGJhY2sgd2lsbCBi ZSB2ZXJ5IHdlbGNvbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6LjVpbiI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCkJlc3QgcmVnYXJkczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KU2VyZ2lvPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 ZGlzcGF0Y2hAaWV0Zi5vcmciPmRpc3BhdGNoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGlzcGF0Y2hfXzshIVBJWmVlVzV3c2N5blJRITlMX0ROU2RQZWVvWExnVVdQSHhsdFcw cFpPRGhHdHk2aUVfMzJ3UGprbV8zNXQ3ZWZxUmE4TGd2VVNmTHhVNFgkIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_FA05D448BC31451583F50174DBB5BEAAnbcunicom_-- From nobody Wed Oct 28 14:09:28 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914163A0AD8 for ; Wed, 28 Oct 2020 14:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 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, HTTPS_HTTP_MISMATCH=0.1, NICE_REPLY_A=-0.247, 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 VImhlp4xl5sN for ; Wed, 28 Oct 2020 14:09:23 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 1BEB73A0AD4 for ; Wed, 28 Oct 2020 14:09:23 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id n15so584004wrq.2 for ; Wed, 28 Oct 2020 14:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=keBGA3Screnp2xDIZGNbfq51UyNwvJ0SwN9SW1/e7KY=; b=kGq8eUTnpAbzCtC9l8gPKvR2sIlE4/6v+QL2wHDz2leHO9zu3JWq6aYcM+Ej5WrqmI uq7g4u1iTKA2CUPQakubm5Qz9HCRepSHWgjzgsgJ7V7uog1AtZoU1grias8m5U8FKucF tbssHGVEgbelAtyBWgsa/Dq/QJlFbJIdZKaKxU+H/dV4fd3nhkxnupl3yJYzolJtL2Wo 7ElmWaiIqdSlpV87ja8a12G8P4tfV2qbP31c6hhCA7e2O8WTyhek+kwulOBl4muLkc2N 6BJKh/gIq6iXQzACYREc4lCtlibvCoeRFEV7vAWSMBWmHyTmI3rw7tsIwqo1B+59Vmg2 IUTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=keBGA3Screnp2xDIZGNbfq51UyNwvJ0SwN9SW1/e7KY=; b=i6290qYam6THJK+MKUG1I9UTdWTSo2yDNisINgoeW/JuUzbXmns/8YJVOoRT8fKaEO bUbexK8OgNZ0ps1LCxEKNQcmqOVFG/jpPtytngGzUhPZXVmdV2ufjvf9YGd2dRziygo1 dbAM/j9qvaVY+XPyT5BDR1cIRSNJyIULF6bIhqTSCYUid7yBQkXW1dlXJx/vODIHSvZT RcXWYqxXzUZ04Lrsk1uNTDRv0zytpsmJuk0fjOGYLwgjV4qCykJE/sXqfPq2LX50QXhc /8KTIs1jWpdW14KfGntO+KFwuYW9KhK7kIuy7oQIpwW7t8iapGgXexhaOdP1yoqTlCIJ f+dg== X-Gm-Message-State: AOAM533qiZE1quTwhC7mpDF9Q8y4e1mbiduZ/I+9ZFGfU5zIQu85MhhZ I3cx8ksAyU5tGIxoK/vQciWhlSxmXY8AXg== X-Google-Smtp-Source: ABdhPJz79D63Rst93yaP2YhAapniO/nssASNXjY71xP8y4tjc010uPVB2F2mbcIqvOl027ld0LJYiw== X-Received: by 2002:a5d:43c6:: with SMTP id v6mr1471104wrr.20.1603919361215; Wed, 28 Oct 2020 14:09:21 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id p9sm821673wma.12.2020.10.28.14.09.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Oct 2020 14:09:20 -0700 (PDT) To: dispatch@ietf.org References: From: Sergio Garcia Murillo Message-ID: <40d984ce-2af4-0b9d-f3cc-ac561a0e769a@gmail.com> Date: Wed, 28 Oct 2020 22:09:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------55CBEF048ECE9C18DFE47954" Content-Language: en-US Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 21:09:27 -0000 This is a multi-part message in MIME format. --------------55CBEF048ECE9C18DFE47954 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Glen, We are already participating in the MOPS, but I don't think it is the best place to progress the proposal, from the MOPS charter: "The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats." However, we were thinking in using it in the future hackathon for testing webrtc as currently there is no other easy way to test webrtc across a different set of implementations without ad-hoc integrations. Regarding SRT and RIST, none of them work on a web browser as an ingest point nor they allow easily to be translated to webrtc to enable lowest delay on distribution via webrtc. Best regards Sergio On 28/10/2020 21:15, Deen, Glenn (NBCUniversal) wrote: > > It may make sense to cross post this to the MOPS mailing list. > > I’ll point out that SRT and RIST are two examples of protocols used > professionally to transport content during acquisition. > > Also, there has been discussion in MOPS about setting up a future > side-by-side set of transport tests and measurements to understand the > behaviors of the different transports – perhaps at a future IETF > hackathon when everyone can work together in the same room. > > -glenn > > On 10/28/20, 1:10 PM, "dispatch on behalf of Ben Campbell" > on > behalf of ben@nostrum.com > wrote: > > Hi Everyone, > > Did anyone have feedback or other thoughts on Sergio’s proposal? > > Thanks! > > Ben. > > > > On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo > > wrote: > > Hi all! > > While WebRTC has been very successful in a wide range of > scenarios, its adaption in the broadcasting/streaming industry is > lagging behind. Currently there is no standard protocol (like SIP > or RTSP) designed for ingesting media in a streaming service, and > content providers still rely heavily on protocols like RTMP for it. > > These protocols are much older than WebRTC and lack by default > some important security and resilience features provided by WebRTC > with minimal delay. > > The media codecs used in older protocols do not always match those > being used in WebRTC, mandating transcoding on the ingest node, > introducing delay and degrading media quality. This transcoding > step is always present in traditional streaming to support e.g. > ABR, and comes at no cost. However webrtc implements client-side > ABR, by means of simulcast and SVC codecs, which otherwise > alleviate the need for server-side transcoding. Content protection > and Privacy Enhancement can be achieve with End-to-End Encryption, > which preclude any server-side media processing. > > We have been working on a proposal for a simple HTTP based > protocol that will allow WebRTC endpoints to ingest content into > streaming services and/or CDNs to fill this gap and facilitate > deployment: > > ·https://tools.ietf.org/html/draft-murillo-whip-00 > > > ·https://github.com/murillo128/webrtc-http-ingest-protocol/ > > > We have already implemented it on Janus and Medooze media servers: > > ·https://www.meetecho.com/blog/whip-janus/ > > > ·https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 > > > And added support into a WebRTC version of OBS studio: > > ·https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2 > > > We also plan to have an interop session on the next IETF > hackhaton, that will allow to check the interoperability between > different WebRTC implementations. > > What would be the best way of moving this forward? Obviously, any > feedback will be very welcome. > > Best regards > > Sergio > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------55CBEF048ECE9C18DFE47954 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Glen,

We are already participating in the MOPS, but I don't think it is the best place to progress the proposal, from the MOPS charter:

"The scope is media and media protocols’ interactions with the network, but not the technologies of control protocols or media formats."

However, we were thinking in using it in the future hackathon for testing webrtc as currently there is no other easy way to test webrtc across a different set of implementations without ad-hoc integrations.

Regarding SRT and RIST, none of them work on a web browser as an ingest point nor they allow easily to be translated to webrtc to enable lowest delay on distribution via webrtc.

Best regards
Sergio


On 28/10/2020 21:15, Deen, Glenn (NBCUniversal) wrote:

It may make sense to cross post this to the MOPS mailing list.

 

I’ll point out that SRT and RIST are two examples of protocols used professionally to transport content during acquisition.

 

Also, there has been discussion in MOPS about setting up a future side-by-side set of transport tests and measurements to understand the behaviors of the different transports – perhaps at a future IETF hackathon when everyone can work together in the same room.

 

-glenn

 

On 10/28/20, 1:10 PM, "dispatch on behalf of Ben Campbell" <dispatch-bounces@ietf.org on behalf of ben@nostrum.com> wrote:

 

Hi Everyone,

 

Did anyone have feedback or other thoughts on Sergio’s proposal?

 

Thanks!

 

Ben.



On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

 

Hi all!

 

While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:

·         https://tools.ietf.org/html/draft-murillo-whip-00

·         https://github.com/murillo128/webrtc-http-ingest-protocol/

 

We have already implemented it on Janus and Medooze media servers:

·         https://www.meetecho.com/blog/whip-janus/

·         https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7

 

And added support into a WebRTC version of OBS studio:

·         https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2

 

We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.

 

What would be the best way of moving this forward? Obviously, any feedback will be very welcome.

 

Best regards

Sergio

 

 

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

 


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


--------------55CBEF048ECE9C18DFE47954-- From nobody Wed Oct 28 14:55:44 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DDE3A03F4 for ; Wed, 28 Oct 2020 14:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nbcuni.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_paJS2zq585 for ; Wed, 28 Oct 2020 14:55:41 -0700 (PDT) Received: from mx0a-00176a04.pphosted.com (mx0a-00176a04.pphosted.com [67.231.149.53]) (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 F01213A02BD for ; Wed, 28 Oct 2020 14:55:40 -0700 (PDT) Received: from pps.filterd (m0193507.ppops.net [127.0.0.1]) by m0193507.ppops.net-00176a04. (8.16.0.42/8.16.0.42) with SMTP id 09SLb4AB019528 for ; Wed, 28 Oct 2020 17:55:39 -0400 Received: from usushmgip004.mail.tfayd.com ([216.178.109.223]) by m0193507.ppops.net-00176a04. with ESMTP id 34cgpcm2k4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 28 Oct 2020 17:55:39 -0400 IronPort-SDR: 2Wm2XXUMM62hST6dRspLE5yapQ6UM+kR6zkThDhJmicAwj9mMbPpt2nBEKkkYskC5mhcrnE58x nd9pIAqGZ7qg== Received: from unknown (HELO potemwp00005.mail.tfayd.com) ([100.124.56.29]) by USUSHMGIP004.mail.tfayd.com with ESMTP/TLS/ECDHE-RSA-AES128-SHA256; 28 Oct 2020 17:55:38 -0400 Received: from potemwp00001.mail.tfayd.com (100.124.56.25) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5; Wed, 28 Oct 2020 15:55:37 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (10.40.33.204) by potemwp00001.mail.tfayd.com (100.124.56.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1913.5 via Frontend Transport; Wed, 28 Oct 2020 15:55:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Vo4QcOag4x3PbaIE589zQ64ugCjCnWjJrlL+67zib/Z/EBPD1/PvxCM8PyVlMorwcJX+M/7JSLJjG/WfubhaZmbKpVKMwG0lMHG/LV3p9pmZ622RSQbTo5VYKyE3HSNZzHVCHXfDPq+6eL5u+jR1F1UifbR0Ueyh6a6fXP85Mx8gE7QZkSEZfMiXwskXvrnNPsPCP3VmjoNlWEgWKlWwK6lj+1wUlAYfgRzyEcKIEs0x0UqUaba/tVId1KEPtVqE5O1bxMDBk52JFU9wQ8RNM6f0qrXiFI3wJdVNraKLJA/n9CwC+1bjKrYKOHwGE+wPZDnaklu0cKC4ZFRzAhU1Fw== 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-SenderADCheck; bh=a2zm2zeDppQKH1QbFhw41is3/PLfS9ewagRd3lRp+k4=; b=XfGu17AQzTXqMsVSuTpJK6IcGIVeNi07F0z4Hp7oixaa9RBDEyr6BR5blP/TjqEi4IV43/rHp0vv3B3654fXq1hE74/VhqtF6NpB+nnegPauKh0O5NEcstx9+LlMnfnjm2DP7CizC6l3FV7LCVQMHdrWqE47xBHepLkiiFtDB60BaU2GSjW6Oy6GuG8j/9CInjHyrTC0hQOdoK90pAyqtBrHfLs0FMgLKcRJUfgHM/tWe7n2cVrfU5o2efVYsm7GTO6Jov+jNl9cr7dEumtiyn9tUzgn17lghkNhNBgtrUZSqvx0VJDBKYmeTKwhcCemswh9Fj2PzrAnE6GWBB50Uw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nbcuni.com; dmarc=pass action=none header.from=nbcuni.com; dkim=pass header.d=nbcuni.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NBCUNI.onmicrosoft.com; s=selector1-NBCUNI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a2zm2zeDppQKH1QbFhw41is3/PLfS9ewagRd3lRp+k4=; b=uzX6bKO7IL1UeSeKsQ56wpR7VmvyBFqTvrM3gyAY+CI6MQx871/el1Ks2pLQvchUgqMcDSZq+otkruKf/BRVVj7VZxAFrXWrUGiP3KJZ9hnwsFOUEHT8et6renRRpJbS9jCxB3J/vOWfymdVnZ/wgFZlbfU7hTDsYALZypbO3F8= Received: from BYAPR14MB3094.namprd14.prod.outlook.com (20.179.154.222) by SJ0PR14MB4507.namprd14.prod.outlook.com (20.182.132.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Wed, 28 Oct 2020 21:55:34 +0000 Received: from BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::589e:ab56:3d14:22db]) by BYAPR14MB3094.namprd14.prod.outlook.com ([fe80::589e:ab56:3d14:22db%6]) with mapi id 15.20.3477.029; Wed, 28 Oct 2020 21:55:34 +0000 From: "Deen, Glenn (NBCUniversal)" To: Sergio Garcia Murillo , "dispatch@ietf.org" Thread-Topic: [dispatch] WHIP - WebRTC HTTP ingestion protocol Thread-Index: AQHWrXUPZZmkn7E4TkWmKsDqoZoD6w== Date: Wed, 28 Oct 2020 21:55:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nbcuni.com; x-originating-ip: [2605:e000:141b:121:84f3:e3b2:fd5c:8476] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4469f371-2637-4d29-d701-08d87b8c3257 x-ms-traffictypediagnostic: SJ0PR14MB4507: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bNXE5u0phbsDyK3k/q8aCFv3eSzy+FAhxPQsbxSg+oI3+3EtwYAc93BgtAjdqb/f6S+wB/lNiyOUNvQDwM+eUqVutYUDt2cSXb+FHxilbCL5sB9pU2HnBzy/JCIc233+OCbAnsYLSYAvz0lqha1UTb4biefXGeotylpRgmqidwfF4//3doNoMwmw8TR4WLvMpUUpQjd7IENIQY5ceLIm3s/1Lw5Ye3IjjhzLpwH4zAOOn5NHUiFZY8MjdN5oHKQ77JSBQOhMGwkoeX5frwIDv0TpcdZ/585+k46cb7BshGGMQsIizMIE5RsLRbeiTNITEiaAhz0KKHN7n5JMtGaJmkgxFfQ6G62llUVLv3vcL9+OrUE7alw75Vubuh9mNjxkhZGi/9yXfbydUUR/eG2TUQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR14MB3094.namprd14.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(396003)(39860400002)(136003)(53546011)(186003)(66574015)(66556008)(6512007)(166002)(8936002)(6486002)(5660300002)(64756008)(66446008)(66476007)(110136005)(66946007)(71200400001)(316002)(966005)(6506007)(76116006)(36756003)(2906002)(33656002)(9326002)(2616005)(478600001)(86362001)(4326008)(8676002)(83380400001)(107886003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: cQVAI/4mV39WA6pX3EbFKEY3v3HZOHD957UMAFgb2kZbxxNtbcEqz9q15yS8QJMeBuCH0oRgGwEW06d0SuJBg7nfi8iQ74v6JhLMeAu37kic16YWsBuqL43gmRqx9WKadLAZBL4TWnpvv/osRxrLbvLiPjM5T9RU7lpuiDQ1c9wZ7mqbNyazL9pte5ZzW5ep2/p/9pIhfvrQN8XxSIFIkJ8q17TmnSYsi7YUDn3eqYQoR2Bqn8a8Mtnt1v29GVkOk/PupsUK8DOHAO++TZue/BplJpPJDDYoxIf3LY5/inEsghm4zpESuOd/9+jNr/djgydJFTfeEw2YrVMBlhGlgY30Hh8u/ohCfWqCoWBvA+ZJId4/SLy0WX0g4tolx2Rq7uVNssM3Z/lHHOYQAu/5U6R8wAwZzz8P19wVyY581rBUxRnjv4fyKbBLMujRDhDMUd8K9jt8s4+BZ5ljbjc0rkItSV3hyzO++dRCncKsx5i0HX8+0l+6SOI6uKJjbBjp8QD/0FlZUe/y/jQlgGvnFB8WUwpnqgqKPNe5Y3SVRCff28yyK4ZOidJscDrdAhGWD6cfxcPM8R46eo55TZXLvqCPONJ/M++bexbuPo1lRzhe5gzQIHUmPKFPuyiCNF433axoocuv60YSy9AFFF+DsZEDQlQqDIMf/0ptD+4g2mMOF4Pd1xGgBKogHg6yCSbWv6wg/PN3gufLg4Bfor64pg== Content-Type: multipart/alternative; boundary="_000_FA2E55FFD39C4C46B6AF8C02E1029968nbcunicom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR14MB3094.namprd14.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4469f371-2637-4d29-d701-08d87b8c3257 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2020 21:55:34.1741 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4f3526f9-97d6-412d-933a-4e30a73110f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: MABAxw0ylXod5GEomWaHBzV2eTnIAY8+CGdEIX5nMhELYc0DJgjUGqIBGVIK3+b/0n3k8wihHqsPfDc3sRkoag== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR14MB4507 X-OriginatorOrg: nbcuni.com X-EXCLAIMER-MD-CONFIG: 47edc00f-f2d6-45ef-be83-8a353bd47e45 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-10-28_09:2020-10-28, 2020-10-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1015 phishscore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010280132 Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 21:55:43 -0000 --_000_FA2E55FFD39C4C46B6AF8C02E1029968nbcunicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2VyZ2lvLA0KDQpHcmVhdC4gIFRoYW5rcyBmb3IgY2xvc2luZyB0aGF0IGxvb3Agd2l0aCBN T1BTLg0KDQpSZWdhcmRzDQpHbGVubg0KDQpPbiAxMC8yOC8yMCwgMjoxMCBQTSwgImRpc3BhdGNo IG9uIGJlaGFsZiBvZiBTZXJnaW8gR2FyY2lhIE11cmlsbG8iIDxkaXNwYXRjaC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Ygc2Vy Z2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbTxtYWlsdG86c2VyZ2lvLmdhcmNpYS5tdXJpbGxv QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBHbGVuLA0KDQpXZSBhcmUgYWxyZWFkeSBwYXJ0aWNp cGF0aW5nIGluIHRoZSBNT1BTLCBidXQgSSBkb24ndCB0aGluayBpdCBpcyB0aGUgYmVzdCBwbGFj ZSB0byBwcm9ncmVzcyB0aGUgcHJvcG9zYWwsIGZyb20gdGhlIE1PUFMgY2hhcnRlcjoNCg0KIlRo ZSBzY29wZSBpcyBtZWRpYSBhbmQgbWVkaWEgcHJvdG9jb2xz4oCZIGludGVyYWN0aW9ucyB3aXRo IHRoZSBuZXR3b3JrLCBidXQgbm90IHRoZSB0ZWNobm9sb2dpZXMgb2YgY29udHJvbCBwcm90b2Nv bHMgb3IgbWVkaWEgZm9ybWF0cy4iDQoNCkhvd2V2ZXIsIHdlIHdlcmUgdGhpbmtpbmcgaW4gdXNp bmcgaXQgaW4gdGhlIGZ1dHVyZSBoYWNrYXRob24gZm9yIHRlc3Rpbmcgd2VicnRjIGFzIGN1cnJl bnRseSB0aGVyZSBpcyBubyBvdGhlciBlYXN5IHdheSB0byB0ZXN0IHdlYnJ0YyBhY3Jvc3MgYSBk aWZmZXJlbnQgc2V0IG9mIGltcGxlbWVudGF0aW9ucyB3aXRob3V0IGFkLWhvYyBpbnRlZ3JhdGlv bnMuDQoNClJlZ2FyZGluZyBTUlQgYW5kIFJJU1QsIG5vbmUgb2YgdGhlbSB3b3JrIG9uIGEgd2Vi IGJyb3dzZXIgYXMgYW4gaW5nZXN0IHBvaW50IG5vciB0aGV5IGFsbG93IGVhc2lseSB0byBiZSB0 cmFuc2xhdGVkIHRvIHdlYnJ0YyB0byBlbmFibGUgbG93ZXN0IGRlbGF5IG9uIGRpc3RyaWJ1dGlv biB2aWEgd2VicnRjLg0KDQpCZXN0IHJlZ2FyZHMNClNlcmdpbw0KDQoNCg0KT24gMjgvMTAvMjAy MCAyMToxNSwgRGVlbiwgR2xlbm4gKE5CQ1VuaXZlcnNhbCkgd3JvdGU6DQpJdCBtYXkgbWFrZSBz ZW5zZSB0byBjcm9zcyBwb3N0IHRoaXMgdG8gdGhlIE1PUFMgbWFpbGluZyBsaXN0Lg0KDQpJ4oCZ bGwgcG9pbnQgb3V0IHRoYXQgU1JUIGFuZCBSSVNUIGFyZSB0d28gZXhhbXBsZXMgb2YgcHJvdG9j b2xzIHVzZWQgcHJvZmVzc2lvbmFsbHkgdG8gdHJhbnNwb3J0IGNvbnRlbnQgZHVyaW5nIGFjcXVp c2l0aW9uLg0KDQpBbHNvLCB0aGVyZSBoYXMgYmVlbiBkaXNjdXNzaW9uIGluIE1PUFMgYWJvdXQg c2V0dGluZyB1cCBhIGZ1dHVyZSBzaWRlLWJ5LXNpZGUgc2V0IG9mIHRyYW5zcG9ydCB0ZXN0cyBh bmQgbWVhc3VyZW1lbnRzIHRvIHVuZGVyc3RhbmQgdGhlIGJlaGF2aW9ycyBvZiB0aGUgZGlmZmVy ZW50IHRyYW5zcG9ydHMg4oCTIHBlcmhhcHMgYXQgYSBmdXR1cmUgSUVURiBoYWNrYXRob24gd2hl biBldmVyeW9uZSBjYW4gd29yayB0b2dldGhlciBpbiB0aGUgc2FtZSByb29tLg0KDQotZ2xlbm4N Cg0KT24gMTAvMjgvMjAsIDE6MTAgUE0sICJkaXNwYXRjaCBvbiBiZWhhbGYgb2YgQmVuIENhbXBi ZWxsIiA8ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3RydW0u Y29tPj4gd3JvdGU6DQoNCkhpIEV2ZXJ5b25lLA0KDQpEaWQgYW55b25lIGhhdmUgZmVlZGJhY2sg b3Igb3RoZXIgdGhvdWdodHMgb24gU2VyZ2lv4oCZcyBwcm9wb3NhbD8NCg0KVGhhbmtzIQ0KDQpC ZW4uDQoNCg0KDQpPbiBTZXAgMzAsIDIwMjAsIGF0IDU6MjQgQU0sIFNlcmdpbyBHYXJjaWEgTXVy aWxsbyA8c2VyZ2lvLmdhcmNpYS5tdXJpbGxvQGdtYWlsLmNvbTxtYWlsdG86c2VyZ2lvLmdhcmNp YS5tdXJpbGxvQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBhbGwhDQoNCldoaWxlIFdlYlJUQyBo YXMgYmVlbiB2ZXJ5IHN1Y2Nlc3NmdWwgaW4gYSB3aWRlIHJhbmdlIG9mIHNjZW5hcmlvcywgaXRz IGFkYXB0aW9uIGluIHRoZSBicm9hZGNhc3Rpbmcvc3RyZWFtaW5nIGluZHVzdHJ5IGlzIGxhZ2dp bmcgYmVoaW5kLiBDdXJyZW50bHkgdGhlcmUgaXMgbm8gc3RhbmRhcmQgcHJvdG9jb2wgKGxpa2Ug U0lQIG9yIFJUU1ApIGRlc2lnbmVkIGZvciBpbmdlc3RpbmcgbWVkaWEgaW4gYSBzdHJlYW1pbmcg c2VydmljZSwgYW5kIGNvbnRlbnQgcHJvdmlkZXJzIHN0aWxsIHJlbHkgaGVhdmlseSBvbiBwcm90 b2NvbHMgbGlrZSBSVE1QIGZvciBpdC4NCg0KVGhlc2UgcHJvdG9jb2xzIGFyZSBtdWNoIG9sZGVy IHRoYW4gV2ViUlRDIGFuZCBsYWNrIGJ5IGRlZmF1bHQgc29tZSBpbXBvcnRhbnQgc2VjdXJpdHkg YW5kIHJlc2lsaWVuY2UgZmVhdHVyZXMgcHJvdmlkZWQgYnkgV2ViUlRDIHdpdGggbWluaW1hbCBk ZWxheS4NCg0KVGhlIG1lZGlhIGNvZGVjcyB1c2VkIGluIG9sZGVyIHByb3RvY29scyBkbyBub3Qg YWx3YXlzIG1hdGNoIHRob3NlIGJlaW5nIHVzZWQgaW4gV2ViUlRDLCBtYW5kYXRpbmcgdHJhbnNj b2Rpbmcgb24gdGhlIGluZ2VzdCBub2RlLCBpbnRyb2R1Y2luZyBkZWxheSBhbmQgZGVncmFkaW5n IG1lZGlhIHF1YWxpdHkuIFRoaXMgdHJhbnNjb2Rpbmcgc3RlcCBpcyBhbHdheXMgcHJlc2VudCBp biB0cmFkaXRpb25hbCBzdHJlYW1pbmcgdG8gc3VwcG9ydCBlLmcuIEFCUiwgYW5kIGNvbWVzIGF0 IG5vIGNvc3QuIEhvd2V2ZXIgd2VicnRjIGltcGxlbWVudHMgY2xpZW50LXNpZGUgQUJSLCBieSBt ZWFucyBvZiBzaW11bGNhc3QgYW5kIFNWQyBjb2RlY3MsIHdoaWNoIG90aGVyd2lzZSBhbGxldmlh dGUgdGhlIG5lZWQgZm9yIHNlcnZlci1zaWRlIHRyYW5zY29kaW5nLiBDb250ZW50IHByb3RlY3Rp b24gYW5kIFByaXZhY3kgRW5oYW5jZW1lbnQgY2FuIGJlIGFjaGlldmUgd2l0aCBFbmQtdG8tRW5k IEVuY3J5cHRpb24sIHdoaWNoIHByZWNsdWRlIGFueSBzZXJ2ZXItc2lkZSBtZWRpYSBwcm9jZXNz aW5nLg0KDQpXZSBoYXZlIGJlZW4gd29ya2luZyBvbiBhIHByb3Bvc2FsIGZvciBhIHNpbXBsZSBI VFRQIGJhc2VkIHByb3RvY29sIHRoYXQgd2lsbCBhbGxvdyBXZWJSVEMgZW5kcG9pbnRzIHRvIGlu Z2VzdCBjb250ZW50IGludG8gc3RyZWFtaW5nIHNlcnZpY2VzIGFuZC9vciBDRE5zIHRvIGZpbGwg dGhpcyBnYXAgYW5kIGZhY2lsaXRhdGUgZGVwbG95bWVudDoNCsK3ICAgICAgICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW11cmlsbG8td2hpcC0wMDxodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbXVyaWxsby13aGlw LTAwX187ISFQSVplZVc1d3NjeW5SUSE5TF9ETlNkUGVlb1hMZ1VXUEh4bHRXMHBaT0RoR3R5NmlF XzMyd1Bqa21fMzV0N2VmcVJhOExndlVWTEpxNEs2JD4NCsK3ICAgICAgICAgaHR0cHM6Ly9naXRo dWIuY29tL211cmlsbG8xMjgvd2VicnRjLWh0dHAtaW5nZXN0LXByb3RvY29sLzxodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2dpdGh1Yi5jb20vbXVyaWxsbzEyOC93ZWJydGMtaHR0 cC1pbmdlc3QtcHJvdG9jb2wvX187ISFQSVplZVc1d3NjeW5SUSE5TF9ETlNkUGVlb1hMZ1VXUEh4 bHRXMHBaT0RoR3R5NmlFXzMyd1Bqa21fMzV0N2VmcVJhOExndlVWN0JaeFlPJD4NCg0KV2UgaGF2 ZSBhbHJlYWR5IGltcGxlbWVudGVkIGl0IG9uIEphbnVzIGFuZCBNZWRvb3plIG1lZGlhIHNlcnZl cnM6DQrCtyAgICAgICAgIGh0dHBzOi8vd3d3Lm1lZXRlY2hvLmNvbS9ibG9nL3doaXAtamFudXMv PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3Lm1lZXRlY2hvLmNvbS9ibG9n L3doaXAtamFudXMvX187ISFQSVplZVc1d3NjeW5SUSE5TF9ETlNkUGVlb1hMZ1VXUEh4bHRXMHBa T0RoR3R5NmlFXzMyd1Bqa21fMzV0N2VmcVJhOExndlVlN2JfQVd4JD4NCsK3ICAgICAgICAgaHR0 cHM6Ly9tZWRpdW0uY29tL0BtZWRvb3plL3doaXAtd2VicnRjLW1lZXRzLXRoZS1icm9hZGNhc3Rp bmctd29ybGQtODY3NzJlYmE4YWU3PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov bWVkaXVtLmNvbS9AbWVkb296ZS93aGlwLXdlYnJ0Yy1tZWV0cy10aGUtYnJvYWRjYXN0aW5nLXdv cmxkLTg2NzcyZWJhOGFlN19fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0 VzBwWk9EaEd0eTZpRV8zMndQamttXzM1dDdlZnFSYThMZ3ZVY1lJbTJoTCQ+DQoNCkFuZCBhZGRl ZCBzdXBwb3J0IGludG8gYSBXZWJSVEMgdmVyc2lvbiBvZiBPQlMgc3R1ZGlvOg0KwrcgICAgICAg ICBodHRwczovL2dpdGh1Yi5jb20vQ29TTW9Tb2Z0d2FyZS9PQlMtc3R1ZGlvLXdlYnJ0Yy9yZWxl YXNlcy90YWcvbTg0djIzLjItUkMyPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov Z2l0aHViLmNvbS9Db1NNb1NvZnR3YXJlL09CUy1zdHVkaW8td2VicnRjL3JlbGVhc2VzL3RhZy9t ODR2MjMuMi1SQzJfXzshIVBJWmVlVzV3c2N5blJRITlMX0ROU2RQZWVvWExnVVdQSHhsdFcwcFpP RGhHdHk2aUVfMzJ3UGprbV8zNXQ3ZWZxUmE4TGd2VWJCeXVmRXQkPg0KDQpXZSBhbHNvIHBsYW4g dG8gaGF2ZSBhbiBpbnRlcm9wIHNlc3Npb24gb24gdGhlIG5leHQgSUVURiBoYWNraGF0b24sIHRo YXQgd2lsbCBhbGxvdyB0byBjaGVjayB0aGUgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGRpZmZl cmVudCBXZWJSVEMgaW1wbGVtZW50YXRpb25zLg0KDQpXaGF0IHdvdWxkIGJlIHRoZSBiZXN0IHdh eSBvZiBtb3ZpbmcgdGhpcyBmb3J3YXJkPyBPYnZpb3VzbHksIGFueSBmZWVkYmFjayB3aWxsIGJl IHZlcnkgd2VsY29tZS4NCg0KQmVzdCByZWdhcmRzDQpTZXJnaW8NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGlzcGF0Y2ggbWFpbGluZyBsaXN0 DQpkaXNwYXRjaEBpZXRmLm9yZzxtYWlsdG86ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPGh0dHBzOi8vdXJsZGVmZW5zZS5j b20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2hfXzsh IVBJWmVlVzV3c2N5blJRITlMX0ROU2RQZWVvWExnVVdQSHhsdFcwcFpPRGhHdHk2aUVfMzJ3UGpr bV8zNXQ3ZWZxUmE4TGd2VVNmTHhVNFgkPg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCg0KZGlz cGF0Y2hAaWV0Zi5vcmc8bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2hfXzshIVBJ WmVlVzV3c2N5blJRITg5bFVUeGVsRWcyM2syN3VoUTVjYkNOXzlsXzloOXVaRm5ScUU3MjZEZ0JC UzRqclRNelhyZzU3TzRnanhvZlokPg0KDQoNCg== --_000_FA2E55FFD39C4C46B6AF8C02E1029968nbcunicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBDU1wpIjsNCglwYW5v c2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29u c29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTMw NjM0NTAyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzU0MTY4ODcwO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNTA5NTE3NDU1Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoyNTg2NTAzNDg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21z by1saXN0LWlkOjIwODg5MTMzNTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NDE5OTc3MTY7 fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5IaSBTZXJnaW8sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+R3JlYXQuJm5ic3A7IFRoYW5r cyBmb3IgY2xvc2luZyB0aGF0IGxvb3Agd2l0aCBNT1BTLiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj5SZWdhcmRz PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+R2xlbm48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5PbiAxMC8yOC8yMCwgMjoxMCBQTSwgJnF1b3Q7 ZGlzcGF0Y2ggb24gYmVoYWxmIG9mIFNlcmdpbyBHYXJjaWEgTXVyaWxsbyZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmciPmRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOnNlcmdpby5nYXJjaWEu bXVyaWxsb0BnbWFpbC5jb20iPnNlcmdpby5nYXJjaWEubXVyaWxsb0BnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPkhpIEdsZW4sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+V2UgYXJlIGFscmVhZHkgcGFydGljaXBhdGluZyBpbiB0aGUgTU9QUywgYnV0IEkgZG9u J3QgdGhpbmsgaXQgaXMgdGhlIGJlc3QgcGxhY2UgdG8gcHJvZ3Jlc3MgdGhlIHByb3Bvc2FsLCBm cm9tIHRoZSBNT1BTIGNoYXJ0ZXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj4mcXVvdDtUaGUg c2NvcGUgaXMgbWVkaWEgYW5kIG1lZGlhIHByb3RvY29sc+KAmSBpbnRlcmFjdGlvbnMgd2l0aCB0 aGUgbmV0d29yaywgYnV0IG5vdA0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPnRoZSB0 ZWNobm9sb2dpZXMgb2YgY29udHJvbCBwcm90b2NvbHMgb3IgbWVkaWEgZm9ybWF0cy4mcXVvdDs8 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SG93ZXZlciwgd2Ugd2VyZSB0aGlua2luZyBpbiB1c2luZyBpdCBpbiB0aGUg ZnV0dXJlIGhhY2thdGhvbiBmb3IgdGVzdGluZyB3ZWJydGMgYXMgY3VycmVudGx5IHRoZXJlIGlz IG5vIG90aGVyIGVhc3kgd2F5IHRvIHRlc3Qgd2VicnRjIGFjcm9zcyBhIGRpZmZlcmVudCBzZXQg b2YgaW1wbGVtZW50YXRpb25zIHdpdGhvdXQgYWQtaG9jIGludGVncmF0aW9ucy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5SZWdhcmRpbmcgU1JUIGFuZCBS SVNULCBub25lIG9mIHRoZW0gd29yayBvbiBhIHdlYiBicm93c2VyIGFzIGFuIGluZ2VzdCBwb2lu dCBub3IgdGhleSBhbGxvdyBlYXNpbHkgdG8gYmUgdHJhbnNsYXRlZCB0byB3ZWJydGMgdG8gZW5h YmxlIGxvd2VzdCBkZWxheSBvbiBkaXN0cmlidXRpb24gdmlhIHdlYnJ0Yy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5CZXN0IHJlZ2FyZHM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5TZXJnaW88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6 IzIyMjIyMiI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPk9uIDI4LzEwLzIwMjAgMjE6MTUsIERlZW4sIEdsZW5uIChOQkNV bml2ZXJzYWwpIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhIj5JdCBtYXkgbWFrZSBzZW5zZSB0byBjcm9zcyBwb3N0IHRoaXMgdG8gdGhlIE1P UFMgbWFpbGluZyBsaXN0Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpI ZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVs dmV0aWNhIj5J4oCZbGwgcG9pbnQgb3V0IHRoYXQgU1JUIGFuZCBSSVNUIGFyZSB0d28gZXhhbXBs ZXMgb2YgcHJvdG9jb2xzIHVzZWQgcHJvZmVzc2lvbmFsbHkgdG8gdHJhbnNwb3J0IGNvbnRlbnQg ZHVyaW5nIGFjcXVpc2l0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Okhl bHZldGljYSI+QWxzbywgdGhlcmUgaGFzIGJlZW4gZGlzY3Vzc2lvbiBpbiBNT1BTIGFib3V0IHNl dHRpbmcgdXAgYSBmdXR1cmUgc2lkZS1ieS1zaWRlIHNldCBvZiB0cmFuc3BvcnQgdGVzdHMgYW5k IG1lYXN1cmVtZW50cyB0byB1bmRlcnN0YW5kIHRoZSBiZWhhdmlvcnMgb2YgdGhlIGRpZmZlcmVu dCB0cmFuc3BvcnRzDQog4oCTIHBlcmhhcHMgYXQgYSBmdXR1cmUgSUVURiBoYWNrYXRob24gd2hl biBldmVyeW9uZSBjYW4gd29yayB0b2dldGhlciBpbiB0aGUgc2FtZSByb29tLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkhlbHZldGljYSI+LWdsZW5uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpIZWx2ZXRpY2EiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjEuMGluIj5PbiAxMC8yOC8yMCwgMToxMCBQTSwgJnF1b3Q7ZGlzcGF0Y2ggb24gYmVoYWxm IG9mIEJlbiBDYW1wYmVsbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmRpc3BhdGNoLWJvdW5j ZXNAaWV0Zi5vcmciPmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0K PGEgaHJlZj0ibWFpbHRvOmJlbkBub3N0cnVtLmNvbSI+YmVuQG5vc3RydW0uY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+ SGkgRXZlcnlvbmUsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+RGlk IGFueW9uZSBoYXZlIGZlZWRiYWNrIG9yIG90aGVyIHRob3VnaHRzIG9uIFNlcmdpb+KAmXMgcHJv cG9zYWw/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5U aGFua3MhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluIj5C ZW4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjEuMGluIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+T24gU2Vw IDMwLCAyMDIwLCBhdCA1OjI0IEFNLCBTZXJnaW8gR2FyY2lhIE11cmlsbG8gJmx0OzxhIGhyZWY9 Im1haWx0bzpzZXJnaW8uZ2FyY2lhLm11cmlsbG9AZ21haWwuY29tIj5zZXJnaW8uZ2FyY2lhLm11 cmlsbG9AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbiI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQpIaSBhbGwhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4waW4iPg0KV2hpbGUgV2ViUlRDIGhhcyBiZWVuIHZlcnkg c3VjY2Vzc2Z1bCBpbiBhIHdpZGUgcmFuZ2Ugb2Ygc2NlbmFyaW9zLCBpdHMgYWRhcHRpb24gaW4g dGhlIGJyb2FkY2FzdGluZy9zdHJlYW1pbmcgaW5kdXN0cnkgaXMgbGFnZ2luZyBiZWhpbmQuIEN1 cnJlbnRseSB0aGVyZSBpcyBubyBzdGFuZGFyZCBwcm90b2NvbCAobGlrZSBTSVAgb3IgUlRTUCkg ZGVzaWduZWQgZm9yIGluZ2VzdGluZyBtZWRpYSBpbiBhIHN0cmVhbWluZyBzZXJ2aWNlLCBhbmQg Y29udGVudA0KIHByb3ZpZGVycyBzdGlsbCByZWx5IGhlYXZpbHkgb24gcHJvdG9jb2xzIGxpa2Ug UlRNUCBmb3IgaXQuPGJyPg0KPGJyPg0KVGhlc2UgcHJvdG9jb2xzIGFyZSBtdWNoIG9sZGVyIHRo YW4gV2ViUlRDIGFuZCBsYWNrIGJ5IGRlZmF1bHQgc29tZSBpbXBvcnRhbnQgc2VjdXJpdHkgYW5k IHJlc2lsaWVuY2UgZmVhdHVyZXMgcHJvdmlkZWQgYnkgV2ViUlRDIHdpdGggbWluaW1hbCBkZWxh eS48YnI+DQo8YnI+DQpUaGUgbWVkaWEgY29kZWNzIHVzZWQgaW4gb2xkZXIgcHJvdG9jb2xzIGRv IG5vdCBhbHdheXMgbWF0Y2ggdGhvc2UgYmVpbmcgdXNlZCBpbiBXZWJSVEMsIG1hbmRhdGluZyB0 cmFuc2NvZGluZyBvbiB0aGUgaW5nZXN0IG5vZGUsIGludHJvZHVjaW5nIGRlbGF5IGFuZCBkZWdy YWRpbmcgbWVkaWEgcXVhbGl0eS4gVGhpcyB0cmFuc2NvZGluZyBzdGVwIGlzIGFsd2F5cyBwcmVz ZW50IGluIHRyYWRpdGlvbmFsIHN0cmVhbWluZyB0byBzdXBwb3J0IGUuZy4NCiBBQlIsIGFuZCBj b21lcyBhdCBubyBjb3N0LiBIb3dldmVyIHdlYnJ0YyBpbXBsZW1lbnRzIGNsaWVudC1zaWRlIEFC UiwgYnkgbWVhbnMgb2Ygc2ltdWxjYXN0IGFuZCBTVkMgY29kZWNzLCB3aGljaCBvdGhlcndpc2Ug YWxsZXZpYXRlIHRoZSBuZWVkIGZvciBzZXJ2ZXItc2lkZSB0cmFuc2NvZGluZy4gQ29udGVudCBw cm90ZWN0aW9uIGFuZCBQcml2YWN5IEVuaGFuY2VtZW50IGNhbiBiZSBhY2hpZXZlIHdpdGggRW5k LXRvLUVuZCBFbmNyeXB0aW9uLA0KIHdoaWNoIHByZWNsdWRlIGFueSBzZXJ2ZXItc2lkZSBtZWRp YSBwcm9jZXNzaW5nLjxicj4NCjxicj4NCldlIGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgcHJvcG9z YWwgZm9yIGEgc2ltcGxlIEhUVFAgYmFzZWQgcHJvdG9jb2wgdGhhdCB3aWxsIGFsbG93IFdlYlJU QyBlbmRwb2ludHMgdG8gaW5nZXN0IGNvbnRlbnQgaW50byBzdHJlYW1pbmcgc2VydmljZXMgYW5k L29yIENETnMgdG8gZmlsbCB0aGlzIGdhcCBhbmQgZmFjaWxpdGF0ZSBkZXBsb3ltZW50OjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEuNWluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtbXVyaWxsby13aGlwLTAwX187ISFQSVplZVc1d3NjeW5SUSE5TF9ETlNkUGVlb1hMZ1VX UEh4bHRXMHBaT0RoR3R5NmlFXzMyd1Bqa21fMzV0N2VmcVJhOExndlVWTEpxNEs2JCI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW11cmlsbG8td2hpcC0wMDwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVu dDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PGEgaHJlZj0iaHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9naXRodWIuY29tL211cmlsbG8xMjgvd2Vi cnRjLWh0dHAtaW5nZXN0LXByb3RvY29sL19fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9Y TGdVV1BIeGx0VzBwWk9EaEd0eTZpRV8zMndQamttXzM1dDdlZnFSYThMZ3ZVVjdCWnhZTyQiPmh0 dHBzOi8vZ2l0aHViLmNvbS9tdXJpbGxvMTI4L3dlYnJ0Yy1odHRwLWluZ2VzdC1wcm90b2NvbC88 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS4w aW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MS4waW4iPg0KV2UgaGF2ZSBhbHJlYWR5IGltcGxlbWVudGVkIGl0IG9uIEphbnVzIGFu ZCBNZWRvb3plIG1lZGlhIHNlcnZlcnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxl dmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovd3d3Lm1lZXRlY2hvLmNvbS9ibG9nL3doaXAtamFudXMvX187ISFQSVplZVc1d3Nj eW5SUSE5TF9ETlNkUGVlb1hMZ1VXUEh4bHRXMHBaT0RoR3R5NmlFXzMyd1Bqa21fMzV0N2VmcVJh OExndlVlN2JfQVd4JCI+aHR0cHM6Ly93d3cubWVldGVjaG8uY29tL2Jsb2cvd2hpcC1qYW51cy88 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MS41 aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5 bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovbWVkaXVtLmNvbS9A bWVkb296ZS93aGlwLXdlYnJ0Yy1tZWV0cy10aGUtYnJvYWRjYXN0aW5nLXdvcmxkLTg2NzcyZWJh OGFlN19fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0VzBwWk9EaEd0eTZp RV8zMndQamttXzM1dDdlZnFSYThMZ3ZVY1lJbTJoTCQiPmh0dHBzOi8vbWVkaXVtLmNvbS9AbWVk b296ZS93aGlwLXdlYnJ0Yy1tZWV0cy10aGUtYnJvYWRjYXN0aW5nLXdvcmxkLTg2NzcyZWJhOGFl NzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDox LjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjBpbiI+DQpBbmQgYWRkZWQgc3VwcG9ydCBpbnRvIGEgV2ViUlRDIHZlcnNpb24g b2YgT0JTIHN0dWRpbzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDoxLjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzYi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9n aXRodWIuY29tL0NvU01vU29mdHdhcmUvT0JTLXN0dWRpby13ZWJydGMvcmVsZWFzZXMvdGFnL204 NHYyMy4yLVJDMl9fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0VzBwWk9E aEd0eTZpRV8zMndQamttXzM1dDdlZnFSYThMZ3ZVYkJ5dWZFdCQiPmh0dHBzOi8vZ2l0aHViLmNv bS9Db1NNb1NvZnR3YXJlL09CUy1zdHVkaW8td2VicnRjL3JlbGVhc2VzL3RhZy9tODR2MjMuMi1S QzI8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MS4waW4iPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MS4waW4iPg0KV2UgYWxzbyBwbGFuIHRvIGhhdmUgYW4gaW50ZXJvcCBzZXNzaW9u IG9uIHRoZSBuZXh0IElFVEYgaGFja2hhdG9uLCB0aGF0IHdpbGwgYWxsb3cgdG8gY2hlY2sgdGhl IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBkaWZmZXJlbnQgV2ViUlRDIGltcGxlbWVudGF0aW9u cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBp biI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxLjBpbiI+DQpXaGF0IHdvdWxkIGJlIHRoZSBiZXN0IHdheSBvZiBtb3ZpbmcgdGhpcyBm b3J3YXJkPyBPYnZpb3VzbHksIGFueSBmZWVkYmFjayB3aWxsIGJlIHZlcnkgd2VsY29tZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDox LjBpbiI+DQpCZXN0IHJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDoxLjBpbiI+DQpTZXJnaW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxLjBpbiI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CmRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRm Lm9yZyI+ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRj aF9fOyEhUElaZWVXNXdzY3luUlEhOUxfRE5TZFBlZW9YTGdVV1BIeGx0VzBwWk9EaEd0eTZpRV8z MndQamttXzM1dDdlZnFSYThMZ3ZVU2ZMeFU0WCQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGlzcGF0Y2g8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEu MGluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+ZGlzcGF0Y2ggbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxhIGhyZWY9Im1haWx0bzpkaXNwYXRjaEBpZXRmLm9yZyI+ ZGlzcGF0Y2hAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2hfXzshIVBJWmVlVzV3c2N5blJR ITg5bFVUeGVsRWcyM2syN3VoUTVjYkNOXzlsXzloOXVaRm5ScUU3MjZEZ0JCUzRqclRNelhyZzU3 TzRnanhvZlokIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNo PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_FA2E55FFD39C4C46B6AF8C02E1029968nbcunicom_-- From nobody Wed Oct 28 15:05:19 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F033A0657; Wed, 28 Oct 2020 15:05:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160392271760.32198.5636551038762025586@ietfa.amsl.com> Date: Wed, 28 Oct 2020 15:05:17 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 22:05:18 -0000 IANA action state changed to "In Progress" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Wed Oct 28 15:05:25 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4E3A064A; Wed, 28 Oct 2020 15:05:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160392271827.32198.1758205073035806800@ietfa.amsl.com> Date: Wed, 28 Oct 2020 15:05:18 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 22:05:18 -0000 IANA action state changed to "Waiting on RFC Editor" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Wed Oct 28 16:05:16 2020 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A33973A0A86; Wed, 28 Oct 2020 16:05:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160392631362.28175.5399648150548972677@ietfa.amsl.com> Date: Wed, 28 Oct 2020 16:05:13 -0700 From: IETF Secretariat Archived-At: Subject: [dispatch] Datatracker State Update Notice: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2020 23:05:14 -0000 IANA action state changed to "RFC-Ed-Ack" Datatracker URL: https://datatracker.ietf.org/doc/draft-hardie-dispatch-rfc3405-update/ From nobody Wed Oct 28 20:14:20 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28E23A067A for ; Wed, 28 Oct 2020 20:14:18 -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 3g6HQulRoP08 for ; Wed, 28 Oct 2020 20:14:16 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 CAE303A0656 for ; Wed, 28 Oct 2020 20:14:16 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id y20so1881313iod.5 for ; Wed, 28 Oct 2020 20:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+wg2FT76Sm4dfDnw9qTuWLTlSIIBcEesaSl48lQ/3/w=; b=XRoCITUyPfROu8vfIgpb+ODLpXSdnw74+Fo1P13O3nlr36KUq4E6fVrWXoWEBoWvGV hX7UX48KLgfszmR6yesgEXayQ9+J/z1Y1ZDSX/Q/lPgYgoiPf4ULWoa+eH6DCE7WA4ZY 0q5kWXo1ggSdLoJDTZPibv5PBe8HLCAbuvxs/Dd3146KxzUlHvNhzbFmDq9kOv/NYD/i c3ypiba/MYgbvmh/65TvAXOB8a48G+1Zk76OIIYHdv9WyNqzKvcYSJ/9w8MoOCmwbWxh ZYLA4MwvDEZvAe67sxctT0c4X9acnQlIFeIKUczDvSYhrlrR0O3zG64YrBKg2kMAXkWO 6cDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+wg2FT76Sm4dfDnw9qTuWLTlSIIBcEesaSl48lQ/3/w=; b=rX1i1VXuXf5H5g6zIty7omNnKRj2L4Hz4+Cq1HHEtqSQ5io3nJNhPkVV8yOUenlFUN LBHtB9BYu29docd+WA/cZNxNvCTbbtK+kTI0GXMPyLj+TAX6unPJR0SUsbwDKN2hGaQp M33IFzXgxVpQEyxHhOGc6HbWTALsZVwoF5PpilSM0bmsOHiKBlzsuQlDwIJBLSTfEJWG X/kczLr5XncdcuXxJz7g0ioH8kdYAcJfdKd7x8FDGkFrk0jXoQWQ3XtASERcR36Dp8fL J9wqRouQeiDs7ymccooBI/sOJT7vewaCti1cxHPxrwYfuDBjvnHbpHqNRxy+C2KQvTpp JZ4g== X-Gm-Message-State: AOAM530HLaDgId94BTz/OpW7K3gIJJrgA5B6S/GjnNB9khgMRkXKQB6L j4W5FC+aJXqSL7OPJ20U7vA4VblsN9f3RpTeBAo= X-Google-Smtp-Source: ABdhPJzKyyCWJL5+zm/FzOViJCtV/MylVCeU2RRHmgBl28NSjfgVMnBFSkcjXlQWhPn8kn/GHbtUunKtkzKrf652mEo= X-Received: by 2002:a05:6638:2494:: with SMTP id x20mr1912936jat.83.1603941256176; Wed, 28 Oct 2020 20:14:16 -0700 (PDT) MIME-Version: 1.0 References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> In-Reply-To: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> From: Alexandre GOUAILLARD Date: Thu, 29 Oct 2020 11:14:05 +0800 Message-ID: To: Ben Campbell Cc: "dispatch@ietf.org" , Alex Gouaillard Content-Type: multipart/alternative; boundary="000000000000d0aa1f05b2c6ac13" Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 03:14:19 -0000 --000000000000d0aa1f05b2c6ac13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Just to clarify the scope. WHIP is a very light weight **signalling** (or control) protocol that acts as the missing reference companion protocol to webrtc in the specific (simplified) use case of webrtc ingest into platforms. The media part, the network part, and the media encryption are handled by webrtc itself. The security of the signalling protocol is handled by HTTPS. In that regard, conceptually, it is very close to what RTSP(s) 2.0 was to RTP, and it could make sense, now that the RTCWEB group is closed, to let either the AVTCORE or the MMUSIC group adopt it. Regards, On Thu, Oct 29, 2020 at 4:10 AM Ben Campbell wrote: > Hi Everyone, > > Did anyone have feedback or other thoughts on Sergio=E2=80=99s proposal? > > Thanks! > > Ben. > > On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > > Hi all! > > > While WebRTC has been very successful in a wide range of scenarios, its > adaption in the broadcasting/streaming industry is lagging behind. > Currently there is no standard protocol (like SIP or RTSP) designed for > ingesting media in a streaming service, and content providers still rely > heavily on protocols like RTMP for it. > > These protocols are much older than WebRTC and lack by default some > important security and resilience features provided by WebRTC with minima= l > delay. > > The media codecs used in older protocols do not always match those being > used in WebRTC, mandating transcoding on the ingest node, introducing del= ay > and degrading media quality. This transcoding step is always present in > traditional streaming to support e.g. ABR, and comes at no cost. However > webrtc implements client-side ABR, by means of simulcast and SVC codecs, > which otherwise alleviate the need for server-side transcoding. Content > protection and Privacy Enhancement can be achieve with End-to-End > Encryption, which preclude any server-side media processing. > > We have been working on a proposal for a simple HTTP based protocol that > will allow WebRTC endpoints to ingest content into streaming services > and/or CDNs to fill this gap and facilitate deployment: > > - https://tools.ietf.org/html/draft-murillo-whip-00 > - https://github.com/murillo128/webrtc-http-ingest-protocol/ > > > We have already implemented it on Janus and Medooze media servers: > > - https://www.meetecho.com/blog/whip-janus/ > - > https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-8= 6772eba8ae7 > > > And added support into a WebRTC version of OBS studio: > > - > https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23= .2-RC2 > > > We also plan to have an interop session on the next IETF hackhaton, that > will allow to check the interoperability between different WebRTC > implementations. > > > What would be the best way of moving this forward? Obviously, any feedbac= k > will be very welcome. > > > Best regards > > Sergio > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Alex. Gouaillard, PhD, PhD, MBA ---------------------------------------------------------------------------= --------- President - CoSMo Software Consulting, Singapore ---------------------------------------------------------------------------= --------- sg.linkedin.com/agouaillard - --000000000000d0aa1f05b2c6ac13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Just to clarify the scope.

WHIP is a very light weight **signalling** (or contr= ol) protocol that acts as the missing reference companion protocol to webrt= c in the specific (simplified) use case of webrtc ingest into platforms. Th= e media part, the network=C2=A0part, and the media encryption are handled b= y webrtc itself. The security of the signalling protocol is handled by HTTP= S.

In that regard, conceptually, it is very close = to what RTSP(s) 2.0 was to RTP, and it could make sense, now that the RTCWE= B group is closed, to let either the AVTCORE or the MMUSIC group adopt it.<= /div>

Regards,


<= br>


On Thu, Oct 29, 2020 at 4:10 AM Ben Campbell <ben@nostrum.com> wrote:
Hi Everyone,

Did anyone have feedback or other thou= ghts on Sergio=E2=80=99s proposal?

Thanks!

Ben.

On Sep 30= , 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com= > wrote:

=20 =20 =20

Hi all!


While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:


We have already implemented it on Janus and Medooze media servers:


And added support into a WebRTC version of OBS studio:


We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.


What would be the best way of moving this forward? Obviously, an= y feedback will be very welcome.


Best regards

Sergio



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

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


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

--000000000000d0aa1f05b2c6ac13-- From nobody Thu Oct 29 04:07:52 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F77D3A03FB for ; Thu, 29 Oct 2020 04:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uu-Lq7o63mel for ; Thu, 29 Oct 2020 04:07:46 -0700 (PDT) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D700B3A03F3 for ; Thu, 29 Oct 2020 04:07:45 -0700 (PDT) Received: (qmail 99043 invoked from network); 29 Oct 2020 11:07:43 -0000 X-APM-Out-ID: 16039696639904 X-APM-Authkey: 255286/0(159927/0) 370 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 29 Oct 2020 11:07:43 -0000 Received: from localhost (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 196FD80BBC; Thu, 29 Oct 2020 11:07:43 +0000 (GMT) Received: from zimbra003.verygoodemail.com ([127.0.0.1]) by localhost (zimbra003.verygoodemail.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pk60mZvxL68n; Thu, 29 Oct 2020 11:07:43 +0000 (GMT) Received: from [192.67.4.33] (unknown [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id D976980896; Thu, 29 Oct 2020 11:07:42 +0000 (GMT) From: T H Panton Message-Id: <566085E5-B555-4314-BCFE-9A03CD082C8E@westhawk.co.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD4AE640-F901-491B-9201-5F951AC0E934" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) Date: Thu, 29 Oct 2020 11:07:41 +0000 In-Reply-To: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> Cc: "dispatch@ietf.org" , Alex Gouaillard To: Ben Campbell References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> X-Mailer: Apple Mail (2.3445.9.7) Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 11:07:49 -0000 --Apple-Mail=_FD4AE640-F901-491B-9201-5F951AC0E934 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My feedback: 1) this is a good idea - we need something like this. Full webRTC O/A is = too complex for simple ingestion usecases. 2) A URI is an excellent hook to hang this on. 3) I don't think it goes far enough. Almost all of the offer/answer content is redundant, because most of it = is _known_ by both sides already. The ingestion services typically specify what codecs/bitrates/framerates = they will accept. They don't output any media. I claim we can simplify the O/A to something that looks more like RTSP's = SDP or even simpler. - So I support this, but would want to discuss simplification. Tim. > On 28 Oct 2020, at 20:10, Ben Campbell wrote: >=20 > Hi Everyone, >=20 > Did anyone have feedback or other thoughts on Sergio=E2=80=99s = proposal? >=20 > Thanks! >=20 > Ben. >=20 >> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo = > wrote: >>=20 >> Hi all! >>=20 >>=20 >> While WebRTC has been very successful in a wide range of scenarios, = its adaption in the broadcasting/streaming industry is lagging behind. = Currently there is no standard protocol (like SIP or RTSP) designed for = ingesting media in a streaming service, and content providers still rely = heavily on protocols like RTMP for it. >>=20 >> These protocols are much older than WebRTC and lack by default some = important security and resilience features provided by WebRTC with = minimal delay. >>=20 >> The media codecs used in older protocols do not always match those = being used in WebRTC, mandating transcoding on the ingest node, = introducing delay and degrading media quality. This transcoding step is = always present in traditional streaming to support e.g. ABR, and comes = at no cost. However webrtc implements client-side ABR, by means of = simulcast and SVC codecs, which otherwise alleviate the need for = server-side transcoding. Content protection and Privacy Enhancement can = be achieve with End-to-End Encryption, which preclude any server-side = media processing. >>=20 >> We have been working on a proposal for a simple HTTP based protocol = that will allow WebRTC endpoints to ingest content into streaming = services and/or CDNs to fill this gap and facilitate deployment: >>=20 >> https://tools.ietf.org/html/draft-murillo-whip-00 = >> https://github.com/murillo128/webrtc-http-ingest-protocol/ = >>=20 >> We have already implemented it on Janus and Medooze media servers: >>=20 >> https://www.meetecho.com/blog/whip-janus/ = >> = https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772= eba8ae7 = >>=20 >> And added support into a WebRTC version of OBS studio: >>=20 >> = https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-R= C2 = >>=20 >> We also plan to have an interop session on the next IETF hackhaton, = that will allow to check the interoperability between different WebRTC = implementations. >>=20 >> What would be the best way of moving this forward? Obviously, any = feedback will be very welcome. >>=20 >> Best regards >>=20 >> Sergio >>=20 >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_FD4AE640-F901-491B-9201-5F951AC0E934 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My = feedback:

1) this is = a good idea - we need something like this. Full webRTC O/A is too = complex for simple ingestion usecases.
2) A URI is = an excellent hook to hang this on.
3) I don't think = it goes far enough.

Almost all of the offer/answer content is redundant, because = most of it is _known_ by both sides already.
The = ingestion services typically specify what codecs/bitrates/framerates = they will accept.
They don't output any = media.

I claim = we can simplify the O/A to something that looks more like RTSP's SDP or = even simpler.

- = So I support this, but would want to discuss simplification.

Tim.

On 28 Oct 2020, at 20:10, Ben Campbell <ben@nostrum.com> = wrote:

Hi Everyone,

Did anyone have feedback = or other thoughts on Sergio=E2=80=99s proposal?

Thanks!

Ben.

On Sep = 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

=20 =20

Hi all!


While WebRTC has been very successful in a wide = range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:


We have already implemented it on Janus and = Medooze media servers:


And added support into a WebRTC version of OBS = studio:


We also plan to have an interop session on the = next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.


What would be the best way of moving this forward? = Obviously, any feedback will be very welcome.


Best regards

Sergio



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

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

= --Apple-Mail=_FD4AE640-F901-491B-9201-5F951AC0E934-- From nobody Thu Oct 29 05:02:55 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84CD3A0CA2 for ; Thu, 29 Oct 2020 05:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2ycR1drfFPf for ; Thu, 29 Oct 2020 05:02:51 -0700 (PDT) Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9B33A0CA0 for ; Thu, 29 Oct 2020 05:02:50 -0700 (PDT) Received: from [192.168.3.157] (unknown [188.113.93.42]) by mork.alvestrand.no (Postfix) with ESMTPSA id 026087C6156 for ; Thu, 29 Oct 2020 13:02:49 +0100 (CET) To: dispatch@ietf.org References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> From: Harald Alvestrand Message-ID: <5bec29fb-1524-eced-e903-c57684b1c979@alvestrand.no> Date: Thu, 29 Oct 2020 13:02:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> Content-Type: multipart/alternative; boundary="------------8C62A8E713AD627A93985DDD" Content-Language: en-US Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 12:02:54 -0000 This is a multi-part message in MIME format. --------------8C62A8E713AD627A93985DDD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit In addition to the use cases mentioned, having a simple standard "configure this connection" protocol would make setting up a server for testing (the parts that can't be done by a browser talking to itself) a lot simpler. Harald On 10/28/20 9:10 PM, Ben Campbell wrote: > Hi Everyone, > > Did anyone have feedback or other thoughts on Sergio’s proposal? > > Thanks! > > Ben. > >> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo >> > > wrote: >> >> Hi all! >> >> >> While WebRTC has been very successful in a wide range of scenarios, >> its adaption in the broadcasting/streaming industry is lagging >> behind. Currently there is no standard protocol (like SIP or RTSP) >> designed for ingesting media in a streaming service, and content >> providers still rely heavily on protocols like RTMP for it. >> >> These protocols are much older than WebRTC and lack by default some >> important security and resilience features provided by WebRTC with >> minimal delay. >> >> The media codecs used in older protocols do not always match those >> being used in WebRTC, mandating transcoding on the ingest node, >> introducing delay and degrading media quality. This transcoding step >> is always present in traditional streaming to support e.g. ABR, and >> comes at no cost. However webrtc implements client-side ABR, by means >> of simulcast and SVC codecs, which otherwise alleviate the need for >> server-side transcoding. Content protection and Privacy Enhancement >> can be achieve with End-to-End Encryption, which preclude any >> server-side media processing. >> >> We have been working on a proposal for a simple HTTP based protocol >> that will allow WebRTC endpoints to ingest content into streaming >> services and/or CDNs to fill this gap and facilitate deployment: >> >> * https://tools.ietf.org/html/draft-murillo-whip-00 >> * https://github.com/murillo128/webrtc-http-ingest-protocol/ >> >> >> We have already implemented it on Janus and Medooze media servers: >> >> * https://www.meetecho.com/blog/whip-janus/ >> * https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 >> >> >> And added support into a WebRTC version of OBS studio: >> >> * https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2 >> >> >> We also plan to have an interop session on the next IETF hackhaton, >> that will allow to check the interoperability between different >> WebRTC implementations. >> >> >> What would be the best way of moving this forward? Obviously, any >> feedback will be very welcome. >> >> >> Best regards >> >> Sergio >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------8C62A8E713AD627A93985DDD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

In addition to the use cases mentioned, having a simple standard "configure this connection" protocol would make setting up a server for testing (the parts that can't be done by a browser talking to itself) a lot simpler.

Harald

On 10/28/20 9:10 PM, Ben Campbell wrote:
Hi Everyone,

Did anyone have feedback or other thoughts on Sergio’s proposal?

Thanks!

Ben.

On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

Hi all!


While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:


We have already implemented it on Janus and Medooze media servers:


And added support into a WebRTC version of OBS studio:


We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.


What would be the best way of moving this forward? Obviously, any feedback will be very welcome.


Best regards

Sergio



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


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
--------------8C62A8E713AD627A93985DDD-- From nobody Thu Oct 29 06:24:29 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080B63A0978 for ; Thu, 29 Oct 2020 06:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 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, NICE_REPLY_A=-0.247, 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 sEwk0Vsuid-1 for ; Thu, 29 Oct 2020 06:24:26 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 D3D193A0990 for ; Thu, 29 Oct 2020 06:24:25 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id d3so2403090wma.4 for ; Thu, 29 Oct 2020 06:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=kqv4miRx1vp+Ty59CkoekT+A/MyktMXh/uiOARbEp3k=; b=o9BjEbhVlMBpFNJ/MBBw5Xl90e34keDs6V6yKl0nULXoqu+YuxKEsxm6KVrhZGSUBj 3hBlvuo0TnfXf1pmqbZP9DSjdIsOVN7sxOt+Tf7Rmyj1kiVBlvWZ7y+uEkXHfy14fp4x rH8DLYe8gT/OaARqjT2sO/5myXm9I9bSE+AthR26Cbx3SAY7v+VfgblzfCe0j6lSprPt 7Y1UBfsvctpavWDHtf8NEEujrM0t2scd+Vj1Um4KWZCSsCpQno95qpjHtvyRnhcbywub 2FqG6Oh3FlV9kOGLXQBX51/xniFrlylxT/6FNN3HRAB2FBKxy1MvRpzC+DdUCPCoUEoi nEZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=kqv4miRx1vp+Ty59CkoekT+A/MyktMXh/uiOARbEp3k=; b=mRRxhcxOzHNAtjGS9Q3OPxnNxKe0Knp8GhrP9SkpyhNYqEOx7JByMACQpG71ucnIME O2nQJmAl483K//X6O240YUSvrKWowqkqpgeQj46PXWoktoKiWMrUyphNGkbBKRl/XBEk ZLY5+KojfMFLYpf6WtAXUt7mz21M15xFua6MAUQ3ezoBv6e60u/bUkqpPLjQo2OYGepB yWO/+aCrRWvQRKddubU2OM8ec3FuPt3xJ7m/dEWKsBt3jAvZZMp4FQ+/yh52GIzrYULI XDBlqU83q+vQCJFUDv35moExGWyNs68a7wMGoSIjRsPe39urKfupK9aJgE0HoEOCJgEO fgMA== X-Gm-Message-State: AOAM53027JjA6IiMfMGYxG445CwL0gMJAyjKpHNY0zvHi5ThUbcIqyTH WqxLI7ru76ABsv5Qe32/p0w7ho5VG+1ZYg== X-Google-Smtp-Source: ABdhPJxS4XssnsJYSaaTnkGp6Ja/ghjCiMukKzKKv4i1hdqtMeLPO7MhXgsJTbzlkUXSiPQ371ED0g== X-Received: by 2002:a1c:96ca:: with SMTP id y193mr4441223wmd.22.1603977861189; Thu, 29 Oct 2020 06:24:21 -0700 (PDT) Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id c8sm4802088wrv.26.2020.10.29.06.24.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Oct 2020 06:24:20 -0700 (PDT) To: dispatch@ietf.org References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> <566085E5-B555-4314-BCFE-9A03CD082C8E@westhawk.co.uk> From: Sergio Garcia Murillo Message-ID: Date: Thu, 29 Oct 2020 14:24:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <566085E5-B555-4314-BCFE-9A03CD082C8E@westhawk.co.uk> Content-Type: multipart/alternative; boundary="------------2D4997EBB9E1477277116895" Content-Language: en-US Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 13:24:28 -0000 This is a multi-part message in MIME format. --------------2D4997EBB9E1477277116895 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Tim, I see the merits for an uri-based signal-less and sdp-less setup for webrtc, specially for p2, in which you could even use datachannel as control channel for adding and removing tracks later on. However, that is far beyond the scope of my current draft. You say that this may not go far enough, and I could agree to that, but relying on current SDP O/A mechanism, HTTP and webrtc specs allows to have simple spec that we can have ready and working really fast. I agree to add constrains or force usage of certain optional features defined in other specs to simplify the implementation complexity on both servers and clients, but if we plan to redefine SDP I am afraid that we will get into a rabbit hole that will keep us discussing for months/years. As I said, I see the benefits of it, but I would prefer to leave it out of scope of current WHIP draft spec and if anyone is interested in leading the work, start an independent draft for that. I will be willing to collaborate anyway. Best regards Sergio On 29/10/2020 12:07, T H Panton wrote: > My feedback: > > 1) this is a good idea - we need something like this. Full webRTC O/A > is too complex for simple ingestion usecases. > 2) A URI is an excellent hook to hang this on. > 3) I don't think it goes far enough. > > Almost all of the offer/answer content is redundant, because most of > it is _known_ by both sides already. > The ingestion services typically specify what > codecs/bitrates/framerates they will accept. > They don't output any media. > > I claim we can simplify the O/A to something that looks more like > RTSP's SDP or even simpler. > > - So I support this, but would want to discuss simplification. > > Tim. > >> On 28 Oct 2020, at 20:10, Ben Campbell > > wrote: >> >> Hi Everyone, >> >> Did anyone have feedback or other thoughts on Sergio’s proposal? >> >> Thanks! >> >> Ben. >> >>> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo >>> >> > wrote: >>> >>> Hi all! >>> >>> >>> While WebRTC has been very successful in a wide range of scenarios, >>> its adaption in the broadcasting/streaming industry is lagging >>> behind. Currently there is no standard protocol (like SIP or RTSP) >>> designed for ingesting media in a streaming service, and content >>> providers still rely heavily on protocols like RTMP for it. >>> >>> These protocols are much older than WebRTC and lack by default some >>> important security and resilience features provided by WebRTC with >>> minimal delay. >>> >>> The media codecs used in older protocols do not always match those >>> being used in WebRTC, mandating transcoding on the ingest node, >>> introducing delay and degrading media quality. This transcoding step >>> is always present in traditional streaming to support e.g. ABR, and >>> comes at no cost. However webrtc implements client-side ABR, by >>> means of simulcast and SVC codecs, which otherwise alleviate the >>> need for server-side transcoding. Content protection and Privacy >>> Enhancement can be achieve with End-to-End Encryption, which >>> preclude any server-side media processing. >>> >>> We have been working on a proposal for a simple HTTP based protocol >>> that will allow WebRTC endpoints to ingest content into streaming >>> services and/or CDNs to fill this gap and facilitate deployment: >>> >>> * https://tools.ietf.org/html/draft-murillo-whip-00 >>> * https://github.com/murillo128/webrtc-http-ingest-protocol/ >>> >>> >>> We have already implemented it on Janus and Medooze media servers: >>> >>> * https://www.meetecho.com/blog/whip-janus/ >>> * https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-86772eba8ae7 >>> >>> >>> And added support into a WebRTC version of OBS studio: >>> >>> * https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v23.2-RC2 >>> >>> >>> We also plan to have an interop session on the next IETF hackhaton, >>> that will allow to check the interoperability between different >>> WebRTC implementations. >>> >>> >>> What would be the best way of moving this forward? Obviously, any >>> feedback will be very welcome. >>> >>> >>> Best regards >>> >>> Sergio >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------2D4997EBB9E1477277116895 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Tim,

I see the merits for an uri-based signal-less and sdp-less setup for webrtc, specially for p2, in which you could even use datachannel as control channel for adding and removing tracks later on. However, that is far beyond the scope of my current draft.

You say that this may not go far enough, and I could agree to that, but relying on current SDP O/A mechanism, HTTP and webrtc specs allows to have simple spec that we can have ready and working really fast. I agree to add constrains or force usage of certain optional features defined in other specs to simplify the implementation complexity on both servers and clients, but if we plan to redefine SDP I am afraid that we will get into a rabbit hole that will keep us discussing for months/years.

As I said, I see the benefits of it, but I would prefer to leave it out of scope of current WHIP draft  spec and if anyone is interested in leading the work, start an independent draft for that. I will be willing to collaborate anyway.

Best regards
Sergio

On 29/10/2020 12:07, T H Panton wrote:
My feedback:

1) this is a good idea - we need something like this. Full webRTC O/A is too complex for simple ingestion usecases.
2) A URI is an excellent hook to hang this on.
3) I don't think it goes far enough.

Almost all of the offer/answer content is redundant, because most of it is _known_ by both sides already.
The ingestion services typically specify what codecs/bitrates/framerates they will accept.
They don't output any media.

I claim we can simplify the O/A to something that looks more like RTSP's SDP or even simpler.

- So I support this, but would want to discuss simplification.

Tim.

On 28 Oct 2020, at 20:10, Ben Campbell <ben@nostrum.com> wrote:

Hi Everyone,

Did anyone have feedback or other thoughts on Sergio’s proposal?

Thanks!

Ben.

On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

Hi all!


While WebRTC has been very successful in a wide range of scenarios, its adaption in the broadcasting/streaming industry is lagging behind. Currently there is no standard protocol (like SIP or RTSP) designed for ingesting media in a streaming service, and content providers still rely heavily on protocols like RTMP for it.

These protocols are much older than WebRTC and lack by default some important security and resilience features provided by WebRTC with minimal delay.

The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node, introducing delay and degrading media quality. This transcoding step is always present in traditional streaming to support e.g. ABR, and comes at no cost. However webrtc implements client-side ABR, by means of simulcast and SVC codecs, which otherwise alleviate the need for server-side transcoding. Content protection and Privacy Enhancement can be achieve with End-to-End Encryption, which preclude any server-side media processing.

We have been working on a proposal for a simple HTTP based protocol that will allow WebRTC endpoints to ingest content into streaming services and/or CDNs to fill this gap and facilitate deployment:


We have already implemented it on Janus and Medooze media servers:


And added support into a WebRTC version of OBS studio:


We also plan to have an interop session on the next IETF hackhaton, that will allow to check the interoperability between different WebRTC implementations.


What would be the best way of moving this forward? Obviously, any feedback will be very welcome.


Best regards

Sergio



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

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


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


--------------2D4997EBB9E1477277116895-- From nobody Thu Oct 29 06:56:21 2020 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3483A0AFA for ; Thu, 29 Oct 2020 06:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=aruba.it 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 gYEnK91TD1qb for ; Thu, 29 Oct 2020 06:56:16 -0700 (PDT) Received: from smtpcmd0986.aruba.it (smtpcmd0986.aruba.it [62.149.156.86]) by ietfa.amsl.com (Postfix) with ESMTP id 800DE3A0AD7 for ; Thu, 29 Oct 2020 06:56:15 -0700 (PDT) Received: from lminiero ([93.35.209.44]) by Aruba Outgoing Smtp with ESMTPSA id Y8PUk2berboZEY8PUkHOxz; Thu, 29 Oct 2020 14:56:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1603979774; bh=8cFbmtlBOPXNhlf8pe+4XXHq06/xg+tY2r5lUBvWf5M=; h=Date:From:To:Subject:MIME-Version:Content-Type; b=SspzFomJYz8j3nDdcpvUlX2miE7GWXBYJlesim6QLEx6RIOfaElwfUXOheAKvudag /7vDdQopGvHwEEMuSNhP/R2KLBFKhHbVSRnXdsEhJJTkDXqSLiSxJPFFXOhWklxKR+ 57zibY0zMsanqCJZg+3ZDLDTYTi++zoOXYz6QuLrIj78uKwh7UXU6EnJWsXeBf4tut nkHs3Cak2D8heOWOseU5J+zvhWpYC62cZNtuGEu9RypoqQzAWs+0gGhZRQRYjI230R CllH4icq2UhUpbIvZ3yRbMl0KLB7UGM1GGPQuSwvDhq9gHmeCv79kgsfrxPMhfFHJF +SwKwYFsx9knQ== Date: Thu, 29 Oct 2020 14:56:11 +0100 From: Lorenzo Miniero To: Sergio Garcia Murillo Cc: dispatch@ietf.org Message-ID: <20201029145611.66571764@lminiero> In-Reply-To: References: <085505e3-9899-f817-b6df-db8022d52e26@gmail.com> <0E35658D-D768-4DF2-BF0F-95D6F5889B4F@nostrum.com> <566085E5-B555-4314-BCFE-9A03CD082C8E@westhawk.co.uk> Organization: Meetecho X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4wfHkb9W8ib9VbCqm5lZveqkZOWx1Bf2sHBz28h1dRd62D17x+mT2J/js/htBtDXqg2myrTsIcPlwHHuvxJ6vbtup49f5CdQOn6fIxqs6UI3RyQ4DAzb/c LmHIWlhOpe2i7JEQUhtgrTOM1KGzSJ7xTalI509OhlEqtJE4Pmj+Y31j2pts6SHnpO7p6Da/lSgBcUlwJfh0HJJP91Y0qh7Rb9s= Archived-At: Subject: Re: [dispatch] WHIP - WebRTC HTTP ingestion protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 13:56:20 -0000 I personally think the currently proposed approach is fine and simple enough. Going for further simplification may actually complicate things, paradoxically: if we assume some parameters are known already, it means potentially crafting and munging SDPs on the client side if the existing APIs don't allow for such flexibility, which in case of browsers may be suboptimal (not to mention SDP munging may actually not even be possible sooner or later). The alternative would be letting the server offer and the client answer, but that means you can't do it with a single HTTP request as WHIP does now. The only feedback I have is adding the ability to expose a further URL (e.g., something you can send an HTTP DELETE to) to interrupt the ingestion, as I think just relying on ICE and DTLS may not be reliable or quick enough, not to mention the fact that there would be no way to distinguish between a user dropping their connection, and the user actually meaning to close the connection in the first place. Lorenzo On Thu, 29 Oct 2020 14:24:19 +0100 Sergio Garcia Murillo wrote: > Hi Tim, >=20 > I see the merits for an uri-based signal-less and sdp-less setup for=20 > webrtc, specially for p2, in which you could even use datachannel as=20 > control channel for adding and removing tracks later on. However, > that is far beyond the scope of my current draft. >=20 > You say that this may not go far enough, and I could agree to that, > but relying on current SDP O/A mechanism, HTTP and webrtc specs > allows to have simple spec that we can have ready and working really > fast. I agree to add constrains or force usage of certain optional > features defined in other specs to simplify the implementation > complexity on both servers and clients, but if we plan to redefine > SDP I am afraid that we will get into a rabbit hole that will keep us > discussing for months/years. >=20 > As I said, I see the benefits of it, but I would prefer to leave it > out of scope of current WHIP draft spec and if anyone is interested > in leading the work, start an independent draft for that. I will be > willing to collaborate anyway. >=20 > Best regards > Sergio >=20 > On 29/10/2020 12:07, T H Panton wrote: > > My feedback: > > > > 1) this is a good idea - we need something like this. Full webRTC > > O/A is too complex for simple ingestion usecases. > > 2) A URI is an excellent hook to hang this on. > > 3) I don't think it goes far enough. > > > > Almost all of the offer/answer content is redundant, because most > > of it is _known_ by both sides already. > > The ingestion services typically specify what=20 > > codecs/bitrates/framerates they will accept. > > They don't output any media. > > > > I claim we can simplify the O/A to something that looks more like=20 > > RTSP's SDP or even simpler. > > > > - So I support this, but would want to discuss simplification. > > > > Tim. > > =20 > >> On 28 Oct 2020, at 20:10, Ben Campbell >> > wrote: > >> > >> Hi Everyone, > >> > >> Did anyone have feedback or other thoughts on Sergio=E2=80=99s proposa= l? > >> > >> Thanks! > >> > >> Ben. > >> =20 > >>> On Sep 30, 2020, at 5:24 AM, Sergio Garcia Murillo=20 > >>> >>> > wrote: > >>> > >>> Hi all! > >>> > >>> > >>> While WebRTC has been very successful in a wide range of > >>> scenarios, its adaption in the broadcasting/streaming industry is > >>> lagging behind. Currently there is no standard protocol (like SIP > >>> or RTSP) designed for ingesting media in a streaming service, and > >>> content providers still rely heavily on protocols like RTMP for > >>> it. > >>> > >>> These protocols are much older than WebRTC and lack by default > >>> some important security and resilience features provided by > >>> WebRTC with minimal delay. > >>> > >>> The media codecs used in older protocols do not always match > >>> those being used in WebRTC, mandating transcoding on the ingest > >>> node, introducing delay and degrading media quality. This > >>> transcoding step is always present in traditional streaming to > >>> support e.g. ABR, and comes at no cost. However webrtc implements > >>> client-side ABR, by means of simulcast and SVC codecs, which > >>> otherwise alleviate the need for server-side transcoding. Content > >>> protection and Privacy Enhancement can be achieve with End-to-End > >>> Encryption, which preclude any server-side media processing. > >>> > >>> We have been working on a proposal for a simple HTTP based > >>> protocol that will allow WebRTC endpoints to ingest content into > >>> streaming services and/or CDNs to fill this gap and facilitate > >>> deployment: > >>> > >>> * https://tools.ietf.org/html/draft-murillo-whip-00 > >>> * https://github.com/murillo128/webrtc-http-ingest-protocol/ > >>> > >>> > >>> We have already implemented it on Janus and Medooze media servers: > >>> > >>> * https://www.meetecho.com/blog/whip-janus/ > >>> * > >>> https://medium.com/@medooze/whip-webrtc-meets-the-broadcasting-world-= 86772eba8ae7 > >>> > >>> > >>> And added support into a WebRTC version of OBS studio: > >>> > >>> * > >>> https://github.com/CoSMoSoftware/OBS-studio-webrtc/releases/tag/m84v2= 3.2-RC2 > >>> > >>> > >>> We also plan to have an interop session on the next IETF > >>> hackhaton, that will allow to check the interoperability between > >>> different WebRTC implementations. > >>> > >>> > >>> What would be the best way of moving this forward? Obviously, any=20 > >>> feedback will be very welcome. > >>> > >>> > >>> Best regards > >>> > >>> Sergio > >>> > >>> > >>> > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch =20 > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch =20 > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch =20 >=20 >=20 --=20 I'm getting older but, unlike whisky, I'm not getting any better https://twitter.com/elminiero