From nobody Thu Mar 5 03:55:55 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05523A136A for ; Thu, 5 Mar 2020 03:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=gmx.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 xxVWyN0oYNCB for ; Thu, 5 Mar 2020 03:55:45 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 F04343A1398 for ; Thu, 5 Mar 2020 03:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583409341; bh=EC+X6jghGOkcIv8N8NbPZrd6j2S5p0gZ0ey+wMpDxGo=; h=X-UI-Sender-Class:To:From:Subject:Date; b=jR4hDb1MDRSBjt/T2YVK9itjnK0xSjlxdv0/N3g9b20GZN8ZFG4K5EwMwYoMHrfjf 9d0c6MLCvvH9jnXSBtz4EDqVNUto/wxuCl8uZLCLeq9PvNwybZebbKamLiG3h8ReLp 9KWrIMwpiqyaC43fhiA3/E0hSeMbm5lH+d8F9lFY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([217.91.35.233]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mlf4S-1jabKY3Rkg-00ihUo for ; Thu, 05 Mar 2020 12:55:40 +0100 To: "xml2rfc@ietf.org" From: Julian Reschke Message-ID: Date: Thu, 5 Mar 2020 12:55:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:oxWmnMCGjnwuRmNXqclLLNS/oynbDQOEqDNEc3n5xGban3We2QI sC/196LTbBBIC+Anz27nCdEEow7hLq6j/DRMKBmcX6VDoX2yISvWRZYGiLU4P6EqkeKWaye xggkstvhVtFbtas1xdHc1AXlP9NwctsLcr8q7Fswi765oAimqzmpV9Qq89oBCbA5me/6ii0 Xo5t+krWpEsFXYDmRCngw== X-UI-Out-Filterresults: notjunk:1;V03:K0:QRsS0na4+4M=:5IIvjXH6sRx4R0yYctcezQ 5Jt0pJGBdRZd7FJG/mWdacIA6N+rIEtJidXn/HEN4g8GY///MCjmutrXHl8wBcJkfQGzKr6AE QdXklnYpTWtKx9p7yczacO/lWT5w6rTp+i5WOiICJ0p9sC8xFuB1vPnGDyxOkb9jbma3tm+UT W75eYAxgwfwyBL3QJqVXLmykc2eEAWwTMyxr5xkUurOLdyS/enYxql8375So8LtgP5KLyYBro jtj3uCY9DXTRSiCHec6vvEZOgL3T9KL6gtQeT//0DfOPcNiEshu0sLxe6k933CeyV9ClqI/+8 Bw5Z6XRyUCk3ve2MQu8ZVtlPDel4O7J7ogn6RW05DP29HWs4vyys/8+6fl0XEai95IECgTH5n TXs2rdo2NJU9cHsWiFS5ev1tU2AvRlGN/kWQ5/oUTzAWhykdUB4DTt3DjmPD+kBW6FVUO52eI b4n7tpzl94CSpufOak0/r++OD8+ANPRjjZyPNwl8mVvvHZX5hn8irvRSPYo6TT67/WKhFQjN8 w+hbKYsOOD+a+48XVD5no/1cEPqlzF3zUmYT1g+hp01ipMot0YKprUCg3NJqPPSLbCDGIl4SS qOELDBC3kOX/+Me4P9/qeKNZH33N43NWGpmwZ4jY5+U7OvchROX2kssWWF34u5nCmPcom8EMv 4Vwr/eeNr68lbdcWdhM47EQt2/GVma5Bd4mDr9vBYicNBr3SkgiZuhTcvkFm18Nm3Kl29cZGS IqRwsUYACryijKc/fyQHvsTIi/XvZx/1JV5QHg/ED39s2xlNpeWyTgMlo/+RDUD9gqO6Ndwah sZwsqxf0L52AjqGp7YUVLm6hja0Ta5KGR0TQ+NDOIZ4fzmbrBQmrgAh7C/viC9kgO6TZBaLFK ZWvUtmG9YSDXhOIHEFNtuGxEVUd8Zcq3B4A4bFzPF5bid2d00BCNcYFWW3W9Zo8XjX0ts92S8 glBOV5+FIwzjmgRZ/ClpZQObA1FY7I2u5cJ5QVPjlwuH9NTxTnm455wLHCtiS60s8h+JfFjP/ hEWdjblO8573yPxSxcObLNlnPMn8g3dogN+n4CMJpgaRMLmLeqCY9nwm57t1AJfUQ06hk5jvi 1jSwQ9kLyZOoQQEhK5J8xjWJCHhwjAUlHcV1uDk7M8Tw9qbsY1OET3FkowN7S8EnAKudMxY1Y 8PSvBkq3nfdGtm80DHrDh3RDcRi25RsIIqZ3xJJF+xJfXoJepTpt0SU/elmTCPUbOiu2V8VYd yl5Qoz9PKFusKGqoW Archived-At: Subject: [xml2rfc] requests for https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 11:55:52 -0000 Is it just me? > > nslookup xml2rfc.ietf.org > ... > Name: ietf.org > Addresses: 2001:1900:3001:11::2c > 4.31.198.44 > Aliases: xml2rfc.ietf.org HTTP: > > curl http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 100 255 100 255 0 0 255 0 0:00:01 --:--:-- 0:00:01 710 > > > 302 Found > >

Found

>

The document has moved here.

> But with HTTPS: > > curl https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml > % Total % Received % Xferd Average Speed Time Time Time Current > Dload Upload Total Spent Left Speed > 0 0 0 0 0 0 0 0 --:--:-- 0:00:20 --:--:-- 0curl: (7) Failed to connect to xml2rfc.ietf.org port 443: Timed out Best regards, Julian PS: AFAIR, the same happened yesterday at some point of time. From nobody Thu Mar 5 04:01:10 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139333A0CC7 for ; Thu, 5 Mar 2020 04:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZJYc5XaSXMD7 for ; Thu, 5 Mar 2020 04:01:06 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED5F3A0CC9 for ; Thu, 5 Mar 2020 04:01:05 -0800 (PST) Received: from [192.168.217.147] (p5089A9C4.dip0.t-ipconnect.de [80.137.169.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48Y8Tr1btDzyky; Thu, 5 Mar 2020 13:01:04 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: Date: Thu, 5 Mar 2020 13:01:03 +0100 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 605102463.6930521-f34f77e02c7623cc1e34b3b5ae721faa Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] requests for https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 12:01:09 -0000 On 2020-03-05, at 12:55, Julian Reschke wrote: >=20 > Is it just me? WFM Gr=C3=BC=C3=9Fe, Carsten $ curl -LI = http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml HTTP/1.1 302 Found Date: Thu, 05 Mar 2020 12:00:20 GMT Server: Apache Location: = https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml Content-Type: text/html; charset=3Diso-8859-1 HTTP/1.1 200 OK Date: Thu, 05 Mar 2020 12:00:21 GMT Server: Apache/2.2.22 (Debian) Last-Modified: Sat, 29 Feb 2020 22:08:45 GMT ETag: "39c146a-295-59fbe32985540" Accept-Ranges: bytes Content-Length: 661 Content-Type: application/xml From nobody Thu Mar 5 05:02:45 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648093A143E for ; Thu, 5 Mar 2020 05:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=gmx.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 yfG0qPk9n-g6 for ; Thu, 5 Mar 2020 05:02:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 629CD3A143A for ; Thu, 5 Mar 2020 05:02:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583413352; bh=g6Vkg5adf2hbJ6yZ4dVLdwgmJcCYSyq8Ya/BOflCi4g=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=K8/kLtkthvO5Wd5bGVwtbdlFaclKPEc6FrNokDpdDiB78GPWUMbf6ooFuzbVSX6qJ FE3X4xWhQvQ5XrMN9XfuwRLRpZGEBXY4kg5VvJkDSac2OgAJUjVhigVEfzN5nu7YJ1 ERFV3TxU1vnebkYQSmzt9at9dHX07o9iJlWLMyUo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.1.220] ([217.91.35.233]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MysVs-1jWASL3Qtm-00w1BR; Thu, 05 Mar 2020 14:02:31 +0100 To: Carsten Bormann Cc: "xml2rfc@ietf.org" References: From: Julian Reschke Message-ID: <6a1bf477-2c8a-fe60-2934-454c07255e19@gmx.de> Date: Thu, 5 Mar 2020 14:02:28 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:mfRmXrOpfOL/fpc+MJrCkcSiyIKbBrGH/HKM8NoSXVh74KcuTRy iXahjqohFllP50Rz390v1RYWamgxJh8Upp63XAgAT9dUaNUeac2V4bhPFHIJT7olonhI66K O8b2Qc/P09kdGvr/Mw1gva9bnfdbuhh/V0+087wL8auouRrg0/jyW5zWt4FgJIaLMb9ajvy d4dFgd6jQ1GI7Vy/Vdw8A== X-UI-Out-Filterresults: notjunk:1;V03:K0:5+cTOgpToM8=:1oVW6soxyIYFLobDKL/ZZA h6fZOQS6etdJ3FciDIxOsPmlGL8CbGqBwSDxE8yG5TVXvS8ZkC7Pr2nCk7jK2rFIp3DmoXp3R yvYPJAa1yW+/8BEbwtxrK5HTQRdqHu1pLgLdp6EeuDxJ3i8ixt+v+bxh8m7DV7C3AYX0pLYpd nnUqvLqqoZ/ClktJhTvhxYcPmC+I9RwU6SejjeBZqm0bZ9Ra3lhby69sWtqOBlgLUDcFrCpsw 8n/6lyT4D503iAVQpG1CN1lnJFeNoS2A1jaDXcn1TXWwNC1gEwwnq96uB324rRXwg2Te1r4Db s4DBMKrV3RVBXCgDSakMtVJGXHDYTsApE4X9BRyMzQWfWClonH3qeE1sgJrFiXschEVVjsuD8 /OlVC8j+fDj8N0XTOqZkhvJw/gKunuzkcwEbTL3QxkJmExLDgJzp7Kdnj91XQfBdgX7eJ1ls5 NvX8EAQQRhSvrI5+gl6Xr0AghpHaxvMqOgpRVMxTAhgtdMmXwFIz8GJJXCr1Ud56CtVFsPOde 0ob7J0EC62257XOO+nIS7JUZoBK4KRXoyQfqwPRI/dAfqjqjQ9BqsQ/SvllcMPLUPdxy+0lpv eumSWNhlvrsDH14j+wr4sDMA/JM1IihI8SCqyYf6MsdHJ3cyF5KZQHWOMin2HJckH5WAB9EYs ueQuB4U3OoCAfF4+moZDczoDpGFTuvh/iTG7Onm6OWfSkkEXRw6z9VZCFWJzAL2rg/UAxXBkz IkSmKkwa3AgaX/7GcVsZhbb/fVo3bHjsL6bp0+QhVcms1SYIHZZttRQFrf7Q8hfgJrlYx253w f6Phjuy6atNJJ6jTIXei7xQuhkKm7i0umQ+d8VdRQAl24IsDnfd+tPzjaFwYX+ni5PF6+rOk/ 5MgRN7PEWLlj2oL0PPNlUUmFDfpm37dPeP9BW6Dm/Hmzl0blapHQ+B99YHuMIcK3nY5mOeywD luvfibQHf7nDp41QNzztSfy0wUnqBPR/ZhaYotweXPJhfoV0zmpUPl8G9vL8YRYyZyXwc9jPs xU7JM9ZPvYDeoO1hFlxrfTJrvF8TKNRfojBG0FmtZfxEnzMGTpUG7hA2Id80jVmVwvVdNjeeS 8qrg7XFcepvNd5CUKpcuetA6sxCw+E3dgsaIr+r3dLpUCN/iN/zkCKgnw0Pspm4iC6Z2XKdRS gV6Ht2tqbDF4WuX2EKqLHi/McImE6R8D7s8qB6B3XPdFfWoFuysyr/8AuzhaREc7TU5/AB6aT 5FW5w4eypRqpuJR1r Archived-At: Subject: Re: [xml2rfc] requests for https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 13:02:44 -0000 On 05.03.2020 13:01, Carsten Bormann wrote: > On 2020-03-05, at 12:55, Julian Reschke wrote: >> >> Is it just me? > > WFM > > Gr=C3=BC=C3=9Fe, Carsten > > $ curl -LI http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.= xml > HTTP/1.1 302 Found > Date: Thu, 05 Mar 2020 12:00:20 GMT > Server: Apache > Location: https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC= .5652.xml > Content-Type: text/html; charset=3Diso-8859-1 > > HTTP/1.1 200 OK > Date: Thu, 05 Mar 2020 12:00:21 GMT > Server: Apache/2.2.22 (Debian) > Last-Modified: Sat, 29 Feb 2020 22:08:45 GMT > ETag: "39c146a-295-59fbe32985540" > Accept-Ranges: bytes > Content-Length: 661 > Content-Type: application/xml Hm. 4.31.198.44 fails for me (that's what DNS gives me). 4.31.198.61 works (that's that Firefox sees for some reason). Best regards, Julian From nobody Thu Mar 5 05:11:45 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1C93A1463 for ; Thu, 5 Mar 2020 05:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GHYxhYpZEuYW for ; Thu, 5 Mar 2020 05:11:41 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58D253A0DEE for ; Thu, 5 Mar 2020 05:11:41 -0800 (PST) Received: from [192.168.217.147] (p5089A9C4.dip0.t-ipconnect.de [80.137.169.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48YB3H4hsbzytC; Thu, 5 Mar 2020 14:11:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <6a1bf477-2c8a-fe60-2934-454c07255e19@gmx.de> Date: Thu, 5 Mar 2020 14:11:38 +0100 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 605106698.7743-f1b97c1d3a344a2d69f751f63d7574ff Content-Transfer-Encoding: quoted-printable Message-Id: <32DA86EA-9137-4501-88DB-9C7DB2DD11CE@tzi.org> References: <6a1bf477-2c8a-fe60-2934-454c07255e19@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] requests for https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml timing out X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2020 13:11:44 -0000 > 4.31.198.44 fails for me (that's what DNS gives me). 4.31.198.61 works > (that's that Firefox sees for some reason). Does anyone know of a curl/wget-like tool that actually tries all the = DNS results for a URI? Like happy eyeballs, but for all addresses. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 8 14:42:46 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A453A07A0 for ; Sun, 8 Mar 2020 14:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 ZlomAXnKqER3 for ; Sun, 8 Mar 2020 14:42:42 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0EA83A078B for ; Sun, 8 Mar 2020 14:42:42 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:b43e:c732:2dc8:7e2a] (unknown [IPv6:2a02:8109:1140:c3d:b43e:c732:2dc8:7e2a]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 96CB3721E280D for ; Sun, 8 Mar 2020 22:42:38 +0100 (CET) From: Michael Tuexen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Message-Id: Date: Sun, 8 Mar 2020 22:42:38 +0100 To: "xml2rfc@ietf.org" X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2020 21:42:45 -0000 Dear all, I'm in the process of converting an Internet Draft from xml v2 to v3 and = found some issues using the translator from = http://xml2rfc.tools.ietf.org/experimental.html: * When not having the docName attribute in , the tool is = complaining that this attribute is missing. According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it is = deprecated. * When not specifying the submissionType attribute in , the tool = is complaining that this attribute is missing. According to https://tools.ietf.org/html/rfc7991#section-2.45.12 the = default is "IETF", so my understanding is that I don't need to specify it when I want to = use IETF. * When not having a category attribute in , the tool is stopping = processing because "Expected a valid category for submissionType=3D'IETF', one of = std,info,historic,bcp,exp, but found 'None'" According to https://tools.ietf.org/html/rfc7991#section-2.45.1 this = is deprecated. It refers to using the , where "Internet-Draft" would be = acceptable. * When using instead of I would expect in the plaintext or v3-plaintext output the ASCII = representation being used. However, the umlauts do appear, so the generate text is not ASCII. That the umlauts appear in the HTML output is expected and works. * When using
, which should be OK according to https://tools.ietf.org/html/rfc7991#section-2.20.2 the translator responds with "Error: Invalid attribute hanging for = element dl, at /rfc/middle/section[3]/dl" Since this is my first usage of v3, it is possible that some of the = issues above are related to mistakes made by me. Any comments appreciated. Best regards Michael From nobody Mon Mar 9 05:19:41 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF0B3A0E6B for ; Mon, 9 Mar 2020 05:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmRzE0Hhldb3 for ; Mon, 9 Mar 2020 05:19:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B513A0E91 for ; Mon, 9 Mar 2020 05:19:23 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:64531 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jBHMz-0002GJ-LJ; Mon, 09 Mar 2020 05:19:23 -0700 To: Michael Tuexen , "xml2rfc@ietf.org" References: From: Henrik Levkowetz Message-ID: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> Date: Mon, 9 Mar 2020 13:18:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wGKHqhwe1BMrNAOqRi5wQnKqH0DBloRSn" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, michael.tuexen@lurchi.franken.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 12:19:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wGKHqhwe1BMrNAOqRi5wQnKqH0DBloRSn Content-Type: multipart/mixed; boundary="vAiufV1SV2vIUFB3MIFVcuwMAfgthSfUu"; protected-headers="v1" From: Henrik Levkowetz To: Michael Tuexen , "xml2rfc@ietf.org" Message-ID: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> Subject: Re: [xml2rfc] v3 questions/comments References: In-Reply-To: --vAiufV1SV2vIUFB3MIFVcuwMAfgthSfUu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 2020-03-08 22:42, Michael Tuexen wrote: > Dear all, >=20 > I'm in the process of converting an Internet Draft from xml v2 to v3 an= d found some issues > using the translator from http://xml2rfc.tools.ietf.org/experimental.ht= ml: >=20 > * When not having the docName attribute in , the tool is complain= ing that this attribute is missing. > According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it is= deprecated. Yes. It was always expected that implementation and use would require a 7991bis. I assembled some of my implementation notes in=20 https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not= es . This point and the third point below are similar in this respect, and ref= lect some of the changes that have been made after 7991. =20 > * When not specifying the submissionType attribute in , the tool = is complaining that > this attribute is missing. > According to https://tools.ietf.org/html/rfc7991#section-2.45.12 the = default is "IETF", > so my understanding is that I don't need to specify it when I want to= use IETF. This may be the case for the v3 output, but the v2v3 converter needs it t= o make sure that the output is correct. > * When not having a category attribute in , the tool is stopping = processing because > "Expected a valid category for submissionType=3D'IETF', one of std,in= fo,historic,bcp,exp, but found 'None'" > According to https://tools.ietf.org/html/rfc7991#section-2.45.1 this = is deprecated. > It refers to using the , where "Internet-Draft" would be= acceptable. >=20 > * When using > instead of > I would expect in the plaintext or v3-plaintext output the ASCII repr= esentation being used. > However, the umlauts do appear, so the generate text is not ASCII. > That the umlauts appear in the HTML output is expected and works. Non-ASCII is now accepable also in .txt format too, so this should be OK.= > * When using
, which should be OK according to > https://tools.ietf.org/html/rfc7991#section-2.20.2 > the translator responds with "Error: Invalid attribute hanging for el= ement dl, at /rfc/middle/section[3]/dl" I will need your v2 XML source to debug this; could you send it, please? > Since this is my first usage of v3, it is possible that some of the > issues above are related to mistakes made by me. Things look mostly the way they should, except for the
error, which I'd like to debug. Best regards, Henrik --vAiufV1SV2vIUFB3MIFVcuwMAfgthSfUu-- --wGKHqhwe1BMrNAOqRi5wQnKqH0DBloRSn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5mNCYACgkQTptXS4+7 FxoNmhAApmOpQo2dvoQEWAh9MnwbXymIaQrBzTJELA5loJpJu+ydoQg8gqj/t6Xe EMqRX+jYodciYHQRnmd6+z/TJalaPw3/RaKfN47l/Ngjtc/O5c2qHatlVLUx7qqH /jAQD+LUytjkTK+9Hlh4/Vo1hUJLwnRrbvDTFGH2K2M+mhf4cR7u/VfRdwog6joZ KAnSye1ZKyTMpVMYAYFnMCAu8GdC4st4/1wkEovQdGk7Pi3cHsZB8RgHiTKPnA6P to6qhq+9jNFlvtRCCOe3VkTCF/rMtWR1eSbeEaxh7MmYWkZo10x8N7Sd4hchitQk XYuKKwCzVlut/9diuXVS946OCvKjsWUHzAnkFEp5CATO5psz4XMZdu0Pcrj7hhw6 bdUxB9opjNsW3SUVnpOsQ82MFtkya9d/2FqXNaOkqW29jhkgYN85Y1hYij4YpO9c i1CWyhj/TPii2PrwvFgSh83NeAPWpfqPjBF1JqWLZoMe2eoPTgJmza3uiCpuj1eA wgrVJcyEt3tAh/arcZEvlak0j+1HQSvZ+SJ7G4kwR0/QWfh9m9SmXCeSLlcg9wME T2YK3HbtHY9mTsJ3q4IMVpV+zuKrZv9RRcqNN09kL7R190POCZOtVAgg8hmzg22V UDeKwuO3ECGDfEx8BX+pPHP5W/9+ivhU4Wm85S5Fvy1PZ3/qAa4= =ZBdg -----END PGP SIGNATURE----- --wGKHqhwe1BMrNAOqRi5wQnKqH0DBloRSn-- From nobody Mon Mar 9 06:18:02 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9993A0F99 for ; Mon, 9 Mar 2020 06:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 Fbu72gBdoDvM for ; Mon, 9 Mar 2020 06:17:49 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D573A0F8F for ; Mon, 9 Mar 2020 06:17:48 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931] (unknown [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 9C4E0721E2829; Mon, 9 Mar 2020 14:17:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> Date: Mon, 9 Mar 2020 14:17:44 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 13:18:01 -0000 > On 9. Mar 2020, at 13:18, Henrik Levkowetz = wrote: >=20 > Hi Michael, >=20 > On 2020-03-08 22:42, Michael Tuexen wrote: >> Dear all, >>=20 >> I'm in the process of converting an Internet Draft from xml v2 to v3 = and found some issues >> using the translator from = http://xml2rfc.tools.ietf.org/experimental.html: >>=20 >> * When not having the docName attribute in , the tool is = complaining that this attribute is missing. >> According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it = is deprecated. >=20 > Yes. It was always expected that implementation and use would require = a > 7991bis. I assembled some of my implementation notes in=20 > = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-note= s . >=20 > This point and the third point below are similar in this respect, and = reflect > some of the changes that have been made after 7991. =20 OK. Wouldn't it make sense to file an errata for this? >=20 >> * When not specifying the submissionType attribute in , the = tool is complaining that >> this attribute is missing. >> According to https://tools.ietf.org/html/rfc7991#section-2.45.12 the = default is "IETF", >> so my understanding is that I don't need to specify it when I want = to use IETF. >=20 > This may be the case for the v3 output, but the v2v3 converter needs = it to > make sure that the output is correct. OK. Not critical, since it is a warning. >=20 >> * When not having a category attribute in , the tool is = stopping processing because >> "Expected a valid category for submissionType=3D'IETF', one of = std,info,historic,bcp,exp, but found 'None'" >> According to https://tools.ietf.org/html/rfc7991#section-2.45.1 this = is deprecated. >> It refers to using the , where "Internet-Draft" would = be acceptable. >>=20 >> * When using >> instead of >> I would expect in the plaintext or v3-plaintext output the ASCII = representation being used. >> However, the umlauts do appear, so the generate text is not ASCII. >> That the umlauts appear in the HTML output is expected and works. >=20 > Non-ASCII is now accepable also in .txt format too, so this should be = OK. Ahh, I see. UTF-8 is now the format. What is then the intention of the = asciiSurname? >=20 >=20 >> * When using
, which should be OK according to >> https://tools.ietf.org/html/rfc7991#section-2.20.2 >> the translator responds with "Error: Invalid attribute hanging for = element dl, at /rfc/middle/section[3]/dl" >=20 > I will need your v2 XML source to debug this; could you send it, = please? >=20 >> Since this is my first usage of v3, it is possible that some of the >> issues above are related to mistakes made by me. >=20 > Things look mostly the way they should, except for the
error, = which > I'd like to debug. Sent to you offlist. Best regards Michael >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 From nobody Mon Mar 9 07:09:55 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F583A1076 for ; Mon, 9 Mar 2020 07:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kZirJYYkbH4m for ; Mon, 9 Mar 2020 07:09:50 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB223A1071 for ; Mon, 9 Mar 2020 07:09:50 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:65009 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jBJ5K-00020l-QN; Mon, 09 Mar 2020 07:09:29 -0700 To: Michael Tuexen References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> Cc: "xml2rfc@ietf.org" From: Henrik Levkowetz Message-ID: <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> Date: Mon, 9 Mar 2020 15:08:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XCAeEUGjkKpaSO4xtgT9K8n70gCFxOPBS" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, michael.tuexen@lurchi.franken.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 14:09:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XCAeEUGjkKpaSO4xtgT9K8n70gCFxOPBS Content-Type: multipart/mixed; boundary="NKKpHivc6OcPeeKB41AInH47XiOVfeocu"; protected-headers="v1" From: Henrik Levkowetz To: Michael Tuexen Cc: "xml2rfc@ietf.org" Message-ID: <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> Subject: Re: [xml2rfc] v3 questions/comments References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> In-Reply-To: <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> --NKKpHivc6OcPeeKB41AInH47XiOVfeocu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 2020-03-09 14:17, Michael Tuexen wrote: >=20 >=20 >> On 9. Mar 2020, at 13:18, Henrik Levkowetz wrot= e: >>=20 >> Hi Michael, >>=20 >> On 2020-03-08 22:42, Michael Tuexen wrote: >>> Dear all, >>>=20 >>> I'm in the process of converting an Internet Draft from xml v2 to v3 = and found some issues >>> using the translator from http://xml2rfc.tools.ietf.org/experimental.= html: >>>=20 >>> * When not having the docName attribute in , the tool is compla= ining that this attribute is missing. >>> According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it i= s deprecated. >>=20 >> Yes. It was always expected that implementation and use would require= a >> 7991bis. I assembled some of my implementation notes in=20 >> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-= notes . >>=20 >> This point and the third point below are similar in this respect, and = reflect >> some of the changes that have been made after 7991. =20 > OK. Wouldn't it make sense to file an errata for this? Not at the moment; these will eventually be captured in a 7991bis documen= t. >>=20 >>> * When not specifying the submissionType attribute in , the too= l is complaining that >>> this attribute is missing. >>> According to https://tools.ietf.org/html/rfc7991#section-2.45.12 the= default is "IETF", >>> so my understanding is that I don't need to specify it when I want t= o use IETF. >>=20 >> This may be the case for the v3 output, but the v2v3 converter needs i= t to >> make sure that the output is correct. > OK. Not critical, since it is a warning. >>=20 >>> * When not having a category attribute in , the tool is stoppin= g processing because >>> "Expected a valid category for submissionType=3D'IETF', one of std,i= nfo,historic,bcp,exp, but found 'None'" >>> According to https://tools.ietf.org/html/rfc7991#section-2.45.1 this= is deprecated. >>> It refers to using the , where "Internet-Draft" would b= e acceptable. >>>=20 >>> * When using >>> instead of >>> I would expect in the plaintext or v3-plaintext output the ASCII rep= resentation being used. >>> However, the umlauts do appear, so the generate text is not ASCII. >>> That the umlauts appear in the HTML output is expected and works. >>=20 >> Non-ASCII is now accepable also in .txt format too, so this should be = OK. > Ahh, I see. UTF-8 is now the format. What is then the intention of > the asciiSurname? If the non-ASCII surname contains characters outside the Latin script blo= ck, it is used within parentheses, see https://www.rfc-editor.org/rfc/rfc8694= =2Etxt . For surnames that use all Latin script characters, the asciiSurname has n= o function. Input during implementation of the new format indicated that common paper publication practice was to render Latin script names as-is,= without ASCIIfication. =20 >>=20 >>> * When using
, which should be OK according to >>> https://tools.ietf.org/html/rfc7991#section-2.20.2 >>> the translator responds with "Error: Invalid attribute hanging for e= lement dl, at /rfc/middle/section[3]/dl" >>=20 >> I will need your v2 XML source to debug this; could you send it, pleas= e? Received; thanks. Best regards, Henrik >>> Since this is my first usage of v3, it is possible that some of the >>> issues above are related to mistakes made by me. >>=20 >> Things look mostly the way they should, except for the
error, whi= ch >> I'd like to debug. > Sent to you offlist. >=20 > Best regards > Michael >>=20 >>=20 >> Best regards, >>=20 >> Henrik >>=20 >>=20 >=20 >=20 --NKKpHivc6OcPeeKB41AInH47XiOVfeocu-- --XCAeEUGjkKpaSO4xtgT9K8n70gCFxOPBS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5mTeIACgkQTptXS4+7 FxoF+g//efJwI1dsJxL1VQKZL0yJBNBexkJE95HHxICPjzHSf96UGk2lbLF83QNk YPfX9m57wd5QEwV+hrFWV/EDRhIPEQyGneGELQpzIN9SMhbARwW18Ug0oC/JjghJ LOKeqE4KiRseqFqNWbwegBEUVQYKV555sFQwItvuo0AhSV6b61zMD2jjwD48bv/T Tqns07LeYl04O3niyNcBAfKAko+MtgrLMElUMnQGGgEAaEc5G9DE7H8/DVp7jlDu RBGIOOcLdamJ2wiIZysJJoSLl34mJlrL5VvxdhopUEKo8ZZnz05OSIY5FU+rzfyr 2hf61j1IETmosY/AVR3vZ1KYlIx7RC3s+WC7imgc1LozFU8Rf7Jj1PAH8JskG+YY vkirBKFtj9IxaX2uIx/JhtLO9/5L4Tdj/rrQHbVgNDIskT2aEl+/0j860sNIVJyN 1ooradtmgev7ZYekYFg134wpp6X+4QPwDyHdrGm4rOEymX1VPvctsjV1Gd7qkCRl lui0HxjZOmZ/ENc9QycFchwpYkk8Sm2H1FckYT4xtbyve8RDx3Pcwc/dN9s1ARUR KC8JclESaZiu1Ig6Mgh0b6ozzq+8y2bsQQB6MrdKJYJTIFYHMGUqKG5HBIoOrSrN wLdFgH72nl5jcJkApxwoucfqC0aSDMLrLMxwcHvc85XwKBc7RAo= =GjxY -----END PGP SIGNATURE----- --XCAeEUGjkKpaSO4xtgT9K8n70gCFxOPBS-- From nobody Mon Mar 9 07:39:16 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125923A115C for ; Mon, 9 Mar 2020 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 Y_IlknCOg0vs for ; Mon, 9 Mar 2020 07:39:04 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA473A1180 for ; Mon, 9 Mar 2020 07:39:03 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931] (unknown [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id B47D57213B000; Mon, 9 Mar 2020 15:38:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> Date: Mon, 9 Mar 2020 15:38:58 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 14:39:08 -0000 > On 9. Mar 2020, at 15:08, Henrik Levkowetz = wrote: >=20 > Hi Michael, >=20 > On 2020-03-09 14:17, Michael Tuexen wrote: >>=20 >>=20 >>> On 9. Mar 2020, at 13:18, Henrik Levkowetz = wrote: >>>=20 >>> Hi Michael, >>>=20 >>> On 2020-03-08 22:42, Michael Tuexen wrote: >>>> Dear all, >>>>=20 >>>> I'm in the process of converting an Internet Draft from xml v2 to = v3 and found some issues >>>> using the translator from = http://xml2rfc.tools.ietf.org/experimental.html: >>>>=20 >>>> * When not having the docName attribute in , the tool is = complaining that this attribute is missing. >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it = is deprecated. >>>=20 >>> Yes. It was always expected that implementation and use would = require a >>> 7991bis. I assembled some of my implementation notes in=20 >>> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-note= s . >>>=20 >>> This point and the third point below are similar in this respect, = and reflect >>> some of the changes that have been made after 7991. =20 >> OK. Wouldn't it make sense to file an errata for this? >=20 > Not at the moment; these will eventually be captured in a 7991bis = document. OK. >=20 >>>=20 >>>> * When not specifying the submissionType attribute in , the = tool is complaining that >>>> this attribute is missing. >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.12 = the default is "IETF", >>>> so my understanding is that I don't need to specify it when I want = to use IETF. >>>=20 >>> This may be the case for the v3 output, but the v2v3 converter needs = it to >>> make sure that the output is correct. >> OK. Not critical, since it is a warning. >>>=20 >>>> * When not having a category attribute in , the tool is = stopping processing because >>>> "Expected a valid category for submissionType=3D'IETF', one of = std,info,historic,bcp,exp, but found 'None'" >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.1 = this is deprecated. >>>> It refers to using the , where "Internet-Draft" would = be acceptable. >>>>=20 >>>> * When using >>>> instead of >>>> I would expect in the plaintext or v3-plaintext output the ASCII = representation being used. >>>> However, the umlauts do appear, so the generate text is not ASCII. >>>> That the umlauts appear in the HTML output is expected and works. >>>=20 >>> Non-ASCII is now accepable also in .txt format too, so this should = be OK. >> Ahh, I see. UTF-8 is now the format. What is then the intention of >> the asciiSurname? >=20 > If the non-ASCII surname contains characters outside the Latin script = block, > it is used within parentheses, see = https://www.rfc-editor.org/rfc/rfc8694.txt . > For surnames that use all Latin script characters, the asciiSurname = has no > function. Input during implementation of the new format indicated = that > common paper publication practice was to render Latin script names = as-is, > without ASCIIfication. Thanks for the clarification. >=20 >>>=20 >>>> * When using
, which should be OK according = to >>>> https://tools.ietf.org/html/rfc7991#section-2.20.2 >>>> the translator responds with "Error: Invalid attribute hanging for = element dl, at /rfc/middle/section[3]/dl" >>>=20 >>> I will need your v2 XML source to debug this; could you send it, = please? >=20 > Received; thanks. Let me know if you have any comments/questions. Best regards Michael >=20 >=20 > Best regards, >=20 > Henrik >=20 >>>> Since this is my first usage of v3, it is possible that some of the >>>> issues above are related to mistakes made by me. >>>=20 >>> Things look mostly the way they should, except for the
error, = which >>> I'd like to debug. >> Sent to you offlist. >>=20 >> Best regards >> Michael >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Henrik >>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Mon Mar 9 11:22:26 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D7A3A14E2 for ; Mon, 9 Mar 2020 11:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 oHpajamjVGMM for ; Mon, 9 Mar 2020 11:22:15 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6653A14C0 for ; Mon, 9 Mar 2020 11:22:14 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931] (unknown [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 93BB6721E2821; Mon, 9 Mar 2020 19:22:11 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> Date: Mon, 9 Mar 2020 19:22:10 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4ED4EE21-8C63-459A-81FA-BC06448BA95C@lurchi.franken.de> References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 18:22:25 -0000 > On 9. Mar 2020, at 15:08, Henrik Levkowetz = wrote: >=20 > Hi Michael, >=20 > On 2020-03-09 14:17, Michael Tuexen wrote: >>=20 >>=20 >>> On 9. Mar 2020, at 13:18, Henrik Levkowetz = wrote: >>>=20 >>> Hi Michael, >>>=20 >>> On 2020-03-08 22:42, Michael Tuexen wrote: >>>> Dear all, >>>>=20 >>>> I'm in the process of converting an Internet Draft from xml v2 to = v3 and found some issues >>>> using the translator from = http://xml2rfc.tools.ietf.org/experimental.html: >>>>=20 >>>> * When not having the docName attribute in , the tool is = complaining that this attribute is missing. >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it = is deprecated. >>>=20 >>> Yes. It was always expected that implementation and use would = require a >>> 7991bis. I assembled some of my implementation notes in=20 >>> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-note= s . >>>=20 >>> This point and the third point below are similar in this respect, = and reflect >>> some of the changes that have been made after 7991. =20 >> OK. Wouldn't it make sense to file an errata for this? >=20 > Not at the moment; these will eventually be captured in a 7991bis = document. >=20 >>>=20 >>>> * When not specifying the submissionType attribute in , the = tool is complaining that >>>> this attribute is missing. >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.12 = the default is "IETF", >>>> so my understanding is that I don't need to specify it when I want = to use IETF. >>>=20 >>> This may be the case for the v3 output, but the v2v3 converter needs = it to >>> make sure that the output is correct. >> OK. Not critical, since it is a warning. >>>=20 >>>> * When not having a category attribute in , the tool is = stopping processing because >>>> "Expected a valid category for submissionType=3D'IETF', one of = std,info,historic,bcp,exp, but found 'None'" >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.1 = this is deprecated. >>>> It refers to using the , where "Internet-Draft" would = be acceptable. >>>>=20 >>>> * When using >>>> instead of >>>> I would expect in the plaintext or v3-plaintext output the ASCII = representation being used. >>>> However, the umlauts do appear, so the generate text is not ASCII. >>>> That the umlauts appear in the HTML output is expected and works. >>>=20 >>> Non-ASCII is now accepable also in .txt format too, so this should = be OK. >> Ahh, I see. UTF-8 is now the format. What is then the intention of >> the asciiSurname? >=20 > If the non-ASCII surname contains characters outside the Latin script = block, > it is used within parentheses, see = https://www.rfc-editor.org/rfc/rfc8694.txt . > For surnames that use all Latin script characters, the asciiSurname = has no > function. Input during implementation of the new format indicated = that > common paper publication practice was to render Latin script names = as-is, > without ASCIIfication. OK. I now used the umlauts. When submitting the I-D, the Idnits tool = warns: Checking nits according to = https://www.ietf.org/id-info/1id-guidelines.txt: = --------------------------------------------------------------------------= -- =3D=3D There are 7 instances of lines with non-ascii characters in the = document. Should it be relaxed? Best regards Michael >=20 >>>=20 >>>> * When using
, which should be OK according = to >>>> https://tools.ietf.org/html/rfc7991#section-2.20.2 >>>> the translator responds with "Error: Invalid attribute hanging for = element dl, at /rfc/middle/section[3]/dl" >>>=20 >>> I will need your v2 XML source to debug this; could you send it, = please? >=20 > Received; thanks. >=20 >=20 > Best regards, >=20 > Henrik >=20 >>>> Since this is my first usage of v3, it is possible that some of the >>>> issues above are related to mistakes made by me. >>>=20 >>> Things look mostly the way they should, except for the
error, = which >>> I'd like to debug. >> Sent to you offlist. >>=20 >> Best regards >> Michael >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Henrik >>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Mon Mar 9 11:24:41 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE763A0DDA for ; Mon, 9 Mar 2020 11:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 RRMRJTb3eaSw for ; Mon, 9 Mar 2020 11:24:36 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0C43A14B9 for ; Mon, 9 Mar 2020 11:24:35 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931] (unknown [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 0610C721E2821; Mon, 9 Mar 2020 19:24:31 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> Date: Mon, 9 Mar 2020 19:24:31 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7C8FD44F-E65E-4FED-B956-1A066C2F9232@lurchi.franken.de> References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 18:24:39 -0000 > On 9. Mar 2020, at 15:08, Henrik Levkowetz = wrote: >=20 > Hi Michael, >=20 > On 2020-03-09 14:17, Michael Tuexen wrote: >>=20 >>=20 >>> On 9. Mar 2020, at 13:18, Henrik Levkowetz = wrote: >>>=20 >>> Hi Michael, >>>=20 >>> On 2020-03-08 22:42, Michael Tuexen wrote: >>>> Dear all, >>>>=20 >>>> I'm in the process of converting an Internet Draft from xml v2 to = v3 and found some issues >>>> using the translator from = http://xml2rfc.tools.ietf.org/experimental.html: >>>>=20 >>>> * When not having the docName attribute in , the tool is = complaining that this attribute is missing. >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.3 it = is deprecated. >>>=20 >>> Yes. It was always expected that implementation and use would = require a >>> 7991bis. I assembled some of my implementation notes in=20 >>> = https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-note= s . >>>=20 >>> This point and the third point below are similar in this respect, = and reflect >>> some of the changes that have been made after 7991. =20 >> OK. Wouldn't it make sense to file an errata for this? >=20 > Not at the moment; these will eventually be captured in a 7991bis = document. >=20 >>>=20 >>>> * When not specifying the submissionType attribute in , the = tool is complaining that >>>> this attribute is missing. >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.12 = the default is "IETF", >>>> so my understanding is that I don't need to specify it when I want = to use IETF. >>>=20 >>> This may be the case for the v3 output, but the v2v3 converter needs = it to >>> make sure that the output is correct. >> OK. Not critical, since it is a warning. >>>=20 >>>> * When not having a category attribute in , the tool is = stopping processing because >>>> "Expected a valid category for submissionType=3D'IETF', one of = std,info,historic,bcp,exp, but found 'None'" >>>> According to https://tools.ietf.org/html/rfc7991#section-2.45.1 = this is deprecated. >>>> It refers to using the , where "Internet-Draft" would = be acceptable. >>>>=20 >>>> * When using >>>> instead of >>>> I would expect in the plaintext or v3-plaintext output the ASCII = representation being used. >>>> However, the umlauts do appear, so the generate text is not ASCII. >>>> That the umlauts appear in the HTML output is expected and works. >>>=20 >>> Non-ASCII is now accepable also in .txt format too, so this should = be OK. >> Ahh, I see. UTF-8 is now the format. What is then the intention of >> the asciiSurname? >=20 > If the non-ASCII surname contains characters outside the Latin script = block, > it is used within parentheses, see = https://www.rfc-editor.org/rfc/rfc8694.txt . > For surnames that use all Latin script characters, the asciiSurname = has no > function. Input during implementation of the new format indicated = that > common paper publication practice was to render Latin script names = as-is, > without ASCIIfication. ... and I can't submit an update with changing my Name from Tuexen to = T=C3=BCxen. I think the tool thinks the submitter has changed although the e-mail = address stayed the same. So not using Umlauts for now... Best regards Michael >=20 >>>=20 >>>> * When using
, which should be OK according = to >>>> https://tools.ietf.org/html/rfc7991#section-2.20.2 >>>> the translator responds with "Error: Invalid attribute hanging for = element dl, at /rfc/middle/section[3]/dl" >>>=20 >>> I will need your v2 XML source to debug this; could you send it, = please? >=20 > Received; thanks. >=20 >=20 > Best regards, >=20 > Henrik >=20 >>>> Since this is my first usage of v3, it is possible that some of the >>>> issues above are related to mistakes made by me. >>>=20 >>> Things look mostly the way they should, except for the
error, = which >>> I'd like to debug. >> Sent to you offlist. >>=20 >> Best regards >> Michael >>>=20 >>>=20 >>> Best regards, >>>=20 >>> Henrik >>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Mon Mar 9 11:41:35 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43B9B3A155E for ; Mon, 9 Mar 2020 11:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Qp0zPDh6Kgbl for ; Mon, 9 Mar 2020 11:41:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE8E3A1551 for ; Mon, 9 Mar 2020 11:41:23 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:49712 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jBNKo-0000oO-4i; Mon, 09 Mar 2020 11:41:22 -0700 To: Michael Tuexen References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> <7C8FD44F-E65E-4FED-B956-1A066C2F9232@lurchi.franken.de> Cc: "xml2rfc@ietf.org" From: Henrik Levkowetz Message-ID: <3eb33245-8a49-dbcc-2869-ca5f9c414455@levkowetz.com> Date: Mon, 9 Mar 2020 19:40:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7C8FD44F-E65E-4FED-B956-1A066C2F9232@lurchi.franken.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ArCad8BnrANRtTXRDLMmrBgxcxfQMH11L" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, michael.tuexen@lurchi.franken.de X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 18:41:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ArCad8BnrANRtTXRDLMmrBgxcxfQMH11L Content-Type: multipart/mixed; boundary="T2McIT3Johkf7iR5DtvgtEVsa3x4qPR82"; protected-headers="v1" From: Henrik Levkowetz To: Michael Tuexen Cc: "xml2rfc@ietf.org" Message-ID: <3eb33245-8a49-dbcc-2869-ca5f9c414455@levkowetz.com> Subject: Re: [xml2rfc] v3 questions/comments References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> <7C8FD44F-E65E-4FED-B956-1A066C2F9232@lurchi.franken.de> In-Reply-To: <7C8FD44F-E65E-4FED-B956-1A066C2F9232@lurchi.franken.de> --T2McIT3Johkf7iR5DtvgtEVsa3x4qPR82 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 2020-03-09 19:24, Michael Tuexen wrote: >> If the non-ASCII surname contains characters outside the Latin script = block, >> it is used within parentheses, see https://www.rfc-editor.org/rfc/rfc8= 694.txt . >> For surnames that use all Latin script characters, the asciiSurname ha= s no >> function. Input during implementation of the new format indicated tha= t >> common paper publication practice was to render Latin script names as-= is, >> without ASCIIfication. > ... and I can't submit an update with changing my Name from Tuexen to T= =C3=BCxen. > I think the tool thinks the submitter has changed although the e-mail a= ddress > stayed the same. So not using Umlauts for now... Huh. And that's actually unexpected. Could you send me the XML which was not accepted, for debugging, please? Best regards, Henrik --T2McIT3Johkf7iR5DtvgtEVsa3x4qPR82-- --ArCad8BnrANRtTXRDLMmrBgxcxfQMH11L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5mjbQACgkQTptXS4+7 Fxp8uQ/9Guo8ervXVuNqyxm3mDNsUT8Tfv7GZTZFhqC1APPxsOsnmUIFzmqIGGkt qUAQnTfFaNwAp0JCuUSeH54ZxlZjI8HbCM6U9nFlYAfiQjk5qEAR3eSAAvAu/7Wi B+SpuXRFtgEEKrFmE9KIod6EXWmST3e4DEIY0hdaYduyNcLFOGX9jbbHf2lTh63B kHR3yYwsFlqi00ENQRHc56dP3+fqDutIcIr5kTD8rMDmEFGX5M0GSOeKIq8+Cic2 Hu1uhkjpHQJ5HF1iQPOZU4FtpfQXqbIn7myQA4pBBy+YmPi8Xo1blyQQhBZ22PAr +ndMqHy1dAL3x3/u2/mj+PqcefgjAVR1MwwKI98em+tN/h41Ea2zvOEZAb0z1Dst 1K9lqbpfDHqnd/8BsCCFgCVUHc/BKGXFWqQiVw70UoeLkQA9GXvZ3ZF+HnmrO/4G P3e/Ydm2FrCQBM5tyk2lw3DlNvGeJnoS6y8pmo2fjC0/rvkIVdWh00Rb7Ej0P4Q2 Mj/qqkC+nQDqEsQRBYm7UvhOWomku/SCP+nya7cxbnfR/bD/jy141jGMNkcV0Mt7 ADCJKfjiZ056OUkO5xwIGkM7/I3rf4N4RP97ni2etS77KZmsFi+50nXvo0y7v3UC cM75mFOeORMldIg7Yz9FI3tD1dWJwFqg635IuXfDgqS3EWakIvQ= =X6M1 -----END PGP SIGNATURE----- --ArCad8BnrANRtTXRDLMmrBgxcxfQMH11L-- From nobody Mon Mar 9 11:56:17 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBFF3A15C5 for ; Mon, 9 Mar 2020 11:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 9D65c9yDVKyM for ; Mon, 9 Mar 2020 11:56:07 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23003A1710 for ; Mon, 9 Mar 2020 11:55:15 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931] (unknown [IPv6:2a02:8109:1140:c3d:fcad:c4b5:d3f7:931]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 1B511721E2821; Mon, 9 Mar 2020 19:55:12 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: <3eb33245-8a49-dbcc-2869-ca5f9c414455@levkowetz.com> Date: Mon, 9 Mar 2020 19:55:11 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <9C6B6715-E703-4A46-9932-0363EF2C6C95@lurchi.franken.de> References: <6acfcf9a-7d64-afb6-ad19-3b58d60186aa@levkowetz.com> <6BD2E4C1-8DBD-476A-A3C3-E5BAF2D72D1E@lurchi.franken.de> <5bef1743-8d3f-7532-d6fd-9167d36a3351@levkowetz.com> <7C8FD44F-E65E-4FED-B956-1A066C2F9232@lurchi.franken.de> <3eb33245-8a49-dbcc-2869-ca5f9c414455@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2020 18:56:16 -0000 > On 9. Mar 2020, at 19:40, Henrik Levkowetz = wrote: >=20 > Hi Michael, >=20 > On 2020-03-09 19:24, Michael Tuexen wrote: >>> If the non-ASCII surname contains characters outside the Latin = script block, >>> it is used within parentheses, see = https://www.rfc-editor.org/rfc/rfc8694.txt . >>> For surnames that use all Latin script characters, the asciiSurname = has no >>> function. Input during implementation of the new format indicated = that >>> common paper publication practice was to render Latin script names = as-is, >>> without ASCIIfication. >> ... and I can't submit an update with changing my Name from Tuexen to = T=C3=BCxen. >> I think the tool thinks the submitter has changed although the e-mail = address >> stayed the same. So not using Umlauts for now... >=20 > Huh. And that's actually unexpected. >=20 > Could you send me the XML which was not accepted, for debugging, = please? Sent directly. Thanks for working on the tool! Best regards Michael >=20 >=20 > Best regards, >=20 > Henrik >=20 >=20 From nobody Tue Mar 10 07:49:51 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E28F3A1479 for ; Tue, 10 Mar 2020 07:49:50 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=gmx.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 sUXzPSvp_agH for ; Tue, 10 Mar 2020 07:49:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 5B10E3A1475 for ; Tue, 10 Mar 2020 07:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583851785; bh=gsOYt9dQv5nEuKN85dbGMrMLsmJfi/T+UgezRxVCOek=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=DB96n0ApRxdFrR6jkeeOZcXXRuZaTZIXyircHK6K0xL800CeR2R97pk0INSDIKc0H 2AgxcTuNDHVKfCOqbmFq5pQeQsngjUXQSTTMLcopshmTZKFqFj6pWzd+TxnDB1ugcH iZPRrfDBBW9K/r+Hdn4cvAVxzX1zOD4EkFvcgFas= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.21.40.250] ([194.224.160.189]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MxDou-1jZopM4AaO-00xdSx; Tue, 10 Mar 2020 15:49:45 +0100 To: Michael Tuexen , "xml2rfc@ietf.org" References: From: Julian Reschke Message-ID: <655b5d10-fa66-ea76-cd9d-38a6aaea2b49@gmx.de> Date: Tue, 10 Mar 2020 15:49:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:PMqajjNnV0y01IZdKiio1MRwYE6E0HcTPqBR+fdq4dth75ZRgJZ iJys0Qnt2lzxAtPVEbhUMz7GE+jKtVHfcyRJo6aG+LcFcoF9/C6aXgof2ztAUwbJN63N4OG Ofx5P0B2Q/xCI/crNlBOhPP0JI9AKCaykW7OYRmE6rYa8DWGYE7kQ6g8tvBcJngy+NtLmmU YoOjRz1AWya36Z2kqezjg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Uo1ljTWzSlk=:6cA5i6iM8y+C/x1gciJR0y Py2HwtiGwQvpPo52ZrXHEgIUCQ9p4XE94mPajsHLT6r1T3i6NBc7WmVLkc83GNCGaK36pv6T+ sZCk93/6yjsO5vr/k6R7eUAho/EfHBrCTCLLLWE+g4LwgE6x30oibdIdg/0csx7TYkrPs//R6 wkGZbJuazUFWa9kNNlKKVLrk1FGHCBUesUaco8Pp6AQkf76lhDcnqy0LkEgP04XP40bOdS8Bj zeWNS0HbJhGitHhe/HsnrgNT7VelW9dAWGKQQ63r7di4l0scPX9egs+OzLvLyd+Pbbad8oYkX vX8D/LiV2Lz1t8KiFVwBSRNHCTE9neCKlaAH7H0ho04KJZWuCyC6KY7WJaJDsNrZA8lLmHxqN xx4IQkXX+6MJhcQqxKczC66iBx3Dh/hrGwS0yjSfiyhkUV0RbISnDqlfLqnSke0WHZQMODqGt 4awEswR8jNJ6eHAZvUF7i4jwVpseAoEINTTv+tAk9eyho7DetzHj5kO1V+9tciuwCi8mnEvuf FoDjHQaHkm22loRjVDWSz5e21bePGDokl1D8mUFHQ6uIEDuDpp24AVBTSxiTQsbwr9t2LKYBc 9kF28T2ZWJVcWmlSTM84Q7a9qaFJrUcX1nW/3bLsgUBkOPXQYMpukhXwGl/KNedQDotL834Gf mLHxYI8CtPBGuC5WyjjiYITKq3Yn3In7rn4rjFv/PcriF338zpzCyfM92VzCI5WKl0ZYSKthF F4d/QkyFMvH5Wtva6gxb4if2ouDCQIwiyFjiLh2DLD98RJN112odDskYdS6lM20QWWzQn7Bwn 25lUFGTBM/HbD82PAuAOggcHO+tZrO51b3mwI9iyAqvXOgEPQQvCRR3rhzVHohuWBRIUWuXxx TaTAmiwAXq+jsnHnjsflcZCl3rd8jT0s+y/c08LBfGfbU4kCBxt2zVP10i065Vzw9u1o9dwCG XoowQA2XvtXJXZUZxE8OTWJYMtrRXx1fnlhbpnZ9lYf/qpcZNsG1dYQ2hK7DFHNDs6zK5bYsV 1oQ6ZMxUWJJ6+6RRapymG5510iGcR3s7rP/KQlhiOJxhwenO/t8PDJ7Uy5wBlTRvAvB3t+jkE Pz17t56pNQuVmhvlqISwO0OBgIrnWfjndZihIsf7SdrIqEB9OXg7rVwQj29bkyM9hFz9loncY eCDxepfO/UBUBS6HY8/W2sHkGZA+1T+ZRymlCmEk7MOjgDLfbXJeeSfsRATIetr62VaKpoe9S q5qbEvlksV/TseLU4 Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:49:50 -0000 On 08.03.2020 22:42, Michael Tuexen wrote: > ... > * When using
, which should be OK according to > https://tools.ietf.org/html/rfc7991#section-2.20.2 > the translator responds with "Error: Invalid attribute hanging for element dl, at /rfc/middle/section[3]/dl" > ... There is no 'hanging' attribute on
(anymore), see and also . Best regards, Julian From nobody Tue Mar 10 08:08:31 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C25A3A146B for ; Tue, 10 Mar 2020 08:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_NONE=0.001, T_SPF_HELO_PERMERROR=0.01, 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 QwnpUvpKFmSr for ; Tue, 10 Mar 2020 08:08:27 -0700 (PDT) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F923A1451 for ; Tue, 10 Mar 2020 08:08:27 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:ac50:10bb:50a6:4635] (unknown [IPv6:2a02:8109:1140:c3d:ac50:10bb:50a6:4635]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id 30BE1721E2830; Tue, 10 Mar 2020 16:08:24 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: <655b5d10-fa66-ea76-cd9d-38a6aaea2b49@gmx.de> Date: Tue, 10 Mar 2020 16:08:23 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <35AE7E46-0873-4F31-99ED-DE91C5B6E848@lurchi.franken.de> References: <655b5d10-fa66-ea76-cd9d-38a6aaea2b49@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 15:08:30 -0000 > On 10. Mar 2020, at 15:49, Julian Reschke = wrote: >=20 >=20 > On 08.03.2020 22:42, Michael Tuexen wrote: > > ... > > * When using
, which should be OK according to > > https://tools.ietf.org/html/rfc7991#section-2.20.2 > > the translator responds with "Error: Invalid attribute hanging = for > element dl, at /rfc/middle/section[3]/dl" > > ... >=20 > There is no 'hanging' attribute on
(anymore), see > = > and also = . Hi Julian, OK, I did not know that the current specification is hosted by your = company and not on an IETF Website. It would be great to have a link from the website of = the tool to the specification I can use.
produces, what I was looking for: Private-Address (Priv-Addr) The private address that is known to the internal host. Internal-Port (Int-Port) The port number that is in use by the host holding the Private- Address. ... But the description in the text says: newline=3D"true" indicates that the term is to the left of the = definition, while newline=3D"false" indicates that the term will be on a separate = line. Isn't that the opposite of what is happening? Best regards Michael >=20 > Best regards, Julian >=20 From nobody Tue Mar 10 08:20:50 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E3C3A1366 for ; Tue, 10 Mar 2020 08:20:48 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=gmx.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 1_dQlIvGEZ9G for ; Tue, 10 Mar 2020 08:20:47 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 382683A10DC for ; Tue, 10 Mar 2020 08:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1583853642; bh=SfM70ruJHzn5zpzsE3fqFKc1615igGIHOt5Mk+4db4A=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=TjZePAmbZ72dDvLLhsJy/rbyTFv+F1PiHeOAGh7WkIyJnbhSXiIuINrQPyujYn0zu DxcL5y6CNEDpvAo0I5sQsmFLD5q+5NO2V2XegleMrZkMdC4KKZ77IYz74QBSaPiEQl AbU19Mx9em96QEZUe+m/qNzEIDFdp5LPV7CwRMOg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.21.40.250] ([194.224.160.189]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MAfUe-1j53v01JrE-00B8Qh; Tue, 10 Mar 2020 16:20:42 +0100 To: Michael Tuexen Cc: "xml2rfc@ietf.org" References: <655b5d10-fa66-ea76-cd9d-38a6aaea2b49@gmx.de> <35AE7E46-0873-4F31-99ED-DE91C5B6E848@lurchi.franken.de> From: Julian Reschke Message-ID: Date: Tue, 10 Mar 2020 16:20:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <35AE7E46-0873-4F31-99ED-DE91C5B6E848@lurchi.franken.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:uyEVAI8p9qX820Ddinwy9PgSfcjJrsJsZDw/eRm+uxDe/YuXpRv WU20fzvBVLW2hvEsQzp8qswG+SevvkzZ41iNNalaGowLEZK6UKXb8wzfiGIyFWdKoIiquYZ hgcuTnAfMCIeJelylSjiZFwwG5ZdbgSDGxCbP3vbbQCok81v2ZALy0qxX037QY2Gvn9JjNk Gf24yzIBB/PAxC4L9KjUw== X-UI-Out-Filterresults: notjunk:1;V03:K0:BINEEI5F0rA=:pn1UpHO92xQo5sMmUaeHgu XVTgovQ8tRCm0JfK4Xkc9O8BE0Arh3sabk49YncImZczR3ThHBYYubKLnMfjBqxNPZ2EnJz96 nEcGgQK3Z44Fz/G+QMh2GyEmtv6ZuDm43W0csoQZd3O8ydXWQLjTDwHIk7xpCd4m1ELxh3met gmOrdxVpsU9lbMsG5iWk5w/SgVtB20DpO7fRNLBD3fQO3Im1aHf4hwKO2p6kQDcoqJM+GKWCA KMt2znQpsPjiiEmPstfm3wtgyb0mceJ4Yxug8+6/gpLDZ9UIaDN13PGnaXZgTvnys1NjS+nV/ 3iWFW1AFpffOEI/qPr+4wJ877CV+Cw/0EGkQptWvCSUzvCXHA1D/PAdu2EX2Y/Ae8Y6N+/l4g eBplSBxe4l5WxDLk7R2puk2udZbZ3pb9UImv3mnoaOXy1XGoZrBFp0QP6/RTkQHxUuQrO1OVh DTfRXhl9ssC9lEiJk2tPrXadugnH+IsbZnYTBkIU2cOkmCkJiw9BL7iKzktXL/q7TXT90A3tt Xk5w5BDUy2OkKT6xfwn2D2H4yx/KeHwdxWX798qIF7ltjV8DTioR60+iXMmkLnM+V0uwOjQ5A ZLmupPb7Z4yinzLqVFlbHV3RgMvOM8jN9EjCNwmhTnR2nPcyuELnp7v+ZUKQLKy5rqZx3yiKK qZUgUXY/HqWd6HwhW7wwpyQXxwFDiL7fIaNjjtYBAGB0PfvaQbElG0Nhwf//uvVDS5u3ue6sy hSNGZ+iTopVJDqPC1/QPPKWrrt4dwPDQwXk9qDdUl39oYqwTUKJxstPjcwrJDXYJZQs6nqSXS jdHX3yo4ZZcSlUOl7c2ibaitnbZyzRH5zs9+NNPQ9PJV4p3q8QEqRZCJmaPwhbOkE3tE4cJbv PWFlAIh45/F+8OzPFUxio2n4M2k+1g9R+LxsLTNsVwgG6L7BDAxhn7/R1SYJVlv0VbNE/+ebc 4oS0p48J4O2DKbfsRinqfbJk543jzJ6u074ryCPTElLNl6ACMvMSMcqxIikhzU0joIgom/+QR 3n3URHp29gy4Ha3i+2Qgl1wqEuOjnfFOT58u8tzqCjHJ7YEgXnF1pxJSxepA3leKXwIVcsqUb HqBt30v4WPsmnpVmvtFLvs0EJjUnCXsnbnAC9VstaVhS2rg1WMBauTL91OEB1HNe2PEM6DDU2 yJXoyATrwKnSwOH+d6LU8u9O9474zgd12YspwEXTR6hCCDfMjBHNds6mjjFrR7qx3Hcozbqli 2woT9HoeOAND0Rb71 Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 15:20:49 -0000 On 10.03.2020 16:08, Michael Tuexen wrote: >> On 10. Mar 2020, at 15:49, Julian Reschke wrote= : >> >> >> On 08.03.2020 22:42, Michael Tuexen wrote: >>> ... >>> * When using
, which should be OK according to >>> https://tools.ietf.org/html/rfc7991#section-2.20.2 >>> the translator responds with "Error: Invalid attribute hanging for >> element dl, at /rfc/middle/section[3]/dl" >>> ... >> >> There is no 'hanging' attribute on
(anymore), see >> >> and also . > Hi Julian, > > OK, I did not know that the current specification is hosted by your comp= any and not > on an IETF Website. It would be great to have a link from the website of= the tool to > the specification I can use. Is is not *hosted* there, it's just a copy. The doc of course is on ietf.org as well (I just prefer my version of the HTML). >
produces, what I was looking for: > > Private-Address (Priv-Addr) > The private address that is known to the internal host. > > Internal-Port (Int-Port) > The port number that is in use by the host holding the Private- > Address. > > ... > > But the description in the text says: > > newline=3D"true" indicates that the term is to the left of the definitio= n, > while newline=3D"false" indicates that the term will be on a separate li= ne. > > Isn't that the opposite of what is happening? Yes. See -- an open issue that was raised first over 13 months ago. Best regards, Julian From nobody Tue Mar 10 08:42:26 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05B43A1511 for ; Tue, 10 Mar 2020 08:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 DVg8FBae57EE for ; Tue, 10 Mar 2020 08:42:15 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6A73A1106 for ; Tue, 10 Mar 2020 08:42:15 -0700 (PDT) Received: from [IPv6:2a02:8109:1140:c3d:2d09:2e5d:b7de:1f17] (unknown [IPv6:2a02:8109:1140:c3d:2d09:2e5d:b7de:1f17]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id 5EAD6721E2830; Tue, 10 Mar 2020 16:42:12 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Michael Tuexen In-Reply-To: Date: Tue, 10 Mar 2020 16:42:09 +0100 Cc: "xml2rfc@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0A7AC9B4-A618-4D32-97B0-29D5C42C4B92@lurchi.franken.de> References: <655b5d10-fa66-ea76-cd9d-38a6aaea2b49@gmx.de> <35AE7E46-0873-4F31-99ED-DE91C5B6E848@lurchi.franken.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] v3 questions/comments X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 15:42:24 -0000 > On 10. Mar 2020, at 16:20, Julian Reschke = wrote: >=20 > On 10.03.2020 16:08, Michael Tuexen wrote: >>> On 10. Mar 2020, at 15:49, Julian Reschke = wrote: >>>=20 >>>=20 >>> On 08.03.2020 22:42, Michael Tuexen wrote: >>>> ... >>>> * When using
, which should be OK according = to >>>> https://tools.ietf.org/html/rfc7991#section-2.20.2 >>>> the translator responds with "Error: Invalid attribute hanging = for >>> element dl, at /rfc/middle/section[3]/dl" >>>> ... >>>=20 >>> There is no 'hanging' attribute on
(anymore), see >>> = >>> and also = . >> Hi Julian, >>=20 >> OK, I did not know that the current specification is hosted by your = company and not >> on an IETF Website. It would be great to have a link from the website = of the tool to >> the specification I can use. >=20 > Is is not *hosted* there, it's just a copy. >=20 > The doc of course is on ietf.org as well (I just prefer my version of > the HTML). OK, I see. Thanks for the clarification. It would be great, if there is a link to = https://tools.ietf.org/html/draft-iab-rfc7991bis at http://xml2rfc.tools.ietf.org/experimental.html. That way one can look up stuff in the latest revision of the spec. >=20 >>
produces, what I was looking for: >>=20 >> Private-Address (Priv-Addr) >> The private address that is known to the internal host. >>=20 >> Internal-Port (Int-Port) >> The port number that is in use by the host holding the Private- >> Address. >>=20 >> ... >>=20 >> But the description in the text says: >>=20 >> newline=3D"true" indicates that the term is to the left of the = definition, >> while newline=3D"false" indicates that the term will be on a separate = line. >>=20 >> Isn't that the opposite of what is happening? >=20 > Yes. See > -- = an > open issue that was raised first over 13 months ago. OK. Then I hope https://tools.ietf.org/html/draft-iab-rfc7991bis will be = updated sometime. Best regards Michael >=20 > Best regards, Julian >=20 >=20 From nobody Thu Mar 12 06:59:00 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22FA3A0901 for ; Thu, 12 Mar 2020 06:58:56 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1DBPLiewRa8 for ; Thu, 12 Mar 2020 06:58:55 -0700 (PDT) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 B22F53A08E7 for ; Thu, 12 Mar 2020 06:58:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 675236216A for ; Thu, 12 Mar 2020 09:58:54 -0400 (EDT) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UOhDeNamNHTb for ; Thu, 12 Mar 2020 09:58:51 -0400 (EDT) Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 052AE62113 for ; Thu, 12 Mar 2020 09:58:50 -0400 (EDT) To: "xml2rfc@ietf.org" From: Robert Moskowitz Message-ID: <1b265cac-c693-5038-7e6d-a4633e25602d@htt-consult.com> Date: Thu, 12 Mar 2020 09:58:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [xml2rfc] NIT: double spacing after e.g. X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 13:58:57 -0000 I have the following in a draft: , e.g. , Where CS-RID_Reg is a section anchor. I am getting a double space after e.g. as if it is the end of a sentence. From nobody Thu Mar 12 07:44:56 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69253A08BB for ; Thu, 12 Mar 2020 07:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oY_js6ANJ189 for ; Thu, 12 Mar 2020 07:44:53 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEA8E3A08BA for ; Thu, 12 Mar 2020 07:44:52 -0700 (PDT) Received: from [172.16.42.113] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48dWnZ364mzymD; Thu, 12 Mar 2020 15:44:50 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <1b265cac-c693-5038-7e6d-a4633e25602d@htt-consult.com> Date: Thu, 12 Mar 2020 15:44:49 +0100 Cc: "xml2rfc@ietf.org" X-Mao-Original-Outgoing-Id: 605717089.738037-32d0851acbed5a1b6d4b4dc7a2126a21 Content-Transfer-Encoding: quoted-printable Message-Id: <4AB4453D-1254-493E-8340-0D717FE59380@tzi.org> References: <1b265cac-c693-5038-7e6d-a4633e25602d@htt-consult.com> To: Robert Moskowitz X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] NIT: double spacing after e.g. X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 14:44:55 -0000 Hi Bob, > On 2020-03-12, at 14:58, Robert Moskowitz wrote: >=20 > I have the following in a draft: >=20 > , e.g. , That may be a bug, but it is never triggered. Any correct usage of =E2=80=9Ce.g.=E2=80=9D is followed by a comma, as = in > , e.g., , >=20 > Where CS-RID_Reg is a section anchor. >=20 > I am getting a double space after e.g. as if it is the end of a = sentence. Which you don=E2=80=99t get after the comma. (Insert the usual squabble about whether the double space is the right = thing to do. Unfortunately, the current fashion of not doing them is defined by = typographers who apparently never have to consume large gobs of text. = Enough said.) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 18 08:26:17 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46C83A178B for ; Wed, 18 Mar 2020 08:26:15 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXeh6LO8e2FU for ; Wed, 18 Mar 2020 08:26:14 -0700 (PDT) Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (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 930793A178A for ; Wed, 18 Mar 2020 08:26:14 -0700 (PDT) Received: from [192.168.15.102] ([IPv6:2601:184:407f:80ce:8f5:bf7c:f97c:bb22]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 02IFQ804029096 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 18 Mar 2020 08:26:10 -0700 From: "David R. Oran" To: xml2rfc@ietf.org Date: Wed, 18 Mar 2020 11:26:03 -0400 X-Mailer: MailMate (1.13.1r5680) Message-ID: <9599990B-1A26-4990-897B-B6450BE56932@orandom.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 15:26:16 -0000 I would have thought unicode characters with diereses would be rendered directly in v3, e.g. for the word “naïvely”. Instead, if I type it directly, I get “naïvely” in HTML and PDF; if I enclose it as “naïvely” I get “na"ï" (LATIN SMALL LETTER I WITH DIAERESIS, U+00EF)vely” Cluebat? DaveO From nobody Wed Mar 18 09:39:00 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AEB3A0477 for ; Wed, 18 Mar 2020 09:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 5ZxU234MN1Jo for ; Wed, 18 Mar 2020 09:38:57 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 58B6F3A0408 for ; Wed, 18 Mar 2020 09:38:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584549521; bh=rigFe+O9h2HpXGWjpiQhoUB4LOq1rjijZfc9Jqcsoew=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=A8iQSB48vlJ0mFK7KBSZ4UViurgimcuQ6Bcf+6N+qCFkzXTYhjCtHTA6hEF8jQ2c9 a30dM2u7rcRQl8wMJKEMDawJ6VFxpiKFVQKbiipiWXoH/QfWPQZrozxjRntb75O5ew AXTC0VXpjCTvhMn58GjpTVB9ZzGY40Nkv5NIBtao= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.53.142]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MIwzA-1iyZy70dqM-00KPIJ; Wed, 18 Mar 2020 17:38:41 +0100 To: "David R. Oran" , xml2rfc@ietf.org References: <9599990B-1A26-4990-897B-B6450BE56932@orandom.net> From: Julian Reschke Message-ID: <51a2850f-aa2f-81fe-5aca-462b565fe70c@gmx.de> Date: Wed, 18 Mar 2020 17:38:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <9599990B-1A26-4990-897B-B6450BE56932@orandom.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:GveSognVlRQmqYqhqvWQ+VuxzL0FiKsgxOeshkL7InujiUJyNvI pbUC2UUp2M+ztjP2BdO0w2E1NKsppTjANE/4niKDn8a2u195XKvCXrns9YyFz4DBAO5Uton 7UkVGrKWr45XPrPHYfdyxbH3jenS5d8Ky1XUvUnEd6FvVhjTg6jd36K0LHvVzqctjfrkwSB vJ2r5SjrG6hSbHTxA/PBQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:FkEWcJlKfAs=:XEy1ySK/5F7XZpCyRWYU5L 5uGJC+Y2pfFS6IPXXGvvj+pbz6MfvqshYGcogZubZ4hn90LzSmD7iZYOq6zQjz68Kibqq5A7G CO+9xKOT5QUBAC54gxVOIg9McICog2/AdawdxQQRejOCGGBh9AegnHu2WCGyf9TEpzYe881XU 73CqFfZNwWqZv9b54DTaYNvAkzNLwWZWN3OR2K6Ozf4XRwP/2iZlamzgzouAk4ZK/SdP5b2CU HcbD3di1TDP+CXmtmezwcC62UCtHX2/C9zdQ+SxGugO1ASonPepTGDmh38BdwtwWS85Yo04TU 6vzCIcXU9S6nRgdLpthy3zMD58dN/tx+bzWnTXZFKLRJX6Jid3gg8ygGE4fQHuVPaHUqgH5Zd t/ykX6urXv6dxvTjAxl577Bwa/aHMhi0La6WO+6d4VEcxoW7omom0rgB9xmcM8Rpc9ObbSs3D /dclnRHf+3yNBvaKA/bZvxGpKojyr9JzUWDp3NlMhZPXPecr8yQy6W+RWJGHvtJZX3spp3zv+ 0lACnSkJdm9VFMKN9YXDiGsPFstZRt8ZsLz2/MaQhT84KFqqb9IG1XRS68yriOoUmQ47Y7iZv SXPYrKxz2fdF65Zc5GYBycjgLkZ7QJKoyD0sx7TD5zawpNU7WNhGYBy41JmkxtCJqRUTp2lPT hHtwbAwC9YVX5JJXydNPdy+2DRpXOUlfwBeyjg4gyn0YtJE6LULT6fd2gTgEACqD2hFSHVE54 ftIzvOwh0H3XOTMdsfod59CPQTRN1nIeV+NmZi4F8NBustDu/wmdJvoVj47SWttlhYxXFCiFn 4PPoRQkgcu4VE/wONzOdNAGD9xPwOLkGfKalEk+kg2RotWdxfrK+qp+kyTVMVa2mxjIPppLPw MBwDHVizllsn7TkH1Vqv1bTL9tbKYWI145AE1NdIx3OnqOi+wValR10Y1X6c/65XqXSDuglvd wdW6Ejj+5taKr0mEdkDWWk0m2QhSXR6LR6rCYFZkZ+TftHhwZrNvCiTqzBDq/0Ut1BJ265rhO NEX55yjHWWa83M9ClFMXEOxrMYc5pIB0hDsRGAKKH63Pmk5RCQRhxmr584vqcywqwVqcfjAEY D2MSUoS2/YU5tovQLdhad3Rf8OG6IVX6UhbMAvESAt0gfDSOhDLPqjKdb8Dy5COFJCqnsFusM rDhMf46I0w0ErD+Eygv46Go/PCrIJqF++qWulJi++SprbIopplXVRQDvD2goW2OhARWJB4SoP ySCY5On0fBX2Z+OKW Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 16:38:59 -0000 On 18.03.2020 16:26, David R. Oran wrote: > I would have thought unicode characters with diereses would be rendered > directly in v3, e.g. for the word =E2=80=9Cna=C3=AFvely=E2=80=9D. > > Instead, if I type it directly, I get =E2=80=9Cnaïvely=E2=80=9D in = HTML and PDF; if > I enclose it as > =E2=80=9Cna=C3=AFvely=E2=80=9D I get =E2=80=9Cna"=C3=AF" (LATIN S= MALL LETTER I WITH DIAERESIS, > U+00EF)vely=E2=80=9D > > Cluebat? > > DaveO Yes. IMHO the intention was to allow that in RFC 7991, but it hasn't been implemented like that. A similar example are non-ASCII characters in names, for which a new element was added (which we wouldn't have needed if we had stuck to RFC 7991). Best regards, Julian From nobody Wed Mar 18 13:46:42 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D375F3A1BF2 for ; Wed, 18 Mar 2020 13:46:38 -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 (1536-bit key) header.d=iecc.com header.b=KiqzAVp+; dkim=pass (1536-bit key) header.d=taugh.com header.b=UwsKMcL8 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 0UqEE4TSrK5f for ; Wed, 18 Mar 2020 13:46:37 -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 3D96F3A1BEF for ; Wed, 18 Mar 2020 13:46:36 -0700 (PDT) Received: (qmail 74565 invoked from network); 18 Mar 2020 20:46:34 -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=12343.5e7288aa.k2003; bh=w6mtO659mX/Iom9FUm724ClralVVnQlz/xP02QaJsA0=; b=KiqzAVp+v1f1hDDLDs8queGMiEu4BFkOxqJQ9CTDkDWU1nbXl9xTATM3VzY5NDl93Qgd4R+yqM6qlxwPeKeO5DePjtg49+qknMrh4AUGaN9R0dU/5b0rZ0Ce7nrSuUsau7E/FRQvm9aAnTWPVscnDFw1klCYpKEEDSJnwtpHbtzmeRhgyzQXSs3TDfI4f0dlNOgkFxv9Q6iiexTSOSAm7PTG1Izgn+jjEoMqR2dHKs0v9Bi0L3RS5AqnHxJncyTV 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=12343.5e7288aa.k2003; bh=w6mtO659mX/Iom9FUm724ClralVVnQlz/xP02QaJsA0=; b=UwsKMcL8pI0IOuEkHILXOd5wix3IqtR3DPycjf9k4WtwJZT5EmfiQf4fMf+baopv3INAS8M1mLZrU4X5rxVviUkAmlSpmmhI65Y4oyVlFq3jKhIfQ+Fhcc5KDzVRuOE+hb9hdGM6UadqgOageZpl0G8iJsmpyd0JoXibt0Mi7HT3RDX0wCzemPzcfGTkCke3nhcaUyRYV5YCdQLngZnD62xVvnjZNsu3ihrVebhZadPDkMLxjJLsCVOcTOvowLra 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 ESMTP via TCP6; 18 Mar 2020 20:46:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 50D31163CA18; Wed, 18 Mar 2020 16:46:33 -0400 (EDT) Date: 18 Mar 2020 16:46:33 -0400 Message-Id: <20200318204634.50D31163CA18@ary.qy> From: "John Levine" To: xml2rfc@ietf.org Cc: julian.reschke@gmx.de In-Reply-To: <51a2850f-aa2f-81fe-5aca-462b565fe70c@gmx.de> 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: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:46:39 -0000 In article <51a2850f-aa2f-81fe-5aca-462b565fe70c@gmx.de> you write: >On 18.03.2020 16:26, David R. Oran wrote: >> I would have thought unicode characters with diereses would be rendered >> directly in v3, e.g. for the word “naïvely”. >> >> Instead, if I type it directly, I get “naïvely” in HTML and PDF; if >> I enclose it as >> “naïvely” I get “na"ï" (LATIN SMALL LETTER I WITH DIAERESIS, >> U+00EF)vely” >> >> Cluebat? >> >> DaveO > >Yes. > >IMHO the intention was to allow that in RFC 7991, but it hasn't been >implemented like that. > >A similar example are non-ASCII characters in names, for which a new >element was added (which we wouldn't have needed if we had stuck to RFC 7991). That seems like a bug to me. We assume that even the unpaginated text will be rendered on something with a UTF-8 character set, right? From nobody Wed Mar 18 13:53:28 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26973A1C10 for ; Wed, 18 Mar 2020 13:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dPzTceUVwBnq for ; Wed, 18 Mar 2020 13:53:25 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E98B3A1C11 for ; Wed, 18 Mar 2020 13:53:25 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:51850 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jEfgW-0006KB-Ip; Wed, 18 Mar 2020 13:53:25 -0700 To: John Levine , xml2rfc@ietf.org References: <20200318204634.50D31163CA18@ary.qy> Cc: julian.reschke@gmx.de From: Henrik Levkowetz Message-ID: <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> Date: Wed, 18 Mar 2020 21:52:57 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20200318204634.50D31163CA18@ary.qy> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="1bH5MoX9jWkb4mPPNLQ8Flb8dAi73AC6i" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: julian.reschke@gmx.de, xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 20:53:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1bH5MoX9jWkb4mPPNLQ8Flb8dAi73AC6i Content-Type: multipart/mixed; boundary="4sEm5UxaDVvtQJlsxvFcQl8mCNKMOtM43"; protected-headers="v1" From: Henrik Levkowetz To: John Levine , xml2rfc@ietf.org Cc: julian.reschke@gmx.de Message-ID: <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> Subject: Re: [xml2rfc] Silly unicode question References: <20200318204634.50D31163CA18@ary.qy> In-Reply-To: <20200318204634.50D31163CA18@ary.qy> --4sEm5UxaDVvtQJlsxvFcQl8mCNKMOtM43 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2020-03-18 21:46, John Levine wrote: > In article <51a2850f-aa2f-81fe-5aca-462b565fe70c@gmx.de> you write: >>On 18.03.2020 16:26, David R. Oran wrote: >>> I would have thought unicode characters with diereses would be render= ed >>> directly in v3, e.g. for the word =E2=80=9Cna=C3=AFvely=E2=80=9D. >>> >>> Instead, if I type it directly, I get =E2=80=9Cnaïvely=E2=80=9D = in HTML and PDF; if >>> I enclose it as >>> =E2=80=9Cna=C3=AFvely=E2=80=9D I get =E2=80=9Cna"=C3=AF" (LATI= N SMALL LETTER I WITH DIAERESIS, >>> U+00EF)vely=E2=80=9D >>> >>> Cluebat? >>> >>> DaveO >> >>Yes. >> >>IMHO the intention was to allow that in RFC 7991, but it hasn't been >>implemented like that. >> >>A similar example are non-ASCII characters in names, for which a new >>element was added (which we wouldn't have needed if we had stuck to RFC= 7991). >=20 > That seems like a bug to me. We assume that even the unpaginated text = will be > rendered on something with a UTF-8 character set, right? What's currently implemented aims to follow RFC 7997, which is the releva= nt RFC in this case, I believe. Henrik --4sEm5UxaDVvtQJlsxvFcQl8mCNKMOtM43-- --1bH5MoX9jWkb4mPPNLQ8Flb8dAi73AC6i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5yiikACgkQTptXS4+7 FxrD3w/+KZq1Q0wdjibrmufb+hryaBsIuY8KB1lVuCrsSDGe1wVsj1iDwNV8abqj Cfh2Lz2cf33HSCj0XwAaF0qD/pHu8Vj2iUtGslSv/8+L5g0Z7IxawANJEv5mFB4g FsQplZvX89Ui4H9mpqkAsqsDnijifppzUHO0SrpFF+ez4HnFTt9X5dUR8NQeLmi/ w/LIkf1aafhcu/T7ktJ7gdyYVgavyPYKKADGieOt66991IZePYSqeXGw5jAJdiur DSflM/nZmripA3bO++4o3XZ0L+a4MMNm7DMTv8doF7mbwCIWrBByAvsA4bog1Z0y eZSa7juTv2trEq1QpeX4JJUEapMQEZoz3qvuFW+ifT3Lw6MYkwVIvbgZbPh3oOvC ghrcPox1Fce+3Qw/Svi17vM9ne2XPhPg5pTLbbuN85z4/4CTwA8xgAeE6201RqWO PCTIqxBQx9goS6V4v/gosmxNZvtL0hytDKwDKdokn2R9fSHAAyF07OOKYtiyaijv oq+Sl1Nw/Z185IW24BsWxHNLuMYx+URChX+eBURRfU559f/XAHnBMjmh6jGDtSw2 GwKbfYHZ3uQGl48k1k7p/kJjOwmITl4o/y1Xlahr+izQAkYk13bGxhN3m0Egh/61 f0iXDwC/2PiYYg/T8MUj4P7ea7ymYSMYW5y/5WrY944BTeVB/zM= =oawl -----END PGP SIGNATURE----- --1bH5MoX9jWkb4mPPNLQ8Flb8dAi73AC6i-- From nobody Wed Mar 18 14:17:22 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9EE3A1C6A for ; Wed, 18 Mar 2020 14:17:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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 (1024-bit key) header.d=gmx.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 MGzZg9sB13xw for ; Wed, 18 Mar 2020 14:17:18 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 DFF933A1C68 for ; Wed, 18 Mar 2020 14:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584566183; bh=K+5z39HQ0vkLEJwDRYX2LXCzwJyq4rk5kYc6PgevUnM=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Te90r82f1bb/a8j/cfRhiASjcNA4ifae74v/tVOz51DcoyXdzVEsA0Z0ShhArYKTn hsDfLf85wgmBS3gjQiV3lqsT5Wct/Tk8xDPxzsMR6MHuH0NAah/yXknYCUsKnpLdwI fXyt+li/7UWMgFpZbVw2ovCICLBuAugV2gd4SkbI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.53.142]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MUXtY-1ioNkt1QnY-00QVt0; Wed, 18 Mar 2020 22:16:23 +0100 To: Henrik Levkowetz , John Levine , xml2rfc@ietf.org References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> From: Julian Reschke Message-ID: <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> Date: Wed, 18 Mar 2020 22:16:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:anBRVBSFmiwxrQ8HWv2c8JETsIzI9paPHghx9lrCDz+v7Dlckzt REF0YZ5hDuZXwY/sHPvxMAkOeldcgcXpDiQvSp923OUImybo/CpHRcQNtDXAaQfoaUANNY2 ZlbVQszsc+7RRaD8m075iLIocTCDzt03E1Rk5Jjfd/cqMInJJVHOMnt7GfDFGa41QIdet3m Q0Rhn94gy0XSEJF57i3dw== X-UI-Out-Filterresults: notjunk:1;V03:K0:dDcU+ooGA3M=:4rSNw9jlQyUbqfJdviUPlb PBOANLfn2enV2wb/kx0JogzDA7LLAdQNW7U9uumaD7kcAkxHaKuSszn+PGOEfnWW4+IS7QtQt 5ZEbtoYGTHQCIPbdWZTplm/Q66Jg8K4JV7EgHfXRw2rF5GhOTcjX/kn0WQJS8i7DOXR6mGofI H6xV/vns//R4tNig3a5tg6Ec/8HpzEsJrzgs8jrlRKk9qLzWyGS7psSWzpxiAtzgx56IkpYxr 6JDgH5IeF1HioLVuLD2mHcT734pWTTzwpVBXCoPr/SO6lYoG5d4I9VTDj1d+M4W8xpA2o+BNa ViMCxsubRukReO55slEPsdUqb4wLLDcr+Y3NgN52Q1RHVqaZhqMq78leHNNKMzHR7q/VuZyFx JJbwhxLWNNXqJT763bf8tbNUhTLKR+BZCfBbBI2emMZ924p3zS6tBW/yIpuNJg73E3O86uKrK uBQRfuZnVon6n32hA1ektca8wFZ3MXDdZFVDJYd+euitPP8pFkt3yD1atkdIFQfwE8Xe+7I22 wMX/bGvG/nERTuxcltgAKLI0WrvmoIFQnsRAEo90WVT/cYFICqWAiVtxIJM9vRCGwiawNEooC OW30wvyClW95t5qJ86mgzIzzsYeJhOBgtYBWG2Mb/xevILB29xoDc/dMfPK5w5TBavx2yWGbK PZsy3BgMUIe4e2zdksMdLKakPrfF9Jgu/rXS8SmVgH5DsgjAtJZm9UsERQ6tKlRCwWYmfGoQY M6Om92gm9Y/ZW8pQgUuhedJO2TN3OIrtqXJwHw4B/vfQgPFJJWZmD/Dn0FPgV8RxZFEFgy6OD 19D/XGlVXVVI3MoQHYm+VAoKR3CCFhKQtX/ukfKKVwNGbMlbkPy/Th5kJz33kc2C/YrXqChDm ztTEWWB9pAmGVKTa0G7TkhOTm6A9KKsLCWUjlkHo5p09IMpKwIUQ8mBYoFKbX7a1rW3Xp+iIl 1hUpjSoa4lQhiYe2cf+yzBQzQAEBAZ/S4InACpmjNa4FX/Ws3kcUrypHPQSOVFRrbTyCp1FWA RjBu+As2Wy9EepamJWfmTgi4zoYFBVEAgedRbNxMhwgz7WYv1sA6LjMoPlzrOgitBWVQ9FkOD FPbfxxBbhcv28TnGWJFhCZLRXXeGfj8VPXULZbStYk1HW+bse1Ik4D5WxU6yYUi5TKpZh2HEW UnKbZQHF1MyJVlQAsxlCAmRiUZ1LBiatk4gLfVy4BwJfkQY5/lJPHpsRMJczCRErOlmyKArMY LNpAwRbZxxRnophIO Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:17:20 -0000 On 18.03.2020 21:52, Henrik Levkowetz wrote: > Hi John, > > On 2020-03-18 21:46, John Levine wrote: >> In article <51a2850f-aa2f-81fe-5aca-462b565fe70c@gmx.de> you write: >>> On 18.03.2020 16:26, David R. Oran wrote: >>>> I would have thought unicode characters with diereses would be render= ed >>>> directly in v3, e.g. for the word =E2=80=9Cna=C3=AFvely=E2=80=9D. >>>> >>>> Instead, if I type it directly, I get =E2=80=9Cnaïvely=E2=80=9D = in HTML and PDF; if >>>> I enclose it as >>>> =E2=80=9Cna=C3=AFvely=E2=80=9D I get =E2=80=9Cna"=C3=AF" (LATI= N SMALL LETTER I WITH DIAERESIS, >>>> U+00EF)vely=E2=80=9D >>>> >>>> Cluebat? >>>> >>>> DaveO >>> >>> Yes. >>> >>> IMHO the intention was to allow that in RFC 7991, but it hasn't been >>> implemented like that. >>> >>> A similar example are non-ASCII characters in names, for which a new >>> element was added (which we wouldn't have needed if we had stuck to RF= C 7991). >> >> That seems like a bug to me. We assume that even the unpaginated text = will be >> rendered on something with a UTF-8 character set, right? > > What's currently implemented aims to follow RFC 7997, which is the relev= ant > RFC in this case, I believe. FWIW, RFC 7997 explains when using non-ASCII characters is ok. That does not necessarily imply that the vocabulary needs to enforce that (otherwise, RFC 7997 would be in conflict with RFC 7991, which IMHO is not the case). Best regards, Julian From nobody Wed Mar 18 14:33:39 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBB3A1C43 for ; Wed, 18 Mar 2020 14:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=WktcClco; dkim=pass (1536-bit key) header.d=taugh.com header.b=TqKiza4M 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 c5vYuZbY6D02 for ; Wed, 18 Mar 2020 14:33:29 -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 398F93A1C3B for ; Wed, 18 Mar 2020 14:33:23 -0700 (PDT) Received: (qmail 83930 invoked from network); 18 Mar 2020 21:33:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=147d8.5e7293a0.k2003; i=johnl-iecc.com@submit.iecc.com; bh=Lptycb1lo+28SdAcrr4HzmlCu5SXN/bTWnGJ6SlHJLc=; b=WktcClcoMvPaTc/23Pcpr6s+tZixZvY0hluI42rTn3bjS4znArFKDR4IoLqdRrfYbQ2NDb/JTQaFun9wP+X7bHXEQIPE/iei9IpX7DOGHZAFa/hOkEs0dsAlgQ20L5RzDcBSVW6i8eQCb9S11+4r1UL+3OAmNm2y3A0ym89YuXqSeFnXlvgOpZBJPd6vLJ9i3FD8W4b9M/qnyNw1wWHznvktnSazNElHVVPbevTrqHRaBiFqKcj0IKSbwMh0TDm2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:references:mime-version:content-type:user-agent; s=147d8.5e7293a0.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=Lptycb1lo+28SdAcrr4HzmlCu5SXN/bTWnGJ6SlHJLc=; b=TqKiza4M/Ff0X5Tdbqqme6AIiZb2tjIMJpfsS8sEI8VVFkYQEbSnNnKlWTr0Oi+7p/s/cqdbk+4CBn+tj/TmPG8tjMJfy33GZSCf3bGpMfZG3lVkYpkvXr9KT1pBW0aATDnreguH/AL7TP2sFVBKBxdtBtcU1XM/Tp7+C7p1+Hvm7DfkIKVYGC9GPSmQz+r+y3zL5r1h76x4Iu0J+N31Yc8wsSgkcV1iGWqnT35kYmSS6kn3T9wTGLDRi1RttGPi Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 18 Mar 2020 21:33:19 -0000 Date: 18 Mar 2020 17:33:19 -0400 Message-ID: From: "John R Levine" To: "Julian Reschke" , "Henrik Levkowetz" , "John Levine" , xml2rfc@ietf.org In-Reply-To: <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2020 21:33:37 -0000 >> What's currently implemented aims to follow RFC 7997, which is the relevant >> RFC in this case, I believe. > > FWIW, RFC 7997 explains when using non-ASCII characters is ok. That does > not necessarily imply that the vocabulary needs to enforce that > (otherwise, RFC 7997 would be in conflict with RFC 7991, which IMHO is > not the case). It seems to me that a fair amount of 7997 became obsolete once we started publishing in v3. I'll run it past the RSOC and see what they think. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Mar 19 04:36:29 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D30603A27B6 for ; Thu, 19 Mar 2020 04:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLh-CvPeI88w for ; Thu, 19 Mar 2020 04:36:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675DA3A27C4 for ; Thu, 19 Mar 2020 04:36:18 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:56514 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jEtSu-0006tN-LV; Thu, 19 Mar 2020 04:36:17 -0700 To: John R Levine , xml2rfc@ietf.org References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> From: Henrik Levkowetz Message-ID: <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> Date: Thu, 19 Mar 2020 12:35:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M7RXdX1xMWXmc11i83UaE6el6AwTdSCaE" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 11:36:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M7RXdX1xMWXmc11i83UaE6el6AwTdSCaE Content-Type: multipart/mixed; boundary="UpSXUQrrFAtqVDsP1cpJhwOF24OaIjOoo"; protected-headers="v1" From: Henrik Levkowetz To: John R Levine , xml2rfc@ietf.org Message-ID: <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> Subject: Re: [xml2rfc] Silly unicode question References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> In-Reply-To: --UpSXUQrrFAtqVDsP1cpJhwOF24OaIjOoo Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2020-03-18 22:33, John R Levine wrote: >>> What's currently implemented aims to follow RFC 7997, which is the re= levant >>> RFC in this case, I believe. >> >> FWIW, RFC 7997 explains when using non-ASCII characters is ok. That do= es >> not necessarily imply that the vocabulary needs to enforce that >> (otherwise, RFC 7997 would be in conflict with RFC 7991, which IMHO is= >> not the case). >=20 > It seems to me that a fair amount of 7997 became obsolete once we start= ed=20 > publishing in v3. I'll run it past the RSOC and see what they think. That's not the line Heather took. She talked about doing a 7997bis after= experience with v3 schema *and* RFC 7997. It's also not backed up by the RFCs as published: since RFC 7997 was published as part of the v3 RFC 7991-7998 group of RFCs, I don't think you can argue that the using the schema from that group (RFC 7991) renders another RFC from that cluster (RFC 7997) obsolete. This would be a major shift in policy. I'm not arguing for or against the actual change in saying this; but I am saying that it's a major chang= e, and I don't think it's appropriate to do it without wider discussion and = a 7997bis document. (On the actual change, I think it is quite reasonable to permit the full Latin script range in running text. I'm more doubtful about moving directly to permitting the full unicode range without more experience wit= h v3 publication. There are too many pitfalls there. Just handling full-w= idth and half-width CJK glyphs and right-to-left scripts in the limited locati= ons we permit them now has been a challenge, and I don't think we've had many= actual instances of publishing documents using such yet.) Regards, Henrik --UpSXUQrrFAtqVDsP1cpJhwOF24OaIjOoo-- --M7RXdX1xMWXmc11i83UaE6el6AwTdSCaE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5zWRMACgkQTptXS4+7 FxqR7w//U+dcUJb70VX0BfG8a7ytOXEg8PO6jerubZW5mIBY35Or/FqqNP4ovhpM x+bsPUSNL1wesyCwjD/8YDuzoHKqcw0WT0qXptiwZF3pJ9EoYwlCYem7WD14rBjM 2yo4ehl4hNaMKc6n5uJ6Yhy13j1arwmG0ehXnogX8rT/6JyfZ9r2ya1OS+bage3b eZ8SETT7XmC1aa0SU6P+SiPXseYRerKJ5vU2x2nCAEtZdgZlRew2eLvzOdiyUcbL FnguEYtNqICsxHXSy02iM9Kg0ZG0G5taJkHCnMu4ft9n3PDGRYeNp4NRa409caa9 w6DvOYoWgOhPMLG06ABqZjGCGDMmhDwGD6uc09LTGPR+eyOWslob/ZY6TqvyZmFl LGwH/Fuv/VeoFowuE7DzIgtfJ0WAqPCBdPVfVr4G+68QdKSYxWaTGcMRqqekVkwq RxgjvXrcZmh86sgBjN7J7buET7JWbpYNb7YKAuy8ZBk82awafeW4FTHZNXc+qC6E Yfb2LLHcJz8znQD36/VZEcDGSB/JDMk5Dh893b+A2mxiVhgcp+i8CCRAJoViLFmZ wAhVJ4kpCs9nPRkETzAlP6hJf6J/ZPvo636tgwGCArPBJs2PWo1c3N3BW+e2k3wu jvXL+B6pd8ZXFKDSrdbGksIzeGOyIosGncfMWdgIXDLk8xsPxPA= =zRtl -----END PGP SIGNATURE----- --M7RXdX1xMWXmc11i83UaE6el6AwTdSCaE-- From nobody Thu Mar 19 04:38:30 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C603A27C8 for ; Thu, 19 Mar 2020 04:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 RRbaD1AMPEc5 for ; Thu, 19 Mar 2020 04:38:19 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 EC8083A27C6 for ; Thu, 19 Mar 2020 04:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584617848; bh=tYYm9d92dnpZUSQMZ+ItaLM4238fJfTydyzPuKoVuvg=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=RCxUQ/Ya5npAFLvPf9hEZgxDPfgH+WgTOr2gliZq8Xg5O3AlNZX5XpYpR7UFaL0g0 npa1+imWp1RE/VS7wCJp4h36sHqiDtZaMjRxNVCwg+e5pRKPwwzlQjV8jRSfQt1dx+ PnY4chJPenLwCqXR5kJ/AaCBj22Be+Fqs0l6GXBw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.53.44]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M5fMe-1jC7X33TNi-007CXo; Thu, 19 Mar 2020 12:37:27 +0100 To: John R Levine , Henrik Levkowetz , xml2rfc@ietf.org References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> From: Julian Reschke Message-ID: <86cd9bb9-73f2-cdbf-46a3-56f617111e6a@gmx.de> Date: Thu, 19 Mar 2020 12:37:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:eVFf7cXSx8hlyTIeKAgXMlx5UYWf5/q/riSiJm7kq3+FKNKQ8pl FO/XnmfUlfHgwilrAuvcCsa2KBSYYsiE3m3+xQ76D3rORjazTPH6GAqqG2S6KWNqQhF0ZrK hS5SjKSn8uZTGNjhcQUYrW95Mw/VIEq9IyXEY5gn/5si9vbdZDh6Q69GFVdLer8htCRwrm+ tyeWEYzpBLmAF0elL0GQg== X-UI-Out-Filterresults: notjunk:1;V03:K0:EMXgwvTlj0s=:fESDzIvWDnZuOOekLEAREH R4kVeNl+SDfbVUMDyzjoD2XLnaavXNEuOTSFkjx4k/kpp5GcZxgpFhdtjtWigAEBk77ZjFPKl yt+EHnwJDDyU6n9aAStnPb6KCv7yW0mZg+lP3a0JaGXXSnzhTMVAHaS2tmof77yQhW5qYiAnT 8XGyqnwfP/47o38yO3LIO98xqmkhUe6HXcqnU50nlpi9q2GIuHn1P+f1/VphqF5O703d0mHUF Rkjr3FiYFIzCm2rxil9dyBPOQAbeJyPUPHljmixXCV0AslWLWptWt8bvWo/Cfysa0YwnHTX2f Ogvbf1pKvOJAQBGGekTuDOKxD585pHcw5cp9mk+vA5SR4ycZnp+dYkHRIVRIG2YfHXDe2g07O igGwXcLQ3Vq16WifmWt4WMERpyFX1GJlsTgjy9EQywEeeMkfNO3P0vvqsKZEXTMI4YgBKFUvC 2FWdbHD/9E4SyAO/haoyOZihNsP+0mFc2TjW4Jp9PDhYlCzOPq2i5t2fMjenlWklIO/4WkGnq IVs30IAKVAABUrYCIksFl8xjprqOFvVNAJnqlAW8YhyZ4Ry5DLEjpJ+tBvtlCdWbFvafi11fL o0fs+LNKxo6oVVkJ7ZEwYxP24d6hJFeneL7KckqMFINliiKXIg9ZMEo4O3M/MrWzi9bFf8LRC JEbROi/60i5MTO/4r3GQmejQLj9BY33ogdLPsa0kRdRZP4vQ3ltl54rEFq/kc95ms2kamH1dX Xkq8pKGna46lsPMoc5q+irD+9fEnPoQTMmgguz57JML9rVDJkSH+6UzNnC4P7gU1Ojplxl0wC jV9LrlMs8eUbQ4QNGXVYuy5DWO9OdGD6ezLvupH1D0ZrJQlFwzR5hA2nOc35XmNQ3VJnidGKf wylvJnIXN1TmDKAWGRpN3zcJWJdKhuWP7LvVAvNwCRq5zGSrenS4Lg91aJWX3s6/ZKoHjjki6 ID2VVE+R0/MnT8VKZUIfm2dlELTJC1AVqq1zeM2036Gu0EAKyDQJ93ih1SOhj+cRzW/HzMJfJ DGrz3W825DQrJDI0HLxSStHK3QyiHi3EqsX7W7sUXuiFNAp9fHVRHrNtbpfVO35l4X74620bc oJPHiXsCo+zGXuQlJN1w34PUYQbBMTPTnDXd9bXxTZQ7EsIuhnZMKRbae/vc/JqtB7+UaFqh5 9Yl28VqP2DMDH+TMvRPfGiHbNec/sba8mnGo9KQPoFpfbs+cGXc2gtce4fMIUXhle6Fzyz38Z L1bwelaQGJDEIddHl Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 11:38:28 -0000 On 18.03.2020 22:33, John R Levine wrote: >>> What's currently implemented aims to follow RFC 7997, which is the >>> relevant >>> RFC in this case, I believe. >> >> FWIW, RFC 7997 explains when using non-ASCII characters is ok. That doe= s >> not necessarily imply that the vocabulary needs to enforce that >> (otherwise, RFC 7997 would be in conflict with RFC 7991, which IMHO is >> not the case). > > It seems to me that a fair amount of 7997 became obsolete once we > started publishing in v3.=C2=A0 I'll run it past the RSOC and see what t= hey > think. Trying to summarize... When RFC 7991 and 7997 were written, the idea was that use of non-ASCII characters would *not* be controlled by the vocabulary, but by the Production Center. This is why RFC 7991 is silent on this, except for the cases where *alternatives* for things with non-ASCII characters are needed (such as in contact information). Later on, was proposed, so that authors needing non-ASCII character in protocol descriptions would have a tool to automatically insert code points, long names, etc. That's a good thing. However, , as implemented, *also* removes the ability to use non-ASCII character in prose except when inside . I think that went too far; in any case it needs to be discussed. With that of course, legit uses such as contact names in Acknowledgements became impossible, which lead to the introduction of as inline element. I think is a good thing to have, although I'd prefer it to be just a tool to make things easier to write correct text, not a requirement. If we keep it, there are at least two things to be done. 1) Bug: (see ) - the output of changes when it becomes the target of a reference. This doesn't make any sense; this *absolutely* needs to be fixed. 2) Task: inserts automatically generated text based on external data (the Unicode database), as such, we need to preserve the expanded form using the preptool step; otherwise we loose information in the archive format (yes, the Unicode database changes). Best regards, Julian From nobody Thu Mar 19 04:41:47 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35643A27D5 for ; Thu, 19 Mar 2020 04:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RoRP5hTaHvEI for ; Thu, 19 Mar 2020 04:41:42 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327013A27F8 for ; Thu, 19 Mar 2020 04:41:41 -0700 (PDT) Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48jlNz3dsJzywx; Thu, 19 Mar 2020 12:41:39 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <86cd9bb9-73f2-cdbf-46a3-56f617111e6a@gmx.de> Date: Thu, 19 Mar 2020 12:41:38 +0100 Cc: John R Levine , Henrik Levkowetz , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 606310898.891705-a32d634ea3966f3e6cc5db8b58fd8a0c Content-Transfer-Encoding: quoted-printable Message-Id: <2B016B4F-B152-4504-BB3A-555BF03F4620@tzi.org> References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <86cd9bb9-73f2-cdbf-46a3-56f617111e6a@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 11:41:46 -0000 On 2020-03-19, at 12:37, Julian Reschke wrote: >=20 > When RFC 7991 and 7997 were written, the idea was that use of = non-ASCII > characters would *not* be controlled by the vocabulary, but by the > Production Center.=20 I think this is an important point: If we want to automate some of the = checks that RPC would be doing, the place to automate this is idnits or = an idnits-like tool, not xml2rfc (maybe outside of warnings). = Specifically, xml2rfc is also used for authoring I-Ds, where none of = these restrictions make sense. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 19 05:20:32 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6E23A2865 for ; Thu, 19 Mar 2020 05:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 baSXCecQO8nB for ; Thu, 19 Mar 2020 05:20:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 4830B3A286C for ; Thu, 19 Mar 2020 05:20:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584620358; bh=fTbkQGhESAxG5DJD5aBRoriZx5BaHhI7kIiJteDvpNI=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=VNpESCwR3jmFPzudm3GCVLPAbRuuHID27RuO61XtO9bsBz86FcRRHXjrhr1Zicfhj qTvbASP9VrO20pNJ3K2MKwFLHg6+LhQRJFlHLmZutpszlXG7vF614Whw8VczvqsSQL QKxSz+qIjrn3PMOR3gg013UdnRCmknZUWWkn0OC4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([91.61.53.44]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MBDnI-1j8pbv3kpq-00CeRr; Thu, 19 Mar 2020 13:19:18 +0100 To: Henrik Levkowetz , John R Levine , xml2rfc@ietf.org References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> From: Julian Reschke Message-ID: <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> Date: Thu, 19 Mar 2020 13:19:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:LoSp/8dDx+lzHW892Ubp6OMGbu2Mo8UG4ryDv/vSfoxJ8pJUMIK RYvp69eGM+CpJxFnhicduQG9RyZUEIc0wSqML11ixJFwyAXgPBWWSi7TD4J8Vo1QRiBDIDo x/U3tLSsyFpiGPii3iUF1HUbeuaozXKvBs8FWf9DxkW5MtZCUlGsnFmUXSZ+8eUx7CqQlE9 KkR2RoCiqvo6C09DfrTJQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:FrBHxPhKinc=:V/0YnnptSb+0JR4XqIjEkH uEM1MUco8+ngox/RY1n9TqK0lVntdATYhj3ZRXsO+BRcKqQLkKI3f9k2js5KniMiKjCFwidFd IHNdK9K2XA0+qX9ZBetpiU64kXuW4LgCTCeEhUZgWu9efOkCa6h+V49/otP0Oe7JIW4RGXomM p2qWIdFt168+gh+6tAJmhFXhV9RevEDVoGb0Plc695Yhqf678TupEudXhZQ1rLgEaXurgc/YI kTuLLlGtSOtCCncQxmdc5Dq3rYssFaaACTpVVK6UG8O47O6bbF5plk4vOuxVM4yO0+alqCpn3 ZXZX37AZ/XAkUSe1vHSGyYC1TxJ7lg/QoARoaoc5/J3XnFhMo1lJ/FdQ9kSePV9rbeZ9NLW2Q 4VQ9F4134fBdxDlevzt7sqhgPi4RVZKpgzUp7ZknBFJr7TwhPKKcE3og6+zl27OUb06cWnU3k 1d17qwNDSmyJ+LP7fXkE4EcqD0uYPbrqCNMiJUvTGeS4pn/dp0vdxI0jmor8RTuapbIbTjW+z ln4psJei3yPQ8XP9MVHnRR4v6hcCo11HjC4ZP3p7XOrAaSL2s2CSCr7uB2Cb5MeBvwjNNv0mZ TWFd8ltviG2WPfiLXx/GlsPy0RsPXkwAPjpNthv4ZtLhDOOCdNntco0Et226fxM/x11Va2jaq 6adunzYdQifLW71QZobw8UBcIIRnPYi2iP18R27f2IAibXr2w6eg+xtbFd+IimBiAalRP36Rr F5KW6hfu58UtQfWEo1SEWHhZ1lWYq2riQW/OHT8CD0AANlAS3hMpWE9d+VJsU+5oVeSQmV8WS Vdlg04G0zUe+QudcrME4yiakaGvf5MwaPkLKwjxEskYYMritunz4j+4Fm0Llq3wdfAspw1mTF N10VXtEkJHUf309EuEruNUm3Z02QtyaQ6yX664a4fLaLfgtTyG2YY3ETX0fkVfE8Eillxw1ka jHHO0ZBCuZ8OOMYUEagD7cny6fdum8bHcRDyADaKcukvNPU2aFLsM8baq3Pbs2L6hVas2tNjG VnknZ62nh+LCyacliPGaOaIHeKEHKs26MYEjdDMp7uLeCw0y26eNeMVnUoDBAdFhWVkXvaf9l NCIOAKKH2wE5sOh6l5W1jhBD0/uznwiDqH/riINwFsQpuwCwzOdVte+xhitKGl5/2qi7H3vNv cZWVBXlJZ8O6LWBvVgd7pNirTxW2XeYrc6l9euWnuswXf+w04A8DDr/9vPcCvnYFdjSyt7JsT 3H7U/jucWBstF6kID Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 12:20:31 -0000 On 19.03.2020 12:35, Henrik Levkowetz wrote: > Hi John, > > On 2020-03-18 22:33, John R Levine wrote: >>>> What's currently implemented aims to follow RFC 7997, which is the re= levant >>>> RFC in this case, I believe. >>> >>> FWIW, RFC 7997 explains when using non-ASCII characters is ok. That do= es >>> not necessarily imply that the vocabulary needs to enforce that >>> (otherwise, RFC 7997 would be in conflict with RFC 7991, which IMHO is >>> not the case). >> >> It seems to me that a fair amount of 7997 became obsolete once we start= ed >> publishing in v3. I'll run it past the RSOC and see what they think. > > That's not the line Heather took. She talked about doing a 7997bis afte= r > experience with v3 schema *and* RFC 7997. > > It's also not backed up by the RFCs as published: since RFC 7997 was > published as part of the v3 RFC 7991-7998 group of RFCs, I don't think > you can argue that the using the schema from that group (RFC 7991) > renders another RFC from that cluster (RFC 7997) obsolete. Absolutely; these were *meant* to be consistent. Speaking of which: once we start actually revising those, we need to include the RFC Style Guide into this. It doesn't make sense to have Style requirements that can not be met by the tools; on the other hand, what we discover when writing/testing the tools needs to inform decisions on the Style Guide. > This would be a major shift in policy. I'm not arguing for or against > the actual change in saying this; but I am saying that it's a major chan= ge, > and I don't think it's appropriate to do it without wider discussion and= a > 7997bis document. > > (On the actual change, I think it is quite reasonable to permit the full > Latin script range in running text. I'm more doubtful about moving +1. > directly to permitting the full unicode range without more experience wi= th > v3 publication. There are too many pitfalls there. Just handling full-= width > and half-width CJK glyphs and right-to-left scripts in the limited locat= ions > we permit them now has been a challenge, and I don't think we've had man= y > actual instances of publishing documents using such yet.) True. Best regards, Julian From nobody Thu Mar 19 05:31:13 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313FE3A2894 for ; Thu, 19 Mar 2020 05:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kWTjktEV5qtN for ; Thu, 19 Mar 2020 05:31:10 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26893A2890 for ; Thu, 19 Mar 2020 05:31:09 -0700 (PDT) Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48jmV40891zyyr; Thu, 19 Mar 2020 13:31:07 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Carsten Bormann In-Reply-To: <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> Date: Thu, 19 Mar 2020 13:31:07 +0100 Cc: Henrik Levkowetz , John R Levine , xml2rfc@ietf.org X-Mao-Original-Outgoing-Id: 606313867.514647-fc57ad8ae6e1600389500bdc8745b262 Content-Transfer-Encoding: quoted-printable Message-Id: <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 12:31:12 -0000 On 2020-03-19, at 13:19, Julian Reschke wrote: >=20 >> (On the actual change, I think it is quite reasonable to permit the = full >> Latin script range in running text. I'm more doubtful about moving >=20 > +1. >=20 >> directly to permitting the full unicode range without more experience = with >> v3 publication. There are too many pitfalls there. Just handling = full-width >> and half-width CJK glyphs and right-to-left scripts in the limited = locations >> we permit them now has been a challenge, and I don't think we've had = many >> actual instances of publishing documents using such yet.) There is something in between Latin and full Unicode: math symbols etc. Adding characters is much easier if they are compatible with the Latin = writing system; we should not put math symbols into the same bin as RTL = and scripts with complicated combining characters (the latter are only = needed in those RFCs that have them as subject matter, and is = already geared to those). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 19 07:19:34 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F363A15DE for ; Thu, 19 Mar 2020 07:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 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, MISSING_HEADERS=1.021, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=DAhjZpOG; dkim=pass (1536-bit key) header.d=taugh.com header.b=q/AvO+BX 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 pR5WPi7k3a78 for ; Thu, 19 Mar 2020 07:19:30 -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 6BDD73A15DC for ; Thu, 19 Mar 2020 07:19:30 -0700 (PDT) Received: (qmail 95394 invoked from network); 19 Mar 2020 14:19:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1749f.5e737f70.k2003; i=johnl-iecc.com@submit.iecc.com; bh=TBB1eCbRvjVFL09KSoCqieODg+R/EF48XLXcWdFPY5Q=; b=DAhjZpOGf7/VtzCTFcbUis6S7XmLI1uDPJ+EQgGUDC7agXXClEpaNcvTSDkZqZwnhVxXwZanpXXRpPBwpXxq/zXMx1MWJcn61G9H7YyA1pKfsKu9edthhM0iVo2Sg7WGOK9IGqd51XgHuIEH/PsRrIRgVuNyMN2O7sXKkXy22KMWe2haVTzvnD0aq8/ngcfJuxDc14P64QsdMFr0kCqPArZkSXMPwNzc+LJH2dt1FdlP0Lglcf22TmX3h1fguQPX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=1749f.5e737f70.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=TBB1eCbRvjVFL09KSoCqieODg+R/EF48XLXcWdFPY5Q=; b=q/AvO+BXWikoNFUaN+KPFPZeImMWytmGbJX6A6aC/7d1+B7Fo1Fj5fJY1+jIi2cI8x1Nn6MPbL5rW8nWsirFiOUWt+MKWjZgD88dhP3pQRrA053pFfsF7Hnini84WydRiFdqTK/Zjd2G2XjqrZYav6ezhlxoj150/rCRJjFIfjDvNjad5x7oCti2WGYe3eFr/BJ5Xxq5wXvcLb26q9YAYMAfHJT5V7tKjB4+2qsHrHdGgKbJEEKe38qhmfx5v4/j Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Mar 2020 14:19:28 -0000 Date: 19 Mar 2020 10:19:27 -0400 Message-ID: From: "John R Levine" Cc: "Henrik Levkowetz" , xml2rfc@ietf.org In-Reply-To: <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> User-Agent: Alpine 2.22 (OSX 407 2020-02-09) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 14:19:32 -0000 Thanks for all of the thoughtful comments. > Adding characters is much easier if they are compatible with the Latin writing system; we should not put math symbols into the same bin as RTL and scripts with complicated combining characters (the latter are only needed in those RFCs that have them as subject matter, and is already geared to those). Could we say something like single width LTR characters? I wouldn't think it would be hard to render, say, Cyrillic in line. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Mar 19 07:24:57 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9A03A2A3A for ; Thu, 19 Mar 2020 07:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yGdhRd5GXr6q for ; Thu, 19 Mar 2020 07:24:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 434423A2A40 for ; Thu, 19 Mar 2020 07:24:53 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57318 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jEw64-0006mE-By; Thu, 19 Mar 2020 07:24:52 -0700 To: Carsten Bormann References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> Cc: John R Levine , xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com> Date: Thu, 19 Mar 2020 15:24:24 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="afxkSdk0Qh4Bjeudd1U18wqJeqOw3IiMe" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com, cabo@tzi.org X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 14:24:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --afxkSdk0Qh4Bjeudd1U18wqJeqOw3IiMe Content-Type: multipart/mixed; boundary="xo5Gf9C076dBEHaVrFrbLf7RGu3S0skL6"; protected-headers="v1" From: Henrik Levkowetz To: Carsten Bormann Cc: John R Levine , xml2rfc@ietf.org Message-ID: <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com> Subject: Re: [xml2rfc] Silly unicode question References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> In-Reply-To: <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> --xo5Gf9C076dBEHaVrFrbLf7RGu3S0skL6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carsten, On 2020-03-19 13:31, Carsten Bormann wrote: > On 2020-03-19, at 13:19, Julian Reschke wrote: >>=20 >>> (On the actual change, I think it is quite reasonable to permit the f= ull >>> Latin script range in running text. I'm more doubtful about moving >>=20 >> +1. >>=20 >>> directly to permitting the full unicode range without more experience= with >>> v3 publication. There are too many pitfalls there. Just handling fu= ll-width >>> and half-width CJK glyphs and right-to-left scripts in the limited lo= cations >>> we permit them now has been a challenge, and I don't think we've had = many >>> actual instances of publishing documents using such yet.) >=20 > There is something in between Latin and full Unicode: math symbols > etc. When math symbols were first brought up, I looked into permitting them inline, and found to my frustration that there's not any single script or= unicode block that is suitable for inclusion; the best I could come up with is captured in Section 5.1 of my implementation notes: https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not= es-10#section-5.1 > Adding characters is much easier if they are compatible with the > Latin writing system; we should not put math symbols into the same > bin as RTL and scripts with complicated combining characters (the > latter are only needed in those RFCs that have them as subject > matter, and is already geared to those). Well, yes; but on the other hand simply saying 'Latin script' is more problematic than I made it sound above; they include half-width, full-wid= th and spacing modified characters that complicate matters: https://en.wikipedia.org/wiki/Latin_script_in_Unicode The easiest approach that would still be fairly inclusive might be to say= 'Latin script below U+2000'. Henrik --xo5Gf9C076dBEHaVrFrbLf7RGu3S0skL6-- --afxkSdk0Qh4Bjeudd1U18wqJeqOw3IiMe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5zgJgACgkQTptXS4+7 Fxr1Ug/9Hqcv1uadTScLYLIHsDU/8mx297BQUUMPAu4NMTGuU5IIZ3XhT8+0fPvk wmlA5fvqRalxKmYnIcDqjNkFSFcbMdpwrPfU3C4tMx3EfpS9FgJx3/oSgxM3GbBD ZUsPcRdkC/PF3mjcv0edWIU6mMce3hbfKr7nZYDAswFDg1rHTGrGSFKgrlKQgBKb TlYa7DDlBXWapHPmSaFbdDlXY1DpCBfgaO+Tdf4B+9sC9+Wl/rLtXnPtUGKPtxMQ Me/5mIt7mIynztpjxo7gEs4pmyNFmUovPzG/e+4Cccyb1gAXY57GetfEraYXQC9o O/l1m4x4BwmvcF1aV59X6ZwbbmzGf22YKoEMOs0slSZXYKOOL1rPFShuQIFZCUeg fditu6s5PM+n7vx2rY5IWJ1mB3mgDSzmC0wm7AJnP8YCa1vYDYx/we5oQgeh0/Mt HLsM0Do2f8OrjA4Xr8PcD7lV7PDYg29eSATLgLg33TIy0mw5Db0T/mRpNkrIKLSA mAyNtV3FkgWWsOB2fmncjJ1hmGsp9aXBBoHyH0ebc4n0sQ9V4iF8wNdoUigYfM23 4/okFAaddQKDzPFXatuoHpBiT+n1EcFyIYSmjMOlGQyPcdETjyN+zKNvfS5q2YPj pK2lG0WUlUiPhA0HfIDKsIaRE0KjEV+00qmlWTKXRI+vMoxkI5U= =DkBd -----END PGP SIGNATURE----- --afxkSdk0Qh4Bjeudd1U18wqJeqOw3IiMe-- From nobody Thu Mar 19 07:31:57 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C1A3A2A94 for ; Thu, 19 Mar 2020 07:31:50 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHPZl0I0cUBD for ; Thu, 19 Mar 2020 07:31:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 662A23A2A8C for ; Thu, 19 Mar 2020 07:31:48 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57337 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jEwCl-00023S-G6; Thu, 19 Mar 2020 07:31:47 -0700 To: John R Levine References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> Cc: xml2rfc@ietf.org From: Henrik Levkowetz Message-ID: Date: Thu, 19 Mar 2020 15:31:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vw59TKOToII3USMPWEjDNPg495JucP3IA" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 14:31:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vw59TKOToII3USMPWEjDNPg495JucP3IA Content-Type: multipart/mixed; boundary="BBB7RBSDBgnbsvqx0W7hF0XdjLtEBubtg"; protected-headers="v1" From: Henrik Levkowetz To: John R Levine Cc: xml2rfc@ietf.org Message-ID: Subject: Re: [xml2rfc] Silly unicode question References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> In-Reply-To: --BBB7RBSDBgnbsvqx0W7hF0XdjLtEBubtg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, On 2020-03-19 15:19, John R Levine wrote: > Thanks for all of the thoughtful comments. >=20 >> Adding characters is much easier if they are compatible with the Latin= writing system; we should not put math symbols into the same bin as RTL = and scripts with complicated combining characters (the latter are only ne= eded in those RFCs that have them as subject matter, and is already g= eared to those). >=20 > Could we say something like single width LTR characters? I wouldn't th= ink=20 > it would be hard to render, say, Cyrillic in line. It sounds as if you're seriously considering obsoleting RFC 7997 outside the usual process, based only on discussion on this list. I think this needs much wider discussion than what we get here. What I've written on this issue in my recent messages tried to address wh= at might make sense or not given a revision of RFC 7997. If we are now goin= g to land on saying anything particular that overrides 7997 without a -bis,= I'm not comfortable with the direction. Henrik --BBB7RBSDBgnbsvqx0W7hF0XdjLtEBubtg-- --vw59TKOToII3USMPWEjDNPg495JucP3IA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5zgjgACgkQTptXS4+7 FxpIDRAAsDgp5agz0iI6uqE+09Vpe54Qe+E1KsjoQip55QbjA1HEdyrxnSJ5UZIW iM+QTTFzd7j2AEgYo6mw4Wv6xwK8AF4Q4JSGkgMFtr0yTPvnQr0Nl7CahaSG1kH/ YmBamBubQspGa+zR95svXK7zlo/F7pV0OKdGcE0tVOS2gSUJn4He8PF6RRcpmK0J t7Bko4S6L/oszQsEophA6OOOXw8WCUDCiZvVRVZ+asiuYBBE0/TzKQgjTzBiKZgo WXBShnDbcvnHtcMMWxYvpV0kE25XerWEHiV6xeW65PTJsjA9FrZHnlHkY6ca728I B+DvofbN3aZUb1abad4Lc7zg2GPis3pp0X/xCmkPEsvOV0Czug0vgFdrmKGbPgPA 2/u1NtxoS9LDDaGOWL5lo6SkIz1N4BSMx/yRAmM9Za/Gul6YqpDGYXs+Im8pvLkQ IlDAFHeb8BUZ72+VIwpUlAGZijK6lFmF9Kr5gEoiUqTzwlIzohz688Whc6eNO/oJ Tj8wHKmwGOjxc0geqG9+dLlHFGG8PcNDv52N2NnDs8fuCcks/muCTllCFC4chMfp oDa3QQfDqwo4b71IyWiEw83MBfqx43+WBB6enZ60kdnxU9aD65Uk+KGF1OD5Ur4u XZWaw30yPCGMDcFkvfyyZFfPdL9AMeiXC1lgjzg9ZaYiFcgRXN0= =aPQb -----END PGP SIGNATURE----- --vw59TKOToII3USMPWEjDNPg495JucP3IA-- From nobody Thu Mar 19 07:34:05 2020 Return-Path: X-Original-To: xml2rfc@ietfa.amsl.com Delivered-To: xml2rfc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4DC3A2A66 for ; Thu, 19 Mar 2020 07:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 Qq7QLX-5Ptek for ; Thu, 19 Mar 2020 07:34:00 -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 0144D3A2A53 for ; Thu, 19 Mar 2020 07:33:59 -0700 (PDT) Received: from unescapeable.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 02JEXvXi015332 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Mar 2020 09:33:58 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1584628439; bh=hRvJhFAA5Vf7vAaMlAJVmFp0zjQFMJWqQFswKnJtfic=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QLNJYAiFbrSrgMVa4Brjpa3ya7gX4kOmCgYfA3By7Ne3BC9poKTS3stECJqonS8+a vufR/Wz1UplQThCKhjZQObusatkHq80V+jobcZ0IbqI+ZAgxxPxYJctSqdQV6es7qP z1fJUhY7QgvlOGL0JZvWrgk5hKzAgHXsbQnqgZ9o= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be unescapeable.local To: Henrik Levkowetz , Carsten Bormann Cc: xml2rfc@ietf.org, John R Levine References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de> <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com> From: Robert Sparks Message-ID: Date: Thu, 19 Mar 2020 09:33:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com> Content-Type: multipart/alternative; boundary="------------5DB41B42A65C3398CCE82F71" Content-Language: en-US Archived-At: Subject: Re: [xml2rfc] Silly unicode question X-BeenThere: xml2rfc@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2020 14:34:02 -0000 This is a multi-part message in MIME format. --------------5DB41B42A65C3398CCE82F71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 3/19/20 9:24 AM, Henrik Levkowetz wrote: > Hi Carsten, > > On 2020-03-19 13:31, Carsten Bormann wrote: >> On 2020-03-19, at 13:19, Julian Reschke wrote: >>>> (On the actual change, I think it is quite reasonable to permit the full >>>> Latin script range in running text. I'm more doubtful about moving >>> +1. >>> >>>> directly to permitting the full unicode range without more experience with >>>> v3 publication. There are too many pitfalls there. Just handling full-width >>>> and half-width CJK glyphs and right-to-left scripts in the limited locations >>>> we permit them now has been a challenge, and I don't think we've had many >>>> actual instances of publishing documents using such yet.) >> There is something in between Latin and full Unicode: math symbols >> etc. > When math symbols were first brought up, I looked into permitting them > inline, and found to my frustration that there's not any single script or > unicode block that is suitable for inclusion; the best I could come up > with is captured in Section 5.1 of my implementation notes: > > https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-5.1 We also need to be sensitive to what's available in the fonts we've decided are ok to use. > >> Adding characters is much easier if they are compatible with the >> Latin writing system; we should not put math symbols into the same >> bin as RTL and scripts with complicated combining characters (the >> latter are only needed in those RFCs that have them as subject >> matter, and is already geared to those). > Well, yes; but on the other hand simply saying 'Latin script' is more > problematic than I made it sound above; they include half-width, full-width > and spacing modified characters that complicate matters: > https://en.wikipedia.org/wiki/Latin_script_in_Unicode > > The easiest approach that would still be fairly inclusive might be to say > 'Latin script below U+2000'. > > > Henrik > > > _______________________________________________ > xml2rfc mailing list > xml2rfc@ietf.org > https://www.ietf.org/mailman/listinfo/xml2rfc --------------5DB41B42A65C3398CCE82F71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit


On 3/19/20 9:24 AM, Henrik Levkowetz wrote:
Hi Carsten,

On 2020-03-19 13:31, Carsten Bormann wrote:

On 2020-03-19, at 13:19, Julian Reschke <julian.reschke@gmx.de> wrote:


          

            
(On the actual change, I think it is quite reasonable to permit the full
Latin script range in running text.  I'm more doubtful about moving


          

          
+1.



          

            
directly to permitting the full unicode range without more experience with
v3 publication.  There are too many pitfalls there.  Just handling full-width
and half-width CJK glyphs and right-to-left scripts in the limited locations
we permit them now has been a challenge, and I don't think we've had many
actual instances of publishing documents using such yet.)


          

        

        
There is something in between Latin and full Unicode: math symbols
etc.


      

      
When math symbols were first brought up, I looked into permitting them
inline, and found to my frustration that there's not any single script or
unicode block that is suitable for inclusion; the best I could come up
with is captured in Section 5.1 of my implementation notes:

https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-5.1

    

    We also need to be sensitive to what's available in the fonts we've
    decided are ok to use.

    

      



      

        
Adding characters is much easier if they are compatible with the
Latin writing system; we should not put math symbols into the same
bin as RTL and scripts with complicated combining characters (the
latter are only needed in those RFCs that have them as subject
matter, and <u> is already geared to those).


      

      
Well, yes; but on the other hand simply saying 'Latin script' is more
problematic than I made it sound above; they include half-width, full-width
and spacing modified characters that complicate matters:
https://en.wikipedia.org/wiki/Latin_script_in_Unicode

The easiest approach that would still be fairly inclusive might be to say
'Latin script below U+2000'.


	Henrik



      

      

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


    

  


--------------5DB41B42A65C3398CCE82F71--


From nobody Thu Mar 19 07:51:11 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AC83A2ACC for ; Thu, 19 Mar 2020 07:51:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=wGXh3Ifs; dkim=pass (1536-bit key) header.d=taugh.com header.b=J2qjrutN
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 p7gxE_MJ5qLo for ; Thu, 19 Mar 2020 07:50:59 -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 A2CD93A2AE0 for ; Thu, 19 Mar 2020 07:50:59 -0700 (PDT)
Received: (qmail 3462 invoked from network); 19 Mar 2020 14:50:58 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d80.5e7386d2.k2003; i=johnl-iecc.com@submit.iecc.com; bh=JpsvieasWVhMtVMXHOlDeI/8fmXQm9mCHB/zU9QfdNI=; b=wGXh3IfsxXBdzciTMdi1OHBR0QRCvDNOPCqltponAKEh1VBg5fk18y5dQfJpYcxH0X593tXLeGZ4z7Dr8BybDlTmfK0dQaKOSyV8EarELMrqgvfi0hTb0YySovu84OzrnshH7w4S1QTybLlSZRCJPDPTzwrM1C6pLGzgd9GywDvor2szadRCKNwlF3q/+kidr+cqiWVfCWTek7YazfEVfNqj+HDEgKi0owO3T0EO9HvWC1dmTu2GGi5EPKcAeBMI
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=d80.5e7386d2.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=JpsvieasWVhMtVMXHOlDeI/8fmXQm9mCHB/zU9QfdNI=; b=J2qjrutNP7Qm1DBsLVK0yq+uGpKlm+rXudq9kj5S6LPldgyIuNJppvONm4f2XY1CzISUVEUaB/82FLjDtvxJWLf+z0fbbbkFilDFDMOSKX5SxOeOoQ1EqOhHQfYY/25u6MkT2+4ZTDLI/XOZenUOAHrAjOLFqDNWfftkHTVoyprwtIYQx/dsex/hbJ/SLFk5tL595rmnS0o6ROTZh++BvshqqaUTsdIWsWkzhzhMT13B/wFwisDMWB73hXvBqNlz
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Mar 2020 14:50:58 -0000
Date: 19 Mar 2020 10:50:57 -0400
Message-ID: 
From: "John R Levine" 
To: "Henrik Levkowetz" 
Cc: xml2rfc@ietf.org
In-Reply-To: 
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org>  
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 14:51:09 -0000

>> Could we say something like single width LTR characters?  I wouldn't think
>> it would be hard to render, say, Cyrillic in line.
>
> It sounds as if you're seriously considering obsoleting RFC 7997 outside
> the usual process, based only on discussion on this list.  I think this
> needs much wider discussion than what we get here.

Remember, I don't get to decide anything.  But I'm trying to figure out 
what to proposed to RSOC et al.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Thu Mar 19 08:50:14 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409183A07EC for ; Thu, 19 Mar 2020 08:49:26 -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=cryptonector.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 62MSQeNbjcc6 for ; Thu, 19 Mar 2020 08:49:24 -0700 (PDT)
Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) (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 15EBB3A07EB for ; Thu, 19 Mar 2020 08:49:23 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1F15A221EE; Thu, 19 Mar 2020 15:49:23 +0000 (UTC)
Received: from pdx1-sub0-mail-a87.g.dreamhost.com (100-96-206-102.trex.outbound.svc.cluster.local [100.96.206.102]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 56B3B21D25; Thu, 19 Mar 2020 15:49:22 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a87.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 19 Mar 2020 15:49:22 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Tangy-Desert: 4bc927be1950b0e3_1584632962838_1445638879
X-MC-Loop-Signature: 1584632962838:2830250589
X-MC-Ingress-Time: 1584632962838
Received: from pdx1-sub0-mail-a87.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a87.g.dreamhost.com (Postfix) with ESMTP id 141A6B279B; Thu, 19 Mar 2020 08:49:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=goPo6EQ9xJD7rD 9DdNrR/6u+eMk=; b=SxVJbfanSFgOOg/+BBMs77By5f5VR8D+f1/qYNXoDfC3H9 5dkTrQgfqxCDRR5KUT1wcECdYFdSWsc6e8lchH9vJuv1Um3bCv8IdyrWboVh2irA fpvIJLUzVtkDeOFUr6jNrWTbhL0Ejga8885D3jhZcotsgoGk+HknrcSMXMhmE=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 0F3D8B2796; Thu, 19 Mar 2020 08:49:14 -0700 (PDT)
Date: Thu, 19 Mar 2020 10:49:12 -0500
X-DH-BACKEND: pdx1-sub0-mail-a87
From: Nico Williams 
To: Carsten Bormann 
Cc: Julian Reschke , xml2rfc@ietf.org, John R Levine 
Message-ID: <20200319154910.GM18021@localhost>
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <86cd9bb9-73f2-cdbf-46a3-56f617111e6a@gmx.de> <2B016B4F-B152-4504-BB3A-555BF03F4620@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2B016B4F-B152-4504-BB3A-555BF03F4620@tzi.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedugedrudefledgkeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 15:49:26 -0000

On Thu, Mar 19, 2020 at 12:41:38PM +0100, Carsten Bormann wrote:
> On 2020-03-19, at 12:37, Julian Reschke  wrote:
> > 
> > When RFC 7991 and 7997 were written, the idea was that use of non-ASCII
> > characters would *not* be controlled by the vocabulary, but by the
> > Production Center. 
> 
> I think this is an important point:  If we want to automate some of
> the checks that RPC would be doing, the place to automate this is
> idnits or an idnits-like tool, not xml2rfc (maybe outside of
> warnings).  Specifically, xml2rfc is also used for authoring I-Ds,
> where none of these restrictions make sense.

+1.

xml2rfc is a typesetting tool.  It should not complain about non-ASCII
character usage (perhaps it could warn, but that's it).

Nico
-- 


From nobody Thu Mar 19 08:50:16 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6CC3A07E3 for ; Thu, 19 Mar 2020 08:49:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uSrR0jFrGGNZ for ; Thu, 19 Mar 2020 08:49:52 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819813A07E8 for ; Thu, 19 Mar 2020 08:49:51 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48jrvK4jlTz1006; Thu, 19 Mar 2020 16:49:49 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>
Date: Thu, 19 Mar 2020 16:49:49 +0100
Cc: John R Levine , xml2rfc@ietf.org
X-Mao-Original-Outgoing-Id: 606325789.0356489-4f2110d50ca2bbd2a8ccd3d88a9829fc
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>
To: Henrik Levkowetz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 15:49:55 -0000

> On 2020-03-19, at 15:24, Henrik Levkowetz  =
wrote:
>=20
> Hi Carsten,
>=20
> On 2020-03-19 13:31, Carsten Bormann wrote:
>> On 2020-03-19, at 13:19, Julian Reschke  =
wrote:
>>>=20
>>>> (On the actual change, I think it is quite reasonable to permit the =
full
>>>> Latin script range in running text.  I'm more doubtful about moving
>>>=20
>>> +1.
>>>=20
>>>> directly to permitting the full unicode range without more =
experience with
>>>> v3 publication.  There are too many pitfalls there.  Just handling =
full-width
>>>> and half-width CJK glyphs and right-to-left scripts in the limited =
locations
>>>> we permit them now has been a challenge, and I don't think we've =
had many
>>>> actual instances of publishing documents using such yet.)
>>=20
>> There is something in between Latin and full Unicode: math symbols
>> etc.
>=20
> When math symbols were first brought up, I looked into permitting them
> inline, and found to my frustration that there's not any single script =
or
> unicode block that is suitable for inclusion;

So just include everything in the tool and let RPC sort it out.

> the best I could come up
> with is captured in Section 5.1 of my implementation notes:
>=20
> =
https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-note=
s-10#section-5.1
>=20
>> Adding characters is much easier if they are compatible with the
>> Latin writing system; we should not put math symbols into the same
>> bin as RTL and scripts with complicated combining characters (the
>> latter are only needed in those RFCs that have them as subject
>> matter, and  is already geared to those).
>=20
> Well, yes; but on the other hand simply saying 'Latin script' is more
> problematic than I made it sound above; they include half-width, =
full-width
> and spacing modified characters that complicate matters:
> https://en.wikipedia.org/wiki/Latin_script_in_Unicode
>=20
> The easiest approach that would still be fairly inclusive might be to =
say
> 'Latin script below U+2000'.

That leaves out some of the most crucial elements of the Latin writing =
system: punctuation.

It also leaves out the math symbols, arrows, Latin extended C, ...

Whatever we come up with here is going to be bizarre.

Again, there is little gain from the formatting tool enforcing a =
specific snapshot of what was considered useful at some time by a small =
group that of course didn=E2=80=99t encompass the author that is trying =
to do something that is obvious to his peer group.

Gr=C3=BC=C3=9Fe, Carsten


>=20
>=20
> 	Henrik


From nobody Thu Mar 19 09:24:09 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40EEB3A08EC for ; Thu, 19 Mar 2020 09:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4LDHyorNFmXs for ; Thu, 19 Mar 2020 09:23:39 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BE33A08B3 for ; Thu, 19 Mar 2020 09:23:38 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57670 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jExwx-0005mA-F1; Thu, 19 Mar 2020 09:23:37 -0700
To: Carsten Bormann 
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com> 
Cc: John R Levine , xml2rfc@ietf.org
From: Henrik Levkowetz 
Message-ID: <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com>
Date: Thu, 19 Mar 2020 17:23:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IFA69SIjAehMw4qn1ORl4d6xr6WjDhv2K"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com, cabo@tzi.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 16:23:49 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IFA69SIjAehMw4qn1ORl4d6xr6WjDhv2K
Content-Type: multipart/mixed; boundary="kus3WUBrWuU1lkVOlbRrS9cWWJbkceBa8";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Carsten Bormann 
Cc: John R Levine , xml2rfc@ietf.org
Message-ID: <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com>
Subject: Re: [xml2rfc] Silly unicode question
References: <20200318204634.50D31163CA18@ary.qy>
 <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com>
 <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>
 
 <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com>
 <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de>
 <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org>
 <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>
 
In-Reply-To: 

--kus3WUBrWuU1lkVOlbRrS9cWWJbkceBa8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Carsten,

On 2020-03-19 16:49, Carsten Bormann wrote:
>=20
>=20
>> On 2020-03-19, at 15:24, Henrik Levkowetz  wrote=
:
>>=20
>> Hi Carsten,
>>=20
>> On 2020-03-19 13:31, Carsten Bormann wrote:
>>> On 2020-03-19, at 13:19, Julian Reschke  wrote=
:
>>>>=20
>>>>> (On the actual change, I think it is quite reasonable to permit the=
 full
>>>>> Latin script range in running text.  I'm more doubtful about moving=

>>>>=20
>>>> +1.
>>>>=20
>>>>> directly to permitting the full unicode range without more experien=
ce with
>>>>> v3 publication.  There are too many pitfalls there.  Just handling =
full-width
>>>>> and half-width CJK glyphs and right-to-left scripts in the limited =
locations
>>>>> we permit them now has been a challenge, and I don't think we've ha=
d many
>>>>> actual instances of publishing documents using such yet.)
>>>=20
>>> There is something in between Latin and full Unicode: math symbols
>>> etc.
>>=20
>> When math symbols were first brought up, I looked into permitting them=

>> inline, and found to my frustration that there's not any single script=
 or
>> unicode block that is suitable for inclusion;
>=20
> So just include everything in the tool and let RPC sort it out.
>=20
>> the best I could come up
>> with is captured in Section 5.1 of my implementation notes:
>>=20
>> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-=
notes-10#section-5.1
>>=20
>>> Adding characters is much easier if they are compatible with the
>>> Latin writing system; we should not put math symbols into the same
>>> bin as RTL and scripts with complicated combining characters (the
>>> latter are only needed in those RFCs that have them as subject
>>> matter, and  is already geared to those).
>>=20
>> Well, yes; but on the other hand simply saying 'Latin script' is more
>> problematic than I made it sound above; they include half-width, full-=
width
>> and spacing modified characters that complicate matters:
>> https://en.wikipedia.org/wiki/Latin_script_in_Unicode
>>=20
>> The easiest approach that would still be fairly inclusive might be to =
say
>> 'Latin script below U+2000'.
>=20
> That leaves out some of the most crucial elements of the Latin writing =
system: punctuation.

Umm.  Which Latin-script code points are you referring to here?=20

> It also leaves out the math symbols, arrows,=20

And here?

> Latin extended C, ...

Yes, agreed. =20

>=20
> Whatever we come up with here is going to be bizarre.
>=20
> Again, there is little gain from the formatting tool enforcing a
> specific snapshot of what was considered useful at some time by a
> small group that of course didn=E2=80=99t encompass the author that is =
trying
> to do something that is obvious to his peer group.

Which is why I'm advocating taking this to a wider audience and doing a
7997bis if we're going to do changes from what 7997 requires.




--kus3WUBrWuU1lkVOlbRrS9cWWJbkceBa8--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5znGsACgkQTptXS4+7
FxqOpg//S3tGp8F5/fCVATowpoTIAfPDJhcTHQN9fprKkY7l9ScR7r1/wFO06zF6
D3uJ8fguVE0h4i/XSgmDarClgnJOoJRcq20RWkVVly2DZpge/ak14qOJAkj6Ghv7
S+yt6AJcAhmirNayz0ueqy2jBdSGc9cK7SuWa5SKIFxc0SUvx5GrOXt1Mi0YnJ3m
DT1H9Td3gTsHF+T9QWFDO9HPd5Az+jaYsqN03VVstNtdXssyBczT0XH220XiF1b7
BeAIpEB1PaooWx7DeOxHqWCyBLkXU67wOx8ZjNLlY9LMYU9OtUOvelTL5q/T01Ni
CYjW4CdIOPWYKqUQr7AImP19f7RAZliVKXAn5tvMTo8mLHR4ksHO2NqZJo2JUYP9
Rs9ypApFIQEuerTZaIfB15F6D0eriUP8syZPpfT69h/vbT3R0eU5VqFk1kq0hVwA
/MNBeQOMoRJupyj6FzC0A/yGQ+wnyDwRuW4P/UdKbEF9A0SAyb7WzLtS99RQwwv2
tsdEwjvVCafik8Epq12bCoe1ao/2Tg11laYfnPM60DrNEUIWxI9F9/O9K75SNexN
rXTLmV+iRGe3aUA3neDE0N6T2WBCtYpcGUF/i470dXX2sx9WsXFdG4kRR1c4nHJY
3lCs+2YNlfgLNsYi9s2cTohRiSFgxO+gJNzHKkiG5TohIhkIqeI=
=Uf4L
-----END PGP SIGNATURE-----

--IFA69SIjAehMw4qn1ORl4d6xr6WjDhv2K--


From nobody Thu Mar 19 09:36:50 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D843A08FA for ; Thu, 19 Mar 2020 09:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LezHagELrd8U for ; Thu, 19 Mar 2020 09:36:44 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 032DD3A0902 for ; Thu, 19 Mar 2020 09:36:38 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48jsxG14CWz1058; Thu, 19 Mar 2020 17:36:34 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com>
Date: Thu, 19 Mar 2020 17:36:33 +0100
Cc: John R Levine , xml2rfc@ietf.org
X-Mao-Original-Outgoing-Id: 606328593.100485-49b8794a344c349db80881831db22a67
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>  <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com>
To: Henrik Levkowetz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 16:36:49 -0000

>>>=20
>>> The easiest approach that would still be fairly inclusive might be =
to say
>>> 'Latin script below U+2000'.
>>=20
>> That leaves out some of the most crucial elements of the Latin =
writing system: punctuation.
>=20
> Umm.  Which Latin-script code points are you referring to here?=20

The whole range U+2000 to U+206F.
Includes dashes, quote marks, thin spaces, =E2=80=A6
Absolutely nondispensable.
(Did I mention the Euro sign?)

>=20
>> It also leaves out the math symbols, arrows,=20
>=20
> And here?

U+2190 to U+21FF for the arrows (U+27F0=E2=80=A6, U+2900=E2=80=A6, =
U+1F800=E2=80=A6).
U+2200 to U+22FF for math (and U+27C0..., U+2980..., U+2A00...).

>> Latin extended C, ...
>=20
> Yes, agreed. =20
>=20
>>=20
>> Whatever we come up with here is going to be bizarre.
>>=20
>> Again, there is little gain from the formatting tool enforcing a
>> specific snapshot of what was considered useful at some time by a
>> small group that of course didn=E2=80=99t encompass the author that =
is trying
>> to do something that is obvious to his peer group.
>=20
> Which is why I'm advocating taking this to a wider audience and doing =
a
> 7997bis if we're going to do changes from what 7997 requires.

RFC 7997 does not require any specific tool to try to figure out what it =
meant and implement draconic measures.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Thu Mar 19 09:43:39 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A9B3A0934 for ; Thu, 19 Mar 2020 09:43:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 TuW4glhN30lh for ; Thu, 19 Mar 2020 09:43:36 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 287753A092B for ; Thu, 19 Mar 2020 09:43:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584636158; bh=+DhE/uJQZl9CT5HnwbL1XF5bTeShyv5tNymHYxuhjDg=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=O39g4PCYTiOt3MTS5cxYN2k+2FttT07xWdwzTrnVVGRgJXgYO0wz0sMNdZsVcMIFt afLkHpRogC6S/Fz5NBkH/qTFnHjNclWphmIlOEgApDrRzARXrQiXeEpxnbzy8eI1kV BoyX9SyMlsV7lMVuwpg/uxFau3Z31aK1gJQCYcWQ=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([91.61.53.44]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mzyya-1jSfqS0F6c-00x7H9; Thu, 19 Mar 2020 17:42:38 +0100
To: John R Levine , Henrik Levkowetz 
Cc: xml2rfc@ietf.org
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org>   
From: Julian Reschke 
Message-ID: 
Date: Thu, 19 Mar 2020 17:42:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:a5Zxd8MSN3a6k9Lu5EIXJRU0rp5wHZtB3Cs40XzI+l1nI5tu60r 6U/jmiCAflMb32CHQRLz6I8C3MNQAPAmkIPg0+5FgYyLr8N57do2WGzxxXmJNxkxAFQXsig 6tD+PWwcaonFfruRT/w8TI681U3tiYFVv6/bTgiADplFvPf8C0dADwbtPvrSbwqNXDbNVNI xaO85H9DWWkfZ5OuUZwKw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:d4Hd0uN3nvo=:ioSTz3HNp8nB34/lRLtpol Uy/mBa37dWlCIXZuh15PAC2yTSPqDob34mUlK93LjzqYE/IHI43vex+Il160RtTsDWDBOeBPQ o2cBTYD400h+pQlWqFKonnxJWitoKSxAmGwXWeuzoVNBQN83iSH+lCHelnWeWQni6+ctFO/at KAn5pG7NJhPrixx332vzF4goB9CjhkdE1ruZG6V+Bz4hdZE1yEJJ7Ck0lFQQ7bKF1p1ZXIUWR FmLLs6YBqB6OhGszzSl3czy/MxgcY2E3aSCgwLMrGhmPkA1/z8jcHwFmowyRUAlL0Umdc9tN4 19thZ3fSQem4+RLKkEqJuvSQpkruUNzLNUVFKEvywu04PoQt/uMR6Kj3xL7RmS5e3dg2AF6KA 2QgqqjlAXfz5JZX4KXtrIpaFvxUaMupA5Qd/0lR0L18Xgwp9ECXnfHaRBo1lCSaiqlEfctY9q TlBlf3TKDg3lqGE8XqGrJ4V72FpG/N6SxC2Ayp9nTWr7WW1oUsEY0AWj5Kb/O7a2iW1cLGoNa fS91Tq+cN/zcS0yYueO7nf3P4TBSFa/KZB9KM5rZiSMOW6M4ALKD8YRR3n0H7m7Tzpv131NHj QvrKVPpK5szwCYjQn+CWMHLCvBB61myYmk6uwzTTZSfZLD2SwngeO3dJrsqdMbx/ZpDjUyDeX xOmEfgMVnLh5/efrUYx25YDguZyDQ5X+T99//4qrqSEXsSacPSpFXY51NgOTOSfon12m6Uhyd RwCHq4ZrY8KcmGxxTQZ8yqB7IZ3ANhHZ4Yv0Jtt4a4S2tHi7olTPIrpvTKoPRfFbj5lU6g6Mb LwCEXZVVuCKWrDx6Gqo1WsGB1wCbGJWbFGNYeT2r9m3mAou3nbTCRxbg0pje8ACP/5qV2g7Hs hzV+X0s0ga7UYpZu1Af+rBwu3Exxhv12eS+uWgkCHpZgX6UMGxKWJ/8vbDkexHBbdv92y5hQR eref492E81mzdnzh4smEN8grTH/9ZGjYRH4wMkcjcBikWffZ5m1ROT9pGVRDj/fDJNFHq/OrE 9GmByjT52Z87OtiB21vxB1N7bM00STiv2wu8glG77KEYc29RHep+OnkQ9CvkHnTFbGoWYzMDa bfmJm2aU5Y9D5451A+fOq5fvmB5/1TGkJ81tqYHXO8vM1VUVzWoMEMwYKxq+ONX+jiLV5fV6b mS76JzjVLkZOrd7E/81+EG2TEYsrfkgfxahOlWXzlcauV7fPYxiPfR4gOqcLUsiryEpuQebPr Nu3kNx3l6SScuEion
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 16:43:38 -0000

On 19.03.2020 15:50, John R Levine wrote:
>>> Could we say something like single width LTR characters?=C2=A0 I would=
n't
>>> think
>>> it would be hard to render, say, Cyrillic in line.
>>
>> It sounds as if you're seriously considering obsoleting RFC 7997 outsid=
e
>> the usual process, based only on discussion on this list.=C2=A0 I think=
 this
>> needs much wider discussion than what we get here.
>
> Remember, I don't get to decide anything.=C2=A0 But I'm trying to figure=
 out
> what to proposed to RSOC et al.
> ...

So is the *RSOC* supposed to decide?

Best regards, Julian


From nobody Thu Mar 19 10:04:27 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5BE13A0AA1 for ; Thu, 19 Mar 2020 10:04:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=gsxBmrsD; dkim=pass (1536-bit key) header.d=taugh.com header.b=fOnnWGnh
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 R4BcFq0k_7FV for ; Thu, 19 Mar 2020 10:04:02 -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 D268F3A0A49 for ; Thu, 19 Mar 2020 10:04:01 -0700 (PDT)
Received: (qmail 34049 invoked from network); 19 Mar 2020 17:04:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=84fe.5e73a600.k2003; i=johnl-iecc.com@submit.iecc.com; bh=23hwkPHUnkWAZDWsq/go4a1J1vCBSkl4QOjvaFBva2k=; b=gsxBmrsDkKccD7dbZtqmVXIw+NcKPY2oTr9H8DUAepHewQRsk2M3Kfz4blk6nGjizaQkzK0jzo9NJ15ARgkaEQXOBJFuLTr14rLltEp5wLRwjbK/zd4iIVpkuK9kCqEUnXB3jej3IYUSDtH0z1yglwUmmC0hIcyfvlbFAdQXnmxKZlSutTOUObS0Olp30IN4aIcpTwj09lnZ87Dq44BkwUWFT1uXEqEJA6QqMNQyAEQoZVLK7Q/Jyc6q8tNBo1At
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=84fe.5e73a600.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=23hwkPHUnkWAZDWsq/go4a1J1vCBSkl4QOjvaFBva2k=; b=fOnnWGnhrKpiHL1ChpJ3yXEjw40uJNw8CPkmxMp6Drb7PnIacqQoPakx8uMeAm7FyjVhcfEVUDof9Ekh+o7nx9sw2azZMgEns8FJIF5Aza2+qAqgA5RuJ+lqdX66aSmLYSzH1+vcHmlB/KIfe83dQQyidTm+iCFcFKYYe+6m3BOHgGGb+qObjBOBcJBczCG9A6MQbJSIt8Np/QtXsDM96aeIPoP2RwrP4BRbRSwRN2dUNsF0D0ot7Jzu2PuQ/lqG
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Mar 2020 17:04:00 -0000
Date: 19 Mar 2020 13:03:59 -0400
Message-ID: 
From: "John R Levine" 
To: "Julian Reschke" 
Cc: xml2rfc@ietf.org
In-Reply-To: 
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org>    
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-1149801112-1584637440=:96031"
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 17:04:17 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-1149801112-1584637440=:96031
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT

>> Remember, I don't get to decide anything.  But I'm trying to figure out
>> what to proposed to RSOC et al.
>
> So is the *RSOC* supposed to decide?

As I understand it, the policy authority I don't have went back to the 
RSOC until they appoint another real RSE.  Not clear how this will work in 
practice.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
--0-1149801112-1584637440=:96031--


From nobody Thu Mar 19 10:20:56 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4F93A0A3B for ; Thu, 19 Mar 2020 10:20:54 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iabNmSGYVg9M for ; Thu, 19 Mar 2020 10:20:52 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D5F3A0A32 for ; Thu, 19 Mar 2020 10:20:52 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57876 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jEyqN-0003ep-15; Thu, 19 Mar 2020 10:20:51 -0700
To: Carsten Bormann 
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>  <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com> 
Cc: John R Levine , xml2rfc@ietf.org
From: Henrik Levkowetz 
Message-ID: <4dd92c96-8096-af3c-e099-6c863d0b43a4@levkowetz.com>
Date: Thu, 19 Mar 2020 18:20:23 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kh9uiprcOU8rLcGvfl87VFa8CaFsWsDll"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, johnl@taugh.com, cabo@tzi.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 17:20:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Kh9uiprcOU8rLcGvfl87VFa8CaFsWsDll
Content-Type: multipart/mixed; boundary="cDxBR8cATLAJQ33aFcPh7hl0Ob1E1PT4t";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Carsten Bormann 
Cc: John R Levine , xml2rfc@ietf.org
Message-ID: <4dd92c96-8096-af3c-e099-6c863d0b43a4@levkowetz.com>
Subject: Re: [xml2rfc] Silly unicode question
References: <20200318204634.50D31163CA18@ary.qy>
 <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com>
 <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>
 
 <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com>
 <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de>
 <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org>
 <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>
 
 <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com>
 
In-Reply-To: 

--cDxBR8cATLAJQ33aFcPh7hl0Ob1E1PT4t
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Carsten,

On 2020-03-19 17:36, Carsten Bormann wrote:
>>>>=20
>>>> The easiest approach that would still be fairly inclusive might be t=
o say
>>>> 'Latin script below U+2000'.
>>>=20
>>> That leaves out some of the most crucial elements of the Latin writin=
g system: punctuation.
>>=20
>> Umm.  Which Latin-script code points are you referring to here?=20
>=20
> The whole range U+2000 to U+206F.
> Includes dashes, quote marks, thin spaces, =E2=80=A6
> Absolutely nondispensable.

Ok. Not part of the Unicode Latin script, though.

> (Did I mention the Euro sign?)
>=20
>>=20
>>> It also leaves out the math symbols, arrows,=20
>>=20
>> And here?
>=20
> U+2190 to U+21FF for the arrows (U+27F0=E2=80=A6, U+2900=E2=80=A6, U+1F=
800=E2=80=A6).
> U+2200 to U+22FF for math (and U+27C0..., U+2980..., U+2A00...).

Ok, but these aren't part of the Unicode Latin-script, either.

>=20
>>> Latin extended C, ...
>>=20
>> Yes, agreed. =20
>>=20
>>>=20
>>> Whatever we come up with here is going to be bizarre.
>>>=20
>>> Again, there is little gain from the formatting tool enforcing a
>>> specific snapshot of what was considered useful at some time by a
>>> small group that of course didn=E2=80=99t encompass the author that i=
s trying
>>> to do something that is obvious to his peer group.
>>=20
>> Which is why I'm advocating taking this to a wider audience and doing =
a
>> 7997bis if we're going to do changes from what 7997 requires.
>=20
> RFC 7997 does not require any specific tool to try to figure out what i=
t
> meant and implement draconic measures.

I think this is now becoming a discussion of the statement of work for th=
e
xml2rfc implementation of 7991-7998.

None of these RFCs require any specific tool to do anything, but that
doesn't mean that they don't apply.


	Henrik


--cDxBR8cATLAJQ33aFcPh7hl0Ob1E1PT4t--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl5zqdcACgkQTptXS4+7
FxqG7RAAhexSV098OZ3XQr6kz9aOaXNuJ8qs/Q1ASRwV0ZKFtrSRErNqVASmDOVG
B1GM9npLCYPn/WEPkcKDeuEvrbmW1+UbgBVXNZVaupj3yrelWJ1o2NoymH+y1zan
GxjyzaXlRQMLHhDWwC//I2Xx5lyKCnTbGJhxWS968bXUDFjBXdF9vfdk6+qYvEFm
cARwZ8lKNPdFBN/OXIWfuTM22L7SDDxAhfinlKWc1BWVizbu6lfA8dwNEW8o1z31
6a+P9WRIUokTDzMKITcZTF8Yoicdtx3p+e7CC9PMJtY8c6ZyeVMGIEIzVw7PDbKN
Lzv9DinrwpY/kgM2T8NKs5izlnlcgRS3Ft8ICa+pEO+y9VFGTNqUkjf1ZUcuXucP
gVozSZg/zZ9fXfN1eJoWDLOvDxmoZbE16z+UtMpAGzWabqYfCEeUbIZ8lIwiTxyf
uLea+wHxdJd46AdUpNuzffCNXsv5J1wbuqBhwE8sjWJ9Lxdstt5Jj28MX0hrHrjP
CDfbaMySEA6DO8XuyeFvqYb8moC0Z79N+vpqLz1OMH7cPWBEOBx8H4kKMQKiuqJx
PSzQYnd1/4DfqJTFMh9RgZqKhpoeTxDiL/aSrhhlFWwsedIY7ajZYr2O0L05/VPx
Uac9ws7ZaLzq+S/p30Vf+GxTTcCrwfGG8beWTGlCRed+xZv8Ztc=
=0Zxg
-----END PGP SIGNATURE-----

--Kh9uiprcOU8rLcGvfl87VFa8CaFsWsDll--


From nobody Thu Mar 19 10:28:57 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0703A0C05 for ; Thu, 19 Mar 2020 10:28:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cEUtTaXdGowH for ; Thu, 19 Mar 2020 10:28:52 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD103A0C04 for ; Thu, 19 Mar 2020 10:28:52 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48jv5Z1GY1z105m; Thu, 19 Mar 2020 18:28:48 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <4dd92c96-8096-af3c-e099-6c863d0b43a4@levkowetz.com>
Date: Thu, 19 Mar 2020 18:28:47 +0100
Cc: John R Levine , xml2rfc@ietf.org
X-Mao-Original-Outgoing-Id: 606331726.938575-157a71bdbb8ca2687b342af21cfa4927
Content-Transfer-Encoding: quoted-printable
Message-Id: <0BBFBE96-1237-4792-8342-F98C2DCF6A14@tzi.org>
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>  <7dab71fa-5a10-31b0-8b08-fb9de42e92cf@levkowetz.com>  <4dd92c96-8096-af3c-e099-6c863d0b43a4@levkowetz.com>
To: Henrik Levkowetz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 17:28:56 -0000

On 2020-03-19, at 18:20, Henrik Levkowetz  wrote:
>=20
> Hi Carsten,
>=20
> On 2020-03-19 17:36, Carsten Bormann wrote:
>>>>>=20
>>>>> The easiest approach that would still be fairly inclusive might be =
to say
>>>>> 'Latin script below U+2000'.
>>>>=20
>>>> That leaves out some of the most crucial elements of the Latin =
writing system: punctuation.
>>>=20
>>> Umm.  Which Latin-script code points are you referring to here?=20
>>=20
>> The whole range U+2000 to U+206F.
>> Includes dashes, quote marks, thin spaces, =E2=80=A6
>> Absolutely nondispensable.
>=20
> Ok. Not part of the Unicode Latin script, though.

No, because much punctuation is shared between a few scripts including =
the Latin one.
That doesn=E2=80=99t make it less essential.  It is just a coincidence =
that a small part of the punctuation we need already was in ASCII and =
there are workarounds known in the CS community to get by with that if =
necessary.

>> (Did I mention the Euro sign?)
>>=20
>>>=20
>>>> It also leaves out the math symbols, arrows,=20
>>>=20
>>> And here?
>>=20
>> U+2190 to U+21FF for the arrows (U+27F0=E2=80=A6, U+2900=E2=80=A6, =
U+1F800=E2=80=A6).
>> U+2200 to U+22FF for math (and U+27C0..., U+2980..., U+2A00...).
>=20
> Ok, but these aren't part of the Unicode Latin-script, either.

... which was what I was trying to point out: These do need to be part =
of the set that we consider normal in RFCs.

>=20
>>=20
>>>> Latin extended C, ...
>>>=20
>>> Yes, agreed. =20
>>>=20
>>>>=20
>>>> Whatever we come up with here is going to be bizarre.
>>>>=20
>>>> Again, there is little gain from the formatting tool enforcing a
>>>> specific snapshot of what was considered useful at some time by a
>>>> small group that of course didn=E2=80=99t encompass the author that =
is trying
>>>> to do something that is obvious to his peer group.
>>>=20
>>> Which is why I'm advocating taking this to a wider audience and =
doing a
>>> 7997bis if we're going to do changes from what 7997 requires.
>>=20
>> RFC 7997 does not require any specific tool to try to figure out what =
it
>> meant and implement draconic measures.
>=20
> I think this is now becoming a discussion of the statement of work for =
the
> xml2rfc implementation of 7991-7998.

I never read those and apparently should have.

> None of these RFCs require any specific tool to do anything, but that
> doesn't mean that they don't apply.

Indeed, no. =20
But then, RFC 3552 applies, too, and xml2rfc is not going to check =
compliance to that, either.

Gr=C3=BC=C3=9Fe, Carsten


From nobody Thu Mar 19 11:11:38 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829DB3A0C96 for ; Thu, 19 Mar 2020 11:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level: 
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 8raV_S40yHzy for ; Thu, 19 Mar 2020 11:11:34 -0700 (PDT)
Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18BBC3A0C91 for ; Thu, 19 Mar 2020 11:11:33 -0700 (PDT)
Received: from paris.clic.cs.columbia.edu (paris.clic.cs.columbia.edu [128.59.15.32]) by mailbackend.panix.com (Postfix) with ESMTPSA id 48jw2r5kTZzxsH; Thu, 19 Mar 2020 14:11:32 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <24179.46548.526870.186935@paris.clic.cs.columbia.edu>
Date: Thu, 19 Mar 2020 14:11:32 -0400
From: Jonathan Lennox 
To: Henrik Levkowetz 
Cc: Carsten Bormann , xml2rfc@ietf.org, John R Levine 
In-Reply-To: <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>
References: <20200318204634.50D31163CA18@ary.qy> <6af16a17-e8c9-b7f7-cab0-39e1238e4346@levkowetz.com> <4da246eb-982e-5f84-c242-d3fdda28e9a8@gmx.de>  <8fd1810b-256b-7dab-03b5-249201f69dbd@levkowetz.com> <4cac0d64-32c4-2913-d2bb-a3c019d730d0@gmx.de> <6B4408BB-7820-48AA-BA78-88C9ECDD9B5E@tzi.org> <766a6806-0cd7-df25-aa74-d0c03e4c7c72@levkowetz.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64-pc-linux-gnu)
Archived-At: 
Subject: Re: [xml2rfc] Silly unicode question
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 18:11:36 -0000

On Thursday, March 19 2020, "Henrik Levkowetz" wrote to "Carsten Bormann, xml2rfc@ietf.org, John R Levine" saying:

> Well, yes; but on the other hand simply saying 'Latin script' is more
> problematic than I made it sound above; they include half-width, full-width
> and spacing modified characters that complicate matters:
> https://en.wikipedia.org/wiki/Latin_script_in_Unicode
> 
> The easiest approach that would still be fairly inclusive might be to say
> 'Latin script below U+2000'.

Not to speak to whether this is a good idea or not, but in the interest of
not re-doing work other people have already done, I'd say that the right
approach here would be to use one of the Multilingual European Subsets of
Unicode  -- probably
MES-3, the broadest.

-- 
Jonathan Lennox
lennox@cs.columbia.edu


From nobody Thu Mar 19 14:49:51 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AC83A1063 for ; Thu, 19 Mar 2020 14:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=JBUN5JJ4; dkim=pass (1536-bit key) header.d=taugh.com header.b=rAfdof5X
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 VFpJCSo3S9IP for ; Thu, 19 Mar 2020 14:49:42 -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 ED1BF3A1062 for ; Thu, 19 Mar 2020 14:49:36 -0700 (PDT)
Received: (qmail 95288 invoked from network); 19 Mar 2020 21:49:33 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=17436.5e73e8ed.k2003; i=johnl-iecc.com@submit.iecc.com; bh=n5ZbiuDJvtFMAjwnkecS8AG6zpy/RgFctJIMRQCuL9A=; b=JBUN5JJ4zy3Q2Vz8gZhf51PVg//NL+H1GqfIvPCzs78novm2Wa4SiHunrBlt7raxgxW4hrLue+9whV55DdUJgx372TdDqW50e/dj9gb0psFmoSGm+jJBHniQ/mxcp0aHiineZ4lAV6lga9IKF9GAtHz+4nBweaB3kCoAt8jRbD0uMTB+rHsO1iceXDDGckqzTrKGToZAPX2+ntyz94UkCtxbQ5k5q62FlCvGAkcfdAR58kr+bMfNl109catv0T4V
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=17436.5e73e8ed.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=n5ZbiuDJvtFMAjwnkecS8AG6zpy/RgFctJIMRQCuL9A=; b=rAfdof5XolRzSOru0Gj+HVm8L/UJM7g6pFLb+5GNoKmfYSnwRtDFlnbaZyrHC7s+3KsgP2AwZ74w/5Vj9JM5fICDRWGouvXRmry5kBG6q+TEuAavcAwP/1nQc+wp0e6euP0s9Io5rlBkSFMYCSQyPzcJJAXroEqOG80ycwRBUUOGr7EVXHiB4DiYnhFLRqvhcR3aNmovjX2zhNZMLPWPY1AwysDb1uAmkgzpuaOiUaretixr7poiCv4jNYu/jp5z
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 19 Mar 2020 21:49:32 -0000
Date: 19 Mar 2020 17:49:32 -0400
Message-ID: 
From: "John R Levine" 
To: xml2rfc@ietf.org
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: [xml2rfc] rfc 7997bis
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Mar 2020 21:49:49 -0000

Unless people violently object, I'll set up a github repo for rfc 7997bis 
with issues for the topics people have brought up.  Then we can socialize 
it and see what else we should be tossing into it.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Thu Mar 19 19:59:58 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B393A1503 for ; Thu, 19 Mar 2020 19:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level: 
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=fM3ZUE6F; dkim=pass (1536-bit key) header.d=taugh.com header.b=J0Z3UCin
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 RbGIjltY6s1K for ; Thu, 19 Mar 2020 19:59:51 -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 C78903A14FF for ; Thu, 19 Mar 2020 19:59:50 -0700 (PDT)
Received: (qmail 43996 invoked from network); 20 Mar 2020 02:59:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=abda.5e7431a3.k2003; i=johnl-iecc.com@submit.iecc.com; bh=WfdYWFLhyTKiFqvQ6OS8q+/89zILTiXGiyvm4v8bjlc=; b=fM3ZUE6Fq7z3ILRSKAS5so4QSDRMcmrEtqt+WNRsY/agrrqwaIfalIe8/vhJJtYyNmrmtoZ1mus1SlW5RkTWQGvTkGrtyXRa0/VWhSQ1sMp1oMAiQ2FRn0kQ4njvGhEMcvMkw0gQIjrdygfLcFa7ByeGruju7cRWTeUfztJrH5wzGd3/D5lS1qcW8FoVhc+uQfECs6+mC1/3t1wG2rZ2Wt8MuYkdthhEinK/AWMJMiKk6dS609YAHNanTKKGVvwr
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=abda.5e7431a3.k2003; olt=johnl-iecc.com@submit.iecc.com; bh=WfdYWFLhyTKiFqvQ6OS8q+/89zILTiXGiyvm4v8bjlc=; b=J0Z3UCinkjZyNphmBubroM16kQeYI511JP5++a9CSHSlGXfEh7hfbUz/KpoLbDl+sMWAtTLvQ4Mbb2wByhWKv/4zUcsJNn3G9kmEtHOXo5MzrkJzt0G1o5sS6A20fRXKOZK6vRhPMQeMPLlobRQcGMOlzRyG6CIVYuIq+xDPeYLDBoBt5v8IJ7siWre/TVqXTU7LZaLIX0Fz0PxcwpVEDGXpeZ1e+egI6N0y9HJWXmtxhtZ5fDqOmCghyd5CVU7Y
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.3 ECDHE-RSA AES-256-GCM AEAD, johnl@iecc.com) via TCP6; 20 Mar 2020 02:59:47 -0000
Date: 19 Mar 2020 22:59:47 -0400
Message-ID: 
From: "John R Levine" 
To: xml2rfc@ietf.org
User-Agent: Alpine 2.22 (OSX 407 2020-02-09)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [xml2rfc] rfc 7997bis
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 02:59:57 -0000

Alice reminded me that we already have a repo at:

  https://github.com/rfc-format/draft-iab-rfc-nonascii-bis

I added a new issue.  What else should I add?

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


From nobody Fri Mar 20 11:00:11 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 310F83A0D73 for ; Fri, 20 Mar 2020 11:00:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD6gaQlAVPhq for ; Fri, 20 Mar 2020 11:00:01 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 B460C3A0D65 for ; Fri, 20 Mar 2020 10:59:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 67F5D621A0 for ; Fri, 20 Mar 2020 13:59:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6z5gsWfaOcGN for ; Fri, 20 Mar 2020 13:59:37 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 53A286212E for ; Fri, 20 Mar 2020 13:59:37 -0400 (EDT)
To: "xml2rfc@ietf.org" 
From: Robert Moskowitz 
Message-ID: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com>
Date: Fri, 20 Mar 2020 13:59:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:00:09 -0000

In v3,

Inside a 
    , how do I get 
  •  to indent under the previous 
  • 

I am just missing this.  I tried 
  •  and that obviously is 
not it...

Thanks


From nobody Fri Mar 20 11:02:21 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8944B3A0D5F for ; Fri, 20 Mar 2020 11:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUG0JpBryLBg for ; Fri, 20 Mar 2020 11:02:11 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65FEB3A0D98 for ; Fri, 20 Mar 2020 11:01:55 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48kWn503rXzyXR; Fri, 20 Mar 2020 19:01:44 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com>
Date: Fri, 20 Mar 2020 19:01:44 +0100
Cc: "xml2rfc@ietf.org" 
X-Mao-Original-Outgoing-Id: 606420104.61861-14483c40fef9f02b26ba6e76d585b762
Content-Transfer-Encoding: quoted-printable
Message-Id: <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org>
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com>
To: Robert Moskowitz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:02:20 -0000

On 2020-03-20, at 18:59, Robert Moskowitz  wrote:
>=20
> Inside a 
      , how do I get 
    •  to indent under the previous 
    • 

You need to express the sublist:


        
  
      • 
    
          
     
        • 

Gr=C3=BC=C3=9Fe, Carsten


From nobody Fri Mar 20 11:07:00 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B2B3A09A8 for ; Fri, 20 Mar 2020 11:06:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vlFiqz0yBHiI for ; Fri, 20 Mar 2020 11:06:51 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 908BD3A0BD0 for ; Fri, 20 Mar 2020 11:06:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 394C7621AA; Fri, 20 Mar 2020 14:06:50 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SRaKxBAWNNd6; Fri, 20 Mar 2020 14:06:47 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 53C15621A0; Fri, 20 Mar 2020 14:06:47 -0400 (EDT)
To: Carsten Bormann 
Cc: "xml2rfc@ietf.org" 
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com> <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org>
From: Robert Moskowitz 
Message-ID: <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com>
Date: Fri, 20 Mar 2020 14:06:41 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:06:58 -0000

On 3/20/20 2:01 PM, Carsten Bormann wrote:
> On 2020-03-20, at 18:59, Robert Moskowitz  wrote:
>> Inside a 
            , how do I get 
          •  to indent under the previous 
          • 
> You need to express the sublist:
>
> 
              
>    
            • 
>      
                
>       
              • 
>

     
                  
         
                • 
             B-RID can more readily be implemented directly in the UA.
             N-RID will more frequently be provided by the GCS or a
             pilot's Internet connected device.
         
                  • 
             
                    
                 
                  • 
                     If Command and Control (C2) is bi-directional over
                     a direct radio connection, B-RID could be a
                     straight-forward addition.
                 
                    • 
                 
                  • 
                     Small IoT devices can be mounted on UA to provide 
B-RID.
                 
                    • 
             
                  
         
                • 
             B-RID can also be used by the UA to assist in Detect and
             Avoid (DAA).
         
                  • 
         
                • 
             B-RID is available to observers even in situations with no
             Internet like natural disaster situations.
         
                  • 
     
                

Error: Did not expect element ul there, at 
/rfc/middle/section[3]/section[2]/ul/ul

Same error if I move the inner 
                   into the above 
                • 



From nobody Fri Mar 20 11:08:22 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5FE3A0C4E for ; Fri, 20 Mar 2020 11:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i2OraxXg3Yuy for ; Fri, 20 Mar 2020 11:08:16 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14323A0B77 for ; Fri, 20 Mar 2020 11:08:15 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48kWwZ1rn0zyXR; Fri, 20 Mar 2020 19:08:14 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com>
Date: Fri, 20 Mar 2020 19:08:13 +0100
Cc: "xml2rfc@ietf.org" 
X-Mao-Original-Outgoing-Id: 606420493.788025-c84dc9d2bee1f4ba5784421fc025fee9
Content-Transfer-Encoding: quoted-printable
Message-Id: <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org>
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com> <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org> <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com>
To: Robert Moskowitz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:08:20 -0000

The ul is in an li

> On 2020-03-20, at 19:06, Robert Moskowitz  wrote:
>=20
> Error: Did not expect element ul there, at =
/rfc/middle/section[3]/section[2]/ul/ul


From nobody Fri Mar 20 11:13:07 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE2B3A0D51 for ; Fri, 20 Mar 2020 11:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uI2hIwPS4KhF for ; Fri, 20 Mar 2020 11:12:50 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 84CA53A0D86 for ; Fri, 20 Mar 2020 11:12:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 6C1D2621A0; Fri, 20 Mar 2020 14:12:49 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rT5eOvfISbsl; Fri, 20 Mar 2020 14:12:45 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 1C1F86212E; Fri, 20 Mar 2020 14:12:45 -0400 (EDT)
To: Carsten Bormann 
Cc: "xml2rfc@ietf.org" 
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com> <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org> <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com> <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org>
From: Robert Moskowitz 
Message-ID: <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>
Date: Fri, 20 Mar 2020 14:12:43 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:13:05 -0000

On 3/20/20 2:08 PM, Carsten Bormann wrote:
> The ul is in an li
>
>> On 2020-03-20, at 19:06, Robert Moskowitz  wrote:
>>
>> Error: Did not expect element ul there, at /rfc/middle/section[3]/section[2]/ul/ul
     
                    
         
                  • 
             B-RID can more readily be implemented directly in the UA.
             N-RID will more frequently be provided by the GCS or a
             pilot's Internet connected device.
             
                      
                 
                    • 
                     If Command and Control (C2) is bi-directional over
                     a direct radio connection, B-RID could be a
                     straight-forward addition.
                 
                      • 
                 
                    • 
                     Small IoT devices can be mounted on UA to provide 
B-RID.
                 
                      • 
             
                    
         
                    • 
         
                  • 
             B-RID can also be used by the UA to assist in Detect and
             Avoid (DAA).
         
                    • 
         
                  • 
             B-RID is available to observers even in situations with no
             Internet like natural disaster situations.
         
                    • 
     
                  

  Error: Element li has extra content: ul, at 
/rfc/middle/section[3]/section[2]/ul/li[1]/ul



From nobody Fri Mar 20 11:36:05 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1D63A0C09 for ; Fri, 20 Mar 2020 11:36:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lkOztMetbvHF for ; Fri, 20 Mar 2020 11:35:59 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42F3E3A0BF3 for ; Fri, 20 Mar 2020 11:35:59 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:63065 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jFMUV-00086f-5j; Fri, 20 Mar 2020 11:35:55 -0700
To: Robert Moskowitz , Carsten Bormann 
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com> <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org> <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com> <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org> <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>
Cc: "xml2rfc@ietf.org" 
From: Henrik Levkowetz 
Message-ID: 
Date: Fri, 20 Mar 2020 19:35:21 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r2HamhG8quCl7KlLm2uLAAVUnAfIxlKon"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, cabo@tzi.org, rgm@htt-consult.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:36:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--r2HamhG8quCl7KlLm2uLAAVUnAfIxlKon
Content-Type: multipart/mixed; boundary="F6VT9RdrVmkDqejrClUgQHN5su8wR9PBJ";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Robert Moskowitz , Carsten Bormann 
Cc: "xml2rfc@ietf.org" 
Message-ID: 
Subject: Re: [xml2rfc] Indenting a sublist
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com>
 <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org>
 <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com>
 <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org>
 <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>
In-Reply-To: <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>

--F6VT9RdrVmkDqejrClUgQHN5su8wR9PBJ
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Bob,

On 2020-03-20 19:12, Robert Moskowitz wrote:
>=20
>=20
> On 3/20/20 2:08 PM, Carsten Bormann wrote:
>> The ul is in an li
>>
>>> On 2020-03-20, at 19:06, Robert Moskowitz  wrote=
:
>>>
>>> Error: Did not expect element ul there, at /rfc/middle/section[3]/sec=
tion[2]/ul/ul
>      
                    
>          
                  • 
	=09
If you want a sequence of text followed by 
                       here, you need to
place the text in :

               
>              B-RID can more readily be implemented directly in the UA.
>              N-RID will more frequently be provided by the GCS or a
>              pilot's Internet connected device.
               

>              
                        
>                  
                      • 
>                      If Command and Control (C2) is bi-directional over=

>                      a direct radio connection, B-RID could be a
>                      straight-forward addition.
>                  
                        • 
>                  
                      • 
>                      Small IoT devices can be mounted on UA to provide =

> B-RID.
>                  
                        • 
>              
                      
>          
>          
                    • 
>              B-RID can also be used by the UA to assist in Detect and
>              Avoid (DAA).
>          
                      • 
>          
                    • 
>              B-RID is available to observers even in situations with no=

>              Internet like natural disaster situations.
>          
                      • 
>      
                    
>=20
>   Error: Element li has extra content: ul, at=20
> /rfc/middle/section[3]/section[2]/ul/li[1]/ul

I think it is confusing that the new v3 grammar permits _either_ plain
text, _or_ a sequence of /
                      /
                         etc. elements, because it leads
to this kind of failure when adding pieces iteratively.

Always requiring the  would make the grammar easier to understand.

I proposed that here:

https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-not=
es-10#section-3.1.10.2

but the change was rejected.


Best regards,

	Henrik



--F6VT9RdrVmkDqejrClUgQHN5su8wR9PBJ--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl51DOkACgkQTptXS4+7
Fxpcuw//WNfMzPOxKWCOK3IpHuuyfCVyrsxUk0wtefoA+9GBxHBOAetYftTR0wm3
iKTe4hJoPgaoWZRpkbhJsFI4h1+pvOIBf4rH59i8ZyfHfFdUk56KszptrNGwRZdp
kuPRYllVlJbJBEh4/LN0Yk+1BOMM1bvpp0OPUr99Cq3fVbroHKUk6+MupwuZnmh3
50W7X9Ciz1urD98MZkfuD5S/fUhrV4yeuikF2jLJjV33ee8VcEUklrj9WAPhok6W
JTKFL+boWYXgLmi/zqcl/gQszu0DkjnzGyf3fB/5jIqP62HLALDDA8/bpkx1sQ+2
TpodxzayZFL9Y/piCJ54iEkJRBZwIDOVeq6VBuXLHh+9VQWWHK5vzs3mDSUEpinu
9BFYTusZGHdZfnt3R3PLiQvvr+RXd/QKJ196ENcC1eY1NxGO+1vo4wJ4tpvsuvvL
useeXOJcP07JneU3qTd5VwIjXxTIxMcdUoritp7qNP/pkV7qm9hcx/HdjwExgLts
KItdjCdADfo3cUyU0xnXV5Ul+/s0v9UPUebwV9iMAlxIl0ga52ndQIAx0JDKz6Dp
PgR6d1uxVzoEr6iWZLiYr0KrHkUpJ+FNAsELOO5dkbPMijrRcUt1/q2OBe4k9Txa
UB197U+Mqxd2PC6C543FZzlhZwKwTBsrhQvxlnAGisBOSPOoYDQ=
=1iTC
-----END PGP SIGNATURE-----

--r2HamhG8quCl7KlLm2uLAAVUnAfIxlKon--


From nobody Fri Mar 20 11:37:20 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16BE3A0BF9 for ; Fri, 20 Mar 2020 11:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ywRzxAce8PpL for ; Fri, 20 Mar 2020 11:37:15 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC353A0BF3 for ; Fri, 20 Mar 2020 11:37:15 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48kXZ14FYCzyY3; Fri, 20 Mar 2020 19:37:13 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>
Date: Fri, 20 Mar 2020 19:37:13 +0100
Cc: "xml2rfc@ietf.org" 
X-Mao-Original-Outgoing-Id: 606422233.052417-7adbe9a390a53fc2e0abf4c1fae1367e
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com> <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org> <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com> <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org> <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com>
To: Robert Moskowitz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:37:19 -0000

Oh.  RFC 7991 seems to avoid mixed content; I had suppressed that in my =
recollection.
So, for this specific case, you have to wrap text in t.
I=E2=80=99m already looking forward to programming this :-)

Gr=C3=BC=C3=9Fe, Carsten


> On 2020-03-20, at 19:12, Robert Moskowitz  wrote:
>=20
>=20
>=20
> On 3/20/20 2:08 PM, Carsten Bormann wrote:
>> The ul is in an li
>>=20
>>> On 2020-03-20, at 19:06, Robert Moskowitz  =
wrote:
>>>=20
>>> Error: Did not expect element ul there, at =
/rfc/middle/section[3]/section[2]/ul/ul
>     
                          
>         
                        • 

>             B-RID can more readily be implemented directly in the UA.
>             N-RID will more frequently be provided by the GCS or a
>             pilot's Internet connected device.

>             
                            
>                 
                          • 
>                     If Command and Control (C2) is bi-directional over
>                     a direct radio connection, B-RID could be a
>                     straight-forward addition.
>                 
                            • 
>                 
                          • 
>                     Small IoT devices can be mounted on UA to provide =
B-RID.
>                 
                            • 
>             
                          
>         
                          • 
>         
                        • 
>             B-RID can also be used by the UA to assist in Detect and
>             Avoid (DAA).
>         
                          • 
>         
                        • 
>             B-RID is available to observers even in situations with no
>             Internet like natural disaster situations.
>         
                          • 
>     
                        


From nobody Fri Mar 20 11:48:52 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2243A0DCA for ; Fri, 20 Mar 2020 11:48:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JQ-g9hMxVq1p for ; Fri, 20 Mar 2020 11:48:37 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 D7BBA3A0DA8 for ; Fri, 20 Mar 2020 11:48:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 90D866212E; Fri, 20 Mar 2020 14:48:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1TiHruysm5Cz; Fri, 20 Mar 2020 14:48:32 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id D3A5D621AA; Fri, 20 Mar 2020 14:48:31 -0400 (EDT)
To: Henrik Levkowetz , Carsten Bormann 
Cc: "xml2rfc@ietf.org" 
References: <55535088-b26b-1867-cd51-06b6d9274a25@htt-consult.com> <027223E2-D283-46A7-9DC5-30FB63054101@tzi.org> <6be2dd36-c2ed-303b-380a-b2e26b2721fa@htt-consult.com> <80DA51D8-B196-463E-9221-997A0DC3E780@tzi.org> <2530afa4-659b-7ea2-25d9-0fa2f364c148@htt-consult.com> 
From: Robert Moskowitz 
Message-ID: <3f2cb0d9-4406-094a-7c93-921fbd23792d@htt-consult.com>
Date: Fri, 20 Mar 2020 14:48:25 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [xml2rfc] Indenting a sublist
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 18:48:50 -0000

Thanks Henrik,

That worked and is totally non-obvious.

On 3/20/20 2:35 PM, Henrik Levkowetz wrote:
> Hi Bob,
>
> On 2020-03-20 19:12, Robert Moskowitz wrote:
>>
>> On 3/20/20 2:08 PM, Carsten Bormann wrote:
>>> The ul is in an li
>>>
>>>> On 2020-03-20, at 19:06, Robert Moskowitz  wrote:
>>>>
>>>> Error: Did not expect element ul there, at /rfc/middle/section[3]/section[2]/ul/ul
>>       
                          
>>           
                        • 
> 		
> If you want a sequence of text followed by 
                             here, you need to
> place the text in :
>
>                 
>>               B-RID can more readily be implemented directly in the UA.
>>               N-RID will more frequently be provided by the GCS or a
>>               pilot's Internet connected device.
>                 
>
>>               
                              
>>                   
                            • 
>>                       If Command and Control (C2) is bi-directional over
>>                       a direct radio connection, B-RID could be a
>>                       straight-forward addition.
>>                   
                              • 
>>                   
                            • 
>>                       Small IoT devices can be mounted on UA to provide
>> B-RID.
>>                   
                              • 
>>               
                            
>>           
>>           
                          • 
>>               B-RID can also be used by the UA to assist in Detect and
>>               Avoid (DAA).
>>           
                            • 
>>           
                          • 
>>               B-RID is available to observers even in situations with no
>>               Internet like natural disaster situations.
>>           
                            • 
>>       
                          
>>
>>    Error: Element li has extra content: ul, at
>> /rfc/middle/section[3]/section[2]/ul/li[1]/ul
> I think it is confusing that the new v3 grammar permits _either_ plain
> text, _or_ a sequence of /
                            /
                               etc. elements, because it leads
> to this kind of failure when adding pieces iteratively.
>
> Always requiring the  would make the grammar easier to understand.
>
> I proposed that here:
>
> https://tools.ietf.org/html/draft-levkowetz-xml2rfc-v3-implementation-notes-10#section-3.1.10.2
>
> but the change was rejected.
>
>
> Best regards,
>
> 	Henrik
>
>


From nobody Fri Mar 20 12:01:39 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C0C3A0C6C; Fri, 20 Mar 2020 12:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IKY-CnUY7n3v; Fri, 20 Mar 2020 12:00:20 -0700 (PDT)
Received: from durif.tools.ietf.org (durif.tools.ietf.org [IPv6:2001:1900:3001:11::3d]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D683A0C32; Fri, 20 Mar 2020 12:00:20 -0700 (PDT)
Received: from henrik by durif.tools.ietf.org with local (Exim 4.80) (envelope-from ) id 1jFMsV-00014M-VG; Fri, 20 Mar 2020 12:00:20 -0700
To: xml2rfc-dev@ietf.org, xml2rfc@ietf.org
Cc: rfc-markdown@ietf.org
Message-Id: 
From: Henrik Levkowetz 
Date: Fri, 20 Mar 2020 12:00:19 -0700
X-SA-Exim-Connect-IP: 
X-SA-Exim-Rcpt-To: rfc-markdown@ietf.org, xml2rfc-dev@ietf.org, xml2rfc@ietf.org
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Scanned: No (on durif.tools.ietf.org); SAEximRunCond expanded to false
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: [xml2rfc] New xml2rfc release: v2.41.0
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Mar 2020 19:00:26 -0000

Hi,

This is an automatic notification about a new xml2rfc release, 
v2.41.0, generated when running the mkrelease script.

Release notes:

xml2rfc (2.41.0) ietf; urgency=medium

  * Added  to the tags that may have bare unicode content.  
    Fixes issue #499.

  * Tweaked the CSS for dl.olPercent dd.  Fixes issue #458.

  * Fixed an issue with rendering  entries without trailing text or 
    whitespace.

  * Fixed an issue in the v2v3 converter that could occur if no  
    element is present.

  * Fixed an issue with using Latin content in , also addressing the 
    same issue for other  sub-elements.  Related to issue #493.

  * Fixed an issue with the formatting of a warning message.

  * Fixed a Py2/3 issue with the --country-help output.

 -- Henrik Levkowetz   20 Mar 2020 18:56:57 +0000

The preferred way to install xml2rfc is by doing 'pip install xml2rfc',
and 'pip install --upgrade xml2rfc' to upgrade.  If there are system-
installed python modules which pip will not upgrade, you may have to
use 'pip install --upgrade --no-deps xml2rfc' and install dependencies
manually.

The new version is also available through SVN checkout, with
  'svn checkout http://svn.tools.ietf.org/svn/tools/xml2rfc/tags/cli/2.41.0'

Regards,

	Henrik
	(via the mkrelease script)


From nobody Sun Mar 22 07:19:29 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB913A02BD for ; Sun, 22 Mar 2020 07:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level: 
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB1BSptvD5mL for ; Sun, 22 Mar 2020 07:19:26 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 C15E83A02BC for ; Sun, 22 Mar 2020 07:19:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 66ABC6214B for ; Sun, 22 Mar 2020 10:19:25 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9nYz6UzS8D8E for ; Sun, 22 Mar 2020 10:19:20 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 0061762145 for ; Sun, 22 Mar 2020 10:19:19 -0400 (EDT)
To: "xml2rfc@ietf.org" 
From: Robert Moskowitz 
Message-ID: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>
Date: Sun, 22 Mar 2020 10:19:15 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 14:19:28 -0000

A few weeks back, I was editing my old draft ietf-hep-dex and since the 
xml in there goes back years, and I was having problems (remember that 
pagebreak question?), I thought to 'force' v2 by:

xml2rfc --v2

Guess what, no such option but it acted as:

xml2rfc --v2v3

!!!

Something you may want to fix.

I bring this up now, as I did it again Friday.  I was rushed getting a 
bunch of things done and it kind of slipped out.  No harm as I knew 
about it from past mess ups.



From nobody Sun Mar 22 09:34:40 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184573A0839 for ; Sun, 22 Mar 2020 09:34:38 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FO4Fbq3NxzL for ; Sun, 22 Mar 2020 09:34:36 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1287B3A0841 for ; Sun, 22 Mar 2020 09:34:36 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57132 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jG3YB-0001iM-8Z; Sun, 22 Mar 2020 09:34:34 -0700
To: Robert Moskowitz , "xml2rfc@ietf.org" 
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>
From: Henrik Levkowetz 
Message-ID: 
Date: Sun, 22 Mar 2020 17:34:01 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gesvOwLh7DILLBPA6FjuglX4OGRlplnx4"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, rgm@htt-consult.com
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 16:34:38 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--gesvOwLh7DILLBPA6FjuglX4OGRlplnx4
Content-Type: multipart/mixed; boundary="LRa4OMKe1iXLAwRPPf1NT7Cvni4xf6Sr8";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Robert Moskowitz ,
 "xml2rfc@ietf.org" 
Message-ID: 
Subject: Re: [xml2rfc] Point about --v2v3 option
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>
In-Reply-To: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>

--LRa4OMKe1iXLAwRPPf1NT7Cvni4xf6Sr8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Bob,

On 2020-03-22 15:19, Robert Moskowitz wrote:
> A few weeks back, I was editing my old draft ietf-hep-dex and since the=
=20
> xml in there goes back years, and I was having problems (remember that =

> pagebreak question?), I thought to 'force' v2 by:
>=20
> xml2rfc --v2
>=20
> Guess what, no such option but it acted as:
>=20
> xml2rfc --v2v3
>=20
> !!!
>=20
> Something you may want to fix.
>=20
> I bring this up now, as I did it again Friday.  I was rushed getting a =

> bunch of things done and it kind of slipped out.  No harm as I knew=20
> about it from past mess ups.

Well, there's no way to force 'v2' for a draft with v3 XML, and unless
you explicitly indicate --v3, a draft with v2 xml will be not be converte=
d
to v3 during processing.

Abbreviations of long options are accepted as long as they are unique,
which is why --v2 did something, instead of being rejected.

Before going further, I think I'd better ask what you intended to happen
with --v2:  Did you have a draft with v3 XML, or was it just insurance
against processing through the v3 formatters?


Regards,

	Henrik


--LRa4OMKe1iXLAwRPPf1NT7Cvni4xf6Sr8--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl53k3kACgkQTptXS4+7
Fxp6hg//UUnXAjA24zQb5eTWRkEgydVPYG0vhrpguZMTxFRLkbUrfRRst3Nq4nuo
Bjpouci4rW1l0GqVIBuOh6e3phqaSi3RhyK0F2HVeSBPkGKkPzclfyYBoX/9pj+T
hY4fK9Kph0+gdAZIEid8bwY4JywPg6IcWi7bfzSITLwAn5sS8OTdhpE7N62g1t2l
COiC1AIKLMZ9I8k+d5MKXEVzwcrv44yjmzXl2zW4aZpdyPoCwaOhindgK6ZWlxaW
83Xb5t9sMFNudKAN7u4FaLU0D+7NKPp31requ1/XqLdzTK4px308BF86S8BaOyLj
X0KLoG+4ygJyfEUOujcOhbw9Qg390GQP+d/NTfJ7TyA+xTxQGGwYFJesr88Mau28
3I4QNokiqCkEU8BLtRCdIAqf5AATTY+OxPYo+6Fqvx550YeXGdZtcbnmraBDBLr9
PMPkejRPbdY07+pgHNonBVkWND+ZKK6AjaLuw3boBKup7S41ELErCvvUPNiwks4A
EL5Z0T4H3JvBFR7+ZbEL/CDhd+XNwJNEgFA0LvUva7UJM/9uKXhSxjoTQqssuubj
M5Z8e8DuIolyif8leaK3RltQzrpcV6oQBn1cGKf6rd8KCdSPsMZkwMyzyCe6AVGH
FDbNqMu/KHtfWeZev3RKBYJfAhybtsnt1pntZ6iB02nCd51yO6U=
=CJqZ
-----END PGP SIGNATURE-----

--gesvOwLh7DILLBPA6FjuglX4OGRlplnx4--


From nobody Sun Mar 22 09:56:26 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D977E3A086C for ; Sun, 22 Mar 2020 09:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tz_mBKG7pGRD for ; Sun, 22 Mar 2020 09:56:21 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8CE3A0775 for ; Sun, 22 Mar 2020 09:56:20 -0700 (PDT)
Received: from [192.168.217.147] (p548DCD70.dip0.t-ipconnect.de [84.141.205.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 48lkDf6shJz102D; Sun, 22 Mar 2020 17:56:18 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Carsten Bormann 
In-Reply-To: 
Date: Sun, 22 Mar 2020 17:56:18 +0100
Cc: Robert Moskowitz , "xml2rfc@ietf.org" 
X-Mao-Original-Outgoing-Id: 606588978.2595201-4c0b0ad4a5d08f7f448a6d6fdfc38df2
Content-Transfer-Encoding: quoted-printable
Message-Id: <8680B1C7-7A59-4F3D-B3C1-21580A2F4B3A@tzi.org>
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com> 
To: Henrik Levkowetz 
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: 
Subject: Re: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 16:56:25 -0000

I can=E2=80=99t answer for Bob, but to me it was indeed feeling a bit =
strange that I can=E2=80=99t get xml2rfc to expect v2 only input and =
reliably act on it with v2 rules.  I don=E2=80=99t think that is a big =
problem going forward, but it was weird in the transition.  Look at

=
https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-more-units-06.=
txt

for an example why surprise switching to v3 rules can be disconcerting =
(even if it wasn=E2=80=99t caused by xml2rfc acting on non-v2 input in =
this particular case).

Again, I don=E2=80=99t think this is much of a problem now going =
forward.

Gr=C3=BC=C3=9Fe, Carsten


> On 2020-03-22, at 17:34, Henrik Levkowetz  =
wrote:
>=20
> Hi Bob,
>=20
> On 2020-03-22 15:19, Robert Moskowitz wrote:
>> A few weeks back, I was editing my old draft ietf-hep-dex and since =
the=20
>> xml in there goes back years, and I was having problems (remember =
that=20
>> pagebreak question?), I thought to 'force' v2 by:
>>=20
>> xml2rfc --v2
>>=20
>> Guess what, no such option but it acted as:
>>=20
>> xml2rfc --v2v3
>>=20
>> !!!
>>=20
>> Something you may want to fix.
>>=20
>> I bring this up now, as I did it again Friday.  I was rushed getting =
a=20
>> bunch of things done and it kind of slipped out.  No harm as I knew=20=

>> about it from past mess ups.
>=20
> Well, there's no way to force 'v2' for a draft with v3 XML, and unless
> you explicitly indicate --v3, a draft with v2 xml will be not be =
converted
> to v3 during processing.
>=20
> Abbreviations of long options are accepted as long as they are unique,
> which is why --v2 did something, instead of being rejected.
>=20
> Before going further, I think I'd better ask what you intended to =
happen
> with --v2:  Did you have a draft with v3 XML, or was it just insurance
> against processing through the v3 formatters?
>=20
>=20
> Regards,
>=20
> 	Henrik
>=20
> _______________________________________________
> xml2rfc mailing list
> xml2rfc@ietf.org
> https://www.ietf.org/mailman/listinfo/xml2rfc


From nobody Sun Mar 22 10:07:12 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72743A08E8 for ; Sun, 22 Mar 2020 10:07:09 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tK4jkcTF_gkW for ; Sun, 22 Mar 2020 10:07:08 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [23.123.122.147]) (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 84BE43A08E7 for ; Sun, 22 Mar 2020 10:07:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2C0B762134; Sun, 22 Mar 2020 13:07:06 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PuqQ84WTgR1h; Sun, 22 Mar 2020 13:07:01 -0400 (EDT)
Received: from lx140e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 720C06212E; Sun, 22 Mar 2020 13:06:59 -0400 (EDT)
To: Henrik Levkowetz , "xml2rfc@ietf.org" 
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com> 
From: Robert Moskowitz 
Message-ID: <71da164d-dda4-5e20-6c31-c8849ca71a7e@htt-consult.com>
Date: Sun, 22 Mar 2020 13:06:52 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 17:07:10 -0000

On 3/22/20 12:34 PM, Henrik Levkowetz wrote:
> Hi Bob,
>
> On 2020-03-22 15:19, Robert Moskowitz wrote:
>> A few weeks back, I was editing my old draft ietf-hep-dex and since the
>> xml in there goes back years, and I was having problems (remember that
>> pagebreak question?), I thought to 'force' v2 by:
>>
>> xml2rfc --v2
>>
>> Guess what, no such option but it acted as:
>>
>> xml2rfc --v2v3
>>
>> !!!
>>
>> Something you may want to fix.
>>
>> I bring this up now, as I did it again Friday.  I was rushed getting a
>> bunch of things done and it kind of slipped out.  No harm as I knew
>> about it from past mess ups.
> Well, there's no way to force 'v2' for a draft with v3 XML, and unless
> you explicitly indicate --v3, a draft with v2 xml will be not be converted
> to v3 during processing.
>
> Abbreviations of long options are accepted as long as they are unique,
> which is why --v2 did something, instead of being rejected.
>
> Before going further, I think I'd better ask what you intended to happen
> with --v2:  Did you have a draft with v3 XML, or was it just insurance
> against processing through the v3 formatters?

I just wanted to ensure V2 rules on this old draft.  Anyone that does 
use --v2 and think it will force v2 rules will quickly see this does not 
work, as it generates the v2v3 xml.

Nothing 'bad' happens, just surprising.

But as Carsten agreed, it would be nice to enforce v2 rules for the old 
stuff still hanging around.  But make the authors ask for it, and then 
understand what will happen with it gets into the Editor queue.



From nobody Sun Mar 22 11:30:31 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256D33A0808 for ; Sun, 22 Mar 2020 11:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.361
X-Spam-Level: 
X-Spam-Status: No, score=-3.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-1.463, 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=gmx.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 VTt3h7KV7k7F for ; Sun, 22 Mar 2020 11:30:19 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 25E213A099B for ; Sun, 22 Mar 2020 11:30:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584901803; bh=1v0Wtqtp/0oDG71AuWpjorN5dZ2GBPMnFwWDz9gRehw=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=XxJj+5eXYwnNF9pULB56qOqNKk2RcT22j5BfX3BqOwQktsEW8qXXVYw6kgygStdai paMI0kc4rELw8RouSEg/htZTYAlyl0gzGDI7sOUvwcIb7jVzS4qF3XRnWrlC4H6Rez fpwnp5SHxYZBy6Wq3+bf6x3oIJkdPhTLeQXaVuDU=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.124] ([91.61.56.63]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mwfac-1jUs7d06aA-00yAvw; Sun, 22 Mar 2020 19:30:03 +0100
To: Carsten Bormann , Henrik Levkowetz 
Cc: "xml2rfc@ietf.org" 
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>  <8680B1C7-7A59-4F3D-B3C1-21580A2F4B3A@tzi.org>
From: Julian Reschke 
Message-ID: <8ca29ea7-85b8-75b3-125e-51b235d09e9e@gmx.de>
Date: Sun, 22 Mar 2020 19:29:58 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <8680B1C7-7A59-4F3D-B3C1-21580A2F4B3A@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:6Q1liA+GpjfLonESRp5T+6PuK3ov6zdksAJVwhWR992gNC2NmJA yX/Zi6PiFvBhhGs8XEo/JahtzqqJ9E9ksE/uy/gDhYwn86WbgLVh0Z/7xZM2F1zYUkxFNxZ SOsfsdsDXoMj1C2jhzbbGUIXmDKr69dclZTVqizurOI724x5+v/Usk4p6BXvqR9Zb2ARR/o d7BYmcMP2gjtpAQ7sM8Cw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:mPC+lpC+cew=:MviyeO6UvJU4gyuvJNeWgQ gvcp5+RCceP2BSBVFdI49kf5IDb+233XQ0vcIukab6k3HLjp6HYmS6urbZMbZrXDuV9hwH7mc +JoETE+l+t6di7VS+vAHkr4YmbjtrHqPqsZHmDLzfBPNR+UHWTHm7DI2DE0maSlPxJqU0/wC1 EDH+/paRwil8DOz81snhFMyXOcLioPYeMNDK2rEeyuCkqoKfCpC7qHpmVYD7+MxIPEN4wF1Bj jU7qeCkUwNqQclQ2blPbo7vKjIdrN52buFubedNUbZFnFmvTMDgTmtiEyJIa3LqiXjBOndxbA idQu276xudX3tgfbqz+kUhlEoTcRZKTP/sGx1+gypyDTgFTBH1oO5AWy8G2RMZDrIUqzHivdP Epj6zNgESIcK/HH3v5PMd8s3IKTcv1/HhgJnW6ZnAh5GDnowi4adXcCfZdSrFVwUQzavDQDJd XEOaWtqKyO+wxK93jNyGgFNoAmggEkMyIgmjWaVZAMwUE19gjtOAXg71D9IECvVbVew0bO7p/ fULYPsJj5rWpw+4HwnbW236rvXMZS7vDjQwTEaLy3OpwNB4bYanpdAFAfQ8iNeiZL/JMQxELa O/Y67P+CMVZhZdsVeXoFGXOR+NALsMU0dh3Aoin0Mr+fhSG8ju3wYFMj4rq5a5CTuAYJzi8Ry WcZ+zSWXGTkiiVbAG35yNcDYiLI/BnHyMNWWZE91riP+aZDyUCidvlbm98820nTJm9VjSqrYw IZADbiIF9RImZ7PsjI1zW3w4FhwB29fTudJgwb1WQJryZZlqI1aYVUWRqLEKLQun/gQ65mwO2 1Gd2W5DVTRxZEdJBPn5GdNAKCVyV7+z8HslDBZW4zCb/1hhqW+Oy9vR7BW+e1DftSedl65MuI A31OGu5Q415l24bjPJqbYAoSleJL2MBVN3+RYbYer5YWpFb6YnvjiBE2HTogr4DDec8A6zrga sdm/EwH/7WHgNbHb9KQCr5AKPharWz+SQ72TD1yMsF+ixHh4sw7t/QC5XQscokhv8RsrCKo8s C9cA1F/fbLDb3MCo12GsYt7rBDrCRfInEkCJvaNSmrUhHl1pPlda8vSNqfmqJbkuxnUqUmrGi uiEQi+9CIXLZPQTktrxBO1eL4+NlIEQH2BLfU+IZWbDvrFhJrgROCtu1l1Lt1pu2lPgOsGBR6 /q40cF7c6ff6nt/eAmGS6apG0VMp3eVRcC8Dc8PMOTTN2BRgXsrtzBk1AIgnVnkkE7f9RsF+z 1ZyXtoqpnrmMcV0y4
Archived-At: 
Subject: Re: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 18:30:29 -0000

On 22.03.2020 17:56, Carsten Bormann wrote:
> I can=E2=80=99t answer for Bob, but to me it was indeed feeling a bit st=
range that I can=E2=80=99t get xml2rfc to expect v2 only input and reliabl=
y act on it with v2 rules.  I don=E2=80=99t think that is a big problem go=
ing forward, but it was weird in the transition.  Look at
>
> https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-core-senml-more-units-0=
6.txt
>
> for an example why surprise switching to v3 rules can be disconcerting (=
even if it wasn=E2=80=99t caused by xml2rfc acting on non-v2 input in this=
 particular case).
> ...

Hm, different order in which seriesInfo elements are processed? Smells
like a bug to me.

Best regards, Julian


From nobody Sun Mar 22 13:07:06 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285843A00C1 for ; Sun, 22 Mar 2020 13:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.464
X-Spam-Level: 
X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-1.463, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 dQIypmtFDw-i for ; Sun, 22 Mar 2020 13:07:02 -0700 (PDT)
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2081.outbound.protection.outlook.com [40.107.244.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 D65E63A00C0 for ; Sun, 22 Mar 2020 13:07:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hLjNtfsbuKlVqJ7KwPxe00qucQprrweClZWljUsphSqDa9/BHo7MgV2GIdj1b4F/BCl/lztb1q8KYP8A91AwQqZcfukGIb3/l4ctm0zLmJgAwxZ7FTfYzQT7wtv5XD9SckBRxqYZKoDou5Ok3eFLhejvdbjQ1LfzhV1HDOjlhKcnmicZc179Yoi2FuBS6HNX9q37z0CyANH8K3xYRYYmoq0s2seR58WQ+57zwe5LcAli1WOXHJ4HaVV94PCn5R2GyaFD0WmA9S1ZwGdlG2t7q4aBoNOfQU6a0aPZP0AWk8iXUA4uu3c6gzshkTn19xvrGR1Dn0xOB4METxbSUTP+BA==
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=qM9lUFQduvNlW9feLQRsnq64WMOc4apqqgfUSqFqhn0=; b=XQXYniSxtLyxylryEesMykYFKTu8rzy48ReI5N6D4bnvHj4lCdPvNzDIhXSr464p1rt23d7A6i/9c941pef6graqaO7pfOGB7qK4nEgknUGYp2rIjy/mL3s5gE30qSUvDXYKN+HSW2UOmuULzJf+tvwx2ZR5rlY30wCM65blgPfXrxJanLx7TDz/5rWRzCBeI0o9Ai0Wotnjs9oFBGluWPgCaFKmqLUkD2JZat8l3CjDC+bYOgEsLze8zOzj2K7SBiPWnIrVG+YVj+cwjEi0XhJSBwPO8mRUuZtd0lWgAijawvpw25jnT4lSTbKUi1YfzQiuHVw//esOU4Rbqkk+Tg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qM9lUFQduvNlW9feLQRsnq64WMOc4apqqgfUSqFqhn0=; b=f4XzR+znlxm24NcmaPQxwbJSG12yqSXe5neGjtHA7KG8+dabqkH309g46sMeQB2/YA41lEoZ1OC75YiZexoayAvhaWQoOIDp+ArAT5eY89UZh2WipmpD6m7fgZ9jo05zf8Eqw0gMpXkvHBFx8lUuOo/XPT1zTLZCVlswjLSASNY=
Received: from MN2PR20CA0020.namprd20.prod.outlook.com (2603:10b6:208:e8::33) by MWHPR12MB1342.namprd12.prod.outlook.com (2603:10b6:300:e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.15; Sun, 22 Mar 2020 20:07:00 +0000
Received: from BL2NAM02FT032.eop-nam02.prod.protection.outlook.com (2603:10b6:208:e8:cafe::f0) by MN2PR20CA0020.outlook.office365.com (2603:10b6:208:e8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.19 via Frontend Transport; Sun, 22 Mar 2020 20:07:00 +0000
Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com;  client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT032.mail.protection.outlook.com (10.152.77.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Sun, 22 Mar 2020 20:06:59 +0000
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 02MK6wxR015176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 22 Mar 2020 16:06:59 -0400
To: xml2rfc@ietf.org
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>  <71da164d-dda4-5e20-6c31-c8849ca71a7e@htt-consult.com>
From: Paul Kyzivat 
Message-ID: <29bb1431-1cce-2625-6b11-757005ec9595@alum.mit.edu>
Date: Sun, 22 Mar 2020 16:06:58 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <71da164d-dda4-5e20-6c31-c8849ca71a7e@htt-consult.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:18.7.68.33; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39860400002)(376002)(199004)(46966005)(8676002)(2616005)(356004)(2906002)(26005)(186003)(8936002)(7596002)(36906005)(75432002)(70586007)(956004)(246002)(70206006)(5660300002)(53546011)(31686004)(86362001)(47076004)(786003)(6916009)(336012)(26826003)(478600001)(316002)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR12MB1342; H:outgoing-alum.mit.edu; FPR:; SPF:Pass; LANG:en; PTR:outgoing-alum.mit.edu; A:1; 
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 7a3fa611-97e1-461e-2c66-08d7ce9c948b
X-MS-TrafficTypeDiagnostic: MWHPR12MB1342:
X-Microsoft-Antispam-PRVS: 
X-MS-Oob-TLC-OOBClassifiers: OLM:4941;
X-Forefront-PRVS: 0350D7A55D
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: e2X1eUPYNTJaUVAm8p76keAAPGYYD4cm8w02OC7VeJQp2Xh06cX+NcDH7rQjhSthVyDcdjSWRD2vtWlZQgX7pXJ/ovToX4u9Yv8dflrofrmJGnxpfDVEjc/5y2H9sOTTDhhU7Ucyfck+mWenl05bDOLccet14uQTxnK/U384aO8cIiFIoquQCIoLRgLRkQ/urwBHsi6LjcVfOWzTIKRuCTonnKy2EgKsOJ7zi79eRPDetjD07rWn16qGqV1RhfF2wWHX/rabj0FEnR6hbrPTUsBRtgkWArAEcaDFmJkhv5GwS/3RsHWFMZ77BKwxK24u0GDQOiJ03Rs0y/uiwGBsiX19IrujcyZuuudxIRxwHh7kRgLHPm+0MqFXfSQ2e/HEu39KVM00IkSMlfaRaIHH21z/zkHtXJBB9W6ONtiYdVxqGWELnyLj/YuzXyGOeE9vEGHtEfRLRj5MUcpd8AJGrh48hM6MLUrgJnPREw6No9UyhLwAy0h6EaXZ9JsTsmukDmwKiySqdJUyB1xmsFFyyg==
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2020 20:06:59.8012 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 7a3fa611-97e1-461e-2c66-08d7ce9c948b
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33];  Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1342
Archived-At: 
Subject: Re: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 20:07:05 -0000

On 3/22/20 1:06 PM, Robert Moskowitz wrote:
> 
> 
> On 3/22/20 12:34 PM, Henrik Levkowetz wrote:
>> Hi Bob,
>>
>> On 2020-03-22 15:19, Robert Moskowitz wrote:
>>> A few weeks back, I was editing my old draft ietf-hep-dex and since the
>>> xml in there goes back years, and I was having problems (remember that
>>> pagebreak question?), I thought to 'force' v2 by:
>>>
>>> xml2rfc --v2
>>>
>>> Guess what, no such option but it acted as:
>>>
>>> xml2rfc --v2v3
>>>
>>> !!!
>>>
>>> Something you may want to fix.
>>>
>>> I bring this up now, as I did it again Friday.  I was rushed getting a
>>> bunch of things done and it kind of slipped out.  No harm as I knew
>>> about it from past mess ups.
>> Well, there's no way to force 'v2' for a draft with v3 XML, and unless
>> you explicitly indicate --v3, a draft with v2 xml will be not be 
>> converted
>> to v3 during processing.
>>
>> Abbreviations of long options are accepted as long as they are unique,
>> which is why --v2 did something, instead of being rejected.

To prevent this from happening again, how about defining a --v2 rule? 
(Even if all it does is generate an error.)


From nobody Sun Mar 22 13:35:22 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2CB3A07BB for ; Sun, 22 Mar 2020 13:35:20 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnaZh48OLeW8 for ; Sun, 22 Mar 2020 13:35:18 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [64.170.98.42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01BC23A00C1 for ; Sun, 22 Mar 2020 13:35:17 -0700 (PDT)
Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:57675 helo=tannat.localdomain) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1jG7J8-00060f-Hd; Sun, 22 Mar 2020 13:35:15 -0700
To: Paul Kyzivat , xml2rfc@ietf.org
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>  <71da164d-dda4-5e20-6c31-c8849ca71a7e@htt-consult.com> <29bb1431-1cce-2625-6b11-757005ec9595@alum.mit.edu>
From: Henrik Levkowetz 
Message-ID: <82470033-34fd-6603-6d99-83220c19d8af@levkowetz.com>
Date: Sun, 22 Mar 2020 21:34:44 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <29bb1431-1cce-2625-6b11-757005ec9595@alum.mit.edu>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oDsP7cujHGeLWKBIWmvrSjL4UHeLJtJUG"
X-SA-Exim-Connect-IP: 158.174.202.242
X-SA-Exim-Rcpt-To: xml2rfc@ietf.org, pkyzivat@alum.mit.edu
X-SA-Exim-Mail-From: henrik@levkowetz.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: 
Subject: Re: [xml2rfc] Point about --v2v3 option
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Mar 2020 20:35:21 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--oDsP7cujHGeLWKBIWmvrSjL4UHeLJtJUG
Content-Type: multipart/mixed; boundary="HwKbvTj4AO5fkLNkS0sBM9MXi19VHCwkT";
 protected-headers="v1"
From: Henrik Levkowetz 
To: Paul Kyzivat , xml2rfc@ietf.org
Message-ID: <82470033-34fd-6603-6d99-83220c19d8af@levkowetz.com>
Subject: Re: [xml2rfc] Point about --v2v3 option
References: <5b204bef-17a1-c877-751f-c722b9ed852b@htt-consult.com>
 
 <71da164d-dda4-5e20-6c31-c8849ca71a7e@htt-consult.com>
 <29bb1431-1cce-2625-6b11-757005ec9595@alum.mit.edu>
In-Reply-To: <29bb1431-1cce-2625-6b11-757005ec9595@alum.mit.edu>

--HwKbvTj4AO5fkLNkS0sBM9MXi19VHCwkT
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Paul,

On 2020-03-22 21:06, Paul Kyzivat wrote:
> On 3/22/20 1:06 PM, Robert Moskowitz wrote:
>>=20
>>=20
>> On 3/22/20 12:34 PM, Henrik Levkowetz wrote:
>>> Hi Bob,
>>>
>>> On 2020-03-22 15:19, Robert Moskowitz wrote:
>>>> A few weeks back, I was editing my old draft ietf-hep-dex and since =
the
>>>> xml in there goes back years, and I was having problems (remember th=
at
>>>> pagebreak question?), I thought to 'force' v2 by:
>>>>
>>>> xml2rfc --v2
>>>>
>>>> Guess what, no such option but it acted as:
>>>>
>>>> xml2rfc --v2v3
>>>>
>>>> !!!
>>>>
>>>> Something you may want to fix.
>>>>
>>>> I bring this up now, as I did it again Friday.  I was rushed getting=
 a
>>>> bunch of things done and it kind of slipped out.  No harm as I knew
>>>> about it from past mess ups.
>>> Well, there's no way to force 'v2' for a draft with v3 XML, and unles=
s
>>> you explicitly indicate --v3, a draft with v2 xml will be not be=20
>>> converted
>>> to v3 during processing.
>>>
>>> Abbreviations of long options are accepted as long as they are unique=
,
>>> which is why --v2 did something, instead of being rejected.
>=20
> To prevent this from happening again, how about defining a --v2 rule?=20
> (Even if all it does is generate an error.)

Yes, I thought of that.  Will do so soon (not necessarily in the next
release, though).


	Henrik


--HwKbvTj4AO5fkLNkS0sBM9MXi19VHCwkT--

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

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

iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl53y+QACgkQTptXS4+7
FxoEPA//UkJjsUV3CKfbl06UyIpTxYj2xCZaHBgMt++1RhCht2baIf50ZDPS+uSW
Yt4mh9zRDYe7PAaJ5eJhvtmpJOVgeVqdh42aESKYK+RP1WmqwZt+ZHMBr1lY0s5O
lYZPfQmqqaJuH8c+CwSCujDc3oiWBBShWpf5lf/oQaZs8asydXErB7APKkyfpNr/
wFljkehEgSvZC2QlQtcWWags3odFcmrIZzyMhL66e3udNyjUxx3Z3YxVkmlgaeM0
dRD5DDo9UYKvs7+fho6s7d3KDhZrjU8Mc+zHfvfjyIDbIgAuOOI+Qx8y0RBWGDKu
S/uESlEkOMZon4T0On+GHrcGI3DhoSCuaYR8aBNliqSo4WH0HbRyhiXhPCAelAC5
+3BitORE0Nc7Lc8Q2DQaTj0Lht0rsY2+Bpat1OyP5al0KUahdvsMvVyNhqxH72ej
X9UM6qzqjzcqgpKxCSp2mduhlIIrmnKEuV6x434IFDnWsdFCvZ94RCm85PEJo1R5
RH/8HJ4Gwarz5d4YKDetMCtw4fX7MFLEBSGAoqEW3ZiNqtOjjuGssERSbQcJ7li3
ntz4S172MxlgQc2Dvv1nagq502XBDvMDnTyHZB0XqUCeJRV/5alDqi4/nMea5BCT
ND71T2GFV05AKn1w0V+pLMBCfhjwhhyLfwOxAwi716O5cU34QIM=
=K0DO
-----END PGP SIGNATURE-----

--oDsP7cujHGeLWKBIWmvrSjL4UHeLJtJUG--


From nobody Tue Mar 31 06:59:08 2020
Return-Path: 
X-Original-To: xml2rfc@ietfa.amsl.com
Delivered-To: xml2rfc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7A73A2174 for ; Tue, 31 Mar 2020 06:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Level: 
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[FILL_THIS_FORM=0.001, 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 o2_cBOK4Z5Fx for ; Tue, 31 Mar 2020 06:58:55 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (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 0C60C3A2176 for ; Tue, 31 Mar 2020 06:58:54 -0700 (PDT)
Received: from [192.168.15.137] ([IPv6:2601:184:407f:80ce:4d9c:d19d:3bc5:16ad]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 02VDwjeU030159 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2020 06:58:47 -0700
From: "David R. Oran" 
To: xml2rfc@ietf.org
Date: Tue, 31 Mar 2020 09:58:39 -0400
X-Mailer: MailMate (1.13.1r5680)
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_MailMate_5F5F5079-90CD-440B-AFDE-4B4D9EE2DACF_="
Archived-At: 
Subject: [xml2rfc] Some problems with idnits checks on  V3 document
X-BeenThere: xml2rfc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 31 Mar 2020 13:59:06 -0000

--=_MailMate_5F5F5079-90CD-440B-AFDE-4B4D9EE2DACF_=
Content-Type: multipart/alternative;
 boundary="=_MailMate_6C591296-A53D-47D1-9720-24A9F0D96BCE_="


--=_MailMate_6C591296-A53D-47D1-9720-24A9F0D96BCE_=
Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown
Content-Transfer-Encoding: quoted-printable

One of these seem to be xml2rfc rendering problem; others may be idnit =

glitches that only show up on V3 docs:

- The too long line 1551 is in fact not too long - the length =

computation seems to be screwed up by the non-ascii characters (probably =

idnit problem?)

- somehow xml2rfc elided part of an author name into the updates head =

field and author address into the Intended Status header field. This =

only happens in the .txt output, not the HTML or PDF. xml2rfc bug?

- idnits says this has a downref, but I believe that an I.D. marked =

experimental saying it updates an experimental RFC isn=E2=80=99t a downre=
f, =

right?

I include the idnits output below and the xml file as an attachment =

(note that this is still a bit private - we haven=E2=80=99t submitted yes=
)

Let me know of any followup I should do - would like to get this =

submitted in the next couple of days.

Thanks! DaveO.

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94=E2=80=94=E2=80=94

idnits 2.16.03


tmp/draft-oran-icnrg-reflexive-forwarding.txt:
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii =

character (=EF=BF=BD) in position 18.
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii =

character (=EF=BF=BD) in position 16.
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long: =

the offending characters are 'ch,'
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii =

character (=EF=BF=BD) in position 16.
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii =

character (=EF=BF=BD) in position 67.


   Checking boilerplate required by RFC 5378 and the IETF Trust (see
   https://trustee.ietf.org/license-info):
   ----------------------------------------------------------------------=
------

      No issues found here.

   Checking nits according to =

https://www.ietf.org/id-info/1id-guidelines.txt:
   ----------------------------------------------------------------------=
------

    =3D=3D There are 4 instances of lines with non-ascii characters in th=
e =

document.


   Checking nits according to https://www.ietf.org/id-info/checklist :
   ----------------------------------------------------------------------=
------

   ** There is 1 instance of too long lines in the document, the longest =

one
      being 3 characters in excess of 72.


   Miscellaneous warnings:
   ----------------------------------------------------------------------=
------

   =3D=3D Unrecognized Status in 'Intended status: Experimental  Universi=
ty =

of
      Applied Sciences Emden/Leer', assuming Proposed Standard

      (Expected one of 'Standards Track', 'Full Standard', 'Draft =

Standard',
      'Proposed Standard', 'Best Current Practice', 'Informational',
      'Experimental', 'Informational', 'Historic'.)

   =3D=3D Couldn't figure out when the document was first submitted -- th=
ere =

may
      comments or warnings related to the use of a disclaimer for =

pre-RFC5378
      work that could not be issued because of this.  Please check the =

Legal
      Provisions document at https://trustee.ietf.org/license-info to =

determine
      if you need the pre-RFC5378 disclaimer.


   Checking references for intended status: Proposed Standard
   ----------------------------------------------------------------------=
------

      (See RFCs 3967 and 4897 for information about using normative =

references
      to lower-maturity documents in RFCs)

   ** Downref: Normative reference to an Experimental RFC: RFC 8569

   ** Downref: Normative reference to an Experimental RFC: RFC 8609


      Summary: 3 errors (**), 0 flaws (~~), 4 warnings (=3D=3D), 0 commen=
ts =

(--).

-------------------------------------------------------------------------=
-------


2	ICNRG                                                            D. =

Oran
3	Internet-Draft                       Network Systems Research and =

Design
4	Updates: 8569, 8609 (if approved)                            D. =

Kutscher
5	Intended status: Experimental  University of Applied Sciences =

Emden/Leer
6	Expires: 2 October 2020                                    31 March =

2020

8	            Reflexive Forwarding for CCNx and NDN Protocols
9	                draft-oran-icnrg-reflexive-forwarding-00

11	Abstract

13	   Current Information-Centric Networking protocols such as CCNx and =

NDN
14	   have a wide range of useful applications in content retrieval and
15	   other scenarios that depend only on a robust two-way exchange in =

the
16	   form of a request and response (represented by an _Interest-Data
17	   exchange_ in the case of the two protocols noted above).  A number =

of
18	   important applications however, require placing large amounts of =

data
19	   in the Interest message, and/or more than one two-way handshake.
20	   While these can be accomplished using independent Interest-Data
21	   exchanges by reversing the roles of consumer and producer, such
22	   approaches can be both clumsy for applications and problematic =

from a
23	   state management, congestion control, or security standpoint.  =

This
24	   specification proposes a _Reflexive Forwarding_ extension to the =

CCNx
25	   and NDN protocol architectures that eliminates the problems =

inherent
26	   in using independent Interest-Data exchanges for such =

applications.
27	   It updates RFC8569 and RFC8609.

29	Status of This Memo

31	   This Internet-Draft is submitted in full conformance with the
32	   provisions of BCP 78 and BCP 79.

34	   Internet-Drafts are working documents of the Internet Engineering
35	   Task Force (IETF).  Note that other groups may also distribute
36	   working documents as Internet-Drafts.  The list of current =

Internet-
37	   Drafts is at https://datatracker.ietf.org/drafts/current/.

39	   Internet-Drafts are draft documents valid for a maximum of six =

months
40	   and may be updated, replaced, or obsoleted by other documents at =

any
41	   time.  It is inappropriate to use Internet-Drafts as reference
42	   material or to cite them other than as "work in progress."

44	   This Internet-Draft will expire on 2 October 2020.

46	Copyright Notice

48	   Copyright (c) 2020 IETF Trust and the persons identified as the
49	   document authors.  All rights reserved.

51	   This document is subject to BCP 78 and the IETF Trust's Legal
52	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
53	   license-info) in effect on the date of publication of this =

document.
54	   Please review these documents carefully, as they describe your =

rights
55	   and restrictions with respect to this document.

57	Table of Contents

59	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  =

  3
60	     1.1.  Problems with pushing data  . . . . . . . . . . . . . . .  =

  4
61	     1.2.  Problems with utilizing independent exchanges . . . . . .  =

  5
62	   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .  =

  6
63	   3.  Overview of the Reflexive Forwarding design . . . . . . . . .  =

  6
64	   4.  Naming of Reflexive Interests . . . . . . . . . . . . . . . .  =

10
65	   5.  Forwarder operation for Reflexive Interests . . . . . . . . .  =

11
66	   6.  State coupling between producer and consumer  . . . . . . . .  =

12
67	   7.  Use cases for Reflexive Interests . . . . . . . . . . . . . .  =

12
68	     7.1.  Achieving Remote Method Invocation with Reflexive
69	           Interests . . . . . . . . . . . . . . . . . . . . . . . .  =

12
70	     7.2.  RESTful Web Interactions  . . . . . . . . . . . . . . . .  =

15
71	     7.3.  Achieving simple data pull from consumers with reflexive
72	           Interests . . . . . . . . . . . . . . . . . . . . . . . .  =

15
73	   8.  Implementation Considerations . . . . . . . . . . . . . . . .  =

19
74	     8.1.  Forwarder implementation considerations . . . . . . . . .  =

19
75	       8.1.1.  Forwarding Information Base (FIB) . . . . . . . . . .  =

19
76	       8.1.2.  Interactions with Interest Lifetime . . . . . . . . .  =

20
77	       8.1.3.  Interactions with Interest aggregation  . . . . . . .  =

21
78	     8.2.  Consumer Implementation Considerations  . . . . . . . . .  =

21
79	       8.2.1.  Data objects returned by the consumer to reflexive =

name
80	               Interests arriving from a producer  . . . . . . . . .  =

21
81	       8.2.2.  Terminating unwanted reflexive Interest exchanges . .  =

22
82	       8.2.3.  Interactions with caching . . . . . . . . . . . . . .  =

22
83	     8.3.  Producer Implementation Considerations  . . . . . . . . .  =

22
84	   9.  Operational Considerations  . . . . . . . . . . . . . . . . .  =

23
85	   10. Mapping to CCNx and NDN packet encodings  . . . . . . . . . .  =

24
86	     10.1.  Packet encoding for CCNx . . . . . . . . . . . . . . . .  =

24
87	     10.2.  Packet encoding for NDN  . . . . . . . . . . . . . . . .  =

24
88	   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  =

24
89	   12. Security Considerations . . . . . . . . . . . . . . . . . . .  =

25
90	     12.1.  Collisions of reflexive Interest names . . . . . . . . .  =

25
91	     12.2.  Additional resource pressure on PIT and FIB  . . . . . .  =

26
92	     12.3.  Privacy Considerations . . . . . . . . . . . . . . . . .  =

26
93	   13. Normative References  . . . . . . . . . . . . . . . . . . . .  =

27
94	   14. Informative References  . . . . . . . . . . . . . . . . . . .  =

27
95	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  =

30

97	1.  Introduction

99	   Current ICN protocols such as CCNx [RFC8569] and [NDN] have a wide
100	   range of useful applications in content retrieval and other =

scenarios
101	   that depend only on a robust two-way exchange in the form of a
102	   request and response.  These ICN architectures use the terms
103	   "consumer" and "producer" for the respective roles of the =

requester
104	   and the responder, and the protocols directly capture the =

mechanics
105	   of the two-way exchange through the "Interest message" carrying =

the
106	   request, and the "Data message" carrying the response.  Through =

these
107	   constructs, the protocols are heavily biased toward a pure _pull-
108	   based_ interaction model where requests are small (carrying =

little or
109	   no user-supplied data other than the name of the requested data
110	   object), and responses are relatively large - up to an =

architecture-
111	   defined maximum transmission unit (MTU) on the order of kilobytes =

or
112	   tens of kilobytes.

114	   A number of important applications however require interaction =

models
115	   more complex than individual request/response interactions in the
116	   same direction (i.e. between the same consumer and one or more
117	   producers).  Among these we identify three important classes =

which
118	   are the target of the proposed enhancements defined in this
119	   specification.  These are described in the following paragraphs.

121	   *Remote Method Invocation (RMI, aka RPC):*  When invoking a =

remote
122	      method, it is common for the method to require arguments =

supplied
123	      by the caller.  In conventional TCP/IP style protocols like =

CORBA
124	      or HTTP "Post", these are pushed to the server as part of the
125	      message or messages that comprise the request.  In ICN-style
126	      protocols there is an unattractive choice between inflating =

the
127	      request initiation with pushed arguments, or arranging to have =

one
128	      or more independent request/responses in the opposite =

direction
129	      for the server to fetch the arguments.  Both of these =

approaches
130	      have substantial disadvantages.  Recently, a viable =

alternative
131	      emerged through the work on RICE [Krol2018] which pioneered =

the
132	      main design elements proposed in this specification.

134	   *Phone-Home scenario:*  Applications in sensing, =

Internet-of-things
135	      (IoT) and other types where data is produced unpredictably and
136	      needs to be _pushed_ somewhere create a conundrum for the pure
137	      pull-based architectures considered here.  If instead one =

eschews
138	      relaxing the size asymmetry between requests and responses, =

some
139	      additional protocol machinery is needed.  Earlier efforts in =

the
140	      ICN community have recognized this issue and designed methods =

to
141	      provoke a cooperating element to issue a request to return the
142	      data the originator desires to push, essentially "phoning =

home" to
143	      get the responder to fetch the data.  One that has been =

explored
144	      to some extent is the _Interest-Interest-Data_ exchange
145	      [Carzaniga2011], where an Interest is sent containing the =

desired
146	      request as encapsulated data.  CCNx-1.0 Bidirectional Streams
147	      [Mosko2017] are also based on a scheme where an Interest is =

used
148	      to signal a name prefix that a consumer has registered for
149	      receiving Interests from a peer in a bidirectional streaming
150	      session.

152	   *Peer state synchronization:*  A large class of applications,
153	      typified by those built on top of on reliable order-preserving
154	      transport protocols, require initial state synchronization =

between
155	      the peers.  This is accomplished with a three-way (or longer)
156	      handshake, since employing a two-way handshake as provided in =

the
157	      existing NDN and CCNx protocols exposes a number of well-know
158	      hazards, such as _half-open connections_. When attempted for
159	      security-related operations such as key exchange, additional
160	      hazards such as _man-in-the-middle_ attacks become trivial to
161	      mount.  Existing alternatives, similar to those used in the =

two
162	      examples above, instead utilize either overlapping =

Interest-Data
163	      exchanges in opposite directions (resulting in a four-way
164	      handshake) or by adding initialization data to the initial =

request
165	      and employing an Interest-Interest-Data protocol extension as
166	      noted in the Phone-home scenarios above.

168	   All of the above application interaction models present =

interesting
169	   challenges, as neither relaxing the architecture to support =

pushing
170	   large amounts of data, nor introducing substantial complexities
171	   through multiple independent Interest-Data exchanges is an =

attractive
172	   approach.  The following subsections provide further background =

and
173	   justification for why push and/or independent exchanges are
174	   problematical.

176	1.1.  Problems with pushing data

178	   There are two substantial problems with the simple approach of =

just
179	   allowing arbitrary amounts of data to be included with requests.
180	   These are:

182	   1.  In ICN protocols, Interest messages are intended to be small, =

on
183	       the order the size of a TCP ACK, as opposed to the size of a =

TCP
184	       data segment.  This is because the hop-by-hop congestion =

control
185	       and forwarder state management requires Interest messages to =

be
186	       buffered in expectation of returning data, and possibly
187	       retransmitted hop-by-hop as opposed to end-to-end.  In =

addition,
188	       the need to create and manage state on a per-Interest basis =

is
189	       substantially complicated if requests in Interest messages =

are
190	       larger than a Path MTU (PMTU) and need to be fragmented =

hop-by-
191	       hop.

193	   2.  If the payload data of a request is used for invoking a
194	       computation (as in the RMI case described above) then =

substantial
195	       bandwidth can be wasted if the computation is either refused =

or
196	       abandoned for any number of reasons, including the requestor
197	       failing an authorization check, or the responder not having
198	       sufficient resources to execute the associated computation.

200	   These problems also exist in pure datagram transport protocols =

such
201	   as those used for legacy RMI applications like NFS [RFC7530].  =

More
202	   usual are application protocols like HTTP(s) which rely on the =

TCP or
203	   QUIC 3-way handshake to establish a session and then have =

congestion
204	   control and segmentation provided as part of the transport =

protocol,
205	   further allowing sessions to be rejected before large amounts of =

data
206	   are transmitted or significant computational resources expended.

208	1.2.  Problems with utilizing independent exchanges

210	   In order to either complete a three-way handshake, or fetch data =

via
211	   a pull from the original requestor, the role of consumer and =

producer
212	   need to be reversed and an Interest/Data exchange initiated in =

the
213	   direction opposite of the initiating exchange.  When done with an
214	   independent Interest/Data request and response, a number of
215	   complications ensue.  Among them are:

217	   1.  The originating consumer needs to have a routable name prefix
218	       that can be used for the exchange.  This means the consumer =

must
219	       arrange to have its name prefix propagated in the ICN routing
220	       system with sufficient reach that the producer issuing the
221	       interest can be assured it is routed appropriately.  While =

some
222	       consumers are generally online and act as application =

servers,
223	       justifying the maintenance of this routing information, many =

do
224	       not.  Further, in mobile environments, a pure consumer that =

does
225	       not need to have a routable name prefix can benefit from the
226	       inherent consumer mobility support in the CCNx and NDN =

protocols.
227	       By requiring a routable name prefix, extra mobile routing
228	       machinery is needed, such as that proposed in KITE =

[Zhang2018] or
229	       MAPME [Auge2018].

231	   2.  The consumer name prefix in item (1) above must be =

communicated
232	       to the producer as a payload, name suffix, or other field of =

the
233	       initiating Interest message.  Since this name in its entirety =

is
234	       chosen by the consumer, it is highly problematic from a =

security
235	       standpoint, as it can recruit the producer to mount a =

reflection
236	       attack against the consumer's chosen victim.

238	   3.  The correlation between the exchanges in opposite directions =

must
239	       be maintained by both the consumer and the producer as
240	       independent state, as opposed to being architecturally tied
241	       together as would be the case with a conventional 3-way =

handshake
242	       finite state machine.  While this can of course be =

accomplished
243	       with care by both parties, experience has shown that it is =

error
244	       prone (for example see the checkered history of interactions
245	       between the SIP [RFC3261] and SDP Offer-Answer [RFC6337])
246	       protocols.  When employed as the wrapper for a key management
247	       protocol such as with TLS [RFC8446] state management errors =

can
248	       be catastrophic for security.

250	2.  Requirements Language

252	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =

NOT",
253	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", =

and
254	   "OPTIONAL" in this document are to be interpreted as described in
255	   [RFC2119].

257	3.  Overview of the Reflexive Forwarding design

259	   This specification defines a _Reflexive Forwarding_ extension to =

CCNx
260	   and NDN that avoids the problems enumerated in Sections 1.1 and =

1.2.
261	   It straightforwardly exploits the hop-by-hop state and symmetric
262	   routing properties of the current protocols.

264	   Figure 1 below illustrates a canonical NDN/CCNx forwarder with =

its
265	   conceptual data structures of the Content Store (CS), Pending
266	   Interest Table (PIT) and Forwarding Information Base (FIB).  The =

key
267	   observation involves the relation between the PIT and the FIB.  =

Upon
268	   arrival of an Interest, a PIT entry is created which contains =

state
269	   recording the incoming interface on which the Interest.  If the
270	   Interest is not immediately satisfied by cached data in the CS, =

the
271	   forwarder looks up the name in the FIB to ascertain the =

_next-hop_ to
272	   propagate the Interest onward upstream toward the named producer.
273	   Therefore, a chain of forwarding state is established during =

Interest
274	   forwarding that couples the PIT entries of the chain of =

forwarders
275	   together conceptually as _breadcrumbs_. These are used to forward =

the
276	   returning Data Message over the inverse path through the chain of
277	   forwarders until the Data message arrives at the originating
278	   consumer.  The state in the PITs is _unwound_ by destroying it as
279	   each PIT entry is _satisfied_. This behavior is *critical* to the
280	   feasibility of the reflexive forwarding design we propose.

282	    =

+-----------------------------------------------------------------+
283	    |                                                      ICN Node  =

  |
284	    | Send data to all                                     =3D=3D=3D=3D=
=3D=3D=3D=3D  =

  |
285	    | interfaces that                                                =

  |
286	    | requested it                                                   =

  |
287	    |                  YES +------------------+                      =

  |
288	   <------------------------| Pending Interest |  =

<---------------------
289	    |              |       |    Table (PIT)   |               Data   =

  |
290	    |              |       +------------------+  1) Find     =

(Signed) |
291	    |              | 2) Save         |              Name             =

  |
292	    |              V    Data         | NO            in              =

  |
293	    |   +---------------+            |              PIT?             =

  |
294	    |   | Content Store |            |                               =

  |
295	    |   |      (CS)     |            |                               =

  |
296	    |   +---------------+            |                               =

  |
297	    |                                |                               =

  |
298	    |                                V                               =

  |
299	    |                             Drop Data                          =

  |
300	    |                                                                =

  |
301	    =

+-----------------------------------------------------------------+
302	    =

+-----------------------------------------------------------------+
303	    |                                                      ICN Node  =

  |
304	    |                                                      =3D=3D=3D=3D=
=3D=3D=3D=3D  =

  |
305	    |                                                                =

  |
306	    |                                           =

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+|
307	    |                                           |Forwarding Strategy =

||
308	    |                                           =

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+|
309	    |                                                                =

  |
310	    |   1) Find name          2) Matching        3) Find matching    =

  |
311	    |        in CS?              name in PIT?       entry in FIB?    =

  |
312	    |                    NO                   NO                   =

YES|
313	    |  +---------------+   +----------------+   =

+-------------------+ |
314	    |  | Content Store |   |   Pending      |   |  Forwarding       =

| |
315	   --->|      (CS)     |-->|   Interest     |-->|  Information Base =

|-->
316	    |  |               |   |   Table (PIT)  |   |     ( FIB)        =

| |
317	    |  +---------------+   +----------------+   =

+-------------------+ |
318	    | Return   | YES           YES | NO               NO |           =

  |
319	    |  Data    |          Add      |   Add               |  Drop     =

  |
320	    |          |          Incoming |   new               |   or      =

  |
321	    |   <------|          Itf.     |   Interest          |  NACK     =

  |
322	    |                              V                     V           =

  |
323	    |                                                                =

  |
324	    =

+-----------------------------------------------------------------+

326	                     Figure 1: ICN forwarder structure

328	   Given the above forwarding properties for Interests, it should be
329	   clear that while an Interest is outstanding and ultimately =

arrives at
330	   a producer who can respond to it, there is sufficient state in =

the
331	   chain of forwarders to route not just a returning Data message, =

but
332	   potentially another Interest directed through the inverse path to =

the
333	   unique consumer who issued the original Interest.  (Section 8.1.3
334	   describes how Interest aggregation interacts with this scheme.)  =

The
335	   key question therefore is how to access this state in a way that =

it
336	   can be used to forward Interests.

338	   In order to achieve this _Reflexive Interest_ forwarding on the
339	   inverse path recorded in the PIT of each forwarder, we need a few
340	   critical design elements.  These are as follows:

342	   1.  The Reflexive Interest needs to have a Name.  This name is =

what
343	       the originating consumer will use to match against the Data
344	       object (or objects - more on this later) it wishes the =

producer
345	       to fetch by issuing the Reflexive Interest.  This cannot be =

just
346	       any name, but needs to essentially name the state already
347	       recorded in the PIT and not allow the consumer to manufacture =

an
348	       arbitrary name and mount a reflection attack as pointed out =

in
349	       Section 1.2, Paragraph 2, Item 2.

351	   2.  There has to be a FIB entry at each forwarder for this name
352	       prefix so that when the reflexive interest arrives, the =

forwarder
353	       can forward it downstream toward the originating consumer.  =

This
354	       FIB entry points directly to the incoming interface on which =

the
355	       corresponding original Interest arrived.  The FIB entry needs =

to
356	       be created as part of the forwarding of the original Interest =

so
357	       that it is available in time to catch any reflexive Interest
358	       issued by the producer.  It usually makes sense to destroy =

this
359	       FIB entry when the Data message satisfying the original =

Interest
360	       arrives since this avoids any dangling stale state.  Given =

the
361	       deign details documented later in this specification, stale =

FIB
362	       state does not represent a correctness hazard and hence can =

be
363	       done lazily if desired in an implementation.  See Section 5 =

for
364	       more details on FIB operation considerations.

366	   3.  There has to be coupling of the state between the originating
367	       Interest-Data exchange and the enclosed Reflexive =

Interest-Data
368	       exchange at both the consumer and the producer.  In our =

design,
369	       this accomplished by the way reflexive interest names are =

chosen.

371	   The following sections provide the normative details on each of =

these
372	   design elements.  The overall interaction flow for reflexive
373	   forwarding is illustrated below in Figure 2.

375	   +-----------+    +-----------+                  +-----------+
376	   | Consumer  |    | Forwarder |                  | Producer  |
377	   +-----------+    +-----------+                  +-----------+
378	         |                |                              |
379	         | I1             |                              |
380	         |--------------->|                              |
381	         |--------------\ |                              |
382	         || Install RNP |-|                              |
383	         || in FIB      | |                              |
384	         ||-------------| |                              |
385	         |                |                              |
386	         |                | I1                           |
387	         |                |----------------------------->|
388	         |                |                              | =

-----------\
389	         |                |                              |-| Create  =

  |
390	         |                |                              | | RI =

state |
391	         |                |                              | =

|----------|
392	         |                |                              |
393	         |                |                           RI |
394	         |                |<-----------------------------|
395	         |                | --------------------\        |
396	         |                |-| lookup RNP in FIB |        |
397	         |                | |-------------------|        |
398	         |                |                              |
399	         |             RI |                              |
400	         |<---------------|                              |
401	         |                |                              |
402	         | D2             |                              |
403	         |--------------->|                              |
404	         |                |                              |
405	         |                | D2                           |
406	         |                |----------------------------->|
407	         |                |                              | =

------------\
408	         |                |                              |-| answer =

I1 |
409	         |                |                              | =

|-----------|
410	         |                |                              |
411	         |                |                           D1 |
412	         |                |<-----------------------------|
413	         |                | -----------------------\     |
414	         |                |-| remove RNP FIB entry |     |
415	         |                | |----------------------|     |
416	         |                |                              |
417	         |             D1 |                              |
418	         |<---------------|                              |
419	         |                |                              |

421	       Legend:
422	       I1: Interest #1 containing the Reflexive Name Prefix TLV
423	       RI: Reflexive Interest with Reflexive Name Prefix Component
424	       RNP: Reflexive Name Prefix
425	       D1: Data message, answering initiating I1 Interest
426	       D2: Data message, answering RI

428	                      Figure 2: Message Flow Overview

430	4.  Naming of Reflexive Interests

432	   A consumer may have one or more objects for the producer to =

fetch,
433	   and therefore needs to communicate enough information in their
434	   initial Interest to allow the producer to construct properly =

formed
435	   reflexive Interest names.  For some applications the set of _full
436	   names_ (see [I-D.irtf-icnrg-terminology]) is known a priori, for
437	   example through compile time bindings of arguments in interface
438	   definitions or by the architectural definition of a simple sensor
439	   reading.  In other cases the full names of the individual objects
440	   must be communicated in the original Interest message.  In all =

cases
441	   enough state must be provided by the consumer for the forwarders =

to
442	   construct a FIB entry (as noted in Section 3, Paragraph 6, Item =

2).
443	   This is accomplished through the following naming construct.

445	   We define a new typed name component, identified by a registered =

name
446	   component type in the IANA registry for [RFC8569].  We call this =

the
447	   _Reflexive Interest Name Component type_. It MUST be the first =

(i.e.
448	   high order) name component of any Reflexive Interest issued by a
449	   producer.  Its value is a random 64 bit number, assigned by the
450	   consumer, which provides the entropy required to uniquely =

identify
451	   the issuing consumer for the duration of any outstanding =

Interest-
452	   Data exchange.  The consumer SHOULD choose a different random =

value
453	   for each Interest message it constructs, for two reasons:

455	   1.  If stale FIB sate is present, the randomness prevents =

potential
456	       mis-routing of reflexive interests (see Section 8.1.1 below =

for
457	       more details), and

459	   2.  Re-use of the same reflexive interest name over multiple
460	       interactions might reveal linkability information that could =

be
461	       used by surveillance adversaries for tracking purposes.

463	   This initial name component is either communicated by itself =

through
464	   a _Reflexive Name Prefix TLV_ in the originating Interest, or
465	   prepended to any object names the consumer wishes the producer to
466	   fetch explicitly where there is more than one object needed by =

the
467	   producer for the current Interest-Data interaction.  There are =

four
468	   cases to consider:

470	   1.  The reflexive _fullname_ of a single object to fetch.

472	   2.  A single reflexive name prefix out of which the producer can =

(by
473	       application-specific means) construct a number of _fullnames_ =

of
474	       the objects it may want to fetch,

476	   3.  The reflexive _fullname_ of a FLIC Manifest =

[I-D.irtf-icnrg-flic]
477	       enumerating the suffixes that may be used by the producer to
478	       construct the necessary names,

480	   4.  Multiple reflexive name TLVs MAY be included in the Interest
481	       message if none of the above 3 options covers the desired use
482	       case.

484	   The last of the four options above, while not explicitly =

outlawed,
485	   SHOULD NOT be used.  This is because it results in a longer =

Interest
486	   message and requires extra FIB resources.  Hence, it is more =

likely a
487	   forwarder will reject the Interest for lack of resources.  A
488	   forwarder MAY optimize for the case of a single Reflexive Name =

TLV at
489	   the expense of those with more than one.

491	   A producer, upon receiving an Interest with one or more Reflexive
492	   Name TLVs, may decide it needs the pull the associated data
493	   object(s).  It therefore can issue one or more Reflexive =

Interests by
494	   appending the necessary name components needed to form valid full
495	   names of the associated objects present at the originating =

consumer.
496	   These in fact comprise conventional Interest-Data exchanges, with =

no
497	   alteration of the usual semantics with regard to signatures, =

caching,
498	   expiration, etc.  When the producer has retrieved the required
499	   objects to complete the original Interest-Data exchange, it can =

issue
500	   its Data response, which unwinds all the established state at the
501	   producer, the consumer, and the intermediate forwarders.

503	5.  Forwarder operation for Reflexive Interests

505	   The forwarder operation for CCNx and/or NDN is changed in three
506	   respects when supporting Reflexive Interests.

508	   1.  The forwarder MUST create short-lifetime FIB entries for any
509	       Reflexive Interest Name prefixes communicated in an Interest
510	       message.  If the forwarder does not have sufficient resources =

to
511	       do so, it MUST reject the Interest with the =

T_RETURN_NO_RESOURCES
512	       error - the same error used if the forwarder were lacking
513	       sufficient PIT resources to process the Interest message.

515	   2.  Those FIB entries MUST be queried whenever an Interest =

message
516	       arrives whose first name component is of the type _Reflexive
517	       Interest Name Component_

519	   3.  The FIB entry MUST be removed eventually, after the =

corresponding
520	       Data message has been forwarded.  One option would be to =

remove
521	       the FIB directly after the Data message has been forwarded.
522	       However, the forwarder MAY do lazy cleanup.

524	   The PIT entry for the Reflexive Interest is consumed per regular
525	   Interest/Data message forwarding requirements.  The PIT entry for =

the
526	   originating Interest (that communicated the Reflexive Interest =

Name)
527	   is also consumed by a final Data message from the producer to the
528	   original consumer.

530	6.  State coupling between producer and consumer

532	   A consumer that wishes to use this scheme MUST utilize one of the
533	   reflexive naming options defined in Section 4 and include it in =

the
534	   corresponding Interest message.  The Reflexive Name TLV _and_ the
535	   full name of the requested data object (that identifies the =

producer)
536	   identify the common state shared by the consumer and the =

producer.
537	   When the producer responds by sending Interests with the =

Reflexive
538	   Name Prefix, the original consumer therefore has sufficient
539	   information to map these Interests to the ongoing Interest-Data
540	   exchange.

542	   The exchange is finished when the producer who received the =

original
543	   Interest message responds with a Data message (or an Interest =

Return
544	   message in the case of error) answering the original Interest.  =

After
545	   sending this Data message, the producer SHOULD destroy the
546	   corresponding shared state.  It MAY decide to use a timer that =

will
547	   trigger a later state destruction.  After receiving this Data
548	   message, the originating consumer MUST destroy the corresponding
549	   Interest-Data exchange state.

551	7.  Use cases for Reflexive Interests

553	7.1.  Achieving Remote Method Invocation with Reflexive Interests

555	   RICE (Remote Method Invocation in ICN) [Krol2018] uses the =

Reflexive
556	   Interest Forwarding scheme that inspired the design specified in =

this
557	   document.

559	   In RICE, the original Interest denotes the remote method (plus
560	   potential parameters) to be invoked at a producer (server).  =

Before
561	   committing any computating resources, the server can then request
562	   authentication credentials and (optional) parameters using =

reflexive
563	   Interest-Data exchanges.

565	   When the server has obtained the necessary credentials and input
566	   parameters, it can decide to commit computing resources, starts =

the
567	   compute process, and returns a handle ("Thunk") in the final Data
568	   message to the original consumer (client).

570	   The client would later request the computation results using a
571	   regular Interest-Data exchange (outside the Reflexive-Interest
572	   transaction) -- using the Thunk as a name for the computation =

result.

574	   Figure 3 depicts an abstract message diagram for RICE.  In =

addition
575	   to the 4-way Reflexive Forwarding Handshake (see Figure 2 for the
576	   details of the interaction), RICE adds another (standard) ICN
577	   Interest/Data exchange for transmitting the RMI result.  The =

Thunk
578	   name is provided to the consumer in the D1 DATA message =

(answering
579	   the initial I1 Interest).

581	   +-----------+              +-----------+
582	   | Consumer  |              | Producer  |
583	   +-----------+              +-----------+
584	         |                          |
585	         | I1                       |
586	         |------------------------->|
587	         |                          | ---------------------\
588	         |                          |-| Requesting request |
589	         |                          | | parameters         |
590	         |                          | | and credentials    |
591	         |                          | |--------------------|
592	         |                          |
593	         |                       RI |
594	         |<-------------------------|
595	         |                          |
596	         | D2                       |
597	         |------------------------->|
598	         |                          | --------------------\
599	         |                          |-| Commit compute    |
600	         |                          | | resources,        |
601	         |                          | | return Thunk name |
602	         |                          | |-------------------|
603	         |                          |
604	         |                       D1 |
605	         |<-------------------------|
606	         |                          | ----------------\
607	         |                          |-| Invoke Remote |
608	         |                          | | Method        |
609	         |                          | |---------------|
610	         | -------------------\     |
611	         |-| After some time, |     |
612	         | | request result   |     |
613	         | |------------------|     |
614	         |                          |
615	         | I3                       |
616	         |------------------------->|
617	         |                          |
618	         |                       D3 |
619	         |<-------------------------|
620	         |                          |
621	       Legend:
622	       I1: Interest #1 containing the Reflexive Name Prefix TLV
623	       D1: Data message, answering initiating I1 Interest,
624	           returning Thunk name
625	       D2: Data message, answering RI (parameters, credentials)
626	       I3: Regular Interest for Thunk (compute result)
627	       D3: Data message, answering I3
628	                        Figure 3: RICE Message Flow

630	7.2.  RESTful Web Interactions

632	   In todays HTTP-based web, RESTful (Representational State =

Transfer)
633	   web interactions are realized by sending requests in a =

client/server
634	   interaction, where the requests provides the application context =

(or
635	   a reference to it).  It has been noted in [Moiseenko2014] that
636	   corresponding requests often exceed the response messages in =

size,
637	   and that this raises the problems noted in Section 1.1 when
638	   attempting to map such exchanges directly to CCNx/NDN.

640	   Another reason not to include all request parameters in a =

(possibly
641	   encrypted) Interest message is the fact that a server (that is
642	   serving thousands of clients) would be obliged to receive, =

possibly
643	   decrypt and parse the complete requests before being able to
644	   determine whether the requestor is authorized, whether the =

request
645	   can be served etc.  Many non-trivial requests could thus lead to
646	   computational overload attacks.

648	   Using Reflexive Interest Forwarding for RESTful Web Interactions
649	   would encode the REST request in the Original request, together =

with
650	   a Reflexive Interest Prefix that the server could then use to get
651	   back to the client for authentication credentials and request
652	   parameters, such as cookies.  The request result (response =

message)
653	   could either be transmitted in the Data message answering the
654	   original request, or -- in case of dynamic, longer-running
655	   computations -- in a seperate Interest/Data exchange, potentially
656	   leveraging the Thunk scheme described in section Section 7.1.

658	   Unlike approaches where clients have to signal a globally =

routable
659	   prefix to the network, this approach would not require the client
660	   (original consumer) to expose its identity to the network (the
661	   network only sees the temporary Reflexive Name Prefix), but it =

would
662	   still be possible to authenticate the client at the server.

664	7.3.  Achieving simple data pull from consumers with reflexive =

Interests

666	   An oft-cited use case for ICN network architectures is _Internet =

of
667	   Things_ (IoT), where the sources of data are limited-resource =

sensor/
668	   actuators.  Many approaches have been tried (e.g.  =

[Baccelli2014],
669	   [Lindgren2016], [Gundogan2018]) with varying degrees of success =

in
670	   addressing the issues outlined in Section 1.1.  The reflexive
671	   forwarding extension may substantially ameliorate the documented
672	   difficulties by allowing a different model for the basic =

interaction
673	   of sensors with the ICN network.

675	   Instead of acting as a producer (either directly to the Internet =

or
676	   indirectly through the use of some form of application-layer
677	   gateway), the IoT device need only act as a consumer.  When it =

has
678	   data to provide, it issues a "phone-home" Interest message to a =

pre-
679	   configured rendezvous name (e.g. an application-layer gateway or =

ICN
680	   Repo [Chen2015]) and provides a reflexive name prefix TLV for the
681	   data it wishes to publish.  The target producer may then issue =

the
682	   necessary reflexive Interest message(s) to fetch the data.  Once
683	   fetched, validated, and stored, the producer then responds to the
684	   original Interest message with a success indication, possibly
685	   containing a Data object if needed to allow the originating =

device to
686	   modify its internal state.  Alternatively, the producer might =

choose
687	   to not respond and allow the original Interest to time out, =

although
688	   this is NOT RECOMMENDED except in cases where the extra message
689	   transmission bandwith is at a premium compared to the persistence =

of
690	   stale state in the forwarders.  We note that this interaction
691	   approach mirrors the earlier efforts using Interest-Interest-Data
692	   designs.

694	   Figure 4 depicts this interaction with the OPTIONAL D1 message.  =

See
695	   Figure 2 for the details of the general Reflexive Forwarding
696	   interaction.

698	                +-----------+ +-----------+
699	                | Consumer  | | Producer  |
700	                +-----------+ +-----------+
701	        ------------\ |             |
702	        | new IoT   |-|             |
703	        | data item | |             |
704	        | produced  | |             |
705	        |-----------| |             |
706	     ---------------\ |             |
707	     | "phone home" |-|             |
708	     | by notifying | |             |
709	     | producer     | |             |
710	     |--------------| |             |
711	                      |             |
712	                      | I1          |
713	                      |------------>|
714	                      |             | --------------------\
715	                      |             |-| generate Interest |
716	                      |             | | for IoT data      |
717	                      |             | |-------------------|
718	                      |             |
719	                      |          RI |
720	                      |<------------|
721	   -----------------\ |             |
722	   | send requested |-|             |
723	   | data object    | |             |
724	   |----------------| |             |
725	                      |             |
726	                      | D2          |
727	                      |------------>|
728	                      |             | -----------------------\
729	                      |             |-| finalize interaction |
730	                      |             | | with optional        |
731	                      |             | | Data message         |
732	                      |             | |----------------------|
733	                      |             |
734	                      |          D1 |
735	                      |<------------|
736	                      |             |
737	       Legend:
738	       I1: Interest #1 containing the Reflexive Name Prefix TLV
739	       D1: Data message (OPTIONAL), finalizing interaction
740	       D1: Data message, answering RI, returning IoT data object

742	                    Figure 4: "Phone Home" Message Flow

744	   There are two approaches that the IoT device can use for its =

response
745	   to a reflexive Interest.  It can simply construct a Data Message
746	   bound through the usual ICN hash name to the reflexive Interest =

name.
747	   Since the scope of any data object bound in this way is only the
748	   duration of the enclosing Interest-Data exchange (see Section =

8.2)
749	   the producer would need to itself construct any persistent Data
750	   object, name it, and sign it.  This is sometimes the right =

approach,
751	   as for some applications the identity of the originating IoT =

device
752	   is not important from an operational or security point of view; =

in
753	   contrast the identity of the gateway or Repo is what matters.

755	   If alternatively, the persistent Data object should be bound from =

a
756	   naming and security point of view to the originating IoT device, =

this
757	   can be easily accomplished.  Instead of directly placing the =

content
758	   in a Data object responding to the reflexive Interest as above, =

the
759	   consumer encapsulates a complete CCNx/NDN Data message (which
760	   includes the desired name of the data) as in the response to the
761	   reflexive Interest message.

763	   The interaction model described above brings a number potential
764	   advantages, some obvious, some less so.  We enumerate a few of =

them
765	   as follows:

767	   *  By not requiring the IoT device to be actively listening for
768	      Interests, it can sleep and only wake up if it has something =

to
769	      communicate.  Conversely, parties interested in obtaining data
770	      from the device do not need to be constantly polling in order =

to
771	      ascertain if there is new data available.

773	   *  No forwarder resources are tied up with state apart from the
774	      actual reflexive forwarding interactions.  All that is needed =

is
775	      enough routing state in the FIB to be able to forward the =

"phone
776	      home" Interest to an appropriate target producer.  While this
777	      model does not provide all the richness of a full Pub/Sub =

system
778	      (like that described in [Gundogan2018]) we argue it is =

adequate
779	      for a large subclass of such applications.

781	   *  The reflexive interest, through either a name suffix or =

Interest
782	      payload, can give the IoT device useful context from which to
783	      craft its Data object in response.  One highly useful =

parameter
784	      would be a robust clock value for the device to use as a =

timestamp
785	      of the data, possibly as part of its name to correctly place =

it in
786	      a time seres of sensor readings.  This substantially =

alleviates
787	      the need for low-end devices to have a robust time base, as =

long
788	      as they trust the producer they contact to provide it.

790	8.  Implementation Considerations

792	   There are a number of important aspects to the reflexive =

forwarding
793	   design which affect correctness and performance of existing
794	   forwarder, consumer, and producer implementations desiring to =

support
795	   it.  This section discusses the effect on each of these elements =

of
796	   the CCNx/NDN protocol architecture.

798	8.1.  Forwarder implementation considerations

800	8.1.1.  Forwarding Information Base (FIB)

802	   The FIB is a performance-critical data structure in any =

forwarder, as
803	   it needs to support relatively expensive longest name prefix =

match
804	   (LNPM) lookup algorithms.  A number of well-known FIB data =

structures
805	   are heavily optimized for read access, since for normal Interest
806	   message processing the FIB changes slowly - only after =

topological
807	   changes or routing protocol updates.  Support for reflexive names
808	   changes this, as FIB entries are created and destroyed rapidly as
809	   Interest messages containing reflexive name TLVs are processed =

and
810	   the corresponding Data messages come back.

812	   While it may be feasible, especially in low-end forwarders =

handling a
813	   low packet forwarding rate to ignore this problem, for high-speed
814	   forwarders there are a number of hazards, including:

816	   1.  If the entire FIB needs to be locked in order to insert or =

remove
817	       entries, this could cause inflated forwarding delays or in
818	       extreme cases, forwarding performance collapse.

820	   2.  A number of high-speed forwarder implementations employ a =

sharded
821	       PIT scheme to better parallelize forwarding across processing
822	       cores.  The FIB, however, is still a shared data structure =

which
823	       is either read without read locks across cores, or explicitly
824	       copied such that there is a separate copy of the FIB for each =

PIT
825	       shard.  Clearly, a high update rate without read locks and/or
826	       updating many copies of the FIB are unattractive =

implementation
827	       options.  (Note: with this reflexive name scheme it is not
828	       feasible to force reflexive interests to be hashed or be
829	       otherwise directed to the PIT shard holding the original =

Interest
830	       state).

832	   There are any number of alternative FIB implementations that can =

work
833	   well however.  The most straightforward is to simply implement a
834	   "special" FIB for just reflexive name lookups.  This is feasible
835	   because reflexive names deterministically contain the =

distinguished
836	   high-order name component type of T_REFLEXIVE_NAME, whose content =

is
837	   a 64-bit value that can be easily hashed to a FIB entry directly,
838	   avoiding the more expensive LNPM lookup.  Inserts and deletes =

then
839	   devolve to the well-understood problem of hash table maintenance.

841	8.1.2.  Interactions with Interest Lifetime

843	   If and when a producer decides to fetch data from the consumer =

using
844	   one or more reflexive Interest-Data exchanges, the total latency =

for
845	   the original Interest-Data exchange is inflated, potentially by
846	   multiple RTTs.  It is difficult for a consumer to predict the
847	   inflation factor when issuing the original Interest, and hence =

there
848	   can be a substantial hazard of that Interest lifetime expiring =

before
849	   completion of the full multi-way exchange.  This can result in
850	   persistent failures, which is obviously highly undesirable.

852	   There is a fairly straightforward technique that can be employed =

by
853	   forwarders to avoid these "false" Interest lifetime expirations.  =

In
854	   the absence of a superior alternative technique, it is =

RECOMMENDED
855	   that all forwarders implement the following algorithm.

857	   When processing an Interest containing the reflexive name TLV and
858	   creating the necessary FIB entry (see Section 8.1.1 above), the
859	   forwarder also creates a _back pointer_ from that FIB entry to =

the
860	   PIT entry for the Interest message that created it.  This PIT =

entry
861	   contains the current value of the remaining Interest lifetime or
862	   alternatively a value from which the remaining Interest lifetime =

can
863	   be easily computed.  Call this value _IL_(t)_.

865	   If and when a reflexive Interest arrives from upstream matching =

the
866	   reflexive FIB entry, the forwarder examines the Interest lifetime =

of
867	   the arriving reflexive Interest.  Call this value _IL_(r)_. The
868	   forwarder computes MAX(_IL_(t), (IL_(r) * 1.5)_), and replaces
869	   _IL_(t)_ with this value.  This in effect ensures that the =

remaining
870	   Interest lifetime of the original Interest accounts for the
871	   additional 1.5 RTTs that may occur as a result of the reflexive
872	   Interest-Data exchange.

874	   If the above algorithm is implemented naively as described above, =

it
875	   may run afoul of a sharded PIT forwarder implementation, since =

the
876	   PIT entry for the reflexive Interest and the PIT entry for the
877	   original Interest may be in different shards.  Therefore, if the
878	   update is done cross-shard on each reflexive Interest arrival,
879	   performance may suffer, perhaps dramatically.  Instead, the =

following
880	   approach to updating the Interest lifetime after computing the =

new
881	   value is RECOMMMENDED for sharded-PIT forwarders.

883	   When creating the reflexive FIB entry as above in Section 8.1.1, =

copy
884	   the remaining Interest lifetime from the PIT entry.  Do the PIT
885	   update if and only if this value is about to expire, thus paying =

the
886	   cross-shard update cost only if the original Interest is about to
887	   expire.  A further optimization at the cost of modest extra
888	   complexity is to instead _queue_ the update to the core holding =

the
889	   shard of the original PIT entry rather than doing the update
890	   directly.  If the PIT entry expires or is satisfied, instead of
891	   removing it the associated core checks the update queue and does =

the
892	   necessary update.

894	   While the above approach of inflating the interest lifetime of =

the
895	   original Interest to accommodate the additional RTTs of reflexive
896	   Interest-Data exchanges, this does introduce a new vulnerability =

that
897	   must be dealt with.  A Producer, either through a bug or =

malicious
898	   intent, could keep an originating Interest-Data exchange alive by
899	   continuing to send reflexive Interests back to the consumer, =

while
900	   the consumer had no way to terminate the enclosing interaction =

(there
901	   is no "cancel Interest" function in either NDN nor CCNx).  To
902	   eliminate this hazard, if the consumer rejects a reflexive =

interest
903	   with a T_RETURN_PROHIBITED error, the forwarder(s), in addition =

to
904	   satisfying the coresponding PIT entry, MUST also delete the
905	   associated reflexive FIB entry, thereby preventing any further
906	   reflexive Interests from reaching the consumer.  This allows the
907	   enclosing Interest-Datsa exchange to either time out or be =

correctly
908	   ended with a Data message or Interest Return from the Producer.

910	8.1.3.  Interactions with Interest aggregation

912	   As with numerous other situations where multiple Interests for =

the
913	   same named object arrive containing different parameters (e.g.
914	   Interest Lifetime, QoS, payload hash) the same phenomenon occurs =

for
915	   the reflexive Name TLV.  If such Interests collide, the forwarder
916	   MUST NOT aggregate these Interest messages and instead MUST =

create a
917	   separate PIT entry for each.

919	8.2.  Consumer Implementation Considerations

921	8.2.1.  Data objects returned by the consumer to reflexive name
922	        Interests arriving from a producer

924	   The Data objects returned to the producer in response to a =

reflexive
925	   Interest are normal CCNx/NDN data objects.  It is therefore worth
926	   noting that the object is bound to the reflexive Interest full =

name
927	   via the hash and hence the scope of the object is under most
928	   circumstances meaningful only for the duration of the enclosing
929	   Interest-Data interaction.  This property is ideal for naming and
930	   securing data that is "part of" the enclosing interaction - =

things
931	   like method arguments, authenticators, and key exchange =

parameters,
932	   but not for the creation and naming of objects intended to =

survive
933	   outside the current interaction's scope (c.f.  Section 7.3, which
934	   describes how to provide globally-named objects using =

encapsulation).
935	   In general, the consumer should use the following guidelines in
936	   creating Data messages in response to reflexive Interest messages
937	   from the producer.

939	   (a)  Set the recommended cache time (T_CACHETIME) either to zero, =

or
940	        a value no greater than the Interest lifetime (T_INTLIFE) of =

the
941	        original Interest messsage.

943	   (b)  Set the payload type (T_PAYLDTYPE) according to the type of
944	        object being returned (e.g. object, link, manifest)

946	   (c)  Set the expiry time (T_EXPIRY) to a value greater than =

_now_,
947	        and less than or equal to the _now_ + Interest lifetime
948	        (T_INTLIFE) of the original Interest messsage.

950	8.2.2.  Terminating unwanted reflexive Interest exchanges

952	   A consumer may wish to stop receiving reflxive Interests due to
953	   possible erors or malicious behavior on the part of the producer.
954	   Therefore, if the consumer receives an unwanted reflexive =

Interest,
955	   it SHOULD reject that interest with a T_RETURN_PROHIBITED error.
956	   This will provoke the forwarders to prevent further reflexive
957	   Interests from reaching the consumer, as described above in
958	   Section 8.1.2, Paragraph 7.

960	8.2.3.  Interactions with caching

962	   The reflexive named objects provide "local", temporary names that =

are
963	   only defined for one specific interaction between a consumer and =

a
964	   producer.  Corresponding Data objects MUST NOT be shared between
965	   multiple consumers (violating this would require specail =

gyrations by
966	   the producer since the reflexive Name utilizes per-consumer/per-
967	   interaction random values).  A producer MUST NOT issue an =

Interest
968	   message for any reflexive name after it has sent the final Data
969	   message answering the original Interest.

971	   Forwarders SHOULD still cache reflexive Data objects for
972	   retransmissions within a transactions, but they MUST remove them =

from
973	   the content store when they forward the final Data message =

answering
974	   the original Interest.

976	8.3.  Producer Implementation Considerations

978	   Producers receiving an Interest with a Reflexive Name Component, =

MAY
979	   decide to issue Interests for the corresponding Data objects.  =

All
980	   Reflexive Interest message that a producer sends MUST be sent =

over
981	   the face that the original Interest was received on.

983	9.  Operational Considerations

985	   This extension represents a substantial enhancement to the =

CCNx/NDN
986	   protocol architecture and hence has important forward and =

backward
987	   compatibility effects.  The most important of these is that =

correct
988	   operation of the scheme requires an unbroken chain of forwarders
989	   between the consumer and the desired producer that support the
990	   Reflexive Name TLV and the corresponding forwarder capabilities
991	   specified in Section 5.  When this invariant is not satisfied, =

some
992	   means is necessary to detect and hopefully recover from the =

error.
993	   We have identified three possible approaches to handling the lack =

of
994	   universal deployment of forwarders supporting the reflexive
995	   forwarding scheme.

997	   The first approach simply lets the producer detect the error by
998	   getting a "no route to destination" error when trying to send an
999	   Interest to a reflexive name.  This will catch the error, but =

only
1000	   after forwarding resources are tied up and the producer has done =

some
1001	   work on the original Interest message.  Further, the producer =

would
1002	   need a bit of smarts to determine that this is a permanent error =

and
1003	   not a transient to be retried.  In order for the consumer to =

attempt
1004	   recovery, there might be a need for some explicit error returned =

for
1005	   the original interest to tell the consumer what the likely =

problem
1006	   is.  This approach does not enable an obvious recovery path for =

the
1007	   consumer either, since while we might envision a way to steer a
1008	   subsequent Interest onto a working path as proposed in
1009	   [I-D.oran-icnrg-pathsteering], there is no capability to force
1010	   Interest routing away from an otherwise working path not =

supporting
1011	   the reflexive name TLV.

1013	   A second approach is to bump the CCNx/NDN protocol version to
1014	   explicitly indicate the lack of comparability.  Such Interests =

would
1015	   be rejected by forwarders not supporting this protocol =

extension.  A
1016	   consumer wishing to use the reflexive name TLV would use the =

higher
1017	   protocol version on those Interest messages (but could of course
1018	   continue to use the current version number on other Interest
1019	   messages).  This is a big hammer, but may be called for in this
1020	   situation because:

1022	   (a)  it detects the problem immediately and deterministically, =

and

1024	   (b)  one could assume an ICN routing protocol that would only =

forward
1025	        to a next hop that supports the updated protocol version =

number.
1026	        The supported forwarder protocol versions would have been
1027	        communicated in the routing protocol ahead of time.

1029	   A third option is to, as a precondition utilizing the protocol =

in a
1030	   deployment, create and deploy a neighbor capability exchange =

protocol
1031	   which will tell a downstream forwarder if the upstream can =

handle the
1032	   new TLV.  This might avoid the large hammer of updating the =

protocol
1033	   version, but of course this puts a pretty strong dependency on
1034	   somebody actually designing and publishing such a protocol!  On =

the
1035	   other hand, a neighbor capability exchange protocol for CCNx/NDN
1036	   would have a number of other substantial benefits, which makes =

it
1037	   worth seriously considering anyway.

1039	10.  Mapping to CCNx and NDN packet encodings

1041	10.1.  Packet encoding for CCNx

1043	   For CCNx[RFC8569] there is one new Name Component TLV type =

defined in
1044	   this specification.

1046	     =

+------------------+----------------+--------------------------+
1047	     |      Abbrev      |      Name      |       Description        =

|
1048	     =

+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
1049	     | T_REFLEXIVE_NAME | Reflexive Name | Name component to use as =

|
1050	     |                  | Component      | name prefix in Reflexive =

|
1051	     |                  |                | Interest Message         =

|
1052	     =

+------------------+----------------+--------------------------+

1054	                       Table 1: Reflexive Name TLV

1056	10.2.  Packet encoding for NDN

1058	   TBD based on [NDNTLV].  Suggestions from the NDN team greatly
1059	   appreciated.

1061	11.  IANA Considerations

1063	   Please add the T_REFLEXIVE_NAME component TLV to the CCNx Name =

types
1064	   TLV types registry of [RFC8609], with Length 9 bytes and type of =

64
1065	   bit random integer.

1067	                        1                   2                   3
1068	    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1069	   =

+---------------+---------------+---------------+---------------+
1070	   |         T_REFLEXIVE_NAME      |               8               =

|
1071	   =

+---------------+---------------+---------------+---------------+
1072	   |                                                               =

|
1073	   |       64bit Integer randomly assigned by consumer             =

|
1074	   =

+-------------------------------+-------------------------------+

1076	                  Figure 5: Reflexive Name component type

1078	12.  Security Considerations

1080	   One of the major motivations for the reflexive forwarding =

extension
1081	   specified in this document is in fact to enable better security =

and
1082	   privacy characteristics for ICN networks.  The main =

considerations
1083	   are presented in Section 1, but we briefly recapitulate them =

here:

1085	   *  Current approaches to authentication and data transfer often =

use
1086	      payloads in Interest messages, which are clumsy to secure
1087	      (Interest messages must be signed) and as a consequence make =

it
1088	      very difficult to ensure consumer privacy.  Reflexive =

forwarding
1089	      moves all sensitive data to the Data messages sent in =

response to
1090	      reflexive Interests, which are secured in the same manner as =

all
1091	      other Data messages in the CCNx and NDN protocol designs.

1093	   *  In many scenarios, consumers are forced to also act as =

producers
1094	      so that data may be fetched by either a particular, or =

arbitrary
1095	      other party.  The means the consumer must arrange to have a
1096	      routable name prefix and that prefix be disseminated by the
1097	      routing protocol or other means.  This represents both a =

privacy
1098	      hazard (by revealing possible important information about the
1099	      consumer) and a security concern as it opens up the consumer =

to
1100	      the full panoply of flooding and crafted Interest denial of
1101	      service attacks.

1103	   *  In order to achieve multi-way handshakes, in current designs =

a
1104	      consumer wishing a producer to communicate back must inform =

the
1105	      producer of what (globally routable) name to use.  This gives =

the
1106	      consumer a convenient means to mount a variety of reflection
1107	      attacks by enlisting the producer to send Interests to =

desired
1108	      victims.

1110	   As a major protocol extension however, this design brings its =

own
1111	   potential security issues, which are discussed in the following
1112	   subsections.

1114	12.1.  Collisions of reflexive Interest names

1116	   Reflexive Interest names are constructed using 64-bit random =

numbers.
1117	   This is intended to ensure an off-path attacker cannot easily
1118	   manufacture a matching reflexive Interest and either masquerade =

as
1119	   the producer, or mount a denial of service attack on the =

consumer.
1120	   It also limits tracking through the linkability of Interests
1121	   containing a re-used random value.

1123	   Therefore consumers MUST utilize a robust means of generating =

these
1124	   random values, and it is RECOMMENDED that a pseudo-random number
1125	   generator (PRNG) approved for use with cryptographic protocols =

be
1126	   employed.

1128	12.2.  Additional resource pressure on PIT and FIB

1130	   Normal Interest message processing in CCNx and NDN needs to =

consider
1131	   effect of various resource depletion attacks on the PIT, =

particularly
1132	   in the form of Interest flooding attacks (see [Gasti2012] for a =

good
1133	   overview of DoS and DDoS mitigation on ICN networks).  Interest
1134	   messages utilizing this reflexive forwarding extension can place
1135	   additional resource pressure on the PIT, and additionally cause
1136	   otherwise stable FIB resources to be subject to highly dynamic =

usage.

1138	   While this does not represent a new DoS/DDoS attack vector, the
1139	   ability of a malicious consumer to utilize this extension in an
1140	   attack does represent an increased risk of resource depletion,
1141	   especially if such Interests are given unfair access to PIT and =

FIB
1142	   resources.  Implementers SHOULD therefore protect PIT and FIB
1143	   resources by weighing requests for reflexive forwarding =

resources
1144	   appropriately relative to other Interests.

1146	12.3.  Privacy Considerations

1148	   ICN architectures like CCNx and NDN provide a rich tapestry of
1149	   interesting privacy issues, which have been extensively explored =

in
1150	   the research literature.  The fundamental tradeoffs for privacy
1151	   concern the risk of exposing the names of information objects to =

the
1152	   forwarding elements of the network, which is a necessary =

property of
1153	   any name-based routing and forwarding design.  Numerous =

approaches
1154	   have been explored with varying degrees of success, such as =

onion
1155	   routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), and =

name
1156	   obfuscation ([Arianfar2011]) among others.

1158	   Reflexive forwarding does not change the overall landscape of =

privacy
1159	   tradeoffs, nor seem to introduce additional hazards.  In fact, =

the
1160	   privacy exposures are confined to the inverse path of forwarders =

from
1161	   the producer to the consumer, through which the original =

Interest
1162	   forwarding may have already exposed names on path.  Similar name
1163	   privacy techniques to those cited above may be equally applied =

to the
1164	   names in reflexive Interests.

1166	   While the individual reflexive Interest-Data exchanges have =

similar
1167	   properties to those in any NDN or CCNx exchange, the target =

usages by
1168	   applications may have interaction patterns that are subject to
1169	   relatively straightforward fingerprinting by adversaries.  For
1170	   example, a particular RMI invocation may fingerprint simply =

through
1171	   the count of arguments fetched by the producer and their sizes.  =

The
1172	   attacker must however be on path, which somewhat ameliorates the
1173	   exposure hazards.

1175	13.  Normative References

1177	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1178	              Requirement Levels", BCP 14, RFC 2119,
1179	              DOI 10.17487/RFC2119, March 1997,
1180	              .

1182	   [RFC8569]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
1183	              Networking (CCNx) Semantics", RFC 8569,
1184	              DOI 10.17487/RFC8569, July 2019,
1185	              .

1187	   [RFC8609]  Mosko, M., Solis, I., and C. Wood, "Content-Centric
1188	              Networking (CCNx) Messages in TLV Format", RFC 8609,
1189	              DOI 10.17487/RFC8609, July 2019,
1190	              .

1192	14.  Informative References

1194	   [Arianfar2011]
1195	              Arianfar, S., Koponen, T., Raghavan, B., and S. =

Shenker,
1196	              "On preserving privacy in content-oriented networks, =

in
1197	              ICN '11: Proceedings of the ACM SIGCOMM workshop on
1198	              Information-centric networking",
1199	              DOI https://doi.org/10.1145/2018584.2018589, August =

2011,
1200	              .

1202	   [Auge2018] Aug=C3=A9, J., Carofiglio, G., Grassi, G., Muscariello=
, =

L.,
1203	              Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less
1204	              Producer Mobility in Content-Centric Networks, in =

IEEE
1205	              Transactions on Network, Volume 15, Issue 2",
1206	              DOI 10.1109/TNSM.2018.2796720, June 2018,
1207	              .

1209	   [Baccelli2014]
1210	              Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., and =

M.
1211	              W=C3=A4hlisch, "Information centric networking in the =

IoT:
1212	              experiments with NDN in the wild, in ACM-ICN '14:
1213	              Proceedings of the 1st ACM Conference on Information-
1214	              Centric Networking", DOI 10.1145/2660129.2660144,
1215	              September 2014,
1216	              .

1218	   [Carzaniga2011]
1219	              Carzaniga, A., Papalini, M., and A.L. Wolf, =

"Content-Based
1220	              Publish/Subscribe Networking and Information-Centric
1221	              Networking", DOI 10.1145/2018584.2018599, September =

2011,
1222	              =

.

1225	   [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDSS: A Named Data =

Storage
1226	              System, in International Conference on Cloud and =

Autonomic
1227	              Computing", DOI 10.1109/ICCAC.2015.12, September =

2014,
1228	              .

1230	   [DiBenedettoGTU12]
1231	              DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun,
1232	              "ANDaNA: Anonymous Named Data Networking Application, =

in
1233	              NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2, =

2102,
1234	              =

.

1237	   [Gasti2012]
1238	              Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, =

"DoS
1239	              and DDoS in Named Data Networking, in 22nd =

International
1240	              Conference on Computer Communication and Networks
1241	              (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August =

2013,
1242	              .

1244	   [Ghali2017]
1245	              Tsudik, G., Ghali, C., and C. Wood, "When encryption =

is
1246	              not enough: privacy attacks in content-centric =

networking,
1247	              in ICN '17: Proceedings of the 4th ACM Conference on
1248	              Information-Centric Networking",
1249	              DOI https://doi.org/10.1145/3125719.3125723, =

September
1250	              2017,
1251	              .

1253	   [Gundogan2018]
1254	              G=C3=BCndo=C4=9Fan, C., Kietzmann, P., Schmidt, T., an=
d M. =

W=C3=A4hlisch,
1255	              "HoPP: publish-subscribe for the constrained IoT, in =

ICN
1256	              '18: Proceedings of the 5th ACM Conference on =

Information-
1257	              Centric Networking", DOI 10.1145/3267955.3269020,
1258	              September 2018,
1259	              .

1261	   [I-D.irtf-icnrg-flic]
1262	              Tschudin, C., Wood, C., Mosko, M., and D. Oran, =

"File-Like
1263	              ICN Collections (FLIC)", Work in Progress, =

Internet-Draft,
1264	              draft-irtf-icnrg-flic-02, 4 November 2019,
1265	              =

.

1267	   [I-D.irtf-icnrg-terminology]
1268	              Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., =

Oran,
1269	              D., and C. Tschudin, "Information-Centric Networking
1270	              (ICN): CCNx and NDN Terminology", Work in Progress,
1271	              Internet-Draft, draft-irtf-icnrg-terminology-08, 17
1272	              January 2020, =

.

1275	   [I-D.oran-icnrg-pathsteering]
1276	              Moiseenko, I. and D. Oran, "Path Steering in CCNx and
1277	              NDN", Work in Progress, Internet-Draft, =

draft-oran-icnrg-
1278	              pathsteering-00, 21 October 2019,
1279	              .

1282	   [Krol2018] Krol, M., Habak, K., Oran, D., Kutscher, D., and I.
1283	              Psaras, "RICE: Remote Method Invocation in ICN, in
1284	              Proceedings of the 5th ACM Conference on Information-
1285	              Centric Networking - ICN '18",
1286	              DOI 10.1145/3267955.3267956, September 2018,
1287	              =

.

1290	   [Lindgren2016]
1291	              Lindgren, A., Ben Abdessiem, F., Ahlgren, B., =

Schlel=C3=A9n,
1292	              O., and A.M. Malik, "Design choices for the IoT in
1293	              Information-Centric Networks, in 13th IEEE Annual =

Consumer
1294	              Communications and Networking Conference (CCNC)",
1295	              DOI 10.1109/CCNC.2016.7444905, January 2016,
1296	              =

.

1298	   [Moiseenko2014]
1299	              Moiseenko, I., Stapp, M., and D. Oran, "Communication
1300	              patterns for web interaction in named data =

networking",
1301	              DOI 10.1145/2660129.2660152, September 2014,
1302	              .

1304	   [Mosko2017]
1305	              Mosko, M., "CCNx 1.0 Bidirectional Streams",
1306	              arXiv 1707.04738, July 2017,
1307	              .

1309	   [NDN]      "Named Data Networking", 2020,
1310	              .

1312	   [NDNTLV]   "NDN Packet Format Specification", 2016,
1313	              .

1315	   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., =

Johnston,
1316	              A., Peterson, J., Sparks, R., Handley, M., and E.
1317	              Schooler, "SIP: Session Initiation Protocol", RFC =

3261,
1318	              DOI 10.17487/RFC3261, June 2002,
1319	              .

1321	   [RFC6337]  Okumura, S., Sawada, T., and P. Kyzivat, "Session
1322	              Initiation Protocol (SIP) Usage of the Offer/Answer
1323	              Model", RFC 6337, DOI 10.17487/RFC6337, August 2011,
1324	              .

1326	   [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed., "Network File =

System
1327	              (NFS) Version 4 Protocol", RFC 7530, DOI =

10.17487/RFC7530,
1328	              March 2015, =

.

1330	   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) =

Protocol
1331	              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August =

2018,
1332	              .

1334	   [Zhang2018]
1335	              Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, =

"KITE:
1336	              Producer Mobility Support in Named Data Networking, =

in
1337	              Proceedings of the 5th ACM Conference on Information-
1338	              Centric Networking - ICN '18",
1339	              DOI 10.1145/3267955.3267959, September 2018,
1340	              =

.

1343	Authors' Addresses

1345	   Dave Oran
1346	   Network Systems Research and Design
1347	   4 Shady Hill Square
1348	   Cambridge, MA 02138
1349	   United States of America

1351	   Email: daveoran@orandom.net

1353	   Dirk Kutscher
1354	   University of Applied Sciences Emden/Leer
1355	   Constantiapl. 4
1356	   26723 Emden
1357	   Germany

1359	   Email: ietf@dkutscher.net
1360	   URI:   https://dirk-kutscher.info










DaveO

--=_MailMate_6C591296-A53D-47D1-9720-24A9F0D96BCE_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable








                              

                              One of these seem to be xml2rfc rendering problem; others=
 may be idnit glitches that only show up on V3 docs:
                              


                                

                              • The too long line 1551 is in fact not too long - the =
length computation seems to be screwed up by the non-ascii characters (pr=
obably idnit problem?)
                                • 

                              • somehow xml2rfc elided part of an author name into th=
e updates head field and author address into the Intended Status header f=
ield. This only happens in the .txt output, not the HTML or PDF. xml2rfc =
bug?
                                • 

                              • idnits says this has a downref, but I believe that an=
 I.D. marked experimental saying it updates an experimental RFC isn=E2=80=
=99t a downref, right?
                                • 

                              


                              I include the idnits output below and the xml file as an =
attachment (note that this is still a bit private - we haven=E2=80=99t su=
bmitted yes)
                              


                              Let me know of any followup I should do - would like to g=
et this submitted in the next couple of days.
                              


                              Thanks! DaveO.
                              


                              =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=
=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
                              


                              idnits 2.16.03
                              


                              tmp/draft-oran-icnrg-reflexive-forwarding.txt:
                              
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1491): Found non-ascii char=
acter (=EF=BF=BD) in position 18.
                              
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1500): Found non-ascii char=
acter (=EF=BF=BD) in position 16.
                              
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Line is too long: th=
e offending characters are 'ch,'
                              
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1551): Found non-ascii char=
acter (=EF=BF=BD) in position 16.
                              
tmp/draft-oran-icnrg-reflexive-forwarding.txt(1597): Found non-ascii char=
acter (=EF=BF=BD) in position 67.
                              


                              Checking boilerplate required by RFC 5378 and the IETF Tr=
ust (see
                              
  https://trustee.ietf.org/license-info):
                              


                              


                               No issues found =
here.

                              


                              Checking nits according to https://www.ietf.o=
rg/id-info/1id-guidelines.txt:
                              


                              


                              =3D=3D There are 4 instances of lines with non-ascii char=
acters in the document.
                              


                              Checking nits according to https://www.ietf.org/id-info=
/checklist :
                              


                              


                              ** There is 1 instance of too long lines in the document,=
 the longest one
                              
     being 3 characters in excess of 72.
                              


                              Miscellaneous warnings:
                              


                              


                              =3D=3D Unrecognized Status in 'Intended status: Experimen=
tal  University of
                              
     Applied Sciences Emden/Leer', assuming Proposed Standard
                              


                               (Expected one of=
 'Standards Track', 'Full Standard', 'Draft Standard',
 'Proposed Standard', 'Best Current Practice', 'Informational',
 'Experimental', 'Informational', 'Historic'.)

                              


                              =3D=3D Couldn't figure out when the document was first su=
bmitted -- there may
                              
     comments or warnings related to the use of a disclaimer for pre-RFC5=
378
                              
     work that could not be issued because of this.  Please check the Leg=
al
                              
     Provisions document at https://trustee.ietf.org/license-info to=
 determine
                              
     if you need the pre-RFC5378 disclaimer.
                              


                              Checking references for intended status: Proposed Standar=
d
                              


                              


                               (See RFCs 3967 a=
nd 4897 for information about using normative references
 to lower-maturity documents in RFCs)

                              


                              ** Downref: Normative reference to an Experimental RFC: R=
FC 8569
                              


                              ** Downref: Normative reference to an Experimental RFC: R=
FC 8609
                              


                               Summary: 3 error=
s (**), 0 flaws (~~), 4 warnings (=3D=3D), 0 comments (--).

                              


                              


                              2    ICNRG                                               =
             D. Oran
                              
3    Internet-Draft                       Network Systems Research and De=
sign
                              
4    Updates: 8569, 8609 (if approved)                            D. Kuts=
cher
                              
5    Intended status: Experimental  University of Applied Sciences Emden/=
Leer
                              
6    Expires: 2 October 2020                                    31 March =
2020
                              


                              8                Reflexive Forwarding for CCNx and NDN Pr=
otocols
                              
9                    draft-oran-icnrg-reflexive-forwarding-00
                              


                              11    Abstract
                              


                              13       Current Information-Centric Networking protocols=
 such as CCNx and NDN
                              
14       have a wide range of useful applications in content retrieval an=
d
                              
15       other scenarios that depend only on a robust two-way exchange in=
 the
                              
16       form of a request and response (represented by an Interest-D=
ata
                              
17       exchange                               in the case of the two protocols noted above).  A =
number of
                              
18       important applications however, require placing large amounts of=
 data
                              
19       in the Interest message, and/or more than one two-way handshake.=

                              
20       While these can be accomplished using independent Interest-Data<=
br>
21       exchanges by reversing the roles of consumer and producer, such<=
br>
22       approaches can be both clumsy for applications and problematic f=
rom a
                              
23       state management, congestion control, or security standpoint.  T=
his
                              
24       specification proposes a Reflexive Forwarding extension=
 to the CCNx
                              
25       and NDN protocol architectures that eliminates the problems inhe=
rent
                              
26       in using independent Interest-Data exchanges for such applicatio=
ns.
                              
27       It updates RFC8569 and RFC8609.
                              


                              29    Status of This Memo
                              


                              31       This Internet-Draft is submitted in full conform=
ance with the
                              
32       provisions of BCP 78 and BCP 79.
                              


                              34       Internet-Drafts are working documents of the Int=
ernet Engineering
                              
35       Task Force (IETF).  Note that other groups may also distribute
36       working documents as Internet-Drafts.  The list of current Inter=
net-
                              
37       Drafts is at https://datatracker.ietf.org/drafts/current=
/.
                              


                              39       Internet-Drafts are draft documents valid for a =
maximum of six months
                              
40       and may be updated, replaced, or obsoleted by other documents at=
 any
                              
41       time.  It is inappropriate to use Internet-Drafts as reference
42       material or to cite them other than as "work in progress."
                              


                              44       This Internet-Draft will expire on 2 October 202=
0.
                              


                              46    Copyright Notice
                              


                              48       Copyright (c) 2020 IETF Trust and the persons id=
entified as the
                              
49       document authors.  All rights reserved.
                              


                              51       This document is subject to BCP 78 and the IETF =
Trust's Legal
                              
52       Provisions Relating to IETF Documents (https://trustee.ietf.org/
                              
53       license-info) in effect on the date of publication of this docum=
ent.
                              
54       Please review these documents carefully, as they describe your r=
ights
                              
55       and restrictions with respect to this document.
                              


                              57    Table of Contents
                              


                              59       1.  Introduction  . . . . . . . . . . . . . . . =
=2E . . . . . . . .   3
                              
60         1.1.  Problems with pushing data  . . . . . . . . . . . . . . =
=2E   4
                              
61         1.2.  Problems with utilizing independent exchanges . . . . . =
=2E   5
                              
62       2.  Requirements Language . . . . . . . . . . . . . . . . . . . =
=2E   6
                              
63       3.  Overview of the Reflexive Forwarding design . . . . . . . . =
=2E   6
                              
64       4.  Naming of Reflexive Interests . . . . . . . . . . . . . . . =
=2E  10
                              
65       5.  Forwarder operation for Reflexive Interests . . . . . . . . =
=2E  11
                              
66       6.  State coupling between producer and consumer  . . . . . . . =
=2E  12
                              
67       7.  Use cases for Reflexive Interests . . . . . . . . . . . . . =
=2E  12
                              
68         7.1.  Achieving Remote Method Invocation with Reflexive
                              
69               Interests . . . . . . . . . . . . . . . . . . . . . . . =
=2E  12
                              
70         7.2.  RESTful Web Interactions  . . . . . . . . . . . . . . . =
=2E  15
                              
71         7.3.  Achieving simple data pull from consumers with reflexive=

                              
72               Interests . . . . . . . . . . . . . . . . . . . . . . . =
=2E  15
                              
73       8.  Implementation Considerations . . . . . . . . . . . . . . . =
=2E  19
                              
74         8.1.  Forwarder implementation considerations . . . . . . . . =
=2E  19
                              
75           8.1.1.  Forwarding Information Base (FIB) . . . . . . . . . =
=2E  19
                              
76           8.1.2.  Interactions with Interest Lifetime . . . . . . . . =
=2E  20
                              
77           8.1.3.  Interactions with Interest aggregation  . . . . . . =
=2E  21
                              
78         8.2.  Consumer Implementation Considerations  . . . . . . . . =
=2E  21
                              
79           8.2.1.  Data objects returned by the consumer to reflexive n=
ame
                              
80                   Interests arriving from a producer  . . . . . . . . =
=2E  21
                              
81           8.2.2.  Terminating unwanted reflexive Interest exchanges . =
=2E  22
                              
82           8.2.3.  Interactions with caching . . . . . . . . . . . . . =
=2E  22
                              
83         8.3.  Producer Implementation Considerations  . . . . . . . . =
=2E  22
                              
84       9.  Operational Considerations  . . . . . . . . . . . . . . . . =
=2E  23
                              
85       10. Mapping to CCNx and NDN packet encodings  . . . . . . . . . =
=2E  24
                              
86         10.1.  Packet encoding for CCNx . . . . . . . . . . . . . . . =
=2E  24
                              
87         10.2.  Packet encoding for NDN  . . . . . . . . . . . . . . . =
=2E  24
                              
88       11. IANA Considerations . . . . . . . . . . . . . . . . . . . . =
=2E  24
                              
89       12. Security Considerations . . . . . . . . . . . . . . . . . . =
=2E  25
                              
90         12.1.  Collisions of reflexive Interest names . . . . . . . . =
=2E  25
                              
91         12.2.  Additional resource pressure on PIT and FIB  . . . . . =
=2E  26
                              
92         12.3.  Privacy Considerations . . . . . . . . . . . . . . . . =
=2E  26
                              
93       13. Normative References  . . . . . . . . . . . . . . . . . . . =
=2E  27
                              
94       14. Informative References  . . . . . . . . . . . . . . . . . . =
=2E  27
                              
95       Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . =
=2E  30
                              


                              97    1.  Introduction
                              


                              99       Current ICN protocols such as CCNx [RFC8569] and=
 [NDN] have a wide
                              
100       range of useful applications in content retrieval and other sce=
narios
                              
101       that depend only on a robust two-way exchange in the form of a<=
br>
102       request and response.  These ICN architectures use the terms
103       "consumer" and "producer" for the respective roles of the reque=
ster
                              
104       and the responder, and the protocols directly capture the mecha=
nics
                              
105       of the two-way exchange through the "Interest message" carrying=
 the
                              
106       request, and the "Data message" carrying the response.  Through=
 these
                              
107       constructs, the protocols are heavily biased toward a pure =
pull-
                              
108       based                               interaction model where requests are small (carrying=
 little or
                              
109       no user-supplied data other than the name of the requested data=

                              
110       object), and responses are relatively large - up to an architec=
ture-
                              
111       defined maximum transmission unit (MTU) on the order of kilobyt=
es or
                              
112       tens of kilobytes.
                              


                              114       A number of important applications however requ=
ire interaction models
                              
115       more complex than individual request/response interactions in t=
he
                              
116       same direction (i.e. between the same consumer and one or more<=
br>
117       producers).  Among these we identify three important classes wh=
ich
                              
118       are the target of the proposed enhancements defined in this
                              =

119       specification.  These are described in the following paragraphs=
=2E
                              


                              121       Remote Method Invocation (RMI, aka RPC):  When invoking a remote
                              
122          method, it is common for the method to require arguments sup=
plied
                              
123          by the caller.  In conventional TCP/IP style protocols like =
CORBA
                              
124          or HTTP "Post", these are pushed to the server as part of th=
e
                              
125          message or messages that comprise the request.  In ICN-style=

                              
126          protocols there is an unattractive choice between inflating =
the
                              
127          request initiation with pushed arguments, or arranging to ha=
ve one
                              
128          or more independent request/responses in the opposite direct=
ion
                              
129          for the server to fetch the arguments.  Both of these approa=
ches
                              
130          have substantial disadvantages.  Recently, a viable alternat=
ive
                              
131          emerged through the work on RICE [Krol2018] which pioneered =
the
                              
132          main design elements proposed in this specification.
                              


                              134       Phone-Home scenario:  Applications in =
sensing, Internet-of-things
                              
135          (IoT) and other types where data is produced unpredictably a=
nd
                              
136          needs to be pushed somewhere create a conundrum for=
 the pure
                              
137          pull-based architectures considered here.  If instead one es=
chews
                              
138          relaxing the size asymmetry between requests and responses, =
some
                              
139          additional protocol machinery is needed.  Earlier efforts in=
 the
                              
140          ICN community have recognized this issue and designed method=
s to
                              
141          provoke a cooperating element to issue a request to return t=
he
                              
142          data the originator desires to push, essentially "phoning ho=
me" to
                              
143          get the responder to fetch the data.  One that has been expl=
ored
                              
144          to some extent is the Interest-Interest-Data exchan=
ge
                              
145          [Carzaniga2011], where an Interest is sent containing the de=
sired
                              
146          request as encapsulated data.  CCNx-1.0 Bidirectional Stream=
s
                              
147          [Mosko2017] are also based on a scheme where an Interest is =
used
                              
148          to signal a name prefix that a consumer has registered for
149          receiving Interests from a peer in a bidirectional streaming=

                              
150          session.
                              


                              152       Peer state synchronization:  A large c=
lass of applications,
                              
153          typified by those built on top of on reliable order-preservi=
ng
                              
154          transport protocols, require initial state synchronization b=
etween
                              
155          the peers.  This is accomplished with a three-way (or longer=
)
                              
156          handshake, since employing a two-way handshake as provided i=
n the
                              
157          existing NDN and CCNx protocols exposes a number of well-kno=
w
                              
158          hazards, such as half-open connections. When attemp=
ted for
                              
159          security-related operations such as key exchange, additional=

                              
160          hazards such as man-in-the-middle attacks become tr=
ivial to
                              
161          mount.  Existing alternatives, similar to those used in the =
two
                              
162          examples above, instead utilize either overlapping Interest-=
Data
                              
163          exchanges in opposite directions (resulting in a four-way
164          handshake) or by adding initialization data to the initial r=
equest
                              
165          and employing an Interest-Interest-Data protocol extension a=
s
                              
166          noted in the Phone-home scenarios above.
                              


                              168       All of the above application interaction models=
 present interesting
                              
169       challenges, as neither relaxing the architecture to support pus=
hing
                              
170       large amounts of data, nor introducing substantial complexities=

                              
171       through multiple independent Interest-Data exchanges is an attr=
active
                              
172       approach.  The following subsections provide further background=
 and
                              
173       justification for why push and/or independent exchanges are
                              =

174       problematical.
                              


                              176    1.1.  Problems with pushing data
                              


                              178       There are two substantial problems with the sim=
ple approach of just
                              
179       allowing arbitrary amounts of data to be included with requests=
=2E
                              
180       These are:
                              


                              182       1.  In ICN protocols, Interest messages are int=
ended to be small, on
                              
183           the order the size of a TCP ACK, as opposed to the size of =
a TCP
                              
184           data segment.  This is because the hop-by-hop congestion co=
ntrol
                              
185           and forwarder state management requires Interest messages t=
o be
                              
186           buffered in expectation of returning data, and possibly
                              =

187           retransmitted hop-by-hop as opposed to end-to-end.  In addi=
tion,
                              
188           the need to create and manage state on a per-Interest basis=
 is
                              
189           substantially complicated if requests in Interest messages =
are
                              
190           larger than a Path MTU (PMTU) and need to be fragmented hop=
-by-
                              
191           hop.
                              


                              193       2.  If the payload data of a request is used fo=
r invoking a
                              
194           computation (as in the RMI case described above) then subst=
antial
                              
195           bandwidth can be wasted if the computation is either refuse=
d or
                              
196           abandoned for any number of reasons, including the requesto=
r
                              
197           failing an authorization check, or the responder not having=

                              
198           sufficient resources to execute the associated computation.=

                              


                              200       These problems also exist in pure datagram tran=
sport protocols such
                              
201       as those used for legacy RMI applications like NFS [RFC7530].  =
More
                              
202       usual are application protocols like HTTP(s) which rely on the =
TCP or
                              
203       QUIC 3-way handshake to establish a session and then have conge=
stion
                              
204       control and segmentation provided as part of the transport prot=
ocol,
                              
205       further allowing sessions to be rejected before large amounts o=
f data
                              
206       are transmitted or significant computational resources expended=
=2E
                              


                              208    1.2.  Problems with utilizing independent exchange=
s
                              


                              210       In order to either complete a three-way handsha=
ke, or fetch data via
                              
211       a pull from the original requestor, the role of consumer and pr=
oducer
                              
212       need to be reversed and an Interest/Data exchange initiated in =
the
                              
213       direction opposite of the initiating exchange.  When done with =
an
                              
214       independent Interest/Data request and response, a number of
                              =

215       complications ensue.  Among them are:
                              


                              217       1.  The originating consumer needs to have a ro=
utable name prefix
                              
218           that can be used for the exchange.  This means the consumer=
 must
                              
219           arrange to have its name prefix propagated in the ICN routi=
ng
                              
220           system with sufficient reach that the producer issuing the<=
br>
221           interest can be assured it is routed appropriately.  While =
some
                              
222           consumers are generally online and act as application serve=
rs,
                              
223           justifying the maintenance of this routing information, man=
y do
                              
224           not.  Further, in mobile environments, a pure consumer that=
 does
                              
225           not need to have a routable name prefix can benefit from th=
e
                              
226           inherent consumer mobility support in the CCNx and NDN prot=
ocols.
                              
227           By requiring a routable name prefix, extra mobile routing
228           machinery is needed, such as that proposed in KITE [Zhang20=
18] or
                              
229           MAPME [Auge2018].
                              


                              231       2.  The consumer name prefix in item (1) above =
must be communicated
                              
232           to the producer as a payload, name suffix, or other field o=
f the
                              
233           initiating Interest message.  Since this name in its entire=
ty is
                              
234           chosen by the consumer, it is highly problematic from a sec=
urity
                              
235           standpoint, as it can recruit the producer to mount a refle=
ction
                              
236           attack against the consumer's chosen victim.
                              


                              238       3.  The correlation between the exchanges in op=
posite directions must
                              
239           be maintained by both the consumer and the producer as
                              
240           independent state, as opposed to being architecturally tied=

                              
241           together as would be the case with a conventional 3-way han=
dshake
                              
242           finite state machine.  While this can of course be accompli=
shed
                              
243           with care by both parties, experience has shown that it is =
error
                              
244           prone (for example see the checkered history of interaction=
s
                              
245           between the SIP [RFC3261] and SDP Offer-Answer [RFC6337])
246           protocols.  When employed as the wrapper for a key manageme=
nt
                              
247           protocol such as with TLS [RFC8446] state management errors=
 can
                              
248           be catastrophic for security.
                              


                              250    2.  Requirements Language
                              


                              252       The key words "MUST", "MUST NOT", "REQUIRED", "=
SHALL", "SHALL NOT",
                              
253       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY"=
, and
                              
254       "OPTIONAL" in this document are to be interpreted as described =
in
                              
255       [RFC2119].
                              


                              257    3.  Overview of the Reflexive Forwarding design


                              259       This specification defines a Reflexive Forw=
arding extension to CCNx
                              
260       and NDN that avoids the problems enumerated in Sections 1.1 and=
 1.2.
                              
261       It straightforwardly exploits the hop-by-hop state and symmetri=
c
                              
262       routing properties of the current protocols.
                              


                              264       Figure 1 below illustrates a canonical NDN/CCNx=
 forwarder with its
                              
265       conceptual data structures of the Content Store (CS), Pending
266       Interest Table (PIT) and Forwarding Information Base (FIB).  Th=
e key
                              
267       observation involves the relation between the PIT and the FIB. =
 Upon
                              
268       arrival of an Interest, a PIT entry is created which contains s=
tate
                              
269       recording the incoming interface on which the Interest.  If the=

                              
270       Interest is not immediately satisfied by cached data in the CS,=
 the
                              
271       forwarder looks up the name in the FIB to ascertain the nex=
t-hop to
                              
272       propagate the Interest onward upstream toward the named produce=
r.
                              
273       Therefore, a chain of forwarding state is established during In=
terest
                              
274       forwarding that couples the PIT entries of the chain of forward=
ers
                              
275       together conceptually as breadcrumbs. These are used t=
o forward the
                              
276       returning Data Message over the inverse path through the chain =
of
                              
277       forwarders until the Data message arrives at the originating
278       consumer.  The state in the PITs is unwound by destroy=
ing it as
                              
279       each PIT entry is satisfied. This behavior is crit=
ical to the
                              
280       feasibility of the reflexive forwarding design we propose.
                              


                              282        +---------------------------------------------=
--------------------+
                              
283        |                                                      ICN Nod=
e   |
                              
284        | Send data to all                                     =3D=3D=3D=
=3D=3D=3D=3D=3D   |
                              
285        | interfaces that                                             =
    |
                              
286        | requested it                                                =
    |
                              
287        |                  YES +------------------+                   =
    |
                              
288       <------------------------| Pending Interest |  <---------=
------------
                              
289        |              |       |    Table (PIT)   |               Data=
    |
                              
290        |              |       +------------------+  1) Find     (Sign=
ed) |
                              
291        |              | 2) Save         |              Name          =
    |
                              
292        |              V    Data         | NO            in           =
    |
                              
293        |   +---------------+            |              PIT?          =
    |
                              
294        |   | Content Store |            |                            =
    |
                              
295        |   |      (CS)     |            |                            =
    |
                              
296        |   +---------------+            |                            =
    |
                              
297        |                                |                            =
    |
                              
298        |                                V                            =
    |
                              
299        |                             Drop Data                       =
    |
                              
300        |                                                             =
    |
                              
301        +-------------------------------------------------------------=
----+
                              
302        +-------------------------------------------------------------=
----+
                              
303        |                                                      ICN Nod=
e   |
                              
304        |                                                      =3D=3D=3D=
=3D=3D=3D=3D=3D   |
                              
305        |                                                             =
    |
                              
306        |                                           +=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+|
                              
307        |                                           |Forwarding Strate=
gy ||
                              
308        |                                           +=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+|
                              
309        |                                                             =
    |
                              
310        |   1) Find name          2) Matching        3) Find matching =
    |
                              
311        |        in CS?              name in PIT?       entry in FIB? =
    |
                              
312        |                    NO                   NO                  =
 YES|
                              
313        |  +---------------+   +----------------+   +-----------------=
--+ |
                              
314        |  | Content Store |   |   Pending      |   |  Forwarding     =
  | |
                              
315       --->|      (CS)     |-->|   Interest     |-->|  Inform=
ation Base |-->
                              
316        |  |               |   |   Table (PIT)  |   |     ( FIB)      =
  | |
                              
317        |  +---------------+   +----------------+   +-----------------=
--+ |
                              
318        | Return   | YES           YES | NO               NO |        =
    |
                              
319        |  Data    |          Add      |   Add               |  Drop  =
    |
                              
320        |          |          Incoming |   new               |   or   =
    |
                              
321        |   <------|          Itf.     |   Interest          |  NAC=
K      |
                              
322        |                              V                     V        =
    |
                              
323        |                                                             =
    |
                              
324        +-------------------------------------------------------------=
----+
                              


                              326                         Figure 1: ICN forwarder struc=
ture
                              


                              328       Given the above forwarding properties for Inter=
ests, it should be
                              
329       clear that while an Interest is outstanding and ultimately arri=
ves at
                              
330       a producer who can respond to it, there is sufficient state in =
the
                              
331       chain of forwarders to route not just a returning Data message,=
 but
                              
332       potentially another Interest directed through the inverse path =
to the
                              
333       unique consumer who issued the original Interest.  (Section 8.1=
=2E3
                              
334       describes how Interest aggregation interacts with this scheme.)=
  The
                              
335       key question therefore is how to access this state in a way tha=
t it
                              
336       can be used to forward Interests.
                              


                              338       In order to achieve this Reflexive Interest=
 forwarding on the
                              
339       inverse path recorded in the PIT of each forwarder, we need a f=
ew
                              
340       critical design elements.  These are as follows:
                              


                              342       1.  The Reflexive Interest needs to have a Name=
=2E  This name is what
                              
343           the originating consumer will use to match against the Data=

                              
344           object (or objects - more on this later) it wishes the prod=
ucer
                              
345           to fetch by issuing the Reflexive Interest.  This cannot be=
 just
                              
346           any name, but needs to essentially name the state already
347           recorded in the PIT and not allow the consumer to manufactu=
re an
                              
348           arbitrary name and mount a reflection attack as pointed out=
 in
                              
349           Section 1.2, Paragraph 2, Item 2.
                              


                              351       2.  There has to be a FIB entry at each forward=
er for this name
                              
352           prefix so that when the reflexive interest arrives, the for=
warder
                              
353           can forward it downstream toward the originating consumer. =
 This
                              
354           FIB entry points directly to the incoming interface on whic=
h the
                              
355           corresponding original Interest arrived.  The FIB entry nee=
ds to
                              
356           be created as part of the forwarding of the original Intere=
st so
                              
357           that it is available in time to catch any reflexive Interes=
t
                              
358           issued by the producer.  It usually makes sense to destroy =
this
                              
359           FIB entry when the Data message satisfying the original Int=
erest
                              
360           arrives since this avoids any dangling stale state.  Given =
the
                              
361           deign details documented later in this specification, stale=
 FIB
                              
362           state does not represent a correctness hazard and hence can=
 be
                              
363           done lazily if desired in an implementation.  See Section 5=
 for
                              
364           more details on FIB operation considerations.
                              


                              366       3.  There has to be coupling of the state betwe=
en the originating
                              
367           Interest-Data exchange and the enclosed Reflexive Interest-=
Data
                              
368           exchange at both the consumer and the producer.  In our des=
ign,
                              
369           this accomplished by the way reflexive interest names are c=
hosen.
                              


                              371       The following sections provide the normative de=
tails on each of these
                              
372       design elements.  The overall interaction flow for reflexive
373       forwarding is illustrated below in Figure 2.
                              


                              375       +-----------+    +-----------+                 =
 +-----------+
                              
376       | Consumer  |    | Forwarder |                  | Producer  |
377       +-----------+    +-----------+                  +-----------+
378             |                |                              |
                              
379             | I1             |                              |
                              
380             |--------------->|                              |
                              
381             |--------------\ |                              |
                              
382             || Install RNP |-|                              |
                              
383             || in FIB      | |                              |
                              
384             ||-------------| |                              |
                              
385             |                |                              |
                              
386             |                | I1                           |
                              
387             |                |----------------------------->|
                              
388             |                |                              | -------=
----\
                              
389             |                |                              |-| Creat=
e   |
                              
390             |                |                              | | RI st=
ate |
                              
391             |                |                              | |------=
----|
                              
392             |                |                              |
                              
393             |                |                           RI |
                              
394             |                |<-----------------------------|
                              
395             |                | --------------------\        |
                              
396             |                |-| lookup RNP in FIB |        |
                              
397             |                | |-------------------|        |
                              
398             |                |                              |
                              
399             |             RI |                              |
                              
400             |<---------------|                              |
                              
401             |                |                              |
                              
402             | D2             |                              |
                              
403             |--------------->|                              |
                              
404             |                |                              |
                              
405             |                | D2                           |
                              
406             |                |----------------------------->|
                              
407             |                |                              | -------=
-----\
                              
408             |                |                              |-| answe=
r I1 |
                              
409             |                |                              | |------=
-----|
                              
410             |                |                              |
                              
411             |                |                           D1 |
                              
412             |                |<-----------------------------|
                              
413             |                | -----------------------\     |
                              
414             |                |-| remove RNP FIB entry |     |
                              
415             |                | |----------------------|     |
                              
416             |                |                              |
                              
417             |             D1 |                              |
                              
418             |<---------------|                              |
                              
419             |                |                              |
                              


                              421           Legend:
                              
422           I1: Interest #1 containing the Reflexive Name Prefix TLV
423           RI: Reflexive Interest with Reflexive Name Prefix Component=

                              
424           RNP: Reflexive Name Prefix
                              
425           D1: Data message, answering initiating I1 Interest
                              
426           D2: Data message, answering RI
                              


                              428                          Figure 2: Message Flow Overv=
iew
                              


                              430    4.  Naming of Reflexive Interests
                              


                              432       A consumer may have one or more objects for the=
 producer to fetch,
                              
433       and therefore needs to communicate enough information in their<=
br>
434       initial Interest to allow the producer to construct properly fo=
rmed
                              
435       reflexive Interest names.  For some applications the set of full
                              
436       names                               (see [I-D.irtf-icnrg-terminology]) is known a priori=
, for
                              
437       example through compile time bindings of arguments in interface=

                              
438       definitions or by the architectural definition of a simple sens=
or
                              
439       reading.  In other cases the full names of the individual objec=
ts
                              
440       must be communicated in the original Interest message.  In all =
cases
                              
441       enough state must be provided by the consumer for the forwarder=
s to
                              
442       construct a FIB entry (as noted in Section 3, Paragraph 6, Item=
 2).
                              
443       This is accomplished through the following naming construct.


                              445       We define a new typed name component, identifie=
d by a registered name
                              
446       component type in the IANA registry for [RFC8569].  We call thi=
s the
                              
447       Reflexive Interest Name Component type. It MUST be the=
 first (i.e.
                              
448       high order) name component of any Reflexive Interest issued by =
a
                              
449       producer.  Its value is a random 64 bit number, assigned by the=

                              
450       consumer, which provides the entropy required to uniquely ident=
ify
                              
451       the issuing consumer for the duration of any outstanding Intere=
st-
                              
452       Data exchange.  The consumer SHOULD choose a different random v=
alue
                              
453       for each Interest message it constructs, for two reasons:
                              


                              455       1.  If stale FIB sate is present, the randomnes=
s prevents potential
                              
456           mis-routing of reflexive interests (see Section 8.1.1 below=
 for
                              
457           more details), and
                              


                              459       2.  Re-use of the same reflexive interest name =
over multiple
                              
460           interactions might reveal linkability information that coul=
d be
                              
461           used by surveillance adversaries for tracking purposes.
                              =



                              463       This initial name component is either communica=
ted by itself through
                              
464       a Reflexive Name Prefix TLV in the originating Interes=
t, or
                              
465       prepended to any object names the consumer wishes the producer =
to
                              
466       fetch explicitly where there is more than one object needed by =
the
                              
467       producer for the current Interest-Data interaction.  There are =
four
                              
468       cases to consider:
                              


                              470       1.  The reflexive fullname of a single=
 object to fetch.
                              


                              472       2.  A single reflexive name prefix out of which=
 the producer can (by
                              
473           application-specific means) construct a number of fulln=
ames of
                              
474           the objects it may want to fetch,
                              


                              476       3.  The reflexive fullname of a FLIC M=
anifest [I-D.irtf-icnrg-flic]
                              
477           enumerating the suffixes that may be used by the producer t=
o
                              
478           construct the necessary names,
                              


                              480       4.  Multiple reflexive name TLVs MAY be include=
d in the Interest
                              
481           message if none of the above 3 options covers the desired u=
se
                              
482           case.
                              


                              484       The last of the four options above, while not e=
xplicitly outlawed,
                              
485       SHOULD NOT be used.  This is because it results in a longer Int=
erest
                              
486       message and requires extra FIB resources.  Hence, it is more li=
kely a
                              
487       forwarder will reject the Interest for lack of resources.  A
488       forwarder MAY optimize for the case of a single Reflexive Name =
TLV at
                              
489       the expense of those with more than one.
                              


                              491       A producer, upon receiving an Interest with one=
 or more Reflexive
                              
492       Name TLVs, may decide it needs the pull the associated data
                              =

493       object(s).  It therefore can issue one or more Reflexive Intere=
sts by
                              
494       appending the necessary name components needed to form valid fu=
ll
                              
495       names of the associated objects present at the originating cons=
umer.
                              
496       These in fact comprise conventional Interest-Data exchanges, wi=
th no
                              
497       alteration of the usual semantics with regard to signatures, ca=
ching,
                              
498       expiration, etc.  When the producer has retrieved the required<=
br>
499       objects to complete the original Interest-Data exchange, it can=
 issue
                              
500       its Data response, which unwinds all the established state at t=
he
                              
501       producer, the consumer, and the intermediate forwarders.
                              


                              503    5.  Forwarder operation for Reflexive Interests


                              505       The forwarder operation for CCNx and/or NDN is =
changed in three
                              
506       respects when supporting Reflexive Interests.
                              


                              508       1.  The forwarder MUST create short-lifetime FI=
B entries for any
                              
509           Reflexive Interest Name prefixes communicated in an Interes=
t
                              
510           message.  If the forwarder does not have sufficient resourc=
es to
                              
511           do so, it MUST reject the Interest with the T_RETURN_NO_RES=
OURCES
                              
512           error - the same error used if the forwarder were lacking
513           sufficient PIT resources to process the Interest message.


                              515       2.  Those FIB entries MUST be queried whenever =
an Interest message
                              
516           arrives whose first name component is of the type Refle=
xive
                              
517           Interest Name Component
                              


                              519       3.  The FIB entry MUST be removed eventually, a=
fter the corresponding
                              
520           Data message has been forwarded.  One option would be to re=
move
                              
521           the FIB directly after the Data message has been forwarded.=

                              
522           However, the forwarder MAY do lazy cleanup.
                              


                              524       The PIT entry for the Reflexive Interest is con=
sumed per regular
                              
525       Interest/Data message forwarding requirements.  The PIT entry f=
or the
                              
526       originating Interest (that communicated the Reflexive Interest =
Name)
                              
527       is also consumed by a final Data message from the producer to t=
he
                              
528       original consumer.
                              


                              530    6.  State coupling between producer and consumer


                              532       A consumer that wishes to use this scheme MUST =
utilize one of the
                              
533       reflexive naming options defined in Section 4 and include it in=
 the
                              
534       corresponding Interest message.  The Reflexive Name TLV and=
 the
                              
535       full name of the requested data object (that identifies the pro=
ducer)
                              
536       identify the common state shared by the consumer and the produc=
er.
                              
537       When the producer responds by sending Interests with the Reflex=
ive
                              
538       Name Prefix, the original consumer therefore has sufficient
                              =

539       information to map these Interests to the ongoing Interest-Data=

                              
540       exchange.
                              


                              542       The exchange is finished when the producer who =
received the original
                              
543       Interest message responds with a Data message (or an Interest R=
eturn
                              
544       message in the case of error) answering the original Interest. =
 After
                              
545       sending this Data message, the producer SHOULD destroy the
                              
546       corresponding shared state.  It MAY decide to use a timer that =
will
                              
547       trigger a later state destruction.  After receiving this Data
548       message, the originating consumer MUST destroy the correspondin=
g
                              
549       Interest-Data exchange state.
                              


                              551    7.  Use cases for Reflexive Interests
                              


                              553    7.1.  Achieving Remote Method Invocation with Refl=
exive Interests
                              


                              555       RICE (Remote Method Invocation in ICN) [Krol201=
8] uses the Reflexive
                              
556       Interest Forwarding scheme that inspired the design specified i=
n this
                              
557       document.
                              


                              559       In RICE, the original Interest denotes the remo=
te method (plus
                              
560       potential parameters) to be invoked at a producer (server).  Be=
fore
                              
561       committing any computating resources, the server can then reque=
st
                              
562       authentication credentials and (optional) parameters using refl=
exive
                              
563       Interest-Data exchanges.
                              


                              565       When the server has obtained the necessary cred=
entials and input
                              
566       parameters, it can decide to commit computing resources, starts=
 the
                              
567       compute process, and returns a handle ("Thunk") in the final Da=
ta
                              
568       message to the original consumer (client).
                              


                              570       The client would later request the computation =
results using a
                              
571       regular Interest-Data exchange (outside the Reflexive-Interest<=
br>
572       transaction) -- using the Thunk as a name for the computation r=
esult.
                              


                              574       Figure 3 depicts an abstract message diagram fo=
r RICE.  In addition
                              
575       to the 4-way Reflexive Forwarding Handshake (see Figure 2 for t=
he
                              
576       details of the interaction), RICE adds another (standard) ICN
577       Interest/Data exchange for transmitting the RMI result.  The Th=
unk
                              
578       name is provided to the consumer in the D1 DATA message (answer=
ing
                              
579       the initial I1 Interest).
                              


                              581       +-----------+              +-----------+
                              
582       | Consumer  |              | Producer  |
                              
583       +-----------+              +-----------+
                              
584             |                          |
                              
585             | I1                       |
                              
586             |------------------------->|
                              
587             |                          | ---------------------\
                              
588             |                          |-| Requesting request |
                              
589             |                          | | parameters         |
                              
590             |                          | | and credentials    |
                              
591             |                          | |--------------------|
                              
592             |                          |
                              
593             |                       RI |
                              
594             |<-------------------------|
                              
595             |                          |
                              
596             | D2                       |
                              
597             |------------------------->|
                              
598             |                          | --------------------\
                              
599             |                          |-| Commit compute    |
                              
600             |                          | | resources,        |
                              
601             |                          | | return Thunk name |
                              
602             |                          | |-------------------|
                              
603             |                          |
                              
604             |                       D1 |
                              
605             |<-------------------------|
                              
606             |                          | ----------------\
                              
607             |                          |-| Invoke Remote |
                              
608             |                          | | Method        |
                              
609             |                          | |---------------|
                              
610             | -------------------\     |
                              
611             |-| After some time, |     |
                              
612             | | request result   |     |
                              
613             | |------------------|     |
                              
614             |                          |
                              
615             | I3                       |
                              
616             |------------------------->|
                              
617             |                          |
                              
618             |                       D3 |
                              
619             |<-------------------------|
                              
620             |                          |
                              
621           Legend:
                              
622           I1: Interest #1 containing the Reflexive Name Prefix TLV
623           D1: Data message, answering initiating I1 Interest,
                              
624               returning Thunk name
                              
625           D2: Data message, answering RI (parameters, credentials)
626           I3: Regular Interest for Thunk (compute result)
                              
627           D3: Data message, answering I3
                              
628                            Figure 3: RICE Message Flow
                              


                              630    7.2.  RESTful Web Interactions
                              


                              632       In todays HTTP-based web, RESTful (Representati=
onal State Transfer)
                              
633       web interactions are realized by sending requests in a client/s=
erver
                              
634       interaction, where the requests provides the application contex=
t (or
                              
635       a reference to it).  It has been noted in [Moiseenko2014] that<=
br>
636       corresponding requests often exceed the response messages in si=
ze,
                              
637       and that this raises the problems noted in Section 1.1 when
                              =

638       attempting to map such exchanges directly to CCNx/NDN.
                              


                              640       Another reason not to include all request param=
eters in a (possibly
                              
641       encrypted) Interest message is the fact that a server (that is<=
br>
642       serving thousands of clients) would be obliged to receive, poss=
ibly
                              
643       decrypt and parse the complete requests before being able to
644       determine whether the requestor is authorized, whether the requ=
est
                              
645       can be served etc.  Many non-trivial requests could thus lead t=
o
                              
646       computational overload attacks.
                              


                              648       Using Reflexive Interest Forwarding for RESTful=
 Web Interactions
                              
649       would encode the REST request in the Original request, together=
 with
                              
650       a Reflexive Interest Prefix that the server could then use to g=
et
                              
651       back to the client for authentication credentials and request
652       parameters, such as cookies.  The request result (response mess=
age)
                              
653       could either be transmitted in the Data message answering the
654       original request, or -- in case of dynamic, longer-running
                              
655       computations -- in a seperate Interest/Data exchange, potential=
ly
                              
656       leveraging the Thunk scheme described in section Section 7.1.


                              658       Unlike approaches where clients have to signal =
a globally routable
                              
659       prefix to the network, this approach would not require the clie=
nt
                              
660       (original consumer) to expose its identity to the network (the<=
br>
661       network only sees the temporary Reflexive Name Prefix), but it =
would
                              
662       still be possible to authenticate the client at the server.
                              =



                              664    7.3.  Achieving simple data pull from consumers wi=
th reflexive Interests
                              


                              666       An oft-cited use case for ICN network architect=
ures is Internet of
                              
667       Things                               (IoT), where the sources of data are limited-resour=
ce sensor/
                              
668       actuators.  Many approaches have been tried (e.g.  [Baccelli201=
4],
                              
669       [Lindgren2016], [Gundogan2018]) with varying degrees of success=
 in
                              
670       addressing the issues outlined in Section 1.1.  The reflexive
671       forwarding extension may substantially ameliorate the documente=
d
                              
672       difficulties by allowing a different model for the basic intera=
ction
                              
673       of sensors with the ICN network.
                              


                              675       Instead of acting as a producer (either directl=
y to the Internet or
                              
676       indirectly through the use of some form of application-layer
677       gateway), the IoT device need only act as a consumer.  When it =
has
                              
678       data to provide, it issues a "phone-home" Interest message to a=
 pre-
                              
679       configured rendezvous name (e.g. an application-layer gateway o=
r ICN
                              
680       Repo [Chen2015]) and provides a reflexive name prefix TLV for t=
he
                              
681       data it wishes to publish.  The target producer may then issue =
the
                              
682       necessary reflexive Interest message(s) to fetch the data.  Onc=
e
                              
683       fetched, validated, and stored, the producer then responds to t=
he
                              
684       original Interest message with a success indication, possibly
685       containing a Data object if needed to allow the originating dev=
ice to
                              
686       modify its internal state.  Alternatively, the producer might c=
hoose
                              
687       to not respond and allow the original Interest to time out, alt=
hough
                              
688       this is NOT RECOMMENDED except in cases where the extra message=

                              
689       transmission bandwith is at a premium compared to the persisten=
ce of
                              
690       stale state in the forwarders.  We note that this interaction
691       approach mirrors the earlier efforts using Interest-Interest-Da=
ta
                              
692       designs.
                              


                              694       Figure 4 depicts this interaction with the OPTI=
ONAL D1 message.  See
                              
695       Figure 2 for the details of the general Reflexive Forwarding
696       interaction.
                              


                              698                    +-----------+ +-----------+
                              
699                    | Consumer  | | Producer  |
                              
700                    +-----------+ +-----------+
                              
701            ------------\ |             |
                              
702            | new IoT   |-|             |
                              
703            | data item | |             |
                              
704            | produced  | |             |
                              
705            |-----------| |             |
                              
706         ---------------\ |             |
                              
707         | "phone home" |-|             |
                              
708         | by notifying | |             |
                              
709         | producer     | |             |
                              
710         |--------------| |             |
                              
711                          |             |
                              
712                          | I1          |
                              
713                          |------------>|
                              
714                          |             | --------------------\
                              
715                          |             |-| generate Interest |
                              
716                          |             | | for IoT data      |
                              
717                          |             | |-------------------|
                              
718                          |             |
                              
719                          |          RI |
                              
720                          |<------------|
                              
721       -----------------\ |             |
                              
722       | send requested |-|             |
                              
723       | data object    | |             |
                              
724       |----------------| |             |
                              
725                          |             |
                              
726                          | D2          |
                              
727                          |------------>|
                              
728                          |             | -----------------------\
                              =

729                          |             |-| finalize interaction |
                              =

730                          |             | | with optional        |
                              =

731                          |             | | Data message         |
                              =

732                          |             | |----------------------|
                              =

733                          |             |
                              
734                          |          D1 |
                              
735                          |<------------|
                              
736                          |             |
                              
737           Legend:
                              
738           I1: Interest #1 containing the Reflexive Name Prefix TLV
739           D1: Data message (OPTIONAL), finalizing interaction
                              
740           D1: Data message, answering RI, returning IoT data object


                              742                        Figure 4: "Phone Home" Message=
 Flow
                              


                              744       There are two approaches that the IoT device ca=
n use for its response
                              
745       to a reflexive Interest.  It can simply construct a Data Messag=
e
                              
746       bound through the usual ICN hash name to the reflexive Interest=
 name.
                              
747       Since the scope of any data object bound in this way is only th=
e
                              
748       duration of the enclosing Interest-Data exchange (see Section 8=
=2E2)
                              
749       the producer would need to itself construct any persistent Data=

                              
750       object, name it, and sign it.  This is sometimes the right appr=
oach,
                              
751       as for some applications the identity of the originating IoT de=
vice
                              
752       is not important from an operational or security point of view;=
 in
                              
753       contrast the identity of the gateway or Repo is what matters.


                              755       If alternatively, the persistent Data object sh=
ould be bound from a
                              
756       naming and security point of view to the originating IoT device=
, this
                              
757       can be easily accomplished.  Instead of directly placing the co=
ntent
                              
758       in a Data object responding to the reflexive Interest as above,=
 the
                              
759       consumer encapsulates a complete CCNx/NDN Data message (which
760       includes the desired name of the data) as in the response to th=
e
                              
761       reflexive Interest message.
                              


                              763       The interaction model described above brings a =
number potential
                              
764       advantages, some obvious, some less so.  We enumerate a few of =
them
                              
765       as follows:
                              


                              767       *  By not requiring the IoT device to be active=
ly listening for
                              
768          Interests, it can sleep and only wake up if it has something=
 to
                              
769          communicate.  Conversely, parties interested in obtaining da=
ta
                              
770          from the device do not need to be constantly polling in orde=
r to
                              
771          ascertain if there is new data available.
                              


                              773       *  No forwarder resources are tied up with stat=
e apart from the
                              
774          actual reflexive forwarding interactions.  All that is neede=
d is
                              
775          enough routing state in the FIB to be able to forward the "p=
hone
                              
776          home" Interest to an appropriate target producer.  While thi=
s
                              
777          model does not provide all the richness of a full Pub/Sub sy=
stem
                              
778          (like that described in [Gundogan2018]) we argue it is adequ=
ate
                              
779          for a large subclass of such applications.
                              


                              781       *  The reflexive interest, through either a nam=
e suffix or Interest
                              
782          payload, can give the IoT device useful context from which t=
o
                              
783          craft its Data object in response.  One highly useful parame=
ter
                              
784          would be a robust clock value for the device to use as a tim=
estamp
                              
785          of the data, possibly as part of its name to correctly place=
 it in
                              
786          a time seres of sensor readings.  This substantially allevia=
tes
                              
787          the need for low-end devices to have a robust time base, as =
long
                              
788          as they trust the producer they contact to provide it.
                              


                              790    8.  Implementation Considerations
                              


                              792       There are a number of important aspects to the =
reflexive forwarding
                              
793       design which affect correctness and performance of existing
                              =

794       forwarder, consumer, and producer implementations desiring to s=
upport
                              
795       it.  This section discusses the effect on each of these element=
s of
                              
796       the CCNx/NDN protocol architecture.
                              


                              798    8.1.  Forwarder implementation considerations
                              


                              800    8.1.1.  Forwarding Information Base (FIB)
                              


                              802       The FIB is a performance-critical data structur=
e in any forwarder, as
                              
803       it needs to support relatively expensive longest name prefix ma=
tch
                              
804       (LNPM) lookup algorithms.  A number of well-known FIB data stru=
ctures
                              
805       are heavily optimized for read access, since for normal Interes=
t
                              
806       message processing the FIB changes slowly - only after topologi=
cal
                              
807       changes or routing protocol updates.  Support for reflexive nam=
es
                              
808       changes this, as FIB entries are created and destroyed rapidly =
as
                              
809       Interest messages containing reflexive name TLVs are processed =
and
                              
810       the corresponding Data messages come back.
                              


                              812       While it may be feasible, especially in low-end=
 forwarders handling a
                              
813       low packet forwarding rate to ignore this problem, for high-spe=
ed
                              
814       forwarders there are a number of hazards, including:
                              


                              816       1.  If the entire FIB needs to be locked in ord=
er to insert or remove
                              
817           entries, this could cause inflated forwarding delays or in<=
br>
818           extreme cases, forwarding performance collapse.
                              


                              820       2.  A number of high-speed forwarder implementa=
tions employ a sharded
                              
821           PIT scheme to better parallelize forwarding across processi=
ng
                              
822           cores.  The FIB, however, is still a shared data structure =
which
                              
823           is either read without read locks across cores, or explicit=
ly
                              
824           copied such that there is a separate copy of the FIB for ea=
ch PIT
                              
825           shard.  Clearly, a high update rate without read locks and/=
or
                              
826           updating many copies of the FIB are unattractive implementa=
tion
                              
827           options.  (Note: with this reflexive name scheme it is not<=
br>
828           feasible to force reflexive interests to be hashed or be
829           otherwise directed to the PIT shard holding the original In=
terest
                              
830           state).
                              


                              832       There are any number of alternative FIB impleme=
ntations that can work
                              
833       well however.  The most straightforward is to simply implement =
a
                              
834       "special" FIB for just reflexive name lookups.  This is feasibl=
e
                              
835       because reflexive names deterministically contain the distingui=
shed
                              
836       high-order name component type of T_REFLEXIVE_NAME, whose conte=
nt is
                              
837       a 64-bit value that can be easily hashed to a FIB entry directl=
y,
                              
838       avoiding the more expensive LNPM lookup.  Inserts and deletes t=
hen
                              
839       devolve to the well-understood problem of hash table maintenanc=
e.
                              


                              841    8.1.2.  Interactions with Interest Lifetime
                              


                              843       If and when a producer decides to fetch data fr=
om the consumer using
                              
844       one or more reflexive Interest-Data exchanges, the total latenc=
y for
                              
845       the original Interest-Data exchange is inflated, potentially by=

                              
846       multiple RTTs.  It is difficult for a consumer to predict the
847       inflation factor when issuing the original Interest, and hence =
there
                              
848       can be a substantial hazard of that Interest lifetime expiring =
before
                              
849       completion of the full multi-way exchange.  This can result in<=
br>
850       persistent failures, which is obviously highly undesirable.
                              =



                              852       There is a fairly straightforward technique tha=
t can be employed by
                              
853       forwarders to avoid these "false" Interest lifetime expirations=
=2E  In
                              
854       the absence of a superior alternative technique, it is RECOMMEN=
DED
                              
855       that all forwarders implement the following algorithm.
                              


                              857       When processing an Interest containing the refl=
exive name TLV and
                              
858       creating the necessary FIB entry (see Section 8.1.1 above), the=

                              
859       forwarder also creates a back pointer from that FIB en=
try to the
                              
860       PIT entry for the Interest message that created it.  This PIT e=
ntry
                              
861       contains the current value of the remaining Interest lifetime o=
r
                              
862       alternatively a value from which the remaining Interest lifetim=
e can
                              
863       be easily computed.  Call this value IL(t)_.
                              


                              865       If and when a reflexive Interest arrives from u=
pstream matching the
                              
866       reflexive FIB entry, the forwarder examines the Interest lifeti=
me of
                              
867       the arriving reflexive Interest.  Call this value IL(r=
). The
                              
868       forwarder computes MAX(_IL                              (t), (IL_(r) * 1.5)), and re=
places
                              
869       _IL                              (t)_ with this value.  This in effect ensures that the =
remaining
                              
870       Interest lifetime of the original Interest accounts for the
                              =

871       additional 1.5 RTTs that may occur as a result of the reflexive=

                              
872       Interest-Data exchange.
                              


                              874       If the above algorithm is implemented naively a=
s described above, it
                              
875       may run afoul of a sharded PIT forwarder implementation, since =
the
                              
876       PIT entry for the reflexive Interest and the PIT entry for the<=
br>
877       original Interest may be in different shards.  Therefore, if th=
e
                              
878       update is done cross-shard on each reflexive Interest arrival,<=
br>
879       performance may suffer, perhaps dramatically.  Instead, the fol=
lowing
                              
880       approach to updating the Interest lifetime after computing the =
new
                              
881       value is RECOMMMENDED for sharded-PIT forwarders.
                              


                              883       When creating the reflexive FIB entry as above =
in Section 8.1.1, copy
                              
884       the remaining Interest lifetime from the PIT entry.  Do the PIT=

                              
885       update if and only if this value is about to expire, thus payin=
g the
                              
886       cross-shard update cost only if the original Interest is about =
to
                              
887       expire.  A further optimization at the cost of modest extra
                              =

888       complexity is to instead queue the update to the core =
holding the
                              
889       shard of the original PIT entry rather than doing the update
890       directly.  If the PIT entry expires or is satisfied, instead of=

                              
891       removing it the associated core checks the update queue and doe=
s the
                              
892       necessary update.
                              


                              894       While the above approach of inflating the inter=
est lifetime of the
                              
895       original Interest to accommodate the additional RTTs of reflexi=
ve
                              
896       Interest-Data exchanges, this does introduce a new vulnerabilit=
y that
                              
897       must be dealt with.  A Producer, either through a bug or malici=
ous
                              
898       intent, could keep an originating Interest-Data exchange alive =
by
                              
899       continuing to send reflexive Interests back to the consumer, wh=
ile
                              
900       the consumer had no way to terminate the enclosing interaction =
(there
                              
901       is no "cancel Interest" function in either NDN nor CCNx).  To
902       eliminate this hazard, if the consumer rejects a reflexive inte=
rest
                              
903       with a T_RETURN_PROHIBITED error, the forwarder(s), in addition=
 to
                              
904       satisfying the coresponding PIT entry, MUST also delete the
                              =

905       associated reflexive FIB entry, thereby preventing any further<=
br>
906       reflexive Interests from reaching the consumer.  This allows th=
e
                              
907       enclosing Interest-Datsa exchange to either time out or be corr=
ectly
                              
908       ended with a Data message or Interest Return from the Producer.=

                              


                              910    8.1.3.  Interactions with Interest aggregation
                              =



                              912       As with numerous other situations where multipl=
e Interests for the
                              
913       same named object arrive containing different parameters (e.g.<=
br>
914       Interest Lifetime, QoS, payload hash) the same phenomenon occur=
s for
                              
915       the reflexive Name TLV.  If such Interests collide, the forward=
er
                              
916       MUST NOT aggregate these Interest messages and instead MUST cre=
ate a
                              
917       separate PIT entry for each.
                              


                              919    8.2.  Consumer Implementation Considerations
                              


                              921    8.2.1.  Data objects returned by the consumer to r=
eflexive name
                              
922            Interests arriving from a producer
                              


                              924       The Data objects returned to the producer in re=
sponse to a reflexive
                              
925       Interest are normal CCNx/NDN data objects.  It is therefore wor=
th
                              
926       noting that the object is bound to the reflexive Interest full =
name
                              
927       via the hash and hence the scope of the object is under most
928       circumstances meaningful only for the duration of the enclosing=

                              
929       Interest-Data interaction.  This property is ideal for naming a=
nd
                              
930       securing data that is "part of" the enclosing interaction - thi=
ngs
                              
931       like method arguments, authenticators, and key exchange paramet=
ers,
                              
932       but not for the creation and naming of objects intended to surv=
ive
                              
933       outside the current interaction's scope (c.f.  Section 7.3, whi=
ch
                              
934       describes how to provide globally-named objects using encapsula=
tion).
                              
935       In general, the consumer should use the following guidelines in=

                              
936       creating Data messages in response to reflexive Interest messag=
es
                              
937       from the producer.
                              


                              939       (a)  Set the recommended cache time (T_CACHETIM=
E) either to zero, or
                              
940            a value no greater than the Interest lifetime (T_INTLIFE) =
of the
                              
941            original Interest messsage.
                              


                              943       (b)  Set the payload type (T_PAYLDTYPE) accordi=
ng to the type of
                              
944            object being returned (e.g. object, link, manifest)
                              


                              946       (c)  Set the expiry time (T_EXPIRY) to a value =
greater than now,
                              
947            and less than or equal to the now + Interest life=
time
                              
948            (T_INTLIFE) of the original Interest messsage.
                              


                              950    8.2.2.  Terminating unwanted reflexive Interest ex=
changes
                              


                              952       A consumer may wish to stop receiving reflxive =
Interests due to
                              
953       possible erors or malicious behavior on the part of the produce=
r.
                              
954       Therefore, if the consumer receives an unwanted reflexive Inter=
est,
                              
955       it SHOULD reject that interest with a T_RETURN_PROHIBITED error=
=2E
                              
956       This will provoke the forwarders to prevent further reflexive
957       Interests from reaching the consumer, as described above in
                              =

958       Section 8.1.2, Paragraph 7.
                              


                              960    8.2.3.  Interactions with caching
                              


                              962       The reflexive named objects provide "local", te=
mporary names that are
                              
963       only defined for one specific interaction between a consumer an=
d a
                              
964       producer.  Corresponding Data objects MUST NOT be shared betwee=
n
                              
965       multiple consumers (violating this would require specail gyrati=
ons by
                              
966       the producer since the reflexive Name utilizes per-consumer/per=
-
                              
967       interaction random values).  A producer MUST NOT issue an Inter=
est
                              
968       message for any reflexive name after it has sent the final Data=

                              
969       message answering the original Interest.
                              


                              971       Forwarders SHOULD still cache reflexive Data ob=
jects for
                              
972       retransmissions within a transactions, but they MUST remove the=
m from
                              
973       the content store when they forward the final Data message answ=
ering
                              
974       the original Interest.
                              


                              976    8.3.  Producer Implementation Considerations
                              


                              978       Producers receiving an Interest with a Reflexiv=
e Name Component, MAY
                              
979       decide to issue Interests for the corresponding Data objects.  =
All
                              
980       Reflexive Interest message that a producer sends MUST be sent o=
ver
                              
981       the face that the original Interest was received on.
                              


                              983    9.  Operational Considerations
                              


                              985       This extension represents a substantial enhance=
ment to the CCNx/NDN
                              
986       protocol architecture and hence has important forward and backw=
ard
                              
987       compatibility effects.  The most important of these is that cor=
rect
                              
988       operation of the scheme requires an unbroken chain of forwarder=
s
                              
989       between the consumer and the desired producer that support the<=
br>
990       Reflexive Name TLV and the corresponding forwarder capabilities=

                              
991       specified in Section 5.  When this invariant is not satisfied, =
some
                              
992       means is necessary to detect and hopefully recover from the err=
or.
                              
993       We have identified three possible approaches to handling the la=
ck of
                              
994       universal deployment of forwarders supporting the reflexive
                              =

995       forwarding scheme.
                              


                              997       The first approach simply lets the producer det=
ect the error by
                              
998       getting a "no route to destination" error when trying to send a=
n
                              
999       Interest to a reflexive name.  This will catch the error, but o=
nly
                              
1000       after forwarding resources are tied up and the producer has do=
ne some
                              
1001       work on the original Interest message.  Further, the producer =
would
                              
1002       need a bit of smarts to determine that this is a permanent err=
or and
                              
1003       not a transient to be retried.  In order for the consumer to a=
ttempt
                              
1004       recovery, there might be a need for some explicit error return=
ed for
                              
1005       the original interest to tell the consumer what the likely pro=
blem
                              
1006       is.  This approach does not enable an obvious recovery path fo=
r the
                              
1007       consumer either, since while we might envision a way to steer =
a
                              
1008       subsequent Interest onto a working path as proposed in
                              
1009       [I-D.oran-icnrg-pathsteering], there is no capability to force=

                              
1010       Interest routing away from an otherwise working path not suppo=
rting
                              
1011       the reflexive name TLV.
                              


                              1013       A second approach is to bump the CCNx/NDN prot=
ocol version to
                              
1014       explicitly indicate the lack of comparability.  Such Interests=
 would
                              
1015       be rejected by forwarders not supporting this protocol extensi=
on.  A
                              
1016       consumer wishing to use the reflexive name TLV would use the h=
igher
                              
1017       protocol version on those Interest messages (but could of cour=
se
                              
1018       continue to use the current version number on other Interest
1019       messages).  This is a big hammer, but may be called for in thi=
s
                              
1020       situation because:
                              


                              1022       (a)  it detects the problem immediately and de=
terministically, and
                              


                              1024       (b)  one could assume an ICN routing protocol =
that would only forward
                              
1025            to a next hop that supports the updated protocol version =
number.
                              
1026            The supported forwarder protocol versions would have been=

                              
1027            communicated in the routing protocol ahead of time.
                              


                              1029       A third option is to, as a precondition utiliz=
ing the protocol in a
                              
1030       deployment, create and deploy a neighbor capability exchange p=
rotocol
                              
1031       which will tell a downstream forwarder if the upstream can han=
dle the
                              
1032       new TLV.  This might avoid the large hammer of updating the pr=
otocol
                              
1033       version, but of course this puts a pretty strong dependency on=

                              
1034       somebody actually designing and publishing such a protocol!  O=
n the
                              
1035       other hand, a neighbor capability exchange protocol for CCNx/N=
DN
                              
1036       would have a number of other substantial benefits, which makes=
 it
                              
1037       worth seriously considering anyway.
                              


                              1039    10.  Mapping to CCNx and NDN packet encodings
                              =



                              1041    10.1.  Packet encoding for CCNx
                              


                              1043       For CCNx[RFC8569] there is one new Name Compon=
ent TLV type defined in
                              
1044       this specification.
                              


                              1046         +------------------+----------------+-------=
-------------------+
                              
1047         |      Abbrev      |      Name      |       Description     =
   |
                              
1048         +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+
                              
1049         | T_REFLEXIVE_NAME | Reflexive Name | Name component to use =
as |
                              
1050         |                  | Component      | name prefix in Reflexi=
ve |
                              
1051         |                  |                | Interest Message      =
   |
                              
1052         +------------------+----------------+-----------------------=
---+
                              


                              1054                           Table 1: Reflexive Name TL=
V
                              


                              1056    10.2.  Packet encoding for NDN
                              


                              1058       TBD based on [NDNTLV].  Suggestions from the N=
DN team greatly
                              
1059       appreciated.
                              


                              1061    11.  IANA Considerations
                              


                              1063       Please add the T_REFLEXIVE_NAME component TLV =
to the CCNx Name types
                              
1064       TLV types registry of [RFC8609], with Length 9 bytes and type =
of 64
                              
1065       bit random integer.
                              


                              1067                            1                   2    =
               3
                              
1068        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=
 1
                              
1069       +---------------+---------------+---------------+-------------=
--+
                              
1070       |         T_REFLEXIVE_NAME      |               8             =
  |
                              
1071       +---------------+---------------+---------------+-------------=
--+
                              
1072       |                                                             =
  |
                              
1073       |       64bit Integer randomly assigned by consumer           =
  |
                              
1074       +-------------------------------+-----------------------------=
--+
                              


                              1076                      Figure 5: Reflexive Name compon=
ent type
                              


                              1078    12.  Security Considerations
                              


                              1080       One of the major motivations for the reflexive=
 forwarding extension
                              
1081       specified in this document is in fact to enable better securit=
y and
                              
1082       privacy characteristics for ICN networks.  The main considerat=
ions
                              
1083       are presented in Section 1, but we briefly recapitulate them h=
ere:
                              


                              1085       *  Current approaches to authentication and da=
ta transfer often use
                              
1086          payloads in Interest messages, which are clumsy to secure
1087          (Interest messages must be signed) and as a consequence mak=
e it
                              
1088          very difficult to ensure consumer privacy.  Reflexive forwa=
rding
                              
1089          moves all sensitive data to the Data messages sent in respo=
nse to
                              
1090          reflexive Interests, which are secured in the same manner a=
s all
                              
1091          other Data messages in the CCNx and NDN protocol designs.


                              1093       *  In many scenarios, consumers are forced to =
also act as producers
                              
1094          so that data may be fetched by either a particular, or arbi=
trary
                              
1095          other party.  The means the consumer must arrange to have a=

                              
1096          routable name prefix and that prefix be disseminated by the=

                              
1097          routing protocol or other means.  This represents both a pr=
ivacy
                              
1098          hazard (by revealing possible important information about t=
he
                              
1099          consumer) and a security concern as it opens up the consume=
r to
                              
1100          the full panoply of flooding and crafted Interest denial of=

                              
1101          service attacks.
                              


                              1103       *  In order to achieve multi-way handshakes, i=
n current designs a
                              
1104          consumer wishing a producer to communicate back must inform=
 the
                              
1105          producer of what (globally routable) name to use.  This giv=
es the
                              
1106          consumer a convenient means to mount a variety of reflectio=
n
                              
1107          attacks by enlisting the producer to send Interests to desi=
red
                              
1108          victims.
                              


                              1110       As a major protocol extension however, this de=
sign brings its own
                              
1111       potential security issues, which are discussed in the followin=
g
                              
1112       subsections.
                              


                              1114    12.1.  Collisions of reflexive Interest names
                              =



                              1116       Reflexive Interest names are constructed using=
 64-bit random numbers.
                              
1117       This is intended to ensure an off-path attacker cannot easily<=
br>
1118       manufacture a matching reflexive Interest and either masquerad=
e as
                              
1119       the producer, or mount a denial of service attack on the consu=
mer.
                              
1120       It also limits tracking through the linkability of Interests
1121       containing a re-used random value.
                              


                              1123       Therefore consumers MUST utilize a robust mean=
s of generating these
                              
1124       random values, and it is RECOMMENDED that a pseudo-random numb=
er
                              
1125       generator (PRNG) approved for use with cryptographic protocols=
 be
                              
1126       employed.
                              


                              1128    12.2.  Additional resource pressure on PIT and FI=
B
                              


                              1130       Normal Interest message processing in CCNx and=
 NDN needs to consider
                              
1131       effect of various resource depletion attacks on the PIT, parti=
cularly
                              
1132       in the form of Interest flooding attacks (see [Gasti2012] for =
a good
                              
1133       overview of DoS and DDoS mitigation on ICN networks).  Interes=
t
                              
1134       messages utilizing this reflexive forwarding extension can pla=
ce
                              
1135       additional resource pressure on the PIT, and additionally caus=
e
                              
1136       otherwise stable FIB resources to be subject to highly dynamic=
 usage.
                              


                              1138       While this does not represent a new DoS/DDoS a=
ttack vector, the
                              
1139       ability of a malicious consumer to utilize this extension in a=
n
                              
1140       attack does represent an increased risk of resource depletion,=

                              
1141       especially if such Interests are given unfair access to PIT an=
d FIB
                              
1142       resources.  Implementers SHOULD therefore protect PIT and FIB<=
br>
1143       resources by weighing requests for reflexive forwarding resour=
ces
                              
1144       appropriately relative to other Interests.
                              


                              1146    12.3.  Privacy Considerations
                              


                              1148       ICN architectures like CCNx and NDN provide a =
rich tapestry of
                              
1149       interesting privacy issues, which have been extensively explor=
ed in
                              
1150       the research literature.  The fundamental tradeoffs for privac=
y
                              
1151       concern the risk of exposing the names of information objects =
to the
                              
1152       forwarding elements of the network, which is a necessary prope=
rty of
                              
1153       any name-based routing and forwarding design.  Numerous approa=
ches
                              
1154       have been explored with varying degrees of success, such as on=
ion
                              
1155       routing ([DiBenedettoGTU12]), name encryption ([Ghali2017]), a=
nd name
                              
1156       obfuscation ([Arianfar2011]) among others.
                              


                              1158       Reflexive forwarding does not change the overa=
ll landscape of privacy
                              
1159       tradeoffs, nor seem to introduce additional hazards.  In fact,=
 the
                              
1160       privacy exposures are confined to the inverse path of forwarde=
rs from
                              
1161       the producer to the consumer, through which the original Inter=
est
                              
1162       forwarding may have already exposed names on path.  Similar na=
me
                              
1163       privacy techniques to those cited above may be equally applied=
 to the
                              
1164       names in reflexive Interests.
                              


                              1166       While the individual reflexive Interest-Data e=
xchanges have similar
                              
1167       properties to those in any NDN or CCNx exchange, the target us=
ages by
                              
1168       applications may have interaction patterns that are subject to=

                              
1169       relatively straightforward fingerprinting by adversaries.  For=

                              
1170       example, a particular RMI invocation may fingerprint simply th=
rough
                              
1171       the count of arguments fetched by the producer and their sizes=
=2E  The
                              
1172       attacker must however be on path, which somewhat ameliorates t=
he
                              
1173       exposure hazards.
                              


                              1175    13.  Normative References
                              


                              1177       [RFC2119]  Bradner, S., "Key words for use in =
RFCs to Indicate
                              
1178                  Requirement Levels", BCP 14, RFC 2119,
                              
1179                  DOI 10.17487/RFC2119, March 1997,
                              
1180                  https://www.rfc-editor.org/info/rfc2119.
                              =



                              1182       [RFC8569]  Mosko, M., Solis, I., and C. Wood, =
"Content-Centric
                              
1183                  Networking (CCNx) Semantics", RFC 8569,
                              
1184                  DOI 10.17487/RFC8569, July 2019,
                              
1185                  https://www.rfc-editor.org/info/rfc8569.
                              =



                              1187       [RFC8609]  Mosko, M., Solis, I., and C. Wood, =
"Content-Centric
                              
1188                  Networking (CCNx) Messages in TLV Format", RFC 8609=
,
                              
1189                  DOI 10.17487/RFC8609, July 2019,
                              
1190                  https://www.rfc-editor.org/info/rfc8609.
                              =



                              1192    14.  Informative References
                              


                              1194       [Arianfar2011]
                              
1195                  Arianfar, S., Koponen, T., Raghavan, B., and S. She=
nker,
                              
1196                  "On preserving privacy in content-oriented networks=
, in
                              
1197                  ICN '11: Proceedings of the ACM SIGCOMM workshop on=

                              
1198                  Information-centric networking",
                              
1199                  DOI https://doi.org/10.1145/2018584.2018589,=
 August 2011,
                              
1200                  https://dl.acm.org/doi/10.1145/2018584.20=
18589.
                              


                              1202       [Auge2018] Aug=C3=A9, J., Carofiglio, G., Gras=
si, G., Muscariello, L.,
                              
1203                  Pau, G., and X. Zeng, "MAP-Me: Managing Anchor-Less=

                              
1204                  Producer Mobility in Content-Centric Networks, in I=
EEE
                              
1205                  Transactions on Network, Volume 15, Issue 2",
                              
1206                  DOI 10.1109/TNSM.2018.2796720, June 2018,
                              
1207                  https://ieeexplore.ieee.org/document/826713=
2.
                              


                              1209       [Baccelli2014]
                              
1210                  Baccelli, E., Mehlis, C., Hahm, O., Schmidt, T., an=
d M.
                              
1211                  W=C3=A4hlisch, "Information centric networking in t=
he IoT:
                              
1212                  experiments with NDN in the wild, in ACM-ICN '14:
1213                  Proceedings of the 1st ACM Conference on Informatio=
n-
                              
1214                  Centric Networking", DOI 10.1145/2660129.2660144,
1215                  September 2014,
                              
1216                  https://dl.acm.org/doi/abs/10.1145/26=
60129.2660144.
                              


                              1218       [Carzaniga2011]
                              
1219                  Carzaniga, A., Papalini, M., and A.L. Wolf, "Conten=
t-Based
                              
1220                  Publish/Subscribe Networking and Information-Centri=
c
                              
1221                  Networking", DOI 10.1145/2018584.2018599, September=
 2011,
                              
1222                  <https://conferences.sigcomm.org/sigcomm/2011/pa=
pers/icn/
                              
1223                  p56.pdf>.
                              


                              1225       [Chen2015] Chen, S., Cao, J., and L. Zhu, "NDS=
S: A Named Data Storage
                              
1226                  System, in International Conference on Cloud and Au=
tonomic
                              
1227                  Computing", DOI 10.1109/ICCAC.2015.12, September 20=
14,
                              
1228                  https://ieeexplore.ieee.org/document/731215=
4.
                              


                              1230       [DiBenedettoGTU12]
                              
1231                  DiBenedetto, S., Gasti, P., Tsudik, G., and E. Uzun=
,
                              
1232                  "ANDaNA: Anonymous Named Data Networking Applicatio=
n, in
                              
1233                  NDSS 2012", DOI https://arxiv.org/abs/1112.2205v2,=
 2102,
                              
1234                  <https://www.ndss-symposium.org/ndss2012/andana-=
anonymous-
                              
1235                  named-data-networking-application>.
                              


                              1237       [Gasti2012]
                              
1238                  Gasti, P., Tsudik, G., Uzun, Ersin., and L. Zhang, =
"DoS
                              
1239                  and DDoS in Named Data Networking, in 22nd Internat=
ional
                              
1240                  Conference on Computer Communication and Networks
1241                  (ICCCN)", DOI 10.1109/ICCCN.2013.6614127, August 20=
13,
                              
1242                  https://ieeexplore.ieee.org/document/661412=
7.
                              


                              1244       [Ghali2017]
                              
1245                  Tsudik, G., Ghali, C., and C. Wood, "When encryptio=
n is
                              
1246                  not enough: privacy attacks in content-centric netw=
orking,
                              
1247                  in ICN '17: Proceedings of the 4th ACM Conference o=
n
                              
1248                  Information-Centric Networking",
                              
1249                  DOI https://doi.org/10.1145/3125719.3125723,=
 September
                              
1250                  2017,
                              
1251                  https://dl.acm.org/doi/abs/10.1145/31=
25719.3125723.
                              


                              1253       [Gundogan2018]
                              
1254                  G=C3=BCndo=C4=9Fan, C., Kietzmann, P., Schmidt, T.,=
 and M. W=C3=A4hlisch,
                              
1255                  "HoPP: publish-subscribe for the constrained IoT, i=
n ICN
                              
1256                  '18: Proceedings of the 5th ACM Conference on Infor=
mation-
                              
1257                  Centric Networking", DOI 10.1145/3267955.3269020,
1258                  September 2018,
                              
1259                  https://dl.acm.org/doi/abs/10.1145/32=
67955.3269020.
                              


                              1261       [I-D.irtf-icnrg-flic]
                              
1262                  Tschudin, C., Wood, C., Mosko, M., and D. Oran, "Fi=
le-Like
                              
1263                  ICN Collections (FLIC)", Work in Progress, Internet=
-Draft,
                              
1264                  draft-irtf-icnrg-flic-02, 4 November 2019,
                              
1265                  https://tools.ietf.org/html/draft-i=
rtf-icnrg-flic-02.
                              


                              1267       [I-D.irtf-icnrg-terminology]
                              
1268                  Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., O=
ran,
                              
1269                  D., and C. Tschudin, "Information-Centric Networkin=
g
                              
1270                  (ICN): CCNx and NDN Terminology", Work in Progress,=

                              
1271                  Internet-Draft, draft-irtf-icnrg-terminology-08, 17=

                              
1272                  January 2020, <https://tools.ietf.org/html/draft=
-irtf-
                              
1273                  icnrg-terminology-08>.
                              


                              1275       [I-D.oran-icnrg-pathsteering]
                              
1276                  Moiseenko, I. and D. Oran, "Path Steering in CCNx a=
nd
                              
1277                  NDN", Work in Progress, Internet-Draft, draft-oran-=
icnrg-
                              
1278                  pathsteering-00, 21 October 2019,
                              
1279                  <https://tools.ietf.org/html/draft-oran-icnrg-
1280                  pathsteering-00>.
                              


                              1282       [Krol2018] Krol, M., Habak, K., Oran, D., Kuts=
cher, D., and I.
                              
1283                  Psaras, "RICE: Remote Method Invocation in ICN, in<=
br>
1284                  Proceedings of the 5th ACM Conference on Informatio=
n-
                              
1285                  Centric Networking - ICN '18",
                              
1286                  DOI 10.1145/3267955.3267956, September 2018,
                              
1287                  <https://conferences.sigcomm.org/acm-icn/2018/pr=
oceedings/
                              
1288                  icn18-final9.pdf>.
                              


                              1290       [Lindgren2016]
                              
1291                  Lindgren, A., Ben Abdessiem, F., Ahlgren, B., Schle=
l=C3=A9n,
                              
1292                  O., and A.M. Malik, "Design choices for the IoT in<=
br>
1293                  Information-Centric Networks, in 13th IEEE Annual C=
onsumer
                              
1294                  Communications and Networking Conference (CCNC)",
1295                  DOI 10.1109/CCNC.2016.7444905, January 2016,
                              
1296                  https://ieeexplore.ieee.org/abstra=
ct/document/7444905.
                              


                              1298       [Moiseenko2014]
                              
1299                  Moiseenko, I., Stapp, M., and D. Oran, "Communicati=
on
                              
1300                  patterns for web interaction in named data networki=
ng",
                              
1301                  DOI 10.1145/2660129.2660152, September 2014,
                              
1302                  https://dl.acm.org/doi/10.1145/2660129.26=
60152.
                              


                              1304       [Mosko2017]
                              
1305                  Mosko, M., "CCNx 1.0 Bidirectional Streams",
                              
1306                  arXiv 1707.04738, July 2017,
                              
1307                  https://arxiv.org/abs/1707.04738.
                              


                              1309       [NDN]      "Named Data Networking", 2020,
                              
1310                  https://named-data.net/project/execsummary/<=
/a>.
                              


                              1312       [NDNTLV]   "NDN Packet Format Specification", =
2016,
                              
1313                                                http://named-data.net/doc/ndn-tlv/.
                              


                              1315       [RFC3261]  Rosenberg, J., Schulzrinne, H., Cam=
arillo, G., Johnston,
                              
1316                  A., Peterson, J., Sparks, R., Handley, M., and E.
1317                  Schooler, "SIP: Session Initiation Protocol", RFC 3=
261,
                              
1318                  DOI 10.17487/RFC3261, June 2002,
                              
1319                  https://www.rfc-editor.org/info/rfc3261.
                              =



                              1321       [RFC6337]  Okumura, S., Sawada, T., and P. Kyz=
ivat, "Session
                              
1322                  Initiation Protocol (SIP) Usage of the Offer/Answer=

                              
1323                  Model", RFC 6337, DOI 10.17487/RFC6337, August 2011=
,
                              
1324                  https://www.rfc-editor.org/info/rfc6337.
                              =



                              1326       [RFC7530]  Haynes, T., Ed. and D. Noveck, Ed.,=
 "Network File System
                              
1327                  (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/R=
FC7530,
                              
1328                  March 2015, https://www.rfc-editor.org/info/rfc7=
530.
                              


                              1330       [RFC8446]  Rescorla, E., "The Transport Layer =
Security (TLS) Protocol
                              
1331                  Version 1.3", RFC 8446, DOI 10.17487/RFC8446, Augus=
t 2018,
                              
1332                  https://www.rfc-editor.org/info/rfc8446.
                              =



                              1334       [Zhang2018]
                              
1335                  Zhang, Y., Xia, Z., Mastorakis, S., and L. Zhang, "=
KITE:
                              
1336                  Producer Mobility Support in Named Data Networking,=
 in
                              
1337                  Proceedings of the 5th ACM Conference on Informatio=
n-
                              
1338                  Centric Networking - ICN '18",
                              
1339                  DOI 10.1145/3267955.3267959, September 2018,
                              
1340                  <https://conferences.sigcomm.org/acm-icn/2018/pr=
oceedings/
                              
1341                  icn18-final23.pdf>.
                              


                              1343    Authors' Addresses
                              


                              1345       Dave Oran
                              
1346       Network Systems Research and Design
                              
1347       4 Shady Hill Square
                              
1348       Cambridge, MA 02138
                              
1349       United States of America
                              


                              1351       Email: daveoran@orandom.net
                              


                              1353       Dirk Kutscher
                              
1354       University of Applied Sciences Emden/Leer
                              
1355       Constantiapl. 4
                              
1356       26723 Emden
                              
1357       Germany
                              


                              1359       Email: ietf@dkutscher.net
                              
1360       URI:   https://dirk-kutscher.info
                              


                              DaveO
                              

                              

                              



--=_MailMate_6C591296-A53D-47D1-9720-24A9F0D96BCE_=--

--=_MailMate_5F5F5079-90CD-440B-AFDE-4B4D9EE2DACF_=
Content-Disposition: attachment;
 filename=draft-oran-icnrg-reflexive-forwarding.xml
Content-Type: application/xml
Content-Transfer-Encoding: base64

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0
eXBlPSJ0ZXh0L3hzbCIgaHJlZj0icmZjMjYyOS54c2x0IiA/Pgo8P3JmYyBzdHJpY3Q9InllcyIg
Pz4KPD9yZmMgY29tcGFjdD0ieWVzIiA/Pgo8P3JmYyBzdWJjb21wYWN0PSJubyIgPz4KPCEtLSB4
bWw6bGFuZz0iZW4iIHhtbG5zOnhpPSJodHRwczovL3d3dy53My5vcmcvMjAwMS9YSW5jbHVkZSIg
LS0+Cgo8cmZjCiAgICB2ZXJzaW9uPSIzIgogICAgaXByPSJ0cnVzdDIwMDkwMiIKICAgIGRvY05h
bWU9ImRyYWZ0LW9yYW4taWNucmctcmVmbGV4aXZlLWZvcndhcmRpbmctMDAiCiAgICBjYXRlZ29y
eT0iZXhwIgogICAgc3VibWlzc2lvblR5cGU9IklSVEYiCiAgICB1cGRhdGVzPSI4NTY5LCA4NjA5
IgogICAgY29uc2Vuc3VzPSJmYWxzZSIKICAgIHNvcnRSZWZzPSJ0cnVlIgogICAgc3ltUmVmcz0i
dHJ1ZSIKICAgIHRvY0RlcHRoPSI0Ij4KCiAgPGZyb250PgoKICAgIDx0aXRsZSBhYmJyZXY9IklD
TiBSZWZsZXhpdmUgRm9yd2FyZGluZyI+CiAgICBSZWZsZXhpdmUgRm9yd2FyZGluZyBmb3IgQ0NO
eCBhbmQgTkROIFByb3RvY29sczwvdGl0bGU+CiAgICA8c2VyaWVzSW5mbyAKICAgIAluYW1lPSJJ
bnRlcm5ldC1EcmFmdCIgCiAgICAJdmFsdWU9ImRyYWZ0LW9yYW4taWNucmctcmVmbGV4aXZlLWZv
cndhcmRpbmctMDAiLz4KCiAgICA8IS0tIGFkZCAicm9sZT0iZWRpdG9yIiIgYmVsb3cgZm9yIHRo
ZSBlZGl0b3JzIGlmIGFwcHJvcHJpYXRlIC0tPgogICAgPGF1dGhvciBmdWxsbmFtZT0iRGF2ZSBP
cmFuIiBpbml0aWFscz0iRC4iIHN1cm5hbWU9Ik9yYW4iPgogICAgICA8b3JnYW5pemF0aW9uPk5l
dHdvcmsgU3lzdGVtcyBSZXNlYXJjaCBhbmQgRGVzaWduPC9vcmdhbml6YXRpb24+CiAgICAgIDxh
ZGRyZXNzPgogICAgICAgIDxwb3N0YWw+CiAgICAgICAgICA8c3RyZWV0PjQgU2hhZHkgSGlsbCBT
cXVhcmU8L3N0cmVldD4KICAgICAgICAgIDwhLS0gUmVvcmRlciB0aGVzZSBpZiB5b3VyIGNvdW50
cnkgZG9lcyB0aGluZ3MgZGlmZmVyZW50bHkgLS0+CiAgICAgICAgICA8Y2l0eT5DYW1icmlkZ2U8
L2NpdHk+CiAgICAgICAgICA8cmVnaW9uPk1BPC9yZWdpb24+CiAgICAgICAgICA8Y29kZT4wMjEz
ODwvY29kZT4KICAgICAgICAgIDxjb3VudHJ5PlVTQTwvY291bnRyeT4KICAgICAgICA8L3Bvc3Rh
bD4KICAgICAgICA8cGhvbmU+PC9waG9uZT4KICAgICAgICA8ZW1haWw+ZGF2ZW9yYW5Ab3JhbmRv
bS5uZXQ8L2VtYWlsPgogICAgICAgIDwhLS0gdXJpIGFuZCBmYWNzaW1pbGUgZWxlbWVudHMgbWF5
IGFsc28gYmUgYWRkZWQgLS0+CiAgICAgIDwvYWRkcmVzcz4KICAgIDwvYXV0aG9yPgoKICAgIDxh
dXRob3IgZnVsbG5hbWU9IkRpcmsgS3V0c2NoZXIiIGluaXRpYWxzPSJELiIgc3VybmFtZT0iS3V0
c2NoZXIiPgogICAgICA8b3JnYW5pemF0aW9uPlVuaXZlcnNpdHkgb2YgQXBwbGllZCBTY2llbmNl
cyBFbWRlbi9MZWVyPC9vcmdhbml6YXRpb24+CiAgICAgIDxhZGRyZXNzPgogICAgICAgIDxwb3N0
YWw+CiAgICAgICAgICA8c3RyZWV0PkNvbnN0YW50aWFwbC4gNDwvc3RyZWV0PgogICAgICAgICAg
PCEtLSBSZW9yZGVyIHRoZXNlIGlmIHlvdXIgY291bnRyeSBkb2VzIHRoaW5ncyBkaWZmZXJlbnRs
eSAtLT4KICAgICAgICAgIDxjb2RlPjI2NzIzPC9jb2RlPgogICAgICAgICAgPGNpdHk+RW1kZW48
L2NpdHk+CiAgICAgICAgICA8Y291bnRyeT5HZXJtYW55PC9jb3VudHJ5PgogICAgICAgIDwvcG9z
dGFsPgogICAgICAgIDxwaG9uZT48L3Bob25lPgogICAgICAgIDxlbWFpbD5pZXRmQGRrdXRzY2hl
ci5uZXQ8L2VtYWlsPgogICAgICAgIDx1cmk+aHR0cHM6Ly9kaXJrLWt1dHNjaGVyLmluZm88L3Vy
aT4KICAgICAgPC9hZGRyZXNzPgogICAgPC9hdXRob3I+CgogICAgPCEtLSAgICA8ZGF0ZSBtb250
aD0iTWFyY2giIHllYXI9IjIwMjAiIC8+IC0tPgoKICAgIDwhLS0gTWV0YS1kYXRhIERlY2xhcmF0
aW9ucyAtLT4KICAgIDx3b3JrZ3JvdXA+SUNOUkc8L3dvcmtncm91cD4KCiAgICA8a2V5d29yZD5J
Q048L2tleXdvcmQ+CiAgICA8a2V5d29yZD5JbmZvcm1hdGlvbi1jZW50cmljIE5ldHdvcmtpbmc8
L2tleXdvcmQ+CiAgICA8a2V5d29yZD5mb3J3YXJkaW5nPC9rZXl3b3JkPgoKICAgIDxhYnN0cmFj
dD4KICAgICAgPHQ+CglDdXJyZW50IEluZm9ybWF0aW9uLUNlbnRyaWMgTmV0d29ya2luZyBwcm90
b2NvbHMgc3VjaCBhcyBDQ054CglhbmQgTkROIGhhdmUgYSB3aWRlIHJhbmdlIG9mIHVzZWZ1bCBh
cHBsaWNhdGlvbnMgaW4gY29udGVudAoJcmV0cmlldmFsIGFuZCBvdGhlciBzY2VuYXJpb3MgdGhh
dCBkZXBlbmQgb25seSBvbiBhIHJvYnVzdAoJdHdvLXdheSBleGNoYW5nZSBpbiB0aGUgZm9ybSBv
ZiBhIHJlcXVlc3QgYW5kIHJlc3BvbnNlCgkocmVwcmVzZW50ZWQgYnkgYW4gPGVtPkludGVyZXN0
LURhdGEgZXhjaGFuZ2U8L2VtPiBpbiB0aGUgY2FzZQoJb2YgdGhlIHR3byBwcm90b2NvbHMgbm90
ZWQgYWJvdmUpLiBBIG51bWJlciBvZiBpbXBvcnRhbnQKCWFwcGxpY2F0aW9ucyBob3dldmVyLCBy
ZXF1aXJlIHBsYWNpbmcgbGFyZ2UgYW1vdW50cyBvZiBkYXRhIGluCgl0aGUgSW50ZXJlc3QgbWVz
c2FnZSwgYW5kL29yIG1vcmUgdGhhbiBvbmUgdHdvLXdheQoJaGFuZHNoYWtlLiBXaGlsZSB0aGVz
ZSBjYW4gYmUgYWNjb21wbGlzaGVkIHVzaW5nIGluZGVwZW5kZW50CglJbnRlcmVzdC1EYXRhIGV4
Y2hhbmdlcyBieSByZXZlcnNpbmcgdGhlIHJvbGVzIG9mIGNvbnN1bWVyIGFuZAoJcHJvZHVjZXIs
IHN1Y2ggYXBwcm9hY2hlcyBjYW4gYmUgYm90aCBjbHVtc3kgZm9yIGFwcGxpY2F0aW9ucwoJYW5k
IHByb2JsZW1hdGljIGZyb20gYSBzdGF0ZSBtYW5hZ2VtZW50LCBjb25nZXN0aW9uIGNvbnRyb2ws
CglvciBzZWN1cml0eSBzdGFuZHBvaW50LiBUaGlzIHNwZWNpZmljYXRpb24gcHJvcG9zZXMgYQoJ
PGVtPlJlZmxleGl2ZSBGb3J3YXJkaW5nPC9lbT4gZXh0ZW5zaW9uIHRvIHRoZSBDQ054IGFuZCBO
RE4KCXByb3RvY29sIGFyY2hpdGVjdHVyZXMgdGhhdCBlbGltaW5hdGVzIHRoZSBwcm9ibGVtcyBp
bmhlcmVudAoJaW4gdXNpbmcgaW5kZXBlbmRlbnQgSW50ZXJlc3QtRGF0YSBleGNoYW5nZXMgZm9y
IHN1Y2gKCWFwcGxpY2F0aW9ucy4gSXQgdXBkYXRlcyBSRkM4NTY5IGFuZCBSRkM4NjA5LgogICAg
ICA8L3Q+CiAgICA8L2Fic3RyYWN0Pgo8L2Zyb250PgoKPG1pZGRsZT4KICA8c2VjdGlvbiBhbmNo
b3I9ImludHJvIj48bmFtZT5JbnRyb2R1Y3Rpb248L25hbWU+CiAgPHQ+CiAgICBDdXJyZW50IElD
TiBwcm90b2NvbHMgc3VjaCBhcyA8eHJlZiB0YXJnZXQ9IlJGQzg1NjkiPkNDTng8L3hyZWY+CiAg
ICBhbmQgPHhyZWYgdGFyZ2V0PSJORE4iPk5ETjwveHJlZj4gaGF2ZSBhIHdpZGUgcmFuZ2Ugb2Yg
dXNlZnVsCiAgICBhcHBsaWNhdGlvbnMgaW4gY29udGVudCByZXRyaWV2YWwgYW5kIG90aGVyIHNj
ZW5hcmlvcyB0aGF0IGRlcGVuZAogICAgb25seSBvbiBhIHJvYnVzdCB0d28td2F5IGV4Y2hhbmdl
IGluIHRoZSBmb3JtIG9mIGEgcmVxdWVzdCBhbmQKICAgIHJlc3BvbnNlLiBUaGVzZSBJQ04gYXJj
aGl0ZWN0dXJlcyB1c2UgdGhlIHRlcm1zICJjb25zdW1lciIgYW5kCiAgICAicHJvZHVjZXIiIGZv
ciB0aGUgcmVzcGVjdGl2ZSByb2xlcyBvZiB0aGUgcmVxdWVzdGVyIGFuZCB0aGUKICAgIHJlc3Bv
bmRlciwgYW5kIHRoZSBwcm90b2NvbHMgZGlyZWN0bHkgY2FwdHVyZSB0aGUgbWVjaGFuaWNzIG9m
IHRoZQogICAgdHdvLXdheSBleGNoYW5nZSB0aHJvdWdoIHRoZSAiSW50ZXJlc3QgbWVzc2FnZSIg
Y2FycnlpbmcgdGhlCiAgICByZXF1ZXN0LCBhbmQgdGhlICJEYXRhIG1lc3NhZ2UiIGNhcnJ5aW5n
IHRoZSByZXNwb25zZS4gVGhyb3VnaAogICAgdGhlc2UgY29uc3RydWN0cywgdGhlIHByb3RvY29s
cyBhcmUgaGVhdmlseSBiaWFzZWQgdG93YXJkIGEgcHVyZQogICAgPGVtPnB1bGwtYmFzZWQ8L2Vt
PiBpbnRlcmFjdGlvbiBtb2RlbCB3aGVyZSByZXF1ZXN0cyBhcmUgc21hbGwKICAgIChjYXJyeWlu
ZyBsaXR0bGUgb3Igbm8gdXNlci1zdXBwbGllZCBkYXRhIG90aGVyIHRoYW4gdGhlIG5hbWUgb2YK
ICAgIHRoZSByZXF1ZXN0ZWQgZGF0YSBvYmplY3QpLCBhbmQgcmVzcG9uc2VzIGFyZSByZWxhdGl2
ZWx5IGxhcmdlIC0KICAgIHVwIHRvIGFuIGFyY2hpdGVjdHVyZS1kZWZpbmVkIG1heGltdW0gdHJh
bnNtaXNzaW9uIHVuaXQgKE1UVSkgb24KICAgIHRoZSBvcmRlciBvZiBraWxvYnl0ZXMgb3IgdGVu
cyBvZiBraWxvYnl0ZXMuCiAgPC90PgoKICA8dD4KICAgIEEgbnVtYmVyIG9mIGltcG9ydGFudCBh
cHBsaWNhdGlvbnMgaG93ZXZlciByZXF1aXJlIGludGVyYWN0aW9uCiAgICBtb2RlbHMgbW9yZSBj
b21wbGV4IHRoYW4gaW5kaXZpZHVhbCByZXF1ZXN0L3Jlc3BvbnNlIGludGVyYWN0aW9ucwogICAg
aW4gdGhlIHNhbWUgZGlyZWN0aW9uIChpLmUuIGJldHdlZW4gdGhlIHNhbWUgY29uc3VtZXIgYW5k
IG9uZSBvcgogICAgbW9yZSBwcm9kdWNlcnMpLiBBbW9uZyB0aGVzZSB3ZSBpZGVudGlmeSB0aHJl
ZSBpbXBvcnRhbnQgY2xhc3NlcwogICAgd2hpY2ggYXJlIHRoZSB0YXJnZXQgb2YgdGhlIHByb3Bv
c2VkIGVuaGFuY2VtZW50cyBkZWZpbmVkIGluIHRoaXMKICAgIHNwZWNpZmljYXRpb24uIFRoZXNl
IGFyZSBkZXNjcmliZWQgaW4gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGhzLgogIDwvdD4KICA8ZGw+
CiAgICA8ZHQ+PHN0cm9uZz5SZW1vdGUgTWV0aG9kIEludm9jYXRpb24gKFJNSSwgYWthIFJQQyk6
PC9zdHJvbmc+PC9kdD4KICAgIDxkZD4KICAgICAgV2hlbiBpbnZva2luZyBhIHJlbW90ZSBtZXRo
b2QsIGl0IGlzIGNvbW1vbiBmb3IgdGhlIG1ldGhvZCB0bwogICAgICByZXF1aXJlIGFyZ3VtZW50
cyBzdXBwbGllZCBieSB0aGUgY2FsbGVyLiBJbiBjb252ZW50aW9uYWwgVENQL0lQCiAgICAgIHN0
eWxlIHByb3RvY29scyBsaWtlIENPUkJBIG9yIEhUVFAgIlBvc3QiLCB0aGVzZSBhcmUgcHVzaGVk
IHRvCiAgICAgIHRoZSBzZXJ2ZXIgYXMgcGFydCBvZiB0aGUgbWVzc2FnZSBvciBtZXNzYWdlcyB0
aGF0IGNvbXByaXNlIHRoZQogICAgICByZXF1ZXN0LiBJbiBJQ04tc3R5bGUgcHJvdG9jb2xzIHRo
ZXJlIGlzIGFuIHVuYXR0cmFjdGl2ZSBjaG9pY2UKICAgICAgYmV0d2VlbiBpbmZsYXRpbmcgdGhl
IHJlcXVlc3QgaW5pdGlhdGlvbiB3aXRoIHB1c2hlZCBhcmd1bWVudHMsCiAgICAgIG9yIGFycmFu
Z2luZyB0byBoYXZlIG9uZSBvciBtb3JlIGluZGVwZW5kZW50IHJlcXVlc3QvcmVzcG9uc2VzCiAg
ICAgIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gZm9yIHRoZSBzZXJ2ZXIgdG8gZmV0Y2ggdGhl
CiAgICAgIGFyZ3VtZW50cy4gQm90aCBvZiB0aGVzZSBhcHByb2FjaGVzIGhhdmUgc3Vic3RhbnRp
YWwKICAgICAgZGlzYWR2YW50YWdlcy4gUmVjZW50bHksIGEgdmlhYmxlIGFsdGVybmF0aXZlIGVt
ZXJnZWQgdGhyb3VnaAogICAgICB0aGUgd29yayBvbiA8eHJlZiB0YXJnZXQ9Iktyb2wyMDE4Ij5S
SUNFPC94cmVmPiB3aGljaCBwaW9uZWVyZWQKICAgICAgdGhlIG1haW4gZGVzaWduIGVsZW1lbnRz
IHByb3Bvc2VkIGluIHRoaXMgc3BlY2lmaWNhdGlvbi4KICAgIDwvZGQ+CiAgICA8ZHQ+PHN0cm9u
Zz5QaG9uZS1Ib21lIHNjZW5hcmlvOjwvc3Ryb25nPjwvZHQ+CiAgICA8ZGQ+CiAgICAgIEFwcGxp
Y2F0aW9ucyBpbiBzZW5zaW5nLCBJbnRlcm5ldC1vZi10aGluZ3MgKElvVCkgYW5kIG90aGVyCiAg
ICAgIHR5cGVzIHdoZXJlIGRhdGEgaXMgcHJvZHVjZWQgdW5wcmVkaWN0YWJseSBhbmQgbmVlZHMg
dG8gYmUKICAgICAgPGVtPnB1c2hlZDwvZW0+IHNvbWV3aGVyZSBjcmVhdGUgYSBjb251bmRydW0g
Zm9yIHRoZSBwdXJlCiAgICAgIHB1bGwtYmFzZWQgYXJjaGl0ZWN0dXJlcyBjb25zaWRlcmVkIGhl
cmUuIElmIGluc3RlYWQgb25lIGVzY2hld3MKICAgICAgcmVsYXhpbmcgdGhlIHNpemUgYXN5bW1l
dHJ5IGJldHdlZW4gcmVxdWVzdHMgYW5kIHJlc3BvbnNlcywgc29tZQogICAgICBhZGRpdGlvbmFs
IHByb3RvY29sIG1hY2hpbmVyeSBpcyBuZWVkZWQuIEVhcmxpZXIgZWZmb3J0cyBpbiB0aGUKICAg
ICAgSUNOIGNvbW11bml0eSBoYXZlIHJlY29nbml6ZWQgdGhpcyBpc3N1ZSBhbmQgZGVzaWduZWQg
bWV0aG9kcyB0bwogICAgICBwcm92b2tlIGEgY29vcGVyYXRpbmcgZWxlbWVudCB0byBpc3N1ZSBh
IHJlcXVlc3QgdG8gcmV0dXJuIHRoZQogICAgICBkYXRhIHRoZSBvcmlnaW5hdG9yIGRlc2lyZXMg
dG8gcHVzaCwgZXNzZW50aWFsbHkgInBob25pbmcgaG9tZSIKICAgICAgdG8gZ2V0IHRoZSByZXNw
b25kZXIgdG8gZmV0Y2ggdGhlIGRhdGEuIE9uZSB0aGF0IGhhcyBiZWVuCiAgICAgIGV4cGxvcmVk
IHRvIHNvbWUgZXh0ZW50IGlzIHRoZSA8ZW0+SW50ZXJlc3QtSW50ZXJlc3QtRGF0YTwvZW0+CiAg
ICAgIGV4Y2hhbmdlIDx4cmVmIHRhcmdldD0iQ2FyemFuaWdhMjAxMSIvPiwgd2hlcmUgYW4gSW50
ZXJlc3QgaXMKICAgICAgc2VudCBjb250YWluaW5nIHRoZSBkZXNpcmVkIHJlcXVlc3QgYXMgZW5j
YXBzdWxhdGVkCiAgICAgIGRhdGEuIENDTngtMS4wIEJpZGlyZWN0aW9uYWwgU3RyZWFtcyA8eHJl
ZiB0YXJnZXQ9Ik1vc2tvMjAxNyIvPgogICAgICBhcmUgYWxzbyBiYXNlZCBvbiBhIHNjaGVtZSB3
aGVyZSBhbiBJbnRlcmVzdCBpcyB1c2VkIHRvIHNpZ25hbCBhCiAgICAgIG5hbWUgcHJlZml4IHRo
YXQgYSBjb25zdW1lciBoYXMgcmVnaXN0ZXJlZCBmb3IgcmVjZWl2aW5nCiAgICAgIEludGVyZXN0
cyBmcm9tIGEgcGVlciBpbiBhIGJpZGlyZWN0aW9uYWwgc3RyZWFtaW5nIHNlc3Npb24uCiAgICAg
IDwhLS0KICAgICAgPGNyZWYgc291cmNlPSJETyI+SSB0cmllZCB0byBmaW5kIGEKICAgICAgcmVm
ZXJlbmNlIGZvciBJbnRlcmVzdC1JbnRlcmVzdC1EYXRhIHdpdGhvdXQgc3VjY2VzcyAtIGFueQog
ICAgICBpZGVhcz88L2NyZWY+IDxjcmVmCiAgICAgIHNvdXJjZT0iREtVIj5odHRwczovL2llZWV4
cGxvcmUuaWVlZS5vcmcvZG9jdW1lbnQvNzExOTc2NgogICAgICBwcm9iYWJseSAtIGNhbm5vdCBh
Y2Nlc3MgcmlnaHQgbm93IHRob3VnaDwvY3JlZj4gLS0+CiAgICA8L2RkPgogICAgPGR0PjxzdHJv
bmc+UGVlciBzdGF0ZSBzeW5jaHJvbml6YXRpb246PC9zdHJvbmc+PC9kdD4KICAgIDxkZD4KICAg
ICAgQSBsYXJnZSBjbGFzcyBvZiBhcHBsaWNhdGlvbnMsIHR5cGlmaWVkIGJ5IHRob3NlIGJ1aWx0
IG9uIHRvcCBvZgogICAgICBvbiByZWxpYWJsZSBvcmRlci1wcmVzZXJ2aW5nIHRyYW5zcG9ydCBw
cm90b2NvbHMsIHJlcXVpcmUKICAgICAgaW5pdGlhbCBzdGF0ZSBzeW5jaHJvbml6YXRpb24gYmV0
d2VlbiB0aGUgcGVlcnMuIFRoaXMgaXMKICAgICAgYWNjb21wbGlzaGVkIHdpdGggYSB0aHJlZS13
YXkgKG9yIGxvbmdlcikgaGFuZHNoYWtlLCBzaW5jZQogICAgICBlbXBsb3lpbmcgYSB0d28td2F5
IGhhbmRzaGFrZSBhcyBwcm92aWRlZCBpbiB0aGUgZXhpc3RpbmcgTkROCiAgICAgIGFuZCBDQ054
IHByb3RvY29scyBleHBvc2VzIGEgbnVtYmVyIG9mIHdlbGwta25vdyBoYXphcmRzLCBzdWNoCiAg
ICAgIGFzIDxlbT5oYWxmLW9wZW4gY29ubmVjdGlvbnM8L2VtPi4gV2hlbiBhdHRlbXB0ZWQgZm9y
CiAgICAgIHNlY3VyaXR5LXJlbGF0ZWQgb3BlcmF0aW9ucyBzdWNoIGFzIGtleSBleGNoYW5nZSwg
YWRkaXRpb25hbAogICAgICBoYXphcmRzIHN1Y2ggYXMgPGVtPm1hbi1pbi10aGUtbWlkZGxlPC9l
bT4gYXR0YWNrcyBiZWNvbWUKICAgICAgdHJpdmlhbCB0byBtb3VudC4gRXhpc3RpbmcgYWx0ZXJu
YXRpdmVzLCBzaW1pbGFyIHRvIHRob3NlIHVzZWQKICAgICAgaW4gdGhlIHR3byBleGFtcGxlcyBh
Ym92ZSwgaW5zdGVhZCB1dGlsaXplIGVpdGhlciBvdmVybGFwcGluZwogICAgICBJbnRlcmVzdC1E
YXRhIGV4Y2hhbmdlcyBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zIChyZXN1bHRpbmcgaW4gYQogICAg
ICBmb3VyLXdheSBoYW5kc2hha2UpIG9yIGJ5IGFkZGluZyBpbml0aWFsaXphdGlvbiBkYXRhIHRv
IHRoZQogICAgICBpbml0aWFsIHJlcXVlc3QgYW5kIGVtcGxveWluZyBhbiBJbnRlcmVzdC1JbnRl
cmVzdC1EYXRhIHByb3RvY29sCiAgICAgIGV4dGVuc2lvbiBhcyBub3RlZCBpbiB0aGUgUGhvbmUt
aG9tZSBzY2VuYXJpb3MgYWJvdmUuCiAgICA8L2RkPgogIDwvZGw+CiAgPHQ+CiAgICBBbGwgb2Yg
dGhlIGFib3ZlIGFwcGxpY2F0aW9uIGludGVyYWN0aW9uIG1vZGVscyBwcmVzZW50CiAgICBpbnRl
cmVzdGluZyBjaGFsbGVuZ2VzLCBhcyBuZWl0aGVyIHJlbGF4aW5nIHRoZSBhcmNoaXRlY3R1cmUg
dG8KICAgIHN1cHBvcnQgcHVzaGluZyBsYXJnZSBhbW91bnRzIG9mIGRhdGEsIG5vciBpbnRyb2R1
Y2luZyBzdWJzdGFudGlhbAogICAgY29tcGxleGl0aWVzIHRocm91Z2ggbXVsdGlwbGUgaW5kZXBl
bmRlbnQgSW50ZXJlc3QtRGF0YSBleGNoYW5nZXMKICAgIGlzIGFuIGF0dHJhY3RpdmUgYXBwcm9h
Y2guIFRoZSBmb2xsb3dpbmcgc3Vic2VjdGlvbnMgcHJvdmlkZQogICAgZnVydGhlciBiYWNrZ3Jv
dW5kIGFuZCBqdXN0aWZpY2F0aW9uIGZvciB3aHkgcHVzaCBhbmQvb3IKICAgIGluZGVwZW5kZW50
IGV4Y2hhbmdlcyBhcmUgcHJvYmxlbWF0aWNhbC4KICA8L3Q+CgogIDxzZWN0aW9uIGFuY2hvcj0i
cHVzaC1wcm9ibGVtcyI+PG5hbWU+UHJvYmxlbXMgd2l0aCBwdXNoaW5nIGRhdGE8L25hbWU+Cgog
IDx0PgogICAgVGhlcmUgYXJlIHR3byBzdWJzdGFudGlhbCBwcm9ibGVtcyB3aXRoIHRoZSBzaW1w
bGUgYXBwcm9hY2ggb2YKICAgIGp1c3QgYWxsb3dpbmcgYXJiaXRyYXJ5IGFtb3VudHMgb2YgZGF0
YSB0byBiZSBpbmNsdWRlZCB3aXRoCiAgICByZXF1ZXN0cy4gVGhlc2UgYXJlOgogIDwvdD4KICAg
PG9sPgogICAgIDxsaT4KICAgICAgIEluIElDTiBwcm90b2NvbHMsIEludGVyZXN0IG1lc3NhZ2Vz
IGFyZSBpbnRlbmRlZCB0byBiZSBzbWFsbCwKICAgICAgIG9uIHRoZSBvcmRlciB0aGUgc2l6ZSBv
ZiBhIFRDUCBBQ0ssIGFzIG9wcG9zZWQgdG8gdGhlIHNpemUgb2YgYQogICAgICAgVENQIGRhdGEg
c2VnbWVudC4gVGhpcyBpcyBiZWNhdXNlIHRoZSBob3AtYnktaG9wIGNvbmdlc3Rpb24KICAgICAg
IGNvbnRyb2wgYW5kIGZvcndhcmRlciBzdGF0ZSBtYW5hZ2VtZW50IHJlcXVpcmVzIEludGVyZXN0
CiAgICAgICBtZXNzYWdlcyB0byBiZSBidWZmZXJlZCBpbiBleHBlY3RhdGlvbiBvZiByZXR1cm5p
bmcgZGF0YSwgYW5kCiAgICAgICBwb3NzaWJseSByZXRyYW5zbWl0dGVkIGhvcC1ieS1ob3AgYXMg
b3Bwb3NlZCB0byBlbmQtdG8tZW5kLiBJbgogICAgICAgYWRkaXRpb24sIHRoZSBuZWVkIHRvIGNy
ZWF0ZSBhbmQgbWFuYWdlIHN0YXRlIG9uIGEgcGVyLUludGVyZXN0CiAgICAgICBiYXNpcyBpcyBz
dWJzdGFudGlhbGx5IGNvbXBsaWNhdGVkIGlmIHJlcXVlc3RzIGluIEludGVyZXN0CiAgICAgICBt
ZXNzYWdlcyBhcmUgbGFyZ2VyIHRoYW4gYSBQYXRoIE1UVSAoUE1UVSkgYW5kIG5lZWQgdG8gYmUK
ICAgICAgIGZyYWdtZW50ZWQgaG9wLWJ5LWhvcC4KICAgICA8L2xpPgoKICAgICA8bGk+CiAgICAg
ICBJZiB0aGUgcGF5bG9hZCBkYXRhIG9mIGEgcmVxdWVzdCBpcyB1c2VkIGZvciBpbnZva2luZyBh
CiAgICAgICBjb21wdXRhdGlvbiAoYXMgaW4gdGhlIFJNSSBjYXNlIGRlc2NyaWJlZCBhYm92ZSkK
ICAgICAgIHRoZW4gc3Vic3RhbnRpYWwgYmFuZHdpZHRoIGNhbiBiZSB3YXN0ZWQgaWYgdGhlIGNv
bXB1dGF0aW9uIGlzCiAgICAgICBlaXRoZXIgcmVmdXNlZCBvciBhYmFuZG9uZWQgZm9yIGFueSBu
dW1iZXIgb2YgcmVhc29ucywKICAgICAgIGluY2x1ZGluZyB0aGUgcmVxdWVzdG9yIGZhaWxpbmcg
YW4gYXV0aG9yaXphdGlvbiBjaGVjaywgb3IgdGhlCiAgICAgICByZXNwb25kZXIgbm90IGhhdmlu
ZyBzdWZmaWNpZW50IHJlc291cmNlcyB0byBleGVjdXRlIHRoZQogICAgICAgYXNzb2NpYXRlZCBj
b21wdXRhdGlvbi4KICAgICA8L2xpPgogICA8L29sPgoKICAgPHQ+CiAgICAgVGhlc2UgcHJvYmxl
bXMgYWxzbyBleGlzdCBpbiBwdXJlIGRhdGFncmFtIHRyYW5zcG9ydCBwcm90b2NvbHMKICAgICBz
dWNoIGFzIHRob3NlIHVzZWQgZm9yIGxlZ2FjeSBSTUkgYXBwbGljYXRpb25zIGxpa2UgPHhyZWYK
ICAgICB0YXJnZXQ9IlJGQzc1MzAiPk5GUzwveHJlZj4uIE1vcmUgdXN1YWwgYXJlIGFwcGxpY2F0
aW9uIHByb3RvY29scwogICAgIGxpa2UgSFRUUChzKSB3aGljaCByZWx5IG9uIHRoZSBUQ1Agb3Ig
UVVJQyAzLXdheSBoYW5kc2hha2UgdG8KICAgICBlc3RhYmxpc2ggYSBzZXNzaW9uIGFuZCB0aGVu
IGhhdmUgY29uZ2VzdGlvbiBjb250cm9sIGFuZAogICAgIHNlZ21lbnRhdGlvbiBwcm92aWRlZCBh
cyBwYXJ0IG9mIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wsIGZ1cnRoZXIKICAgICBhbGxvd2luZyBz
ZXNzaW9ucyB0byBiZSByZWplY3RlZCBiZWZvcmUgbGFyZ2UgYW1vdW50cyBvZiBkYXRhIGFyZQog
ICAgIHRyYW5zbWl0dGVkIG9yIHNpZ25pZmljYW50IGNvbXB1dGF0aW9uYWwgcmVzb3VyY2VzIGV4
cGVuZGVkLgogICA8L3Q+CiAgPC9zZWN0aW9uPgoKICA8c2VjdGlvbiBhbmNob3I9ImluZGVwZW5k
ZW50LWV4Y2hhbmdlLXByb2JsZW1zIj4KICA8bmFtZT5Qcm9ibGVtcyB3aXRoIHV0aWxpemluZyBp
bmRlcGVuZGVudCBleGNoYW5nZXM8L25hbWU+CiAgPHQ+CiAgICBJbiBvcmRlciB0byBlaXRoZXIg
Y29tcGxldGUgYSB0aHJlZS13YXkgaGFuZHNoYWtlLCBvciBmZXRjaCBkYXRhCiAgICB2aWEgYSBw
dWxsIGZyb20gdGhlIG9yaWdpbmFsIHJlcXVlc3RvciwgdGhlIHJvbGUgb2YgY29uc3VtZXIgYW5k
CiAgICBwcm9kdWNlciBuZWVkIHRvIGJlIHJldmVyc2VkIGFuZCBhbiBJbnRlcmVzdC9EYXRhIGV4
Y2hhbmdlCiAgICBpbml0aWF0ZWQgaW4gdGhlIGRpcmVjdGlvbiBvcHBvc2l0ZSBvZiB0aGUgaW5p
dGlhdGluZwogICAgZXhjaGFuZ2UuIFdoZW4gZG9uZSB3aXRoIGFuIGluZGVwZW5kZW50IEludGVy
ZXN0L0RhdGEgcmVxdWVzdCBhbmQKICAgIHJlc3BvbnNlLCBhIG51bWJlciBvZiBjb21wbGljYXRp
b25zIGVuc3VlLiBBbW9uZyB0aGVtIGFyZToKICA8L3Q+CiAgPG9sPgogICAgPGxpIGFuY2hvcj0i
cm91dGFibGUtbmFtZS1wcmVmaXgiPgogICAgICBUaGUgb3JpZ2luYXRpbmcgY29uc3VtZXIgbmVl
ZHMgdG8gaGF2ZSBhIHJvdXRhYmxlIG5hbWUgcHJlZml4CiAgICAgIHRoYXQgY2FuIGJlIHVzZWQg
Zm9yIHRoZSBleGNoYW5nZS4gVGhpcyBtZWFucyB0aGUgY29uc3VtZXIgbXVzdAogICAgICBhcnJh
bmdlIHRvIGhhdmUgaXRzIG5hbWUgcHJlZml4IHByb3BhZ2F0ZWQgaW4gdGhlIElDTiByb3V0aW5n
IHN5c3RlbQogICAgICB3aXRoIHN1ZmZpY2llbnQgcmVhY2ggdGhhdCB0aGUgcHJvZHVjZXIgaXNz
dWluZyB0aGUgaW50ZXJlc3QgY2FuCiAgICAgIGJlIGFzc3VyZWQgaXQgaXMgcm91dGVkIGFwcHJv
cHJpYXRlbHkuIFdoaWxlIHNvbWUgY29uc3VtZXJzIGFyZQogICAgICBnZW5lcmFsbHkgb25saW5l
IGFuZCBhY3QgYXMgYXBwbGljYXRpb24gc2VydmVycywganVzdGlmeWluZyB0aGUKICAgICAgbWFp
bnRlbmFuY2Ugb2YgdGhpcyByb3V0aW5nIGluZm9ybWF0aW9uLCBtYW55IGRvIG5vdC4gRnVydGhl
ciwKICAgICAgaW4gbW9iaWxlIGVudmlyb25tZW50cywgYSBwdXJlIGNvbnN1bWVyIHRoYXQgZG9l
cyBub3QgbmVlZCB0bwogICAgICBoYXZlIGEgcm91dGFibGUgbmFtZSBwcmVmaXggY2FuIGJlbmVm
aXQgZnJvbSB0aGUgaW5oZXJlbnQKICAgICAgY29uc3VtZXIgbW9iaWxpdHkgc3VwcG9ydCBpbiB0
aGUgQ0NOeCBhbmQgTkROIHByb3RvY29scy4gQnkKICAgICAgcmVxdWlyaW5nIGEgcm91dGFibGUg
bmFtZSBwcmVmaXgsIGV4dHJhIG1vYmlsZSByb3V0aW5nIG1hY2hpbmVyeQogICAgICBpcyBuZWVk
ZWQsIHN1Y2ggYXMgdGhhdCBwcm9wb3NlZCBpbiA8eHJlZgogICAgICB0YXJnZXQ9IlpoYW5nMjAx
OCI+S0lURTwveHJlZj4gb3IgPHhyZWYKICAgICAgdGFyZ2V0PSJBdWdlMjAxOCI+TUFQTUU8L3hy
ZWY+Lgo8IS0tCiAgICAgIDxlbT5Ob3RlOiBJIGNvdWxkIG5vdCBnZXQgdGhlCiAgICAgIG1hcG1l
IGludGVybmV0IGRyYWZ0IHJlZmVyZW5jZSB0byByZXNvbHZlLCBzbyBJIGFtIHVzaW5nIHRoZQog
ICAgICBJRUVFIHBhcGVyIGluc3RlYWQgZm9yIG5vdy48L2VtPgotLT4KICAgIDwvbGk+CgogICAg
PGxpIGFuY2hvcj0icmVmbGVjdGlvbi1hdHRhY2siPgogICAgICBUaGUgY29uc3VtZXIgbmFtZSBw
cmVmaXggaW4gPHhyZWYgdGFyZ2V0PSJyb3V0YWJsZS1uYW1lLXByZWZpeCIKICAgICAgZm9ybWF0
PSJjb3VudGVyIj5pdGVtPC94cmVmPiBhYm92ZSBtdXN0IGJlIGNvbW11bmljYXRlZCB0byB0aGUK
ICAgICAgcHJvZHVjZXIgYXMgYSBwYXlsb2FkLCBuYW1lIHN1ZmZpeCwgb3Igb3RoZXIgZmllbGQg
b2YgdGhlCiAgICAgIGluaXRpYXRpbmcgSW50ZXJlc3QgbWVzc2FnZS4gU2luY2UgdGhpcyBuYW1l
IGluIGl0cyBlbnRpcmV0eSBpcwogICAgICBjaG9zZW4gYnkgdGhlIGNvbnN1bWVyLCBpdCBpcyBo
aWdobHkgcHJvYmxlbWF0aWMgZnJvbSBhIHNlY3VyaXR5CiAgICAgIHN0YW5kcG9pbnQsIGFzIGl0
IGNhbiByZWNydWl0IHRoZSBwcm9kdWNlciB0byBtb3VudCBhIHJlZmxlY3Rpb24KICAgICAgYXR0
YWNrIGFnYWluc3QgdGhlIGNvbnN1bWVyJ3MgY2hvc2VuIHZpY3RpbS48IS0tICcgLS0+CiAgICA8
L2xpPgoKICAgIDxsaT4KICAgICAgVGhlIGNvcnJlbGF0aW9uIGJldHdlZW4gdGhlIGV4Y2hhbmdl
cyBpbiBvcHBvc2l0ZSBkaXJlY3Rpb25zCiAgICAgIG11c3QgYmUgbWFpbnRhaW5lZCBieSBib3Ro
IHRoZSBjb25zdW1lciBhbmQgdGhlIHByb2R1Y2VyIGFzCiAgICAgIGluZGVwZW5kZW50IHN0YXRl
LCBhcyBvcHBvc2VkIHRvIGJlaW5nIGFyY2hpdGVjdHVyYWxseSB0aWVkCiAgICAgIHRvZ2V0aGVy
IGFzIHdvdWxkIGJlIHRoZSBjYXNlIHdpdGggYSBjb252ZW50aW9uYWwgMy13YXkKICAgICAgaGFu
ZHNoYWtlIGZpbml0ZSBzdGF0ZSBtYWNoaW5lLiBXaGlsZSB0aGlzIGNhbiBvZiBjb3Vyc2UgYmUK
ICAgICAgYWNjb21wbGlzaGVkIHdpdGggY2FyZSBieSBib3RoIHBhcnRpZXMsIGV4cGVyaWVuY2Ug
aGFzIHNob3duCiAgICAgIHRoYXQgaXQgaXMgZXJyb3IgcHJvbmUgKGZvciBleGFtcGxlIHNlZSB0
aGUgY2hlY2tlcmVkIGhpc3Rvcnkgb2YKICAgICAgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlIDx4
cmVmIHRhcmdldD0iUkZDMzI2MSI+U0lQPC94cmVmPiBhbmQKICAgICAgPHhyZWYgdGFyZ2V0PSJS
RkM2MzM3Ij5TRFAgT2ZmZXItQW5zd2VyPC94cmVmPikgcHJvdG9jb2xzLiBXaGVuIGVtcGxveWVk
CiAgICAgIGFzIHRoZSB3cmFwcGVyIGZvciBhIGtleSBtYW5hZ2VtZW50IHByb3RvY29sIHN1Y2gg
YXMgd2l0aCA8eHJlZgogICAgICB0YXJnZXQ9IlJGQzg0NDYiPlRMUzwveHJlZj4gc3RhdGUgbWFu
YWdlbWVudCBlcnJvcnMgY2FuIGJlCiAgICAgIGNhdGFzdHJvcGhpYyBmb3Igc2VjdXJpdHkuCiAg
ICA8L2xpPgogIDwvb2w+Cjwvc2VjdGlvbj4KPC9zZWN0aW9uPgoKPHNlY3Rpb24+IDxuYW1lPlJl
cXVpcmVtZW50cyBMYW5ndWFnZTwvbmFtZT4KICAgICAgICA8dD4KCSAgVGhlIGtleSB3b3JkcyAi
TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAg
ICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9UIFJFQ09NTUVOREVE
IiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIAogICAgICBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBi
ZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJSRkMyMTE5Ii8+LgoJ
PC90PgogICAgICA8L3NlY3Rpb24+Cgo8c2VjdGlvbiBhbmNob3I9ImRlc2lnbi1vdmVydmlldyI+
IAo8bmFtZT5PdmVydmlldyBvZiB0aGUgUmVmbGV4aXZlIEZvcndhcmRpbmcgZGVzaWduPC9uYW1l
PgoKPHQ+CiAgVGhpcyBzcGVjaWZpY2F0aW9uIGRlZmluZXMgYSA8ZW0+UmVmbGV4aXZlIEZvcndh
cmRpbmc8L2VtPiBleHRlbnNpb24KICB0byBDQ054IGFuZCBORE4gdGhhdCBhdm9pZHMgdGhlIHBy
b2JsZW1zIGVudW1lcmF0ZWQgaW4gU2VjdGlvbnMgPHhyZWYKICB0YXJnZXQ9InB1c2gtcHJvYmxl
bXMiIGZvcm1hdD0iY291bnRlciIvPiBhbmQgPHhyZWYKICB0YXJnZXQ9ImluZGVwZW5kZW50LWV4
Y2hhbmdlLXByb2JsZW1zIiBmb3JtYXQ9ImNvdW50ZXIiLz4uIEl0IHN0cmFpZ2h0Zm9yd2FyZGx5
CiAgZXhwbG9pdHMgdGhlIGhvcC1ieS1ob3Agc3RhdGUgYW5kIHN5bW1ldHJpYyByb3V0aW5nIHBy
b3BlcnRpZXMgb2YKICB0aGUgY3VycmVudCBwcm90b2NvbHMuCjwvdD4KCjx0PgogIDx4cmVmIHRh
cmdldD0iZm9yd2FyZGVyLWRhdGEtc3RydWN0dXJlcyIvPiBiZWxvdyBpbGx1c3RyYXRlcyBhCiAg
Y2Fub25pY2FsIE5ETi9DQ054IGZvcndhcmRlciB3aXRoIGl0cyBjb25jZXB0dWFsIGRhdGEgc3Ry
dWN0dXJlcyBvZgogIHRoZSBDb250ZW50IFN0b3JlIChDUyksIFBlbmRpbmcgSW50ZXJlc3QgVGFi
bGUgKFBJVCkgYW5kIEZvcndhcmRpbmcKICBJbmZvcm1hdGlvbiBCYXNlIChGSUIpLiBUaGUga2V5
IG9ic2VydmF0aW9uIGludm9sdmVzIHRoZSByZWxhdGlvbgogIGJldHdlZW4gdGhlIFBJVCBhbmQg
dGhlIEZJQi4gVXBvbiBhcnJpdmFsIG9mIGFuIEludGVyZXN0LCBhIFBJVCBlbnRyeSAKICBpcyBj
cmVhdGVkICB3aGljaCBjb250YWlucyBzdGF0ZSByZWNvcmRpbmcgdGhlIGluY29taW5nIGludGVy
ZmFjZQogIG9uIHdoaWNoIHRoZSBJbnRlcmVzdC4gSWYgdGhlIEludGVyZXN0IGlzIG5vdCBpbW1l
ZGlhdGVseQogIHNhdGlzZmllZCBieSBjYWNoZWQgZGF0YSBpbiB0aGUgQ1MsIHRoZSBmb3J3YXJk
ZXIgbG9va3MgdXAgdGhlIG5hbWUKICBpbiB0aGUgRklCIHRvIGFzY2VydGFpbiB0aGUgPGVtPm5l
eHQtaG9wPC9lbT4gdG8gcHJvcGFnYXRlIHRoZQogIEludGVyZXN0IG9ud2FyZCB1cHN0cmVhbSB0
b3dhcmQgdGhlIG5hbWVkIHByb2R1Y2VyLiBUaGVyZWZvcmUsIGEKICBjaGFpbiBvZiBmb3J3YXJk
aW5nIHN0YXRlIGlzIGVzdGFibGlzaGVkIGR1cmluZyBJbnRlcmVzdCBmb3J3YXJkaW5nCiAgdGhh
dCBjb3VwbGVzIHRoZSBQSVQgZW50cmllcyBvZiB0aGUgY2hhaW4gb2YgZm9yd2FyZGVycyB0b2dl
dGhlcgogIGNvbmNlcHR1YWxseSBhcyA8ZW0+YnJlYWRjcnVtYnM8L2VtPi4gVGhlc2UgYXJlIHVz
ZWQgdG8gZm9yd2FyZCB0aGUKICByZXR1cm5pbmcgRGF0YSBNZXNzYWdlIG92ZXIgdGhlIGludmVy
c2UgcGF0aCB0aHJvdWdoIHRoZSBjaGFpbiBvZgogIGZvcndhcmRlcnMgdW50aWwgdGhlIERhdGEg
bWVzc2FnZSBhcnJpdmVzIGF0IHRoZSBvcmlnaW5hdGluZwogIGNvbnN1bWVyLiBUaGUgc3RhdGUg
aW4gdGhlIFBJVHMgaXMgPGVtPnVud291bmQ8L2VtPiBieSBkZXN0cm95aW5nIGl0CiAgYXMgZWFj
aCBQSVQgZW50cnkgaXMgPGVtPnNhdGlzZmllZDwvZW0+LiBUaGlzIGJlaGF2aW9yIGlzCiAgPHN0
cm9uZz5jcml0aWNhbDwvc3Ryb25nPiB0byB0aGUgZmVhc2liaWxpdHkgb2YgdGhlIHJlZmxleGl2
ZQogIGZvcndhcmRpbmcgZGVzaWduIHdlIHByb3Bvc2UuPC90PgoKCTxmaWd1cmUgYW5jaG9yPSJm
b3J3YXJkZXItZGF0YS1zdHJ1Y3R1cmVzIj4KCQk8bmFtZT5JQ04gZm9yd2FyZGVyIHN0cnVjdHVy
ZTwvbmFtZT4KCQk8IS0tIDxhcnR3b3JrIHR5cGU9InN2ZyIgc3JjPSJkYXRhLWZ3ZC1uZXctc3Zn
dC5zdmciLz4gLS0+CgkJPCEtLSA8YXJ0d29yayB0eXBlPSJzdmciIHNyYz0iaW50ZXJlc3RfZndy
LXN2Z3Quc3ZnIj48L2FydHdvcms+IC0tPgoJCTwhLS0gPGFydHdvcmsgdHlwZT0ic3ZnIiBzcmM9
ImRhdGFfZndyLXN2Z3Quc3ZnIj48L2FydHdvcms+IC0tPgoKCQk8YXJ0d29yayB0eXBlPSJhc2Np
aS1hcnQiPgogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tKwogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIElDTiBOb2RlICAgfAogfCBTZW5kIGRhdGEgdG8gYWxsICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID09PT09PT09ICAgfAogfCBpbnRlcmZhY2Vz
IHRoYXQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog
fCByZXF1ZXN0ZWQgaXQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfAogfCAgICAgICAgICAgICAgICAgIFlFUyArLS0tLS0tLS0tLS0tLS0tLS0tKyAg
ICAgICAgICAgICAgICAgICAgICAgfAombHQ7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCBQZW5k
aW5nIEludGVyZXN0IHwgICZsdDstLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHwgICAgICAgICAgICAg
IHwgICAgICAgfCAgICBUYWJsZSAoUElUKSAgIHwgICAgICAgICAgICAgICBEYXRhICAgIHwKIHwg
ICAgICAgICAgICAgIHwgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLSsgIDEpIEZpbmQgICAgIChT
aWduZWQpIHwKIHwgICAgICAgICAgICAgIHwgMikgU2F2ZSAgICAgICAgIHwgICAgICAgICAgICAg
IE5hbWUgICAgICAgICAgICAgIHwKIHwgICAgICAgICAgICAgIFYgICAgRGF0YSAgICAgICAgIHwg
Tk8gICAgICAgICAgICBpbiAgICAgICAgICAgICAgIHwKIHwgICArLS0tLS0tLS0tLS0tLS0tKyAg
ICAgICAgICAgIHwgICAgICAgICAgICAgIFBJVD8gICAgICAgICAgICAgIHwKIHwgICB8IENvbnRl
bnQgU3RvcmUgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK
IHwgICB8ICAgICAgKENTKSAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwKIHwgICArLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgIHwgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwKIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKIHwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIFYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIERyb3AgRGF0YSAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwKIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwKICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKIAkJPC9hcnR3b3JrPgoKCQk8YXJ0d29yayB0eXBl
PSJhc2NpaS1hcnQiPgogKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIElDTiBOb2RlICAgfAogfCAgICAgICAgICAgICAJICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID09PT09PT09ICAgfAogfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgfAogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArPT09PT09
PT09PT09PT09PT09PT0rfAogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB8Rm9yd2FyZGluZyBTdHJhdGVneSB8fAogfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICArPT09PT09PT09PT09PT09PT09PT0rfAogfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogfCAg
IDEpIEZpbmQgbmFtZSAgICAgICAgICAyKSBNYXRjaGluZyAgICAgICAgMykgRmluZCBtYXRjaGlu
ZyAgICAgfAogfCAgICAgICAgaW4gQ1M/ICAgICAgICAgICAgICBuYW1lIGluIFBJVD8gICAgICAg
ZW50cnkgaW4gRklCPyAgICAgfAogfCAgICAgICAgICAgICAgICAgICAgTk8gICAgICAgICAgICAg
ICAgICAgTk8gICAgICAgICAgICAgICAgICAgWUVTfAogfCAgKy0tLS0tLS0tLS0tLS0tLSsgICAr
LS0tLS0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgfAogfCAgfCBDb250ZW50
IFN0b3JlIHwgICB8ICAgUGVuZGluZyAgICAgIHwgICB8ICBGb3J3YXJkaW5nICAgICAgIHwgfAot
LS0+fCAgICAgIChDUykgICAgIHwtLT58ICAgSW50ZXJlc3QgIAkgfC0tPnwgIEluZm9ybWF0aW9u
IEJhc2UgfC0tPgogfCAgfCAgICAgICAgICAgICAgIHwgICB8ICAgVGFibGUgKFBJVCkgIHwgICB8
ICAgICAoIEZJQikgICAgICAgIHwgfAogfCAgKy0tLS0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0t
LS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLS0tLS0tLSsgfAogfCBSZXR1cm4gICB8IFlFUyAgICAg
ICAgICAgWUVTIHwgTk8gICAgICAgICAgICAgICBOTyB8ICAgICAgICAgICAgfAogfCAgRGF0YSAg
ICB8ICAgICAgICAgIEFkZCAgICAgIHwgICBBZGQgICAgICAgICAgICAgICB8ICBEcm9wICAgICAg
fAogfCAgICAgICAgICB8ICAgICAgICAgIEluY29taW5nIHwgICBuZXcgICAgICAgICAgICAgICB8
ICAgb3IgICAgICAgfAogfCAgICZsdDstLS0tLS18ICAgICAgICAgIEl0Zi4gICAgIHwgICBJbnRl
cmVzdCAgICAgICAgICB8ICBOQUNLICAgICAgfAogfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIFYgICAgICAgICAgICAgICAgICAgICBWICAgICAgICAgICAgfAogfCAgICAgCSAgICAgICAJ
ICAgICAgIAkgICAgICAgCSAgICAgICAJICAgICAgIAkgICAgICAgCSAgICAgICAJICAgfAogKy0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tKwogICAgICAJCTwvYXJ0d29yaz4KCgk8L2ZpZ3VyZT4KCgoJPHQ+CgkgIEdpdmVuIHRo
ZSBhYm92ZSBmb3J3YXJkaW5nIHByb3BlcnRpZXMgZm9yIEludGVyZXN0cywgaXQKCSAgc2hvdWxk
IGJlIGNsZWFyIHRoYXQgd2hpbGUgYW4gSW50ZXJlc3QgaXMgb3V0c3RhbmRpbmcgYW5kCgkgIHVs
dGltYXRlbHkgYXJyaXZlcyBhdCBhIHByb2R1Y2VyIHdobyBjYW4gcmVzcG9uZCB0byBpdCwKCSAg
dGhlcmUgaXMgc3VmZmljaWVudCBzdGF0ZSBpbiB0aGUgY2hhaW4gb2YgZm9yd2FyZGVycyB0bwoJ
ICByb3V0ZSBub3QganVzdCBhIHJldHVybmluZyBEYXRhIG1lc3NhZ2UsIGJ1dCBwb3RlbnRpYWxs
eQoJICBhbm90aGVyIEludGVyZXN0IGRpcmVjdGVkIHRocm91Z2ggdGhlIGludmVyc2UgcGF0aCB0
byB0aGUKCSAgdW5pcXVlIGNvbnN1bWVyIHdobyBpc3N1ZWQgdGhlIG9yaWdpbmFsIEludGVyZXN0
LiAoPHhyZWYgdGFyZ2V0PSJpbnRlcmVzdC1hZ2dyZWdhdGlvbiIvPiBkZXNjcmliZXMgaG93Cgkg
IEludGVyZXN0IGFnZ3JlZ2F0aW9uIGludGVyYWN0cyB3aXRoIHRoaXMgc2NoZW1lLikgVGhlIGtl
eQoJICBxdWVzdGlvbiB0aGVyZWZvcmUgaXMgaG93IHRvIGFjY2VzcyB0aGlzIHN0YXRlIGluIGEg
d2F5IHRoYXQKCSAgaXQgY2FuIGJlIHVzZWQgdG8gZm9yd2FyZCBJbnRlcmVzdHMuCgk8L3Q+CgoJ
PHQ+CgkgIEluIG9yZGVyIHRvIGFjaGlldmUgdGhpcyA8ZW0+UmVmbGV4aXZlIEludGVyZXN0PC9l
bT4KCSAgZm9yd2FyZGluZyBvbiB0aGUgaW52ZXJzZSBwYXRoIHJlY29yZGVkIGluIHRoZSBQSVQg
b2YgZWFjaAoJICBmb3J3YXJkZXIsIHdlIG5lZWQgYSBmZXcgY3JpdGljYWwgZGVzaWduIGVsZW1l
bnRzLiBUaGVzZSBhcmUKCSAgYXMgZm9sbG93czoKCTwvdD4KCgk8b2w+CgkgIDxsaT4KCSAgICBU
aGUgUmVmbGV4aXZlIEludGVyZXN0IG5lZWRzIHRvIGhhdmUgYSBOYW1lLiBUaGlzIG5hbWUgaXMK
CSAgICB3aGF0IHRoZSBvcmlnaW5hdGluZyBjb25zdW1lciB3aWxsIHVzZSB0byBtYXRjaCBhZ2Fp
bnN0CgkgICAgdGhlIERhdGEgb2JqZWN0IChvciBvYmplY3RzIC0gbW9yZSBvbiB0aGlzIGxhdGVy
KSBpdAoJICAgIHdpc2hlcyB0aGUgcHJvZHVjZXIgdG8gZmV0Y2ggYnkgaXNzdWluZyB0aGUgUmVm
bGV4aXZlCgkgICAgSW50ZXJlc3QuIFRoaXMgY2Fubm90IGJlIGp1c3QgYW55IG5hbWUsIGJ1dCBu
ZWVkcyB0bwoJICAgIGVzc2VudGlhbGx5IG5hbWUgdGhlIHN0YXRlIGFscmVhZHkgcmVjb3JkZWQg
aW4gdGhlIFBJVCBhbmQKCSAgICBub3QgYWxsb3cgdGhlIGNvbnN1bWVyIHRvIG1hbnVmYWN0dXJl
IGFuIGFyYml0cmFyeSBuYW1lIGFuZAoJICAgIG1vdW50IGEgcmVmbGVjdGlvbiBhdHRhY2sgYXMg
cG9pbnRlZCBvdXQgaW4gPHhyZWYKCSAgICB0YXJnZXQ9InJlZmxlY3Rpb24tYXR0YWNrIi8+LgoJ
ICA8L2xpPgoKCSAgPGxpIGFuY2hvcj0iRklCLXJlcXVpcmVtZW50cyI+CgkgICAgVGhlcmUgaGFz
IHRvIGJlIGEgRklCIGVudHJ5IGF0IGVhY2ggZm9yd2FyZGVyIGZvciB0aGlzCgkgICAgbmFtZSBw
cmVmaXggc28gdGhhdCB3aGVuIHRoZSByZWZsZXhpdmUgaW50ZXJlc3QgYXJyaXZlcywKCSAgICB0
aGUgZm9yd2FyZGVyIGNhbiBmb3J3YXJkIGl0IGRvd25zdHJlYW0gdG93YXJkIHRoZQoJICAgIG9y
aWdpbmF0aW5nIGNvbnN1bWVyLiBUaGlzIEZJQiBlbnRyeSBwb2ludHMgZGlyZWN0bHkgdG8KCSAg
ICB0aGUgaW5jb21pbmcgaW50ZXJmYWNlIG9uIHdoaWNoIHRoZSBjb3JyZXNwb25kaW5nIG9yaWdp
bmFsCgkgICAgSW50ZXJlc3QgYXJyaXZlZC4gVGhlIEZJQiBlbnRyeSBuZWVkcyB0byBiZSBjcmVh
dGVkIGFzCgkgICAgcGFydCBvZiB0aGUgZm9yd2FyZGluZyBvZiB0aGUgb3JpZ2luYWwgSW50ZXJl
c3Qgc28gdGhhdCBpdCBpcwoJICAgIGF2YWlsYWJsZSBpbiB0aW1lIHRvIGNhdGNoIGFueSByZWZs
ZXhpdmUgSW50ZXJlc3QgaXNzdWVkCgkgICAgYnkgdGhlIHByb2R1Y2VyLiBJdCB1c3VhbGx5IG1h
a2VzIHNlbnNlIHRvIGRlc3Ryb3kgdGhpcwoJICAgIEZJQiBlbnRyeSB3aGVuIHRoZSBEYXRhIG1l
c3NhZ2Ugc2F0aXNmeWluZyB0aGUgb3JpZ2luYWwKCSAgICBJbnRlcmVzdCBhcnJpdmVzIHNpbmNl
IHRoaXMgYXZvaWRzIGFueSBkYW5nbGluZyBzdGFsZQoJICAgIHN0YXRlLiBHaXZlbiB0aGUgZGVp
Z24gZGV0YWlscyBkb2N1bWVudGVkIGxhdGVyIGluIHRoaXMKCSAgICBzcGVjaWZpY2F0aW9uLCBz
dGFsZSBGSUIgc3RhdGUgZG9lcyBub3QgcmVwcmVzZW50IGEKCSAgICBjb3JyZWN0bmVzcyBoYXph
cmQgYW5kIGhlbmNlIGNhbiBiZSBkb25lIGxhemlseSBpZiBkZXNpcmVkCgkgICAgaW4gYW4gaW1w
bGVtZW50YXRpb24uIFNlZSA8eHJlZiB0YXJnZXQ9ImZvcndhcmRlci1vcGVyYXRpb24iLz4gZm9y
IG1vcmUgZGV0YWlscyBvbiBGSUIgb3BlcmF0aW9uIGNvbnNpZGVyYXRpb25zLgoJICA8L2xpPgoK
CSAgPGxpPgoJICAgIFRoZXJlIGhhcyB0byBiZSBjb3VwbGluZyBvZiB0aGUgc3RhdGUgYmV0d2Vl
biB0aGUKCSAgICBvcmlnaW5hdGluZyBJbnRlcmVzdC1EYXRhIGV4Y2hhbmdlIGFuZCB0aGUgZW5j
bG9zZWQKCSAgICBSZWZsZXhpdmUgSW50ZXJlc3QtRGF0YSBleGNoYW5nZSBhdCBib3RoIHRoZSBj
b25zdW1lciBhbmQKCSAgICB0aGUgcHJvZHVjZXIuIEluIG91ciBkZXNpZ24sIHRoaXMgYWNjb21w
bGlzaGVkIGJ5IHRoZSB3YXkKCSAgICByZWZsZXhpdmUgaW50ZXJlc3QgbmFtZXMgYXJlIGNob3Nl
bi4KCSAgPC9saT4KCTwvb2w+Cgk8dD5UaGUgZm9sbG93aW5nIHNlY3Rpb25zIHByb3ZpZGUgdGhl
IG5vcm1hdGl2ZSBkZXRhaWxzIG9uIGVhY2gKCSAgb2YgdGhlc2UgZGVzaWduIGVsZW1lbnRzLiBU
aGUgb3ZlcmFsbCBpbnRlcmFjdGlvbiBmbG93IGZvciByZWZsZXhpdmUgZm9yd2FyZGluZyBpcyBp
bGx1c3RyYXRlZCBiZWxvdyBpbiA8eHJlZiB0YXJnZXQ9Im92ZXJhbGwtbWVzc2FnZS1mbG93MiIv
Pi48L3Q+Cgk8ZmlndXJlIGFuY2hvcj0ib3ZlcmFsbC1tZXNzYWdlLWZsb3cyIj4KCSAgPG5hbWU+
TWVzc2FnZSBGbG93IE92ZXJ2aWV3PC9uYW1lPgoJICA8YXJ0d29yayB0eXBlPSJhc2NpaS1hcnQi
IHNyYz0ibWVzc2FnZS1mbG93LWdlbmVyaWMyLnR4dCIvPgoJICAJICA8YXJ0d29yayB0eXBlPSJh
c2NpaS1hcnQiPgogICAgTGVnZW5kOgogICAgSTE6IEludGVyZXN0ICMxIGNvbnRhaW5pbmcgdGhl
IFJlZmxleGl2ZSBOYW1lIFByZWZpeCBUTFYKICAgIFJJOiBSZWZsZXhpdmUgSW50ZXJlc3Qgd2l0
aCBSZWZsZXhpdmUgTmFtZSBQcmVmaXggQ29tcG9uZW50CiAgICBSTlA6IFJlZmxleGl2ZSBOYW1l
IFByZWZpeAogICAgRDE6IERhdGEgbWVzc2FnZSwgYW5zd2VyaW5nIGluaXRpYXRpbmcgSTEgSW50
ZXJlc3QKICAgIEQyOiBEYXRhIG1lc3NhZ2UsIGFuc3dlcmluZyBSSQoJICA8L2FydHdvcms+Cgk8
L2ZpZ3VyZT4KCiAgICAgIDwvc2VjdGlvbj4KCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0ibmFtaW5n
Ij48bmFtZT5OYW1pbmcgb2YgUmVmbGV4aXZlIEludGVyZXN0czwvbmFtZT4KICAgICAgCiAgICAg
IDx0PgoJQSBjb25zdW1lciBtYXkgaGF2ZSBvbmUgb3IgbW9yZSBvYmplY3RzIGZvciB0aGUgcHJv
ZHVjZXIgdG8KCWZldGNoLCBhbmQgdGhlcmVmb3JlIG5lZWRzIHRvIGNvbW11bmljYXRlIGVub3Vn
aCBpbmZvcm1hdGlvbgoJaW4gdGhlaXIgaW5pdGlhbCBJbnRlcmVzdCB0byBhbGxvdyB0aGUgcHJv
ZHVjZXIgdG8gY29uc3RydWN0Cglwcm9wZXJseSBmb3JtZWQgcmVmbGV4aXZlIEludGVyZXN0IG5h
bWVzLiBGb3Igc29tZQoJYXBwbGljYXRpb25zIHRoZSBzZXQgb2YgPGVtPmZ1bGwgbmFtZXM8L2Vt
PiAoc2VlIDx4cmVmCgl0YXJnZXQ9IkktRC5pcnRmLWljbnJnLXRlcm1pbm9sb2d5Ii8+KSBpcyBr
bm93biBhIHByaW9yaSwgZm9yCglleGFtcGxlIHRocm91Z2ggY29tcGlsZSB0aW1lIGJpbmRpbmdz
IG9mIGFyZ3VtZW50cyBpbgoJaW50ZXJmYWNlIGRlZmluaXRpb25zIG9yIGJ5IHRoZSBhcmNoaXRl
Y3R1cmFsIGRlZmluaXRpb24gb2YgYQoJc2ltcGxlIHNlbnNvciByZWFkaW5nLiBJbiBvdGhlciBj
YXNlcyB0aGUgZnVsbCBuYW1lcyBvZiB0aGUKCWluZGl2aWR1YWwgb2JqZWN0cyBtdXN0IGJlIGNv
bW11bmljYXRlZCBpbiB0aGUgb3JpZ2luYWwKCUludGVyZXN0IG1lc3NhZ2UuIEluIGFsbCBjYXNl
cyBlbm91Z2ggc3RhdGUgbXVzdCBiZSBwcm92aWRlZAoJYnkgdGhlIGNvbnN1bWVyIGZvciB0aGUg
Zm9yd2FyZGVycyB0byBjb25zdHJ1Y3QgYSBGSUIgZW50cnkKCShhcyBub3RlZCBpbiA8eHJlZiB0
YXJnZXQ9IkZJQi1yZXF1aXJlbWVudHMiLz4pLiBUaGlzIGlzCglhY2NvbXBsaXNoZWQgdGhyb3Vn
aCB0aGUgZm9sbG93aW5nIG5hbWluZyBjb25zdHJ1Y3QuCiAgICAgIDwvdD4KCiAgICAgIDx0PgoJ
V2UgZGVmaW5lIGEgbmV3IHR5cGVkIG5hbWUgY29tcG9uZW50LCBpZGVudGlmaWVkIGJ5IGEKCXJl
Z2lzdGVyZWQgbmFtZSBjb21wb25lbnQgdHlwZSBpbiB0aGUgSUFOQSByZWdpc3RyeSBmb3IgPHhy
ZWYKCXRhcmdldD0iUkZDODU2OSIvPi4gV2UgY2FsbCB0aGlzIHRoZSA8ZW0+UmVmbGV4aXZlIElu
dGVyZXN0CglOYW1lIENvbXBvbmVudCB0eXBlPC9lbT4uIEl0IE1VU1QgYmUgdGhlIGZpcnN0IChp
LmUuIGhpZ2gKCW9yZGVyKSBuYW1lIGNvbXBvbmVudCBvZiBhbnkgUmVmbGV4aXZlIEludGVyZXN0
IGlzc3VlZCBieSBhCglwcm9kdWNlci4gSXRzIHZhbHVlIGlzIGEgcmFuZG9tIDY0IGJpdCBudW1i
ZXIsIGFzc2lnbmVkIGJ5IHRoZQoJY29uc3VtZXIsIHdoaWNoIHByb3ZpZGVzIHRoZSBlbnRyb3B5
IHJlcXVpcmVkIHRvIHVuaXF1ZWx5CglpZGVudGlmeSB0aGUgaXNzdWluZyBjb25zdW1lciBmb3Ig
dGhlIGR1cmF0aW9uIG9mIGFueQoJb3V0c3RhbmRpbmcgSW50ZXJlc3QtRGF0YSBleGNoYW5nZS4g
VGhlIGNvbnN1bWVyIFNIT1VMRCBjaG9vc2UgYSBkaWZmZXJlbnQgcmFuZG9tIHZhbHVlIGZvciBl
YWNoIEludGVyZXN0IG1lc3NhZ2UgaXQgY29uc3RydWN0cywgZm9yIHR3byByZWFzb25zOjwvdD4K
CQoJPG9sPgoJCTxsaT5JZiBzdGFsZSBGSUIgc2F0ZSBpcyBwcmVzZW50LCB0aGUgcmFuZG9tbmVz
cyBwcmV2ZW50cyBwb3RlbnRpYWwgbWlzLXJvdXRpbmcgb2YgcmVmbGV4aXZlIGludGVyZXN0cyAo
c2VlIDx4cmVmIHRhcmdldD0iRklCIi8+IGJlbG93IGZvciBtb3JlIGRldGFpbHMpLCBhbmQ8L2xp
PgoJCQoJCTxsaT5SZS11c2Ugb2YgdGhlIHNhbWUgcmVmbGV4aXZlIGludGVyZXN0IG5hbWUgb3Zl
ciBtdWx0aXBsZSBpbnRlcmFjdGlvbnMgbWlnaHQgcmV2ZWFsIGxpbmthYmlsaXR5IGluZm9ybWF0
aW9uIHRoYXQgY291bGQgYmUgdXNlZCBieSBzdXJ2ZWlsbGFuY2UgYWR2ZXJzYXJpZXMgZm9yIHRy
YWNraW5nIHB1cnBvc2VzLjwvbGk+Cgk8L29sPgoJCiAgICA8dD5UaGlzIGluaXRpYWwgbmFtZSBj
b21wb25lbnQgaXMgZWl0aGVyIGNvbW11bmljYXRlZCBieSBpdHNlbGYKCXRocm91Z2ggYSA8ZW0+
UmVmbGV4aXZlIE5hbWUgUHJlZml4IFRMVjwvZW0+IGluIHRoZQoJb3JpZ2luYXRpbmcgSW50ZXJl
c3QsIG9yIHByZXBlbmRlZCB0byBhbnkgb2JqZWN0IG5hbWVzIHRoZQoJY29uc3VtZXIgd2lzaGVz
IHRoZSBwcm9kdWNlciB0byBmZXRjaCBleHBsaWNpdGx5IHdoZXJlIHRoZXJlCglpcyBtb3JlIHRo
YW4gb25lIG9iamVjdCBuZWVkZWQgYnkgdGhlIHByb2R1Y2VyIGZvciB0aGUgY3VycmVudAoJSW50
ZXJlc3QtRGF0YSBpbnRlcmFjdGlvbi4gVGhlcmUgYXJlIGZvdXIgY2FzZXMgdG8gY29uc2lkZXI6
PC90PgoJCgk8b2w+CgkJPGxpPlRoZSByZWZsZXhpdmUgPGVtPmZ1bGxuYW1lPC9lbT4gb2YgYSBz
aW5nbGUgb2JqZWN0IHRvIGZldGNoLjwvbGk+CgkJPGxpPkEgc2luZ2xlIHJlZmxleGl2ZSBuYW1l
IHByZWZpeCBvdXQgb2Ygd2hpY2ggdGhlIHByb2R1Y2VyIGNhbiAoYnkgYXBwbGljYXRpb24tc3Bl
Y2lmaWMgbWVhbnMpIGNvbnN0cnVjdCBhIG51bWJlciBvZiA8ZW0+ZnVsbG5hbWVzPC9lbT4gb2Yg
dGhlIG9iamVjdHMgaXQgbWF5IHdhbnQgdG8gZmV0Y2gsPC9saT4KCQk8bGk+VGhlIHJlZmxleGl2
ZSA8ZW0+ZnVsbG5hbWU8L2VtPiBvZiBhIDx4cmVmIHRhcmdldD0iSS1ELmlydGYtaWNucmctZmxp
YyI+RkxJQyAgTWFuaWZlc3Q8L3hyZWY+IGVudW1lcmF0aW5nIHRoZSBzdWZmaXhlcyB0aGF0IG1h
eSBiZSB1c2VkIGJ5IHRoZSBwcm9kdWNlciB0byBjb25zdHJ1Y3QgdGhlIG5lY2Vzc2FyeSBuYW1l
cyw8L2xpPgoJCTxsaT5NdWx0aXBsZSByZWZsZXhpdmUgbmFtZSBUTFZzIE1BWSBiZSBpbmNsdWRl
ZCBpbiB0aGUgSW50ZXJlc3QgbWVzc2FnZSBpZiBub25lIG9mIHRoZSBhYm92ZSAzIG9wdGlvbnMg
Y292ZXJzIHRoZSBkZXNpcmVkIHVzZSBjYXNlLjwvbGk+Cgk8L29sPgoJCgk8dD5UaGUgbGFzdCBv
ZiB0aGUgZm91ciBvcHRpb25zIGFib3ZlLCB3aGlsZSBub3QgZXhwbGljaXRseSBvdXRsYXdlZCwg
U0hPVUxEIE5PVCBiZSB1c2VkLiBUaGlzIGlzIGJlY2F1c2UgaXQgcmVzdWx0cyBpbiBhIGxvbmdl
ciBJbnRlcmVzdCBtZXNzYWdlIGFuZCByZXF1aXJlcyBleHRyYSBGSUIgcmVzb3VyY2VzLiBIZW5j
ZSwgaXQgaXMgbW9yZSBsaWtlbHkgYSBmb3J3YXJkZXIgd2lsbCByZWplY3QgdGhlIEludGVyZXN0
IGZvciBsYWNrIG9mIHJlc291cmNlcy4gQSBmb3J3YXJkZXIgTUFZIG9wdGltaXplIGZvciB0aGUg
Y2FzZSBvZiBhIHNpbmdsZSBSZWZsZXhpdmUgTmFtZSBUTFYgYXQgdGhlIGV4cGVuc2Ugb2YgdGhv
c2Ugd2l0aCBtb3JlIHRoYW4gb25lLjwvdD4KCQkKCiAgICAgIDx0PgoJQSBwcm9kdWNlciwgdXBv
biByZWNlaXZpbmcgYW4gSW50ZXJlc3Qgd2l0aCBvbmUgb3IgbW9yZQoJUmVmbGV4aXZlIE5hbWUg
VExWcywgbWF5IGRlY2lkZSBpdCBuZWVkcyB0aGUgcHVsbCB0aGUKCWFzc29jaWF0ZWQgZGF0YSBv
YmplY3QocykuIEl0IHRoZXJlZm9yZSBjYW4gaXNzdWUgb25lIG9yIG1vcmUKCVJlZmxleGl2ZSBJ
bnRlcmVzdHMgYnkgYXBwZW5kaW5nIHRoZSBuZWNlc3NhcnkgbmFtZSBjb21wb25lbnRzCgluZWVk
ZWQgdG8gZm9ybSB2YWxpZCBmdWxsIG5hbWVzIG9mIHRoZSBhc3NvY2lhdGVkIG9iamVjdHMKCXBy
ZXNlbnQgYXQgdGhlIG9yaWdpbmF0aW5nIGNvbnN1bWVyLiBUaGVzZSBpbiBmYWN0IGNvbXByaXNl
Cgljb252ZW50aW9uYWwgSW50ZXJlc3QtRGF0YSBleGNoYW5nZXMsIHdpdGggbm8gYWx0ZXJhdGlv
biBvZgoJdGhlIHVzdWFsIHNlbWFudGljcyB3aXRoIHJlZ2FyZCB0byBzaWduYXR1cmVzLCBjYWNo
aW5nLAoJZXhwaXJhdGlvbiwgZXRjLiBXaGVuIHRoZSBwcm9kdWNlciBoYXMgcmV0cmlldmVkIHRo
ZSByZXF1aXJlZAoJb2JqZWN0cyB0byBjb21wbGV0ZSB0aGUgb3JpZ2luYWwgSW50ZXJlc3QtRGF0
YSBleGNoYW5nZSwgaXQKCWNhbiBpc3N1ZSBpdHMgRGF0YSByZXNwb25zZSwgd2hpY2ggdW53aW5k
cyBhbGwgdGhlIGVzdGFibGlzaGVkCglzdGF0ZSBhdCB0aGUgcHJvZHVjZXIsIHRoZSBjb25zdW1l
ciwgYW5kIHRoZSBpbnRlcm1lZGlhdGUKCWZvcndhcmRlcnMuCiAgICAgIDwvdD4KICAgICAgCiAg
ICAgIDwvc2VjdGlvbj4KICAgICAgCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0iZm9yd2FyZGVyLW9w
ZXJhdGlvbiI+PG5hbWU+Rm9yd2FyZGVyIG9wZXJhdGlvbiBmb3IgUmVmbGV4aXZlIEludGVyZXN0
czwvbmFtZT4KICAgICAgCiAgICAgIDx0PgoJVGhlIGZvcndhcmRlciBvcGVyYXRpb24gZm9yIEND
TnggYW5kL29yIE5ETiBpcyBjaGFuZ2VkIGluIHRocmVlCglyZXNwZWN0cyB3aGVuIHN1cHBvcnRp
bmcgUmVmbGV4aXZlIEludGVyZXN0cy4KICAgICAgPC90PgogICAgICA8b2w+Cgk8bGk+CgkgIFRo
ZSBmb3J3YXJkZXIgTVVTVCBjcmVhdGUgc2hvcnQtbGlmZXRpbWUgRklCIGVudHJpZXMgZm9yCgkg
IGFueSBSZWZsZXhpdmUgSW50ZXJlc3QgTmFtZSBwcmVmaXhlcyBjb21tdW5pY2F0ZWQgaW4gYW4K
CSAgSW50ZXJlc3QgbWVzc2FnZS4gSWYgdGhlIGZvcndhcmRlciBkb2VzIG5vdCBoYXZlIHN1ZmZp
Y2llbnQgcmVzb3VyY2VzIHRvIGRvIHNvLCBpdCBNVVNUIHJlamVjdCB0aGUgSW50ZXJlc3Qgd2l0
aCB0aGUgVF9SRVRVUk5fTk9fUkVTT1VSQ0VTIGVycm9yIC0gdGhlIHNhbWUgZXJyb3IgdXNlZCBp
ZiB0aGUgZm9yd2FyZGVyIHdlcmUgbGFja2luZyBzdWZmaWNpZW50IFBJVCByZXNvdXJjZXMgdG8g
cHJvY2VzcyB0aGUgSW50ZXJlc3QgbWVzc2FnZS4KCTwvbGk+Cgk8bGk+CgkgIFRob3NlIEZJQiBl
bnRyaWVzIE1VU1QgYmUgcXVlcmllZCB3aGVuZXZlciBhbiBJbnRlcmVzdCBtZXNzYWdlIGFycml2
ZXMKCSAgd2hvc2UgZmlyc3QgbmFtZSBjb21wb25lbnQgaXMgb2YgdGhlIHR5cGUgPGVtPlJlZmxl
eGl2ZQoJICBJbnRlcmVzdCBOYW1lIENvbXBvbmVudDwvZW0+Cgk8L2xpPgoJPGxpPgoJICBUaGUg
RklCIGVudHJ5IE1VU1QgYmUgcmVtb3ZlZCBldmVudHVhbGx5LCBhZnRlciB0aGUKCSAgY29ycmVz
cG9uZGluZyBEYXRhIG1lc3NhZ2UgaGFzIGJlZW4gZm9yd2FyZGVkLiBPbmUgb3B0aW9uCgkgIHdv
dWxkIGJlIHRvIHJlbW92ZSB0aGUgRklCIGRpcmVjdGx5IGFmdGVyIHRoZSBEYXRhIG1lc3NhZ2UK
CSAgaGFzIGJlZW4gZm9yd2FyZGVkLiBIb3dldmVyLCB0aGUgZm9yd2FyZGVyIE1BWSBkbyBsYXp5
IGNsZWFudXAuCgk8L2xpPgogICAgICA8L29sPgoKICAgICAgPHQ+CglUaGUgUElUIGVudHJ5IGZv
ciB0aGUgUmVmbGV4aXZlIEludGVyZXN0IGlzIGNvbnN1bWVkIHBlcgoJcmVndWxhciBJbnRlcmVz
dC9EYXRhIG1lc3NhZ2UgZm9yd2FyZGluZyByZXF1aXJlbWVudHMuIFRoZSBQSVQKCWVudHJ5IGZv
ciB0aGUgb3JpZ2luYXRpbmcgSW50ZXJlc3QgKHRoYXQgY29tbXVuaWNhdGVkIHRoZQoJUmVmbGV4
aXZlIEludGVyZXN0IE5hbWUpIGlzIGFsc28gY29uc3VtZWQgYnkgYSBmaW5hbCBEYXRhCgltZXNz
YWdlIGZyb20gdGhlIHByb2R1Y2VyIHRvIHRoZSBvcmlnaW5hbCBjb25zdW1lci4KCTwhLS0gZGt1
OiBjb3VsZCBzYXkgc29tZXRoaW5nIGFib3V0IFBJVCBlbnRyeSBleHBpcnkgdGltZXMgYW5kCgkg
ICAgIG1vcmUgZXhwZXJpbWVudGF0aW9uIHRoYXQgc2hvdWxkIGJlIGNvbmR1Y3RlZCAtLT4KICAg
ICAgPC90PgogICAgICA8L3NlY3Rpb24+CiAgICAgIAogIDxzZWN0aW9uIGFuY2hvcj0ic3RhdGUt
Y291cGxpbmciPjxuYW1lPlN0YXRlIGNvdXBsaW5nIGJldHdlZW4gcHJvZHVjZXIgYW5kIGNvbnN1
bWVyPC9uYW1lPgoKICAgIDx0PkEgY29uc3VtZXIgdGhhdCB3aXNoZXMgdG8gdXNlIHRoaXMgc2No
ZW1lIE1VU1QgdXRpbGl6ZSBvbmUgb2YgdGhlIHJlZmxleGl2ZSBuYW1pbmcgb3B0aW9ucyBkZWZp
bmVkIGluIDx4cmVmIHRhcmdldD0nbmFtaW5nJy8+IGFuZCBpbmNsdWRlIGl0IGluIHRoZSBjb3Jy
ZXNwb25kaW5nIEludGVyZXN0IG1lc3NhZ2UuIFRoZSBSZWZsZXhpdmUgTmFtZSBUTFYgPGVtPmFu
ZDwvZW0+IHRoZSBmdWxsIG5hbWUgb2YgdGhlIHJlcXVlc3RlZCBkYXRhIG9iamVjdCAodGhhdCBp
ZGVudGlmaWVzIHRoZSBwcm9kdWNlcikgaWRlbnRpZnkgdGhlIGNvbW1vbiBzdGF0ZSBzaGFyZWQg
YnkgdGhlCgljb25zdW1lciBhbmQgdGhlIHByb2R1Y2VyLiBXaGVuIHRoZSBwcm9kdWNlciByZXNw
b25kcyBieQoJc2VuZGluZyBJbnRlcmVzdHMgd2l0aCB0aGUgUmVmbGV4aXZlIE5hbWUgUHJlZml4
LCB0aGUgb3JpZ2luYWwKCWNvbnN1bWVyIHRoZXJlZm9yZSBoYXMgc3VmZmljaWVudCBpbmZvcm1h
dGlvbiB0byBtYXAgdGhlc2UgSW50ZXJlc3RzIHRvIHRoZSBvbmdvaW5nIEludGVyZXN0LURhdGEg
ZXhjaGFuZ2UuPC90PgoJCiAgICA8dD5UaGUgZXhjaGFuZ2UgaXMgZmluaXNoZWQgd2hlbiB0aGUg
cHJvZHVjZXIgd2hvIHJlY2VpdmVkIHRoZSBvcmlnaW5hbCBJbnRlcmVzdCBtZXNzYWdlIHJlc3Bv
bmRzIHdpdGggYSBEYXRhIG1lc3NhZ2UgKG9yIGFuIEludGVyZXN0IFJldHVybiBtZXNzYWdlIGlu
IHRoZSBjYXNlIG9mIGVycm9yKSAgYW5zd2VyaW5nIHRoZSBvcmlnaW5hbCBJbnRlcmVzdC4gQWZ0
ZXIKCXNlbmRpbmcgdGhpcyBEYXRhIG1lc3NhZ2UsIHRoZSBwcm9kdWNlciBTSE9VTEQgZGVzdHJv
eSB0aGUKCWNvcnJlc3BvbmRpbmcgc2hhcmVkIHN0YXRlLiAgSXQgTUFZIGRlY2lkZSB0byB1c2Ug
YSB0aW1lcgoJdGhhdCB3aWxsIHRyaWdnZXIgYSBsYXRlciBzdGF0ZSBkZXN0cnVjdGlvbi4gQWZ0
ZXIgcmVjZWl2aW5nCgl0aGlzIERhdGEgbWVzc2FnZSwgdGhlIG9yaWdpbmF0aW5nIGNvbnN1bWVy
IE1VU1QgZGVzdHJveSB0aGUKCWNvcnJlc3BvbmRpbmcgSW50ZXJlc3QtRGF0YSBleGNoYW5nZSBz
dGF0ZS48L3Q+CiAgPC9zZWN0aW9uPgogICAgICAKICAgICAgPHNlY3Rpb24+PG5hbWU+VXNlIGNh
c2VzIGZvciBSZWZsZXhpdmUgSW50ZXJlc3RzPC9uYW1lPgogICAgICAKICAgICAgPHNlY3Rpb24g
YW5jaG9yPSJSTUkiPjxuYW1lPkFjaGlldmluZyBSZW1vdGUgTWV0aG9kIEludm9jYXRpb24gd2l0
aCBSZWZsZXhpdmUgSW50ZXJlc3RzPC9uYW1lPgoKICAgICAgPCEtLTx0PjxzdHJvbmc+VEJELjwv
c3Ryb25nPiBSZWNhcGl0dWxhdGUgd2hhdCBSSUNFIGRvZXMuLi4gPC90Pi0tPgoKICAgICAgPHQ+
CglSSUNFIChSZW1vdGUgTWV0aG9kIEludm9jYXRpb24gaW4gSUNOKSA8eHJlZgoJdGFyZ2V0PSJL
cm9sMjAxOCIvPiB1c2VzIHRoZSBSZWZsZXhpdmUgSW50ZXJlc3QgRm9yd2FyZGluZwoJc2NoZW1l
IHRoYXQgaW5zcGlyZWQgdGhlIGRlc2lnbiBzcGVjaWZpZWQgaW4gdGhpcyBkb2N1bWVudC4KICAg
ICAgPC90PgogICAgICA8dD4KCUluIFJJQ0UsIHRoZSBvcmlnaW5hbCBJbnRlcmVzdCBkZW5vdGVz
IHRoZSByZW1vdGUgbWV0aG9kIChwbHVzCglwb3RlbnRpYWwgcGFyYW1ldGVycykgdG8gYmUgaW52
b2tlZCBhdCBhIHByb2R1Y2VyCgkoc2VydmVyKS4gQmVmb3JlIGNvbW1pdHRpbmcgYW55IGNvbXB1
dGF0aW5nIHJlc291cmNlcywgdGhlCglzZXJ2ZXIgY2FuIHRoZW4gcmVxdWVzdCBhdXRoZW50aWNh
dGlvbiBjcmVkZW50aWFscyBhbmQKCShvcHRpb25hbCkgcGFyYW1ldGVycyB1c2luZyByZWZsZXhp
dmUgSW50ZXJlc3QtRGF0YSBleGNoYW5nZXMuCiAgICAgIDwvdD4KICAgICAgPHQ+CglXaGVuIHRo
ZSBzZXJ2ZXIgaGFzIG9idGFpbmVkIHRoZSBuZWNlc3NhcnkgY3JlZGVudGlhbHMgYW5kCglpbnB1
dCBwYXJhbWV0ZXJzLCBpdCBjYW4gZGVjaWRlIHRvIGNvbW1pdCBjb21wdXRpbmcKCXJlc291cmNl
cywgc3RhcnRzIHRoZSBjb21wdXRlIHByb2Nlc3MsIGFuZCByZXR1cm5zIGEgaGFuZGxlCgkoIlRo
dW5rIikgaW4gdGhlIGZpbmFsIERhdGEgbWVzc2FnZSB0byB0aGUgb3JpZ2luYWwgY29uc3VtZXIK
CShjbGllbnQpLgogICAgICA8L3Q+CiAgICAgIDx0PgoJVGhlIGNsaWVudCB3b3VsZCBsYXRlciBy
ZXF1ZXN0IHRoZSBjb21wdXRhdGlvbiByZXN1bHRzIHVzaW5nIGEKCXJlZ3VsYXIgSW50ZXJlc3Qt
RGF0YSBleGNoYW5nZSAob3V0c2lkZSB0aGUgUmVmbGV4aXZlLUludGVyZXN0Cgl0cmFuc2FjdGlv
bikgLS0gdXNpbmcgdGhlIFRodW5rIGFzIGEgbmFtZSBmb3IgdGhlIGNvbXB1dGF0aW9uCglyZXN1
bHQuCiAgICAgIDwvdD4KICAgICAgPHQ+Cgk8eHJlZiB0YXJnZXQ9InJpY2UtbWVzc2FnZS1mbG93
Ii8+IGRlcGljdHMgYW4gYWJzdHJhY3QgbWVzc2FnZQoJZGlhZ3JhbSBmb3IgUklDRS4gSW4gYWRk
aXRpb24gdG8gdGhlIDQtd2F5IFJlZmxleGl2ZQoJRm9yd2FyZGluZyBIYW5kc2hha2UgKHNlZSA8
eHJlZgoJdGFyZ2V0PSJvdmVyYWxsLW1lc3NhZ2UtZmxvdzIiLz4gZm9yIHRoZSBkZXRhaWxzIG9m
IHRoZQoJaW50ZXJhY3Rpb24pLCBSSUNFIGFkZHMgYW5vdGhlciAoc3RhbmRhcmQpIElDTiBJbnRl
cmVzdC9EYXRhCglleGNoYW5nZSBmb3IgdHJhbnNtaXR0aW5nIHRoZSBSTUkgcmVzdWx0LiBUaGUg
VGh1bmsgbmFtZSBpcwoJcHJvdmlkZWQgdG8gdGhlIGNvbnN1bWVyIGluIHRoZSBEMSBEQVRBIG1l
c3NhZ2UgKGFuc3dlcmluZyB0aGUKCWluaXRpYWwgSTEgSW50ZXJlc3QpLgogICAgICA8L3Q+Cgog
ICAgICA8ZmlndXJlIGFuY2hvcj0icmljZS1tZXNzYWdlLWZsb3ciPgoJPG5hbWU+UklDRSBNZXNz
YWdlIEZsb3c8L25hbWU+Cgk8YXJ0d29yayB0eXBlPSJhc2NpaS1hcnQiIHNyYz0icmljZTIudHh0
Ii8+Cgk8YXJ0d29yayB0eXBlPSJhc2NpaS1hcnQiPgogICAgTGVnZW5kOgogICAgSTE6IEludGVy
ZXN0ICMxIGNvbnRhaW5pbmcgdGhlIFJlZmxleGl2ZSBOYW1lIFByZWZpeCBUTFYKICAgIEQxOiBE
YXRhIG1lc3NhZ2UsIGFuc3dlcmluZyBpbml0aWF0aW5nIEkxIEludGVyZXN0LAogICAgICAgIHJl
dHVybmluZyBUaHVuayBuYW1lCiAgICBEMjogRGF0YSBtZXNzYWdlLCBhbnN3ZXJpbmcgUkkgKHBh
cmFtZXRlcnMsIGNyZWRlbnRpYWxzKQogICAgSTM6IFJlZ3VsYXIgSW50ZXJlc3QgZm9yIFRodW5r
IChjb21wdXRlIHJlc3VsdCkKICAgIEQzOiBEYXRhIG1lc3NhZ2UsIGFuc3dlcmluZyBJMwoJPC9h
cnR3b3JrPgoKICAgICAgPC9maWd1cmU+CiAgICAgIAoKICAgICAgCiAgICAgIDwvc2VjdGlvbj4K
CiAgICAgIDxzZWN0aW9uIGFuY2hvcj0id2ViIj48bmFtZT5SRVNUZnVsIFdlYiBJbnRlcmFjdGlv
bnM8L25hbWU+CiAgICAgIDx0PgoJSW4gdG9kYXlzIEhUVFAtYmFzZWQgd2ViLCBSRVNUZnVsIChS
ZXByZXNlbnRhdGlvbmFsIFN0YXRlCglUcmFuc2Zlcikgd2ViIGludGVyYWN0aW9ucyBhcmUgcmVh
bGl6ZWQgYnkgc2VuZGluZyByZXF1ZXN0cyBpbgoJYSBjbGllbnQvc2VydmVyIGludGVyYWN0aW9u
LCB3aGVyZSB0aGUgcmVxdWVzdHMgcHJvdmlkZXMgdGhlCglhcHBsaWNhdGlvbiBjb250ZXh0IChv
ciBhIHJlZmVyZW5jZSB0byBpdCkuIEl0IGhhcyBiZWVuIG5vdGVkCglpbiA8eHJlZiB0YXJnZXQ9
Ik1vaXNlZW5rbzIwMTQiLz4gdGhhdCBjb3JyZXNwb25kaW5nIHJlcXVlc3RzCglvZnRlbiBleGNl
ZWQgdGhlIHJlc3BvbnNlIG1lc3NhZ2VzIGluIHNpemUsIGFuZCB0aGF0IHRoaXMKCXJhaXNlcyB0
aGUgcHJvYmxlbXMgbm90ZWQgaW4gPHhyZWYgdGFyZ2V0PSJwdXNoLXByb2JsZW1zIi8+IHdoZW4g
YXR0ZW1wdGluZyB0byBtYXAgc3VjaCBleGNoYW5nZXMgZGlyZWN0bHkgdG8gQ0NOeC9ORE4uCiAg
ICAgIDwvdD4KICAgICAgPHQ+CglBbm90aGVyIHJlYXNvbiBub3QgdG8gaW5jbHVkZSBhbGwgcmVx
dWVzdCBwYXJhbWV0ZXJzIGluIGEKCShwb3NzaWJseSBlbmNyeXB0ZWQpIEludGVyZXN0IG1lc3Nh
Z2UgaXMgdGhlIGZhY3QgdGhhdCBhCglzZXJ2ZXIgKHRoYXQgaXMgc2VydmluZyB0aG91c2FuZHMg
b2YgY2xpZW50cykgd291bGQgYmUgb2JsaWdlZAoJdG8gcmVjZWl2ZSwgcG9zc2libHkgZGVjcnlw
dCBhbmQgcGFyc2UgdGhlIGNvbXBsZXRlIHJlcXVlc3RzCgliZWZvcmUgYmVpbmcgYWJsZSB0byBk
ZXRlcm1pbmUgd2hldGhlciB0aGUgcmVxdWVzdG9yIGlzCglhdXRob3JpemVkLCB3aGV0aGVyIHRo
ZSByZXF1ZXN0IGNhbiBiZSBzZXJ2ZWQgZXRjLiBNYW55Cglub24tdHJpdmlhbCByZXF1ZXN0cyBj
b3VsZCB0aHVzIGxlYWQgdG8gY29tcHV0YXRpb25hbCBvdmVybG9hZAoJYXR0YWNrcy4KICAgICAg
PC90PgogICAgICA8dD4KCVVzaW5nIFJlZmxleGl2ZSBJbnRlcmVzdCBGb3J3YXJkaW5nIGZvciBS
RVNUZnVsIFdlYgoJSW50ZXJhY3Rpb25zIHdvdWxkIGVuY29kZSB0aGUgUkVTVCByZXF1ZXN0IGlu
IHRoZSBPcmlnaW5hbAoJcmVxdWVzdCwgdG9nZXRoZXIgd2l0aCBhIFJlZmxleGl2ZSBJbnRlcmVz
dCBQcmVmaXggdGhhdCB0aGUKCXNlcnZlciBjb3VsZCB0aGVuIHVzZSB0byBnZXQgYmFjayB0byB0
aGUgY2xpZW50IGZvcgoJYXV0aGVudGljYXRpb24gY3JlZGVudGlhbHMgYW5kIHJlcXVlc3QgcGFy
YW1ldGVycywgc3VjaCBhcwoJY29va2llcy4gVGhlIHJlcXVlc3QgcmVzdWx0IChyZXNwb25zZSBt
ZXNzYWdlKSBjb3VsZCBlaXRoZXIgYmUKCXRyYW5zbWl0dGVkIGluIHRoZSBEYXRhIG1lc3NhZ2Ug
YW5zd2VyaW5nIHRoZSBvcmlnaW5hbAoJcmVxdWVzdCwgb3IgLS0gaW4gY2FzZSBvZiBkeW5hbWlj
LCBsb25nZXItcnVubmluZyBjb21wdXRhdGlvbnMKCS0tIGluIGEgc2VwZXJhdGUgSW50ZXJlc3Qv
RGF0YSBleGNoYW5nZSwgcG90ZW50aWFsbHkKCWxldmVyYWdpbmcgdGhlIFRodW5rIHNjaGVtZSBk
ZXNjcmliZWQgaW4gc2VjdGlvbiA8eHJlZgoJdGFyZ2V0PSJSTUkiLz4uCiAgICAgIDwvdD4KICAg
ICAgPHQ+CglVbmxpa2UgYXBwcm9hY2hlcyB3aGVyZSBjbGllbnRzIGhhdmUgdG8gc2lnbmFsIGEg
Z2xvYmFsbHkKCXJvdXRhYmxlIHByZWZpeCB0byB0aGUgbmV0d29yaywgdGhpcyBhcHByb2FjaCB3
b3VsZCBub3QKCXJlcXVpcmUgdGhlIGNsaWVudCAob3JpZ2luYWwgY29uc3VtZXIpIHRvIGV4cG9z
ZSBpdHMgaWRlbnRpdHkKCXRvIHRoZSBuZXR3b3JrICh0aGUgbmV0d29yayBvbmx5IHNlZXMgdGhl
IHRlbXBvcmFyeSBSZWZsZXhpdmUKCU5hbWUgUHJlZml4KSwgYnV0IGl0IHdvdWxkIHN0aWxsIGJl
IHBvc3NpYmxlIHRvCglhdXRoZW50aWNhdGUgdGhlIGNsaWVudCBhdCB0aGUgc2VydmVyLgogICAg
ICA8L3Q+CiAgICAgIDwvc2VjdGlvbj4KCQogICAgICA8c2VjdGlvbiBhbmNob3I9InBob25lLWhv
bWUiPgoJPG5hbWU+QWNoaWV2aW5nIHNpbXBsZSBkYXRhIHB1bGwgZnJvbSBjb25zdW1lcnMgd2l0
aCByZWZsZXhpdmUgSW50ZXJlc3RzPC9uYW1lPgogICAgICAJCiAgICAgIDx0PgoJQW4gb2Z0LWNp
dGVkIHVzZSBjYXNlIGZvciBJQ04gbmV0d29yayBhcmNoaXRlY3R1cmVzIGlzCgk8ZW0+SW50ZXJu
ZXQgb2YgVGhpbmdzPC9lbT4gKElvVCksIHdoZXJlIHRoZSBzb3VyY2VzIG9mIGRhdGEKCWFyZSBs
aW1pdGVkLXJlc291cmNlIHNlbnNvci9hY3R1YXRvcnMuIE1hbnkgYXBwcm9hY2hlcyBoYXZlCgli
ZWVuIHRyaWVkIChlLmcuIDx4cmVmIHRhcmdldD0iQmFjY2VsbGkyMDE0Ii8+LCA8eHJlZgoJdGFy
Z2V0PSJMaW5kZ3JlbjIwMTYiLz4sIDx4cmVmIHRhcmdldD0iR3VuZG9nYW4yMDE4Ii8+KSB3aXRo
Cgl2YXJ5aW5nIGRlZ3JlZXMgb2Ygc3VjY2VzcyBpbiBhZGRyZXNzaW5nIHRoZSBpc3N1ZXMgb3V0
bGluZWQKCWluIDx4cmVmIHRhcmdldD0icHVzaC1wcm9ibGVtcyIvPi4gVGhlIHJlZmxleGl2ZSBm
b3J3YXJkaW5nCglleHRlbnNpb24gbWF5IHN1YnN0YW50aWFsbHkgYW1lbGlvcmF0ZSB0aGUgZG9j
dW1lbnRlZAoJZGlmZmljdWx0aWVzIGJ5IGFsbG93aW5nIGEgZGlmZmVyZW50IG1vZGVsIGZvciB0
aGUgYmFzaWMKCWludGVyYWN0aW9uIG9mIHNlbnNvcnMgd2l0aCB0aGUgSUNOIG5ldHdvcmsuCiAg
ICAgIDwvdD4KCQkKICAgICAgPHQ+CglJbnN0ZWFkIG9mIGFjdGluZyBhcyBhIHByb2R1Y2VyIChl
aXRoZXIgZGlyZWN0bHkgdG8gdGhlCglJbnRlcm5ldCBvciBpbmRpcmVjdGx5IHRocm91Z2ggdGhl
IHVzZSBvZiBzb21lIGZvcm0gb2YKCWFwcGxpY2F0aW9uLWxheWVyIGdhdGV3YXkpLCB0aGUgSW9U
IGRldmljZSBuZWVkIG9ubHkgYWN0IGFzIGEKCWNvbnN1bWVyLiBXaGVuIGl0IGhhcyBkYXRhIHRv
IHByb3ZpZGUsIGl0IGlzc3VlcyBhCgkicGhvbmUtaG9tZSIgSW50ZXJlc3QgbWVzc2FnZSB0byBh
IHByZS1jb25maWd1cmVkIHJlbmRlenZvdXMKCW5hbWUgKGUuZy4gYW4gYXBwbGljYXRpb24tbGF5
ZXIgZ2F0ZXdheSBvciBJQ04gPHhyZWYKCXRhcmdldD0iQ2hlbjIwMTUiPlJlcG88L3hyZWY+KSBh
bmQgcHJvdmlkZXMgYSByZWZsZXhpdmUgbmFtZQoJcHJlZml4IFRMViBmb3IgdGhlIGRhdGEgaXQg
d2lzaGVzIHRvIHB1Ymxpc2guIFRoZSB0YXJnZXQKCXByb2R1Y2VyIG1heSB0aGVuIGlzc3VlIHRo
ZSBuZWNlc3NhcnkgcmVmbGV4aXZlIEludGVyZXN0CgltZXNzYWdlKHMpIHRvIGZldGNoIHRoZSBk
YXRhLiBPbmNlIGZldGNoZWQsIHZhbGlkYXRlZCwgYW5kCglzdG9yZWQsIHRoZSBwcm9kdWNlciB0
aGVuIHJlc3BvbmRzIHRvIHRoZSBvcmlnaW5hbCBJbnRlcmVzdAoJbWVzc2FnZSB3aXRoIGEgc3Vj
Y2VzcyBpbmRpY2F0aW9uLCBwb3NzaWJseSBjb250YWluaW5nIGEgRGF0YQoJb2JqZWN0IGlmIG5l
ZWRlZCB0byBhbGxvdyB0aGUgb3JpZ2luYXRpbmcgZGV2aWNlIHRvIG1vZGlmeSBpdHMKCWludGVy
bmFsIHN0YXRlLiBBbHRlcm5hdGl2ZWx5LCB0aGUgcHJvZHVjZXIgbWlnaHQgY2hvb3NlIHRvCglu
b3QgcmVzcG9uZCBhbmQgYWxsb3cgdGhlIG9yaWdpbmFsIEludGVyZXN0IHRvIHRpbWUgb3V0LAoJ
YWx0aG91Z2ggdGhpcyBpcyBOT1QgUkVDT01NRU5ERUQgZXhjZXB0IGluIGNhc2VzIHdoZXJlIHRo
ZQoJZXh0cmEgbWVzc2FnZSB0cmFuc21pc3Npb24gYmFuZHdpdGggaXMgYXQgYSBwcmVtaXVtIGNv
bXBhcmVkCgl0byB0aGUgcGVyc2lzdGVuY2Ugb2Ygc3RhbGUgc3RhdGUgaW4gdGhlIGZvcndhcmRl
cnMuIFdlIG5vdGUKCXRoYXQgdGhpcyBpbnRlcmFjdGlvbiBhcHByb2FjaCBtaXJyb3JzIHRoZSBl
YXJsaWVyIGVmZm9ydHMgdXNpbmcKCUludGVyZXN0LUludGVyZXN0LURhdGEgZGVzaWducy4KICAg
ICAgPC90PgoKICAgICAgPHQ+Cgk8eHJlZiB0YXJnZXQ9InBob25laG9tZS1tZXNzYWdlLWZsb3ci
Lz4gZGVwaWN0cyB0aGlzCglpbnRlcmFjdGlvbiB3aXRoIHRoZSBPUFRJT05BTCBEMSBtZXNzYWdl
LiBTZWUgPHhyZWYKCXRhcmdldD0ib3ZlcmFsbC1tZXNzYWdlLWZsb3cyIi8+IGZvciB0aGUgZGV0
YWlscyBvZiB0aGUKCWdlbmVyYWwgUmVmbGV4aXZlIEZvcndhcmRpbmcgaW50ZXJhY3Rpb24uCiAg
ICAgIDwvdD4KICAgICAgCiAgICAgIDxmaWd1cmUgYW5jaG9yPSJwaG9uZWhvbWUtbWVzc2FnZS1m
bG93Ij4KCTxuYW1lPiJQaG9uZSBIb21lIiBNZXNzYWdlIEZsb3c8L25hbWU+Cgk8YXJ0d29yayB0
eXBlPSJhc2NpaS1hcnQiIHNyYz0icGhvbmVob21lLnR4dCIvPgoJPGFydHdvcmsgdHlwZT0iYXNj
aWktYXJ0Ij4KICAgIExlZ2VuZDoKICAgIEkxOiBJbnRlcmVzdCAjMSBjb250YWluaW5nIHRoZSBS
ZWZsZXhpdmUgTmFtZSBQcmVmaXggVExWCiAgICBEMTogRGF0YSBtZXNzYWdlIChPUFRJT05BTCks
IGZpbmFsaXppbmcgaW50ZXJhY3Rpb24KICAgIEQxOiBEYXRhIG1lc3NhZ2UsIGFuc3dlcmluZyBS
SSwgcmV0dXJuaW5nIElvVCBkYXRhIG9iamVjdAoJPC9hcnR3b3JrPgogICAgICA8L2ZpZ3VyZT4K
CiAgICAgIDx0PgoJVGhlcmUgYXJlIHR3byBhcHByb2FjaGVzIHRoYXQgdGhlIElvVCBkZXZpY2Ug
Y2FuIHVzZSBmb3IKCWl0cyByZXNwb25zZSB0byBhIHJlZmxleGl2ZSBJbnRlcmVzdC4gSXQgY2Fu
IHNpbXBseSBjb25zdHJ1Y3QKCWEgRGF0YSBNZXNzYWdlIGJvdW5kIHRocm91Z2ggdGhlIHVzdWFs
IElDTiBoYXNoIG5hbWUgdG8gdGhlCglyZWZsZXhpdmUgSW50ZXJlc3QgbmFtZS4gU2luY2UgdGhl
IHNjb3BlIG9mIGFueSBkYXRhIG9iamVjdAoJYm91bmQgaW4gdGhpcyB3YXkgaXMgb25seSB0aGUg
ZHVyYXRpb24gb2YgdGhlIGVuY2xvc2luZwoJSW50ZXJlc3QtRGF0YSBleGNoYW5nZSAoc2VlIDx4
cmVmCgl0YXJnZXQ9ImNvbnN1bWVyLWltcGxlbWVudGF0aW9uIi8+KSB0aGUgcHJvZHVjZXIgd291
bGQgbmVlZCB0bwoJaXRzZWxmIGNvbnN0cnVjdCBhbnkgcGVyc2lzdGVudCBEYXRhIG9iamVjdCwg
bmFtZSBpdCwgYW5kIHNpZ24KCWl0LiBUaGlzIGlzIHNvbWV0aW1lcyB0aGUgcmlnaHQgYXBwcm9h
Y2gsIGFzIGZvciBzb21lCglhcHBsaWNhdGlvbnMgdGhlIGlkZW50aXR5IG9mIHRoZSBvcmlnaW5h
dGluZyBJb1QgZGV2aWNlIGlzIG5vdAoJaW1wb3J0YW50IGZyb20gYW4gb3BlcmF0aW9uYWwgb3Ig
c2VjdXJpdHkgcG9pbnQgb2YgdmlldzsgaW4KCWNvbnRyYXN0IHRoZSBpZGVudGl0eSBvZiB0aGUg
Z2F0ZXdheSBvciBSZXBvIGlzIHdoYXQgbWF0dGVycy4KICAgICAgPC90PgoJCQogICAgICA8dD4K
CUlmIGFsdGVybmF0aXZlbHksIHRoZSBwZXJzaXN0ZW50IERhdGEgb2JqZWN0IHNob3VsZCBiZSBi
b3VuZAoJZnJvbSBhIG5hbWluZyBhbmQgc2VjdXJpdHkgcG9pbnQgb2YgdmlldyB0byB0aGUgb3Jp
Z2luYXRpbmcKCUlvVCBkZXZpY2UsIHRoaXMgY2FuIGJlIGVhc2lseSBhY2NvbXBsaXNoZWQuIElu
c3RlYWQgb2YKCWRpcmVjdGx5IHBsYWNpbmcgdGhlIGNvbnRlbnQgaW4gYSBEYXRhIG9iamVjdCBy
ZXNwb25kaW5nIHRvCgl0aGUgcmVmbGV4aXZlIEludGVyZXN0IGFzIGFib3ZlLCB0aGUgY29uc3Vt
ZXIgZW5jYXBzdWxhdGVzIGEKCWNvbXBsZXRlIENDTngvTkROIERhdGEgbWVzc2FnZSAod2hpY2gg
aW5jbHVkZXMgdGhlIGRlc2lyZWQgbmFtZQoJb2YgdGhlIGRhdGEpIGFzIGluIHRoZSByZXNwb25z
ZSB0byB0aGUgcmVmbGV4aXZlIEludGVyZXN0CgltZXNzYWdlLgo8IS0tCgk8Y3JlZiBzb3VyY2U9
IkRPIiBkaXNwbGF5PSJmYWxzZSI+CgkgIFdlIG1heSBuZWVkIHRvIHRoaW5rIGlmIHRoaXMgZXhh
Y2VyYmF0ZXMgcG9pc29uaW5nL3BvbGx1dGlvbgoJICBhdHRhY2tzIC0gSSB0aGluayBub3QgYnV0
IG5lZWQgdG8gbm9vZGxlIG9uIHRoaXMgYSBiaXQuCgk8L2NyZWY+Ci0tPgogICAgICA8L3Q+CiAg
ICAgIDx0PgoJVGhlIGludGVyYWN0aW9uIG1vZGVsIGRlc2NyaWJlZCBhYm92ZSBicmluZ3MgYSBu
dW1iZXIKCXBvdGVudGlhbCBhZHZhbnRhZ2VzLCBzb21lIG9idmlvdXMsIHNvbWUgbGVzcyBzby4g
V2UgZW51bWVyYXRlCglhIGZldyBvZiB0aGVtIGFzIGZvbGxvd3M6CiAgICAgIDwvdD4KCQkKICAg
ICAgPHVsPgoJPGxpPgoJICBCeSBub3QgcmVxdWlyaW5nIHRoZSBJb1QgZGV2aWNlIHRvIGJlIGFj
dGl2ZWx5IGxpc3RlbmluZyBmb3IKCSAgSW50ZXJlc3RzLCBpdCBjYW4gc2xlZXAgYW5kIG9ubHkg
d2FrZSB1cCBpZiBpdCBoYXMgc29tZXRoaW5nCgkgIHRvIGNvbW11bmljYXRlLiBDb252ZXJzZWx5
LCBwYXJ0aWVzIGludGVyZXN0ZWQgaW4gb2J0YWluaW5nCgkgIGRhdGEgZnJvbSB0aGUgZGV2aWNl
IGRvIG5vdCBuZWVkIHRvIGJlIGNvbnN0YW50bHkgcG9sbGluZyBpbgoJICBvcmRlciB0byBhc2Nl
cnRhaW4gaWYgdGhlcmUgaXMgbmV3IGRhdGEgYXZhaWxhYmxlLgoJPC9saT4KCQoJPGxpPgoJICBO
byBmb3J3YXJkZXIgcmVzb3VyY2VzIGFyZSB0aWVkIHVwIHdpdGggc3RhdGUgYXBhcnQgZnJvbSB0
aGUKCSAgYWN0dWFsIHJlZmxleGl2ZSBmb3J3YXJkaW5nIGludGVyYWN0aW9ucy4gQWxsIHRoYXQg
aXMgbmVlZGVkCgkgIGlzIGVub3VnaCByb3V0aW5nIHN0YXRlIGluIHRoZSBGSUIgdG8gYmUgYWJs
ZSB0byBmb3J3YXJkIHRoZQoJICAicGhvbmUgaG9tZSIgSW50ZXJlc3QgdG8gYW4gYXBwcm9wcmlh
dGUgdGFyZ2V0CgkgIHByb2R1Y2VyLiBXaGlsZSB0aGlzIG1vZGVsIGRvZXMgbm90IHByb3ZpZGUg
YWxsIHRoZSByaWNobmVzcwoJICBvZiBhIGZ1bGwgUHViL1N1YiBzeXN0ZW0gKGxpa2UgdGhhdCBk
ZXNjcmliZWQgaW4gPHhyZWYKCSAgdGFyZ2V0PSJHdW5kb2dhbjIwMTgiLz4pIHdlIGFyZ3VlIGl0
IGlzIGFkZXF1YXRlIGZvciBhIGxhcmdlCgkgIHN1YmNsYXNzIG9mIHN1Y2ggYXBwbGljYXRpb25z
LgoJPC9saT4KCQkJCgk8bGk+CgkgIFRoZSByZWZsZXhpdmUgaW50ZXJlc3QsIHRocm91Z2ggZWl0
aGVyIGEgbmFtZSBzdWZmaXggb3IKCSAgSW50ZXJlc3QgcGF5bG9hZCwgY2FuIGdpdmUgdGhlIElv
VCBkZXZpY2UgdXNlZnVsIGNvbnRleHQKCSAgZnJvbSB3aGljaCB0byBjcmFmdCBpdHMgRGF0YSBv
YmplY3QgaW4gcmVzcG9uc2UuIE9uZSBoaWdobHkKCSAgdXNlZnVsIHBhcmFtZXRlciB3b3VsZCBi
ZSBhIHJvYnVzdCBjbG9jayB2YWx1ZSBmb3IgdGhlCgkgIGRldmljZSB0byB1c2UgYXMgYSB0aW1l
c3RhbXAgb2YgdGhlIGRhdGEsIHBvc3NpYmx5IGFzIHBhcnQKCSAgb2YgaXRzIG5hbWUgdG8gY29y
cmVjdGx5IHBsYWNlIGl0IGluIGEgdGltZSBzZXJlcyBvZiBzZW5zb3IKCSAgcmVhZGluZ3MuIFRo
aXMgc3Vic3RhbnRpYWxseSBhbGxldmlhdGVzIHRoZSBuZWVkIGZvciBsb3ctZW5kCgkgIGRldmlj
ZXMgdG8gaGF2ZSBhIHJvYnVzdCB0aW1lIGJhc2UsIGFzIGxvbmcgYXMgdGhleSB0cnVzdAoJICB0
aGUgcHJvZHVjZXIgdGhleSBjb250YWN0IHRvIHByb3ZpZGUgaXQuCgk8L2xpPgogICAgICA8L3Vs
PgogICAgICAKICAgIDwvc2VjdGlvbj4KCiAgICA8IS0tCiAgICAgIDxzZWN0aW9uIGFuY2hvcj0i
c3RhdGUtc3luY2hyb25pemF0aW9uIj48bmFtZT5BY2hpZXZpbmcgcGVlciBzdGF0ZSBzeW5jaHJv
bml6YXRpb24gd2l0aCBSZWZsZXhpdmUgSW50ZXJlc3RzPC9uYW1lPgogICAgICA8dD48Y3JlZiBz
b3VyY2U9IkRPIj48c3Ryb25nPlRCRC48L3N0cm9uZz4gVGFsayBhYm91dCBwZWVyIHNlc3Npb24g
ZXN0YWJsaXNobWVudCwKCUF1dGh6LCBrZXkgZXhjaGFuZ2UsIHBlcmhhcHMgb3RoZXIgdXNlIGNh
c2VzPzwvY3JlZj48L3Q+CiAgICAgIDwvc2VjdGlvbj4KLS0+CiAgPC9zZWN0aW9uPgoKCgogIDxz
ZWN0aW9uIGFuY2hvcj0iaW1wbGVtZW50YXRpb24tY29uc2lkZXJhdGlvbnMiPgoJICA8bmFtZT5J
bXBsZW1lbnRhdGlvbiBDb25zaWRlcmF0aW9uczwvbmFtZT4KICAgICAgPHQ+VGhlcmUgYXJlIGEg
bnVtYmVyIG9mIGltcG9ydGFudCBhc3BlY3RzIHRvIHRoZSByZWZsZXhpdmUgZm9yd2FyZGluZyBk
ZXNpZ24gd2hpY2ggYWZmZWN0IGNvcnJlY3RuZXNzIGFuZCBwZXJmb3JtYW5jZSBvZiBleGlzdGlu
ZyBmb3J3YXJkZXIsIGNvbnN1bWVyLCBhbmQgcHJvZHVjZXIgaW1wbGVtZW50YXRpb25zIGRlc2ly
aW5nIHRvIHN1cHBvcnQgaXQuIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgdGhlIGVmZmVjdCBvbiBl
YWNoIG9mIHRoZXNlIGVsZW1lbnRzIG9mIHRoZSBDQ054L05ETiBwcm90b2NvbCBhcmNoaXRlY3R1
cmUuPC90PgogICAgICAKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJmb3J3YXJkZXItaW1wbGVtZW50
YXRpb24iPgogICAgICA8bmFtZT5Gb3J3YXJkZXIgaW1wbGVtZW50YXRpb24gY29uc2lkZXJhdGlv
bnM8L25hbWU+CiAgICAgIAogICAgICAJPHNlY3Rpb24gYW5jaG9yPSJGSUIiPgogICAgICAJPG5h
bWU+Rm9yd2FyZGluZyBJbmZvcm1hdGlvbiBCYXNlIChGSUIpPC9uYW1lPgogICAgICAJCTx0PlRo
ZSBGSUIgaXMgYSBwZXJmb3JtYW5jZS1jcml0aWNhbCBkYXRhIHN0cnVjdHVyZSBpbiBhbnkgZm9y
d2FyZGVyLCBhcyBpdCBuZWVkcyB0byBzdXBwb3J0IHJlbGF0aXZlbHkgZXhwZW5zaXZlIGxvbmdl
c3QgbmFtZSBwcmVmaXggbWF0Y2ggKExOUE0pIGxvb2t1cCBhbGdvcml0aG1zLiBBIG51bWJlciBv
ZiB3ZWxsLWtub3duIEZJQiBkYXRhIHN0cnVjdHVyZXMgYXJlIGhlYXZpbHkgb3B0aW1pemVkIGZv
ciByZWFkIGFjY2Vzcywgc2luY2UgZm9yIG5vcm1hbCBJbnRlcmVzdCBtZXNzYWdlIHByb2Nlc3Np
bmcgdGhlIEZJQiBjaGFuZ2VzIHNsb3dseSAtIG9ubHkgYWZ0ZXIgdG9wb2xvZ2ljYWwgY2hhbmdl
cyBvciByb3V0aW5nIHByb3RvY29sIHVwZGF0ZXMuIFN1cHBvcnQgZm9yIHJlZmxleGl2ZSBuYW1l
cyBjaGFuZ2VzIHRoaXMsIGFzIEZJQiBlbnRyaWVzIGFyZSBjcmVhdGVkIGFuZCBkZXN0cm95ZWQg
cmFwaWRseSBhcyBJbnRlcmVzdCBtZXNzYWdlcyBjb250YWluaW5nIHJlZmxleGl2ZSBuYW1lIFRM
VnMgYXJlIHByb2Nlc3NlZCBhbmQgdGhlIGNvcnJlc3BvbmRpbmcgRGF0YSBtZXNzYWdlcyBjb21l
IGJhY2suPC90PgogICAgICAJCQogICAgICAJCTx0PldoaWxlIGl0IG1heSBiZSBmZWFzaWJsZSwg
ZXNwZWNpYWxseSBpbiBsb3ctZW5kIGZvcndhcmRlcnMgaGFuZGxpbmcgYSBsb3cgcGFja2V0IGZv
cndhcmRpbmcgcmF0ZSB0byBpZ25vcmUgdGhpcyBwcm9ibGVtLCBmb3IgaGlnaC1zcGVlZCBmb3J3
YXJkZXJzIHRoZXJlIGFyZSBhIG51bWJlciBvZiBoYXphcmRzLCBpbmNsdWRpbmc6PC90PgogICAg
ICAJCTxvbD4KICAgICAgCQkJPGxpPklmIHRoZSBlbnRpcmUgRklCIG5lZWRzIHRvIGJlIGxvY2tl
ZCBpbiBvcmRlciB0byBpbnNlcnQgb3IgcmVtb3ZlIGVudHJpZXMsIHRoaXMgY291bGQgY2F1c2Ug
aW5mbGF0ZWQgZm9yd2FyZGluZyBkZWxheXMgb3IgaW4gZXh0cmVtZSBjYXNlcywgZm9yd2FyZGlu
ZyBwZXJmb3JtYW5jZSBjb2xsYXBzZS48L2xpPgogICAgICAJCQk8bGk+QSBudW1iZXIgb2YgaGln
aC1zcGVlZCBmb3J3YXJkZXIgaW1wbGVtZW50YXRpb25zIGVtcGxveSBhIHNoYXJkZWQgUElUIHNj
aGVtZSB0byBiZXR0ZXIgcGFyYWxsZWxpemUgZm9yd2FyZGluZyBhY3Jvc3MgcHJvY2Vzc2luZyBj
b3Jlcy4gVGhlIEZJQiwgaG93ZXZlciwgaXMgc3RpbGwgYSBzaGFyZWQgZGF0YSBzdHJ1Y3R1cmUg
d2hpY2ggaXMgZWl0aGVyIHJlYWQgd2l0aG91dCByZWFkIGxvY2tzIGFjcm9zcyBjb3Jlcywgb3Ig
ZXhwbGljaXRseSBjb3BpZWQgc3VjaCB0aGF0IHRoZXJlIGlzIGEgc2VwYXJhdGUgY29weSBvZiB0
aGUgRklCIGZvciBlYWNoIFBJVCBzaGFyZC4gQ2xlYXJseSwgYSBoaWdoIHVwZGF0ZSByYXRlIHdp
dGhvdXQgcmVhZCBsb2NrcyBhbmQvb3IgdXBkYXRpbmcgbWFueSBjb3BpZXMgb2YgdGhlIEZJQiBh
cmUgdW5hdHRyYWN0aXZlIGltcGxlbWVudGF0aW9uIG9wdGlvbnMuIChOb3RlOiB3aXRoIHRoaXMg
cmVmbGV4aXZlIG5hbWUgc2NoZW1lIGl0IGlzIG5vdCBmZWFzaWJsZSB0byBmb3JjZSByZWZsZXhp
dmUgaW50ZXJlc3RzIHRvIGJlIGhhc2hlZCBvciBiZSBvdGhlcndpc2UgZGlyZWN0ZWQgdG8gdGhl
IFBJVCBzaGFyZCBob2xkaW5nIHRoZSBvcmlnaW5hbCBJbnRlcmVzdCBzdGF0ZSkuPC9saT4KICAg
ICAgCQk8L29sPgogICAgICAJCQogICAgICAJCTx0PlRoZXJlIGFyZSBhbnkgbnVtYmVyIG9mIGFs
dGVybmF0aXZlIEZJQiBpbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW4gd29yayB3ZWxsIGhvd2V2ZXIu
IFRoZSBtb3N0IHN0cmFpZ2h0Zm9yd2FyZCBpcyB0byBzaW1wbHkgaW1wbGVtZW50IGEgInNwZWNp
YWwiIEZJQiBmb3IganVzdCByZWZsZXhpdmUgbmFtZSBsb29rdXBzLiBUaGlzIGlzIGZlYXNpYmxl
IGJlY2F1c2UgcmVmbGV4aXZlIG5hbWVzIGRldGVybWluaXN0aWNhbGx5IGNvbnRhaW4gdGhlIGRp
c3Rpbmd1aXNoZWQgaGlnaC1vcmRlciBuYW1lIGNvbXBvbmVudCB0eXBlIG9mIFRfUkVGTEVYSVZF
X05BTUUsIHdob3NlIGNvbnRlbnQgaXMgYSA2NC1iaXQgdmFsdWUgdGhhdCBjYW4gYmUgZWFzaWx5
IGhhc2hlZCB0byBhIEZJQiBlbnRyeSBkaXJlY3RseSwgYXZvaWRpbmcgdGhlIG1vcmUgZXhwZW5z
aXZlIExOUE0gbG9va3VwLiBJbnNlcnRzIGFuZCBkZWxldGVzIHRoZW4gZGV2b2x2ZSB0byB0aGUg
d2VsbC11bmRlcnN0b29kIHByb2JsZW0gb2YgaGFzaCB0YWJsZSBtYWludGVuYW5jZS48L3Q+CiAg
ICAgIAk8L3NlY3Rpb24+CiAgICAgIAkKICAgICAgCTxzZWN0aW9uPgogICAgICAJPG5hbWU+SW50
ZXJhY3Rpb25zIHdpdGggSW50ZXJlc3QgTGlmZXRpbWU8L25hbWU+CiAgICAgIAkgICAgICAJCiAg
ICAgIAkJPHQ+SWYgYW5kIHdoZW4gYSBwcm9kdWNlciBkZWNpZGVzIHRvIGZldGNoIGRhdGEgZnJv
bSB0aGUgY29uc3VtZXIgdXNpbmcgb25lIG9yIG1vcmUgcmVmbGV4aXZlIEludGVyZXN0LURhdGEg
ZXhjaGFuZ2VzLCB0aGUgdG90YWwgbGF0ZW5jeSBmb3IgdGhlIG9yaWdpbmFsIEludGVyZXN0LURh
dGEgZXhjaGFuZ2UgaXMgaW5mbGF0ZWQsIHBvdGVudGlhbGx5IGJ5IG11bHRpcGxlIFJUVHMuIEl0
IGlzIGRpZmZpY3VsdCBmb3IgYSBjb25zdW1lciB0byBwcmVkaWN0IHRoZSBpbmZsYXRpb24gZmFj
dG9yIHdoZW4gaXNzdWluZyB0aGUgb3JpZ2luYWwgSW50ZXJlc3QsIGFuZCBoZW5jZSB0aGVyZSBj
YW4gYmUgYSBzdWJzdGFudGlhbCBoYXphcmQgb2YgdGhhdCBJbnRlcmVzdCBsaWZldGltZSBleHBp
cmluZyBiZWZvcmUgY29tcGxldGlvbiBvZiB0aGUgZnVsbCBtdWx0aS13YXkgZXhjaGFuZ2UuIFRo
aXMgY2FuIHJlc3VsdCBpbiBwZXJzaXN0ZW50IGZhaWx1cmVzLCB3aGljaCBpcyBvYnZpb3VzbHkg
aGlnaGx5IHVuZGVzaXJhYmxlLjwvdD4KICAgICAgCQogICAgICAJCTx0PlRoZXJlIGlzIGEgZmFp
cmx5IHN0cmFpZ2h0Zm9yd2FyZCB0ZWNobmlxdWUgdGhhdCBjYW4gYmUgZW1wbG95ZWQgYnkgZm9y
d2FyZGVycyB0byBhdm9pZCB0aGVzZSAiZmFsc2UiIEludGVyZXN0IGxpZmV0aW1lIGV4cGlyYXRp
b25zLiBJbiB0aGUgYWJzZW5jZSBvZiBhIHN1cGVyaW9yIGFsdGVybmF0aXZlIHRlY2huaXF1ZSwg
aXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhbGwgZm9yd2FyZGVycyBpbXBsZW1lbnQgdGhlIGZvbGxv
d2luZyBhbGdvcml0aG0uPC90PgogICAgICAJCiAgICAgIAkJPHQ+V2hlbiBwcm9jZXNzaW5nIGFu
IEludGVyZXN0IGNvbnRhaW5pbmcgdGhlIHJlZmxleGl2ZSBuYW1lIFRMViBhbmQgY3JlYXRpbmcg
dGhlIG5lY2Vzc2FyeSBGSUIgZW50cnkgKHNlZSA8eHJlZiB0YXJnZXQ9IkZJQiIvPiBhYm92ZSks
IHRoZSBmb3J3YXJkZXIgYWxzbyBjcmVhdGVzIGEgPGVtPmJhY2sgcG9pbnRlcjwvZW0+IGZyb20g
dGhhdCBGSUIgZW50cnkgdG8gdGhlIFBJVCBlbnRyeSBmb3IgdGhlIEludGVyZXN0IG1lc3NhZ2Ug
dGhhdCBjcmVhdGVkIGl0LiBUaGlzIFBJVCBlbnRyeSBjb250YWlucyB0aGUgY3VycmVudCB2YWx1
ZSBvZiB0aGUgcmVtYWluaW5nIEludGVyZXN0IGxpZmV0aW1lIG9yIGFsdGVybmF0aXZlbHkgYSB2
YWx1ZSBmcm9tIHdoaWNoIHRoZSByZW1haW5pbmcgSW50ZXJlc3QgbGlmZXRpbWUgY2FuIGJlIGVh
c2lseSBjb21wdXRlZC4gQ2FsbCB0aGlzIHZhbHVlIDxlbT5JTDxzdWI+dDwvc3ViPjwvZW0+Ljwv
dD4KICAgICAgCQogICAgICAJCTx0PklmIGFuZCB3aGVuIGEgcmVmbGV4aXZlIEludGVyZXN0IGFy
cml2ZXMgZnJvbSB1cHN0cmVhbSBtYXRjaGluZyB0aGUgcmVmbGV4aXZlIEZJQiBlbnRyeSwgdGhl
IGZvcndhcmRlciBleGFtaW5lcyB0aGUgSW50ZXJlc3QgbGlmZXRpbWUgb2YgdGhlIGFycml2aW5n
IHJlZmxleGl2ZSBJbnRlcmVzdC4gQ2FsbCB0aGlzIHZhbHVlIDxlbT5JTDxzdWI+cjwvc3ViPjwv
ZW0+LiBUaGUgZm9yd2FyZGVyIGNvbXB1dGVzIE1BWCg8ZW0+SUw8c3ViPnQ8L3N1Yj4sIChJTDxz
dWI+cjwvc3ViPiAqIDEuNSk8L2VtPiksIGFuZCByZXBsYWNlcyA8ZW0+SUw8c3ViPnQ8L3N1Yj48
L2VtPiB3aXRoIHRoaXMgdmFsdWUuIFRoaXMgaW4gZWZmZWN0IGVuc3VyZXMgdGhhdCB0aGUgcmVt
YWluaW5nIEludGVyZXN0IGxpZmV0aW1lIG9mIHRoZSBvcmlnaW5hbCBJbnRlcmVzdCBhY2NvdW50
cyBmb3IgdGhlIGFkZGl0aW9uYWwgMS41IFJUVHMgdGhhdCBtYXkgb2NjdXIgYXMgYSByZXN1bHQg
b2YgdGhlIHJlZmxleGl2ZSBJbnRlcmVzdC1EYXRhIGV4Y2hhbmdlLjwvdD4KICAgICAgCQkKICAg
ICAgCQk8dD5JZiB0aGUgYWJvdmUgYWxnb3JpdGhtIGlzIGltcGxlbWVudGVkIG5haXZlbHkgYXMg
ZGVzY3JpYmVkIGFib3ZlLCBpdCBtYXkgcnVuIGFmb3VsIG9mIGEgc2hhcmRlZCBQSVQgZm9yd2Fy
ZGVyIGltcGxlbWVudGF0aW9uLCBzaW5jZSB0aGUgUElUIGVudHJ5IGZvciB0aGUgcmVmbGV4aXZl
IEludGVyZXN0IGFuZCB0aGUgUElUIGVudHJ5IGZvciB0aGUgb3JpZ2luYWwgSW50ZXJlc3QgbWF5
IGJlIGluIGRpZmZlcmVudCBzaGFyZHMuIFRoZXJlZm9yZSwgaWYgdGhlIHVwZGF0ZSBpcyBkb25l
IGNyb3NzLXNoYXJkIG9uIGVhY2ggcmVmbGV4aXZlIEludGVyZXN0IGFycml2YWwsIHBlcmZvcm1h
bmNlIG1heSBzdWZmZXIsIHBlcmhhcHMgZHJhbWF0aWNhbGx5LiBJbnN0ZWFkLCB0aGUgZm9sbG93
aW5nIGFwcHJvYWNoIHRvIHVwZGF0aW5nIHRoZSBJbnRlcmVzdCBsaWZldGltZSBhZnRlciBjb21w
dXRpbmcgdGhlIG5ldyB2YWx1ZSBpcyBSRUNPTU1NRU5ERUQgZm9yIHNoYXJkZWQtUElUIGZvcndh
cmRlcnMuPC90PgogICAgICAJCQogICAgICAJCTx0PldoZW4gY3JlYXRpbmcgdGhlICByZWZsZXhp
dmUgRklCIGVudHJ5IGFzIGFib3ZlIGluIDx4cmVmIHRhcmdldD0iRklCIi8+LCBjb3B5IHRoZSBy
ZW1haW5pbmcgSW50ZXJlc3QgbGlmZXRpbWUgZnJvbSB0aGUgUElUIGVudHJ5LiBEbyB0aGUgUElU
IHVwZGF0ZSBpZiBhbmQgb25seSBpZiB0aGlzIHZhbHVlIGlzIGFib3V0IHRvIGV4cGlyZSwgdGh1
cyBwYXlpbmcgdGhlIGNyb3NzLXNoYXJkIHVwZGF0ZSBjb3N0IG9ubHkgaWYgdGhlIG9yaWdpbmFs
IEludGVyZXN0IGlzIGFib3V0IHRvIGV4cGlyZS4gQSBmdXJ0aGVyIG9wdGltaXphdGlvbiBhdCB0
aGUgY29zdCBvZiBtb2Rlc3QgZXh0cmEgY29tcGxleGl0eSBpcyB0byBpbnN0ZWFkIDxlbT5xdWV1
ZTwvZW0+IHRoZSB1cGRhdGUgdG8gdGhlIGNvcmUgaG9sZGluZyB0aGUgc2hhcmQgb2YgdGhlIG9y
aWdpbmFsIFBJVCBlbnRyeSByYXRoZXIgdGhhbiBkb2luZyB0aGUgdXBkYXRlIGRpcmVjdGx5LiBJ
ZiB0aGUgUElUIGVudHJ5IGV4cGlyZXMgb3IgaXMgc2F0aXNmaWVkLCBpbnN0ZWFkIG9mIHJlbW92
aW5nIGl0IHRoZSBhc3NvY2lhdGVkIGNvcmUgY2hlY2tzIHRoZSB1cGRhdGUgcXVldWUgYW5kIGRv
ZXMgdGhlIG5lY2Vzc2FyeSB1cGRhdGUuPC90PgogICAgICAJCQogICAgICAJCTx0IGFuY2hvcj0i
cmVmbGV4aXZlLXByb2R1Y2VyLWhhemFyZCI+V2hpbGUgdGhlIGFib3ZlIGFwcHJvYWNoIG9mIGlu
ZmxhdGluZyB0aGUgaW50ZXJlc3QgbGlmZXRpbWUgb2YgdGhlIG9yaWdpbmFsIEludGVyZXN0IHRv
IGFjY29tbW9kYXRlIHRoZSBhZGRpdGlvbmFsIFJUVHMgb2YgcmVmbGV4aXZlIEludGVyZXN0LURh
dGEgZXhjaGFuZ2VzLCB0aGlzIGRvZXMgaW50cm9kdWNlIGEgbmV3IHZ1bG5lcmFiaWxpdHkgdGhh
dCBtdXN0IGJlIGRlYWx0IHdpdGguIEEgUHJvZHVjZXIsIGVpdGhlciB0aHJvdWdoIGEgYnVnIG9y
IG1hbGljaW91cyBpbnRlbnQsIGNvdWxkIGtlZXAgYW4gb3JpZ2luYXRpbmcgSW50ZXJlc3QtRGF0
YSBleGNoYW5nZSBhbGl2ZSBieSBjb250aW51aW5nIHRvIHNlbmQgcmVmbGV4aXZlIEludGVyZXN0
cyBiYWNrIHRvIHRoZSBjb25zdW1lciwgd2hpbGUgdGhlIGNvbnN1bWVyIGhhZCBubyB3YXkgdG8g
dGVybWluYXRlIHRoZSBlbmNsb3NpbmcgaW50ZXJhY3Rpb24gKHRoZXJlIGlzIG5vICJjYW5jZWwg
SW50ZXJlc3QiIGZ1bmN0aW9uIGluIGVpdGhlciBORE4gbm9yIENDTngpLiBUbyBlbGltaW5hdGUg
dGhpcyBoYXphcmQsIGlmIHRoZSBjb25zdW1lciByZWplY3RzIGEgcmVmbGV4aXZlIGludGVyZXN0
IHdpdGggYSBUX1JFVFVSTl9QUk9ISUJJVEVEIGVycm9yLCB0aGUgZm9yd2FyZGVyKHMpLCBpbiBh
ZGRpdGlvbiB0byBzYXRpc2Z5aW5nIHRoZSBjb3Jlc3BvbmRpbmcgUElUIGVudHJ5LCBNVVNUIGFs
c28gZGVsZXRlIHRoZSBhc3NvY2lhdGVkIHJlZmxleGl2ZSBGSUIgZW50cnksIHRoZXJlYnkgcHJl
dmVudGluZyBhbnkgZnVydGhlciByZWZsZXhpdmUgSW50ZXJlc3RzIGZyb20gcmVhY2hpbmcgdGhl
IGNvbnN1bWVyLiBUaGlzIGFsbG93cyB0aGUgZW5jbG9zaW5nIEludGVyZXN0LURhdHNhIGV4Y2hh
bmdlIHRvIGVpdGhlciB0aW1lIG91dCBvciBiZSBjb3JyZWN0bHkgZW5kZWQgd2l0aCBhIERhdGEg
bWVzc2FnZSBvciBJbnRlcmVzdCBSZXR1cm4gZnJvbSB0aGUgUHJvZHVjZXIuPC90PgogICAgICAJ
CQogICAgICAJPC9zZWN0aW9uPgoJICAKICAgICAgCTxzZWN0aW9uIGFuY2hvcj0iaW50ZXJlc3Qt
YWdncmVnYXRpb24iPjxuYW1lPkludGVyYWN0aW9ucyB3aXRoIEludGVyZXN0IGFnZ3JlZ2F0aW9u
PC9uYW1lPgogICAgICAJPHQ+QXMgd2l0aCBudW1lcm91cyBvdGhlciBzaXR1YXRpb25zIHdoZXJl
IG11bHRpcGxlIEludGVyZXN0cyBmb3IgdGhlIHNhbWUgbmFtZWQgb2JqZWN0IGFycml2ZSBjb250
YWluaW5nIGRpZmZlcmVudCBwYXJhbWV0ZXJzIChlLmcuIEludGVyZXN0IExpZmV0aW1lLCBRb1Ms
IHBheWxvYWQgaGFzaCkgdGhlIHNhbWUgcGhlbm9tZW5vbiBvY2N1cnMgZm9yIHRoZSByZWZsZXhp
dmUgTmFtZSBUTFYuIElmIHN1Y2ggSW50ZXJlc3RzIGNvbGxpZGUsIHRoZSBmb3J3YXJkZXIgTVVT
VCBOT1QgYWdncmVnYXRlIHRoZXNlIEludGVyZXN0IG1lc3NhZ2VzIGFuZCBpbnN0ZWFkIE1VU1Qg
Y3JlYXRlIGEgc2VwYXJhdGUgUElUIGVudHJ5IGZvciBlYWNoLjwvdD4KICAgICAgCTwvc2VjdGlv
bj4KICAgIDwvc2VjdGlvbj4KICAgIAogICAgICA8c2VjdGlvbiBhbmNob3I9ImNvbnN1bWVyLWlt
cGxlbWVudGF0aW9uIj4KICAgICAgPG5hbWU+Q29uc3VtZXIgSW1wbGVtZW50YXRpb24gQ29uc2lk
ZXJhdGlvbnM8L25hbWU+CiAgICAJCiAgICAJPHNlY3Rpb24+PG5hbWU+RGF0YSBvYmplY3RzIHJl
dHVybmVkIGJ5IHRoZSBjb25zdW1lciB0byByZWZsZXhpdmUgbmFtZSBJbnRlcmVzdHMgYXJyaXZp
bmcgZnJvbSBhIHByb2R1Y2VyPC9uYW1lPgogICAgCQkKICAgIAkJCiAgICAJCTx0PlRoZSBEYXRh
IG9iamVjdHMgcmV0dXJuZWQgdG8gdGhlIHByb2R1Y2VyIGluIHJlc3BvbnNlIHRvIGEgcmVmbGV4
aXZlIEludGVyZXN0IGFyZSBub3JtYWwgQ0NOeC9ORE4gZGF0YSBvYmplY3RzLiBJdCBpcyB0aGVy
ZWZvcmUgd29ydGggbm90aW5nIHRoYXQgdGhlIG9iamVjdCBpcyBib3VuZCB0byB0aGUgcmVmbGV4
aXZlIEludGVyZXN0IGZ1bGwgbmFtZSB2aWEgdGhlIGhhc2ggYW5kIGhlbmNlIHRoZSBzY29wZSBv
ZiB0aGUgb2JqZWN0IGlzIHVuZGVyIG1vc3QgY2lyY3Vtc3RhbmNlcyBtZWFuaW5nZnVsIG9ubHkg
Zm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgZW5jbG9zaW5nIEludGVyZXN0LURhdGEgaW50ZXJhY3Rp
b24uIFRoaXMgcHJvcGVydHkgaXMgaWRlYWwgZm9yIG5hbWluZyBhbmQgc2VjdXJpbmcgZGF0YSB0
aGF0IGlzICJwYXJ0IG9mIiB0aGUgZW5jbG9zaW5nIGludGVyYWN0aW9uIC0gdGhpbmdzIGxpa2Ug
bWV0aG9kIGFyZ3VtZW50cywgYXV0aGVudGljYXRvcnMsIGFuZCBrZXkgZXhjaGFuZ2UgcGFyYW1l
dGVycywgYnV0IG5vdCBmb3IgdGhlIGNyZWF0aW9uIGFuZCBuYW1pbmcgb2Ygb2JqZWN0cyBpbnRl
bmRlZCB0byBzdXJ2aXZlIG91dHNpZGUgdGhlIGN1cnJlbnQgaW50ZXJhY3Rpb24ncyBzY29wZSAo
Yy5mLiA8eHJlZiB0YXJnZXQ9InBob25lLWhvbWUiLz4sIHdoaWNoIGRlc2NyaWJlcyBob3cgdG8g
cHJvdmlkZSBnbG9iYWxseS1uYW1lZCBvYmplY3RzIHVzaW5nIGVuY2Fwc3VsYXRpb24pLiBJbiBn
ZW5lcmFsLCB0aGUgY29uc3VtZXIgc2hvdWxkIHVzZSB0aGUgZm9sbG93aW5nIGd1aWRlbGluZXMg
aW4gY3JlYXRpbmcgRGF0YSBtZXNzYWdlcyBpbiByZXNwb25zZSB0byByZWZsZXhpdmUgSW50ZXJl
c3QgbWVzc2FnZXMgZnJvbSB0aGUgcHJvZHVjZXIuPC90PgogICAgCQkKICAgIAkJPG9sIHR5cGU9
IiglYykiPgogICAgCQkJPGxpPlNldCB0aGUgcmVjb21tZW5kZWQgY2FjaGUgdGltZSAoVF9DQUNI
RVRJTUUpIGVpdGhlciB0byB6ZXJvLCBvciBhIHZhbHVlIG5vIGdyZWF0ZXIgdGhhbiB0aGUgSW50
ZXJlc3QgbGlmZXRpbWUgKFRfSU5UTElGRSkgb2YgdGhlIG9yaWdpbmFsIEludGVyZXN0IG1lc3Nz
YWdlLjwvbGk+CiAgICAJCQk8bGk+U2V0IHRoZSBwYXlsb2FkIHR5cGUgKFRfUEFZTERUWVBFKSBh
Y2NvcmRpbmcgdG8gdGhlIHR5cGUgb2Ygb2JqZWN0IGJlaW5nIHJldHVybmVkIChlLmcuIG9iamVj
dCwgbGluaywgbWFuaWZlc3QpPC9saT4KICAgIAkJCTxsaT5TZXQgdGhlIGV4cGlyeSB0aW1lIChU
X0VYUElSWSkgdG8gYSB2YWx1ZSBncmVhdGVyIHRoYW4gPGVtPm5vdzwvZW0+LCBhbmQgbGVzcyB0
aGFuIG9yIGVxdWFsIHRvIHRoZSA8ZW0+bm93PC9lbT4gKyBJbnRlcmVzdCBsaWZldGltZSAoVF9J
TlRMSUZFKSBvZiB0aGUgb3JpZ2luYWwgSW50ZXJlc3QgbWVzc3NhZ2UuPC9saT4KICAgIAkJPC9v
bD4KICAgIAkJCiAgICAJPC9zZWN0aW9uPgogICAgCQogICAgCTxzZWN0aW9uPjxuYW1lPlRlcm1p
bmF0aW5nIHVud2FudGVkIHJlZmxleGl2ZSBJbnRlcmVzdCBleGNoYW5nZXM8L25hbWU+CiAgICAJ
PHQ+QSBjb25zdW1lciBtYXkgd2lzaCB0byBzdG9wIHJlY2VpdmluZyByZWZseGl2ZSBJbnRlcmVz
dHMgZHVlIHRvIHBvc3NpYmxlIGVyb3JzIG9yIG1hbGljaW91cyBiZWhhdmlvciBvbiB0aGUgcGFy
dCBvZiB0aGUgcHJvZHVjZXIuIFRoZXJlZm9yZSwgaWYgdGhlIGNvbnN1bWVyIHJlY2VpdmVzIGFu
IHVud2FudGVkIHJlZmxleGl2ZSBJbnRlcmVzdCwgaXQgU0hPVUxEIHJlamVjdCB0aGF0IGludGVy
ZXN0IHdpdGggYSBUX1JFVFVSTl9QUk9ISUJJVEVEIGVycm9yLiBUaGlzIHdpbGwgcHJvdm9rZSB0
aGUgZm9yd2FyZGVycyB0byBwcmV2ZW50IGZ1cnRoZXIgcmVmbGV4aXZlIEludGVyZXN0cyBmcm9t
IHJlYWNoaW5nIHRoZSBjb25zdW1lciwgYXMgZGVzY3JpYmVkIGFib3ZlIGluIDx4cmVmIHRhcmdl
dD0icmVmbGV4aXZlLXByb2R1Y2VyLWhhemFyZCIvPi48L3Q+CiAgICAJPC9zZWN0aW9uPgogICAg
CQoJPHNlY3Rpb24+PG5hbWU+SW50ZXJhY3Rpb25zIHdpdGggY2FjaGluZzwvbmFtZT4KCTx0PgoJ
ICBUaGUgcmVmbGV4aXZlIG5hbWVkIG9iamVjdHMgcHJvdmlkZSAibG9jYWwiLCB0ZW1wb3Jhcnkg
bmFtZXMKCSAgdGhhdCBhcmUgb25seSBkZWZpbmVkIGZvciBvbmUgc3BlY2lmaWMgaW50ZXJhY3Rp
b24gYmV0d2VlbiBhCgkgIGNvbnN1bWVyIGFuZCBhIHByb2R1Y2VyLiBDb3JyZXNwb25kaW5nIERh
dGEgb2JqZWN0cyBNVVNUIE5PVAoJICBiZSBzaGFyZWQgYmV0d2VlbiBtdWx0aXBsZSBjb25zdW1l
cnMgKHZpb2xhdGluZyB0aGlzIHdvdWxkIHJlcXVpcmUgc3BlY2FpbCBneXJhdGlvbnMgYnkgdGhl
IHByb2R1Y2VyIHNpbmNlIHRoZSByZWZsZXhpdmUgTmFtZSB1dGlsaXplcyBwZXItY29uc3VtZXIv
cGVyLWludGVyYWN0aW9uIHJhbmRvbSB2YWx1ZXMpLiBBIHByb2R1Y2VyIE1VU1QgTk9UIGlzc3Vl
IGFuIEludGVyZXN0IG1lc3NhZ2UgZm9yIGFueSByZWZsZXhpdmUgbmFtZSBhZnRlciBpdCBoYXMg
c2VudCB0aGUgZmluYWwgRGF0YSBtZXNzYWdlIGFuc3dlcmluZyB0aGUgb3JpZ2luYWwgSW50ZXJl
c3QuCgk8L3Q+Cgk8dD4KCSAgRm9yd2FyZGVycyBTSE9VTEQgc3RpbGwgY2FjaGUgcmVmbGV4aXZl
IERhdGEgb2JqZWN0cyBmb3IKCSAgcmV0cmFuc21pc3Npb25zIHdpdGhpbiBhIHRyYW5zYWN0aW9u
cywgYnV0IHRoZXkgTVVTVCByZW1vdmUKCSAgdGhlbSBmcm9tIHRoZSBjb250ZW50IHN0b3JlIHdo
ZW4gdGhleSBmb3J3YXJkIHRoZSBmaW5hbCBEYXRhCgkgIG1lc3NhZ2UgYW5zd2VyaW5nIHRoZSBv
cmlnaW5hbCBJbnRlcmVzdC4KCSAgPC90PgoJPC9zZWN0aW9uPgogICAgICA8L3NlY3Rpb24+CiAg
ICAgIAogICAgPHNlY3Rpb24gYW5jaG9yPSJwcm9kdWNlci1pbXBsZW1lbnRhdGlvbiI+CiAgICAg
IDxuYW1lPlByb2R1Y2VyIEltcGxlbWVudGF0aW9uIENvbnNpZGVyYXRpb25zPC9uYW1lPgogICAg
ICA8dD5Qcm9kdWNlcnMgcmVjZWl2aW5nIGFuIEludGVyZXN0IHdpdGggYSBSZWZsZXhpdmUgTmFt
ZQoJQ29tcG9uZW50LCBNQVkgZGVjaWRlIHRvIGlzc3VlIEludGVyZXN0cyBmb3IgdGhlIGNvcnJl
c3BvbmRpbmcKCURhdGEgb2JqZWN0cy4gQWxsIFJlZmxleGl2ZSBJbnRlcmVzdCBtZXNzYWdlIHRo
YXQgYSBwcm9kdWNlcgoJc2VuZHMgTVVTVCBiZSBzZW50IG92ZXIgdGhlIGZhY2UgdGhhdCB0aGUg
b3JpZ2luYWwgSW50ZXJlc3QKCXdhcyByZWNlaXZlZCBvbi4gPC90Pgo8IS0tCgk8dD4KCTxjcmVm
IHNvdXJjZT0iREtVIj48c3Ryb25nPndoYXQgZWxzZT88L3N0cm9uZz48L2NyZWY+CiAgICAgIDwv
dD4KLS0+CiAgICA8L3NlY3Rpb24+CiAgPC9zZWN0aW9uPgoKICAgIDxzZWN0aW9uIGFuY2hvcj0i
T3BzIj48bmFtZT5PcGVyYXRpb25hbCBDb25zaWRlcmF0aW9uczwvbmFtZT4KCQoJPHQ+VGhpcyBl
eHRlbnNpb24gcmVwcmVzZW50cyBhIHN1YnN0YW50aWFsIGVuaGFuY2VtZW50IHRvIHRoZSBDQ054
L05ETiBwcm90b2NvbCBhcmNoaXRlY3R1cmUgYW5kIGhlbmNlIGhhcyBpbXBvcnRhbnQgZm9yd2Fy
ZCBhbmQgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBlZmZlY3RzLiBUaGUgbW9zdCBpbXBvcnRhbnQg
b2YgdGhlc2UgaXMgdGhhdCBjb3JyZWN0IG9wZXJhdGlvbiBvZiB0aGUgc2NoZW1lIHJlcXVpcmVz
IGFuIHVuYnJva2VuIGNoYWluIG9mIGZvcndhcmRlcnMgYmV0d2VlbiB0aGUgY29uc3VtZXIgYW5k
IHRoZSBkZXNpcmVkIHByb2R1Y2VyIHRoYXQgc3VwcG9ydCB0aGUgUmVmbGV4aXZlIE5hbWUgVExW
IGFuZCB0aGUgY29ycmVzcG9uZGluZyBmb3J3YXJkZXIgY2FwYWJpbGl0aWVzIHNwZWNpZmllZCBp
biA8eHJlZiB0YXJnZXQ9ImZvcndhcmRlci1vcGVyYXRpb24iLz4uIFdoZW4gdGhpcyBpbnZhcmlh
bnQgaXMgbm90IHNhdGlzZmllZCwgc29tZSBtZWFucyBpcyBuZWNlc3NhcnkgdG8gZGV0ZWN0IGFu
ZCBob3BlZnVsbHkgcmVjb3ZlciBmcm9tIHRoZSBlcnJvci4gV2UgaGF2ZSBpZGVudGlmaWVkIHRo
cmVlIHBvc3NpYmxlIGFwcHJvYWNoZXMgdG8gaGFuZGxpbmcgdGhlIGxhY2sgb2YgdW5pdmVyc2Fs
IGRlcGxveW1lbnQgb2YgZm9yd2FyZGVycyBzdXBwb3J0aW5nIHRoZSByZWZsZXhpdmUgZm9yd2Fy
ZGluZyBzY2hlbWUuPC90PgoJCgk8dD5UaGUgZmlyc3QgYXBwcm9hY2ggc2ltcGx5IGxldHMgdGhl
IHByb2R1Y2VyIGRldGVjdCB0aGUgZXJyb3IgYnkgZ2V0dGluZyBhICJubyByb3V0ZSB0byBkZXN0
aW5hdGlvbiIgZXJyb3Igd2hlbiB0cnlpbmcgdG8gc2VuZCBhbiBJbnRlcmVzdCB0byBhIHJlZmxl
eGl2ZSBuYW1lLiBUaGlzIHdpbGwgY2F0Y2ggdGhlIGVycm9yLCBidXQgb25seSBhZnRlciBmb3J3
YXJkaW5nIHJlc291cmNlcyBhcmUgdGllZCB1cCBhbmQgdGhlIHByb2R1Y2VyIGhhcyBkb25lIHNv
bWUgd29yayBvbiB0aGUgb3JpZ2luYWwgSW50ZXJlc3QgbWVzc2FnZS4gRnVydGhlciwgdGhlIHBy
b2R1Y2VyIHdvdWxkIG5lZWQgYSBiaXQgb2Ygc21hcnRzIHRvIGRldGVybWluZSB0aGF0IHRoaXMg
aXMgYSBwZXJtYW5lbnQgZXJyb3IgYW5kIG5vdCBhIHRyYW5zaWVudCB0byBiZSByZXRyaWVkLiBJ
biBvcmRlciBmb3IgdGhlIGNvbnN1bWVyIHRvIGF0dGVtcHQgcmVjb3ZlcnksIHRoZXJlIG1pZ2h0
IGJlIGEgbmVlZCBmb3Igc29tZSBleHBsaWNpdCBlcnJvciByZXR1cm5lZCBmb3IgdGhlIG9yaWdp
bmFsIGludGVyZXN0IHRvIHRlbGwgdGhlIGNvbnN1bWVyIHdoYXQgdGhlIGxpa2VseSBwcm9ibGVt
IGlzLiBUaGlzIGFwcHJvYWNoIGRvZXMgbm90IGVuYWJsZSBhbiBvYnZpb3VzIHJlY292ZXJ5IHBh
dGggZm9yIHRoZSBjb25zdW1lciBlaXRoZXIsIHNpbmNlIHdoaWxlIHdlIG1pZ2h0IGVudmlzaW9u
IGEgd2F5IHRvIHN0ZWVyIGEgc3Vic2VxdWVudCBJbnRlcmVzdCBvbnRvIGEgd29ya2luZyBwYXRo
IGFzIHByb3Bvc2VkIGluIDx4cmVmIHRhcmdldD0iSS1ELm9yYW4taWNucmctcGF0aHN0ZWVyaW5n
Ii8+LCB0aGVyZSBpcyBubyBjYXBhYmlsaXR5IHRvIGZvcmNlIEludGVyZXN0IHJvdXRpbmcgYXdh
eSBmcm9tIGFuIG90aGVyd2lzZSB3b3JraW5nIHBhdGggbm90IHN1cHBvcnRpbmcgdGhlIHJlZmxl
eGl2ZSBuYW1lIFRMVi48L3Q+CgkKCTx0PkEgc2Vjb25kIGFwcHJvYWNoIGlzIHRvIGJ1bXAgdGhl
IENDTngvTkROIHByb3RvY29sIHZlcnNpb24gdG8gZXhwbGljaXRseSBpbmRpY2F0ZSB0aGUgbGFj
ayBvZiBjb21wYXJhYmlsaXR5LiBTdWNoIEludGVyZXN0cyB3b3VsZCBiZSByZWplY3RlZCBieSBm
b3J3YXJkZXJzIG5vdCBzdXBwb3J0aW5nIHRoaXMgcHJvdG9jb2wgZXh0ZW5zaW9uLiBBIGNvbnN1
bWVyIHdpc2hpbmcgdG8gdXNlIHRoZSByZWZsZXhpdmUgbmFtZSBUTFYgd291bGQgdXNlIHRoZSBo
aWdoZXIgcHJvdG9jb2wgdmVyc2lvbiBvbiB0aG9zZSBJbnRlcmVzdCBtZXNzYWdlcyAoYnV0IGNv
dWxkIG9mIGNvdXJzZSBjb250aW51ZSB0byB1c2UgdGhlIGN1cnJlbnQgdmVyc2lvbiBudW1iZXIg
b24gb3RoZXIgSW50ZXJlc3QgbWVzc2FnZXMpLiBUaGlzIGlzIGEgYmlnIGhhbW1lciwgYnV0IG1h
eSBiZSBjYWxsZWQgZm9yIGluIHRoaXMgc2l0dWF0aW9uIGJlY2F1c2U6PC90PiAKCTxvbCB0eXBl
PSIoJWMpIj4KCQk8bGk+aXQgZGV0ZWN0cyB0aGUgcHJvYmxlbSBpbW1lZGlhdGVseSBhbmQgZGV0
ZXJtaW5pc3RpY2FsbHksIGFuZDwvbGk+CgkJPGxpPm9uZSBjb3VsZCBhc3N1bWUgYW4gSUNOIHJv
dXRpbmcgcHJvdG9jb2wgdGhhdCB3b3VsZCBvbmx5IGZvcndhcmQgdG8gYSBuZXh0IGhvcCB0aGF0
IHN1cHBvcnRzIHRoZSB1cGRhdGVkIHByb3RvY29sIHZlcnNpb24gbnVtYmVyLiBUaGUgc3VwcG9y
dGVkIGZvcndhcmRlciBwcm90b2NvbCB2ZXJzaW9ucyB3b3VsZCBoYXZlIGJlZW4gY29tbXVuaWNh
dGVkIGluIHRoZSByb3V0aW5nIHByb3RvY29sIGFoZWFkIG9mIHRpbWUuPC9saT4KCTwvb2w+CgkK
CTx0PkEgdGhpcmQgb3B0aW9uIGlzIHRvLCBhcyBhIHByZWNvbmRpdGlvbiB1dGlsaXppbmcgdGhl
IHByb3RvY29sIGluIGEgZGVwbG95bWVudCwgY3JlYXRlIGFuZCBkZXBsb3kgYSBuZWlnaGJvciBj
YXBhYmlsaXR5IGV4Y2hhbmdlIHByb3RvY29sIHdoaWNoIHdpbGwgdGVsbCBhIGRvd25zdHJlYW0g
Zm9yd2FyZGVyIGlmIHRoZSB1cHN0cmVhbSBjYW4gaGFuZGxlIHRoZSBuZXcgVExWLiBUaGlzIG1p
Z2h0IGF2b2lkIHRoZSBsYXJnZSBoYW1tZXIgb2YgdXBkYXRpbmcgdGhlIHByb3RvY29sIHZlcnNp
b24sIGJ1dCBvZiBjb3Vyc2UgdGhpcyBwdXRzIGEgcHJldHR5IHN0cm9uZyBkZXBlbmRlbmN5IG9u
IHNvbWVib2R5IGFjdHVhbGx5IGRlc2lnbmluZyBhbmQgcHVibGlzaGluZyBzdWNoIGEgcHJvdG9j
b2whIE9uIHRoZSBvdGhlciBoYW5kLCBhIG5laWdoYm9yIGNhcGFiaWxpdHkgZXhjaGFuZ2UgcHJv
dG9jb2wgZm9yIENDTngvTkROIHdvdWxkIGhhdmUgYSBudW1iZXIgb2Ygb3RoZXIgc3Vic3RhbnRp
YWwgYmVuZWZpdHMsIHdoaWNoIG1ha2VzIGl0IHdvcnRoIHNlcmlvdXNseSBjb25zaWRlcmluZyBh
bnl3YXkuPC90PgoJCiAgPC9zZWN0aW9uPgoKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJlbmNvZGlu
ZyI+PG5hbWU+TWFwcGluZyB0byBDQ054IGFuZCBORE4gcGFja2V0IGVuY29kaW5nczwvbmFtZT4K
ICAgICAgPHQ+PC90PgogICAgICAKICAgICAgPHNlY3Rpb24gYW5jaG9yPSJDQ054LWVuY29kaW5n
Ij48bmFtZT5QYWNrZXQgZW5jb2RpbmcgZm9yIENDTng8L25hbWU+CiAgICAgIDx0IGtlZXBXaXRo
TmV4dD0idHJ1ZSI+Rm9yIENDTng8eHJlZiB0YXJnZXQ9IlJGQzg1NjkiLz4gdGhlcmUgaXMgb25l
IG5ldyBOYW1lIENvbXBvbmVudCBUTFYgdHlwZSBkZWZpbmVkIGluIHRoaXMgc3BlY2lmaWNhdGlv
bi48L3Q+CiAgICAgIDx0YWJsZT4KCTxuYW1lPlJlZmxleGl2ZSBOYW1lIFRMVjwvbmFtZT4KCTx0
aGVhZD4KCSAgPHRyPgoJICAgIDx0aCBhbGlnbj0iY2VudGVyIj5BYmJyZXY8L3RoPgoJICAgIDx0
aCBhbGlnbj0iY2VudGVyIj5OYW1lPC90aD4KCSAgPHRoIGFsaWduPSJjZW50ZXIiPkRlc2NyaXB0
aW9uPC90aD48L3RyPgoJPC90aGVhZD4KCTx0Ym9keT4KCSAgPHRyPgoJICAgIDx0ZD5UX1JFRkxF
WElWRV9OQU1FPC90ZD4KCSAgICA8dGQ+UmVmbGV4aXZlIE5hbWUgQ29tcG9uZW50PC90ZD4KCSAg
PHRkPk5hbWUgY29tcG9uZW50IHRvIHVzZSBhcyBuYW1lIHByZWZpeCBpbiBSZWZsZXhpdmUgSW50
ZXJlc3QgTWVzc2FnZTwvdGQ+PC90cj4KCTwvdGJvZHk+CiAgICAgIDwvdGFibGU+CiAgICAgIAog
ICAgICA8L3NlY3Rpb24+CiAgICAgIAogICAgICA8c2VjdGlvbiBhbmNob3I9Ik5ETi1lbmNvZGlu
ZyIgdGl0bGU9IlBhY2tldCBlbmNvZGluZyBmb3IgTkROIj4KCTx0PlRCRCBiYXNlZCBvbiA8eHJl
ZiB0YXJnZXQ9Ik5ETlRMViIvPi4gU3VnZ2VzdGlvbnMgZnJvbSB0aGUgTkROIHRlYW0gZ3JlYXRs
eSBhcHByZWNpYXRlZC48L3Q+CiAgICAgIDwvc2VjdGlvbj4KICAgICAgPC9zZWN0aW9uPgoKICAg
ICAgPHNlY3Rpb24gYW5jaG9yPSJJQU5BIj48bmFtZT5JQU5BIENvbnNpZGVyYXRpb25zPC9uYW1l
PgogICAgICA8dD5QbGVhc2UgYWRkIHRoZSBUX1JFRkxFWElWRV9OQU1FIGNvbXBvbmVudCBUTFYg
dG8gdGhlIENDTnggTmFtZSB0eXBlcyBUTFYgdHlwZXMgcmVnaXN0cnkgb2YgPHhyZWYgdGFyZ2V0
PSJSRkM4NjA5Ii8+LCB3aXRoIExlbmd0aCA5IGJ5dGVzIGFuZCB0eXBlIG9mIDY0IGJpdCByYW5k
b20gaW50ZWdlci4gPC90PgogICAgICA8ZmlndXJlIGFuY2hvcj0icmVmbGV4aXZlLW5hbWUtZW5j
b2RpbmciPjxuYW1lPlJlZmxleGl2ZSBOYW1lIGNvbXBvbmVudCB0eXBlPC9uYW1lPgogICAgICA8
YXJ0d29yayBhbGlnbj0ibGVmdCI+PCFbQ0RBVEFbCiAgICAgICAgICAgICAgICAgICAgIDEgICAg
ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAwIDEgMiAzIDQgNSA2IDcgOCA5
IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKKy0tLS0tLS0tLS0t
LS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsKfCAg
ICAgICAgIFRfUkVGTEVYSVZFX05BTUUgICAgICB8ICAgICAgICAgICAgICAgOCAgICAgICAgICAg
ICAgIHwKKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tKy0t
LS0tLS0tLS0tLS0tLSsKfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwKfCAgICAgICA2NGJpdCBJbnRlZ2VyIHJhbmRvbWx5IGFz
c2lnbmVkIGJ5IGNvbnN1bWVyICAgICAgICAgICAgIHwKKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKXV0+PC9hcnR3b3JrPgog
ICAgICA8L2ZpZ3VyZT4KICAgICAgCiAgICAgIDwvc2VjdGlvbj4KICAgICAgCiAgICAgIDxzZWN0
aW9uIGFuY2hvcj0iU2VjdXJpdHkiIHRpdGxlPSJTZWN1cml0eSBDb25zaWRlcmF0aW9ucyI+CiAg
ICAgIAo8IS0tCiAgICAgICAgPHQ+PGNyZWYgc291cmNlPSJETyI+PHN0cm9uZz5Qb3NzaWJseSBh
bHNvIHRhbGsgYWJvdXQ8L3N0cm9uZz5zdHVmZiBmcm9tIFJJQ0Ugb24gYXZvaWRpbmcgc2VydmVy
IG92ZXJsb2FkLjwvY3JlZj48L3Q+Ci0tPgogICAgICAJCiAgICAgIDx0Pk9uZSBvZiB0aGUgbWFq
b3IgbW90aXZhdGlvbnMgZm9yIHRoZSByZWZsZXhpdmUgZm9yd2FyZGluZyBleHRlbnNpb24gc3Bl
Y2lmaWVkIGluIHRoaXMgZG9jdW1lbnQgaXMgaW4gZmFjdCB0byBlbmFibGUgYmV0dGVyIHNlY3Vy
aXR5IGFuZCBwcml2YWN5IGNoYXJhY3RlcmlzdGljcyBmb3IgSUNOIG5ldHdvcmtzLiBUaGUgbWFp
biBjb25zaWRlcmF0aW9ucyBhcmUgcHJlc2VudGVkIGluIDx4cmVmIHRhcmdldD0iaW50cm8iLz4s
IGJ1dCB3ZSBicmllZmx5IHJlY2FwaXR1bGF0ZSB0aGVtIGhlcmU6PC90PgogICAgICA8dWw+CiAg
ICAgIAk8bGk+Q3VycmVudCBhcHByb2FjaGVzIHRvIGF1dGhlbnRpY2F0aW9uIGFuZCBkYXRhIHRy
YW5zZmVyIG9mdGVuIHVzZSBwYXlsb2FkcyBpbiBJbnRlcmVzdCBtZXNzYWdlcywgd2hpY2ggYXJl
IGNsdW1zeSB0byBzZWN1cmUgKEludGVyZXN0IG1lc3NhZ2VzIG11c3QgYmUgc2lnbmVkKSBhbmQg
YXMgYSBjb25zZXF1ZW5jZSBtYWtlIGl0IHZlcnkgZGlmZmljdWx0IHRvIGVuc3VyZSBjb25zdW1l
ciBwcml2YWN5LiBSZWZsZXhpdmUgZm9yd2FyZGluZyBtb3ZlcyBhbGwgc2Vuc2l0aXZlIGRhdGEg
dG8gdGhlIERhdGEgbWVzc2FnZXMgc2VudCBpbiByZXNwb25zZSB0byByZWZsZXhpdmUgSW50ZXJl
c3RzLCB3aGljaCBhcmUgc2VjdXJlZCBpbiB0aGUgc2FtZSBtYW5uZXIgYXMgYWxsIG90aGVyIERh
dGEgbWVzc2FnZXMgaW4gdGhlIENDTnggYW5kIE5ETiBwcm90b2NvbCBkZXNpZ25zLjwvbGk+CiAg
ICAgIAkKICAgICAgCTxsaT5JbiBtYW55IHNjZW5hcmlvcywgY29uc3VtZXJzIGFyZSBmb3JjZWQg
dG8gYWxzbyBhY3QgYXMgcHJvZHVjZXJzIHNvIHRoYXQgZGF0YSBtYXkgYmUgZmV0Y2hlZCBieSBl
aXRoZXIgYSBwYXJ0aWN1bGFyLCBvciBhcmJpdHJhcnkgb3RoZXIgcGFydHkuIFRoZSBtZWFucyB0
aGUgY29uc3VtZXIgbXVzdCBhcnJhbmdlIHRvIGhhdmUgYSByb3V0YWJsZSBuYW1lIHByZWZpeCBh
bmQgdGhhdCBwcmVmaXggYmUgZGlzc2VtaW5hdGVkIGJ5IHRoZSByb3V0aW5nIHByb3RvY29sIG9y
IG90aGVyIG1lYW5zLiBUaGlzIHJlcHJlc2VudHMgYm90aCBhIHByaXZhY3kgaGF6YXJkIChieSBy
ZXZlYWxpbmcgcG9zc2libGUgaW1wb3J0YW50IGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb25zdW1l
cikgYW5kIGEgc2VjdXJpdHkgY29uY2VybiBhcyBpdCBvcGVucyB1cCB0aGUgY29uc3VtZXIgdG8g
dGhlIGZ1bGwgcGFub3BseSBvZiBmbG9vZGluZyBhbmQgY3JhZnRlZCBJbnRlcmVzdCBkZW5pYWwg
b2Ygc2VydmljZSBhdHRhY2tzLjwvbGk+CiAgICAgIAkKICAgICAgCTxsaT5JbiBvcmRlciB0byBh
Y2hpZXZlIG11bHRpLXdheSBoYW5kc2hha2VzLCBpbiBjdXJyZW50IGRlc2lnbnMgYSBjb25zdW1l
ciB3aXNoaW5nIGEgcHJvZHVjZXIgdG8gY29tbXVuaWNhdGUgYmFjayBtdXN0IGluZm9ybSB0aGUg
cHJvZHVjZXIgb2Ygd2hhdCAoZ2xvYmFsbHkgcm91dGFibGUpIG5hbWUgdG8gdXNlLiBUaGlzIGdp
dmVzIHRoZSBjb25zdW1lciBhIGNvbnZlbmllbnQgbWVhbnMgdG8gbW91bnQgYSB2YXJpZXR5IG9m
IHJlZmxlY3Rpb24gYXR0YWNrcyBieSBlbmxpc3RpbmcgdGhlIHByb2R1Y2VyIHRvIHNlbmQgSW50
ZXJlc3RzIHRvIGRlc2lyZWQgdmljdGltcy48L2xpPgogICAgICA8L3VsPgogICAgICAKICAgICAg
PHQ+QXMgYSBtYWpvciBwcm90b2NvbCBleHRlbnNpb24gaG93ZXZlciwgdGhpcyBkZXNpZ24gYnJp
bmdzIGl0cyBvd24gcG90ZW50aWFsIHNlY3VyaXR5IGlzc3Vlcywgd2hpY2ggYXJlIGRpc2N1c3Nl
ZCBpbiB0aGUgZm9sbG93aW5nIHN1YnNlY3Rpb25zLjwvdD4KICAgICAgCiAgICAgIDxzZWN0aW9u
PjxuYW1lPkNvbGxpc2lvbnMgb2YgcmVmbGV4aXZlIEludGVyZXN0IG5hbWVzPC9uYW1lPgogICAg
ICAJPHQ+UmVmbGV4aXZlIEludGVyZXN0IG5hbWVzIGFyZSBjb25zdHJ1Y3RlZCB1c2luZyA2NC1i
aXQgcmFuZG9tIG51bWJlcnMuIFRoaXMgaXMgaW50ZW5kZWQgdG8gZW5zdXJlIGFuIG9mZi1wYXRo
IGF0dGFja2VyIGNhbm5vdCBlYXNpbHkgbWFudWZhY3R1cmUgYSBtYXRjaGluZyByZWZsZXhpdmUg
SW50ZXJlc3QgYW5kIGVpdGhlciBtYXNxdWVyYWRlIGFzIHRoZSBwcm9kdWNlciwgb3IgbW91bnQg
YSBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2sgb24gdGhlIGNvbnN1bWVyLiBJdCBhbHNvIGxpbWl0
cyB0cmFja2luZyB0aHJvdWdoIHRoZSBsaW5rYWJpbGl0eSBvZiBJbnRlcmVzdHMgY29udGFpbmlu
ZyBhIHJlLXVzZWQgcmFuZG9tIHZhbHVlLjwvdD4KICAgICAgCQogICAgICAJPHQ+VGhlcmVmb3Jl
IGNvbnN1bWVycyBNVVNUIHV0aWxpemUgYSByb2J1c3QgbWVhbnMgb2YgZ2VuZXJhdGluZyB0aGVz
ZSByYW5kb20gdmFsdWVzLCBhbmQgaXQgaXMgUkVDT01NRU5ERUQgdGhhdCBhIHBzZXVkby1yYW5k
b20gbnVtYmVyIGdlbmVyYXRvciAoUFJORykgYXBwcm92ZWQgZm9yIHVzZSB3aXRoIGNyeXB0b2dy
YXBoaWMgcHJvdG9jb2xzIGJlIGVtcGxveWVkLjwvdD4KICAgICAgPC9zZWN0aW9uPgogICAgICAK
ICAgICAgPHNlY3Rpb24+PG5hbWU+QWRkaXRpb25hbCByZXNvdXJjZSBwcmVzc3VyZSBvbiBQSVQg
YW5kIEZJQjwvbmFtZT4KICAgICAgCTx0Pk5vcm1hbCBJbnRlcmVzdCBtZXNzYWdlIHByb2Nlc3Np
bmcgaW4gQ0NOeCBhbmQgTkROIG5lZWRzIHRvIGNvbnNpZGVyIGVmZmVjdCBvZiB2YXJpb3VzIHJl
c291cmNlIGRlcGxldGlvbiBhdHRhY2tzIG9uIHRoZSBQSVQsIHBhcnRpY3VsYXJseSBpbiB0aGUg
Zm9ybSBvZiBJbnRlcmVzdCBmbG9vZGluZyBhdHRhY2tzIChzZWUgPHhyZWYgdGFyZ2V0PSJHYXN0
aTIwMTIiLz4gZm9yIGEgZ29vZCBvdmVydmlldyBvZiBEb1MgYW5kIEREb1MgbWl0aWdhdGlvbiBv
biBJQ04gbmV0d29ya3MpLiBJbnRlcmVzdCBtZXNzYWdlcyB1dGlsaXppbmcgdGhpcyByZWZsZXhp
dmUgZm9yd2FyZGluZyBleHRlbnNpb24gY2FuIHBsYWNlIGFkZGl0aW9uYWwgcmVzb3VyY2UgcHJl
c3N1cmUgb24gdGhlIFBJVCwgYW5kIGFkZGl0aW9uYWxseSBjYXVzZSBvdGhlcndpc2Ugc3RhYmxl
IEZJQiByZXNvdXJjZXMgdG8gYmUgc3ViamVjdCB0byBoaWdobHkgZHluYW1pYyB1c2FnZS48L3Q+
CiAgICAgIAkKICAgICAgCTx0PldoaWxlIHRoaXMgZG9lcyBub3QgcmVwcmVzZW50IGEgbmV3IERv
Uy9ERG9TIGF0dGFjayB2ZWN0b3IsIHRoZSBhYmlsaXR5IG9mIGEgbWFsaWNpb3VzIGNvbnN1bWVy
IHRvIHV0aWxpemUgdGhpcyBleHRlbnNpb24gaW4gYW4gYXR0YWNrIGRvZXMgcmVwcmVzZW50IGFu
IGluY3JlYXNlZCByaXNrIG9mIHJlc291cmNlIGRlcGxldGlvbiwgZXNwZWNpYWxseSBpZiBzdWNo
IEludGVyZXN0cyBhcmUgZ2l2ZW4gdW5mYWlyIGFjY2VzcyB0byBQSVQgYW5kIEZJQiByZXNvdXJj
ZXMuIEltcGxlbWVudGVycyBTSE9VTEQgdGhlcmVmb3JlIHByb3RlY3QgUElUIGFuZCBGSUIgcmVz
b3VyY2VzIGJ5IHdlaWdoaW5nIHJlcXVlc3RzIGZvciByZWZsZXhpdmUgZm9yd2FyZGluZyByZXNv
dXJjZXMgYXBwcm9wcmlhdGVseSByZWxhdGl2ZSB0byBvdGhlciBJbnRlcmVzdHMuPC90PgogICAg
ICA8L3NlY3Rpb24+IAogICAgICAKICAgICAgPHNlY3Rpb24+PG5hbWU+UHJpdmFjeSBDb25zaWRl
cmF0aW9uczwvbmFtZT4KICAgICAgCTx0PklDTiBhcmNoaXRlY3R1cmVzIGxpa2UgQ0NOeCBhbmQg
TkROIHByb3ZpZGUgYSByaWNoIHRhcGVzdHJ5IG9mIGludGVyZXN0aW5nIHByaXZhY3kgaXNzdWVz
LCB3aGljaCBoYXZlIGJlZW4gZXh0ZW5zaXZlbHkgZXhwbG9yZWQgaW4gdGhlIHJlc2VhcmNoIGxp
dGVyYXR1cmUuIFRoZSBmdW5kYW1lbnRhbCB0cmFkZW9mZnMgZm9yIHByaXZhY3kgY29uY2VybiB0
aGUgcmlzayBvZiBleHBvc2luZyB0aGUgbmFtZXMgb2YgaW5mb3JtYXRpb24gb2JqZWN0cyB0byB0
aGUgZm9yd2FyZGluZyBlbGVtZW50cyBvZiB0aGUgbmV0d29yaywgd2hpY2ggaXMgYSBuZWNlc3Nh
cnkgcHJvcGVydHkgb2YgYW55IG5hbWUtYmFzZWQgcm91dGluZyBhbmQgZm9yd2FyZGluZyBkZXNp
Z24uIE51bWVyb3VzIGFwcHJvYWNoZXMgaGF2ZSBiZWVuIGV4cGxvcmVkIHdpdGggdmFyeWluZyBk
ZWdyZWVzIG9mIHN1Y2Nlc3MsIHN1Y2ggYXMgb25pb24gcm91dGluZyAoPHhyZWYgdGFyZ2V0PSJE
aUJlbmVkZXR0b0dUVTEyIi8+KSwgbmFtZSBlbmNyeXB0aW9uICg8eHJlZiB0YXJnZXQ9IkdoYWxp
MjAxNyIvPiksIGFuZCBuYW1lIG9iZnVzY2F0aW9uICg8eHJlZiB0YXJnZXQ9IkFyaWFuZmFyMjAx
MSIvPikgYW1vbmcgb3RoZXJzLjwvdD4KICAgICAgCQogICAgICAJPHQ+UmVmbGV4aXZlIGZvcndh
cmRpbmcgZG9lcyBub3QgY2hhbmdlIHRoZSBvdmVyYWxsIGxhbmRzY2FwZSBvZiBwcml2YWN5IHRy
YWRlb2Zmcywgbm9yIHNlZW0gdG8gaW50cm9kdWNlIGFkZGl0aW9uYWwgaGF6YXJkcy4gSW4gZmFj
dCwgdGhlIHByaXZhY3kgZXhwb3N1cmVzIGFyZSBjb25maW5lZCB0byB0aGUgaW52ZXJzZSBwYXRo
IG9mIGZvcndhcmRlcnMgZnJvbSB0aGUgcHJvZHVjZXIgdG8gdGhlIGNvbnN1bWVyLCB0aHJvdWdo
IHdoaWNoIHRoZSBvcmlnaW5hbCBJbnRlcmVzdCBmb3J3YXJkaW5nIG1heSBoYXZlIGFscmVhZHkg
ZXhwb3NlZCBuYW1lcyBvbiBwYXRoLiBTaW1pbGFyIG5hbWUgcHJpdmFjeSB0ZWNobmlxdWVzIHRv
IHRob3NlIGNpdGVkIGFib3ZlIG1heSBiZSBlcXVhbGx5IGFwcGxpZWQgdG8gdGhlIG5hbWVzIGlu
IHJlZmxleGl2ZSBJbnRlcmVzdHMuPC90PgogICAgICAJCiAgICAgIAk8dD5XaGlsZSB0aGUgaW5k
aXZpZHVhbCByZWZsZXhpdmUgSW50ZXJlc3QtRGF0YSBleGNoYW5nZXMgaGF2ZSBzaW1pbGFyIHBy
b3BlcnRpZXMgdG8gdGhvc2UgaW4gYW55IE5ETiBvciBDQ054IGV4Y2hhbmdlLCB0aGUgdGFyZ2V0
IHVzYWdlcyBieSBhcHBsaWNhdGlvbnMgbWF5IGhhdmUgaW50ZXJhY3Rpb24gcGF0dGVybnMgdGhh
dCBhcmUgc3ViamVjdCB0byByZWxhdGl2ZWx5IHN0cmFpZ2h0Zm9yd2FyZCBmaW5nZXJwcmludGlu
ZyBieSBhZHZlcnNhcmllcy4gRm9yIGV4YW1wbGUsIGEgcGFydGljdWxhciBSTUkgaW52b2NhdGlv
biBtYXkgZmluZ2VycHJpbnQgc2ltcGx5IHRocm91Z2ggdGhlIGNvdW50IG9mIGFyZ3VtZW50cyBm
ZXRjaGVkIGJ5IHRoZSBwcm9kdWNlciBhbmQgdGhlaXIgc2l6ZXMuIFRoZSBhdHRhY2tlciBtdXN0
IGhvd2V2ZXIgYmUgb24gcGF0aCwgd2hpY2ggc29tZXdoYXQgYW1lbGlvcmF0ZXMgdGhlIGV4cG9z
dXJlIGhhemFyZHMuPC90PgogICAgICA8L3NlY3Rpb24+CiAgICAgIAogIDwvc2VjdGlvbj4KCiAg
ICAgIAogICAgPC9taWRkbGU+CiAgICAKICAgIDxiYWNrPgogICAgICAKICAgICAgPHJlZmVyZW5j
ZXM+PG5hbWU+Tm9ybWF0aXZlIFJlZmVyZW5jZXM8L25hbWU+CiAgICAgIDw/cmZjIGluY2x1ZGU9
InJlZmVyZW5jZS5SRkMuMjExOS54bWwiPz4KICAgICAgPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNl
LlJGQy44NTY5LnhtbCI/PgogICAgICA8P3JmYyBpbmNsdWRlPSJyZWZlcmVuY2UuUkZDLjg2MDku
eG1sIj8+CiAgICAgIDwvcmVmZXJlbmNlcz4KICAgICAgCiAgICAgIDxyZWZlcmVuY2VzIHRpdGxl
PSJJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIj4KCQoJPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJG
Qy43NTMwLnhtbCI/PgoJPD9yZmMgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy4zMjYxLnhtbCI/PgoJ
PD9yZWYgaW5jbHVkZT0icmVmZXJlbmNlLlJGQy42MzM3LnhtbCI/PgoJPD9yZWYgaW5jbHVkZT0i
cmVmZXJlbmNlLlJGQy44NDQ2LnhtbCI/PgoJCgk8IS0tCQk8P3JmYyBpbmNsdWRlPSJyZWZlcmVu
Y2UuSS1ELmlydGYuaWNucmcubWFwbWUueG1sIj8+IC0tPgoJPD9yZmMgaW5jbHVkZT0icmVmZXJl
bmNlLkktRC5pcnRmLWljbnJnLXRlcm1pbm9sb2d5LnhtbCI/PgoJPD9yZmMgaW5jbHVkZT0icmVm
ZXJlbmNlLkktRC5pcnRmLWljbnJnLWZsaWMueG1sIj8+Cgk8P3JmYyBpbmNsdWRlPSJyZWZlcmVu
Y2UuSS1ELm9yYW4taWNucmctcGF0aHN0ZWVyaW5nLnhtbCI/PgoJCgk8cmVmZXJlbmNlIGFuY2hv
cj0iS3JvbDIwMTgiIHRhcmdldD0iaHR0cHM6Ly9jb25mZXJlbmNlcy5zaWdjb21tLm9yZy9hY20t
aWNuLzIwMTgvcHJvY2VlZGluZ3MvaWNuMTgtZmluYWw5LnBkZiI+CgkgIDxmcm9udD4KCSAgICA8
dGl0bGU+UklDRTogUmVtb3RlIE1ldGhvZCBJbnZvY2F0aW9uIGluIElDTiwgaW4gUHJvY2VlZGlu
Z3Mgb2YgdGhlIDV0aCBBQ00gQ29uZmVyZW5jZSBvbiBJbmZvcm1hdGlvbi1DZW50cmljIE5ldHdv
cmtpbmcgLSBJQ04gJzE4PC90aXRsZT4KCSAgICA8YXV0aG9yIHN1cm5hbWU9Iktyb2wiIGluaXRp
YWxzPSJNLiIvPgoJICAgIDxhdXRob3Igc3VybmFtZT0iSGFiYWsiIGluaXRpYWxzPSJLLiIvPgoJ
ICAgIDxhdXRob3Igc3VybmFtZT0iT3JhbiIgaW5pdGlhbHM9IkQuIi8+CgkgICAgPGF1dGhvciBz
dXJuYW1lPSJLdXRzY2hlciIgaW5pdGlhbHM9IkQuIi8+CgkgICAgPGF1dGhvciBzdXJuYW1lPSJQ
c2FyYXMiIGluaXRpYWxzPSJJLiIvPgoJICAgIDxkYXRlIHllYXI9IjIwMTgiIG1vbnRoPSJTZXB0
ZW1iZXIiLz4KCSAgPC9mcm9udD4KCSAgPHNlcmllc0luZm8gbmFtZT0iRE9JIiB2YWx1ZT0iMTAu
MTE0NS8zMjY3OTU1LjMyNjc5NTYiLz4KCTwvcmVmZXJlbmNlPgoJCgk8cmVmZXJlbmNlIGFuY2hv
cj0iTkROIiB0YXJnZXQ9Imh0dHBzOi8vbmFtZWQtZGF0YS5uZXQvcHJvamVjdC9leGVjc3VtbWFy
eS8iPgoJICA8ZnJvbnQ+CgkgICAgPHRpdGxlPk5hbWVkIERhdGEgTmV0d29ya2luZzwvdGl0bGU+
CgkgICAgPGF1dGhvciBzdXJuYW1lPSJORE4gdGVhbSIvPgoJICAgIDxkYXRlIHllYXI9IjIwMjAi
Lz4KCSAgPC9mcm9udD4KCTwvcmVmZXJlbmNlPgoJCgk8cmVmZXJlbmNlIGFuY2hvcj0iTkROVExW
IiB0YXJnZXQ9Imh0dHA6Ly9uYW1lZC1kYXRhLm5ldC9kb2MvbmRuLXRsdi8iPgogICAgCSAgPGZy
b250PgogICAgICAgICAgICA8dGl0bGU+TkROIFBhY2tldCBGb3JtYXQgU3BlY2lmaWNhdGlvbjwv
dGl0bGU+CgkgICAgPGF1dGhvciBzdXJuYW1lPSJORE4gUHJvamVjdCBUZWFtIi8+CgkgICAgPGRh
dGUgeWVhcj0iMjAxNiIgLz4KICAgICAgICAgIDwvZnJvbnQ+CiAgICAJPC9yZWZlcmVuY2U+CgkK
ICAgIAk8cmVmZXJlbmNlIGFuY2hvcj0iWmhhbmcyMDE4IiB0YXJnZXQ9Imh0dHBzOi8vY29uZmVy
ZW5jZXMuc2lnY29tbS5vcmcvYWNtLWljbi8yMDE4L3Byb2NlZWRpbmdzL2ljbjE4LWZpbmFsMjMu
cGRmIj4KICAgIAkgIDxmcm9udD4KICAgIAkgICAgPHRpdGxlPktJVEU6IFByb2R1Y2VyIE1vYmls
aXR5IFN1cHBvcnQgaW4gTmFtZWQgRGF0YSBOZXR3b3JraW5nLCBpbiBQcm9jZWVkaW5ncyBvZiB0
aGUgNXRoIEFDTSBDb25mZXJlbmNlIG9uIEluZm9ybWF0aW9uLUNlbnRyaWMgTmV0d29ya2luZyAt
IElDTiAnMTg8L3RpdGxlPgogICAgCSAgICA8YXV0aG9yIHN1cm5hbWU9IlpoYW5nIiBpbml0aWFs
cz0iWSIgZnVsbG5hbWU9Ill1IFpoYW5nIi8+CiAgICAJICAgIDxhdXRob3Igc3VybmFtZT0iWGlh
IiBpbml0aWFscz0iWi4iIGZ1bGxuYW1lPSJaaG9uZ2RhIFhpYSIvPgogICAgCSAgICA8YXV0aG9y
IHN1cm5hbWU9Ik1hc3RvcmFraXMiIGluaXRpYWxzPSJTLiIgZnVsbG5hbWU9IlNweXJpZG9uIE1h
c3RvcmFraXMiLz4KICAgIAkgICAgPGF1dGhvciBzdXJuYW1lPSJaaGFuZyIgaW5pdGlhbHM9Ikwi
IGZ1bGxuYW1lPSJMaXhpYSBaaGFuZyIvPgogICAgCSAgICA8ZGF0ZSB5ZWFyPSIyMDE4IiBtb250
aD0iU2VwdGVtYmVyIi8+CiAgICAJICA8L2Zyb250PgogICAgCSAgPHNlcmllc0luZm8gbmFtZT0i
RE9JIiB2YWx1ZT0iMTAuMTE0NS8zMjY3OTU1LjMyNjc5NTkiLz4KICAgIAk8L3JlZmVyZW5jZT4K
CQoJPHJlZmVyZW5jZSBhbmNob3I9IkF1Z2UyMDE4IiB0YXJnZXQ9Imh0dHBzOi8vaWVlZXhwbG9y
ZS5pZWVlLm9yZy9kb2N1bWVudC84MjY3MTMyIj4KCSAgPGZyb250PgoJICAgIDx0aXRsZT5NQVAt
TWU6IE1hbmFnaW5nIEFuY2hvci1MZXNzIFByb2R1Y2VyIE1vYmlsaXR5IGluIENvbnRlbnQtQ2Vu
dHJpYyBOZXR3b3JrcywgaW4gSUVFRSBUcmFuc2FjdGlvbnMgb24gTmV0d29yaywgVm9sdW1lIDE1
LCBJc3N1ZSAyPC90aXRsZT4KCSAgICA8YXV0aG9yIHN1cm5hbWU9IkF1Z8OpIiBpbml0aWFscz0i
Si4iIGZ1bGxuYW1lPSJKb3JkYW4gQXVnw6kiLz4KCSAgICA8YXV0aG9yIHN1cm5hbWU9IkNhcm9m
aWdsaW8iIGluaXRpYWxzPSJHLiIgZnVsbG5hbWU9Ikdpb3Zhbm5hIENhcm9maWdsaW8iLz4KCSAg
ICA8YXV0aG9yIGluaXRpYWxzPSJHLiIgc3VybmFtZT0iR3Jhc3NpIi8+CgkgICAgPGF1dGhvciBp
bml0aWFscz0iTC4iIHN1cm5hbWU9Ik11c2NhcmllbGxvIiBmdWxsbmFtZT0iTHVjYSBNdXNjYXJp
ZWxsbyIvPgoJICAgIDxhdXRob3IgaW5pdGlhbHM9IkcuIiBzdXJuYW1lPSJQYXUiIGZ1bGxuYW1l
PSJHaW92YW5uaSBQYXUiLz4KCSAgICA8YXV0aG9yIGluaXRpYWxzPSJYLiIgc3VybmFtZT0iWmVu
ZyIvPgoJICAgIDxkYXRlIG1vbnRoPSJKdW5lIiB5ZWFyPSIyMDE4Ii8+CgkgIDwvZnJvbnQ+Cgkg
IDxzZXJpZXNJbmZvIG5hbWU9IkRPSSIgdmFsdWU9IjEwLjExMDkvVE5TTS4yMDE4LjI3OTY3MjAi
Lz4KCTwvcmVmZXJlbmNlPgoKCgk8cmVmZXJlbmNlIGFuY2hvcj0iQ2FyemFuaWdhMjAxMSIgdGFy
Z2V0PSJodHRwczovL2NvbmZlcmVuY2VzLnNpZ2NvbW0ub3JnL3NpZ2NvbW0vMjAxMS9wYXBlcnMv
aWNuL3A1Ni5wZGYiPgoJICA8ZnJvbnQ+CgkgICAgPHRpdGxlPkNvbnRlbnQtQmFzZWQgUHVibGlz
aC9TdWJzY3JpYmUgTmV0d29ya2luZyBhbmQgSW5mb3JtYXRpb24tQ2VudHJpYyBOZXR3b3JraW5n
PC90aXRsZT4KCSAgICA8YXV0aG9yIHN1cm5hbWU9IkNhcnphbmlnYSIgaW5pdGlhbHM9IkEuIiBm
dWxsbmFtZT0iQW50b25pbyBDYXJ6YW5pZ2EiLz4KCSAgICA8YXV0aG9yIHN1cm5hbWU9IlBhcGFs
aW5pIiBpbml0aWFscz0iTS4iIGZ1bGxuYW1lPSJNaWNoZWxlIFBhcGFsaW5lIi8+CgkgICAgPGF1
dGhvciBzdXJuYW1lPSJXb2xmIiBpbml0aWFscz0iQS5MLiIgZnVsbG5hbWU9IkFsZXhhbmRlciBM
LiBXb2xmIi8+CgkgICAgPGRhdGUgbW9udGg9IlNlcHRlbWJlciIgeWVhcj0iMjAxMSIvPgoJICA8
L2Zyb250PgoJICA8c2VyaWVzSW5mbyBuYW1lPSJET0kiIHZhbHVlPSIxMC4xMTQ1LzIwMTg1ODQu
MjAxODU5OSIvPgoJPC9yZWZlcmVuY2U+CgkgICAgICAKCTxyZWZlcmVuY2UgYW5jaG9yPSJNb3Nr
bzIwMTciIHRhcmdldD0iaHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzE3MDcuMDQ3MzgiPgoJICA8ZnJv
bnQ+CgkgICAgPHRpdGxlPkNDTnggMS4wIEJpZGlyZWN0aW9uYWwgU3RyZWFtczwvdGl0bGU+Cgkg
ICAgPGF1dGhvciBzdXJuYW1lPSJNb3NrbyIgaW5pdGlhbHM9Ik0uIiBmdWxsbmFtZT0iTWFyYyBN
b3NrbyIvPgoJICAgIDxkYXRlIG1vbnRoPSJKdWx5IiB5ZWFyPSIyMDE3Ii8+CgkgIDwvZnJvbnQ+
CgkgIDxzZXJpZXNJbmZvIG5hbWU9ImFyWGl2IiB2YWx1ZT0iMTcwNy4wNDczOCIvPgoJPC9yZWZl
cmVuY2U+CgoKCTxyZWZlcmVuY2UgYW5jaG9yPSJNb2lzZWVua28yMDE0IiB0YXJnZXQ9Imh0dHBz
Oi8vZGwuYWNtLm9yZy9kb2kvMTAuMTE0NS8yNjYwMTI5LjI2NjAxNTIiPgoJICA8ZnJvbnQ+Cgkg
ICAgPHRpdGxlPkNvbW11bmljYXRpb24gcGF0dGVybnMgZm9yIHdlYiBpbnRlcmFjdGlvbiBpbiBu
YW1lZCBkYXRhIG5ldHdvcmtpbmc8L3RpdGxlPgoJICAgIDxhdXRob3Igc3VybmFtZT0iTW9pc2Vl
bmtvIiBpbml0aWFscz0iSS4iIGZ1bGxuYW1lPSJJbHlhIE1vaXNlZW5rbyIvPgoJICAgIDxhdXRo
b3Igc3VybmFtZT0iU3RhcHAiIGluaXRpYWxzPSJNLiIgZnVsbG5hbWU9Ik1hcmsgU3RhcHAiLz4K
CSAgICA8YXV0aG9yIHN1cm5hbWU9Ik9yYW4iIGluaXRpYWxzPSJELiIgZnVsbG5hbWU9IkRhdmUg
T3JhbiIvPgoJICAgIDxkYXRlIG1vbnRoPSJTZXB0ZW1iZXIiIHllYXI9IjIwMTQiLz4KCSAgPC9m
cm9udD4KCSAgPHNlcmllc0luZm8gbmFtZT0iRE9JIiB2YWx1ZT0iMTAuMTE0NS8yNjYwMTI5LjI2
NjAxNTIiLz4KCTwvcmVmZXJlbmNlPgoKCTxyZWZlcmVuY2UgYW5jaG9yPSJHYXN0aTIwMTIiIHRh
cmdldD0iaHR0cHM6Ly9pZWVleHBsb3JlLmllZWUub3JnL2RvY3VtZW50LzY2MTQxMjciPgoJICA8
ZnJvbnQ+CgkJPHRpdGxlPkRvUyBhbmQgRERvUyBpbiBOYW1lZCBEYXRhIE5ldHdvcmtpbmcsIGlu
IDIybmQgSW50ZXJuYXRpb25hbCBDb25mZXJlbmNlIG9uIENvbXB1dGVyIENvbW11bmljYXRpb24g
YW5kIE5ldHdvcmtzIChJQ0NDTik8L3RpdGxlPgoJCTxhdXRob3Igc3VybmFtZT0iR2FzdGkiIGlu
aXRpYWxzPSJQLiIgZnVsbG5hbWU9IlBhb2xvIEdhc3RpIi8+CgkJPGF1dGhvciBzdXJuYW1lPSJU
c3VkaWsiIGluaXRpYWxzPSJHLiIgZnVsbG5hbWU9IkdlbmUgVHN1ZGlrIi8+CgkJPGF1dGhvciBz
dXJuYW1lPSJVenVuIiBpbml0aWFscz0iRXJzaW4iIGZ1bGxuYW1lPSJFcnNpbiBVenVuIi8+CgkJ
PGF1dGhvciBzdXJuYW1lPSJaaGFuZyIgaW5pdGlhbHM9IkwuIiBmdWxsbmFtZT0iTGl4aWEgWmhh
bmciLz4KCQk8ZGF0ZSBtb250aD0iQXVndXN0IiB5ZWFyPSIyMDEzIi8+CgkgIDwvZnJvbnQ+Cgkg
IDxzZXJpZXNJbmZvIG5hbWU9IkRPSSIgdmFsdWU9IjEwLjExMDkvSUNDQ04uMjAxMy42NjE0MTI3
Ii8+Cgk8L3JlZmVyZW5jZT4KCQoJPHJlZmVyZW5jZSBhbmNob3I9IkJhY2NlbGxpMjAxNCIgdGFy
Z2V0PSJodHRwczovL2RsLmFjbS5vcmcvZG9pL2Ficy8xMC4xMTQ1LzI2NjAxMjkuMjY2MDE0NCI+
CgkgIDxmcm9udD4KCSAgCTx0aXRsZT5JbmZvcm1hdGlvbiBjZW50cmljIG5ldHdvcmtpbmcgaW4g
dGhlIElvVDogZXhwZXJpbWVudHMgd2l0aCBORE4gaW4gdGhlIHdpbGQsIGluIEFDTS1JQ04gJzE0
OiBQcm9jZWVkaW5ncyBvZiB0aGUgMXN0IEFDTSBDb25mZXJlbmNlIG9uIEluZm9ybWF0aW9uLUNl
bnRyaWMgTmV0d29ya2luZzwvdGl0bGU+CgkgIAk8YXV0aG9yIHN1cm5hbWU9IkJhY2NlbGxpIiBp
bml0aWFscz0iRS4iIGZ1bGxuYW1lPSJFbW1hbnVlbCBCYWNjZWxsaSIvPgoJICAJPGF1dGhvciBz
dXJuYW1lPSJNZWhsaXMiIGluaXRpYWxzPSJDLiIgZnVsbG5hbWU9IkNocmlzdGlhbiBNZWhsaXMi
Lz4KCSAgCTxhdXRob3Igc3VybmFtZT0iSGFobSIgaW5pdGlhbHM9Ik8uIiBmdWxsbmFtZT0iT2xp
dmVyIEhhaG0iLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iU2NobWlkdCIgaW5pdGlhbHM9IlQuIiBm
dWxsbmFtZT0iVGhvbWFzIFNjaG1pZHQiLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iV8OkaGxpc2No
IiBpbml0aWFscz0iTS4iIGZ1bGxuYW1lPSJNYXR0aGlhcyBXw6RobGlzY2giLz4KCSAgCTxkYXRl
IG1vbnRoPSJTZXB0ZW1iZXIiIHllYXI9IjIwMTQiLz4KCSAgPC9mcm9udD4KCSAgPHNlcmllc0lu
Zm8gbmFtZT0iRE9JIiB2YWx1ZT0iMTAuMTE0NS8yNjYwMTI5LjI2NjAxNDQiLz4KCTwvcmVmZXJl
bmNlPgoJCgk8cmVmZXJlbmNlIGFuY2hvcj0iTGluZGdyZW4yMDE2IiB0YXJnZXQ9Imh0dHBzOi8v
aWVlZXhwbG9yZS5pZWVlLm9yZy9hYnN0cmFjdC9kb2N1bWVudC83NDQ0OTA1Ij4KCSAgPGZyb250
PgoJICAJPHRpdGxlPkRlc2lnbiBjaG9pY2VzIGZvciB0aGUgSW9UIGluIEluZm9ybWF0aW9uLUNl
bnRyaWMgTmV0d29ya3MsIGluIDEzdGggSUVFRSBBbm51YWwgQ29uc3VtZXIgQ29tbXVuaWNhdGlv
bnMgYW5kIE5ldHdvcmtpbmcgQ29uZmVyZW5jZSAoQ0NOQyk8L3RpdGxlPgoJICAJPGF1dGhvciBz
dXJuYW1lPSJMaW5kZ3JlbiIgaW5pdGlhbHM9IkEuIiBmdWxsbmFtZT0iQW5kZXJzIExpbmRncmVu
Ii8+CgkgIAk8YXV0aG9yIHN1cm5hbWU9IkJlbiBBYmRlc3NpZW0iIGluaXRpYWxzPSJGLiIgZnVs
bG5hbWU9IkZlaG1pIEJlbiBBYmRlc3NsZW0iLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iQWhsZ3Jl
biIgaW5pdGlhbHM9IkIuIiBmdWxsbmFtZT0iQmVuZ3QgQWhsZ3JlbiIvPgoJICAJPGF1dGhvciBz
dXJuYW1lPSJTY2hsZWzDqW4iIGluaXRpYWxzPSJPLiIgZnVsbG5hbWU9IiBPbG92IFNjaGVsw6lu
Ii8+CgkgIAk8YXV0aG9yIHN1cm5hbWU9Ik1hbGlrIiBpbml0aWFscz0iQS5NLiIgZnVsbG5hbWU9
IkFkZWVsIE1vaGFtbWFkIE1hbGlrIi8+CgkgIAk8ZGF0ZSBtb250aD0iSmFudWFyeSIgeWVhcj0i
MjAxNiIvPgoJICA8L2Zyb250PgoJICA8c2VyaWVzSW5mbyBuYW1lPSJET0kiIHZhbHVlPSIxMC4x
MTA5L0NDTkMuMjAxNi43NDQ0OTA1Ii8+Cgk8L3JlZmVyZW5jZT4KCQoJPHJlZmVyZW5jZSBhbmNo
b3I9Ikd1bmRvZ2FuMjAxOCIgdGFyZ2V0PSJodHRwczovL2RsLmFjbS5vcmcvZG9pL2Ficy8xMC4x
MTQ1LzMyNjc5NTUuMzI2OTAyMCI+CgkgIDxmcm9udD4KCSAgCTx0aXRsZT5Ib1BQOiBwdWJsaXNo
LXN1YnNjcmliZSBmb3IgdGhlIGNvbnN0cmFpbmVkIElvVCwgaW4gSUNOICcxODogUHJvY2VlZGlu
Z3Mgb2YgdGhlIDV0aCBBQ00gQ29uZmVyZW5jZSBvbiBJbmZvcm1hdGlvbi1DZW50cmljIE5ldHdv
cmtpbmc8L3RpdGxlPgoJICAJPGF1dGhvciBzdXJuYW1lPSJHw7xuZG/En2FuIiBpbml0aWFscz0i
Qy4iIGZ1bGxuYW1lPSJDZW5rIEfDvG5kb8SfYW4iLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iS2ll
dHptYW5uIiBpbml0aWFscz0iUC4iIGZ1bGxuYW1lPSJQZXRlciBLaWV0em1hbm4iLz4KCSAgCTxh
dXRob3Igc3VybmFtZT0iU2NobWlkdCIgaW5pdGlhbHM9IlQuIiBmdWxsbmFtZT0iVGhvbWFzIFNj
aG1pZHQiLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iV8OkaGxpc2NoIiBpbml0aWFscz0iTS4iIGZ1
bGxuYW1lPSJNYXR0aGlhcyBXw6RobGlzY2giLz4KCSAgCTxkYXRlIG1vbnRoPSJTZXB0ZW1iZXIi
IHllYXI9IjIwMTgiLz4KCSAgPC9mcm9udD4KCSAgPHNlcmllc0luZm8gbmFtZT0iRE9JIiB2YWx1
ZT0iMTAuMTE0NS8zMjY3OTU1LjMyNjkwMjAiLz4KCTwvcmVmZXJlbmNlPgoJCgk8cmVmZXJlbmNl
IGFuY2hvcj0iQ2hlbjIwMTUiIHRhcmdldD0iaHR0cHM6Ly9pZWVleHBsb3JlLmllZWUub3JnL2Rv
Y3VtZW50LzczMTIxNTQiPgoJICA8ZnJvbnQ+CgkgIAk8dGl0bGU+TkRTUzogQSBOYW1lZCBEYXRh
IFN0b3JhZ2UgU3lzdGVtLCBpbiBJbnRlcm5hdGlvbmFsIENvbmZlcmVuY2Ugb24gQ2xvdWQgYW5k
IEF1dG9ub21pYyBDb21wdXRpbmc8L3RpdGxlPgoJICAJPGF1dGhvciBzdXJuYW1lPSJDaGVuIiBp
bml0aWFscz0iUy4iIGZ1bGxuYW1lPSJTaHVvIENoZW4iLz4KCSAgCTxhdXRob3Igc3VybmFtZT0i
Q2FvIiBpbml0aWFscz0iSi4iIGZ1bGxuYW1lPSJKdW53ZWkgQ2FvIi8+CgkgIAk8YXV0aG9yIHN1
cm5hbWU9IlpodSIgaW5pdGlhbHM9IkwuIiBmdWxsbmFtZT0iTGlwZW5nIFpodSIvPgoJICAJPGRh
dGUgbW9udGg9IlNlcHRlbWJlciIgeWVhcj0iMjAxNCIvPgoJICA8L2Zyb250PgoJICA8c2VyaWVz
SW5mbyBuYW1lPSJET0kiIHZhbHVlPSIxMC4xMTA5L0lDQ0FDLjIwMTUuMTIiLz4KCTwvcmVmZXJl
bmNlPgoJCgk8cmVmZXJlbmNlIGFuY2hvcj0iRGlCZW5lZGV0dG9HVFUxMiIgdGFyZ2V0PSJodHRw
czovL3d3dy5uZHNzLXN5bXBvc2l1bS5vcmcvbmRzczIwMTIvYW5kYW5hLWFub255bW91cy1uYW1l
ZC1kYXRhLW5ldHdvcmtpbmctYXBwbGljYXRpb24iPgoJICA8ZnJvbnQ+CgkJPHRpdGxlPkFORGFO
QTogQW5vbnltb3VzIE5hbWVkIERhdGEgTmV0d29ya2luZyBBcHBsaWNhdGlvbiwgaW4gTkRTUyAy
MDEyPC90aXRsZT4KCQk8YXV0aG9yIHN1cm5hbWU9IkRpQmVuZWRldHRvIiBpbml0aWFscz0iUy4i
IGZ1bGxuYW1lPSJTdGV2ZSBCZW5lZGV0dG8iLz4KCQk8YXV0aG9yIHN1cm5hbWU9Ikdhc3RpIiBp
bml0aWFscz0iUC4iIGZ1bGxuYW1lPSJQYW9sbyBHYXN0aSIvPgoJCTxhdXRob3Igc3VybmFtZT0i
VHN1ZGlrIiBpbml0aWFscz0iRy4iIGZ1bGxuYW1lPSJHZW5lIFRzdWRpayIvPgoJCTxhdXRob3Ig
c3VybmFtZT0iVXp1biIgaW5pdGlhbHM9IkUuIiBmdWxsbmFtZT0iRXJzaW4gVXp1biIvPgoJCTxk
YXRlIHllYXI9IjIxMDIiLz4KCSAgPC9mcm9udD4KCSAgPHNlcmllc0luZm8gbmFtZT0iRE9JIiB2
YWx1ZT0iaHR0cHM6Ly9hcnhpdi5vcmcvYWJzLzExMTIuMjIwNXYyIi8+Cgk8L3JlZmVyZW5jZT4K
CQoJPHJlZmVyZW5jZSBhbmNob3I9IkdoYWxpMjAxNyIgdGFyZ2V0PSJodHRwczovL2RsLmFjbS5v
cmcvZG9pL2Ficy8xMC4xMTQ1LzMxMjU3MTkuMzEyNTcyMyI+CgkgIDxmcm9udD4KCSAgCTx0aXRs
ZT5XaGVuIGVuY3J5cHRpb24gaXMgbm90IGVub3VnaDogcHJpdmFjeSBhdHRhY2tzIGluIGNvbnRl
bnQtY2VudHJpYyBuZXR3b3JraW5nLCBpbiBJQ04gJzE3OiBQcm9jZWVkaW5ncyBvZiB0aGUgNHRo
IEFDTSBDb25mZXJlbmNlIG9uIEluZm9ybWF0aW9uLUNlbnRyaWMgTmV0d29ya2luZzwvdGl0bGU+
CgkgIAk8YXV0aG9yIHN1cm5hbWU9IlRzdWRpayIgaW5pdGlhbHM9IkcuIiBmdWxsbmFtZT0iR2Vu
ZSBUc3VkaWsiLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iR2hhbGkiIGluaXRpYWxzPSJDLiIgZnVs
bG5hbWU9IkNlc2FyIEdoYWxpIi8+CgkgIAk8YXV0aG9yIHN1cm5hbWU9Ildvb2QiIGluaXRpYWxz
PSJDLiIgZnVsbG5hbWU9IkNocmlzdG9waGVyIFdvb2QiLz4KCSAgCTxkYXRlIG1vbnRoPSJTZXB0
ZW1iZXIiIHllYXI9IjIwMTciLz4KCSAgPC9mcm9udD4KCSAgPHNlcmllc0luZm8gbmFtZT0iRE9J
IiB2YWx1ZT0iaHR0cHM6Ly9kb2kub3JnLzEwLjExNDUvMzEyNTcxOS4zMTI1NzIzIi8+Cgk8L3Jl
ZmVyZW5jZT4KCQoJPHJlZmVyZW5jZSBhbmNob3I9IkFyaWFuZmFyMjAxMSIgdGFyZ2V0PSJodHRw
czovL2RsLmFjbS5vcmcvZG9pLzEwLjExNDUvMjAxODU4NC4yMDE4NTg5Ij4KCSAgPGZyb250PgoJ
ICAJPHRpdGxlPk9uIHByZXNlcnZpbmcgcHJpdmFjeSBpbiBjb250ZW50LW9yaWVudGVkIG5ldHdv
cmtzLCBpbiBJQ04gJzExOiBQcm9jZWVkaW5ncyBvZiB0aGUgQUNNIFNJR0NPTU0gd29ya3Nob3Ag
b24gSW5mb3JtYXRpb24tY2VudHJpYyBuZXR3b3JraW5nPC90aXRsZT4KCSAgCTxhdXRob3Igc3Vy
bmFtZT0iQXJpYW5mYXIiIGluaXRpYWxzPSJTLiIgZnVsbG5hbWU9IlNvbWF5YSBBcmlhbmZhciIv
PgoJICAJPGF1dGhvciBzdXJuYW1lPSJLb3BvbmVuIiBpbml0aWFscz0iVC4iIGZ1bGxuYW1lPSJU
ZWVtdSBLb3BvbmVuIi8+CgkgIAk8YXV0aG9yIHN1cm5hbWU9IlJhZ2hhdmFuIiBpbml0aWFscz0i
Qi4iIGZ1bGxuYW1lPSJCYXJhdGggUmFnaGF2YW4iLz4KCSAgCTxhdXRob3Igc3VybmFtZT0iU2hl
bmtlciIgaW5pdGlhbHM9IlMuIiBmdWxsbmFtZT0iU2NvdHQgU2hlbmtlciIvPgoJICAJPGRhdGUg
bW9udGg9IkF1Z3VzdCIgeWVhcj0iMjAxMSIvPgoJICA8L2Zyb250PgoJICA8c2VyaWVzSW5mbyBu
YW1lPSJET0kiIHZhbHVlPSJodHRwczovL2RvaS5vcmcvMTAuMTE0NS8yMDE4NTg0LjIwMTg1ODki
Lz4KCTwvcmVmZXJlbmNlPgoKCgogIDwvcmVmZXJlbmNlcz4KICAgICAgCiAgICAgIDwhLS0gQ2hh
bmdlIExvZwoJICAgdjAwIDIwMjAtMDMtMTUgIERSTy9ESyBJbml0aWFsIHZlcnNpb24KICAgICAg
LS0+CiAgICA8L2JhY2s+CiAgPC9yZmM+CiAgCg==
--=_MailMate_5F5F5079-90CD-440B-AFDE-4B4D9EE2DACF_=--