From nobody Thu Aug 1 09:56:05 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2916A1200E0; Thu, 1 Aug 2019 09:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156467856303.19329.15131153168134727262@ietfa.amsl.com> Date: Thu, 01 Aug 2019 09:56:03 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-08-27 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 16:56:03 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-08-27 from 22:00 to 23:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Thu Aug 1 09:57:22 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A788A1200E0; Thu, 1 Aug 2019 09:57:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156467864064.19363.16495666444713214051@ietfa.amsl.com> Date: Thu, 01 Aug 2019 09:57:20 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-09-24 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 16:57:21 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-09-24 from 22:00 to 23:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Thu Aug 1 09:58:42 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1241200E0; Thu, 1 Aug 2019 09:58:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156467871179.19207.4446652162125694559@ietfa.amsl.com> Date: Thu, 01 Aug 2019 09:58:31 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-10-29 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 16:58:32 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-10-29 from 22:00 to 23:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Thu Aug 1 09:58:55 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9378F1201C5; Thu, 1 Aug 2019 09:58:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156467872053.19223.17837747572565895922@ietfa.amsl.com> Date: Thu, 01 Aug 2019 09:58:40 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-12-03 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 16:58:46 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-12-03 from 22:00 to 23:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Thu Aug 1 17:05:39 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3B3120073 for ; Thu, 1 Aug 2019 17:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 75baZApJ281H for ; Thu, 1 Aug 2019 17:05:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D49612001A for ; Thu, 1 Aug 2019 17:05:35 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9F20D380BE for ; Thu, 1 Aug 2019 20:05:06 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A09F28EF for ; Thu, 1 Aug 2019 20:05:34 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: <156467872053.19223.17837747572565895922@ietfa.amsl.com> References: <156467872053.19223.17837747572565895922@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-12-03 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 00:05:38 -0000 --=-=-= Content-Type: text/plain IESG Secretary wrote: > The Codec Encoding for LossLess Archiving and Realtime transmission > (cellar) Working Group will hold a virtual interim meeting on > 2019-12-03 from 22:00 to 23:00 Europe/Paris. Reto, did we get this time right? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1Dfk4ACgkQgItw+93Q 3WWYggf8DXo/Y3isdyntxXOjDVnQb8nUUUaQU1oQ4mdJO6do3E4ZpaScyYtxp29/ gRK2RY2pUYrZ+ryIy4FXempS3Z6AAlc+YooBUrxE4iAahGwHzA0pMobTaMvrb1Jm HXqDg36m74pHauaq5WSxzNAdWOvQhLJsvfGaQqL0v/vB6qc53hYz1YNXkFucWiAq vdczwb8Mpfr/8DCfZ8i84un5hjaEpwT+5763H1EURafNiV3jJ8SWVO9ktP285Cmy 7xGLO/sT6mQrnfRXfehub0TMn/omTOzCQ9zZk674M4E+0rYsoIdodvlOj6+iFj0y KUJt4K9V1jJWGWknaFilRqdc/+GfTQ== =r/Er -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 2 02:17:39 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3AE120072 for ; Fri, 2 Aug 2019 02:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 T0ZSClOdlEOM for ; Fri, 2 Aug 2019 02:17:35 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 5CECD12004E for ; Fri, 2 Aug 2019 02:17:35 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x729HX6P225804 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 2 Aug 2019 11:17:33 +0200 Received: from Castor ([IPv6:2a02:aa13:4680:f280:cdb5:e1a8:82a1:e032]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x729HWAU001112 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 2 Aug 2019 11:17:33 +0200 Date: Fri, 2 Aug 2019 11:17:33 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <18555.1564704334@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-12-03 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 09:17:38 -0000 Michael Richardson wrote: >IESG Secretary wrote: >> The Codec Encoding for LossLess Archiving and Realtime transmission >> (cellar) Working Group will hold a virtual interim meeting on >> 2019-12-03 from 22:00 to 23:00 Europe/Paris. > >Reto, did we get this time right? That's the same time than it's currently, from 22:00 to 23:00 CET/CEST (or form 10 pm to 11 pm). Yet if I am the only one who cannot be present that late, then please keep it as it is. Best regards, Reto From nobody Fri Aug 2 10:41:26 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD431120770 for ; Fri, 2 Aug 2019 10:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 A4EEl6TVtL3z for ; Fri, 2 Aug 2019 10:41:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4853612076E for ; Fri, 2 Aug 2019 10:41:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7B4EE3818D; Fri, 2 Aug 2019 13:40:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 937D4983; Fri, 2 Aug 2019 13:41:16 -0400 (EDT) From: Michael Richardson To: Reto Kromer cc: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Fri, 02 Aug 2019 13:41:16 -0400 Message-ID: <18711.1564767676@localhost> Archived-At: Subject: Re: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-12-03 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 17:41:25 -0000 Reto Kromer wrote: >> IESG Secretary wrote: >>> The Codec Encoding for LossLess Archiving and Realtime transmission >>> (cellar) Working Group will hold a virtual interim meeting on >>> 2019-12-03 from 22:00 to 23:00 Europe/Paris. >> >> Reto, did we get this time right? > That's the same time than it's currently, from 22:00 to 23:00 CET/CEST > (or form 10 pm to 11 pm). Yet if I am the only one who cannot be > present that late, then please keep it as it is. The intention was to have it an hour earlier. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From nobody Fri Aug 2 13:35:52 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0F01200E9; Fri, 2 Aug 2019 13:35:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156477814469.20950.5000739942670838903@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:35:44 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-08-27 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:35:45 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-08-27 from 21:00 to 22:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Fri Aug 2 13:36:08 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7A1120833; Fri, 2 Aug 2019 13:36:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156477816309.20999.10175594682527135245@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:36:03 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-09-24 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:36:06 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-09-24 from 21:00 to 22:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Fri Aug 2 13:36:32 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 046981207F8; Fri, 2 Aug 2019 13:36:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156477818798.20918.10977233790747106269@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:36:28 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-10-29 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:36:31 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-10-29 from 21:00 to 22:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Fri Aug 2 13:36:52 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C11781207EA; Fri, 2 Aug 2019 13:36:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156477820576.20966.4818063946479175962@ietfa.amsl.com> Date: Fri, 02 Aug 2019 13:36:45 -0700 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-12-03 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 20:36:50 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-12-03 from 21:00 to 22:00 Europe/Paris. Agenda: (No agenda submitted) Information about remote participation: https://appear.in/cellar-interim From nobody Fri Aug 2 21:41:04 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 215D2120073 for ; Fri, 2 Aug 2019 21:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 4a06R8nWc1Aq for ; Fri, 2 Aug 2019 21:41:00 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 B65F612006D for ; Fri, 2 Aug 2019 21:40:59 -0700 (PDT) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id x734ev41091125 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 3 Aug 2019 06:40:57 +0200 Received: from Castor ([IPv6:2a02:aa13:4680:f280:a5d4:6d59:1072:6c18]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id x734euTQ130745 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 3 Aug 2019 06:40:57 +0200 Date: Sat, 3 Aug 2019 06:40:57 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <156477814469.20950.5000739942670838903@ietfa.amsl.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-08-27 CHANGED X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2019 04:41:02 -0000 IESG Secretary wrote: >The Codec Encoding for LossLess Archiving and Realtime >transmission (cellar) Working Group will hold a virtual interim >meeting on 2019-08-27 from 21:00 to 22:00 Europe/Paris. Hello Michael, now it's correct: the four future virtual meetings are scheduled one hour earlier. Thank you very much! Best regards, Reto From nobody Sat Aug 10 08:18:33 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D8F120163 for ; Sat, 10 Aug 2019 08:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=bunkus.org 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 JHG1laLrHk-e for ; Sat, 10 Aug 2019 08:18:23 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 A8B8512018B for ; Sat, 10 Aug 2019 08:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=rD1i9F0f5IQkxdPwBylSCs5zGG5lYjuDs7Xz9HHsA5o=; b=zp8yV3fWvr6BPUAePnnnJZanRJ6cnt+QxHq9y/UljB/r+ZWDldCxgd+bTl4ytF3cIJbQTg9b0nwgvFR80jna/KYUTXA/LQi4bO8a1CRsGLyyuzHKflxjWyohGyWEdYQgmH2xOoNoNI/TajZCBa5PoSwqo5c9nssogcYIMenqyAA=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:48274) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1hwT8K-0003Jj-0i; Sat, 10 Aug 2019 17:18:17 +0200 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id C893B65435BB; Sat, 10 Aug 2019 17:18:08 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 2F6042C616C; Sat, 10 Aug 2019 17:18:08 +0200 (CEST) X-CTCH-RefID: str=0001.0A090208.5D4EE039.0047, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.2.0; emacs 26.2 From: Moritz Bunkus To: Cellar list , help Questions Date: Sat, 10 Aug 2019 17:18:08 +0200 Message-ID: <87d0hd82xb.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v36.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 15:18:32 -0000 Hey, Here=E2=80=99s another small summery bug fix release for MKVToolNix, v36.0.0. Nothing major=E2=80=99s changed; just a couple of fixes here & the= re. There've been no changes regarding packaging since the previous release. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 36.0.0 "Is That Jazz?" 2019-08-10 ## New features and enhancements * mkvmerge: mkvmerge now allows appending AV1, VP8, VP9, H.264/AVC and H.265/HEVC tracks whose pixel dimensions differ. Implements #2582. ## Bug fixes * source code: fixed building with Boost 1.71.0. Fixes #2599. * all: fixed the spelling of the H.264 & H.265 codec names. * mkvmerge: Blu-ray MPLS handling: mkvmerge will now find corresponding M2TS files even if the `clip_codec_identifier` playlist item field is not set = to `M2TS` in the MPLS file. Fixes #2601. * mkvmerge: fixed handling of text files that use both DOS-style and Unix-style line endings resulting in problems such as text subtitle files not being parsed correctly. Fixes #2594. ------------------------------------------------------------ Have fun :) mosu From nobody Tue Aug 13 07:07:40 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF5712018D; Tue, 13 Aug 2019 07:07:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <156570525035.24192.11478213250563651884@ietfa.amsl.com> Date: Tue, 13 Aug 2019 07:07:30 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-08.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 14:07:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-08.txt Pages : 45 Date : 2019-08-13 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-08 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 13 07:09:34 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE3D21201DE; Tue, 13 Aug 2019 07:09:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <156570537181.24067.13488360349948056963@ietfa.amsl.com> Date: Tue, 13 Aug 2019 07:09:31 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-05.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 14:09:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-05.txt Pages : 45 Date : 2019-08-13 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-v4-05 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 23 14:23:22 2019 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 969CB120047; Fri, 23 Aug 2019 14:23:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mcr+ietf@sandelman.ca, cellar@ietf.org, cellar-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156659540054.25007.15452884463686685878.idtracker@ietfa.amsl.com> Date: Fri, 23 Aug 2019 14:23:20 -0700 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 106 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 21:23:21 -0000 Michael Richardson, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 106. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Sat Aug 24 02:06:45 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E096A12007A for ; Sat, 24 Aug 2019 02:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=bunkus.org 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 DYupHnASkBya for ; Sat, 24 Aug 2019 02:06:42 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 466E112003F for ; Sat, 24 Aug 2019 02:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=6aIBBG/2hNE+G+N3u+3yCGD344pr7Yt62a7elDqp4MQ=; b=DLR0k2hwVRtwdEAjOfMoc0qQp5V+Emglj/7g7S3+d6SeX8WXiQfAKxu4BqZhDrKJKMJp8TEw+FurIMwddeTR8cSHKknBfs2BCi47G3+4nzImFgChe+bv7T5vevahNg+4G+Whvz3DGAW+PUE5WASFy5YvS77IyYRfrFV/7P4iSbw=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:43858) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1i1S0L-0005Ye-1B; Sat, 24 Aug 2019 11:06:37 +0200 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 63E3E6540086; Sat, 24 Aug 2019 11:06:31 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 9D70C658DB5; Sat, 24 Aug 2019 11:06:30 +0200 (CEST) X-CTCH-RefID: str=0001.0A090211.5D60FE1D.002F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 User-agent: mu4e 1.2.0; emacs 26.2 From: Moritz Bunkus To: Cellar list , help Questions Date: Sat, 24 Aug 2019 11:06:30 +0200 Message-ID: <87a7bzue3t.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v37.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 09:06:44 -0000 Hey, Due to two nasty bugs in v36 I'm releasing v37 sooner than anticipated. This release fixes both of the bugs; see below for details. There've been no changes regarding packaging since the previous release. Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 37.0.0 "Leave It" 2019-08-24 ## New features and enhancements * MKVToolNix GUI: the list of often used languages now contains those from Wikipedia's "List of languages by native speakers" by default. Also by default only those languages will be shown in the language drop-down boxe= s. ## Bug fixes * MKVToolNix GUI: multiplexer: fixed a bug in the "make destination file na= mes unique" logic that caused an existing number-in-parenthesis at the end of the file base name to be removed in certain situations (e.g. when the fir= st added file was named `m (3).mkv` and both `m (3) (1).mkv` and `m (3) (2).mkv` existed already, the GUI was suddenly use `m.mkv` instead of `m = (3) (3).mkv`). * MKVToolNix GUI: on Windows the GUI is built with a slightly older version= of the Qt library again (5.12.4). The Qt version used in release v36.0.0, v5.13.0, lead to crashes when doing certain things such as selecting multiple tracks in the multiplexer. Fixes #2605 and #26008. ------------------------------------------------------------ Have fun :) mosu From nobody Mon Aug 26 10:37:21 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A51120B01 for ; Mon, 26 Aug 2019 10:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 m1Dd4ooxK4gY for ; Mon, 26 Aug 2019 10:37:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070CD120AEB for ; Mon, 26 Aug 2019 10:37:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 89241380BE for ; Mon, 26 Aug 2019 13:36:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AE74170F for ; Mon, 26 Aug 2019 13:37:16 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] DRAFT AGENDA 2019-08-27 19:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 17:37:21 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable CELLAR -- DRAFT AGENDA for Virtual Interim Meeting August 27, 2019 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco NOTE this is one hour earlier than last time! INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-07/session/cell= ar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-07-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. 2. Accept draft minutes from July 30 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospaceF= ont=3Dtrue 2b) APPEAR.IN is not called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. WG status update * EBML -- still waiting on revised -11 document for AD evaluation. We had a lot of conversation last time about solving this logjam. Much work on it 2019-08-26, is it done? 5. Remining EBML issues, hoping for none. Issue #279 https://github.com/cellar-wg/ebml-specification/issues/279 Pull request: https://github.com/cellar-wg/ebml-specification/pull/281 5. Work on Matroska issues. 6. Any other business. =3D=3D=3D=3D CELLAR -- DRAFT AGENDA for Virtual Interim Meeting July 30, 2019 20:00 UTC Present: 1) Michael Richardson 2) Timothy B. Terriberry 3) Steve Lhomme 4) Martin Below 5) Dave Rice 6) Michael Niedermeier Regrets: Jerome Martinez INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-06/session/cel= lar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-06-sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from June 25 meeting (attached below) No objections/changes, minutes passed. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useMonospace= Font=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim 2c) Roll call 4. WG status update * EBML -- still waiting on revised -11 document for AD evaluation. ACTION from last time: =3D=3D> issue #257, requested one more day to think about i= t. The changes are fine in general, but want to make sure it precise enough. = (MB) We created issue #279 to introduce some new text to better explain what a = Global Element is, and why it does not end an unlimited size Element. * Thank for reposting of draft-ietf-cellar-tags-02, draft-ietf-cellar-matroska-03 and draft-ietf-cellar-codec-02 * The personal draft-weaver-cellar-flac-00 did not get reposted. I believe that we adopted it, so it should have been reposted with a draft-ietf-cellar-flac-00! reposted today, thank you. 5. Any remining EBML issues. none known. 6. ffv1-07 could be reposted in v3 format. ACTION: mcr to ask DataTracker and RSE if they are ready for this. 7. Work on Matroska issues. Closed issue #325 (merged). Discussed issue #334 and related issue #308. 8. Any other business. Matroska Pull request #318 will be on the agenda for next time. Meeting will be moved to an hour earlier, until the time changes. Currently it is 23:00 Berlin, so we will anchor the meeting to 22:00 Berli= n time. =3D=3D=3D=3D CELLAR -- DRAFT AGENDA for Virtual Interim Meeting June 25, 2019 20:00 UTC INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-05/ses= sion/cellar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-05-= sessa/ WEB CONFERENCE: https://appear.in/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes Present: 1) Michael Richardson 2) Moritz Bunkus 3) Martin Below 4) Steve Lhomme 5) Dave Rice 6) J=C3=A9r=C3=B4me Martinez Regrets: 1) Reto Kromer 1. Note Well. 2. Accept draft minutes from May 28 meeting accepted without change. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual?useM= onospaceFont=3Dtrue 2b) APPEAR.IN for video and screen sharing. https://appear.in/cellar-interim 2c) Roll call 4. WG status update * MCR still need to help Martin on large pull request. * EBML changes... done. + issue #257, requested one more day to think about it. Th= e changes are fine in general, but want to make sure it precise enough. (MB) * ffv1 has been submitted to IESG by AD. 5. Work on Matroska issues. 48 open issues 21 open pull requests https://github.com/cellar-wg/matroska-specification/issues Next time, Steve will walk us through XSLT code to validat= e the specification. TAG: "format extension" suggestion that does not have to go into the mai= n spec, because it could be added as separate spec https://github.com/cel= lar-wg/matroska-specification/issues?q=3Dis%3Aissue+is%3Aopen+label%3A%22fo= rmat+extension%22 "format addition" something that has to go into main specifica= tion. https://github.com/cellar-wg/matroska-specification/issues?q=3Dis%3= Aissue+is%3Aopen+label%3A%22format+addition%22 * As the WebM will not be defined, remove all of the WebM specific stuff. * MCR suggests removing it from the Matroska document, and leave t= he history for others. * MB: DivX is also not part of Matroska. Also concerned about how= the Matroska project presents the WebM/DiVX vs core Matroska elements. T= he spec will be huge, so take things out. * define how to add unpredictable data to the Matroska, so we could track = things that are added. Not just WebM, but also a libmotrsaka as well. * extension data would be on their own lines, and revision history would b= e clearly. 6. Any other business. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1kGMwACgkQgItw+93Q 3WXO4Qf+NENlxbTqzNndnKbF7zj/vwt3CnDESDeNdwNYNqDw19wxtm8QaPJ59ENU 6suyrU+tsyirHRbhx9GMaA5JSjxP5mj+8IsjSPJkDarLUDJVF8nljbbMYmbPYcHQ Hwq3spMf2Vmvc4Q5Ia06lcz2eHCVBN6fuY0L/uH5ON8jY1aOmi0sMzpeBkUoPSGz MZgtFgjV5S0Mxtz+ay2GVzGLGPcYIPr29i10Z8O4FsKutbeOhadp8L6kwG+tEQSS Tyl6W0K/8M2yM9TcFjZHS1z2AXJnudR5nEPxITAeGMb6Q5EAZgLtQ0HOsOQK91z9 jq8gDYxlJMPSDTcCBbyVktKsneKFiQ== =telg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 26 10:40:59 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D7A120B0E for ; Mon, 26 Aug 2019 10:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=bunkus.org 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 So_wLkHm2uOE for ; Mon, 26 Aug 2019 10:40:56 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 CAC2F120B0D for ; Mon, 26 Aug 2019 10:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:To:From:References; bh=dt4lUEM10O1CMKQzQ4Wdrb/W7K7eTdph0E5tzKXOaX8=; b=h0mXP1ppriZEZ+eD2yN5H5GEw4YawwZNQMdbqjXsX/AyWDZ3jEAVfrLkqSssr494WuZnSpwatKNyHI/WnqN5qHugnPWTyLpnQz00zpdYEWlo1gJVqT6qVOrde3Df2HyeIfOQBGNvrI9AHjKNx1QpDWwsRmRygRQBUn1+OhEA8j4=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:56274) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1i2Iyv-0007Ev-0t for cellar@ietf.org; Mon, 26 Aug 2019 19:40:41 +0200 Received: from sweet-chili.local (unknown [10.55.5.2]) by liselle.bunkus.org (Postfix) with ESMTPS id 3376B6543664 for ; Mon, 26 Aug 2019 19:40:35 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id A94D56C9587 for ; Mon, 26 Aug 2019 19:40:34 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0210.5D641999.005D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 References: <21096.1566841036@localhost> User-agent: mu4e 1.2.0; emacs 26.2 From: Moritz Bunkus To: cellar@ietf.org In-reply-to: <21096.1566841036@localhost> Date: Mon, 26 Aug 2019 19:40:34 +0200 Message-ID: <87v9ujn7u5.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] DRAFT AGENDA 2019-08-27 19:00 UTC virtual interim meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 17:40:58 -0000 Hey, unfortunately I'll be out of town due to work for most of Tuesday; it's likely that I won't be back in time for the meeting. I'll try to make it, but please don't wait for me if I'm not on time. Kind regards, mosu From nobody Tue Aug 27 07:24:54 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2220B120236 for ; Tue, 27 Aug 2019 07:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 Qqge-hNwot9Y for ; Tue, 27 Aug 2019 07:24:51 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 ED037120220 for ; Tue, 27 Aug 2019 07:24:47 -0700 (PDT) Received: from [146.96.19.240] (port=25319 helo=[10.10.201.23]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i2cOp-003X8J-4c for cellar@ietf.org; Tue, 27 Aug 2019 10:24:47 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_1AE895C0-B164-47E7-88CD-7AAB52148251" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <9B0701D1-79B5-40E0-8701-BC711282093B@dericed.com> Date: Tue, 27 Aug 2019 10:24:41 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 14:24:53 -0000 --Apple-Mail=_1AE895C0-B164-47E7-88CD-7AAB52148251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar, I=E2=80=99m doing an idnits review on the latest ffv1 draft and am = confused about the IETF rules for non-ascii characters in txt rfc = drafts. The update at https://tools.ietf.org/html/rfc7997 = seems to allow the RFC Editor to = use some discretion in using non-ascii characters, but idnits = still complains about that. One = instance is using a Unicode minus sign to be more semantically clear = than an ascii hyphen. Also since the Unicode minus sign uses more bytes = than the ascii hyphen, idnits will say the line is too long, even though = in appearance the line displays within the correct width. In the RFC for ffv1, we=E2=80=99ve used unicode symbols for floor and = ceiling functions, such as =E2=8C=8Aa=E2=8C=8B and =E2=8C=88a=E2=8C=89, = but rfc2xml transforms these into their hexadecimal expressions such as = ⌊a⌋ and ⌈a⌉. Any advice, should we listen to = idnits and avoid non-ascii characters or listen to rfc7997 and use them = when it makes the content more clear? Kind Regards, Dave Rice= --Apple-Mail=_1AE895C0-B164-47E7-88CD-7AAB52148251 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi cellar,

I=E2=80=99m doing an = idnits review on the latest ffv1 draft and am confused about the IETF = rules for non-ascii characters in txt rfc drafts. The update at https://tools.ietf.org/html/rfc7997 seems to allow = the RFC Editor to use some discretion in using non-ascii characters, = but idnits still complains about that. One instance is = using a Unicode minus sign to be more semantically clear than an ascii = hyphen. Also since the Unicode minus sign uses more bytes than the ascii = hyphen, idnits will say the line is too long, even though in appearance = the line displays within the correct width.

In the RFC for ffv1, we=E2=80=99ve used = unicode symbols for floor and ceiling functions, such as =E2=8C=8Aa=E2=8C=8B= and =E2=8C=88a=E2=8C=89, but rfc2xml transforms these into their = hexadecimal expressions such as &#8970;a&#8971; and = &#8968;a&#8969;. Any advice, should we listen to idnits and = avoid non-ascii characters or listen to rfc7997 and use them when it = makes the content more clear?

Kind Regards,
Dave = Rice
= --Apple-Mail=_1AE895C0-B164-47E7-88CD-7AAB52148251-- From nobody Tue Aug 27 11:29:19 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880C7120825; Tue, 27 Aug 2019 11:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 TdEjVKXArDmT; Tue, 27 Aug 2019 11:29:14 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7B01201B7; Tue, 27 Aug 2019 11:29:13 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1BA243818D; Tue, 27 Aug 2019 14:28:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF44889; Tue, 27 Aug 2019 14:29:12 -0400 (EDT) From: Michael Richardson To: tools-discuss@ietf.org, cellar@ietf.org X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:29:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable reposting to tools-discuss for comments. I suspect that the idnits tool may be in error in this case. We are also using xml-v3 for ffv1, since it is full of math which gets rendered to SVG.=20=20 From: Dave Rice Date: Tue, 27 Aug 2019 10:24:41 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission Hi cellar, I=E2=80=99m doing an idnits review on the latest ffv1 draft and am confused= about the IETF rules for non-ascii characters in txt rfc drafts. The update at https://tools.ietf.org/html/rfc7997 seems to allow the RFC Editor to use some discretion in using non-ascii characters, but idnits still complai= ns about that. One instance is using a Unicode minus sign to be more semantically clear than an ascii hyphen. Also since the Unicode minus sign uses more bytes than the ascii hyphen, idnits will say the line is too long, even though in appearance the line displays within the correct width.=20 In the RFC for ffv1, we=E2=80=99ve used unicode symbols for floor and ceili= ng functions, such as =E2=8C=8Aa=E2=8C=8B and =E2=8C=88a=E2=8C=89, but rfc2xml= transforms these into their hexadecimal expressions such as ⌊a⌋ and ⌈a⌉. Any advice, should we listen to idnits and avoid non-ascii characters or listen to rfc7997 and use them when it makes the content more clear?=20 Kind Regards, Dave Rice =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1ldngACgkQgItw+93Q 3WWBTwf+LgIQN8RQPWI3juT+71Q3zPZV8K2Uni9YNtOR8L7w9AhNcIweT8jQpYzy GLGeTESiyKW1OEDqR+cNOxQ7YgRBBh9mdsOIoYZjcCWyiYYoerzBUMKdmWd8YiU6 WYEkoRfZbgIcXB6vsmnvfj73wvUR13b+BL6Q0sM8VKC8AfpdnBd0Ibx5I4q/A6+A D3FAdJhdD84kYYp/V6s5G3kWVdQMWaoElV8ooF9N/mDgY6UgB4K0htu0reu0q4Iv SroLe9cKHfEtywCblO7/qj+L2E8WoWFZkO9NPQ23to7s/Uc0EeB2u57iO0a48YSV Gsv59mn5swP0uT3aGG2MkkXfOIVbuQ== =DNRR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 11:46:54 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F2C120834; Tue, 27 Aug 2019 11:46:51 -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 dza-_WzInrjx; Tue, 27 Aug 2019 11:46:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F43F120133; Tue, 27 Aug 2019 11:46:49 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53021 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 1i2gUR-0003db-4l; Tue, 27 Aug 2019 11:46:48 -0700 To: Michael Richardson , tools-discuss@ietf.org, cellar@ietf.org References: <31591.1566930552@localhost> From: Henrik Levkowetz Message-ID: Date: Tue, 27 Aug 2019 20:46:37 +0200 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: <31591.1566930552@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="DhUJlBnMb63gcMsp1cu7wre5KpjKWWRR0" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: cellar@ietf.org, tools-discuss@ietf.org, mcr+ietf@sandelman.ca 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: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 18:46:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --DhUJlBnMb63gcMsp1cu7wre5KpjKWWRR0 Content-Type: multipart/mixed; boundary="4RUhnwE9QJFCUqVOgGvsr4tmm8G6uGWd9"; protected-headers="v1" From: Henrik Levkowetz To: Michael Richardson , tools-discuss@ietf.org, cellar@ietf.org Message-ID: Subject: Re: [Tools-discuss] [Cellar] non-ascii characters (fwd) Dave Rice: [Cellar] non-ascii characters References: <31591.1566930552@localhost> In-Reply-To: <31591.1566930552@localhost> --4RUhnwE9QJFCUqVOgGvsr4tmm8G6uGWd9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, Here's my take on this: A number of people has highlighted the desirability of using math symbols= in text. However, this is not currently supported by xml2rfc v3, and wil= l make idnits unhappy. Putting math in SVG is currently the supported approach. Several approaches to permitting math other than by providing SVG artwork= has been raised and discussed, and there may be ways forward for this onc= e the current focus on the v3 format transition is complete, but until we reach completion on the transition effort, I don't think it's going to be= fruitful to push for this. (Personally, I've felt sufficiently strongly about inline and display mat= h support to propose a number of possible approaches to the RFC Editor, but= I don't have time over to do any prototyping of any of the most promising approaches until well after the xml2rfc v3 formatters are seen to be soli= d.) Best regards, Henrik On 2019-08-27 20:29, Michael Richardson wrote: >=20 > reposting to tools-discuss for comments. > I suspect that the idnits tool may be in error in this case. >=20 > We are also using xml-v3 for ffv1, since it is full of math which gets > rendered to SVG. =20 >=20 > From: Dave Rice > Date: Tue, 27 Aug 2019 10:24:41 -0400 > To: Codec Encoding for LossLess Archiving and Realtime transmission > >=20 > Hi cellar, >=20 > I=E2=80=99m doing an idnits review on the latest ffv1 draft and am conf= used about the > IETF rules for non-ascii characters in txt rfc drafts. The update at > https://tools.ietf.org/html/rfc7997 > seems to allow the RFC Editor to use some discretion in using non-ascii= > characters, but idnits still com= plains > about that. One instance is using a Unicode minus sign to be more > semantically clear than an ascii hyphen. Also since the Unicode minus s= ign > uses more bytes than the ascii hyphen, idnits will say the line is too = long, > even though in appearance the line displays within the correct width.=20 >=20 > In the RFC for ffv1, we=E2=80=99ve used unicode symbols for floor and c= eiling > functions, such as =E2=8C=8Aa=E2=8C=8B and =E2=8C=88a=E2=8C=89, but rfc= 2xml transforms these into their > hexadecimal expressions such as ⌊a⌋ and ⌈a⌉. An= y > advice, should we listen to idnits and avoid non-ascii characters or li= sten > to rfc7997 and use them when it makes the content more clear?=20 >=20 > Kind Regards, > Dave Rice >=20 >=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list > Tools-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > Please report datatracker.ietf.org and mailarchive.ietf.org > bugs at http://tools.ietf.org/tools/ietfdb > or send email to datatracker-project@ietf.org >=20 > Please report tools.ietf.org bugs at > http://tools.ietf.org/tools/issues > or send email to webmaster@tools.ietf.org >=20 --4RUhnwE9QJFCUqVOgGvsr4tmm8G6uGWd9-- --DhUJlBnMb63gcMsp1cu7wre5KpjKWWRR0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1leo0ACgkQTptXS4+7 FxoQ8BAAx08w2+QnsCrJG79+JLXlfclnN8iqL+IiE2bkAtEHbub56iKlY+r8zsZc lwBWXEMFSX/h/Lj5qH6NmkPJSuXRh443VVJqiDKG8Oh4RhD58zfd5CKY3hH/62xb Okx/orW/C5f/zu+sjFGyNiByGtoaw60TNu1je8a+tirSq5AS+pKfpli6wGm2V6sP DYZgDaLQ/GMfhPO3yG1t0Dttk/q36svGY4ECjzhA698B1Kst3f93jlyW8jlvAla+ xgmuyO3WUIkq1Ly2P5Al9OVobG3bwZFa8OHtWhJME65qWim+gIICclg1kPRIPw5G f8ExT0IRsprmIrhyr2VdndYexjQ5iWyFu7IzROBMr0kko2yfs4yKuloNLlbZo1XY 1cy8DWIy7yWVo4xi07Wmjz3KGBGOge2M2+Iznpwn/d7A978SzoHyySNGIZRGaXXG EqKlyM+BTLpo6SZAxry3toXWGJP1TfSLoqgAxSZfsFaFGHnzARm+xGjNqokWVmax mvO43NruvFk2hveUgErM3KltemCHx8bBRlP3hncz1/CrXGnc0beS+/4b9WTp0i4z alKlw3FB0acv4oo8lYBshWb8yTTyOuwRQ1NzT/y4AzCgG5THGLcke8E8tgms3MeD 877ZNrD2PR9/XUZAg632crvfscZwMSG3znNW3iQY5f+WUyLA638= =x0lS -----END PGP SIGNATURE----- --DhUJlBnMb63gcMsp1cu7wre5KpjKWWRR0-- From nobody Tue Aug 27 12:35:16 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFB4120133; Tue, 27 Aug 2019 12:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 DTkGBNyoqE-L; Tue, 27 Aug 2019 12:35:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B640120116; Tue, 27 Aug 2019 12:35:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F5DB3818E; Tue, 27 Aug 2019 15:34:03 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E69D68F1; Tue, 27 Aug 2019 15:35:10 -0400 (EDT) From: Michael Richardson To: Henrik Levkowetz cc: tools-discuss@ietf.org, cellar@ietf.org In-Reply-To: References: <31591.1566930552@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 19:35:15 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Henrik Levkowetz wrote: > Hi Michael, > Here's my take on this: > A number of people has highlighted the desirability of using math > symbols in text. However, this is not currently supported by xml2rfc > v3, and will make idnits unhappy. Putting math in SVG is currently t= he > supported approach. Yes, and we are using SVG. But we can't do it with XML yet (now Sept. 16). So we format a txt version for submission to post to the datatracker, and it has some UTF-8 in it. Are you agreeing that idnits is in error? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1lhe4ACgkQgItw+93Q 3WWMjwgAirjY+fpAdurfut67R3EDohXz6VT+un8D1MKzJPbdLa+XicI2BXljAbx7 tR1AWIiOt/YBuMqq7AV2QTL/poJzLJVqUNPLGF1iiIUViyZWPvVcHslD0ztyYHPn h/1oHbyvpzqKmQ8/Votep2dAtUUZnvvProASWq/8n3vOfzjoEySv8YKpXpXF9Cdn 8Kj3hs/XLKLdO0/iywsExVeQ2SPcXIDthGmtlsq4o8hjdnV4Nx76++S9GSRgmcJo usXOD4KvOCdPb/5HXbPZkddAJIjEvxC0GFQDOyoIDqD0TrRPar6dtPoD1ug78rs3 WdktNBkEIaV+qr+ivMXXrJy2+V/DHw== =D3VG -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 27 13:10:51 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899361200FF; Tue, 27 Aug 2019 13:10:49 -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 UGA47kUMEuOt; Tue, 27 Aug 2019 13:10:48 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8BA1200DE; Tue, 27 Aug 2019 13:10:48 -0700 (PDT) Received: from h-202-242.a357.priv.bahnhof.se ([158.174.202.242]:53639 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 1i2hnj-0008Cq-8D; Tue, 27 Aug 2019 13:10:47 -0700 To: Michael Richardson References: <31591.1566930552@localhost> <16112.1566934510@localhost> Cc: tools-discuss@ietf.org, cellar@ietf.org From: Henrik Levkowetz Message-ID: <73ea49ee-c173-33f5-6fa1-031f1599434a@levkowetz.com> Date: Tue, 27 Aug 2019 22:10:39 +0200 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: <16112.1566934510@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xAw9eGSGTUvPpX7r6Ko9LI1mfWo3rS6Q2" X-SA-Exim-Connect-IP: 158.174.202.242 X-SA-Exim-Rcpt-To: cellar@ietf.org, tools-discuss@ietf.org, mcr+ietf@sandelman.ca 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: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 20:10:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xAw9eGSGTUvPpX7r6Ko9LI1mfWo3rS6Q2 Content-Type: multipart/mixed; boundary="1W5HSGlVd3HILxXX64BcQLsBMa6vmw4j0"; protected-headers="v1" From: Henrik Levkowetz To: Michael Richardson Cc: tools-discuss@ietf.org, cellar@ietf.org Message-ID: <73ea49ee-c173-33f5-6fa1-031f1599434a@levkowetz.com> Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters References: <31591.1566930552@localhost> <16112.1566934510@localhost> In-Reply-To: <16112.1566934510@localhost> --1W5HSGlVd3HILxXX64BcQLsBMa6vmw4j0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Michael, On 2019-08-27 21:35, Michael Richardson wrote: >=20 > Henrik Levkowetz wrote: > > Hi Michael, >=20 > > Here's my take on this: >=20 > > A number of people has highlighted the desirability of using math= > > symbols in text. However, this is not currently supported by xml= 2rfc > > v3, and will make idnits unhappy. Putting math in SVG is current= ly the > > supported approach. >=20 > Yes, and we are using SVG. But we can't do it with XML yet (now Sept. 1= 6). That's when the RFC-Editor intends to start publishing xml, I believe? But you should already be able to post drafts using v3 XML -- any reason = not to do so? (It doesn't affect your primary question, but I'm curious.) > So we format a txt version for submission to post to the datatracker, > and it has some UTF-8 in it. >=20 > Are you agreeing that idnits is in error? For publication purposes, the final arbiter isn't idnits, and the idnits message for non-ascii characters has been downgraded from error to warnin= g, since it's not sufficiently sophisticated to clearly tell what's acceptab= le and what's not, based on RFC 7997. I think it's right to emit a warning,= in order to have both authors, shepherd and ADs consider the case, but can't make any further judgement. Henrik --1W5HSGlVd3HILxXX64BcQLsBMa6vmw4j0-- --xAw9eGSGTUvPpX7r6Ko9LI1mfWo3rS6Q2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAl1ljj8ACgkQTptXS4+7 FxrTKw/9HQUJOfsx0mrTbRwebcnW4795d0leVmpVQYIpYn6sobEaWgENPrWcxM7Q t09E/adY2YZceospbAMgeVJsKjJDHRQKY3lYOj+GyOgcgyHCUeq2l5dHqzRIHjUW cK8BUJuYrBhweSdKGCVHnwlZmWFJqxAj42/Ic8iHhlMAYNjDDQgONgNsOU9PfS+J wscN0OKHFNCZcwfG6Wx7mAlyZyL33gNHYwCPFXHqaUMLfnJuWrTde20ssTLaA0AM rweymiuMPSDOEVHG2jR+iSbQfkbOOGQz2zsjzw65kUxe+KPq/PDju8bkFjK2/jKI 35UkH3CEmc8RJcN7CmLqWR7aZRxzFk/zURackAm+lfLPH93Qs8Tw4753b2IdvEDy VuqZCFK8z5w2F2EljRQ1kPM/Ix21DG6KFCG+6YoHFkUC3bLkfS27sliJcgCR38pF 2Zi1oqGIqlOSL/Xv91lqv7/HRehMezrUe+FKTKEz2KjuvioM1SXLjdf4FoEiDeb4 oub9xzcpChNW/77kX5ckV+nr0o3Si3g4dCx1eX0nqhXCNTCWm4af9Apeelgxv9sH x+SmzbqbFEvNaeENuhQryRyqsnozbNy0vOPFKV0IReEcAwsG6g5u54EVhnPrDDOL e2Ueff5Zv1XXnaLVmE4asHNnY2W81E6HXs47fvdyrZd6zvYUJXE= =wtUG -----END PGP SIGNATURE----- --xAw9eGSGTUvPpX7r6Ko9LI1mfWo3rS6Q2-- From nobody Tue Aug 27 14:06:21 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCA812012E; Tue, 27 Aug 2019 14:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bangj.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 LOAUAp0UhCmy; Tue, 27 Aug 2019 14:06:12 -0700 (PDT) Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32653120113; Tue, 27 Aug 2019 14:06:12 -0700 (PDT) Received: from [172.16.25.146] (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id EB9DF335F6; Tue, 27 Aug 2019 17:06:10 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1566939971; bh=SN2Y9gN+uYs7w4tytRE3qb3cTinrLsJI7l/5PgaXep4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=kLRzMT1DTOhSKMvEPEeWWTeAOzgie0zUBvN7q306YI7rfPYq4s0pwadmhvkOq5qAB jxurOsxrDMDh4Surdmr7r2J3WrOficLHWv73JmkKi50xPsvn0AnzhAiGEidXRO0Zp9 QjcfEDaJxl/1VaC6J17EbzSj3+r4CrYds/fw0WyNa1QZ+66ryEtgY0rCbM9O7NH5g3 B+eWX0jc8lgRhOnFU6QMBz6JF4sndaglKjKTbY/HeIX+0I+ESUf48S+r7vQMg4HMVd DpTELK0TijbXVMarkUkHbcGsjHJkGzoxZ2MoW24IQgFB+VlcaKoqV7LoHxiJBzR6L2 cyp3YF8FekWpg== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3578.1\)) From: Tom Pusateri In-Reply-To: <16112.1566934510@localhost> Date: Tue, 27 Aug 2019 17:06:10 -0400 Cc: Henrik Levkowetz , cellar@ietf.org, tools-discuss Content-Transfer-Encoding: quoted-printable Message-Id: <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> References: <31591.1566930552@localhost> <16112.1566934510@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3578.1) Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 21:06:14 -0000 > On Aug 27, 2019, at 3:35 PM, Michael Richardson = wrote: >=20 >=20 > Henrik Levkowetz wrote: >> Hi Michael, >=20 >> Here's my take on this: >=20 >> A number of people has highlighted the desirability of using math >> symbols in text. However, this is not currently supported by xml2rfc >> v3, and will make idnits unhappy. Putting math in SVG is currently = the >> supported approach. >=20 > Yes, and we are using SVG. But we can't do it with XML yet (now Sept. = 16). > So we format a txt version for submission to post to the datatracker, > and it has some UTF-8 in it. RFC 7997 is pretty clear when UTF-8 is permissible and math symbols are = not in the list. I also wanted to use math symbols recently and the TXT version and the = HTML version looked fine but the PDF version did not and so during IESG = review, I was asked to revert the math symbols to their ASCII = equivalent. I think you=E2=80=99ll probably run into the same problem if you try to = use them at this point other than for the particular use cases in RFC = 7997 (names and titles). Tom From nobody Thu Aug 29 18:12:21 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A23120CAB for ; Thu, 29 Aug 2019 18:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyycWNTpxzXr for ; Thu, 29 Aug 2019 18:12:03 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F2EE120C9A for ; Thu, 29 Aug 2019 18:12:03 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-07v.sys.comcast.net with ESMTP id 3UdZiWKNlvpGJ3VSMiJlWt; Fri, 30 Aug 2019 01:12:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1567127522; bh=SLK4lxSy6Nv3nKEge7UIHrZ1vncQGeCE1kUbXnPu0oQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Ytv8r38su2NphL7eTT2D30CeG7Su19cr4Ng1Wt/XhkWtrIKVJwG0CjutrDtCGek15 dEVNz5hZi7hXaYvPqSY+iO+HPu3veC3UXgkOH4DYpPrtkXpZ+NiwGm3PxErDNEhao4 QUD8a9SXoFjus1CjQvKbh2vrYsSD8SGqhY/f3qkUDQJPtm/Be43bDWL+CPzMoKegUb EYptyHInunnfqaKw2oFFxu0v1ZhtgFWr7m9LXTXMoN9vga2GMSCVuCa5qhk61fgFW7 feKq5D5Y0pRrmhxyhUqF4UXdt0Boa7tHDVCHd5pwtHzWKvY/5iB726pv10SyCXEgNO MZhIag+46ylOg== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with ESMTPA id 3VSKiQyToaxmK3VSLipe9B; Fri, 30 Aug 2019 01:12:02 +0000 X-Xfinity-VMeta: sc=0;st=legit Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id x7U1C010013778; Thu, 29 Aug 2019 21:12:00 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id x7U1BxGJ013775; Thu, 29 Aug 2019 21:11:59 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Michael Richardson Cc: tools-discuss@ietf.org, cellar@ietf.org In-Reply-To: <31591.1566930552@localhost> (mcr+ietf@sandelman.ca) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 29 Aug 2019 21:11:58 -0400 Message-ID: <87lfvbwj6p.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 01:12:12 -0000 Michael Richardson writes: > [...] One instance is using a Unicode minus sign to be more > semantically clear than an ascii hyphen. [...] Given that using non-ASCII characters is still considered doubtful, and given that using hyphen to mean "minus" is a long-established tradition, I would say to use hyphen. The place where I'd expect the Editor to show flexiblity is where ASCII makes it difficult to express the intended meaning. Do you have such a situation? Dale From nobody Thu Aug 29 21:20:55 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 614AF120C72; Thu, 29 Aug 2019 21:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmcoRPSzgNln; Thu, 29 Aug 2019 21:20:41 -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 DFCE5120918; Thu, 29 Aug 2019 21:20:40 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (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 46KR9M056pzyg9; Fri, 30 Aug 2019 06:20:38 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> Date: Fri, 30 Aug 2019 06:20:38 +0200 Cc: Michael Richardson , cellar@ietf.org, Henrik Levkowetz , tools-discuss X-Mao-Original-Outgoing-Id: 588831636.9663661-93b1197d63ce95ced93ac18c8f328286 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> To: Tom Pusateri X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 04:20:43 -0000 On Aug 27, 2019, at 23:06, Tom Pusateri = wrote: >=20 > RFC 7997 is pretty clear when UTF-8 is permissible and math symbols = are not in the list. I believe, with a 2019 perspective on the world, this is no longer the = right decision. We are incurring the costs of supporting Unicode but not reaping its = benefits. Providing HTML as a main viewing format and not even being able to solve = the hyphen-dash-minus problem leads to weird-looking documents. How is requiring SVG display support for understanding a document better = than simply requiring Unicode support? Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 29 21:26:29 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29EB120C82; Thu, 29 Aug 2019 21:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LW1xSn52mFMI; Thu, 29 Aug 2019 21:26:27 -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 9D48E120C80; Thu, 29 Aug 2019 21:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567139146; bh=ePC1tQxJLy0np2H030Q8GXx3cX1Z4zyESmsilzaVIlM=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=IiviP+AGJnaIfha32axMCy4Ux2sKzb3jHCAyQomRLQd+OLRMtdXpPz0lhjr3LHNUK riHg4FW9H99GVJzAAJ0+fSyc+gMEwCuwQGmAjbRFs2m+aE2Jf2BYd6hWQ2oVF1mP4b z6rtV0Vb0EzI7G/3NDoRYLRBl16YROkvVPkqDWns= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.109]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrevR-1iBQjH2Mhx-013Q37; Fri, 30 Aug 2019 06:25:46 +0200 To: Carsten Bormann , Tom Pusateri Cc: Michael Richardson , cellar@ietf.org, Henrik Levkowetz , tools-discuss References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> From: Julian Reschke Message-ID: <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> Date: Fri, 30 Aug 2019 06:25:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.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:sKTaCFzCCrWgPZk37VIIEko3BLTZsWq6qpQCVLxFEesTQk8p0mq dxkP0wOT9rW+8krglzs76Yr2rYOlZm1Jn8JIJaYzeg+npckSmSuk9K0bZKc8qontKutnL98 OgfbWvcNToZZ/5sBn7NI8Qs6UvJpPv61HfPRJownfr3VKVfUHFkbiL7ny+Gt2/T5DTf0XFY UkanKkiTv2XlUsucnxiGw== X-UI-Out-Filterresults: notjunk:1;V03:K0:8q5UJaya82Q=:n/z6va1PzH6Z0Bwt/3JGLD b/i49DdLviRQJPiX4uixy1fOmxrbWtZrn1tZxoK3zu+8E1nGFrRgOGWJkkWpyK0ngyLt2oF8M JVPdTxXxXuitHjACF09dJOgquJBGhIa6B6XWxtioPKv3w6aGUfFg5F/IWKioNQPE/wa40z3X1 QgrtkGtTqg0iLSEKwdcwNHy6iy2Z1Faag3VdW+HV79egjl3dh3S7bKmwgd7+9m4L4/PZtfwUc 8U//qgZnZx+yarfzuDtBMUHYsk7PWyxOC93JhxfJyuS7JPl+SeLDrlmBWzaULgPpLe2+cgDXd HIMuXhnvPkVKg9MOUcjwNDNVDrdHPamqIPJ3twKuwc2VFQgI+NLjmIpMOXQdgO3/PfqPaNP9X iAYFTV7CBm9H/aQJhT6aV4ccb5h7mhF2kioBzn9FWRMmbmRxWUuNsl7XEdbDnmCsIiN7PQGKA bnxpkBmjDuXy5qf2ctZ8NmjTxsHncODIsyi0c+Kfsvm7HUyeSdQ1Wh3Q8Nknx//zVd71kIwYT W2FLnu3KmYOm30omLWsyL/g81rZ7ECHP+eillbeSIZcxetjNGbPBPVTaXmzMCnJR2RfWhywZ5 rlcOTovoq0vw9vy6sGKvn9DVT/JK1UnyETmlzuVgg41vw4xdivcmYzLi8hS5bqYQSqfodh32R sM0aqnL5LjV8aw10vAP53aOZDSoGaUKIB4DVBZ7tvA7JYD9iBaIkT+7mDXMsRiteVvViky/+j J7yxfOtx9LbFAIx1fc2Nzp+hJQVlXbUIeitnnt5MzP2f8agoXKOKH2XiDf2IxZpuKduDyHTWC dzIATgTv+6hpJwL8+vqn3e+cS4hNv5aftmtv1IpOgxBXeL5tQuZkD/U5M3CRIe7Wbj+38YaO1 RiCFHeKIBMjYEHk83BSe5UbrTK2AK2RdQ8tJL3KAI20HU86ziMz9+36teTMv358JbthYuoUcW kxvoEBVYdpF8cDTCsiV5Even9QxWOWQKiimka8lpvtiUIo+bFmPrpkfZsIPJoeFFxhdo8B5cI CpYNu7VP8aaw81lDMm0B+vhlWdw3j63pfxFqmWcsW07jVLrn/q8Imv2IjvkBHHhxbVwmExQYG iQLGhrUWiNvz9zgMmNoIWdXGOjQFwUuzPjWBpOxQN4T93Z6Weq0eKFJz2GhS1kAixANqDJ0+b +eeun/G83nvfsNp9yGCGe+uouxW5xPhL++FL4NETiOMbybtQ== Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 04:26:28 -0000 On 30.08.2019 06:20, Carsten Bormann wrote: > On Aug 27, 2019, at 23:06, Tom Pusateri wrote: >> >> RFC 7997 is pretty clear when UTF-8 is permissible and math symbols are= not in the list. > > I believe, with a 2019 perspective on the world, this is no longer the r= ight decision. Did the perspective change significantly within the last 4 years?? > We are incurring the costs of supporting Unicode but not reaping its ben= efits. > Providing HTML as a main viewing format and not even being able to solve= the hyphen-dash-minus problem leads to weird-looking documents. > How is requiring SVG display support for understanding a document better= than simply requiring Unicode support? I do prefer proper hyphens, but I also note that the proper choice can lead to bikeshedding. My recollection is that we started with the use cases that seemed most important back then. I'll also note that Unicode math characters won't be sufficient in all cases, so MathML definitively is something to consider as well. Best regards, Julian From nobody Thu Aug 29 22:16:32 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EC8120C74; Thu, 29 Aug 2019 22:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7cyhdmpHH6Dy; Thu, 29 Aug 2019 22:16:28 -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 16B251200E3; Thu, 29 Aug 2019 22:16:28 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (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 46KSPk3PYQzyXX; Fri, 30 Aug 2019 07:16:26 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> Date: Fri, 30 Aug 2019 07:16:26 +0200 Cc: Tom Pusateri , Michael Richardson , cellar@ietf.org, Henrik Levkowetz , tools-discuss X-Mao-Original-Outgoing-Id: 588834984.486306-b40a1ec80b57b06e89369b0c57b34ef5 Content-Transfer-Encoding: quoted-printable Message-Id: <76BBD514-2BB6-4291-B80F-4C72B17E43B4@tzi.org> References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 05:16:30 -0000 On Aug 30, 2019, at 06:25, Julian Reschke wrote: >=20 > On 30.08.2019 06:20, Carsten Bormann wrote: >> On Aug 27, 2019, at 23:06, Tom Pusateri = wrote: >>>=20 >>> RFC 7997 is pretty clear when UTF-8 is permissible and math symbols = are not in the list. >>=20 >> I believe, with a 2019 perspective on the world, this is no longer = the right decision. >=20 > Did the perspective change significantly within the last 4 years?? I think so. Of course, tipping points are always a perception issue, = but I think it would not be hard to obtain consensus today that we are = past the UTF-8 tipping point. Of course, there will be people who = remember that they argued otherwise a decade ago and will try to = maintain that position, but outside of vintage computer museums, the = reality is pretty well-defined now. >> We are incurring the costs of supporting Unicode but not reaping its = benefits. >> Providing HTML as a main viewing format and not even being able to = solve the hyphen-dash-minus problem leads to weird-looking documents. >> How is requiring SVG display support for understanding a document = better than simply requiring Unicode support? >=20 > I do prefer proper hyphens, but I also note that the proper choice can > lead to bikeshedding. I=E2=80=99m not aware of an opportunity for that (well, maybe except for = the choice between en-dashes and em-dashes for the punctuation mark in = the form of a horizontal line used to indicate a pause, to delimit an = inserted sentence or phrase, or to indicate a deliberately omitted = word). But given that this is the IETF, I=E2=80=99m sure we=E2=80=99ll = find one :-) More seriously, this is one place where copy-editing can simply solve = the problem. > My recollection is that we started with the use cases that seemed most > important back then. I'll also note that Unicode math characters won't > be sufficient in all cases, so MathML definitively is something to > consider as well. Having math characters available is not a valid replacement for = something like MathML. Being able to throw in some casual in-line math (that an authoring tool = would convert to the right characters) is useful, though. As in =E2=8C=88= a=E2=8C=89 and friends=E2=80=A6 (Nobody would argue that I can=E2=80=99t = use a*b in a spec to talk about the product of a and b, so why not a=E2=88= =89B or =E2=88=80x.x=C2=B2=E2=89=A50.) Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 30 00:39:59 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC512006A; Fri, 30 Aug 2019 00:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 x_xSt_vxXhg8; Fri, 30 Aug 2019 00:39:56 -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 F15DE120806; Fri, 30 Aug 2019 00:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567150764; bh=Lv1Cn2Y142b+azlJy2VPlTg+63TqSpJiHVpJeAAkO1M=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=GQxPcBUZaAE94Or3/X08xcWPRlLvz9RPPdV1Btbhu0lK4XWMmtctVOv17chtS35V8 9vdkqUU3zAirdkun7iTglJoldJYwZa98Si9xIrDi4/P+cR0FS3FrFT/5khF8d4HvkE qDrowC1VDoGQtpyy5+nEfIwn6qjToz2gksBhUY78= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.109]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MbaS9-1hnJhm3CoH-00J5vu; Fri, 30 Aug 2019 09:39:23 +0200 To: Carsten Bormann Cc: Michael Richardson , Tom Pusateri , cellar@ietf.org, Henrik Levkowetz , tools-discuss References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> <76BBD514-2BB6-4291-B80F-4C72B17E43B4@tzi.org> From: Julian Reschke Message-ID: <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> Date: Fri, 30 Aug 2019 09:39:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <76BBD514-2BB6-4291-B80F-4C72B17E43B4@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:12aLs5TFUCRjyx2+z8Ysp8E1P8dvQG91gYgm3aQat5qO+tXVtA7 gMZ0vp+RY2w/CS58eHfHUJhhxUx+k7G5fCTaYyfIVZ64WTY0zHhJ4cfcBwhlBc0kZwp/h0R SIHIAFv6ghBo3JcwC5egckeGieRNnnFOwyQ3xIQfFibBx2BDahqnqCBwSWDuMVU512nwuVo xa6DObFlr5oCPlzBrLrNA== X-UI-Out-Filterresults: notjunk:1;V03:K0:zaFyTwdOt/Y=:SnwuPSd061yN2ehUGRCjmz PcFDCLd+UmkBlC/mex1ro8Fto5T+s+2hK9ahxcqdQMaftLxJ4/XuFpMJ/1Lik5+ledjHzHJDN O0jmK3MDjqI0J+Q1TKCcdKTqI5/m180EUmTn9H0Um8hrY4yREZK8G2uKN22QU7dJ+zzCfH3mA WpAd4C4cBeG7WAmdfk92TQNuLHnbwelZkQQjTM7gMBhKWHkdwBUT5b5IXpH7SHEl6Q/tTCCCD F1gYZwaF0E4c+CgwHdOb8PfKTxwhd9LCDn5/a90LZAy5T7l3t0oxOPhEmi+xTG93Q88j/69wf TTDJ5KRTC4vIumitTnx4VdOTkbI5ezXLlAx+U6wK0NZmmUucgAxSvr9VBK0Qrab62LyPsnaRj qedfE7IvtFxaXqh6JF7QiJHYS3s3pRiTVLWs/I5H9+9qmLoixFU2Zia91/WwQ9EgwfkO/VHIB anHvIlYd53wwdzZrCOKkxxSwU1pap4cHaosnv1NLPnM+Q/Wj25F2DK/JgBnzFGQxng1DSOPKi hGmOl8I//Red938cNogPDSjEm1OhmtjYQVn0yIE3lwHXrpzmYZfOPA/lcBK6FFKzoDaKjx5Vp N6rQcTOShzSKSkeEolFNNnstQwt6v6VB9r28/BCNWPVs6jtWDC0EhJp4xYGrIxELaQesSTcL4 3N5i8W3HSoyZ+9W4TFUU3pFc4OCNeY9bJaBtAMu/FgodSa/rh5q+6VyFAFTH0bZe8CUtDPHry /VJ4ma6bz8JvP1y6aA++Jh1cteeAyEx1CdpDr5atcx+C97saCSioOaDib124IPRLjvGm7iGFy NaHf7mliLupUK0OYq/e8a4hq5d+l3de+k56CLWqmU0N9uZNftBqSL669vRb859XIEh3+fDmJo BlYSZ/+gAvbXLZKtdUsuPHSJgSFK6jkj4nTSbBxmIB1sPfH4mGVjr5z7HCk/iVF4qKmreHlIM jsNNlzH+omV244+nfSVSslf9wtr9paA3iB9ilBW4P3UVhrukO1Eqhw8hisksX6+srtUcgrG3A YD4+vsqQRCQOUqSMrzdUVF2EereCmOf+m3ugINgjZXcCyAm6JzTbwACE4vSJn/MOTwb43Vtlm NFYkT+5MrAlFJO0aM4fpHbuw9j2QBhFJJhTNVvEruk+F60BrTWEWez+T3sH0ZcFob4fl2h4Xj ezZTJoYjKFfeG2TdK7CG85/wZEXupkjKuVT7A+OJkJuWEPnw== Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:39:57 -0000 On 30.08.2019 07:16, Carsten Bormann wrote: > ... > I=E2=80=99m not aware of an opportunity for that (well, maybe except for= the choice between en-dashes and em-dashes for the punctuation mark in th= e form of a horizontal line used to indicate a pause, to delimit an insert= ed sentence or phrase, or to indicate a deliberately omitted word). But= given that this is the IETF, I=E2=80=99m sure we=E2=80=99ll find one :-) AFAIR, there are also different opinions about whether there should be whitespace around it. > More seriously, this is one place where copy-editing can simply solve th= e problem. That is true. >> My recollection is that we started with the use cases that seemed most >> important back then. I'll also note that Unicode math characters won't >> be sufficient in all cases, so MathML definitively is something to >> consider as well. > > Having math characters available is not a valid replacement for somethin= g like MathML. > Being able to throw in some casual in-line math (that an authoring tool = would convert to the right characters) is useful, though. As in =E2=8C=88= a=E2=8C=89 and friends=E2=80=A6 (Nobody would argue that I can=E2=80=99t = use a*b in a spec to talk about the product of a and b, so why not a=E2=88= =89B or =E2=88=80x.x=C2=B2=E2=89=A50.) > > Gr=C3=BC=C3=9Fe, Carsten Ack. Just explaining how we got there. Best regards, Julian From nobody Fri Aug 30 01:00:16 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12D6120113; Fri, 30 Aug 2019 01:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jpq7WfqmzGSq; Fri, 30 Aug 2019 01:00: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 1CA0712001A; Fri, 30 Aug 2019 01:00:11 -0700 (PDT) Received: from [192.168.217.110] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (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 46KX2d3Gg8zywt; Fri, 30 Aug 2019 10:00:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> Date: Fri, 30 Aug 2019 10:00:09 +0200 Cc: Michael Richardson , Tom Pusateri , cellar@ietf.org, Henrik Levkowetz , tools-discuss X-Mao-Original-Outgoing-Id: 588844807.490808-5087a3644267b470c833424d0152cb06 Content-Transfer-Encoding: quoted-printable Message-Id: <6FF73116-59F3-453E-B001-171AF369A7E9@tzi.org> References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> <76BBD514-2BB6-4291-B80F-4C72B17E43B4@tzi.org> <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 08:00:14 -0000 On Aug 30, 2019, at 09:39, Julian Reschke wrote: >=20 >> I=E2=80=99m not aware of an opportunity for that (well, maybe except = for the choice between en-dashes and em-dashes for the punctuation mark = in the form of a horizontal line used to indicate a pause, to delimit an = inserted sentence or phrase, or to indicate a deliberately omitted = word). But given that this is the IETF, I=E2=80=99m sure we=E2=80=99ll = find one :-) >=20 > AFAIR, there are also different opinions about whether there should be > whitespace around it. Right. Traditional German: em-dash with whitespace =E2=80=9CModern=E2=80=9D German: en-dash with whitespace Traditional US English: em-dash without whitespace, or sometimes with = (AP style, i.e., news) Traditional UK English: it=E2=80=99s complicated Today=E2=80=99s English: hodgepodge Laypeople: essentially, use dashes only where Microsoft Word turns a = hyphen into a dash automatically, and that involves typing spaces, or so (And, of course, there are range and versus dashes as well, which are = always en-dashes, but might incomprehensibly have whitespace in = English.) I don=E2=80=99t have my CMOS with me, or I would cite chapter and verse. But the important observation is that this is a well-known editorial = style issue to which a copy-editor should have an answer. More generally speaking, the fact that Unicode has more characters does = not mean we need to spend a lot of time deciding which character to use. = I think we are also old enough to no longer fall into Unicode traps = (e.g., =CE=A9 vs. =E2=84=A6). Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Aug 30 09:33:55 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6212097F; Fri, 30 Aug 2019 09:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nmFsLWit5R-j; Fri, 30 Aug 2019 09:33:47 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCFE120B43; Fri, 30 Aug 2019 09:33:45 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D44B53808A; Fri, 30 Aug 2019 12:32:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 22388B1C; Fri, 30 Aug 2019 12:33:45 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org, tools-discuss In-Reply-To: <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> <76BBD514-2BB6-4291-B80F-4C72B17E43B4@tzi.org> <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 16:33:49 -0000 --=-=-= Content-Type: text/plain If we accept the rules of RFC7997 (nice palindrone) suggests UTF-8 for proper names only, is it acceptable to use other symbols in the XML for use when translating to to HTML? And if so, is there a way to tell xml2rfc (v3) what to put when producing the ASCII^Wtxt copy? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1pT+gACgkQgItw+93Q 3WWqTgf/SH67O+V3qHh2Q3vrAqsG82mKR0t1uaskn42G8XNTFr3qg5Qz3vAVdQXj HkTh7A90Bg3cRLYL/joTxrN6+y8JTKbIlTbcNKE6TJ0+kGgsSXlsd8+PZywp8dtg 3IPeHjSCCFZohAwgbHvLPPbqTRvtbETkR+/97LjEkO0W+YEzkkL0P5Et7k6wiOd4 Y0XXstTvOkGs+797pHLJttEyusfaE7wvAdhPG1Tzo7wbD611PsiDTraKer4mRMaQ MGGYGNEa9tlXQfyhuQYu63qLO+SMiDmHZRV+1pxZEoBPDmM4+SkaOT/B0mCKaXd1 aEnHkFvzIGDcb49Z/pEkdMqB4cD92Q== =hyQw -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 30 09:44:43 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E312093E; Fri, 30 Aug 2019 09:44:40 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 bXVmmxWHHyOF; Fri, 30 Aug 2019 09:44:39 -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 9611D1200F6; Fri, 30 Aug 2019 09:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1567183469; bh=28qbWEXZjWRAQlUngj6VDxEoJ9yLClZMvwsFzQk4Z9o=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=KevcXxW0DBMEM0eWroL3MfZvRrRt3fasCUwUuqSMEG7d9kA0VszEA4xZzVuWbFgRh ShLkXQd0rMBoZmoX3YRhjva+LxuaOwVqoJxIZjPDVWcDcMhgAUtqeTPt6Aep3t6uQS tUJkMxJjQEZMoSQtmDNppDcLiQ3eYtuNDenQgSZE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.124] ([84.171.150.109]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MJmGZ-1hjbl61KnZ-00KB8m; Fri, 30 Aug 2019 18:44:29 +0200 To: Michael Richardson , cellar@ietf.org, tools-discuss References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> <76BBD514-2BB6-4291-B80F-4C72B17E43B4@tzi.org> <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> <6317.1567182825@localhost> From: Julian Reschke Message-ID: Date: Fri, 30 Aug 2019 18:44:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6317.1567182825@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:P/qgSX7uwMd1ym8rTx503nJz/OdTMs8+U811GbeUiItdLJ7snnb ujtI77kb+xjSusqwETHShLAYJko22mGK62WJtfLLQFfqbJBgYdEu7WlPPuaU0rRzW8joue/ J2MKfZ9nDOToXETQe7/BDEGixbk5XVleZHuhFjLBn2eoGXzK8FomhdFg9q6rVTY2FIuRRQB vneQFTfXpZvMPV/qgDVmw== X-UI-Out-Filterresults: notjunk:1;V03:K0:zT6fqbbC4Z4=:81XLDZ2KZCX6emIKMYghqP 6Mig7J/uLR2rWKHWR5eChfWivUGkku/Vb8oFKc4ej/BqHTfNhk6d1YikGpvjzBiA5HY/UCr4U f/GES0dKui0rq7fUh53CBcH8gRXGlj0cGbL2JWwX3dAXXdrpNCXxfz4EXsogzvfUPtJTCL900 OT7gx9cBI/LiwDyq4aeAOeHOAdOnLtPBLVrkO/9CIgxo83zzj4EyzPeOemy/82KwaNeoPQ5nY Ikx0YCymhIUEu47CYhFTyPQ7DUBXF4GSI1lQeWQWuC3hpvxoQEDbNT1DphRF+sMw19+MZKK/w twkWaarymMJtprCVx7r9CTO+wXywUI3VPcb7umCiA3yrDFwQbiE9fs5SsZJc7RZF0Q8qxBdnD SWiSWhilNiUs8cpiu69yFLmVLQd02rFRhBAV1Qk9wqgX037r+F6Kj1fNkmLz9vdhBoRYATGmB irpPQJStLGEL9GaSJsXVvdB3M+gqwgJHtLwkPwu/rjXl6BcZqoJzEpNPoYP6qwSo/DrCUIWsd 8gJaTIRpCYUSH0dpMMZyKP7umGpryWVqpvpvBUDUDuEPFfJheYyw9XzssWDmItjM6tmCSXXTK po+oduxIXvitdW6igy0ZtdCT0VaAZWBQdNu6WA44Ew+TkDXziUSMSiRGynWXZFqJjayySE/tp 7XQmE2SGZRwD2Ot09rpw/wQD+GYmAkoWYXyxasSmoXgts6kTQyna9FBKJBxrmRSBWM2GNABPf 50itaULzBJnuP7gO0JdfhZpH6a90Qn4QJP1oB31TNvjAqEAnZfvZq8twi+0W2Pb6xXCTFD6vH podb+sciGmc5HTe7LDS7BNeIy1me6KkVbSRf0n2WTGhc9R9ErcJ9lLRehMvfwwHVXu/b+Iwoy /1FGs0xJ+/aQqen126uUvdCraFKHL5O9mmWfCQLsQlu6t3UtSCyqC/uTYuCq8DcWA5yxdXHLs 0A7la8FKKZS2+i2HL5xPwDpL3WGwr5mbFSPn6yBG/ZnjtXQJ6fDzF4JLP/T5JJxy/Z/tJ3YTT bPq5nnJeNd3lyaCrO6RwGXbq4cQZmmIjiwId9NuMCUESnCezNG9Fg5nUNtxjK6m6t29rA7vTV BclAYxanI6zJQMPjOO1F+ka7F/r9+oNFc3dFHIu8rpn4r694vgEIY6kZjvI4ZY4D6W7MP4xJI Y2hie93pI1j5oouGa/Kn6mZNzVnf+Vu2VNAiIMkvPVMAD5qQ== Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 16:44:41 -0000 On 30.08.2019 18:33, Michael Richardson wrote: > > If we accept the rules of RFC7997 (nice palindrone) suggests UTF-8 for p= roper > names only, is it acceptable to use other symbols in the XML for use wh= en > translating to to HTML? I don't quite understand. Example maybe? > And if so, is there a way to tell xml2rfc (v3) what to put when producin= g the ASCII^Wtxt > copy? You mean plain text? That can contain non-ASCII just fine... Best regards, Julian From nobody Sat Aug 31 16:02:29 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B916512013A; Sat, 31 Aug 2019 16:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] 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 KXSNi6RH0bAK; Sat, 31 Aug 2019 16:02:18 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 0CDD61200FB; Sat, 31 Aug 2019 16:02:17 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:39645 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i4CNm-002sAI-RY; Sat, 31 Aug 2019 19:02:15 -0400 From: Dave Rice Message-Id: <1671C432-1E43-41C4-99FC-B927887BBE12@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7E2F97F0-FC05-4443-9685-862EB0B80BB8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 31 Aug 2019 19:02:08 -0400 In-Reply-To: <6FF73116-59F3-453E-B001-171AF369A7E9@tzi.org> Cc: Julian Reschke , Michael Richardson , Tom Pusateri , cellar@ietf.org, Henrik Levkowetz , tools-discuss To: Carsten Bormann References: <31591.1566930552@localhost> <16112.1566934510@localhost> <5E85BF29-021D-4235-BD68-893F5729D5E6@bangj.com> <4fa5f1ff-71f8-5303-e285-0e1f10e458c2@gmx.de> <76BBD514-2BB6-4291-B80F-4C72B17E43B4@tzi.org> <0ce8e099-0344-dacc-06b2-898fb63c75e5@gmx.de> <6FF73116-59F3-453E-B001-171AF369A7E9@tzi.org> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [Tools-discuss] non-ascii characters (fwd) Dave Rice: non-ascii characters X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Aug 2019 23:02:20 -0000 --Apple-Mail=_7E2F97F0-FC05-4443-9685-862EB0B80BB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On Aug 30, 2019, at 4:00 AM, Carsten Bormann wrote: >=20 > On Aug 30, 2019, at 09:39, Julian Reschke = wrote: >>=20 >>> I=E2=80=99m not aware of an opportunity for that (well, maybe except = for the choice between en-dashes and em-dashes for the punctuation mark = in the form of a horizontal line used to indicate a pause, to delimit an = inserted sentence or phrase, or to indicate a deliberately omitted = word). But given that this is the IETF, I=E2=80=99m sure we=E2=80=99ll = find one :-) >>=20 >> AFAIR, there are also different opinions about whether there should = be >> whitespace around it. >=20 > Right. >=20 > Traditional German: em-dash with whitespace > =E2=80=9CModern=E2=80=9D German: en-dash with whitespace > Traditional US English: em-dash without whitespace, or sometimes with = (AP style, i.e., news) > Traditional UK English: it=E2=80=99s complicated > Today=E2=80=99s English: hodgepodge > Laypeople: essentially, use dashes only where Microsoft Word turns a = hyphen into a dash automatically, and that involves typing spaces, or so >=20 > (And, of course, there are range and versus dashes as well, which are = always en-dashes, but might incomprehensibly have whitespace in = English.) >=20 > I don=E2=80=99t have my CMOS with me, or I would cite chapter and = verse. > But the important observation is that this is a well-known editorial = style issue to which a copy-editor should have an answer. >=20 > More generally speaking, the fact that Unicode has more characters = does not mean we need to spend a lot of time deciding which character to = use. I think we are also old enough to no longer fall into Unicode = traps (e.g., =CE=A9 vs. =E2=84=A6). Thanks very much for this discussion, based on this and also running = idnits, I=E2=80=99ve created this pull request for the FFV1 draft, = https://github.com/FFmpeg/FFV1/pull/158/files = . Related to this = discussion the pull request changes the unicode minus sign to an ascii = hyphen and uses a "ceil(a)" and "floor(a)" function rather than using = "=E2=8C=88a=E2=8C=89" and "=E2=8C=8Aa=E2=8C=8B=E2=80=9D. After this PR, = it passes idnits with no errors, warnings, or comments. Thanks much, Dave Rice --Apple-Mail=_7E2F97F0-FC05-4443-9685-862EB0B80BB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = all,

On Aug 30, 2019, at 4:00 AM, Carsten Bormann = <cabo@tzi.org> = wrote:

On Aug 30, 2019, at 09:39, Julian Reschke <julian.reschke@gmx.de> wrote:

I=E2=80=99m not aware of an opportunity for that (well, maybe = except for the choice between en-dashes and em-dashes for the = punctuation mark in the form of a horizontal line used to indicate a = pause, to delimit an inserted sentence or phrase, or to indicate a = deliberately omitted word).    But given that this is the = IETF, I=E2=80=99m sure we=E2=80=99ll find one :-)

AFAIR, there are also different = opinions about whether there should be
whitespace around = it.

Right.

Traditional German: em-dash with whitespace
=E2=80=9CModern=E2=80=9D German: en-dash with whitespace
Traditional US English: em-dash without whitespace, or = sometimes with (AP style, i.e., news)
Traditional UK = English: it=E2=80=99s complicated
Today=E2=80=99s English: = hodgepodge
Laypeople: essentially, use dashes only where = Microsoft Word turns a hyphen into a dash automatically, and that = involves typing spaces, or so

(And, of = course, there are range and versus dashes as well, which are always = en-dashes, but might incomprehensibly have whitespace in English.)

I don=E2=80=99t have my CMOS with me, or I = would cite chapter and verse.
But the important = observation is that this is a well-known editorial style issue to which = a copy-editor should have an answer.

More = generally speaking, the fact that Unicode has more characters does not = mean we need to spend a lot of time deciding which character to use. =  I think we are also old enough to no longer fall into Unicode = traps (e.g., =CE=A9 vs. =E2=84=A6).

Thanks very much for this discussion, based on this and also = running idnits, I=E2=80=99ve created this pull request for the FFV1 = draft, https://github.com/FFmpeg/FFV1/pull/158/files. Related to = this discussion the pull request changes the unicode minus sign to an = ascii hyphen and uses a "ceil(a)" and "floor(a)" function rather than = using "=E2=8C=88a=E2=8C=89" and "=E2=8C=8Aa=E2=8C=8B=E2=80=9D. After = this PR, it passes idnits with no errors, warnings, or = comments.

Thanks= much,
Dave Rice

= --Apple-Mail=_7E2F97F0-FC05-4443-9685-862EB0B80BB8-- From nobody Sat Aug 31 17:13:26 2019 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3F412010C for ; Sat, 31 Aug 2019 17:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.118 X-Spam-Level: X-Spam-Status: No, score=-0.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, TVD_SUBJ_NUM_OBFU_MINFP=1, 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 XzDo04dh3nsl for ; Sat, 31 Aug 2019 17:13:22 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (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 D06A112001B for ; Sat, 31 Aug 2019 17:13:22 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:47579 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1i4DUb-003bI4-Pe for cellar@ietf.org; Sat, 31 Aug 2019 20:13:22 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_8D4E2054-E7B1-4749-A1C6-12DFAA76FD8A" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <3AAAEED4-87A9-4F5B-9910-55BABBDBBB15@dericed.com> Date: Sat, 31 Aug 2019 20:13:16 -0400 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] expressing both svg graphics and ascii-art fallback within an rfc2xml version 3 file? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Sep 2019 00:13:25 -0000 --Apple-Mail=_8D4E2054-E7B1-4749-A1C6-12DFAA76FD8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello cellar, The draft of FFV1 now uses xml2rfc version 3 as defined at = https://tools.ietf.org/html/rfc7991 = . Presently in the markdown source = of the FFV1 draft, the math is maintained in both LaTeX expressions = (which are converted to SVG for inclusion in the RFC XML) as well as an = Ascii Art representation (heavily reliant on functions defined within = the draft). For example: vs r_{i} =3D floor( ( R_{i} * S_{i,C_{i}} ) / 2^8 ) Whether in SVG or ascii art, this data is contained by the = node in rfc2xml version 3. In = https://tools.ietf.org/html/rfc7991#section-2.5 = it states, Alternatively, the "src" attribute allows referencing an external graphics file, such as a vector drawing in SVG or a bitmap graphic file, using a URI. In this case, the textual content acts as a fallback for output representations that do not support graphics; thus, it ought to contain either (1) a "line art" variant of the graphics or (2) prose that describes the included image in sufficient detail. A bit later it says that SVG data may be encoded and stored within the = =E2=80=99s @src attribute such as=20 o As a data: URI, such as: So from this I was hoping we could work on one draft rfc2xml version 3 = file that could use the SVG image data or use the ascii art as a = fallback; however when I try to craft the node with both such = as: FALLBACK_AS= CII_ART_HERE then the output =E2=80=9Cv3-plaintext=E2=80=9D output of the conversion = tool at https://xml2rfc.tools.ietf.org/experimental.html = , does not use the = textual content of the node as a fallback but instead places a = warning such as (Artwork only available as svg: No external link available, see draft-ietf-cellar-ffv1-08.html for artwork.) Is it feasible (recommended?) to have one rfc2xml XML document that = could be a source for both plaintext formats (using an ascii art = fallback) and non-plaintext formats such as HTML and PDF which would use = the embedded SVG data? Kind Regards, Dave Rice --Apple-Mail=_8D4E2054-E7B1-4749-A1C6-12DFAA76FD8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= cellar,

The draft = of FFV1 now uses xml2rfc version 3 as defined at https://tools.ietf.org/html/rfc7991. Presently in the = markdown source of the FFV1 draft, the math is maintained in both LaTeX = expressions (which are converted to SVG for inclusion in the RFC XML) as = well as an Ascii Art representation (heavily reliant on functions = defined within the draft). For example:
vs

r_{i} =3D floor( ( R_{i} * S_{i,C_{i}} = ) / 2^8 )

Whether in SVG or ascii art, this data is contained by the = <artwork> node in rfc2xml version 3. In https://tools.ietf.org/html/rfc7991#section-2.5 it = states,

   Alternatively, the "src" attribute allows = referencing an external
   graphics file, = such as a vector drawing in SVG or a bitmap graphic
   file, using a URI.  In this case, the textual content acts as a
   fallback for output representations that do not = support graphics;
   thus, it ought = to contain either (1) a "line art" variant of the
   graphics or (2) prose that describes the = included image in sufficient
  =  detail.

A bit later it says that SVG data may be encoded and stored = within the <artwork>=E2=80=99s @src attribute such = as 

   o  As a data: URI, such as: <artwork = type=3D"svg" src=3D"data:image/
    =   = svg+xml,%3Csvg%20xmlns%3D%22http%3A%2F%2Fwww.w3=E2=80=A6">
<= div class=3D"">
So from this I was = hoping we could work on one draft rfc2xml version 3 file that could use = the SVG image data or use the ascii art as a fallback; however when I = try to craft the <artwork> node with both such as:

<artwork type=3D"svg" = src=3D"data:image/svg+xml,ENCODED_SVG_MATH_IMAGE_HERE=E2=80=9D>FALLBACK= _ASCII_ART_HERE</artwork>

then the output =E2=80=9Cv3-plaintext=E2=80= =9D output of the conversion tool at https://xml2rfc.tools.ietf.org/experimental.html, does = not use the textual content of the <artwork> node as a fallback = but instead places a warning such as

   (Artwork = only available as svg: No external link available, see
   draft-ietf-cellar-ffv1-08.html for = artwork.)

Is it feasible (recommended?) to have one rfc2xml XML = document that could be a source for both plaintext formats (using an = ascii art fallback) and non-plaintext formats such as HTML and PDF which = would use the embedded SVG data?

Kind Regards,
Dave = Rice

= --Apple-Mail=_8D4E2054-E7B1-4749-A1C6-12DFAA76FD8A--