From nobody Wed Jul 7 09:15:22 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2D23A1D57 for ; Wed, 7 Jul 2021 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, PDS_TONAME_EQ_TOLOCAL_HDRS_LCASE=1.998, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iaaW7Zl3YM4 for ; Wed, 7 Jul 2021 09:15:18 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 0D2BA3A1D56 for ; Wed, 7 Jul 2021 09:14:49 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id f17so3702620wrt.6 for ; Wed, 07 Jul 2021 09:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version; bh=M04SZI3bUtQeyYBJNBjZ4P2FLusWFji2Gxh7jXo9cHs=; b=gj+eWf8vhk9dNthiErfQlEn3M+J7bS6UzCuh315EUjsnMiZ2t/gjjv5np0hNzs6a/Z 3BU5fPcGp1OJqnmUXjCt6g1PvpOqkS4JvKQrgfOlN1saKN68kh8J/arP4Ge0OHUxMUT4 NUbBIEkpeHsrQph0ahN2JNCs36AWvrvMyPQkHstGbI3FhfQN4IPdvucK502cFnLmDjsd lJok8Ek1sAns9dSB8HJYxqkWQa75/RaVg5UMPYLGQRqMofTU5TohRDQB+y0k/GwrwOML O/I+Y6coQsXSZEYrExQA9y8SeBFo6Mw+4UOx5unvsaEAmBW2HlyWSt0h43wSkWXZCT+n cwFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version; bh=M04SZI3bUtQeyYBJNBjZ4P2FLusWFji2Gxh7jXo9cHs=; b=AzpSStVJnlymtoT/mjsTbNVR2wP3aQB9lG+fwVPNAQS+W3IMLMTssxgDCh5UuupJZX uQJP/y0A6hs7+O50kx6LZp0TDaxaUlaHnB+UrAdJe0E3oy5OTFaHq91WyVWzBazbV03L K9W6VxfEAwdGDnaR1H20l/vXv9W/WqNUozfOZTH+HWYB/WqGJsZ2HhMh2G7VjqACwDem 294PEd8S7E3f+1Bp8ScLr5f1hj7HJC9wusVNxFeGvSxo1fY3u0n++pBTafJXV6gMTZuq N+cPwp5XjXumGS2JGQwY3frvw7L+Ney2uHNeq9HmhJ14TjtzGISMf0aZNWl1Q48wzbnX +plA== X-Gm-Message-State: AOAM530i/3hvEbDl3Zv1kr05m6Ps49TnqmrRasHcAnRHd5qlQteWA+n2 0NneUqASk/ZXnILx8teCg77wbLK8bGg= X-Google-Smtp-Source: ABdhPJwgxzgQss9B+JNlfkYgG8jx4l6gEcmLZQPr6LYZa7+Vu9DLZzsQu6kuq7tqd0KHEJcrxAVy8g== X-Received: by 2002:adf:fc4c:: with SMTP id e12mr28778359wrs.412.1625674487736; Wed, 07 Jul 2021 09:14:47 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-182-62-6.red.bezeqint.net. [79.182.62.6]) by smtp.gmail.com with ESMTPSA id x1sm6182089wmc.0.2021.07.07.09.14.46 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jul 2021 09:14:47 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.50.21061301 Date: Wed, 07 Jul 2021 19:14:45 +0300 From: Yaron Sheffer To: tools-discuss Message-ID: <3CA32D16-EEB4-4E9E-BCB4-877D5E373F1B@gmail.com> Thread-Topic: Sup to nuts Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3708530086_140039542" Archived-At: Subject: [Tools-discuss] Sup to nuts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 16:15:21 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3708530086_140039542 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, =20 I=E2=80=99ve been using the =E2=80=9Csup=E2=80=9D XML element (superscript). It goes well thr= ough the Markdown tooling, and through xml2rfc v3.4.0 (with =E2=80=93v3). But then= it bombs when I submit the I-D. Is this just a version difference, or shoul= d I somehow set xml2rfc to be more strict? =20 FWIW, this message =E2=80=9CElement sup is not declared in t list of possible chi= ldren=E2=80=9D appears to contradict RFC 7991. =20 Thanks, =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron --B_3708530086_140039542 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi,

 

I=E2=80=99ve been using the =E2=80=9Csup=E2=80=9D XML element (superscript)= . It goes well through the Markdown tooling, and through xml2rfc v3.4.0 (wit= h =E2=80=93v3). But then it bombs when I submit the I-D. Is this just a version di= fference, or should I somehow set xml2rfc to be more strict?

 

FWIW, this message= =E2=80=9CElement sup is not declared in t list of possible children=E2=80=9D appears to= contradict RFC 7991.

 

Thanks,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron=

--B_3708530086_140039542-- From nobody Wed Jul 7 09:59:35 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8F03A1F02 for ; Wed, 7 Jul 2021 09:59:32 -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 da-q_0QHgLwQ for ; Wed, 7 Jul 2021 09:59:28 -0700 (PDT) Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5581B3A1EFE for ; Wed, 7 Jul 2021 09:59:28 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GKlyK4FpRz2xFw; Wed, 7 Jul 2021 18:59:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <3CA32D16-EEB4-4E9E-BCB4-877D5E373F1B@gmail.com> Date: Wed, 7 Jul 2021 18:59:21 +0200 Cc: tools-discuss X-Mao-Original-Outgoing-Id: 647369961.043116-79d70975f1e0873b0f21e85d2f629107 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3CA32D16-EEB4-4E9E-BCB4-877D5E373F1B@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Tools-discuss] Sup to nuts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 16:59:33 -0000 On 2021-07-07, at 18:14, Yaron Sheffer wrote: >=20 > Hi, > =20 > I=E2=80=99ve been using the =E2=80=9Csup=E2=80=9D XML element = (superscript). It goes well through the Markdown tooling, and through = xml2rfc v3.4.0 (with =E2=80=93v3). But then it bombs when I submit the = I-D. Is this just a version difference, or should I somehow set xml2rfc = to be more strict? > =20 > FWIW, this message =E2=80=9CElement sup is not declared in t list of = possible children=E2=80=9D appears to contradict RFC 7991. Hi Yaron, you are submitting something that the nostalgic software at the = submission point believes to be a pure v2 document, and this it enforces = historic purity. In order to persuade this software that it=E2=80=99s 2021, you need to = convert it to pristine v3 first. You can do that with kdrfc -3c foo.md or, if you prefer to work from the xml output, by=20 kdrfc -3c foo.xml or xml2rfc --v2v3 foo.xml In all of these cases, you get a foo.v2v3.xml that can be submitted = without invoking v2 nostalgia in the submission software. Gr=C3=BC=C3=9Fe, Carsten (Yes, I know that the submission service will be fixed very soon.) From nobody Wed Jul 7 14:23:23 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98EB3A0657 for ; Wed, 7 Jul 2021 14:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBAjUxlUks8m for ; Wed, 7 Jul 2021 14:23:16 -0700 (PDT) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 A37E53A0653 for ; Wed, 7 Jul 2021 14:23:16 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id a5-20020a7bc1c50000b02901e3bbe0939bso2620214wmj.0 for ; Wed, 07 Jul 2021 14:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=6wJ2Cl+cU5UN1/eb2UisXIzpkue6TYuPVcTAuPH+yzI=; b=kT4s77qul6js9ykzS/n7eW02xRkBdfmjs3KSfMD0658pzefob4Q7W62BkI9LzUDXIZ 0Zp3FLS4IfE1jYwiaguhfaIxRtdcwuIAmYikOIOVBpXOziS6OpKlQo84hJ+K9MPF9GKW 1YRrAWXsAvW771ICS+yhUaa2I2b76jzAbS8Ue/1YS7QX451SIPTvQHQ4oLizW9b1gQdS fYeusQZIKn3fO0pVRnU24Tz+2p+MO5qbd2f1a2r5SlmVmsW2hvMJJnvLfnWgVb7IVUOo cb9mjkFHBWL4RBvUfoV9uwLUxQtQAK2zjhlKCGWsZO1NDkknl2ol3l1KS1n4AsD5PLKX KlZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=6wJ2Cl+cU5UN1/eb2UisXIzpkue6TYuPVcTAuPH+yzI=; b=CVFqw1mxjwTEiBS78ZwNZPWEs+fSmb4r3TsuTRoOh8J+gvSsKz7tjBgcooT6rGuZ9+ cZPqgoe2VIhBA/a0Gf5aa+2LPk9KPeVvxC3PfznlCDw1KbxCRYdg9a5RC83g9X79tsa1 rLjcphKqVqRWJRQFu7KQIdlAEuqycCURLDh8BFLf+FnY0L2qgR400MzBoAMTHVhT/5us sKQkjEzrQg11t+682zWEXXFtXZni7+THU5XOlk3rCk8Bpg/uHE2yz7vs34q5+XYH60CE oLG3oLDvCNeynxo8I4F2vVjhTu+lRIBTriPokkyt8N/ok4SS/5fYTh4A2eVg0xLxluSV i6Fw== X-Gm-Message-State: AOAM530GXJ5rVK4HhSamDes1P8Uzr7rHqZ32oQonLvVb/1I4sKen8rhZ GhvXKcut0EoEcm5gwvQ3pHs= X-Google-Smtp-Source: ABdhPJxMuh5hlSXqA6PJw79Lqni5NzP8Uw7f32rWmn//a6lIJZ2S+tBHxWY8H1S1qIh6KNti2bPg4A== X-Received: by 2002:a7b:c351:: with SMTP id l17mr29112247wmj.120.1625692994594; Wed, 07 Jul 2021 14:23:14 -0700 (PDT) Received: from [192.168.68.110] (bzq-79-182-62-6.red.bezeqint.net. [79.182.62.6]) by smtp.gmail.com with ESMTPSA id t6sm99733wru.75.2021.07.07.14.23.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Jul 2021 14:23:14 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.50.21061301 Date: Thu, 08 Jul 2021 00:23:07 +0300 From: Yaron Sheffer To: Carsten Bormann CC: tools-discuss Message-ID: <4975ED33-924A-416F-B799-3B6ABAC705FE@gmail.com> Thread-Topic: [Tools-discuss] Sup to nuts References: <3CA32D16-EEB4-4E9E-BCB4-877D5E373F1B@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [Tools-discuss] Sup to nuts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 21:23:22 -0000 Hi Carsten, Yes, this fixed my problem. Thanks for your help! Yaron =EF=BB=BFOn 7/7/21, 19:59, "Carsten Bormann" wrote: On 2021-07-07, at 18:14, Yaron Sheffer wrote: >=20 > Hi, > =20 > I=E2=80=99ve been using the =E2=80=9Csup=E2=80=9D XML element (superscript). It goes we= ll through the Markdown tooling, and through xml2rfc v3.4.0 (with =E2=80=93v3). Bu= t then it bombs when I submit the I-D. Is this just a version difference, or= should I somehow set xml2rfc to be more strict? > =20 > FWIW, this message =E2=80=9CElement sup is not declared in t list of possib= le children=E2=80=9D appears to contradict RFC 7991. Hi Yaron, you are submitting something that the nostalgic software at the submiss= ion point believes to be a pure v2 document, and this it enforces historic p= urity. In order to persuade this software that it=E2=80=99s 2021, you need to conver= t it to pristine v3 first. You can do that with kdrfc -3c foo.md or, if you prefer to work from the xml output, by=20 kdrfc -3c foo.xml or xml2rfc --v2v3 foo.xml In all of these cases, you get a foo.v2v3.xml that can be submitted wit= hout invoking v2 nostalgia in the submission software. Gr=C3=BC=C3=9Fe, Carsten (Yes, I know that the submission service will be fixed very soon.) From nobody Tue Jul 13 13:14:39 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66853A180F for ; Tue, 13 Jul 2021 13:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=WTMqaa4o; dkim=pass (2048-bit key) header.d=taugh.com header.b=hCSKMbav 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 c8jZvgRoX2SN for ; Tue, 13 Jul 2021 13:14:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C2F23A180B for ; Tue, 13 Jul 2021 13:14:31 -0700 (PDT) Received: (qmail 54883 invoked from network); 13 Jul 2021 20:14:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=d661.60edf426.k2107; bh=rQeabR0Ap+shJTgrEtPgJVVRVAyNtvTXFjjCenP5258=; b=WTMqaa4oXV0g0RylQ/LaeOTpAJO0Dnhzdki/xaQcRHLwpZmB6+rK4VgJ1CCHE7L6DyXLMa1mhnRfiInVuV2wgsZWBnjfCy3QcPfTaRUvMDGhvV/dhAG4dsd7PfgoyJXZDRtoCDkraxd1a5rU1Z/9HrCPKApSWjLydcOXp+o1wEAzxa7hoCawfZd0zJJzl/6yq9BG++DtoT54LdAlcD4aG1UctWMGVzBxw4KTapLyuG59lpCfu2T5uw3Ka8FDEpNsp0MdTySSm96g6ymPUIEI/AIrR2JbQphHOx3S0R10f/+qZx8hnhKXJMJYK05fLymwbkryZQpgM3402hHxcOCjkg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=d661.60edf426.k2107; bh=rQeabR0Ap+shJTgrEtPgJVVRVAyNtvTXFjjCenP5258=; b=hCSKMbavGjxiV8hXhrqKOyQGe7l6DSEFyuGhgCjvgfSfdv5jo8+dsETNI1m0B6qU5FptoctGkIDvT5pPppVwUqxnNPil+ysZTCXV3h8jcBiCtdfiaExwRYvSlMZXELoB5cmQcqUWqVyLRKZszID+Y7G00BI1sdEEatGO86GkO1ivBacmoLl2BaHPXNOG0Wsz5p20xB9YTplrvfG2XwM/upo8fcuUYX/OGGKmWZBwdZ24nlt+uH/CLYm4mw+Nb6ujAd2hXFajzrVsIZh+Up/WwSimzNXAyNV8QawE4jxn+4rZDIMEybzZDXyprdEvPDwwU/mzcWs4q22YlfHwkOlHDw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Jul 2021 20:14:30 -0000 Received: by ary.qy (Postfix, from userid 501) id 5881D2150B1F; Tue, 13 Jul 2021 16:14:29 -0400 (EDT) Date: 13 Jul 2021 16:14:29 -0400 Message-Id: <20210713201429.5881D2150B1F@ary.qy> From: "John Levine" To: gendispatch@ietf.org, tools-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] [Gendispatch] Updating the IETF Discussion List Charter (was: Fwd: New Version Notification for draft-eggert-bcp45bis-02.txt) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 20:14:38 -0000 It appears that Lars Eggert said: >On 2021-7-13, at 1:50, Eric Rescorla wrote: >> With that said, there's no reason to be locked into the "one-size-fits-all" mailing list paradigm for this kind of automatic notification. Unlike ietf@, the number of people >who send mail to ietf-announce is very small, so we don't really need to have it as a simple mailing list. Instead, what I would suggest is that we modify the automatic >notification system to allow people to customize which notifications they want to receive (they can still allo appear to go to the same list, which could even be called >ietf-announce if we want). That way, people can easily filter on the server side and get just the subset they care about. [0] >> >> -Ekr >> >> [0] We can of course still build an archive that has every announcement. > >I like this idea. Would this need to result in new custom datatracker code, or is there a third-party service that could be leveraged? > >(This part of the discussion should also probably move to tools-discus.) You really, REALLY, do not want to try to reinvent a bulk mail system. GNU Mailman has a little-used "topics" feature that I think can do the trick here. The list manager configures a set of topic regexps for the list, and subscribers can say which topics they want. In each message the topic(s) appear in the Subject or Keywords line and it sends the message to the people subscribed to the topics. If you don't pick any topics, by default you get all of them. See https://www.gnu.org/software/mailman/mailman-member/node29.html The interface within mailman to set the topics is pretty grody, but I presume it just puts stuff in the underlying database so we could invent our own interface to it without extreme pain. R's, John PS: Some of us don't subscribe to any IETF lists but instead retrieve the messages from the IMAP server, but I think we can fend for ourselves. From nobody Tue Jul 13 14:44:04 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76F3A12C9; Tue, 13 Jul 2021 14:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7YOuaTMfDqv; Tue, 13 Jul 2021 14:43:54 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (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 78B043A12C5; Tue, 13 Jul 2021 14:43:48 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id b13so37295775ybk.4; Tue, 13 Jul 2021 14:43:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9E8iNGg+qNJagN4jJojSvyQfLYPNBpgqU2Ka3ZqmE5Q=; b=QPi1hvHzRZ4tsmkVXMccEDNBw+QJNWhcVbWpwKXZrR7Z/8qq0AAbMozlM6drXW/4Bg oATgxGKMl3lZU40Gu5JYU7TRXeFNvS3ShC3koonmXw6j8hPOB680Wc3jARR6eBFOLXvk AHj77QEJ96jw5czlEdyqY+4v91heVK12+v6ZYa0+ljPL6ctsi79QEaDacYMLL7J3i8aS JnCJckAw+imXS0dPVlt9biB0Ju/WpR9cZRIvrFaUm8RkBm7ZwijFAfnU5wGAcaMtsIsn //vhyxRVhMxtHMsKRqhT1d3PgHjLipja3V9+27mMmXwhAWZyQp6SSTazSDsvEIlrC70T mSMg== X-Gm-Message-State: AOAM530qq/688K30ctU7m92za3CQZ3C67eCyHYQhSO0PkEgDO+gAW+vz zJ3fo2TqXodc9nLUzkEUXeBaLZm+7K64+56QErs= X-Google-Smtp-Source: ABdhPJyljTd4L2P9oXRMsT+EXiBXx6MZWhihJqnSVjxkOAv4r5vlbJN1JHYyvp47JLs6insheiL6yDBHqN7IImUPB5o= X-Received: by 2002:a25:2d57:: with SMTP id s23mr8796580ybe.302.1626212627351; Tue, 13 Jul 2021 14:43:47 -0700 (PDT) MIME-Version: 1.0 References: <20210713201429.5881D2150B1F@ary.qy> In-Reply-To: <20210713201429.5881D2150B1F@ary.qy> From: Phillip Hallam-Baker Date: Tue, 13 Jul 2021 17:43:36 -0400 Message-ID: To: John Levine Cc: GENDISPATCH List , Tools Discussion , Lars Eggert Content-Type: multipart/alternative; boundary="000000000000fb8ef305c70821a7" Archived-At: Subject: Re: [Tools-discuss] [Gendispatch] Updating the IETF Discussion List Charter (was: Fwd: New Version Notification for draft-eggert-bcp45bis-02.txt) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 21:43:59 -0000 --000000000000fb8ef305c70821a7 Content-Type: text/plain; charset="UTF-8" The reason to not reinvent a bulk mail system is simple: It is a terrible idea that has always sucked. The Achilles heel of SMTP is that it is a push mode system. NNTP was better because messages were pulled. An NNTP based discussion scheme would be a much more effective way to manage 'mailing list' traffic because it is a pull mode scheme. The big mismatch between functionality and features here is that we are trying to use SMTP as a workflow system which it is not what it is designed to do. A better solution would be an append only log of events such as ID publication, RFC publication, interims, etc. that might trigger actions for specific users and client software capable of processing those events on the user's behalf according to rules specified by the user. Sign the logs as a Merkle Tree and we have authenticated events and can do more interesting stuff. Of course, this is yet another of those 'things we could actually do with crock-chain' which the crock-chain world completely ignores. On Tue, Jul 13, 2021 at 4:14 PM John Levine wrote: > It appears that Lars Eggert said: > >On 2021-7-13, at 1:50, Eric Rescorla wrote: > >> With that said, there's no reason to be locked into the > "one-size-fits-all" mailing list paradigm for this kind of automatic > notification. Unlike ietf@, the number of people > >who send mail to ietf-announce is very small, so we don't really need to > have it as a simple mailing list. Instead, what I would suggest is that we > modify the automatic > >notification system to allow people to customize which notifications they > want to receive (they can still allo appear to go to the same list, which > could even be called > >ietf-announce if we want). That way, people can easily filter on the > server side and get just the subset they care about. [0] > >> > >> -Ekr > >> > >> [0] We can of course still build an archive that has every announcement. > > > >I like this idea. Would this need to result in new custom datatracker > code, or is there a third-party service that could be leveraged? > > > >(This part of the discussion should also probably move to tools-discus.) > > You really, REALLY, do not want to try to reinvent a bulk mail system. > > GNU Mailman has a little-used "topics" feature that I think can do the > trick here. The list manager configures > a set of topic regexps for the list, and subscribers can say which topics > they want. In each message the topic(s) > appear in the Subject or Keywords line and it sends the message to the > people subscribed to the topics. If you don't > pick any topics, by default you get all of them. > > See https://www.gnu.org/software/mailman/mailman-member/node29.html > > The interface within mailman to set the topics is pretty grody, but I > presume it just puts stuff in the underlying > database so we could invent our own interface to it without extreme pain. > > R's, > John > > PS: Some of us don't subscribe to any IETF lists but instead retrieve the > messages from the IMAP server, but I think we > can fend for ourselves. > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --000000000000fb8ef305c70821a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The= reason to not reinvent a bulk mail system is simple: It is a terrible idea= that has always sucked.

= The Achilles heel of SMTP is that it is a push mode system. NNTP was better= because messages were pulled. An NNTP based discussion scheme would be a m= uch more effective way to manage 'mailing list' traffic because it = is a pull mode scheme.=C2=A0

The big mismatch between functionality and features here is that we are= trying to use SMTP as a workflow system which it is not what it is designe= d to do.=C2=A0
=

=
A better solution wo= uld be an append only log of events such as ID publication, RFC publication= , interims, etc. that might trigger actions for specific users and client= =C2=A0software capable of processing those events on the user's behalf = according to rules specified by the user.

Sign the logs as a Merkle Tree and we have authenticated e= vents and can do more interesting stuff.


Of course, this is yet another of those 'things we could actually= do with crock-chain' which the crock-chain world completely ignores.





On Tue, Jul 13, 2021 at 4:14 PM John= Levine <johnl@taugh.com> wrot= e:
It appears th= at Lars Eggert=C2=A0 <lars@eggert.org> said:
>On 2021-7-13, at 1:50, Eric Rescorla <ekr@rtfm.com> wrote:
>> With that said, there's no reason to be locked into the "= one-size-fits-all" mailing list paradigm for this kind of automatic no= tification. Unlike ietf@, the number of people
>who send mail to ietf-announce is very small, so we don't really ne= ed to have it as a simple mailing list. Instead, what I would suggest is th= at we modify the automatic
>notification system to allow people to customize which notifications th= ey want to receive (they can still allo appear to go to the same list, whic= h could even be called
>ietf-announce if we want). That way, people can easily filter on the se= rver side and get just the subset they care about. [0]
>>
>> -Ekr
>>
>> [0] We can of course still build an archive that has every announc= ement.
>
>I like this idea. Would this need to result in new custom datatracker c= ode, or is there a third-party service that could be leveraged?
>
>(This part of the discussion should also probably move to tools-discus.= )

You really, REALLY, do not want to try to reinvent a bulk mail system.

GNU Mailman has a little-used "topics" feature that I think can d= o the trick here.=C2=A0 The list manager configures
a set of topic regexps for the list, and subscribers can say which topics t= hey want.=C2=A0 In each message the topic(s)
appear in the Subject or Keywords line and it sends the message to the peop= le subscribed to the topics.=C2=A0 If you don't
pick any topics, by default you get all of them.

See https://www.gnu.org/software/mail= man/mailman-member/node29.html

The interface within mailman to set the topics is pretty grody, but I presu= me it just puts stuff in the underlying
database so we could invent our own interface to it without extreme pain.
R's,
John

PS: Some of us don't subscribe to any IETF lists but instead retrieve t= he messages from the IMAP server, but I think we
can fend for ourselves.

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--000000000000fb8ef305c70821a7-- From nobody Tue Jul 13 14:52:31 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785FF3A13A3 for ; Tue, 13 Jul 2021 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=MCFt3yG/; dkim=pass (2048-bit key) header.d=taugh.com header.b=KwlAvJVQ 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 orP-u0ROSH-h for ; Tue, 13 Jul 2021 14:52:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2740E3A13A4 for ; Tue, 13 Jul 2021 14:52:23 -0700 (PDT) Received: (qmail 77957 invoked from network); 13 Jul 2021 21:52:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=13083.60ee0b15.k2107; bh=9U0hd1/a+/TNk7AfbDfz/ueeHgKGhpA6qUiFIor0wUY=; b=MCFt3yG/KLZQxNjO6qyPF0n+CW/SSN/ul/mxAEuyhGuXYcu+DlBxRX/79tOl6bDOuF1KSi38cZP+2gCXj4hjw1vT57aigtoc9ql4uFGDPLzIF+v48ik/q+pfS3ngwsGdCaplMydIRNHO4mGT3PCwPiWLJKeqxyZt29aw967lAlaaco37tziNZcad0tHzpJT7aRe99Oc0kGTk3AQy5KGrtB+Pom290WpES7z7LK9L0q4XCwjNB+eMLtCx+uxTbo5yw24RI/i9mTROzkNKZ8N64rZSF3rVeQchPECj0ydv/vSwKoEFHhbIU2ZlIEE3cbG4MSh/WPX8z2sA6Wj5iA8gDA== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=13083.60ee0b15.k2107; bh=9U0hd1/a+/TNk7AfbDfz/ueeHgKGhpA6qUiFIor0wUY=; b=KwlAvJVQyU4o+Xi+szSETFCkgfM3xv8qaiqcK7pzZb2Z25i23e4EgXvP6GuHo/6Jv7uKnrX8I4TOxTFEdC4QsOTSo/98h5TPq77srDImg/0m5HCOPzDlhnyKcBa00ZsrzxuRpn5cIjXejPWhHp3xBnbDSdCRRtj7hSzCiNDNoUrqpBICW/JvRb2GjoAHUNOhH7Sc+nzRJ8uQmuL/agmayjs5B4VN0KaGWUmVT+pxPDZqrlZXbXA9sDMJn7ZDvhx8r/NaFWqSDfcJqzysmLGBfnIgCzVm1m4BXLCbuuNLLSppG1aZZAEANwjcY4PmGCW217k5d0R0ShVBRFbmwAHw5g== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 13 Jul 2021 21:52:21 -0000 Received: by ary.qy (Postfix, from userid 501) id B00FC215FFB3; Tue, 13 Jul 2021 17:52:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 5F077215FF8C; Tue, 13 Jul 2021 17:52:19 -0400 (EDT) Date: 13 Jul 2021 17:52:19 -0400 Message-ID: <4f6398-4efe-d1be-7cf-d0bce8a3a62c@taugh.com> From: "John R Levine" To: "Phillip Hallam-Baker" Cc: "GENDISPATCH List" , "Tools Discussion" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210713201429.5881D2150B1F@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Tools-discuss] [Gendispatch] Updating the IETF Discussion List Charter (was: Fwd: New Version Notification for draft-eggert-bcp45bis-02.txt) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 21:52:30 -0000 > The Achilles heel of SMTP is that it is a push mode system. NNTP was better > because messages were pulled. An NNTP based discussion scheme would be a > much more effective way to manage 'mailing list' traffic because it is a > pull mode scheme. That's why I have an IMAP->NNTP gateway and read all the lists from my news server. The threading and killfiles are nice, too. But as you know, I am strange. > Sign the logs as a Merkle Tree and we have authenticated events and can do > more interesting stuff. Unfortunately, decades of experience tell us that the reason we all still use e-mail is that it *is* a push system, the stuff shows up automatically, and we all still check our e-mail. If we have to check some whizzo other thing, we won't, and it will fail. The news hack works for me because I put every mailing list I read from everywhere into it, so it's only one place to look. R's, John >> GNU Mailman has a little-used "topics" feature that I think can do the trick here. From nobody Thu Jul 15 20:14:34 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1E23A21BB for ; Thu, 15 Jul 2021 20:14:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=i8e5aTUV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dwt7+zc5 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 FFaBy2F45PPu for ; Thu, 15 Jul 2021 20:14:27 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2253A21B9 for ; Thu, 15 Jul 2021 20:14:26 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id ECC9A5C00E3 for ; Thu, 15 Jul 2021 23:14:21 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Thu, 15 Jul 2021 23:14:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=PjRYzMz9iChKQ4dNy4zxcVGRMTEf3ceKkWr3Fmum+tA=; b=i8e5aTUV t87hjEPeEtKrdtBPUDBEX3CljE85g5yVKPKZEDQF5To4ht7q4ZUERaD2HVFr58tU bUP9R5FEb2IYSU86l8mDPXvv8bJa6WdXLNWTUla4QQ2Py/xBeut5I8towZ9dVyno UZlbTBzAXR/UW4Bn8mXrmk2mANKnVRKDFAsvmHCFJou03Ioy4qWxC5epQ9nzVGFs /qANHE96z/4AePvIUbseBeX2CV0Fapm6fjyESCRUO87ZUnzr6T5F61JhuUwHWfYS nIEvMm033UhWHTGSdhkN+Ait+d/iqPXxztDWPIdTioDgG7+pqMIrBnkd1b6b5IbF lpYKkXkvLirrIg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=PjRYzMz9iChKQ4dNy4zxcVGRMTEf3 ceKkWr3Fmum+tA=; b=dwt7+zc5U18nerQfOAXXdvEYSCYPmIoEebCun406zTD3S +9nais2vEX6lCF31t4sor1s3fm3hPJD8JVBWHvyK7XKFk5YlSz/cr3DTHiHiLbBN ZTKbyNDfHDJj+UC8jSHEaO55WW3pL8zoBbotqC7oEE0f3xDst3YXYjbcz6Hv4yS1 Bg3j+SCwtbMPktYGGa+ai8p/askB5xUyP6YrxqILcPZAkxufeZS+zKhgImERyF8+ lyuscK7Fs+J5mJu4UFsuimhEpgWXUQSLJbhzc8KiYcqaUCcFuEGfDK3Y1EHSEhUY DTROyr8EtKfsWFP04Eu54XaGZvTOdxNKUssE+MvjA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgdeifecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepieevffekveelleehteefleefhf fggeduudegieffffeujeeufeduvdelveekjeetnecuffhomhgrihhnpehgihhthhhusgdr tghomhdpthgvmhhplhgrthgvrdhmugenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A66F33C0CFD; Thu, 15 Jul 2021 23:14:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-Id: <5391988e-7180-49d3-989b-3cf40e395408@www.fastmail.com> Date: Fri, 16 Jul 2021 13:14:04 +1000 From: "Martin Thomson" To: tools-discuss@ietf.org Content-Type: text/plain Archived-At: Subject: [Tools-discuss] Template repository for GitHub X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 03:14:32 -0000 Hey, Anyone who has setup a new GitHub repository for an Internet-Draft knows that it can be a little tricky, particularly if you use the toolchain I support. Not any more. I've created a template repository that makes setup very simple. Just create a new repository using the template, rename your draft, enable GitHub Pages, and you are ready to go. You can run all of this from the web UI that GitHub provides. That includes publishing drafts to datatracker, which is done by creating a release[*]. Some credit here is owed to Mallory Knodel for complaining loudly enough about how unfriendly this whole setup was and motivating me to spend a couple of hours on finally doing this. Documentation here: https://github.com/martinthomson/i-d-template/blob/main/doc/TEMPLATE.md As always contributions and bug reports are welcome. Cheers, Martin [*] This bit isn't completely tested yet, I'll confess. From nobody Fri Jul 16 06:57:08 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A438E3A3814 for ; Fri, 16 Jul 2021 06:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nohats.ca 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 sU5hi77iCvH6 for ; Fri, 16 Jul 2021 06:57:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 D01563A3815 for ; Fri, 16 Jul 2021 06:57:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4GRCTd1QYqz3CL for ; Fri, 16 Jul 2021 15:56:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1626443813; bh=ZYMjFYR+KktMXNy42JLFzGC3hsUMeLnUSoMrtWPIxSw=; h=Date:From:To:Subject; b=NFiPGw4uasd014vGgPC1SZCdss+COpLBGPthXPMnh4OnBiRAQFOwHvkp54rXFZvJ8 AdSl5WW09owZ6mdDQOBQkq49aRdLiV7BgiY5tzg0HZL+y1avoDw1W9mQ1nK9F4wGjm 5W2bGuaa3J7/nRfCBp5qfYykQTrJqgRJI9WIKu88= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id EQnFyoDSYqjI for ; Fri, 16 Jul 2021 15:56:52 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 16 Jul 2021 15:56:51 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AD233CA111; Fri, 16 Jul 2021 09:56:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A9A3FCA110 for ; Fri, 16 Jul 2021 09:56:50 -0400 (EDT) Date: Fri, 16 Jul 2021 09:56:50 -0400 (EDT) From: Paul Wouters To: tools-discuss@ietf.org Message-ID: <261bdc5b-ff6d-2f9e-b997-7c1f933fbd87@nohats.ca> MIME-Version: 1.0 Content-Type: text/plain; CHARSET=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: [Tools-discuss] fwd: (harmless?) Incident on IETF.ORG (fwd) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 13:57:06 -0000 Just forwarding this message. Not sure why they reached out to me personally. Removed personal details from sender to not publish those to the archive - I can relay a message back if desired. [omited large included screenshots] ---------- Forwarded message ---------- Date: Fri, 16 Jul 2021 04:54:54 From: Support To: Paul Wouters Subject: (harmless?) Incident on IETF.ORG Dear Mr. Wouters, as an involved in the ietf security, i think i should inform you about this. Instead of the normal tools.ietf.org website with the rfcs, i got content of the homepage of Hendrik Levkowetz. I know hes  involved in the ietf and i assume his homepage is hosted on the same server. This leads me to the assumption, that the IETF Webservice had a breakdown, something your webmaster should know about. Time: ~10:45 CEST I can't reproduce it at the moment, so the browser history has to prove my words : Mit freundlichem Gruß From nobody Fri Jul 16 07:19:07 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9FC3A087E for ; Fri, 16 Jul 2021 07:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6DbnQXa1ivr for ; Fri, 16 Jul 2021 07:19:01 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2819F3A38B6 for ; Fri, 16 Jul 2021 07:18:46 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GRCyn6sLmz2xLW; Fri, 16 Jul 2021 16:18:41 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <261bdc5b-ff6d-2f9e-b997-7c1f933fbd87@nohats.ca> Date: Fri, 16 Jul 2021 16:18:41 +0200 Cc: tools-discuss@ietf.org X-Mao-Original-Outgoing-Id: 648137921.389272-7aa753fc11fca1c0b95a823f7a92643c Content-Transfer-Encoding: quoted-printable Message-Id: <4D14B17C-14A7-4975-BFF9-017BE9C51B56@tzi.org> References: <261bdc5b-ff6d-2f9e-b997-7c1f933fbd87@nohats.ca> To: Paul Wouters X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Tools-discuss] (harmless?) Incident on IETF.ORG (fwd) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 14:19:06 -0000 On 2021-07-16, at 15:56, Paul Wouters wrote: >=20 > Instead of the normal tools.ietf.org website with the rfcs, i got = content of the > homepage of Hendrik Levkowetz. Indeed. Operational URLs that I tested on tools.ietf.org do work, = though. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 16 07:44:22 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6323A39A7 for ; Fri, 16 Jul 2021 07:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ1TLVhsJ8Kc for ; Fri, 16 Jul 2021 07:44:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABA43A39A4 for ; Fri, 16 Jul 2021 07:44:14 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16GEiAm6070777 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 16 Jul 2021 09:44:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626446651; bh=VZJkPg46LF3FtK7eHeKdse/JjuBfF4aCkeZdLs94TIU=; h=Subject:To:References:From:Date:In-Reply-To; b=mh29x1nKBqRjdxuPlJdhxHvO6ukE4Vpt1CTRp2oxriE2a2OO8AU29AodHSu1G08tC YPpKJFjOZIx7g0Wc1Ewdv8wxogYq6+TpRLuHDWxHxjmVjIEEv7uNIXjmr9WnBkIK60 3xtJJ4XfOPepACR4ETecVJt3SxM7KjfKChjeu6Ps= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: tools-discuss@ietf.org References: <261bdc5b-ff6d-2f9e-b997-7c1f933fbd87@nohats.ca> <4D14B17C-14A7-4975-BFF9-017BE9C51B56@tzi.org> From: Robert Sparks Message-ID: Date: Fri, 16 Jul 2021 09:44:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <4D14B17C-14A7-4975-BFF9-017BE9C51B56@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] (harmless?) Incident on IETF.ORG (fwd) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 14:44:22 -0000 Henrik is making adjustments to move some things to his personal domain - I suspect the below was a transient configuration issue. RjS On 7/16/21 9:18 AM, Carsten Bormann wrote: > On 2021-07-16, at 15:56, Paul Wouters wrote: >> Instead of the normal tools.ietf.org website with the rfcs, i got content of the >> homepage of Hendrik Levkowetz. > Indeed. Operational URLs that I tested on tools.ietf.org do work, though. > > Grüße, Carsten > > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss From nobody Fri Jul 16 07:51:13 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA7B3A39F0 for ; Fri, 16 Jul 2021 07:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dli9n2ONs3dw for ; Fri, 16 Jul 2021 07:51:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 1E4583A39EC for ; Fri, 16 Jul 2021 07:51:06 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16GEit9Q024078 for ; Fri, 16 Jul 2021 10:51:06 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by mx0a-00191d01.pphosted.com with ESMTP id 39u60p6c4a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 16 Jul 2021 10:51:06 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16GEp5qx001320 for ; Fri, 16 Jul 2021 10:51:05 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16GEp2cP001269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Jul 2021 10:51:03 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id D69584005C1D for ; Fri, 16 Jul 2021 14:51:02 +0000 (GMT) Received: from GAALPA1MSGED2DA.ITServices.sbc.com (unknown [135.50.89.138]) by zlp30486.vci.att.com (Service) with ESMTP id A84784005C1E for ; Fri, 16 Jul 2021 14:51:02 +0000 (GMT) Received: from GAALPA1MSGED2CC.ITServices.sbc.com (135.50.89.134) by GAALPA1MSGED2DA.ITServices.sbc.com (135.50.89.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Fri, 16 Jul 2021 10:51:02 -0400 Received: from GAALPA1MSGETA03.tmg.ad.att.com (144.160.249.125) by GAALPA1MSGED2CC.ITServices.sbc.com (135.50.89.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Fri, 16 Jul 2021 10:51:02 -0400 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.170) by edgeal3.exch.att.com (144.160.249.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Fri, 16 Jul 2021 10:50:52 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KBO24EgwMYGMphJPlDksxVxDFxfN/MefXhW1QUU7QyoOymDxTb+2jMKTe7ATb055hageMWiWnE0kWHb7AsE0Wc5QbbfjQ+8wgC3B1mvtCJb4tOP8WTKZZu6N1rKlHXkv0tbMyrRGpl/DxctBRfnx7slT43rDJIuom0K9raSm5gkj9RspiYdVCAs1Ua97nfsXX4UL2qSOw7Oojj6CKnZyP583UNrFNbEris4fR0XHK7yQxjlC5v9LjPccQifejYI7rXhbReyyAK8CdKKolt95cgDE1vfirnuB23Ju+XJqxBmPdAuXTuGjeBE59ebWL4H/T+BQ9pXuokoeAkE1EaHZWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o604pkISsAHabJQmIS8dysnxIJp0VMDEQzGmRM5R8Cc=; b=Qbuw44mhByPvgAUP1NR5ncrh8dDJDAg+fl2n+Y8MHjL7Zb3MePa8c/GWEQY+UmCcfD9BRVCM+Ix+PO/lBlAv4YJ9o5VeYhuKBYWqtiWRD4Hlbh1Np6aMfHw+UrlZG3j14UPemOV9AkrZYoN6wyhfrkzKcI9veRBcLNG26UnzlKjWJWU4z3xwdjf39Iw5A39bRW+JXxwICMFw/OTaX+B1St0ZxIK2qxmZ8L45O8SArnwEBndJLBRQzNguT4byLBodRLaxWZ4fGExIAgAdl49nFohFjnbbQ0HaMHC83LEjXmyQh8E7KaRpFHWLMlaSAFH04cUiovTU6u7C/aDSt+wE2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o604pkISsAHabJQmIS8dysnxIJp0VMDEQzGmRM5R8Cc=; b=G6y0qI6UOh4G4hbQMxwoDwZKq91ttwYVfCKXi64m2Q2vlF+c0BDE+gBDQg0FuSlFOiwUh7ocbN7sLiziDSrGQa5/2L7GHR1pU1/qPsIgZaMrVeJZAxIdzsUQX415sx4akl+jaQJagRc5rPyUYUgXZJ6b5jgaBzf6m3mQqwpGdds= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6922.namprd02.prod.outlook.com (2603:10b6:5:252::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.22; Fri, 16 Jul 2021 14:50:51 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130%3]) with mapi id 15.20.4308.027; Fri, 16 Jul 2021 14:50:51 +0000 From: "STARK, BARBARA H" To: "'tools-discuss@ietf.org'" Thread-Topic: emails being truncated Thread-Index: Add6UW1BT3hnBbhrRzu9q3XpOkAMBA== Date: Fri, 16 Jul 2021 14:50:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c7b7e7e-09d2-408c-5a84-08d948691b4e x-ms-traffictypediagnostic: DM6PR02MB6922: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3631; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Cq0/2tMvD394WVH44cs1P88/eBELgfqqJKVRgJ6PYRi99jOxzlFt/nEMQ3BydxXomqAOMhqXMZvcJ0cA0ODlUJzFOCVnA0ASEP7p+3uRLb81dINTTosH2WJCJoE9+D8ZsjsnszuzZe6nzYINTcvmcK/BPvGFIv/hlS4JmXFECMFfyCAniKdsp4EuxHOiDQZU5MoIS/fz2o8bT9A1wq6cWbyBzEp4uERn9mZyfCvVYn/qgXUUMW8RmpQMHjjEG+DOV9kwTj/U8GjpOf0HQPeMMJWot0PEyc7IvIUwWwnMDO+z0SFsZb3jZjvX8x8glJ/aFukIFkzyI3wWMVlxhYH539x9nBdwm60du4GFH4JN6mLXlwoiwZwuU7qO16ms8AYne7m0qWWyTtIVNQyfpsMrXCVC5WZ7MpcEzOQZJ/bB8m841KNDrTR0GgcAZZSeUtq1EKh2bRwxvqaGf7i5mFrhM6V+ZDYzKpa9FESS1+rN0jjuWgy9PwKyBDyQAvjQar9WPVu1dy8+egjMuovjpH7Pjv0aLGLeHIYulF3D9Vrs5XHNirZn85ozV7I/WXPpMaOSpYo5oAT+3b3S3/DOSIaGL/6qtmk4ep1yo17u4l7lplrl27NUoDnCQWF3bFS092LWiBpf9UyRB1um4Uq3P5d9ALlqqbMyUahpn3Ro17LoOUXiWyXPJEKdcNLSF3Bi1SsLJosdhLS0nA1q9pC6YbT74VFcxNWx6dpwxYGhavjJ38jkfjujoMGY2QZ3TreEdzom x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(64756008)(6916009)(7696005)(66446008)(5660300002)(66476007)(66556008)(76116006)(66946007)(508600001)(82202003)(558084003)(26005)(2906002)(316002)(71200400001)(6506007)(7116003)(8676002)(186003)(55016002)(8936002)(9686003)(86362001)(52536014)(122000001)(38100700002)(3480700007)(133083001)(491001)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+zjBueQcGhR/Kadzj9nLFiteprBDa3fAf7DycR6QYBtQQWbSqQ/d6wNhx7HV?= =?us-ascii?Q?UJgwL9DH0HIz7avmCHROLtNTn95bygXB4aRh/g15g0qEjcQHnMIWL17VSU5e?= =?us-ascii?Q?7ySFaMiCrGXTE6u4Wd9d2aCDlBpufN5rE4d3N8WZSH6Jg/HLHA0h8DyakRR3?= =?us-ascii?Q?egVIl2gdlimhUM/iPvkvZxAjQXWOZV8vbLkCEf2w/L+bobJLCfHyqioHg3ta?= =?us-ascii?Q?0me6ySq37rbDEmIf10MJfgd3o/k4r3RUjnbiEtH2ZI7W0oVjVINyHYkz0l4y?= =?us-ascii?Q?t7TW1bsBVMr1+niy5iY7a27JzhEPLsYLKXlLpF7HgBP5EX0PNtLQCu/xJ37G?= =?us-ascii?Q?n/YY5iRcBbodH6dbA0dsv0ttdcDvxomfNWdq5oXKy51bLn7JMyYieNCwD7Vz?= =?us-ascii?Q?rz54eIYM6PmWZwRKlwN1KhoNBFfXwh4rR+hN/VWJrFgppurBvIbwA/LkUMm9?= =?us-ascii?Q?t/EieVrGQyIbUVtSmLOstrO4kRLQIWJW48Mc4qFPAOiOkHUjRrfkxR1pErbo?= =?us-ascii?Q?aZ77foU0YUASzNl17p0W8LGyCOseherDmt5/CDb5Tpy8MVU8TWuGmd47QFQS?= =?us-ascii?Q?0xfb9XqP4gou9brNhZOss9OkPET15rNEOXHN2W5FHlV4ZWPbPmoTKGHZ1ETF?= =?us-ascii?Q?uzqyPkDs0jyc5k+0wCKDyzGD2AU/faxuS4C9Gaekqgi/VeqLZDW4K4XaCgL4?= =?us-ascii?Q?GSlZTuCvKYedwpi9Y50/yhV/OxUOfblN6GqMoZqZnOsp9fMIOaVKeokc+fd2?= =?us-ascii?Q?7kCwbRv8P10OLZEccA595jg5HE6qH5Y19LHV1b3AMlM8pLAy/FfFAfOy/A91?= =?us-ascii?Q?NYVR/cwMc73xEUCQkFPzGlSHq16VCAEzxzJhFZiqLDOTSdnmdb9y+Ti/KTPc?= =?us-ascii?Q?c+/hYyGRfYjIQsSD73n/tRG/U1Qb9/a7rtXo+k7UWawpO9er9dOKfTQ82kw2?= =?us-ascii?Q?dTHjc8hU812+B3oPl5HxIChF1YOQL5BgUGUnS4NKhQbaVNEHsoV2p4ytauVX?= =?us-ascii?Q?EZa36tvaol7lQBqSyCRQhcGOEt2PGEZL7LBkA21m4M+kw5clC9h/AVtRTTJN?= =?us-ascii?Q?l+9K5x7t8zrxLVQxiIBQylgGKxgpjLnA2Dnu12DDjVwJuO6OnfweqP7gdd+H?= =?us-ascii?Q?+OJsbU/HSF6HoJ+069cFk2AaqKHyyyWkhRdpNIBURuRI1HJGVnlVo5rRedd8?= =?us-ascii?Q?23c8r8BN453N+ZCSD8+VCQJaYrS7we0yURppDn6K1rkOCBYmUpWC7q6p8ndM?= =?us-ascii?Q?FnrCqDmI5j4ye23yOr3Qg3G6OR79pmK1tFmUW0FuZBpl9a/dUN5GCL+HFWUr?= =?us-ascii?Q?rCI=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c7b7e7e-09d2-408c-5a84-08d948691b4e X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jul 2021 14:50:51.5257 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6HaQzvyAh4pglyNx3v0yEPaHNU3rchK/gJrnDx3dYfWUhRnZ69vq5dOaABvkc3Zv X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6922 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: DD69F320034AF1EFE6BBCBBF6A6C6A9C886CEB7C5A1FF57FA50198229660BF702 X-Proofpoint-ORIG-GUID: OAedUXkVWeCzbzECYByhqSFz4zN6_eX8 X-Proofpoint-GUID: OAedUXkVWeCzbzECYByhqSFz4zN6_eX8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-16_05:2021-07-16, 2021-07-16 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 lowpriorityscore=0 bulkscore=0 malwarescore=0 spamscore=0 suspectscore=0 clxscore=1011 impostorscore=0 mlxlogscore=490 priorityscore=1501 mlxscore=0 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107160090 Archived-At: Subject: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 14:51:13 -0000 My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've = never seen this before. Is anyone else experiencing this, or experienced th= is in the past? Barbara From nobody Fri Jul 16 08:54:25 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580EB3A1044 for ; Fri, 16 Jul 2021 08:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltRXRq4P2FxB for ; Fri, 16 Jul 2021 08:54:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8B03A08FC for ; Fri, 16 Jul 2021 08:54:13 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16GFs9ml059492 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 16 Jul 2021 10:54:09 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626450850; bh=CdzKAzYDhYlIoWXo0vOWVt6QoZdsfviq6v6ztXQYGUk=; h=Subject:To:References:From:Date:In-Reply-To; b=dL2n9mcmUO8ORtQYW8iNdhFrvHRToaB4TAV4c6dHmmhwuSWXDHx2i4kwckDI6g8OF dAc5ULpUPviApyY+hqPkT9NbcZySjZTMusFxVZ7be3Fv9RdRwzSGEf4mJK1r8G+80P Uoszd7kmgsPqCDXDfqsf8s6HQpO3DDIN6uR2wgWw= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: "STARK, BARBARA H" , "'tools-discuss@ietf.org'" , Ryan Cross References: From: Robert Sparks Message-ID: Date: Fri, 16 Jul 2021 10:54:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 15:54:23 -0000 Hi Barbara - Your messages look intact to me both through imap.ietf.org and using https://mailarchive.ietf.org/arch/browse/dnssd/ If that looks right to you, perhaps you could forward the raw message you got from the list that didn't look right to both me and Ryan (copied)? RjS On 7/16/21 9:50 AM, STARK, BARBARA H wrote: > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've never seen this before. Is anyone else experiencing this, or experienced this in the past? > Barbara > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss From nobody Fri Jul 16 09:11:19 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF28D3A3C0D for ; Fri, 16 Jul 2021 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 hYNmknybTeKd for ; Fri, 16 Jul 2021 09:11:13 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87E03A3C0B for ; Fri, 16 Jul 2021 09:11:12 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BCC7A548056; Fri, 16 Jul 2021 18:11:05 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id B658F4E7A6D; Fri, 16 Jul 2021 18:11:05 +0200 (CEST) Date: Fri, 16 Jul 2021 18:11:05 +0200 From: Toerless Eckert To: "STARK, BARBARA H" Cc: "'tools-discuss@ietf.org'" Message-ID: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 16:11:18 -0000 Do you have an example date / message id of such an email ? Does the dnssd email archive have the email untruncated but only group members report that it was truncated on their end, or is it also truncated on the list archive ? I had once email recently from an AD via draft-alias and WG expander, which arrived truncated on my side, but made it untruncated to the WG alias. Alas, i have not been able to track thast one down, even through it was a mayor issue for me (AD review of one of my drafts that i received truncated. Imagine how i felt when the AD told me: why did you stop fixing nits after 25% of my review... ;-)) Cheers Toerless On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've never seen this before. Is anyone else experiencing this, or experienced this in the past? > Barbara > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss -- --- tte@cs.fau.de From nobody Fri Jul 16 09:19:26 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4C43A3C2F for ; Fri, 16 Jul 2021 09:19:24 -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 7H1iygIQ6Oye for ; Fri, 16 Jul 2021 09:19:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D223A3C31 for ; Fri, 16 Jul 2021 09:19:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 812A838A6C; Fri, 16 Jul 2021 12:22:24 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UOJLMY-xuD8R; Fri, 16 Jul 2021 12:22:21 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 567B238A67; Fri, 16 Jul 2021 12:22:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DB2A5407; Fri, 16 Jul 2021 12:19:15 -0400 (EDT) From: Michael Richardson To: "Martin Thomson" cc: tools-discuss@ietf.org In-Reply-To: <5391988e-7180-49d3-989b-3cf40e395408@www.fastmail.com> References: <5391988e-7180-49d3-989b-3cf40e395408@www.fastmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] Template repository for GitHub X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2021 16:19:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Thomson wrote: > Anyone who has setup a new GitHub repository for an Internet-Draft > knows that it can be a little tricky, particularly if you use the > toolchain I support. > Not any more. I've created a template repository that makes setup ve= ry > simple. Just create a new repository using the template, rename your > draft, enable GitHub Pages, and you are ready to go. So, as I understand it, this is just an empty git repo that github provides some sugar around it. I could equally well glone the template to my comput= er and git clone form there. > As always contributions and bug reports are welcome. I'd like to contribute a template for work with YANG models. That assumes I get my process working to my satisfaction first :-) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmDxsYMACgkQgItw+93Q 3WVoBAgAiXaTlLH3Z9GkUXvjpuOQuD7iomwmhP4xhhS7nJQ0Kd37hNvwVGQEa/DL fhL8CBtaStJz9wsgQxkZw5Mw3o9tA3Wp9v0RtWAxvazu7Azdz8ecUGcN+QPhyKpk 4hUIt5hkLAcbLIJeb7Ejxuw0VW+gzlLXrd7GrbLgw3eO0EcqWKIY13LVlRhltsu/ ZI3PxXBiJ3SGOocg0XE72IhznmW/S9dtfFojKjXr9YNHs4GaMJeJocQxCwISAznX yC6HMo+CNiWE8vdMvMOZzwHX+nL1/k7/n5AkvpG0tYBFOJMniMGS7p3y22tNNuQh nG5aVAFfmUBsRCI1xOQwZxAxefJODg== =V2cv -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 18 15:19:55 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2B03A1151; Sun, 18 Jul 2021 15:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 alogjGhiGWy6; Sun, 18 Jul 2021 15:19:44 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id D7CE03A114E; Sun, 18 Jul 2021 15:19:43 -0700 (PDT) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_855F8F67-DF6E-4E34-8B30-ABC1923DB2D7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Mon, 19 Jul 2021 10:19:40 +1200 In-Reply-To: <20210713201429.5881D2150B1F@ary.qy> Cc: GENDISPATCH List , tools-discuss@ietf.org To: John Levine References: <20210713201429.5881D2150B1F@ary.qy> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Tools-discuss] [Gendispatch] Updating the IETF Discussion List Charter (was: Fwd: New Version Notification for draft-eggert-bcp45bis-02.txt) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 22:19:50 -0000 --Apple-Mail=_855F8F67-DF6E-4E34-8B30-ABC1923DB2D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 When it comes to letting people select the information that they want to = get notified about, the concept of a list such as ietf-announce is = perhaps a bit out of date. Nowadays people simply use a form to say, I = want this, this and that delivered to this mailbox and that to that = mailbox and none of that please. Behind the scenes this would probably = best be implemented with API populated Mailman lists and possibly topics = and I=E2=80=99m sure people would want the from address to be stay as = ietf-announce@ietf.org , but it might = actually be several lists in the background. Jay > On 14/07/2021, at 8:14 AM, John Levine wrote: >=20 > It appears that Lars Eggert said: >> On 2021-7-13, at 1:50, Eric Rescorla wrote: >>> With that said, there's no reason to be locked into the = "one-size-fits-all" mailing list paradigm for this kind of automatic = notification. Unlike ietf@, the number of people >> who send mail to ietf-announce is very small, so we don't really need = to have it as a simple mailing list. Instead, what I would suggest is = that we modify the automatic >> notification system to allow people to customize which notifications = they want to receive (they can still allo appear to go to the same list, = which could even be called >> ietf-announce if we want). That way, people can easily filter on the = server side and get just the subset they care about. [0] >>>=20 >>> -Ekr >>>=20 >>> [0] We can of course still build an archive that has every = announcement. >>=20 >> I like this idea. Would this need to result in new custom datatracker = code, or is there a third-party service that could be leveraged? >>=20 >> (This part of the discussion should also probably move to = tools-discus.) >=20 > You really, REALLY, do not want to try to reinvent a bulk mail system. >=20 > GNU Mailman has a little-used "topics" feature that I think can do the = trick here. The list manager configures > a set of topic regexps for the list, and subscribers can say which = topics they want. In each message the topic(s) > appear in the Subject or Keywords line and it sends the message to the = people subscribed to the topics. If you don't > pick any topics, by default you get all of them. >=20 > See https://www.gnu.org/software/mailman/mailman-member/node29.html >=20 > The interface within mailman to set the topics is pretty grody, but I = presume it just puts stuff in the underlying > database so we could invent our own interface to it without extreme = pain. >=20 > R's, > John >=20 > PS: Some of us don't subscribe to any IETF lists but instead retrieve = the messages from the IMAP server, but I think we > can fend for ourselves. >=20 > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_855F8F67-DF6E-4E34-8B30-ABC1923DB2D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Jay

On 14/07/2021, at 8:14 AM, John = Levine <johnl@taugh.com> wrote:

It = appears that Lars Eggert  <lars@eggert.org> said:
On 2021-7-13, at 1:50, Eric Rescorla <ekr@rtfm.com> wrote:
With that said, there's = no reason to be locked into the "one-size-fits-all" mailing list = paradigm for this kind of automatic notification. Unlike ietf@, the = number of people
who send mail to = ietf-announce is very small, so we don't really need to have it as a = simple mailing list. Instead, what I would suggest is that we modify the = automatic
notification system to allow people to customize = which notifications they want to receive (they can still allo appear to = go to the same list, which could even be called
ietf-announce if we want). That way, people can easily filter = on the server side and get just the subset they care about. [0]

-Ekr

[0] We can of course still build an archive = that has every announcement.

I = like this idea. Would this need to result in new custom datatracker = code, or is there a third-party service that could be leveraged?

(This part of the discussion should also = probably move to tools-discus.)

You really, REALLY, do not want to try to reinvent a bulk = mail system.

GNU Mailman has a little-used = "topics" feature that I think can do the trick here.  The list = manager configures
a set of topic regexps for the list, = and subscribers can say which topics they want.  In each message = the topic(s)
appear in the Subject or Keywords line and it = sends the message to the people subscribed to the topics.  If you = don't
pick any topics, by default you get all of them.

See https://www.gnu.org/software/mailman/mailman-member/node29.html=

The interface within mailman to set = the topics is pretty grody, but I presume it just puts stuff in the = underlying
database so we could invent our own interface = to it without extreme pain.

R's,
John

PS: Some of us don't = subscribe to any IETF lists but instead retrieve the messages from the = IMAP server, but I think we
can fend for ourselves.

___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for = discussion, not for action requests or bug reports.
* = Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other = bugs or issues to: ietf-action@ietf.org
List info (including = how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss


-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_855F8F67-DF6E-4E34-8B30-ABC1923DB2D7-- From nobody Sun Jul 18 15:22:15 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DED3A116A for ; Sun, 18 Jul 2021 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=mccAYI4K; dkim=pass (2048-bit key) header.d=taugh.com header.b=TykekXVJ 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 QCxE3-_zTILC for ; Sun, 18 Jul 2021 15:22:07 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033203A1165 for ; Sun, 18 Jul 2021 15:22:06 -0700 (PDT) Received: (qmail 77294 invoked from network); 18 Jul 2021 22:22:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=12deb.60f4a98d.k2107; bh=lXchAQhl2xSnyzeddk7eHDPO58Ko6kAIXE6NUwI3+iY=; b=mccAYI4Kc0t/9Pwt2cGH4NAuDlPF9Xb3kc7PxWG7FnZUHf/BtfyoXiueuvv8g5XNm/xQRRX+ptEQGJjQa/KUR6mvPws4SWFUiQ/OSZ19hdbfHIJRXcMx15+kEREGSrprJjIRTVvs68z9XHnXIEaKBx6QpUwn0y7+q6Z6VPwwgAXr8mBTtiRXaATRWj1e+qhlZJnvCgREKC/FW6PuHSQ/TGUUuT/1CGaebCDBnHdxJtrIEuMRQDnaDBo5zAteBfaboMPnsr4r1HoXak19fbRfDufKoKWl9TvUmRQ1w/FGBUVV/BlOBXGzaboRIwoO1CHl5rwC4qnswvwLdHr9lkgf9w== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=12deb.60f4a98d.k2107; bh=lXchAQhl2xSnyzeddk7eHDPO58Ko6kAIXE6NUwI3+iY=; b=TykekXVJlvB3lndpfF7AK281DUXvQtyHxZMZtu+5iJ40D6ryq+4iUqN3VrFHm8obBiZpsdWnvbQy3AdAMi5kX9CpwHyMq8keag/UqdCEQeraLm+T4SxhxNQBcr1JSe9jHlM2H6BBiX6Z8Hw2kOjnhR45hKbzLYMsdTvsvjtVHrwrN+pdgh+GZA2mDuhQYMxYDeKnr3oZ1PzrGQGkWvFUzNQjgjPbGmVXCc7tJCXxnd7gD4jfh0fAoxmR9miMsZR0K8bg/RZqa5v7Mak7AoWzaWGIRWlRJMqYelMBdI7iG+6n7ZYLHeDjUrE87n3eOMqBoxS5UZbYWCH4bZGtRo/sAg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 18 Jul 2021 22:22:05 -0000 Received: by ary.qy (Postfix, from userid 501) id 21BA724B2753; Sun, 18 Jul 2021 18:22:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 75F4924B2735; Sun, 18 Jul 2021 18:22:03 -0400 (EDT) Date: 18 Jul 2021 18:22:03 -0400 Message-ID: <21788991-7b7-d172-b325-5ab0e167ee6c@taugh.com> From: "John R Levine" To: "Jay Daley" Cc: "GENDISPATCH List" , tools-discuss@ietf.org X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210713201429.5881D2150B1F@ary.qy> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1249114230-1626646923=:15698" Archived-At: Subject: Re: [Tools-discuss] [Gendispatch] Updating the IETF Discussion List Charter (was: Fwd: New Version Notification for draft-eggert-bcp45bis-02.txt) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2021 22:22:13 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1249114230-1626646923=:15698 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > When it comes to letting people select the information that they want to get notified about, the concept of a list such as ietf-announce is perhaps a bit out of date. Nowadays people simply use a form to say, I want this, this and that delivered to this mailbox and that to that mailbox and none of that please. Behind the scenes this would probably best be implemented with API populated Mailman lists and possibly topics and I’m sure people would want the from address to be stay as ietf-announce@ietf.org , but it might actually be several lists in the background. That's certainly a reasonable way to do it. To minimize mysterious side effects in the mail archive and IMAP server, I'd do it with an API that adjusts the topics in one list and leave the lower level stuff alone. I don't think that would be very hard. R's, John >> On 14/07/2021, at 8:14 AM, John Levine wrote: >> >> It appears that Lars Eggert said: >>> On 2021-7-13, at 1:50, Eric Rescorla wrote: >>>> With that said, there's no reason to be locked into the "one-size-fits-all" mailing list paradigm for this kind of automatic notification. Unlike ietf@, the number of people >>> who send mail to ietf-announce is very small, so we don't really need to have it as a simple mailing list. Instead, what I would suggest is that we modify the automatic >>> notification system to allow people to customize which notifications they want to receive (they can still allo appear to go to the same list, which could even be called >>> ietf-announce if we want). That way, people can easily filter on the server side and get just the subset they care about. [0] >>>> >>>> -Ekr >>>> >>>> [0] We can of course still build an archive that has every announcement. >>> >>> I like this idea. Would this need to result in new custom datatracker code, or is there a third-party service that could be leveraged? >>> >>> (This part of the discussion should also probably move to tools-discus.) >> >> You really, REALLY, do not want to try to reinvent a bulk mail system. >> >> GNU Mailman has a little-used "topics" feature that I think can do the trick here. The list manager configures >> a set of topic regexps for the list, and subscribers can say which topics they want. In each message the topic(s) >> appear in the Subject or Keywords line and it sends the message to the people subscribed to the topics. If you don't >> pick any topics, by default you get all of them. >> >> See https://www.gnu.org/software/mailman/mailman-member/node29.html >> >> The interface within mailman to set the topics is pretty grody, but I presume it just puts stuff in the underlying >> database so we could invent our own interface to it without extreme pain. >> >> R's, >> John >> >> PS: Some of us don't subscribe to any IETF lists but instead retrieve the messages from the IMAP server, but I think we >> can fend for ourselves. >> >> ___________________________________________________________ >> Tools-discuss mailing list - Tools-discuss@ietf.org >> This list is for discussion, not for action requests or bug reports. >> * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org >> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >> * Report all other bugs or issues to: ietf-action@ietf.org >> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss >> > > Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1249114230-1626646923=:15698-- From nobody Mon Jul 19 08:08:48 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A473A371E for ; Mon, 19 Jul 2021 08:08:35 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 NUor_htoc3Ln for ; Mon, 19 Jul 2021 08:08:31 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47BFA3A36FB for ; Mon, 19 Jul 2021 08:08:31 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 31330548056; Mon, 19 Jul 2021 17:08:24 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 2B7484E7AB4; Mon, 19 Jul 2021 17:08:24 +0200 (CEST) Date: Mon, 19 Jul 2021 17:08:24 +0200 From: Toerless Eckert To: "'tools-discuss@ietf.org'" Message-ID: <20210719150824.GA62005@faui48e.informatik.uni-erlangen.de> References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Tools-discuss] Email error report... to whom ? Re: emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 15:08:47 -0000 What is actually the right place to raise email error issues ? I just received the following email error back for email to nomcomi-2021@ietf.org: This is the mail system at host ietfa.amsl.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : Command died with status 1: "/a/www/ietf-datatracker/web/ietf/virtualenv-manage.py feedback_email --nomcom-year 2021". Command output: CommandError: 'utf-8' codec can't decode byte 0xb7 in position 114: invalid start byte Cheers Toerless On Fri, Jul 16, 2021 at 06:11:05PM +0200, Toerless Eckert wrote: > Do you have an example date / message id of such an email ? > > Does the dnssd email archive have the email untruncated but only group members > report that it was truncated on their end, or is it also truncated on the > list archive ? > > I had once email recently from an AD via draft-alias and WG expander, > which arrived truncated on my side, but made it untruncated to > the WG alias. > > Alas, i have not been able to track thast one down, even > through it was a mayor issue for me (AD review of one of my drafts > that i received truncated. Imagine how i felt when the AD told me: > why did you stop fixing nits after 25% of my review... ;-)) > > Cheers > Toerless > > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've never seen this before. Is anyone else experiencing this, or experienced this in the past? > > Barbara > > > > ___________________________________________________________ > > Tools-discuss mailing list - Tools-discuss@ietf.org > > This list is for discussion, not for action requests or bug reports. > > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > * Report all other bugs or issues to: ietf-action@ietf.org > > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Mon Jul 19 08:18:08 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF123A372C for ; Mon, 19 Jul 2021 08:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTcr_UhCwDLG for ; Mon, 19 Jul 2021 08:18:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 453623A372A for ; Mon, 19 Jul 2021 08:17:55 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16JFHaHp006876 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Jul 2021 10:17:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626707857; bh=oFHXA/XuyCmAsVJaBtjeKzcC1rtrUJrbOotTeUbUcQU=; h=Subject:To:References:From:Date:In-Reply-To; b=K1YVwelGr1KGVw34J04fRecmsk1X3C6J5WtChtcKGIdOSu9X/fJJLueVgea4n0Jw1 F4WA6vcjuc8UMiFFLPLjWa7frUrzv0mXtZkBr2S/5sAFVtz7sEoZpT9pyKexJ+bGzm k7MwbKzzwVieRKjGOAwAspKzK6tAy4vDbEAxk3Yk= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: Toerless Eckert , "'tools-discuss@ietf.org'" References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> <20210719150824.GA62005@faui48e.informatik.uni-erlangen.de> From: Robert Sparks Message-ID: <10b650d6-5fe8-ca20-82ff-0e6d423ffe24@nostrum.com> Date: Mon, 19 Jul 2021 10:17:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20210719150824.GA62005@faui48e.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Email error report... to whom ? Re: emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2021 15:18:07 -0000 support@ietf.org would be appropriate for this kind of failure. I've forwarded this one there already, and will follow up with you individually. RjS On 7/19/21 10:08 AM, Toerless Eckert wrote: > What is actually the right place to raise email error issues ? > > I just received the following email error back > for email to nomcomi-2021@ietf.org: > > This is the mail system at host ietfa.amsl.com. > I'm sorry to have to inform you that your message could not > be delivered to one or more recipients. It's attached below. > > For further assistance, please send mail to postmaster. > > If you do so, please include this problem report. You can > delete your own text from the attached returned message. > > The mail system > > : Command died with status 1: "/a/www/ietf-datatracker/web/ietf/virtualenv-manage.py feedback_email --nomcom-year 2021". Command output: CommandError: 'utf-8' codec can't decode byte 0xb7 in position 114: invalid start byte > > > Cheers > Toerless > > On Fri, Jul 16, 2021 at 06:11:05PM +0200, Toerless Eckert wrote: >> Do you have an example date / message id of such an email ? >> >> Does the dnssd email archive have the email untruncated but only group members >> report that it was truncated on their end, or is it also truncated on the >> list archive ? >> >> I had once email recently from an AD via draft-alias and WG expander, >> which arrived truncated on my side, but made it untruncated to >> the WG alias. >> >> Alas, i have not been able to track thast one down, even >> through it was a mayor issue for me (AD review of one of my drafts >> that i received truncated. Imagine how i felt when the AD told me: >> why did you stop fixing nits after 25% of my review... ;-)) >> >> Cheers >> Toerless >> >> On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: >>> My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've never seen this before. Is anyone else experiencing this, or experienced this in the past? >>> Barbara >>> >>> ___________________________________________________________ >>> Tools-discuss mailing list - Tools-discuss@ietf.org >>> This list is for discussion, not for action requests or bug reports. >>> * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org >>> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >>> * Report all other bugs or issues to: ietf-action@ietf.org >>> List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss >> -- >> --- >> tte@cs.fau.de From nobody Tue Jul 20 00:26:44 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1A3A1605 for ; Tue, 20 Jul 2021 00:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.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 Los-tMlFP4hh for ; Tue, 20 Jul 2021 00:26:37 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 A8E0C3A1610 for ; Tue, 20 Jul 2021 00:26:37 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 5EF9C60035D for ; Tue, 20 Jul 2021 10:26:30 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1626765990; bh=QxLGk/6TYjUJZIohy/iXXNSaFFdlDELU26s2JtaJPzY=; h=From:Subject:Date:To; b=uhQ1cj026Ez+JrsMhzLAJEJfWytzqNx7MFrE1yS7TRfi+7+XMcA/YKK2JE6uMY6Qv IdO+f+cfAGmHdOe16/sYcEtw60UQZoP4HjHUpaj+Kjov3d8uLsPEfPmqbM2EydTydZ Sg5RUnRO9wNZ5w6oJq6GLn1yyXXxDj/A9BZ3daNg= From: Lars Eggert Content-Type: multipart/signed; boundary="Apple-Mail=_7C13CAB1-89E7-4CA8-97B2-A2365BF9EFA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <095668BD-93B7-42A9-8F04-8EC53D5D4E99@eggert.org> Date: Tue, 20 Jul 2021 10:26:29 +0300 To: Tools Team Discussion X-MailScanner-ID: 5EF9C60035D.A3D30 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 07:26:43 -0000 --Apple-Mail=_7C13CAB1-89E7-4CA8-97B2-A2365BF9EFA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, amI correct in my understanding that rfc-editor.org mailing lists don't = add "Archived-At" headers? Could we add that? Also, are there any other = lists that "we" host that don't add "Archived-At" headers? Thanks, Lars PS: I also see that rfc-editor.org mailing lists are not searchable via = mailarchive. That also seems like a feature we'd want. --Apple-Mail=_7C13CAB1-89E7-4CA8-97B2-A2365BF9EFA7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmD2eqUACgkQVLXDCb9w wVcyixAAocliH//zckHpNL/5k30K+u8WY1/rSLM+XDCKxZKZFMFmVr0bsAPUI/iw Sh47oSahVuryKg5kT7GZfnKyZhjd4Z5WiWaAK9a3jDIJihjyOLf+gYCdRiXF+Qsh JIbfSft2aZP87ZrhLa9F25CBpTF7fyEVIx/Bc0h1ORTCkBdL5nQ54MDHmUODEzI5 dKBNpJJq/485dVsZ6z0wy8iMiCDIVMhZWben4/YY0dtQchh2dyvlQCX8lKSxtNuK /TRczDim4k2j3CG1qZIMG/diYvNdxwtXsju3gt7CIHQgzqAhxmapGbeWUqlHuq+f za2o0ufeJQZ05wDD0nkMFBCO+x2Vs6Yto7iBsFvP+TYXPk13P/KIim95CtBwvlVK R4yiH1Shvns67G4CnBQM+rm7YysLN1SNqroALkI/QOzza8gKZZcQwBnQXcmBL/XF qWtHNXaJuHzCxNrw5Az1TPOGr+q0Op9oJfe8Qz2TP0QPitkz58mE2Lg0mXvp+hr7 J7/Su55g8AYRjTQ74v1nd8KQ9a0f6HvjyR/DKfNLsF3WShXlNDcndVAem5z3qJKw W/Qr9+tuzsqxx3hO9sqFGnlUR0gJ2LdeskMiOkUW+bGJimX/r/4AP7m39S2Qd8f0 EX9TW2Knybfb9bYSsZ1C8c1qx22vlvtxWR2iNfPyI9OQN+oCddY= =URav -----END PGP SIGNATURE----- --Apple-Mail=_7C13CAB1-89E7-4CA8-97B2-A2365BF9EFA7-- From nobody Tue Jul 20 13:56:12 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95EC3A31D9 for ; Tue, 20 Jul 2021 13:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.209 X-Spam-Level: X-Spam-Status: No, score=-104.209 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, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] 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 fGCmGg6O09lZ for ; Tue, 20 Jul 2021 13:56:05 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D813A31DB for ; Tue, 20 Jul 2021 13:56:05 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 40DB5389F3F for ; Tue, 20 Jul 2021 13:56:05 -0700 (PDT) Received: from Z301 (unknown [IPv6:2603:3024:1507:36a0:b4b4:2647:24f4:613f]) by c8a.amsl.com (Postfix) with ESMTPSA id 2EF5F389EFA for ; Tue, 20 Jul 2021 13:56:05 -0700 (PDT) From: "Glen" To: Date: Tue, 20 Jul 2021 13:56:03 -0700 Message-ID: <000d01d77da9$a7b745b0$f725d110$@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: Add9pTbf+PzAYkB1SOijlYXHU1LQ3A== Content-Language: en-us Archived-At: Subject: Re: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 20:56:11 -0000 Hello Lars - I haven't seen any replies, so, speaking only as the operator for both the IETF and the RFC-Editor, I will try to answer those questions for you. > From: Lars Eggert > Subject: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? > Am I correct in my understanding that rfc-editor.org mailing lists don't add > "Archived-At" headers? You are correct. > Also, are there any other lists that "we" host that don't add "Archived-At" headers? No, there are no lists we (the IETF) host that don't add those headers. The IETF currently hosts all of its list on its central server grid, across several domains, and they all have that header added. In the case of the IETF, the Archived-At headers are added as one of the many functions of the IETF's custom Postconfirm program, which interfaces with the IETF's custom Mail Archive tool. Both of those tools are IETF-owned products, and deployed on the IETF servers, providing those custom features to the IETF and the lists it runs. (As an aside, the IETF also provides "mirrors" of some external lists' archives, wherein we are not the primary provider of the list, but our archive system is just "subscribed" to that external list as a member. Those messages do not have the Archived-At header added to them, because the list messages come from an external source, and feed directly into the IETF Mail Archive, without actually being "processed" by the IETF mail chain.) But "We the IETF" don't actually host the RFC Editor mailing lists. Those lists are hosted on the RFC-Editor's servers, and are used by the Editor staff, and operated by the RFC-Editor. The custom systems used by the IETF are not deployed on or used by the RFC-Editor's servers in any way. The RFC-Editor deployment is just a "normal" Mailman instance, with the normal Mailman archives. > Could we add that? Anything is possible given appropriate circumstances, and there are different approaches we could take. I believe that the primary concerns are keeping the RFC-Editor's systems severable, and not disrupting the operations of the RFC Production Center or their staff. With that in mind, one approach might be to develop custom code for the RFC-Editor Mailman instance which would put a more-or-less generic Archived-At header into the messages that go through the list. As a simple example, an Archived-at header could be added which points to the monthly index for the message, as in https://www.rfc-editor.org/pipermail/rfc-interest/2021-July/ . That would require, I guess, an RFP from the IETF? RFC-Editor?, and could be deployed (I would hope) in a reasonably non-invasive way to the RFC-Editor servers. Other approaches no doubt exist, but this would be the simplest one I could think of. > PS: I also see that rfc-editor.org mailing lists are not searchable via > mailarchive. That also seems like a feature we'd want. I'm given to understand that the primary public lists, RFC-DIST, and RFC-INTEREST, should be searchable. They are certainly browse-able, at https://mailarchive.ietf.org/arch/browse/rfc-dist/ and https://mailarchive.ietf.org/arch/browse/rfc-interest/ . For those, we took the same approach we took with other external lists, and we just do an external feed into the IETF Mail Archive. The primary archives are, of course, still on the RFC-Editor server, but the IETF Mail Archive does have the full copies available as shown above. If there are other lists that the RFC-Editor wants to share across, setting that up would be trivial. I hope this information is helpful, please feel free to contact me directly if you have any additional questions, and I will always do whatever I can to assist! Glen -- Glen Barney IT Director AMS (IETF and RPC Secretariat) From nobody Tue Jul 20 14:52:32 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5E03A33BE for ; Tue, 20 Jul 2021 14:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX2KKyt2Yn8O for ; Tue, 20 Jul 2021 14:52:25 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B4A73A33BC for ; Tue, 20 Jul 2021 14:52:25 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16KLqKZ5061612 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 20 Jul 2021 16:52:21 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626817941; bh=Mh8ed2/SW/H4f84Q6YaDDF3b8NGPs4IplwjRh9oN90U=; h=To:References:From:Subject:Date:In-Reply-To; b=Ail9VqB08xwI+4Er1i37aFA4tAF1g42ZY4YIIAqwbeE1Xp/bVeu+JEXZkxKjLSZw/ WPIoi/dSeBZ37aNSfuNV+np0f23wixvLUDifPfzDb8mimvJxGrBkEOalUOI7eS5P44 V70JB+VS0sVOo5R/D1AmbpSTVeYod8bJdtRHtRj4= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: tools-discuss , Glen References: <000d01d77da9$a7b745b0$f725d110$@amsl.com> From: Robert Sparks Message-ID: <0b69c7ea-1107-293b-053f-d66e1e18383d@nostrum.com> Date: Tue, 20 Jul 2021 16:52:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <000d01d77da9$a7b745b0$f725d110$@amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 21:52:31 -0000 On 7/20/21 3:56 PM, Glen wrote: > Hello Lars - > > I haven't seen any replies, so, speaking only as the operator for both = the > IETF and the RFC-Editor, I will try to answer those questions for you. > >> From: Lars Eggert >> Subject: [Tools-discuss] rfc-editor.org mailing lists don't add > "Archived-At"? >> Am I correct in my understanding that rfc-editor.org mailing lists don= 't > add >> "Archived-At" headers? > You are correct. > >> Also, are there any other lists that "we" host that don't add > "Archived-At" headers? > > No, there are no lists we (the IETF) host that don't add those headers.= The > IETF currently hosts all of its list on its central server grid, across= > several domains, and they all have that header added. In the case of t= he > IETF, the Archived-At headers are added as one of the many functions of= the > IETF's custom Postconfirm program, which interfaces with the IETF's cus= tom > Mail Archive tool. Both of those tools are IETF-owned products, and > deployed on the IETF servers, providing those custom features to the IE= TF > and the lists it runs. > > (As an aside, the IETF also provides "mirrors" of some external lists' > archives, wherein we are not the primary provider of the list, but our > archive system is just "subscribed" to that external list as a member. > Those messages do not have the Archived-At header added to them, becaus= e the > list messages come from an external source, and feed directly into the = IETF > Mail Archive, without actually being "processed" by the IETF mail chain= =2E) > > But "We the IETF" don't actually host the RFC Editor mailing lists. Th= ose > lists are hosted on the RFC-Editor's servers, and are used by the Edito= r > staff, and operated by the RFC-Editor. The custom systems used by the= IETF > are not deployed on or used by the RFC-Editor's servers in any way. T= he > RFC-Editor deployment is just a "normal" Mailman instance, with the nor= mal > Mailman archives. Are there any other sets of mailing lists in the halo of=20 domains/services that someone might expect to be accessible via the=20 imap/mailarchive interfaces that currently aren't? I think all of the IAB and IRTF lists are available. What's missing=20 other than the rfc-editor lists? > >> Could we add that? > Anything is possible given appropriate circumstances, and there are > different approaches we could take. I believe that the primary concer= ns > are keeping the RFC-Editor's systems severable, and not disrupting the > operations of the RFC Production Center or their staff. > > With that in mind, one approach might be to develop custom code for the= > RFC-Editor Mailman instance which would put a more-or-less generic > Archived-At header into the messages that go through the list. As a si= mple > example, an Archived-at header could be added which points to the month= ly > index for the message, as in > https://www.rfc-editor.org/pipermail/rfc-interest/2021-July/ . That w= ould > require, I guess, an RFP from the IETF? RFC-Editor?, and could be depl= oyed > (I would hope) in a reasonably non-invasive way to the RFC-Editor serve= rs. > > Other approaches no doubt exist, but this would be the simplest one I c= ould > think of. > >> PS: I also see that rfc-editor.org mailing lists are not searchable vi= a >> mailarchive. That also seems like a feature we'd want. > I'm given to understand that the primary public lists, RFC-DIST, and > RFC-INTEREST, should be searchable. They are certainly browse-able, at= > https://mailarchive.ietf.org/arch/browse/rfc-dist/ and > https://mailarchive.ietf.org/arch/browse/rfc-interest/ . For those, w= e > took the same approach we took with other external lists, and we just d= o an > external feed into the IETF Mail Archive. The primary archives are, of= > course, still on the RFC-Editor server, but the IETF Mail Archive does = have > the full copies available as shown above. If there are other lists th= at > the RFC-Editor wants to share across, setting that up would be trivial.= > > I hope this information is helpful, please feel free to contact me dire= ctly > if you have any additional questions, and I will always do whatever I c= an to > assist! > > Glen > -- > Glen Barney > IT Director > AMS (IETF and RPC Secretariat) > > > > > > > > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.= org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/= listinfo/tools-discuss From nobody Tue Jul 20 15:05:30 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4341A3A3418 for ; Tue, 20 Jul 2021 15:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.209 X-Spam-Level: X-Spam-Status: No, score=-104.209 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, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] 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 zXIfQYBLlNv1 for ; Tue, 20 Jul 2021 15:05:24 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 894B33A3416 for ; Tue, 20 Jul 2021 15:05:24 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 34E5A389EBF for ; Tue, 20 Jul 2021 15:05:24 -0700 (PDT) Received: from Z301 (unknown [IPv6:2603:3024:1507:36a0:b4b4:2647:24f4:613f]) by c8a.amsl.com (Postfix) with ESMTPSA id 17830389EBB for ; Tue, 20 Jul 2021 15:05:24 -0700 (PDT) From: "Glen" To: "'tools-discuss'" References: <000d01d77da9$a7b745b0$f725d110$@amsl.com> <0b69c7ea-1107-293b-053f-d66e1e18383d@nostrum.com> In-Reply-To: <0b69c7ea-1107-293b-053f-d66e1e18383d@nostrum.com> Date: Tue, 20 Jul 2021 15:05:23 -0700 Message-ID: <000701d77db3$568c6b20$03a54160$@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQNmwm3u9zAJqJBJ5Rd1OzKiiJhI6AFJHCh+qCOYKTA= Archived-At: Subject: Re: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 22:05:29 -0000 Hi - Not sure if this was for me, apologies if not, but I wouldn't want to = ignore if it was :-) so: > Are there any other sets of mailing lists in the halo of > domains/services that someone might expect to be accessible via the > imap/mailarchive interfaces that currently aren't? > I think all of the IAB and IRTF lists are available. What's missing > other than the rfc-editor lists? To my knowledge, nothing. But I would not consider the RPC lists to be = in that halo, so there may be other things "out there" that I'm not = aware of. For all the things I manage and am aware of, nothing should be missing. Glen From nobody Tue Jul 20 15:16:39 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E0F3A3467 for ; Tue, 20 Jul 2021 15:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.08 X-Spam-Level: X-Spam-Status: No, score=-2.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND-59W0Po55P for ; Tue, 20 Jul 2021 15:16:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491633A3468 for ; Tue, 20 Jul 2021 15:16:31 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16KMGOK4066344 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 20 Jul 2021 17:16:25 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1626819385; bh=cByxR1mzz/d6quriVz9AOfA942l0+9niUZXybmb9H1k=; h=To:References:From:Subject:Date:In-Reply-To; b=eLHrq5tIdhPKLVEA7KfBOoqgZXQyuZ2iD3jP8iEVcXs4hGHJkvC15fEG1oOrIEHhi p1kAScgcslRlrbZPiUWCab/nFjlFV6+w43Olk+ZIPed5iolCovoOWpCDgHjBPdaOzs ro0Sqqhyux1qqzz75rM3+pHZeofbeozBp1/YYzDg= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: Martin Thomson , tools-discuss@ietf.org References: <5391988e-7180-49d3-989b-3cf40e395408@www.fastmail.com> From: Robert Sparks Message-ID: Date: Tue, 20 Jul 2021 17:16:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <5391988e-7180-49d3-989b-3cf40e395408@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Template repository for GitHub X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 22:16:38 -0000 Martin - I tried to pretend I didn't know anything about IDs and started a new=20 draft using this template, making some notes along the way. I'll share=20 them here before they're lost. I don't think any of the points are quite = cooked enough to go in as Issues, but if so, feel free to just transcode = them or tell me to do so. * A new person won't know about the -latest convention. Something should = be really obvious in the startup that tells them to leave that part of=20 the name alone (maybe as a comment block in the template?) * Is it possible to have an initial workflow that asks the new author=20 for the draft name and target wg at least and does the initial=20 alteration of the template md for them, waiting to start the other=20 actions (that would build that md) until that's already been done? * Something that made it quickly clear what the stuff (kramdown-2629=20 input) in the .md template is would help - I think a complete new person = won't be able to find that soon enough to not walk away * The enabling github pages step is not intuitive to github newbies. I=20 don't know if there's enough control that an action could do that for=20 them? (maybe that's on the other side of "get an api key"). If not,=20 perhaps the documentation example could show the place they should touch = in the default theme, and maybe words-circles-and-arrows to help with=20 the handholding. * The run fail messages are really going to scare someone new (to=20 github) away. Maybe the above suggestion can help people avoid them. * Would it be useful to start a "something broke, how do I fix it" FAQ?=20 For instance, when I tried, the submission window was closed, so=20 creating a release led to an expected failure. I've done this enough to=20 know that I can delete that release and try to make another one when the = window opens, but I don't think someone new would know to try that?=20 Maybe the submission step could delete the release for them if the API=20 returns an error? (Won't help for the "some other author cancelled the=20 submission" possibility). * I wonder when we should abstract the template examples away from real=20 people? (Has Hannes ever had to reject (or otherwise chase) something he = wasn't actually invovled in?) * It will take someone awhile to find .note.xml and know what to do with = it. The setup for a non-wg submission isn't obvious - maybe it could be=20 made simpler for a complete newcomer? RjS On 7/15/21 10:14 PM, Martin Thomson wrote: > Hey, > > Anyone who has setup a new GitHub repository for an Internet-Draft know= s that it can be a little tricky, particularly if you use the toolchain I= support. > > Not any more. I've created a template repository that makes setup very= simple. Just create a new repository using the template, rename your dr= aft, enable GitHub Pages, and you are ready to go. > > You can run all of this from the web UI that GitHub provides. That inc= ludes publishing drafts to datatracker, which is done by creating a relea= se[*]. > > Some credit here is owed to Mallory Knodel for complaining loudly enoug= h about how unfriendly this whole setup was and motivating me to spend a = couple of hours on finally doing this. > > Documentation here: > https://github.com/martinthomson/i-d-template/blob/main/doc/TEMPLATE.md= > > As always contributions and bug reports are welcome. > > Cheers, > Martin > > [*] This bit isn't completely tested yet, I'll confess. > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.= org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/= listinfo/tools-discuss From nobody Tue Jul 20 19:35:39 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B13A0D3A for ; Tue, 20 Jul 2021 19:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=IclRWWIv; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BOwpn/7/ 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 X296D492a7af for ; Tue, 20 Jul 2021 19:35:31 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40523A0D38 for ; Tue, 20 Jul 2021 19:35:30 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id A097E32001BB; Tue, 20 Jul 2021 22:35:29 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 20 Jul 2021 22:35:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=blFSkN8AhtGNQqQe9dQcjkNj300hBfM xBq8eXfkOyRQ=; b=IclRWWIvchR/bOWlTH3YmQyegH99acb0m6AdnmvBYd8FPql KX57NKMZgesVWrztXa5UUJZn9wSJ7N1zIpKyewuh6MIAxkipuObE+dsQ72gvC4F/ 6RjF99KSPgCe8M1IGhsQCOunmZbtPQ06tgDrWWw8O/U1Rz3dB6dBNoUptA51eEJF O8r357XABuGGLGv/zWveMsDD5DyHSmmUEvyjZo44UKynaXTYYqjuGDwOYnbPVMT4 qavw2C2IGQEtBb5YlEO0hKb2adAbOv+X9o0SNIyqwrYQl4U6O1CYs7mLj2/cGSxl sAJSEdVDcud2ye48RP3uGo2PQBMJOgruIaZHguw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=blFSkN 8AhtGNQqQe9dQcjkNj300hBfMxBq8eXfkOyRQ=; b=BOwpn/7/c1EgJ8f19Oz2LS MiaLZQx1Hi3GYmMJWzrCA3+tLHVQsrQ3nuFXYy5/tOyg0wYZa1Kea8Whvuvhg8Lo jp8/cBRObf+OvX03G2jazChIUJ2OKSxqx/e7eaGq87IHDgklQ4784xmMBCuYBd0e 1oJSQOX/v4N7sIQ94PE5dfIhchgG9ftuLWH+hyzmoWxKhsnNxboA5bjTJmhV21fO dY1VgSMTjrq/9rH6CwYRxmCJdyOgQrnwRdImeZccJQRhoSsgqUhK7t8OGohDechy dCNfGIE5ipyHSfaN8+FM1mCgP+R8I8b3jTwfErHgXK5eIege1lV/G24NaqY5INNA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrfeefgdehudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BC9583C0F5D; Tue, 20 Jul 2021 22:35:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b Mime-Version: 1.0 Message-Id: <1f1a792d-fb21-4f01-8c5a-107570757e08@www.fastmail.com> In-Reply-To: References: <5391988e-7180-49d3-989b-3cf40e395408@www.fastmail.com> Date: Wed, 21 Jul 2021 12:34:58 +1000 From: "Martin Thomson" To: "Robert Sparks" , tools-discuss@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Tools-discuss] Template repository for GitHub X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 02:35:38 -0000 Thanks for taking the time Robert. I'll see what can be done to improve the process, but there are some hard limits on what I can do here. Maybe there will be some tricks we can employ to get around those roadblocks over time; I'm still learning how this all works. On Wed, Jul 21, 2021, at 08:16, Robert Sparks wrote: > Martin - > > I tried to pretend I didn't know anything about IDs and started a new > draft using this template, making some notes along the way. I'll share > them here before they're lost. I don't think any of the points are quite > cooked enough to go in as Issues, but if so, feel free to just transcode > them or tell me to do so. > > * A new person won't know about the -latest convention. Something should > be really obvious in the startup that tells them to leave that part of > the name alone (maybe as a comment block in the template?) A comment block in the template seems like the right way to deal with this. I've done that. > * Is it possible to have an initial workflow that asks the new author > for the draft name and target wg at least and does the initial > alteration of the template md for them, waiting to start the other > actions (that would build that md) until that's already been done? Something like this might be possible, but in order to do something like that a lot of manual and awkward setup needs to be done first. For instance, you can't just run a GitHub Action without a bunch of prior setup (cloning a repository that contains the repository, creating a personal access token, installing that token as a secret in that repository). This is where I ended up. > * Something that made it quickly clear what the stuff (kramdown-2629 > input) in the .md template is would help - I think a complete new person > won't be able to find that soon enough to not walk away Yep, that's something a comment might help. > * The enabling github pages step is not intuitive to github newbies. I > don't know if there's enough control that an action could do that for > them? (maybe that's on the other side of "get an api key"). If not, > perhaps the documentation example could show the place they should touch > in the default theme, and maybe words-circles-and-arrows to help with > the handholding. I worked it out. If you "Include all branches" when creating the repository from the template, this step isn't needed. I've updated the instructions. > * The run fail messages are really going to scare someone new (to > github) away. Maybe the above suggestion can help people avoid them. Yeah, I'm aware of how bad it is, but this is one of the hard constraints I hit. I've deployed a trick (that should also allow the action to be used for people who just have drafts sitting in a repo) that will suppress one of those, but I can't do that for the others without a major rewrite and that's not feasible right now. I'll open an issue to track it. The fact that actions are effectively immutable (without user intervention from the command line) makes this a tough thing to manage. > * Would it be useful to start a "something broke, how do I fix it" FAQ? > For instance, when I tried, the submission window was closed, so > creating a release led to an expected failure. I've done this enough to > know that I can delete that release and try to make another one when the > window opens, but I don't think someone new would know to try that? > Maybe the submission step could delete the release for them if the API > returns an error? (Won't help for the "some other author cancelled the > submission" possibility). I've added something, but it will probably not be enough. BTW, thanks for testing releases; I wasn't 100% confident about that, but it sounds like it worked as expected. > * I wonder when we should abstract the template examples away from real > people? (Has Hannes ever had to reject (or otherwise chase) something he > wasn't actually invovled in?) I'll fix that. > * It will take someone awhile to find .note.xml and know what to do with > it. The setup for a non-wg submission isn't obvious - maybe it could be > made simpler for a complete newcomer? Not sure what you mean by non-wg submission here. If you mean that the output when the draft doesn't target a working group is poor, yes, that could be improved. Most people won't need to worry about this file, though they are free to just delete it. I've tweaked the construction slightly so it should appear to be less broken. From nobody Wed Jul 21 08:34:22 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8E23A1C1A for ; Wed, 21 Jul 2021 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJBvwy95Yz9n for ; Wed, 21 Jul 2021 08:34:07 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 0A4333A1C12 for ; Wed, 21 Jul 2021 08:34:06 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 16LFFVB7046197; Wed, 21 Jul 2021 11:33:53 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 39x6sp5yk0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jul 2021 11:33:52 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16LFXph2031604; Wed, 21 Jul 2021 11:33:51 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16LFXlKJ031553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jul 2021 11:33:48 -0400 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id 7C10E4016D69; Wed, 21 Jul 2021 15:33:47 +0000 (GMT) Received: from MISOUT7MSGEX2CF.ITServices.sbc.com (unknown [135.66.184.212]) by zlp27130.vci.att.com (Service) with ESMTP id 610F74016D68; Wed, 21 Jul 2021 15:33:47 +0000 (GMT) Received: from MISOUT7MSGED1AB.ITServices.sbc.com (135.66.184.208) by MISOUT7MSGEX2CF.ITServices.sbc.com (135.66.184.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 21 Jul 2021 11:33:46 -0400 Received: from MISOUT7MSGETA02.tmg.ad.att.com (144.160.12.220) by MISOUT7MSGED1AB.ITServices.sbc.com (135.66.184.208) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 21 Jul 2021 11:33:46 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.173) by edgeso2.exch.att.com (144.160.12.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 21 Jul 2021 11:33:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hq0/6v5eKSESs7/LH6zXQgRimILmk4gykXK0sJ4nh7dz8BYidgpWmrJvYXa/1UmYB39plwFBZZVX0qcg3KsZl2hQ5KPOOYSFflQcXo+yQ3EZbZOaDMbsp87Pa68CIdyMdHEQFyZXYvw9C1QfRa7me1H3NdjCcTwMhKievLJg+BelXYC8AdBHaxwRyZs/btupY2z7JMOXywd5QK0dE4JKCgANw6ykvoxiip95N3Ha97b8Q0iHTSUtZNGehykFAckR9fYcLto/x7x00ySsmzFV4CjcjxDvMg9YPk0PbxXuXn+bkx5swUdYmsVnj4PhuRvvlZn9Tz26E6M11m3WO5Mswg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y25wXhg11ByNlmkDwLVfMsbR84c90wxapkTPSo89cgg=; b=WmLULssE7wOzhcefOXC8ZyK0dgzMiA2fTIKI5rhTSlG7LkN/uLgmasgE/IwiGnAiaXuJ0/Se1Gt2RDaNbVtYr2cFpQnKTnmwU7VtM/V/Z++nNzcNv6Ao6aEwDXsz8PsUQIJDDlRoRKdxcF/eq7E8yBqcCo3CyBrc1lmEjG2AEjnRgxlvFsrju8CYQOWAbrw5ENI4WkgYILRPxYKB58l48jqc59RA1qbj0iAup4PcUfvWOGkSrnSnte6UqZ7/ab/t6WOGlR9A5EjjUBgwbOWwhHFITSPEewhEcp/0g1EeJAqGzCWnWfig716/45i3Od8DKFgWWPFMlcilgCUBpLTaBw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y25wXhg11ByNlmkDwLVfMsbR84c90wxapkTPSo89cgg=; b=B4P6zgxIAYGY7RYL938FbKdJOa7DbX1CsgtzSXSmHCWoSTDQuVNmr45QhxHksyYWbs7cov+XzdButT9/ywD0+Ho9vT2HHywqWQEQ2O7DFCoKl1VZIIvUNjOK6t3o2VoF/86znmSsD47HQfMHJkY+ZU9U5R/1tv4ro1xLEtfgOxM= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB5305.namprd02.prod.outlook.com (2603:10b6:5:48::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.25; Wed, 21 Jul 2021 15:33:35 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130%3]) with mapi id 15.20.4331.034; Wed, 21 Jul 2021 15:33:35 +0000 From: "STARK, BARBARA H" To: "'Toerless Eckert'" CC: "'tools-discuss@ietf.org'" Thread-Topic: [Tools-discuss] emails being truncated Thread-Index: Add6UW1BT3hnBbhrRzu9q3XpOkAMBAAC8CSAAPlG5LA= Date: Wed, 21 Jul 2021 15:33:35 +0000 Message-ID: References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> In-Reply-To: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 876add18-3707-46ad-fa0e-08d94c5ce7bc x-ms-traffictypediagnostic: DM6PR02MB5305: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 195xG8b7rMZo16jH6aIiwQTTmSsJFJxG6DWOfgAER4wQjzqK3D70Ac7uMnufvI1Ui/Tz1QXtlwAdB1I7Aidz49HyO9seA+Ra0SMfL0uVJOGIYfQk8Kt244onr6qA3sRxFkeIyhDqHCSQYBoH3hEJX1t8niGuPjvQq+zuZtY1dM74mZ4roP5iiwyazc+ZOfEPAR5Jsw3D39UdtMkaQqnQ3Bb530bP46fvcgWVVHNv9z10oueFql0+w2WKtGpvK1f9fV0XuUE9IED4lD4CCfVMi8jO9es2BWtN9HYFXs9NkuL/HihZPahnjjam63q0OEw/31qinLv/ncIzrIvo0w62RhDUVLk48KH7zcQWFun8IeX15Tgs3o4qC1M1tKqq/xgKjLOFUxZw+pccLKyDTrc9ZfRoZsAdWQa0a4qM7v14LpNfIA5oZhp1zEaoxIy0XSwnLOAe6VjIbs1jQUQwu1emn80Up8Ba4bovYZtSU8y5oiuSK4qnUu4PwLNC+H8YgZg15Jt//taNLUQ3ElNm7vKD/wPV/Nv6cv3j9vE/CueHIcMMgZgOqBynXmthwC+uzP5Fzz+IGE83Xb22HuD7zwqSHhdhc/VEmEtfC5FeZSPRYYeaANSbtFCm0OE5qsV36KEBN1LkvsAjAQsLTCEAiyxmpooLeKvgM8I2x2CVUS2/MKPp67QWN9nksZ6pJcXigv5V4iF8jXd1IQqY6XmSjtZniR7k/8o3hij8+eRqsZ3lpcZDvcomEImaHPLLVYNOTUW53/kOovxePXHAzUlQUb5wubkJKvRivDDs075+5jFlDoQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(5660300002)(26005)(7696005)(966005)(76116006)(8936002)(66556008)(71200400001)(33656002)(55016002)(66946007)(52536014)(122000001)(6506007)(316002)(6916009)(82202003)(38100700002)(2906002)(4326008)(66446008)(64756008)(66476007)(186003)(83380400001)(86362001)(9686003)(8676002)(478600001)(38070700004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?iA7N3VuGpT2KdJamrlCo8NQ/hNgDHT6A6jM3RslT6IZZdIp/zbcjALEtLUPt?= =?us-ascii?Q?TdcE7uCFOj1nxXPXE9cPkTruVQ1J+5Ll1C6qV8AVr+G4WuXAi/N6BHQvlyGF?= =?us-ascii?Q?e7x/E5ihBBSAAJjcs/ZbyEnYaYy3CU/gsEvVTobEY4d1pGteiiWiSe5puFBQ?= =?us-ascii?Q?mQNBxxzFYglwqYA8A3rgXljdCEcpLDww1n0Ehj3rzASArB2BVAMm7uoP8FNT?= =?us-ascii?Q?GNmnw7q4f+Frf+onoicMURVvAsnwgv+tfQdwGz1rn1BK0llJw05VV2TxCR2W?= =?us-ascii?Q?t5YCBGAGzROA8MZEu703gZh0t471PJDIxpxQu8v4RNSK0nRtHnWEZH+o9mZC?= =?us-ascii?Q?xH+/TJsnQVXXfIol7Ej/bzvr91zo+pQ/23cwUdchZsF7yuDi3N/RvRGMmfWq?= =?us-ascii?Q?bGyo6HHKzATnhb/uXLw92UzPRHj2tQU5koLIVqcZ9Qgb42a3Ulzv/Oucu6vC?= =?us-ascii?Q?hGhhO/oUoi177+GlUjJwPoyv2+A8jK1O60WHzAgrMUVZW8gWMaA6FWqDRZ7e?= =?us-ascii?Q?pcvzVWW4McLOtSL9kHkSDbIWtVgwwZXh2taURxzpv5uTmbDRH094ZlHcfl92?= =?us-ascii?Q?zvInB2moMfnlORqNDL3RIaUoL7YMEZCofwpFE572EFQr0pN9FMeimDKHXko+?= =?us-ascii?Q?WQTlPigSS+ZzwQR5+o0MYm2y7wnoRE2OZxaRGDtJIczUbeLgWh8Q3Hqi8a1r?= =?us-ascii?Q?z6zP2IJ7HrNXCUWbhSNxK44ipMMaf29YUdlIFX0mJPaxaQOk+4FYb+2Zg68R?= =?us-ascii?Q?A+fg7CcEcAlQ+roPVSh/dvZ0rj25zSSEv1qEV3lODJ9Ic6blJB6aeXO2jVm3?= =?us-ascii?Q?ffr9lEvzBO0kD7OYo17o6SG1+EM74xpsdbf7AY2nPszFIQy4e3OUbzLVj7UM?= =?us-ascii?Q?RxG+Ioe5pVfwp5dOj5pem0bs4UnStPrIs+dpQyTzxfai4CowuwWOCRGwbVrH?= =?us-ascii?Q?n9Ce8avYD/gCjaKuCO9NdSfPsMZiRyF6CuN2Sy174jObk153LCZbaaCeNtAU?= =?us-ascii?Q?/yRAICHG+FXn2N2tqJCGvaUgwfeq8TQGQOIx2OjQhgkAzBZWvpRZFYl3aam3?= =?us-ascii?Q?IhSZMkaPzwH9LsPfI8Fztqvqp91lrzGvOuaAkS0MGLRC5vDjLzfuIFiQuNOo?= =?us-ascii?Q?go8LYyiIu9acWUPmcnlDsvRtxIdZECh0kNagEnhfpf/aResIxyjYMFFH0QJD?= =?us-ascii?Q?2C0JsddAVGTelVJM3hHwVXL5ELoTtIdWArfcZZYyOsZII41S6wrVFu7SpjIg?= =?us-ascii?Q?DfmmS6/pRFt8EQutlTlMQ3dzhV6JqqVXR0TxQoBVW7P/Qu1kWpgfxMjacQM6?= =?us-ascii?Q?Mdw=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 876add18-3707-46ad-fa0e-08d94c5ce7bc X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 15:33:35.7642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8trNwlJuszzulHAWif+KN2TVf+vV3WGobCtQQpDWpbKhn4vmymGjSvL/mfTsmNEN X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB5305 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: 32EEED66AC7183CF65CB48D3BD4809B801FC0A19C5A8542D20EEE436F1E1FC5D2 X-Proofpoint-GUID: niOiANT-Il8wNjrIzEHQ38JXYA2V3wcP X-Proofpoint-ORIG-GUID: niOiANT-Il8wNjrIzEHQ38JXYA2V3wcP X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-21_09:2021-07-21, 2021-07-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 spamscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 phishscore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107210089 Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 15:34:21 -0000 Following up for those who may be curious... I did email the support team with copies of the sent and received versions = of emails. Glen correctly diagnosed the problem. My email contained a line with exactly 76 characters, with last character "= .", and followed by carriage return. Apparently, my Exchange server wrapped= this line at 75 characters to put that "." all by itself on a line (with t= he carriage return). The emails I received were being truncated directly before that ".". This is a known bizarre issue. https://unix.stackexchange.com/questions/38156/sendmail-procmail-exchange-t= runcating-mail The answer there explains that " - Exchange: on accepting a piece of mail for delivery, it appears to refo= rmat a plain text message, encoding and wrapping its lines to 75 characters= . - sendmail: An old (but known) behaviour was being followed in that mail= with a bare period on a line was interpreted as end-of-message and then de= livered, effectively truncating the actual mail body." Well, I feel better now. Barbara > Do you have an example date / message id of such an email ? >=20 > Does the dnssd email archive have the email untruncated but only group > members > report that it was truncated on their end, or is it also truncated on the > list archive ? >=20 > I had once email recently from an AD via draft-alias and WG expander, > which arrived truncated on my side, but made it untruncated to > the WG alias. >=20 > Alas, i have not been able to track thast one down, even > through it was a mayor issue for me (AD review of one of my drafts > that i received truncated. Imagine how i felt when the AD told me: > why did you stop fixing nits after 25% of my review... ;-)) >=20 > Cheers > Toerless >=20 > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I= 've > never seen this before. Is anyone else experiencing this, or experienced = this in > the past? > > Barbara > > > > ___________________________________________________________ > > Tools-discuss mailing list - Tools-discuss@ietf.org > > This list is for discussion, not for action requests or bug reports. > > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.= org > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > * Report all other bugs or issues to: ietf-action@ietf.org > > List info (including how to Unsubscribe): > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tools- > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh- > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$ >=20 > -- > --- > tte@cs.fau.de From nobody Wed Jul 21 09:55:43 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F234F3A1EEE for ; Wed, 21 Jul 2021 09:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVJU-YqAP1kl for ; Wed, 21 Jul 2021 09:55:34 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8514A3A1EED for ; Wed, 21 Jul 2021 09:55:34 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 07AA3548053; Wed, 21 Jul 2021 18:55:28 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 013744E7AE5; Wed, 21 Jul 2021 18:55:27 +0200 (CEST) Date: Wed, 21 Jul 2021 18:55:27 +0200 From: 'Toerless Eckert' To: "STARK, BARBARA H" , glen@amsl.com, john-ietf@jck.com Cc: "'tools-discuss@ietf.org'" Message-ID: <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 16:55:42 -0000 Thanks, Barbara, but i can still not make out heds or tails (adding Glen and John) a) Was the bug now fixed ? Aka: when you repeat this, will it work now ? b) Whether fixed or not, which piece of software is the culprit ? AFAIK: The "old" behavior you refer to is the standard SMTP end-of-mail-data "." behavior of 1982 RFC821 section 3.1 that must go along with the transparency procedure of section 4.5.2. Current SMTP RFC5321 does not change this behavior. So, you can see why i am curious about any software having a bug about a procedure that has been used in gazillions (too many to count) of emails since 1982. The way you describe it sounds as if an Exchane server must be speaking SMTP, and it is folding long lines AFTER performing the SMTP transparency fixup, which is the wrong order. The only SMTP server/message-receiver side issue i can think of is confusion introduced when going beyond ASCII about what constitutes a ".". RFC5321 hints at this, but does not explain the breaking workflow. Cheers Toerless On Wed, Jul 21, 2021 at 03:33:35PM +0000, STARK, BARBARA H wrote: > Following up for those who may be curious... > I did email the support team with copies of the sent and received versions of emails. Glen correctly diagnosed the problem. > My email contained a line with exactly 76 characters, with last character ".", and followed by carriage return. Apparently, my Exchange server wrapped this line at 75 characters to put that "." all by itself on a line (with the carriage return). > The emails I received were being truncated directly before that ".". > This is a known bizarre issue. > https://unix.stackexchange.com/questions/38156/sendmail-procmail-exchange-truncating-mail > > The answer there explains that > " - Exchange: on accepting a piece of mail for delivery, it appears to reformat a plain text message, encoding and wrapping its lines to 75 characters. > - sendmail: An old (but known) behaviour was being followed in that mail with a bare period on a line was interpreted as end-of-message and then delivered, effectively truncating the actual mail body." > > Well, I feel better now. > > Barbara > > > Do you have an example date / message id of such an email ? > > > > Does the dnssd email archive have the email untruncated but only group > > members > > report that it was truncated on their end, or is it also truncated on the > > list archive ? > > > > I had once email recently from an AD via draft-alias and WG expander, > > which arrived truncated on my side, but made it untruncated to > > the WG alias. > > > > Alas, i have not been able to track thast one down, even > > through it was a mayor issue for me (AD review of one of my drafts > > that i received truncated. Imagine how i felt when the AD told me: > > why did you stop fixing nits after 25% of my review... ;-)) > > > > Cheers > > Toerless > > > > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > > > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've > > never seen this before. Is anyone else experiencing this, or experienced this in > > the past? > > > Barbara > > > > > > ___________________________________________________________ > > > Tools-discuss mailing list - Tools-discuss@ietf.org > > > This list is for discussion, not for action requests or bug reports. > > > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > > * Report all other bugs or issues to: ietf-action@ietf.org > > > List info (including how to Unsubscribe): > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tools- > > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh- > > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$ > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Wed Jul 21 10:30:32 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F92F3A2089 for ; Wed, 21 Jul 2021 10:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=att.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMBZfEk7FmAw for ; Wed, 21 Jul 2021 10:30:24 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 7596F3A2084 for ; Wed, 21 Jul 2021 10:30:24 -0700 (PDT) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 16LHPjVi044473; Wed, 21 Jul 2021 13:30:07 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 39x236fbu8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jul 2021 13:30:07 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16LHU4PC017893; Wed, 21 Jul 2021 13:30:05 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 16LHTuuX015110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Jul 2021 13:29:58 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 65AA8403DE57; Wed, 21 Jul 2021 17:29:56 +0000 (GMT) Received: from MISOUT7MSGED1AC.ITServices.sbc.com (unknown [135.66.184.173]) by zlp27126.vci.att.com (Service) with ESMTP id 4308D403DE56; Wed, 21 Jul 2021 17:29:56 +0000 (GMT) Received: from MISOUT7MSGEX2CC.ITServices.sbc.com (135.66.184.218) by MISOUT7MSGED1AC.ITServices.sbc.com (135.66.184.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Wed, 21 Jul 2021 13:29:55 -0400 Received: from MISOUT7MSGETA01.tmg.ad.att.com (144.160.12.221) by MISOUT7MSGEX2CC.ITServices.sbc.com (135.66.184.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10 via Frontend Transport; Wed, 21 Jul 2021 13:29:55 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.106) by edgeso1.exch.att.com (144.160.12.221) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.10; Wed, 21 Jul 2021 13:29:55 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i9fIPOmt1b4NGQu8nL7BT4HX4997Tu6p0dMh45VbdQKa4AXVU0gJ6ypO9NPuUVBk0GzBJBjLxQex/ow2JVwqUL93sdML9gg+fDMumeMkZew0W8X2Q8XZYPW719Mbw3ApYFLwl1emOpHFYqr2jfJActOp5C4MLhABpmrWEArP9GIZYzzMSbPRWP+1bCJ8xv+A1MwPajYzviWgyf97e3NyYWQC68lGtwPWKZxFfzeJEuUlWVAoi6MeREvP3m/Zr2E6+o92IUOTYiJDFimqyoMSp0bpATbDJ8qrLCNmG9dzyPbMqffs3Ly4k3s10NNelts/ci12sYRhJkZAx6bHV6+KHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pGsFu3fH5EaoOhqSQb60KtoduWDzSIZZlXQ2Zwh73O0=; b=DGUpIalapspjnUoV5EZoLf8kRzZGbYgdIxEC+lnpMYzMAqKnhDTFOlGs15/si5YEz+b4BnQ5hPvmM4PAaWwmdWRaJZzKHFQfxGJdph6gHvqDSGkQagprsFSLIZYEis7OK53skPTXeT2EWovHT4xWIpp2+hZS+jK3FoXpAsqGVaB4+bTu7qQh9wFvLlxy1vC7fcmw9nartsOwxzGfsi6jQJQUsdcLTnjY8lqj1+7SB2AFJT6KL0OwJv4JsXAfI7ajjLdcrSp902ybAVeIJztDl5TE6CPFo6P6F51y4hZENN+FKS6qkZw6S5jpqRbj7tzYl3CJTlLOv5C93Ptmi8WXAQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=att.com; dmarc=pass action=none header.from=att.com; dkim=pass header.d=att.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.onmicrosoft.com; s=selector2-att-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pGsFu3fH5EaoOhqSQb60KtoduWDzSIZZlXQ2Zwh73O0=; b=p1Zd80IgWq/dXkx5JzXEDmYYGqfkEFso/gw9OjZRzNNFm61v+wz2MXjpPQMkj+jGjIojlCyuZHqsKrK7munr7dRbQolXMkBTuRReKsjmwhYbYUECkzMxX2JKIWqWLbs2eKuqJxPOqdU0PokVI7saqZDNfycMdxE9O2/3KunSt/Q= Received: from DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) by DM6PR02MB6924.namprd02.prod.outlook.com (2603:10b6:5:25f::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4331.31; Wed, 21 Jul 2021 17:29:54 +0000 Received: from DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130]) by DM6PR02MB6924.namprd02.prod.outlook.com ([fe80::d019:8784:1d4c:6130%3]) with mapi id 15.20.4331.034; Wed, 21 Jul 2021 17:29:54 +0000 From: "STARK, BARBARA H" To: "'Toerless Eckert'" , "'glen@amsl.com'" , "'john-ietf@jck.com'" CC: "'tools-discuss@ietf.org'" Thread-Topic: [Tools-discuss] emails being truncated Thread-Index: Add6UW1BT3hnBbhrRzu9q3XpOkAMBAAC8CSAAPlG5LAAA7rLgAAAzyXQ Date: Wed, 21 Jul 2021 17:29:54 +0000 Message-ID: References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> In-Reply-To: <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.fau.de; dkim=none (message not signed) header.d=none;cs.fau.de; dmarc=none action=none header.from=att.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cac9c984-03bd-485a-fa5e-08d94c6d2746 x-ms-traffictypediagnostic: DM6PR02MB6924: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iGebn4kjrXNN8VS8p9NSCijCXorf2DyoR4MyifKhwPG3pACwIbsW6LMFXtFaM2cU33bgoS7zOHJc610Dc/PDP2uU9CHKhwODySQ5nOtB0cx/Hu0o368A5XyNY4IW79bRj081odI7QBq2nVDmIyJRxJmcHw8J6Waa+dEvtL92zW/pbCM2ugzw6VKaAGdDbemcoCGN8DBEVBBCw7GgjgfPEfZ+RsFmTa39jBq/+JxeA43Dr8e22TBC3ul4cRDhsFe+Yse38LTFTEyrpzYk2qMzEyMBrsvedMi9g13N3CqNgkv/1+Wwu81h/RD2j2BOrNv+fFHGA7HE1ghtm2gDJiJttC1V9iWOdVIZPgSVQNs5wG1zcf41vr5XHPEmgRxWrfXz7hpfMipyk307SkGLqmChtcU0yiQWAKuAIRK332n2bvVCn3L4OvPZrvfqxU4uQPjGOwgYSMVin6CEAfQiGcd+NiqUenr7SOmbpmVHOvSzXw0H+C1xCK62ReOHlihcb0UExM6nZpmZdTtSgtg1wlmIrRJap05NrfRizbDfLJkN4mDn64HZv1vFlsRrgpXc2WoYUYCwv7X3gUFNADdew/arZtiV5saJ9OeBY7WrMy1tCM4jPlwe/tLWb3YB09GBfnDxvu67MXvD7cO0ep38mahwoCy0ARzll073m1nHS5ZmwxKQjGggIj/7GlNUSnyMfITXwwHBOHKASOG2+d8e9fHbhN3KZvs5aUHZN0JVIXfh24QdR/LcckOJCaKu6jPMHBnDJ3KaE64HJ4m34O4wemF18DN14ZDlU8Vr9NuxUcKq9LYva9n4sOcY+VqQudkZid1laa42MHkWMPM1RaMjPNk8FKtcmub0cU6V4wdqobOeYLw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR02MB6924.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(396003)(376002)(346002)(366004)(66556008)(316002)(5660300002)(55016002)(8936002)(9686003)(83380400001)(33656002)(86362001)(38100700002)(122000001)(71200400001)(66446008)(66946007)(82202003)(64756008)(66476007)(52536014)(966005)(110136005)(76116006)(2906002)(8676002)(4326008)(186003)(6506007)(26005)(478600001)(7696005)(38070700004)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BSlvIB0edDeHHf93Bigb4mdcBiea+M0mnja9zkv10SW8OqNlVY3aC+eGYlk+?= =?us-ascii?Q?WGNVTjGHPpg+bFKYUqtXjD0YnUclJuYfQ9u2Q9pm9MTugHDFXHHcWBklbr01?= =?us-ascii?Q?NslKLGQjmBn8Qut337V9+cV2y/TsH9HFbQ3il/4/+3tf7i5f7ajUc+/lTqVE?= =?us-ascii?Q?2EDDhhoCMy00VOcWx1L26V3Gy3l4MdlBMcsijtOrVsHYhkhIIIXLFw8DwaiA?= =?us-ascii?Q?PlGj/ReSyQ3TtMNNbriL0rbVwL94FeOE1GENCAsjw3uGmAYD+p+C8A4FKLHf?= =?us-ascii?Q?JIPisqi+DIr8hTvVevFqYLHp9x0K0gnE2UjWH04Q8dMWoKl5qpNmbKrv5hEC?= =?us-ascii?Q?291N0XumUm2VFrW3L0uvFCCeZLSZiLOtHcN5J1W/OKk5JPgZkPWk4vexK1Ml?= =?us-ascii?Q?YiYulNl+zd+CJBKP762Y3uVPik1ZUsGEBGx0aFN1OnCQDai5FuzgBJml+eMq?= =?us-ascii?Q?UyzSZxdqxpUZKG3VzR3arrJAR54ipsrDRy4lC4qtF9LaXynQD1Uel/3XL/VB?= =?us-ascii?Q?md1oq82cz+uaUMxDLNjqfPKHf4C3iSB72YvQLKbEenWKbkxggJ0JLoXryN+K?= =?us-ascii?Q?KSVVP6yRTcGnU6h1S2E7HaI7WYWMd8dWezWXm1cWlmtKrWmJQy8EZg5IPdny?= =?us-ascii?Q?cq4t2/Vz+KjOB5XsLSgntEkQ3iVVOEwbbKxzCRFc3N1WSlqkcRo4rLArymBC?= =?us-ascii?Q?JJTbqxceYWQ+dnBld2xQ9bWEYhk5K7mUBbZJmBjjXCg9H05bbAe7AKS+YcLe?= =?us-ascii?Q?uw0r5AzFU+DjMF2TNvDI6NqKjzwotT5JsBqjP6XY6wNp6S6IglOn/hA6U2q3?= =?us-ascii?Q?ij7944pxHNaIXrOIBP3yovUhSe7NOeTGbBQR6zRtUPXXf9rdfthJkw2a6J+7?= =?us-ascii?Q?VKX3RiE1s/WHOIwOsU6AfEpINRSeUSgoPWs8yU5uurCd/7dymkz42fMQ3h70?= =?us-ascii?Q?idyP9rBAJBfE+cL9iCLLsqiYGxThdGSK1uz+Y+P2l1+sTC7Cszi0BRx/hpOX?= =?us-ascii?Q?TIoOEsunDoKc3w6EE4q/AvLG8UHfOgJSEVbhBm4M2YgDvXBOwmsM9jBuHPyy?= =?us-ascii?Q?+EmLnecYkwZNNoWWEcTVernMgq2puNYkPbDqsMllXr6CDTSXnoCxOwYzblHV?= =?us-ascii?Q?hBQOEAXyDxRIuU7aCuhzfyUTZy6ziBQriAr8Dfk6cRmCgvKiYjUZSKBWMpTc?= =?us-ascii?Q?SoU9sx68suFRH2Y2ykMUFAOkuZgrLZPykcnKb4RtPerJOh+XJ/M8bkQRS4Ra?= =?us-ascii?Q?7CSe/tvehWWNPJ1nRwYq/lu4+jZaanKUQ5JFh5DHdkKNl7euULA2/sXLZbip?= =?us-ascii?Q?i5gUEJqNsAAgZqxv6Fg+4ne6?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR02MB6924.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cac9c984-03bd-485a-fa5e-08d94c6d2746 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2021 17:29:54.3097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e741d71c-c6b6-47b0-803c-0f3b32b07556 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xKAnMGERspX54VbOTnJdCjeInWSHtjoowG865NUr1a0JBNJTOVccKJ9zR0PFXRT2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR02MB6924 X-OriginatorOrg: att.com X-TM-SNTS-SMTP: A7F87B472C23EC9D9D79C618D2C3BC4323B5736896521C956187D408BA6609F62 X-Proofpoint-GUID: N67AqhUPrPiUzFNAAGnQ0yDe3Fq1SxL3 X-Proofpoint-ORIG-GUID: N67AqhUPrPiUzFNAAGnQ0yDe3Fq1SxL3 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-21_10:2021-07-21, 2021-07-21 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 suspectscore=0 phishscore=0 bulkscore=0 mlxscore=0 priorityscore=1501 clxscore=1011 malwarescore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107210102 Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 17:30:30 -0000 Hi Toerless, I'm fairly sure the problem lies within the AT&T email systems, which are v= ery convoluted (for security reasons). I don't think this is a problem that= can be solve by IETF. I'm not particularly incented to try to fix the AT&T= email issue because such things always involve going through a Tier 1 "hel= p" desk that will want to invasively take control of my laptop to try to "f= ix" my problem (because all problems are on users' local machines, of cours= e). They may break something that works, while doing this. I would then hav= e to convince this person half a world a way to please escalate. It's not w= orth it to me, so I'm going to leave it here. Barbara =20 > Thanks, Barbara, but i can still not make out heds or tails > (adding Glen and John) >=20 > a) Was the bug now fixed ? Aka: when you repeat this, will it work now ? >=20 > b) Whether fixed or not, which piece of software is the culprit ? >=20 > AFAIK: >=20 > The "old" behavior you refer to is the standard SMTP end-of-mail-data > "." behavior of 1982 RFC821 section 3.1 that must go > along with the transparency procedure of section 4.5.2. Current > SMTP RFC5321 does not change this behavior. >=20 > So, you can see why i am curious about any software having a bug > about a procedure that has been used in gazillions (too many to count) > of emails since 1982. >=20 > The way you describe it sounds as if an Exchane server must be > speaking SMTP, and it is folding long lines AFTER performing the > SMTP transparency fixup, which is the wrong order. >=20 > The only SMTP server/message-receiver side issue i can think of is > confusion introduced when going beyond ASCII about what constitutes > a ".". RFC5321 hints at this, but does not explain the breaking workflow. >=20 > Cheers > Toerless >=20 > On Wed, Jul 21, 2021 at 03:33:35PM +0000, STARK, BARBARA H wrote: > > Following up for those who may be curious... > > I did email the support team with copies of the sent and received versi= ons of > emails. Glen correctly diagnosed the problem. > > My email contained a line with exactly 76 characters, with last charact= er ".", > and followed by carriage return. Apparently, my Exchange server wrapped t= his > line at 75 characters to put that "." all by itself on a line (with the c= arriage > return). > > The emails I received were being truncated directly before that ".". > > This is a known bizarre issue. > > > https://urldefense.com/v3/__https://unix.stackexchange.com/questions/3815= 6 > /sendmail-procmail-exchange-truncating- > mail__;!!BhdT!y4NKbaHihIlZDD_qjVaDSgFEXbVqZpRI00Bnmb63dTsUcMAY6vSUA > QCQI5jkaA$ > > > > The answer there explains that > > " - Exchange: on accepting a piece of mail for delivery, it appears to = reformat > a plain text message, encoding and wrapping its lines to 75 characters. > > - sendmail: An old (but known) behaviour was being followed in that = mail > with a bare period on a line was interpreted as end-of-message and then > delivered, effectively truncating the actual mail body." > > > > Well, I feel better now. > > > > Barbara > > > > > Do you have an example date / message id of such an email ? > > > > > > Does the dnssd email archive have the email untruncated but only grou= p > > > members > > > report that it was truncated on their end, or is it also truncated on= the > > > list archive ? > > > > > > I had once email recently from an AD via draft-alias and WG expander, > > > which arrived truncated on my side, but made it untruncated to > > > the WG alias. > > > > > > Alas, i have not been able to track thast one down, even > > > through it was a mayor issue for me (AD review of one of my drafts > > > that i received truncated. Imagine how i felt when the AD told me: > > > why did you stop fixing nits after 25% of my review... ;-)) > > > > > > Cheers > > > Toerless > > > > > > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > > > > My emails (to dnssd@ietf.org) are suddenly being strangely truncate= d. I've > > > never seen this before. Is anyone else experiencing this, or experien= ced this > in > > > the past? > > > > Barbara > > > > > > > > ___________________________________________________________ > > > > Tools-discuss mailing list - Tools-discuss@ietf.org > > > > This list is for discussion, not for action requests or bug reports= . > > > > * Report datatracker and mailarchive bugs to: datatracker- > project@ietf.org > > > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > > > * Report all other bugs or issues to: ietf-action@ietf.org > > > > List info (including how to Unsubscribe): > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/too= ls- > > > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh- > > > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$ > > > > > > -- > > > --- > > > tte@cs.fau.de >=20 > -- > --- > tte@cs.fau.de From nobody Wed Jul 21 11:41:21 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080953A2481; Wed, 21 Jul 2021 11:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 NtirbttJwEpX; Wed, 21 Jul 2021 11:41:08 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D01F3A2480; Wed, 21 Jul 2021 11:41:08 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 9577854804E; Wed, 21 Jul 2021 20:41:01 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8E8C64E7AE7; Wed, 21 Jul 2021 20:41:01 +0200 (CEST) Date: Wed, 21 Jul 2021 20:41:01 +0200 From: 'Toerless Eckert' To: "STARK, BARBARA H" , emailcore@ietf.org Cc: "'glen@amsl.com'" , "'john-ietf@jck.com'" , tools-discuss@ietf.org Message-ID: <20210721184101.GR57276@faui48e.informatik.uni-erlangen.de> References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 18:41:14 -0000 Let me add emailcore On Wed, Jul 21, 2021 at 05:29:54PM +0000, STARK, BARBARA H wrote: > Hi Toerless, > I'm fairly sure the problem lies within the AT&T email systems, which are very convoluted (for security reasons). Thanks. > I don't think this is a problem that can be solve by IETF. Let me disagree! It is of course very frustrating to see such bugs in deployments for a spec from 1982 (RFC821/RFC5321). But if the problem does happen in a large enterprise as ATT, it likely happens elsewhere too, and after 43 years its clear it will not go away by itself: I suspect that after 43 years this is not even bad old code, but badly written "recent" SMTP code. SMTP sending looks from the outset so simple, many attempt to just re-implement it as few lines of code in their app and of course miss out on details. I know i did (statue of limitations for me ;-). emailcore is working on RFC5321bis. Hardening protocol state machineries against broken peers is IMHO extremely important, for sond principles such as "be lenient in what you accept and diligent in what you send", or providing good error diagnostics. This particular part of the SMTP state machinery is one which doesn't do either. In my memory almost the only. I do suspect ATTs broken sender would continue to send the message body after the ".", but the SMTP peer will just interpret that as broken SMTP. If that is the case, it should be possible to use an expanded SMTP state machinery with such an error recognition, even if just heuristic. And heuristic is good enough. It just takes few correctly triggeed error email notifications from the heuristic to get bugs like this fixed over the years, especially when the error email generated was easy to understand. I would be happy to suggest a heuristic if emailcore was willing to think about adding this as an item to fix for draft-ietf-emailcore-rfc5321bis. Worst case, you might need to send more emails with the problematic 76 characters to test the theory ;-) Cheers Toerless > I'm not particularly incented to try to fix the AT&T email issue because such things always involve going through a Tier 1 "help" desk that will want to invasively take control of my laptop to try to "fix" my problem (because all problems are on users' local machines, of course). They may break something that works, while doing this. I would then have to convince this person half a world a way to please escalate. It's not worth it to me, so I'm going to leave it here. > Barbara > > > Thanks, Barbara, but i can still not make out heds or tails > > (adding Glen and John) > > > > a) Was the bug now fixed ? Aka: when you repeat this, will it work now ? > > > > b) Whether fixed or not, which piece of software is the culprit ? > > > > AFAIK: > > > > The "old" behavior you refer to is the standard SMTP end-of-mail-data > > "." behavior of 1982 RFC821 section 3.1 that must go > > along with the transparency procedure of section 4.5.2. Current > > SMTP RFC5321 does not change this behavior. > > > > So, you can see why i am curious about any software having a bug > > about a procedure that has been used in gazillions (too many to count) > > of emails since 1982. > > > > The way you describe it sounds as if an Exchane server must be > > speaking SMTP, and it is folding long lines AFTER performing the > > SMTP transparency fixup, which is the wrong order. > > > > The only SMTP server/message-receiver side issue i can think of is > > confusion introduced when going beyond ASCII about what constitutes > > a ".". RFC5321 hints at this, but does not explain the breaking workflow. > > > > Cheers > > Toerless > > > > On Wed, Jul 21, 2021 at 03:33:35PM +0000, STARK, BARBARA H wrote: > > > Following up for those who may be curious... > > > I did email the support team with copies of the sent and received versions of > > emails. Glen correctly diagnosed the problem. > > > My email contained a line with exactly 76 characters, with last character ".", > > and followed by carriage return. Apparently, my Exchange server wrapped this > > line at 75 characters to put that "." all by itself on a line (with the carriage > > return). > > > The emails I received were being truncated directly before that ".". > > > This is a known bizarre issue. > > > > > https://urldefense.com/v3/__https://unix.stackexchange.com/questions/38156 > > /sendmail-procmail-exchange-truncating- > > mail__;!!BhdT!y4NKbaHihIlZDD_qjVaDSgFEXbVqZpRI00Bnmb63dTsUcMAY6vSUA > > QCQI5jkaA$ > > > > > > The answer there explains that > > > " - Exchange: on accepting a piece of mail for delivery, it appears to reformat > > a plain text message, encoding and wrapping its lines to 75 characters. > > > - sendmail: An old (but known) behaviour was being followed in that mail > > with a bare period on a line was interpreted as end-of-message and then > > delivered, effectively truncating the actual mail body." > > > > > > Well, I feel better now. > > > > > > Barbara > > > > > > > Do you have an example date / message id of such an email ? > > > > > > > > Does the dnssd email archive have the email untruncated but only group > > > > members > > > > report that it was truncated on their end, or is it also truncated on the > > > > list archive ? > > > > > > > > I had once email recently from an AD via draft-alias and WG expander, > > > > which arrived truncated on my side, but made it untruncated to > > > > the WG alias. > > > > > > > > Alas, i have not been able to track thast one down, even > > > > through it was a mayor issue for me (AD review of one of my drafts > > > > that i received truncated. Imagine how i felt when the AD told me: > > > > why did you stop fixing nits after 25% of my review... ;-)) > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Fri, Jul 16, 2021 at 02:50:51PM +0000, STARK, BARBARA H wrote: > > > > > My emails (to dnssd@ietf.org) are suddenly being strangely truncated. I've > > > > never seen this before. Is anyone else experiencing this, or experienced this > > in > > > > the past? > > > > > Barbara > > > > > > > > > > ___________________________________________________________ > > > > > Tools-discuss mailing list - Tools-discuss@ietf.org > > > > > This list is for discussion, not for action requests or bug reports. > > > > > * Report datatracker and mailarchive bugs to: datatracker- > > project@ietf.org > > > > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > > > > * Report all other bugs or issues to: ietf-action@ietf.org > > > > > List info (including how to Unsubscribe): > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tools- > > > > discuss__;!!BhdT!y69XSrVx9_N0CqsoYvkdc4xaLGtXfH6kh- > > > > qvbmUhVIgNfw0yBw6GXgb2ZApVtA$ > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Wed Jul 21 12:54:16 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC73F3A2725 for ; Wed, 21 Jul 2021 12:54: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 sWy5RcWorkjG for ; Wed, 21 Jul 2021 12:54:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D873A2724 for ; Wed, 21 Jul 2021 12:54:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id BE6B538A01; Wed, 21 Jul 2021 15:57:32 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uCCuR436nyLU; Wed, 21 Jul 2021 15:57:29 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4CFE1389FE; Wed, 21 Jul 2021 15:57:29 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E680454A; Wed, 21 Jul 2021 15:54:04 -0400 (EDT) From: Michael Richardson To: "Glen" , tools-discuss@ietf.org In-Reply-To: <000d01d77da9$a7b745b0$f725d110$@amsl.com> References: <000d01d77da9$a7b745b0$f725d110$@amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 19:54:15 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ps: I really like the RFC-editor's use of lists for the clusters. AFAIK, these lists and communications with the RPC are not publically archived, but probably they are implicitely public. At least, I'm pretty = sure that they aren't priviledged in any way, and would be trivially discoverable in a court case. That's one advantage of the Archived-At: header: it makes it really obvious when something is explicitely public. Maybe it should ... a standard :-) (Maybe it is already) Maybe we ought to package our mailing list system into a few containers, and sell/lease/lend them to other entities. RIPE? ARIN? Linux Foundation? Maybe we could lighten our load here by sharing. (I've been told that Glen is moving towards containers for everything) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD4e1wACgkQgItw+93Q 3WUscwgAtsANGLCA8tTnKiDR/bsvCOULd6czVFjz1ZpG1g47vSWAAqTPxiKHhamv Pcz18EUQY9y7rB3FyrExXybL11jq9Hp0/ACBLUb8E14eGzJO7hEFANqDbRfRwQvw +F1rQDWiA2getjp8pce+dHvBKyT+x7Mqy7jFCUQCV4iV002LESLzi57Ped93QZTx 9Hvid2D8lmwRo0AQBVi5HthIiSerFo3RhC52tm7YFvazdcxYjNHdxOaY6njJ5pgC vJobdtNHBnmXMfZV/Ri8H31uqIeFrYm7luKLyAufPiIr56Jm0sxZ0wfD3U7jDwmn B84YrkEylKkfW78V4qgEla1xb0//0Q== =0aN9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 21 13:25:13 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0D43A2800 for ; Wed, 21 Jul 2021 13:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.209 X-Spam-Level: X-Spam-Status: No, score=-104.209 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, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] 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 aEEyE3k3NGol for ; Wed, 21 Jul 2021 13:25:05 -0700 (PDT) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633853A2805 for ; Wed, 21 Jul 2021 13:25:05 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 2321E389F8D; Wed, 21 Jul 2021 13:25:05 -0700 (PDT) Received: from Z301 (unknown [IPv6:2603:3024:1507:36a0:e17f:7cd8:b9e4:164c]) by c8a.amsl.com (Postfix) with ESMTPSA id 0D359389EC3; Wed, 21 Jul 2021 13:25:05 -0700 (PDT) From: "Glen" To: References: <000d01d77da9$a7b745b0$f725d110$@amsl.com> <30861.1626897244@localhost> In-Reply-To: <30861.1626897244@localhost> Date: Wed, 21 Jul 2021 13:25:04 -0700 Message-ID: <001101d77e6e$7dab7550$79025ff0$@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQNmwm3u9zAJqJBJ5Rd1OzKiiJhI6AH5q+vBqB+G4EA= Archived-At: Subject: Re: [Tools-discuss] rfc-editor.org mailing lists don't add "Archived-At"? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 20:25:11 -0000 Having been summoned by name :-) ... > -----Original Message----- > From: Michael Richardson > To: Glen ; tools-discuss@ietf.org > Subject: Re: [Tools-discuss] rfc-editor.org mailing lists don't add = "Archived- > At"? > (I've been told that Glen is moving towards containers for everything) I'm gratified that you think I'm a "mover" :-) - I try to be as = proactive on things as I can. But, just so nobody gets the wrong = idea.... I am *supporting* moving towards containers for as many things as make = sense so to do. I've had long discussions with the IETF (Jay and = Robert, mainly - pity them!) to hammer out best practices and clarify my = own understanding of the challenges involved. Like most of us, I love = new technologies (and, let's be honest!, new *toys*), and = containerization has some exciting aspects that I really like. I am = working hard - in my "copious" free time - to better learn and = understand the operational nuances of Docker, Podman, K8S, and related = technologies, and hope to build out some really great future = infrastructure using these technologies, so that my team and I can = better support these things for the IETF, as they move their tools and = services into the future. But I do not "move" the IETF, I just *serve* the IETF. :-) Glen From nobody Wed Jul 21 14:19:53 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08863A2ABB for ; Wed, 21 Jul 2021 14:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=ViF1Slm3; dkim=pass (2048-bit key) header.d=taugh.com header.b=LiOtm7z6 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 rDB_4OvyLxjw for ; Wed, 21 Jul 2021 14:19:42 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF60B3A2AFF for ; Wed, 21 Jul 2021 14:19:04 -0700 (PDT) Received: (qmail 28711 invoked from network); 21 Jul 2021 21:19:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7021.60f88f46.k2107; bh=/LcCiyHnonRx/nSp/lxKeEWqOuxX6DNQooqZXK9zE0s=; b=ViF1Slm3X1GRND9I3w/b0p7mFp1Fyiw3wRAHrV0OLqvKADWbxewWygBRZ0F4kDdlKr9PJwIUltAQogJnPESdOlUcPTUNgdVIDCZfwCvaq3raZZ/bmqvpILJPkPzQkipzRct1OeMt8RN1gyUMqh+uwbGxA0JFCzu8kCYadz3Q4hD4OHeYtsvRQJ+WKxK+hW1eInaoksYICPqnA0QiuxGnHhQi7TSoyfNNygzJbypr+swhnCeNJYShhkOjq/Dc7wwzDTgoUuZLXuxLU8GM7H0hYsoTyXxvlXCPie8YcZK1o4C7mHY9nl4ir7HKQMJ5IQSRBtivKTWM1dvEmdfbKxNRpQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=7021.60f88f46.k2107; bh=/LcCiyHnonRx/nSp/lxKeEWqOuxX6DNQooqZXK9zE0s=; b=LiOtm7z6QQtJKFpbTF1CqiZ3ZTyOIU+Y+4Kx7x4p2f14806VL9gTzVnl7kocFsTE3xSQ83quPqhjjEMLkdXWFCoYffz4MmQU8DOT+7FAIzpsyeID905cuTuaxz418iffhnMg6GqIgwN2kNQpv7TSe6/6p3wiwNhp7+nj2hVf7ERK8ydkPUut02GwUTQ1fkTva+SBfunizzIb30QKVCOuM12+5R8nOssznaN24Pdlpraxdv6mKelp4tDVt1OE4V4gkBn90wuCidU6Jfas+SdGZJC+GwDFUTjawel86i9iHB22qpADDeUvQFfBWQA+UbDKViT7U2iG5ue/jt0VnLz3sw== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 21 Jul 2021 21:19:01 -0000 Received: by ary.qy (Postfix, from userid 501) id 1D55C24D279F; Wed, 21 Jul 2021 17:19:00 -0400 (EDT) Date: 21 Jul 2021 17:19:00 -0400 Message-Id: <20210721211901.1D55C24D279F@ary.qy> From: "John Levine" To: tools-discuss@ietf.org In-Reply-To: <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 21:19:51 -0000 It appears that \'Toerless Eckert\' said: >Thanks, Barbara, but i can still not make out heds or tails >(adding Glen and John) > >a) Was the bug now fixed ? Aka: when you repeat this, will it work now ? As she said, it's a well known bug in Microsoft Exchange. >b) Whether fixed or not, which piece of software is the culprit ? It's still in Microsoft Exchange, which is famous for its casual relationship to mail standards. R's, John From nobody Wed Jul 21 14:21:33 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D133A2AC9 for ; Wed, 21 Jul 2021 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=a6F9Tszv; dkim=pass (2048-bit key) header.d=taugh.com header.b=MM9WUEiv 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 WHWKFzdWypxz for ; Wed, 21 Jul 2021 14:21:25 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB0F3A2ACE for ; Wed, 21 Jul 2021 14:21:24 -0700 (PDT) Received: (qmail 29096 invoked from network); 21 Jul 2021 21:21:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=71a6.60f88fd2.k2107; bh=O1jD8bY6mKhYau8EHRL7V7zUdRiligEmY0dkICH3LiE=; b=a6F9TszvXV2ayJ9vbumwMgFuZa4zPswn9mEoQhzx9uTXTPU/z8osDbPsgdTRU7GJEFomu9zjJqCD5gTBra6ipjiyDNkKsrWraPg6TnYZH+W2k2vwXXhHo1fKrgjLe2hGcjPYkL9Asmt9+u602j4giiST+3R8LDed0Rpo8bio/Hnpdd5wJLS4IVtC9g52vt1MRXEBRZL/W1x6xJ4gszBUm1WBZdjT+sn2Osv5jET0ziBthu4bNGT9ueugEe525xrWoD/NNMlud24OwBrDObqyUIplOMhjQneXc8Q7iCOE6KoomqVv4nivpLZZ4xS3IgBC44VO4E0ngRXrRk5y9FgiFw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=71a6.60f88fd2.k2107; bh=O1jD8bY6mKhYau8EHRL7V7zUdRiligEmY0dkICH3LiE=; b=MM9WUEivohFB0giegluAc5gKA1qSvdC4Eu+/DbLTG+iFKwerNPPf0FydI71E6kLwZDxgPGJYGOvCtImpC45FdgN4U9BzLAKAMbVliqlFBpKWuwdkgKt/dUUUdJzOhaRTIxwjBbkK4PRJ/G+BRizixZtT7C914B41D5Hnjw8Oru4g3OUVD+Y+QAcY7Z3btNyHcDx22eV/F0ShmraSTu7bVeFtePBGAHdnJzzzucpzNG/VW9EEDNsfqCU3a27jP+dnc08GovfPvgQ8S5d1VrtB4lSjMr99CaQRpMOMkMn85WgVjmw9UU2yUmoOjYCBmlqase3liYsd0j47VE3QYJu0eg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 21 Jul 2021 21:21:22 -0000 Received: by ary.qy (Postfix, from userid 501) id 055B224D27E8; Wed, 21 Jul 2021 17:21:21 -0400 (EDT) Date: 21 Jul 2021 17:21:21 -0400 Message-Id: <20210721212122.055B224D27E8@ary.qy> From: "John Levine" To: tools-discuss@ietf.org In-Reply-To: <20210721184101.GR57276@faui48e.informatik.uni-erlangen.de> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] [Emailcore] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2021 21:21:32 -0000 It appears that \'Toerless Eckert\' said: >> I don't think this is a problem that can be solve by IETF. > >Let me disagree! > >It is of course very frustrating to see such bugs in deployments >for a spec from 1982 (RFC821/RFC5321). But if the problem does happen in >a large enterprise as ATT, it likely happens elsewhere too, >and after 43 years its clear it will not go away by itself: > >I suspect that after 43 years this is not even bad old code, but >badly written "recent" SMTP code. SMTP sending looks from the outset so >simple, many attempt to just re-implement it as few lines of >code in their app and of course miss out on details. I know >i did (statue of limitations for me ;-). An interesting guess, but clearly wrong, since it's still a well known bug in Microsoft Exchange. How about if you pop up to Redmond, explain to Microsoft what they're doing wrong, and let us know what they say? R's, John From nobody Wed Jul 21 17:14:52 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5EE3A2FE7 for ; Wed, 21 Jul 2021 17:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aT2ljHkW5ttP for ; Wed, 21 Jul 2021 17:14:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6D63A2FE4 for ; Wed, 21 Jul 2021 17:14:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 28D7438A01; Wed, 21 Jul 2021 20:18:07 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3L8H99yUQqrq; Wed, 21 Jul 2021 20:18:04 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3A219389EC; Wed, 21 Jul 2021 20:18:04 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2F8171E8; Wed, 21 Jul 2021 20:14:39 -0400 (EDT) From: Michael Richardson To: tools-discuss@ietf.org, rfc-interest@rfc-editor.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] rfc-editor errata reporting and stale emails and datatracker X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 00:14:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I just replied-all to an errata (on RFC8366), and one of my co-authors has changed jobs, and of course it bounced. Now I know the new address. But, we did have this thread a month or so ago of having stable addresses f= or the RFC-editor to send errata to. rfcXXXX@ietf.org to hit authors and use that errata, with some kind of bounce detection... if that list becomes emp= ty, then it just goes to the WG chairs and if that list becomes empty... then A= D. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD4uG4ACgkQgItw+93Q 3WXAdQgAvjcG5Os5dFmeDNA4nW3hIuOmG/KKgEBHjXXOGMvxcRQ00/dDzlk+ccJX mM1ITkcq+NWWPIs1Q3A+dChW/gOBXUFKmro5iBobhZv7VUfn0FPmhggsIj0XFllK FqSo8dpglr519/m61fnMUS79j8L3YfFhH1q7W6+QPuciSzXz+bdcMyLeKSSCJytT YmwdSQ3EnNTa5ier0PxA0XzB2ABXCJIziSz0hTF5q7HGFCKYZNRXIfgKM170DqCt byHtULJKp5S4XLvPH1RSGAido0teNcix4eWxcSJOR6po2XGPxaIDNP7itaKJyq53 tN39lnjQMSJtsnp9TNB8qHPe9HeiTw== =h8QD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 22 06:15:21 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B81DE3A4608 for ; Thu, 22 Jul 2021 06:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkZ46SXlhLGB for ; Thu, 22 Jul 2021 06:15:14 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A54A3A4610 for ; Thu, 22 Jul 2021 06:15:14 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1m6YXb-000ATw-Pf; Thu, 22 Jul 2021 09:15:07 -0400 Date: Thu, 22 Jul 2021 09:15:02 -0400 From: John C Klensin To: 'Toerless Eckert' , "STARK, BARBARA H" , glen@amsl.com cc: "'tools-discuss@ietf.org'" Message-ID: <6F183CB68B6F420768E912FB@PSB> In-Reply-To: <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> References: <20210716161105.GM24216@faui48e.informatik.uni-erlangen.de> <20210721165527.GP57276@faui48e.informatik.uni-erlangen.de> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Tools-discuss] emails being truncated X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2021 13:15:19 -0000 --On Wednesday, July 21, 2021 18:55 +0200 'Toerless Eckert' wrote: >... > The only SMTP server/message-receiver side issue i can think > of is confusion introduced when going beyond ASCII about what > constitutes a ".". RFC5321 hints at this, but does not explain > the breaking workflow. In what way do you consider the text in RFC6321 a "hint"? Is it because the text refers to "period" and, in several places, to "." without spelling out that the period is ASCII (2/14 in the original notation, Hex 2E)? Are the restrictions to ASCII in Section 2.3.1 insufficient? Because RFC 5321 is being revised in the EMAILCORE WG (where you are welcome to bring this up if you think it is important), it is quite easy to add the hex value to the "(period or full stop)" note in Section 3.3. Would that be sufficient to make the text more than a hint, or it just being ridiculously pedantic? john From nobody Sat Jul 24 09:55:25 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4E93A4254 for ; Sat, 24 Jul 2021 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBDS-YIhfAp3 for ; Sat, 24 Jul 2021 09:55:20 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B273A4252 for ; Sat, 24 Jul 2021 09:55:20 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GXC3n60t0z2xJV; Sat, 24 Jul 2021 18:55:17 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 648838517.426441-08d7b0542d8518b504faae0f567e0db0 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Sat, 24 Jul 2021 18:55:17 +0200 Message-Id: <83D8BDB2-C4F3-457B-BC8F-701E523F4EC8@tzi.org> To: tools-discuss@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Tools-discuss] Meeting support for contributors X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2021 16:55:23 -0000 Here I am sitting with the IETF111 agenda. I have a simple question: Which WG/RG slots =E2=80=94 have scheduled me to lead a topic - are discussing one of =E2=80=9Cmy=E2=80=9D Internet-Drafts - are discussing an =E2=80=9Cimportant-for-me=E2=80=9D = Internet-Draft Obviously, that can be found out with some significant amount of tedium. Obstacles: =E2=80=94 I can=E2=80=99t download and sync the agenda documents for all = the meetings. (I can download each individual one, which is busywork for 126 WG/RG = meetings.) Syncing is hard because the URIs/filenames change. =E2=80=94 agenda documents don=E2=80=99t have a defined way to summon = me: CB, cabo, Carsten, C. Bormann, =E2=80=A6 - agenda documents don=E2=80=99t have a defined way to list an I-D (some = don=E2=80=99t give even the full draft-ietf-foo-bar name) =E2=80=94 = well, datatracker has a way to record that information outside the = agenda document now, but very few WGs are taking advantage of that = capability (statistics?). =E2=80=94 datatracker does not know which Internet-Drafts are = =E2=80=9Cimportant-for-me=E2=80=9D (which is probably not a boolean = quality either). So, we=E2=80=99d need: (1) A mass download/sync for agenda documents (unless all the mining can = be done centrally). (2) A way to put recognizable person identifiers (=E2=80=9Cnames=E2=80=9D)= on the agenda document. (3) A way to get chairs to record which drafts are up on a meeting. Can = this be mined from the agenda? Possibly with an =E2=80=9CAll OK=E2=80=9D = button for the chairs? (4) A way to push =E2=80=9Cwatch=E2=80=9D on an I-D while I=E2=80=99m = logged into datatracker, possibly with different interest levels. Of = course, I=E2=80=99m already watching drafts that I=E2=80=99m an author, = a shepherd, =E2=80=A6 of. (5) lots of glue, masking tape, and spit, to correlate all this = information and present it in a contributor dashboard. Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 24 12:17:06 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EBF93A0140 for ; Sat, 24 Jul 2021 12:17:05 -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 XVYmUwUEDczY for ; Sat, 24 Jul 2021 12:17:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1687B3A0128 for ; Sat, 24 Jul 2021 12:16:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 808CF38A8F; Sat, 24 Jul 2021 15:20:33 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JYvpKp3uP6S0; Sat, 24 Jul 2021 15:20:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5764C38A88; Sat, 24 Jul 2021 15:20:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E41D72CC; Sat, 24 Jul 2021 15:16:54 -0400 (EDT) From: Michael Richardson To: Carsten Bormann cc: tools-discuss@ietf.org In-Reply-To: <83D8BDB2-C4F3-457B-BC8F-701E523F4EC8@tzi.org> References: <83D8BDB2-C4F3-457B-BC8F-701E523F4EC8@tzi.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] Meeting support for contributors X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2021 19:17:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Carsten Bormann wrote: > =E2=80=94 agenda documents don=E2=80=99t have a defined way to summon= me: CB, cabo, > Carsten, C. Bormann, =E2=80=A6 The DT has a way to indicate who needs to be present, as a clue to the sche= duler. But, I don't think that works right. > - agenda documents don=E2=80=99t have a defined way to list an I-D (s= ome don=E2=80=99t > give even the full draft-ietf-foo-bar name) =E2=80=94 well, datatrack= er has a > way to record that information outside the agenda document now, but > very few WGs are taking advantage of that capability (statistics?). Chairs can indicate which documents are on which agenda, and I think that t= he DT could tell you this. Chairs are not doing this frequently yet. > =E2=80=94 datatracker does not know which Internet-Drafts are > =E2=80=9Cimportant-for-me=E2=80=9D (which is probably not a boolean q= uality either). Yeah. This is the hard part. I take it that you are trying to make sure you are present where you need to be. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD8ZyYACgkQgItw+93Q 3WUDzQgAudF4P5mgXwjJjVss0MWkQFnb+Az3oBoED0rtbyn29g5zlXTyQgV9bCYf IrfFAWAFA25OzErPk0mzIxn9XvInEa6Tu3gWC5utt1aUQbzykWY5chK0oAYJuOxq MZNi4PTTFY5Kq9HxEyHJ+emZEB3WdjHrSUPlo/MBS25SuBmBjHz3dyzuD9x4jKOz 9R+g1MLpo7kQ5VGZ6JwDibiFSkoXQwYTdFnf30JP4k8GycL8wUgcDobacnTc//MN 7OLiDc4W6ts5RChTpuxq61Um+8G1wOyMklaz74qwp8vWkxjpbb8vGhqTV9yJ6d+x 0ylklB/ekBnbcRwPF2gcH+2qRBKeOA== =Sbcd -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 26 11:41:29 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1073A0763 for ; Mon, 26 Jul 2021 11:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2X07OCUxuTf for ; Mon, 26 Jul 2021 11:41:26 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 E25FD3A0755 for ; Mon, 26 Jul 2021 11:41:25 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id 19-20020a9d08930000b02904b98d90c82cso10933932otf.5 for ; Mon, 26 Jul 2021 11:41:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=u/Er3YfEYuaDB9lnXck0ypeQviBrG6mHH8A6tfVgrME=; b=wgXP1lLowUHw/Goy4v9zvlIEsd+Q2mC5/uOO7Bf+ABGV8GKYNqNpjXOGWuX6Jv3ar6 q/mldezl3436Hf9TJ0ahCcYAM52z1dgd+aygdjeO7jwq2+BbTMG65ZEXK1KI8Io9vtlN o2IslW7O3W9I4FG5M2OIuQC/l+MM/rmssmXbOL9fyib6eeDF0sfoM6Ag6811qKqq8APw Cp5AsENT68NEkOb0zfsM3YCfw3IRoyUlBWNDSlcucfZo7fXK7IoqLqAAPBoEBl6GqO3l 4NKgrrpGpYty/tplXy/Vv7sGc/lwgcNCROcDiz2fQwLcMyNgmuAinQ2W688o2F8OANtB Z26w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=u/Er3YfEYuaDB9lnXck0ypeQviBrG6mHH8A6tfVgrME=; b=c8o9CYK/zy2Jk69yrnYElegDNexTkDFIefsxE5GlqCSDPEhje6LsUSBWoGP0RbnL6Q OGlLk0HXgry8I7zy9oaDJdhP23JRb40QNJLZiK10knau64SfhLi7GmFh+wkerFMHIcSK 9fbJllMaCGLyXBDAuwm8RB/cf50AZISV/lt+OfmHpgR6dRjKNwbeDRi17poNbfmIXOVB D0TrexN39KaoLCK6WQoY/MV8giFY9Dj89PdyQT3ZQ1AA0eNZuhALWW0zobXavkruRxdb h0Kmkb7Kn10nNVZpEhgqiwfozivaH3e62x4Z7HFikEO1XgRVDwYM2hjP4C+Vp/oS2MMJ zpNg== X-Gm-Message-State: AOAM530F2JdRTUPOpW1bT6gngx1YkEjSzGYWGUPMxsk9p0KaIxJABsUo MtEUbdd2WAcjZu+1Ghd7e0biajNtT3LTccJTf7qiy3IguM8= X-Google-Smtp-Source: ABdhPJzoc6SryVi38oA59f72lHxZq/6xvK1AkbAWZwIsqdNUGwGQGcRD5FJ6kaD66E0fiYuTtSFGxFmxon4tVAu6J4U= X-Received: by 2002:a9d:491c:: with SMTP id e28mr12502602otf.342.1627324884356; Mon, 26 Jul 2021 11:41:24 -0700 (PDT) Received: from 649336022844 named unknown by gmailapi.google.com with HTTPREST; Mon, 26 Jul 2021 11:41:23 -0700 Mime-Version: 1.0 X-Superhuman-Thread-ID: draft008272ffb084aa10 X-Mailer: Superhuman Desktop (2021-07-23T22:05:57Z) X-Superhuman-ID: krkz7g3t.840c09d8-6f18-4894-a7b4-b501cda3185f X-Superhuman-Draft-ID: draft000e44de9c181259 From: Ted Lemon Date: Mon, 26 Jul 2021 11:41:23 -0700 Message-ID: To: Tools Team Discussion Content-Type: multipart/alternative; boundary="000000000000aaa51e05c80b195a" Archived-At: Subject: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 18:41:27 -0000 --000000000000aaa51e05c80b195a Content-Type: text/plain; charset="UTF-8" The way that xml2rfc handles Chinese names is broken in a way that I think is really problematic. Chinese family names come first, not last. But there's no way to tell xml2rfc to use this ordering, and it uses the surname and initial on the title page. This is actually not necessary, at least for HTML output, and worse it's wrong in a way that I think is not acceptable. Furthermore, I don't even know if Chinese has any notion of an "initial" so I actually put the author's first name in instead, since it's only two glyphs. Have people run into this before? I know this isn't the first Chinese author, by a long shot. Right now I'm addressing the problem by reversing surname and initial, but that is obviously not a good solution when the document makes it to RFC, since a citation will then come out wrong. --000000000000aaa51e05c80b195a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The way that xml2rfc handles Chines= e names is broken in a way that I think is really problematic. Chinese fami= ly names come first, not last. But there's no way to tell xml2rfc to us= e this ordering, and it uses the surname and initial on the title page. Thi= s is actually not necessary, at least for HTML output, and worse it's w= rong in a way that I think is not acceptable. Furthermore, I don't even= know if Chinese has any notion of an "initial" so I actually put= the author's first name in instead, since it's only two glyphs.

Have people run into this before? I know this is= n't the first Chinese author, by a long shot.

<= div>Right now I'm addressing the problem by reversing surname and initi= al, but that is obviously not a good solution when the document makes it to= RFC, since a citation will then come out wrong.

=
--000000000000aaa51e05c80b195a-- From nobody Mon Jul 26 11:56:57 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F0F3A0819 for ; Mon, 26 Jul 2021 11:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.897 X-Spam-Level: X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 P1kXcEp-_gim for ; Mon, 26 Jul 2021 11:56:54 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 18EF53A0817 for ; Mon, 26 Jul 2021 11:56:54 -0700 (PDT) Received: from [10.32.60.200] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged)) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 16QItwYw025292 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Jul 2021 11:55:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] (may be forged) claimed to be [10.32.60.200] From: Paul Hoffman To: Ted Lemon Cc: Tools Team Discussion Date: Mon, 26 Jul 2021 11:56:49 -0700 X-Mailer: MailMate (1.14r5798) Message-ID: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 18:56:56 -0000 On 26 Jul 2021, at 11:41, Ted Lemon wrote: > The way that xml2rfc handles Chinese names is broken in a way that I > think > is really problematic. Chinese family names come first, not last. But > there's no way to tell xml2rfc to use this ordering, and it uses the > surname and initial on the title page. This is actually not necessary, > at > least for HTML output, and worse it's wrong in a way that I think is > not > acceptable. Furthermore, I don't even know if Chinese has any notion > of an > "initial" so I actually put the author's first name in instead, since > it's > only two glyphs. > > Have people run into this before? I know this isn't the first Chinese > author, by a long shot. > > Right now I'm addressing the problem by reversing surname and initial, > but > that is obviously not a good solution when the document makes it to > RFC, > since a citation will then come out wrong. Yes, we have run into this before, and it is more problematic than you state because some people with Chinese names (not just Chinese authors) prefer to put their given name first (the "modern" way), while others prefer to put it last (the "traditional" way). There is no way to programmatically determine which method was chosen. To be clear, this isn't just an RFC format issue: it hits all publishing. --Paul Hoffman From nobody Mon Jul 26 17:38:13 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351AF3A097B for ; Mon, 26 Jul 2021 17:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84GIoixZDHzq for ; Mon, 26 Jul 2021 17:38:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46C623A0977 for ; Mon, 26 Jul 2021 17:38:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 19F19389B5; Mon, 26 Jul 2021 20:41:50 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tK8JSO23ZFtB; Mon, 26 Jul 2021 20:41:46 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CD47389B4; Mon, 26 Jul 2021 20:41:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8558B454; Mon, 26 Jul 2021 20:38:02 -0400 (EDT) From: Michael Richardson To: Paul Hoffman , Ted Lemon , Tools Team Discussion In-Reply-To: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> References: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 00:38:12 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Hoffman wrote: >> The way that xml2rfc handles Chinese names is broken in a way that I= think >> is really problematic. Chinese family names come first, not last. But >> there's no way to tell xml2rfc to use this ordering, and it uses the >> surname and initial on the title page. This is actually not necessar= y, at >> least for HTML output, and worse it's wrong in a way that I think is > Yes, we have run into this before, and it is more problematic than yo= u state > because some people with Chinese names (not just Chinese authors) pre= fer to > put their given name first (the "modern" way), while others prefer to= put it > last (the "traditional" way). There is no way to programmatically det= ermine > which method was chosen. > To be clear, this isn't just an RFC format issue: it hits all publish= ing. It seems that we need an ordering bit added then. (The meta-problem is that we seem to be perpetually behind on fixing our XML specifications. At least, that's what it appears to me) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmD/VWoACgkQgItw+93Q 3WXLMAgAhybSXEqGbifskYebhxnWWbTN9IDs/7iP3dk5zv6tYNzlkDITM68/2i4p Q9WW71uZU+wo31LgXgFUokxWa5Ky1kQPQHiQZpD7ejm6BQ+MRgohbmxA4kemTFGB PW4o9KByJpArafzfvBTgxRGSTAGWCsvJByqEkTlNqUO0RGVZCykOiQnvE2yZo1gs qilYE2TUeQtJP1wFngcH4OfayyLQHpf7kyyThU/LUak5tfCYJ/jGKEuGfz96US2a Yj+PgsOkcdAa4uRYUZprG6qgb9xYjcMNA+wU7Dk/6wSs/uXlOYB8hzVWLoXjWOUR aC55/NN+6efv99XF/9G0YTa0QXoLew== =THSe -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 26 18:12:20 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4493A0CC1 for ; Mon, 26 Jul 2021 18:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29V5-8CbxinO for ; Mon, 26 Jul 2021 18:12:13 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E8893A0D99 for ; Mon, 26 Jul 2021 18:11:46 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GYdzh3rqPz31LS; Tue, 27 Jul 2021 03:11:44 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <24698.1627346282@localhost> Date: Tue, 27 Jul 2021 03:11:44 +0200 Cc: Paul Hoffman , Ted Lemon , Tools Team Discussion X-Mao-Original-Outgoing-Id: 649041104.000388-79181e64f99aaef669ec049ef6a009c1 Content-Transfer-Encoding: quoted-printable Message-Id: <6E1A26BC-3B97-4B9C-B07F-5D91A45A0E40@tzi.org> References: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> <24698.1627346282@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 01:12:18 -0000 >=20 > (The meta-problem is that we seem to be perpetually behind on fixing = our XML > specifications. At least, that's what it appears to me) If we try to do semantic markup, and don=E2=80=99t think the semantics = through, we'll need to do endless fixing. In a similar case, postal addresses, we are in the process of deciding = to get away from semantic markup and let everyone format their addresses = the way they like them. May seem like a regression, or like a = liberation, depending on your perspective. Personal names are really hard to get right [1]. RFCs make that much harder than it needs to be by employing initials, = which are a computation on personal names that only makes sense if you = don=E2=80=99t care about most of the people in the world. If we got rid of that, we could reduce the need for semantic markup of = names, and everything would be wonderful. Depending on your = perspective. Gr=C3=BC=C3=9Fe, Carsten [1]: = https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-= names/ Read on at least until you get down to number 40 :-) From nobody Tue Jul 27 01:18:21 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C058B3A15B5 for ; Tue, 27 Jul 2021 01:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.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 0PZMMnJudMou for ; Tue, 27 Jul 2021 01:18:15 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 14FAE3A1285 for ; Tue, 27 Jul 2021 01:18:14 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id C841460033B; Tue, 27 Jul 2021 11:18:08 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1627373888; bh=Dv2xy0Ff1ffnef3qjbiSIUygcwqicXfyS42FuLmUU3U=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=G7dOBmC7UIhPAN7UtQd4mmJWKK1ml/m80yUVPHx/5C1WYNc/4Hq63WIxVJRorJ0xA OzU6B3bAlEPN2eGMwH3WYUpWOSqElrQcnPnFjBij42suwxImpGYfCWcaYMKFlLatXQ LKBqprdtYpFV3zV2a85XMPp5f7AQHx9hhCj2H9h8= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9E01C4E5-C3DD-4705-A5D5-B95E242AE380"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 27 Jul 2021 11:18:08 +0300 In-Reply-To: <6E1A26BC-3B97-4B9C-B07F-5D91A45A0E40@tzi.org> Cc: Michael Richardson , Paul Hoffman , Tools Team Discussion To: Carsten Bormann References: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> <24698.1627346282@localhost> <6E1A26BC-3B97-4B9C-B07F-5D91A45A0E40@tzi.org> X-MailScanner-ID: C841460033B.A1720 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 08:18:20 -0000 --Apple-Mail=_9E01C4E5-C3DD-4705-A5D5-B95E242AE380 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2021-7-27, at 4:11, Carsten Bormann wrote: > RFCs make that much harder than it needs to be by employing initials, = which are a computation on personal names that only makes sense if you = don=E2=80=99t care about most of the people in the world. A personal +1 t that. The only use case for initials are in references in academic publishing, = when you hit the page limit for a submission and need to fight for every = mm of vertical space:-) Thanks, Lars --Apple-Mail=_9E01C4E5-C3DD-4705-A5D5-B95E242AE380 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmD/wUAACgkQVLXDCb9w wVfb5g//Wp/Cla1WCzpuHinX5+dJQGM4Wz4fc1TXsyHrOXH8MPH3p3sFh+pWxCu/ LOxSafJeoZM+MDC272Vie7sxj6iJWxbUXgvBbn+eJA4LUu6/Xsn1gJEZG0GVtRby mYST9VzcCxOoo8UR29ZKaY2M85AqmKeE+4NLtOdXGfHwy7Gfw/B5Bt5+kMEaG3B6 1pXOPLYxkuBVcfMG8ftsgdIfeoRl1qrcf+VOn2v0iqaZwynLPAGpL6reMEzT2aCC 89ff7vwbwLQ4OyuaRdZ8tCVYDYmJjvxLIALF99rgXKCyH8FrveEQZ1u7fJOYOukP YFjsd4lUqTgmUz/yZtbITxchcy9D+YDER86oKTlQEIquTUGhewUvK0KtDPqb2RnB zFZJLI5wmbJbw6lOE2CIk/dWGgA6jCpK7eapf1T7NRjK8knrr2eB1Cr9gsqnld0n ZBcxVGyx2220R2jd6qHz817e/t/j7YhXLGGYAvS5fV5Jso0+QQ15laRthDM5Zln+ /9c6O7SjOkKoUM76+xYzVX/9gOGN6GywvaNo1F9gxVE9TJFlGNErgRHmvWbX4tec DQpgOe+yLwSkLLxZJrIkxYXwx7FxgtSddQJMiV4TwCHmRkTisLC2OdbhW6ygMEFU YwjimCXZ/vRTJqhFD0DZ0tkem1rb7T3sDZBQc0pfOr3R2jerr8s= =CnHU -----END PGP SIGNATURE----- --Apple-Mail=_9E01C4E5-C3DD-4705-A5D5-B95E242AE380-- From nobody Tue Jul 27 06:57:56 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170783A0953 for ; Tue, 27 Jul 2021 06:57:55 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 nvpl9UMgseWJ for ; Tue, 27 Jul 2021 06:57:50 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B218B3A0AB8 for ; Tue, 27 Jul 2021 06:57:49 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5E26D548005; Tue, 27 Jul 2021 15:57:38 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 583754E7B72; Tue, 27 Jul 2021 15:57:38 +0200 (CEST) Date: Tue, 27 Jul 2021 15:57:38 +0200 From: Toerless Eckert To: Carsten Bormann Cc: Michael Richardson , Paul Hoffman , Tools Team Discussion Message-ID: <20210727135738.GT15189@faui48e.informatik.uni-erlangen.de> References: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> <24698.1627346282@localhost> <6E1A26BC-3B97-4B9C-B07F-5D91A45A0E40@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6E1A26BC-3B97-4B9C-B07F-5D91A45A0E40@tzi.org> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 13:57:55 -0000 In the first place it would be good to figure out if we can come up with the list of things someone is expected to provide to the IETF community if that person wants to be correctly addressed by the community. Whether in publishing or email. a) Identity pronoun b) How to address the person in informal communications (email) given name only ? Surname ? surname-given-name ? ... c) How to address the person in information communications when there is a need for further disambiguation (as in JohnA...JohnZ). d) How to address the person in places where the IETF may be under some legal constraints, which i guess is RFC publishing. Aka: Sufficient good faith effort for IETF not being made responsible in any possible legal proceedins like IPR litigation (Your John Doe does not exist, IETF is violating copy and trademarks in this RFC, please pay $$$$$$). IMHO, d) mostly likely comes for free when we had a)-c) in before, and i for once do regularily struggle with a)-c) for people whom i have not met in at least voice conferencing, but only encounter in IETF email threads. Alternatively, we can simply address IETF'ler in email by the first RFC number in which that person is the first named author. But that is probably discriminatory ;-) Of course, i am also happy to address other IETF'er purely by "rfcXXXX siad" I am happy to address On Tue, Jul 27, 2021 at 03:11:44AM +0200, Carsten Bormann wrote: > > > > (The meta-problem is that we seem to be perpetually behind on fixing our XML > > specifications. At least, that's what it appears to me) > > If we try to do semantic markup, and don’t think the semantics through, we'll need to do endless fixing. > > In a similar case, postal addresses, we are in the process of deciding to get away from semantic markup and let everyone format their addresses the way they like them. May seem like a regression, or like a liberation, depending on your perspective. > > Personal names are really hard to get right [1]. > RFCs make that much harder than it needs to be by employing initials, which are a computation on personal names that only makes sense if you don’t care about most of the people in the world. > If we got rid of that, we could reduce the need for semantic markup of names, and everything would be wonderful. Depending on your perspective. > > Grüße, Carsten > > [1]: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > Read on at least until you get down to number 40 :-) > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss -- --- tte@cs.fau.de From nobody Tue Jul 27 13:05:49 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA223A1044 for ; Tue, 27 Jul 2021 13:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W68NL6-xX-Nt for ; Tue, 27 Jul 2021 13:05:42 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4373A104B for ; Tue, 27 Jul 2021 13:05:42 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 01B5E548005; Tue, 27 Jul 2021 22:05:35 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id EFDDA4E7B79; Tue, 27 Jul 2021 22:05:34 +0200 (CEST) Date: Tue, 27 Jul 2021 22:05:34 +0200 From: Toerless Eckert To: Carsten Bormann Cc: Michael Richardson , Paul Hoffman , Tools Team Discussion Message-ID: <20210727200534.GA44310@faui48e.informatik.uni-erlangen.de> References: <51106D93-E01D-4695-8B59-B4E28A6BA215@vpnc.org> <24698.1627346282@localhost> <6E1A26BC-3B97-4B9C-B07F-5D91A45A0E40@tzi.org> <20210727135738.GT15189@faui48e.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210727135738.GT15189@faui48e.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 20:05:47 -0000 Btw: Someone told me in PM that my mail was perceived as a joke and as an attack against persons, cultures and identities. It actually is meant very serious, and i don't quite understand how it could be misunderstood in that way. I have repeatedly had trouble figuring out gender/pronouns for IETF participants that i never met in person, especially because given names often do not even are clear indicators of gender and of course not at all any preferred pronoun if its not simply derived from obvious gender. Sure, its not a deadly problem one can write text around it, just repeating the name instead of using a pronoun, but then if one makes a mistak with the name, then that blunder (such as using wrong order or using the surname when you wanted to use the given name but didn't know which of the two names that is) becomes even more problematic. As far as i know from passing, social networks do provide the option to explicitly enter public profile information like given name, surname, preferred pronoun. I think it would be great if datatracker would provide such fields. When i then again fumble addressing a person in IETF mails incorrectly, i can at least suggest to the person to fill in the datatracker profile to avoid others to make the same mistakes. And maybe preferred name ordering (surname given-name or other way around) would be useful information to declare as well. To the extend that the mayority of RFC authors have datatracker accounts, this might also help with the original issue of this thread. Cheers Toerless On Tue, Jul 27, 2021 at 03:57:38PM +0200, Toerless Eckert wrote: > In the first place it would be good to figure out if we can > come up with the list of things someone is expected to provide > to the IETF community if that person wants to be correctly > addressed by the community. Whether in publishing or email. > > a) Identity pronoun > b) How to address the person in informal communications (email) > given name only ? Surname ? surname-given-name ? ... > c) How to address the person in information communications > when there is a need for further disambiguation (as in JohnA...JohnZ). > > d) How to address the person in places where the IETF may be > under some legal constraints, which i guess is RFC publishing. > Aka: Sufficient good faith effort for IETF not being made > responsible in any possible legal proceedins like IPR litigation > (Your John Doe does not exist, IETF is violating copy and trademarks > in this RFC, please pay $$$$$$). > > IMHO, d) mostly likely comes for free when we had a)-c) in before, > and i for once do regularily struggle with a)-c) for people > whom i have not met in at least voice conferencing, but only > encounter in IETF email threads. > > Alternatively, we can simply address IETF'ler in email by > the first RFC number in which that person is the first > named author. But that is probably discriminatory ;-) > > Of course, i am also happy to address other IETF'er purely > by "rfcXXXX siad" > I am happy to address > > > On Tue, Jul 27, 2021 at 03:11:44AM +0200, Carsten Bormann wrote: > > > > > > (The meta-problem is that we seem to be perpetually behind on fixing our XML > > > specifications. At least, that's what it appears to me) > > > > If we try to do semantic markup, and don’t think the semantics through, we'll need to do endless fixing. > > > > In a similar case, postal addresses, we are in the process of deciding to get away from semantic markup and let everyone format their addresses the way they like them. May seem like a regression, or like a liberation, depending on your perspective. > > > > Personal names are really hard to get right [1]. > > RFCs make that much harder than it needs to be by employing initials, which are a computation on personal names that only makes sense if you don’t care about most of the people in the world. > > If we got rid of that, we could reduce the need for semantic markup of names, and everything would be wonderful. Depending on your perspective. > > > > Grüße, Carsten > > > > [1]: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ > > Read on at least until you get down to number 40 :-) > > > > ___________________________________________________________ > > Tools-discuss mailing list - Tools-discuss@ietf.org > > This list is for discussion, not for action requests or bug reports. > > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > > * Report all other bugs or issues to: ietf-action@ietf.org > > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Tue Jul 27 14:37:02 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46333A095E for ; Tue, 27 Jul 2021 14:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=RsQEqcG1; dkim=pass (2048-bit key) header.d=taugh.com header.b=eBtMn2Sw 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 FRGr2ik6aI8W for ; Tue, 27 Jul 2021 14:36:51 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B30FD3A0953 for ; Tue, 27 Jul 2021 14:36:50 -0700 (PDT) Received: (qmail 5335 invoked from network); 27 Jul 2021 21:36:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14d3.61007c71.k2107; bh=cqcl1C4v68aOM6LmqVb/AEcQM0r9bhTozd3bvl6fCok=; b=RsQEqcG1MAJ6ympBE28HhQ8Yz8/n4s47oboWilLV12R7ypDE5F3mR5H85+ibB29qzdvbMKOvvqg3OdFojPPteAk8w7Ls/4M0D4pbe2dBxzpErx+7sDUoqWzmfFShM2w0vIlydwUSWyn+CJBN7CAT8f7CG3HGQuVVulov1L/E2KtLgj0fUfjqtgnD67NO82KXKIr0mVXr/sZMjFhl3st5n/4oBL1YTHCxS2cQiPFtdMEC9n7TALTV3VmSv8+hhSlbG/Vnv4E0g7bVhryaEifVfTD4+0Prl5JkOwP140AjUqY17m12PKIkZKxZ2So6uz2qidj2ZcGiSx0U/QeHPhhWkQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=14d3.61007c71.k2107; bh=cqcl1C4v68aOM6LmqVb/AEcQM0r9bhTozd3bvl6fCok=; b=eBtMn2Sw3+1Qk73uurJRQ00Q5QurkB5W7CSd6RwhnzDGEbALeGm4CZ3arxqLpBYO7Gvy46zNNU1y878eo6LKSndnkUOvVSUdVRiUmNPdsE54WNKFXnOfFlXD7aUlrVJ6ql9PvG1/dZpBd2XJFY46lyNzasAMndroAKoCQUScZUoXgR+DoijX4Lm9G220p3K5OJ6afo1e6uA8FAmN9sMRaVcMNuGzCy0z7RUCn5tjEpP09Go/1Jj5xHKHYI7dQiupeBLS8Yxv+VDxtxPFVkXFTzb7CW9wKSHCzy027TO3Lb7lXh0oBmmMIeked8ysYiDJXQhAdXXRWlBJzF1SuFSIYg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Jul 2021 21:36:48 -0000 Received: by ary.qy (Postfix, from userid 501) id BB87125378AD; Tue, 27 Jul 2021 17:36:48 -0400 (EDT) Date: 27 Jul 2021 17:36:48 -0400 Message-Id: <20210727213648.BB87125378AD@ary.qy> From: "John Levine" To: tools-discuss@ietf.org Cc: mcr+ietf@sandelman.ca In-Reply-To: <24698.1627346282@localhost> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] Chinese name order versus surname and initial attributes in X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2021 21:36:59 -0000 It appears that Michael Richardson said: >It seems that we need an ordering bit added then. Nope. In Spanish speaking countries, people usually have a matronymic name written after their surname. For example, the prime minister of Spain is named Pedro Sánchez Pérez-Castejón and his surname is Sánchez. Names in former colonies get even longer, like the president of Equitorial Guinea, Teodoro Obiang Nguema Mbasogo, whose surname is Obiang. When I was in college one of my classmates was named Tim of Angle, surname "of Angle". He was really tired of forms that made him Tim O. Angle. In Indonesia people use a single name which may not be a single word, like former president Suharto and current president Joko Widodo, invariably known as Jokowi. Keeping in mind Lars' note that there's no reason for us to use initials, I think it would work for the author and contact elements to have an attribute for the full name and another for the surname, I suppose with the surname defaulting to the last word of the full name since most of us use the American name order. It is not obvious how to alphabetize such a list of authors, so we should just leave them in whatever order the document lists them. >(The meta-problem is that we seem to be perpetually behind on fixing our XML >specifications. At least, that's what it appears to me) We definitely shipped the beta, but given that we decided to invent our own XML grammar rather than adapting one known to work in publishing like Docbook, that's not a big surprise. We're going to be updating our grammar for quite a while. We still need to figure out whether to update the XML (not text) of published RFCs when we fix the grammar, or live with multiple not quite compatible versions. R's, John -- Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jul 27 18:54:17 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9B33A160B for ; Tue, 27 Jul 2021 18:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=qrGuWq/P; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tx2sse0o 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 rSu9OySxRBXC for ; Tue, 27 Jul 2021 18:54:10 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8AE3A1607 for ; Tue, 27 Jul 2021 18:54:10 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 8B1BC5C0161 for ; Tue, 27 Jul 2021 21:54:06 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Tue, 27 Jul 2021 21:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm2; bh=NQpaoNrLAUrfvLY4IDGNncRPFGBsejzDiMuFyBEo2/g=; b=qrGuWq/P Flx8z43ssaFcPq9/v7hLcWfMx2j2LeND6gXERJhRysrH4wYZ2OQquWDL8Tr1lJZJ 5sPlbvltZxNA2gucE/MCXpy2c/pGcMvPZRUEaFqchG3gRl4bLnVUD+qwuWRCH16X ixDUEF3tF9VYg388w6fR07s460wDNcXogqIWAauIgWK4RU6wObS0x+/A+U0BeyMP ozMXN9vmFYIN0UqFt2l3hJTdoZh9j15GjTKJ7oxy7byCqpPUuAER9d7RSDC9mcyD nk3RBTRBnrxmm9Bv7zsR2s/uFjfGtVpsbCYVfMR8oFIsBrl79Z+i+JH8av3NO7pK LtLIc9b5HN7VHw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=NQpaoNrLAUrfvLY4IDGNncRPFGBse jzDiMuFyBEo2/g=; b=tx2sse0onb8hCXtVB4/KyFfZOHiz5r05BL0hbksBGULrg JNwun8K69TVPeFzljVrALqQJHKBHSjY+Nf7czG51fKkNFEZu/IniYCHtKyrdu9J+ r0dUjmFGMGYx6kS6jsaFUUDxHGvjkzDLbHoCu/oqSE/ChUSi95rAJFpfxl3BeenC /tpF2QtpLyLBc+NrgmlJfPNwt4yyJKWUGTFUf2LvNPLYRkipCiN5N22O3tly5P7Y up9dvcOBYXKAXlWQK9Ngo9r3iPw2q2VeuKI/FT87n5L9jdbvdivrFna6XjyDMhFy iKXeuhClPtkpr6O31Z00znKex13/ks8Nu7FeN12pg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeekgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhhtihhn ucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrg htthgvrhhnpedufeejtdetuedtvedvgedttdejkedtveejveegheeikefftdelgfdvgfet ueejfeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhgihhthhhusgdrihhonecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohif vghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2C40D3C0471; Tue, 27 Jul 2021 21:54:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54 Mime-Version: 1.0 Message-Id: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> Date: Wed, 28 Jul 2021 11:53:49 +1000 From: "Martin Thomson" To: tools-discuss@ietf.org Content-Type: text/plain Archived-At: Subject: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 01:54:15 -0000 I realize that this might be a little inflammatory as far as subjects go, but bear with me. There are probably a few narrow cases where rendering plain text is better than HTML. But what we've been doing for years (thanks to Henrik's great tool) is take text and turn it into HTML using the power of regular expressions. That's been good, but it's not always reliable (how many errata mention that "Section X of [FOO]" links to Section X of this document?). It's also been lagging as the text format changed (case in point: lack of a table of contents). Here's an alternative: style the HTML so that it looks like the text. I tried this and it worked shockingly well. Repo: https://github.com/martinthomson/rfc-txt-html Demo: https://martinthomson.github.io/rfc-txt-html/diff.html This isn't perfect, but it seems pretty good to me. Keep in mind that this took only a little bit of time to sketch out. No doubt it can be improved. The readme has a bunch of things I found, all minor. I don't think that this is the end of text, but a possible way to limit our use of the htmlizer[1]. People who need to automate access to content might still use text, though I will argue that XML is superior in that regard. The other thing that comes to mind is diffs: HTML-native diff tools are somewhat less than ideal. Either way, serving HTML is just better. Enjoy, Martin [1] Though I still see a shocking number of people authoring in XML (or XML-capable input formats) and submitting in text. But I think we have plans to limit that. From nobody Tue Jul 27 19:22:10 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516963A16FA for ; Tue, 27 Jul 2021 19:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix0MnHdExAUl for ; Tue, 27 Jul 2021 19:22:03 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 6518A3A16F9 for ; Tue, 27 Jul 2021 19:22:03 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id r5so1210912ilc.13 for ; Tue, 27 Jul 2021 19:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=R1jUgGaMlgoNUXXCPqT19Utn/nZ1wsJTADdryqXJ6Yc=; b=H0wifV4bYdVMrU/CYjeiV6PP1wgVIEuczvG2UBDc3/9OcM1ji90SxGrneHdpNlMm1q /i5PxjcYdu4OraC59tbIvG9wU+ie65YrpTxEpaTdgbMxW9DCU9Q/VHYZnADcE/eYUB0I oJ3cYlKBqcRiK9U6J5oAyYWqO+PyK4JwVHooeGNGaFMXndpheQsbE28jASlhGql6LrYO HH+Ef+aid3h9tqzYMPB/J6IRGDdxkDcTe52lK19kjR/r1hCigOZGu92UXwS+MVWAGvhx EecbLgP6fHBl2E3mZmK0ZOoOGupmNo57X0QmPwAb7pIJo1Z4v9BB4VgJj1i4PD4XilHS RaNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=R1jUgGaMlgoNUXXCPqT19Utn/nZ1wsJTADdryqXJ6Yc=; b=RVG46LCen60lq0u7OLaGb39XsXHbSb0uyah9UPuKWh5WxVl1HHLVhuWr4qCceMI2A/ PBD1yJc7Q2QqVR74kV4RQgkHQczPMwFhXp5mMqTur2R59sZtc3iUFLh03B9BGUx0aSsA rNDOCiJFaH+q8ZzzM+981cQMfpji2nEL1KYdMUsSlhOFpAPpo/xpIbLTLV1TQBUZTsvm DkOW9tWVgb7LNvLU/aqfl8X6EObZRSt4vCMVJpH9GSkngRH5eW6BX5NiAPyGjNJlbq7s SZOOfHPhBi8fSUIdD94rw4fPl2jYfYpwWsSOOXhLApEFS/XYQzEL0BSa3nI2GoLBB/ZN DDeg== X-Gm-Message-State: AOAM5323XqXW1sj+DOzselcsyTw/ZbYdBAJk0eUzWBvAKRpgh6RlB5MH /Zfe2rWOPfehRN3nIZWL3QWKqUr6OWbvohBGpl+5hN0D6NPzTw== X-Google-Smtp-Source: ABdhPJyy7Ass8+fGMnxfGbGwXRXuOlZOTNDV9wZKtCbKHaNpPYHci3zfRc0q9LbJswdHhhv6a8gSJ2OkgUculiU7ZM8= X-Received: by 2002:a92:d848:: with SMTP id h8mr19032153ilq.282.1627438922182; Tue, 27 Jul 2021 19:22:02 -0700 (PDT) MIME-Version: 1.0 References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> In-Reply-To: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> From: Eric Rescorla Date: Tue, 27 Jul 2021 19:21:26 -0700 Message-ID: To: Martin Thomson Cc: tools-discuss Content-Type: multipart/alternative; boundary="000000000000d9cca405c825a6bb" Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 02:22:08 -0000 --000000000000d9cca405c825a6bb Content-Type: text/plain; charset="UTF-8" FWIW, I generally do reviews by pulling the .txt file into my editor and then cutting and pasting the pieces I want to respond to. Presumably I could find some way to make that work with HTML if we ditched the text format entirely though it would probably be somewhat less convenient. -Ekr On Tue, Jul 27, 2021 at 6:54 PM Martin Thomson wrote: > I realize that this might be a little inflammatory as far as subjects go, > but bear with me. > > There are probably a few narrow cases where rendering plain text is better > than HTML. But what we've been doing for years (thanks to Henrik's great > tool) is take text and turn it into HTML using the power of regular > expressions. That's been good, but it's not always reliable (how many > errata mention that "Section X of [FOO]" links to Section X of this > document?). It's also been lagging as the text format changed (case in > point: lack of a table of contents). > > Here's an alternative: style the HTML so that it looks like the text. I > tried this and it worked shockingly well. > > Repo: https://github.com/martinthomson/rfc-txt-html > Demo: https://martinthomson.github.io/rfc-txt-html/diff.html > > This isn't perfect, but it seems pretty good to me. Keep in mind that > this took only a little bit of time to sketch out. No doubt it can be > improved. The readme has a bunch of things I found, all minor. > > I don't think that this is the end of text, but a possible way to limit > our use of the htmlizer[1]. People who need to automate access to content > might still use text, though I will argue that XML is superior in that > regard. The other thing that comes to mind is diffs: HTML-native diff > tools are somewhat less than ideal. Either way, serving HTML is just > better. > > Enjoy, > Martin > > > [1] Though I still see a shocking number of people authoring in XML (or > XML-capable input formats) and submitting in text. But I think we have > plans to limit that. > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): > https://www.ietf.org/mailman/listinfo/tools-discuss > --000000000000d9cca405c825a6bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW, I generally do reviews by pulling the .txt file= into my editor and then
cutting and pasting the pieces I want to= respond to. Presumably I could find
some way to make that work w= ith HTML if we ditched the text format entirely
though it would p= robably be somewhat less convenient.

-Ekr


On Tue, Jul 27, 2021 at 6:54 PM Martin Thomson <mt@lowentropy.net> wrote:
I realize that this might be a li= ttle inflammatory as far as subjects go, but bear with me.

There are probably a few narrow cases where rendering plain text is better = than HTML.=C2=A0 But what we've been doing for years (thanks to Henrik&= #39;s great tool) is take text and turn it into HTML using the power of reg= ular expressions.=C2=A0 That's been good, but it's not always relia= ble (how many errata mention that "Section X of [FOO]" links to S= ection X of this document?).=C2=A0 It's also been lagging as the text f= ormat changed (case in point: lack of a table of contents).

Here's an alternative: style the HTML so that it looks like the text.= =C2=A0 I tried this and it worked shockingly well.

Repo: https://github.com/martinthomson/rfc-txt-html=
Demo: https://martinthomson.github.io/rfc-txt-= html/diff.html

This isn't perfect, but it seems pretty good to me.=C2=A0 Keep in mind = that this took only a little bit of time to sketch out. No doubt it can be = improved.=C2=A0 The readme has a bunch of things I found, all minor.

I don't think that this is the end of text, but a possible way to limit= our use of the htmlizer[1].=C2=A0 People who need to automate access to co= ntent might still use text, though I will argue that XML is superior in tha= t regard.=C2=A0 =C2=A0The other thing that comes to mind is diffs: HTML-nat= ive diff tools are somewhat less than ideal.=C2=A0 Either way, serving HTML= is just better.

Enjoy,
Martin


[1] Though I still see a shocking number of people authoring in XML (or XML= -capable input formats) and submitting in text.=C2=A0 But I think we have p= lans to limit that.

___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for discussion, not for action requests or bug reports.
* Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other bugs or issues to: ietf-action@ietf.org
List info (including how to Unsubscribe): https:/= /www.ietf.org/mailman/listinfo/tools-discuss
--000000000000d9cca405c825a6bb-- From nobody Tue Jul 27 19:22:42 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB18A3A1702 for ; Tue, 27 Jul 2021 19:22:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGRHEvehYOz6 for ; Tue, 27 Jul 2021 19:22:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B5153A1701 for ; Tue, 27 Jul 2021 19:22:36 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16S2MZj3077467 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 27 Jul 2021 21:22:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1627438956; bh=U6xeQTou8+ggvoQYCpvQyyTODcqELxfU278nRM6iRjE=; h=To:References:From:Subject:Date:In-Reply-To; b=e2Hf2a2NJ4Uxfs0/O0oizVnF03xbiQ+IeqKhTUUgDcPJzvW3FDa5mRW1lBOTgOjv+ 8p8QBOETGWgNHIQSgFgaz3it2KhbOvEDWpe9ADXrqeiqc0xVGf2O7tuRh3Wph5Hl8o J/Fl5IdDxIpx80loiSyeRkHBUtMtc4so4OIG0AHw= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: tools-discuss@ietf.org References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> From: Robert Sparks Message-ID: <14bd112c-fd34-44ce-dcbc-9f3b989cdd7d@nostrum.com> Date: Tue, 27 Jul 2021 21:22:30 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 02:22:41 -0000 This is worth exploring, but a few things: First thought - we have some thousands of RFCs that only exist as txt,=20 so I'm reading your argument as "for new things", but keep in mind we=20 often have to process both old and new things (think diff). Second thought - diff. You and I have discussed some potential=20 candidates for html-diff that would rival the text diff for visual=20 inspection, and they're still not-quite there. And when it comes down to = some things, diffing text is still going to be the best generalizable=20 tool. XML-diffing continues to be more of a stretch than it intuitively=20 appears. (I think there's an argument here for keeping as much work that = would involve diffing as we can in a language like markdown, but...) Third thought - an alternative already brought up (Carsten I think was=20 first) to html-ization for the things we have v3 xml for is to create a=20 writer for it that builds it from the xml source rather than trying to=20 pull things by heuristics from the text. Maybe where you're pointing=20 would obviate that, but there may be different decisions to make in that = writer that would be advantageous. And finally, to your footnote, raising "why aren't people submitting=20 XML?" - I've seen recently that there is fear from some seasoned=20 submitters that the processor at the datatracker will get the references = wrong. This is tied up with working in v2 and the issues we are working=20 to correct with bibxml generation. Mitigating that fear will have an=20 impact on the xml submission rate, I think. RjS On 7/27/21 8:53 PM, Martin Thomson wrote: > I realize that this might be a little inflammatory as far as subjects g= o, but bear with me. > > There are probably a few narrow cases where rendering plain text is bet= ter than HTML. But what we've been doing for years (thanks to Henrik's g= reat tool) is take text and turn it into HTML using the power of regular = expressions. That's been good, but it's not always reliable (how many er= rata mention that "Section X of [FOO]" links to Section X of this documen= t?). It's also been lagging as the text format changed (case in point: l= ack of a table of contents). > > Here's an alternative: style the HTML so that it looks like the text. = I tried this and it worked shockingly well. > > Repo: https://github.com/martinthomson/rfc-txt-html > Demo: https://martinthomson.github.io/rfc-txt-html/diff.html > > This isn't perfect, but it seems pretty good to me. Keep in mind that = this took only a little bit of time to sketch out. No doubt it can be imp= roved. The readme has a bunch of things I found, all minor. > > I don't think that this is the end of text, but a possible way to limit= our use of the htmlizer[1]. People who need to automate access to conte= nt might still use text, though I will argue that XML is superior in that= regard. The other thing that comes to mind is diffs: HTML-native diff = tools are somewhat less than ideal. Either way, serving HTML is just bet= ter. > > Enjoy, > Martin > > > [1] Though I still see a shocking number of people authoring in XML (or= XML-capable input formats) and submitting in text. But I think we have = plans to limit that. > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.= org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/= listinfo/tools-discuss From nobody Tue Jul 27 23:59:23 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086C83A207E for ; Tue, 27 Jul 2021 23:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=m33sCQw9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qHCwYmcp 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 7vuapTxR8dWz for ; Tue, 27 Jul 2021 23:59:17 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 002113A207D for ; Tue, 27 Jul 2021 23:59:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 06CBF5C00D0 for ; Wed, 28 Jul 2021 02:59:16 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Wed, 28 Jul 2021 02:59:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=8GGdWe1iTIwcmSizV9kkC9ax3Q0GpVo Nt4S8+s/KZ4c=; b=m33sCQw9m6fACsuwstVCBAesEyeBEVx1EgEXLM6CXASjll9 WuTMsIHlCTI+HvOfMbxFO9Sq2hkq/L3PNqnX4bcu+hgK592hvAfYEKSSMz3VRkoG iD3JMV+8MxfOQaUnbCfGLeZfrwDvI+fzGR7DZRcc+BBTdiFU71T98x9n3E4AWPSg v88wDu10ePtSdiLc8SZGiZNiJ3SGFv9ob5VFs1XA5nYNcLYOSENmnSBq33gcfeK6 FbsYUoxMN2uO3ZhCuZjeiKHeiDb9axiby+Wt/6OeGcWpNyp3zehKhAD0I2j/OCW/ HQTsovFvLjX6pKzVUpNlk3OW+Lxh1rwuPprRSsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8GGdWe 1iTIwcmSizV9kkC9ax3Q0GpVoNt4S8+s/KZ4c=; b=qHCwYmcpbLlkQFQMMm9bEI yzpUZ2/Ljf7srFb2x7O8okv8qVsAkjI/0UIbof8T66yw8NlPkqTT9hkhOkJet3oo xIsaaBBDWiECmlA3C9Pm95f94sHfqRXRlB726HBNWYAdI9k19IQ4FJl0Z33eVq0E s2b8U5rRoKYoiQiQzC7CsUly0I1IjnlCZcC9+Tnx9YifaKGH4gO6e0qc5YrB1cnu q/WbeOrWFIVNWWB00OUamgy1rOpHpfHYLU6sSGTbhDaNjQoAYWtoweqG8a9xfzIm FnpbK+za0mRdB9Ehd2lhdt7CNH3+gj2FFw4Qu+eTsUSZ36j/EQh+Xhhhbb59MW1w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeekgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 86A333C0471; Wed, 28 Jul 2021 02:59:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-545-g7a4eea542e-fm-20210727.001-g7a4eea54 Mime-Version: 1.0 Message-Id: <4e967ce8-618d-4c00-b873-e6b64b54659a@www.fastmail.com> In-Reply-To: <14bd112c-fd34-44ce-dcbc-9f3b989cdd7d@nostrum.com> References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <14bd112c-fd34-44ce-dcbc-9f3b989cdd7d@nostrum.com> Date: Wed, 28 Jul 2021 16:59:00 +1000 From: "Martin Thomson" To: tools-discuss@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 06:59:22 -0000 On Wed, Jul 28, 2021, at 12:22, Robert Sparks wrote: > "for new things" Of course. Anything that is in v3 format could get this treatment. > diff Yeah, I noted that. It is clear to me that HTML tools are just not good enough. Oddly, this is not because they couldn't just diff the text, but because they try to do so much more, like capture style or element choice changes as well as text changes. For this, and for Ekr's use case, or anything where the goal is to remove noise, having text renderings available is useful. My pitch here is mostly about the most common case, which is people reading the documents in a web browser (and maybe those who print them too). Keeping text because people have processes or tools that rely on text is probably necessary, if only because that means being able to present the entire series in a nominally consistent format. I do think that the htmlizer can go in that case. > create a writer for it that builds it from the xml source rather than trying to > pull things by heuristics from the text. Yeah, this is a neat idea, and it would avoid some of the issues I've discovered. That said, the marginal benefit for the engineering cost involved seems unjustified in light of the HTML restyling option here. > the processor at the datatracker will get the references wrong. Interesting. Is this because people use some combination of entity references and processing instructions and fear that those will be filled in poorly? That seems like a reasonable concern. Part of it might derive from the fact that people have their own (skewed or hacked) local reference caches that they want to use in generating the final output. I believe that xml2rfc can already produce XML with inline references, which draws from local sources. Maybe we just need to document that process better for those people. That and make the entire references infrastructure more reliable. I routinely have build failures due to reference fetches that fail. From nobody Wed Jul 28 00:33:36 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699A53A216E for ; Wed, 28 Jul 2021 00:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 jvw9CC8ZTQ2Z for ; Wed, 28 Jul 2021 00:33:31 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B123A216D for ; Wed, 28 Jul 2021 00:33:30 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GZQPg31nGz2xLr; Wed, 28 Jul 2021 09:33:27 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <14bd112c-fd34-44ce-dcbc-9f3b989cdd7d@nostrum.com> Date: Wed, 28 Jul 2021 09:33:26 +0200 Cc: tools-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <24E8E5F1-0492-49F8-8BA5-5A3E8D246BEC@tzi.org> References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <14bd112c-fd34-44ce-dcbc-9f3b989cdd7d@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 07:33:35 -0000 On 28. Jul 2021, at 04:22, Robert Sparks wrote: >=20 > And finally, to your footnote, raising "why aren't people submitting = XML?" - I've seen recently that there is fear from some seasoned = submitters that the processor at the datatracker will get the references = wrong. This is tied up with working in v2 and the issues we are working = to correct with bibxml generation. Mitigating that fear will have an = impact on the xml submission rate, I think. Until recently, submitting TXT was the easy way to work around the = mistreatment of hybrid XML by the submission process(*). It will take some time until that gets out of people=E2=80=99s head. The htmlizer did a mostly useful service for v2 users that the HTML = output did not have: Adding links for section references. V3 can now do that, but it requires conscious keyboarding(**); htmlizer = completely automated that (but got it wrong occasionally). I wrote a small PoC for a database of places where htmlizer gets it = wrong with the necessary substitutions. The cognitive barrier that v2 is obsolete might prevent that feature = from happening. Gr=C3=BC=C3=9Fe, Carsten (*) People used to submit TXT for most of the life of the I-D = repository. Then it became possible to submit XML along with that, which didn=E2=80=99= t add anything except for archiving the XML as well. But when the submission process started rejecting or mishandling = submissions because XML came with them, everybody learned that it is a = bad idea to send the XML, and TXT it was, again. (**) Of course, in kramdown-rfc, Section 4.2.1 of {{RFC8949}} simply becomes {{Section 4.2.1 of RFC8949}} but for people keyboarding XML, manually adding section references is a = bit more nightmarish: =46rom a recent AUTH48 (which still forces me to get in contact with = XML): IANA has created a new "" subregistry within the "Sensor Measurement Lists (SenML)" registry with the I can=E2=80=99t blame people who don=E2=80=99t want to make that effort. From nobody Wed Jul 28 01:57:50 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE23A2405 for ; Wed, 28 Jul 2021 01:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.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 ur3eMVPOfb3B for ; Wed, 28 Jul 2021 01:57:43 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 B21373A2401 for ; Wed, 28 Jul 2021 01:57:43 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 1C13960035D; Wed, 28 Jul 2021 11:57:37 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1627462657; bh=p7WKy4bo7NIUNG1UIn5OBPGi1AgmRiMqE9byFNqumME=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=hLk1jpmABzcWZxmGX7lE3Xi9jYBHxvcAeN9dWmYmWPK76NVfb6WrX9XXj7OuP1kxP L+hMJYZs2H32xdGUe3Zg8jm6QBA6Ww6FaDHzQDN4r4C7sG/yC69qn0AocmRVZ6uXis MiWUeYLcMn+06yVEXD33Hm0yrbHJ0DXv/+w5t60U= From: Lars Eggert Message-Id: <228E9B32-2E65-46FA-9330-28E1AA3FA39A@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_081651D5-9546-4AEF-93AE-0F6C51CAF088"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Wed, 28 Jul 2021 11:57:36 +0300 In-Reply-To: Cc: Martin Thomson , tools-discuss To: Eric Rescorla References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> X-MailScanner-ID: 1C13960035D.A5511 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 08:57:49 -0000 --Apple-Mail=_081651D5-9546-4AEF-93AE-0F6C51CAF088 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2021-7-28, at 5:21, Eric Rescorla wrote: > FWIW, I generally do reviews by pulling the .txt file into my editor = and then > cutting and pasting the pieces I want to respond to. Presumably I = could find > some way to make that work with HTML if we ditched the text format = entirely > though it would probably be somewhat less convenient. w3m -dump https://martinthomson.github.io/rfc-txt-html/rfc9000.html (There are some paragraph marks in the output that I'm sure can be = turned off somehow with an option or further posprocessing.) Thanks, Lars --Apple-Mail=_081651D5-9546-4AEF-93AE-0F6C51CAF088 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEBHAAACgkQVLXDCb9w wVdt4A/+P7Z2c93LIwiYks1UWtMLUIHGxu6RwiM89dg05UPqfBXqgDaDrPyJf+R1 NyoMv5wxWr+yR4gyH033EAxnkP98Imdz8zwQ4+UDm1zEZs4rPRAsdQX3LFnB+HF4 3T6IIa1hswA+PbhvuX2pNRsIlhSTnanz/Hf8tllCFwXQIIZwwM+vNY2BbHrLSsEl KjPdlXa4lwJ64gvHlMq61+lZ+4hTzwzkECiXjBUmCWtaqHvddwXOzp5cdzqKMaKw 05pC8IwW6XxKNL+jYEXol29sRt0QQii/NyC0tKXXRWW9RiIbnqYUtn0JMK0OyxiN zq02McSLE8KmuWfPtLNJlwbfuaxLepfB2K/80NCuWjb85cHNrw4tGRqWfRTPHYNk hCsBX0lNSXRdKLx8DItQ/26NRUFy2LoVdUGK/asT51AKbisrAGjETjsg9KmslklI 3DcdRzqLP59IxkPz/IRqpoivQY8kjlWjHj6ILYz0qyjUfaFyuyFbzXFgUfXMRxOv 8ZrP9aebiZYicleq20UeXPDLRFfmVj5rYgBt4fqi1EYYvqNNijay8YLdX6t9sP2w 6XBNWAA8E8MPGfKL2chrn98JSIT6c3leIEFbJRu5sha29VUPbKSQz5B81vZDTs2C KGJ+M8NWGb/JOYX6CImOaYoxoFeZoN68fS4VIBAwAgjYXBZ/rM0= =P891 -----END PGP SIGNATURE----- --Apple-Mail=_081651D5-9546-4AEF-93AE-0F6C51CAF088-- From nobody Wed Jul 28 05:49:47 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856B43A0DD3 for ; Wed, 28 Jul 2021 05:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 57xE7oXXWyrL for ; Wed, 28 Jul 2021 05:49:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4B83A0DD6 for ; Wed, 28 Jul 2021 05:49:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3A0E91E1D0; Wed, 28 Jul 2021 08:49:41 -0400 (EDT) Date: Wed, 28 Jul 2021 08:49:41 -0400 From: Jeffrey Haas To: tools-discuss@ietf.org Message-ID: <20210728124940.GA24015@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Tools-discuss] IETF 111 Meetecho quirks X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 12:49:45 -0000 Greetings, These observations come from after chairing the IETF 111 IDR session. In general, Meetecho continues to improve. Please consider these minor bug reports. - Whole screen sharing on a Mac (Big Sur) running Firefox 89.0.2 doesn't fully handle screen refreshes when changing displayed PDF slides from the browser. - After being pointed to the newer feature to display converted slides from the meetings materials, two of our posted slide decks to the meetings materials were not available for conversion. These were: + 04-BGP MPLS-namespaces: Improve Scaling and Convergence in Seamless-MPLS networks + 05-Generic Metric for the AIGP attribute - The new converted materials, when presented from meetecho, work smoothly. However, an incoming chat or hand-raise will cover the UI element for accessing the next slides. -- Jeff From nobody Wed Jul 28 07:32:04 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7763A12C5 for ; Wed, 28 Jul 2021 07:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, 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 WTcc0DrnTDbx for ; Wed, 28 Jul 2021 07:31:58 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41D73A12C3 for ; Wed, 28 Jul 2021 07:31:57 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4D222548053; Wed, 28 Jul 2021 16:31:52 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 40A4E4E7B8B; Wed, 28 Jul 2021 16:31:52 +0200 (CEST) Date: Wed, 28 Jul 2021 16:31:52 +0200 From: Toerless Eckert To: Martin Thomson Cc: tools-discuss@ietf.org Message-ID: <20210728143152.GA57091@faui48e.informatik.uni-erlangen.de> References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 14:32:03 -0000 a) As mentioned in before, i would love for datatracker to offer the option for users to choose or even upload an html style sheet which would then be used for rendering of datatracker drafta/RFC for them. This IMHO would be the most easy and useful starting point to leverage the flexibility of HTML. b) I can not see any way to move away from a pure text editor for all core work - writing drafts and commenting on them. I can see that this can be done with either a txt or a markdown version of drafts/RFCs, not with HTML/XML. c) RFCdiff is a big thing for me, i guess that can evolve to use other imputs than just txt over time. Cheers Toerless On Wed, Jul 28, 2021 at 11:53:49AM +1000, Martin Thomson wrote: > I realize that this might be a little inflammatory as far as subjects go, but bear with me. > > There are probably a few narrow cases where rendering plain text is better than HTML. But what we've been doing for years (thanks to Henrik's great tool) is take text and turn it into HTML using the power of regular expressions. That's been good, but it's not always reliable (how many errata mention that "Section X of [FOO]" links to Section X of this document?). It's also been lagging as the text format changed (case in point: lack of a table of contents). > > Here's an alternative: style the HTML so that it looks like the text. I tried this and it worked shockingly well. > > Repo: https://github.com/martinthomson/rfc-txt-html > Demo: https://martinthomson.github.io/rfc-txt-html/diff.html > > This isn't perfect, but it seems pretty good to me. Keep in mind that this took only a little bit of time to sketch out. No doubt it can be improved. The readme has a bunch of things I found, all minor. > > I don't think that this is the end of text, but a possible way to limit our use of the htmlizer[1]. People who need to automate access to content might still use text, though I will argue that XML is superior in that regard. The other thing that comes to mind is diffs: HTML-native diff tools are somewhat less than ideal. Either way, serving HTML is just better. > > Enjoy, > Martin > > > [1] Though I still see a shocking number of people authoring in XML (or XML-capable input formats) and submitting in text. But I think we have plans to limit that. > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss -- --- tte@cs.fau.de From nobody Wed Jul 28 08:43:01 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E271F3A15C6 for ; Wed, 28 Jul 2021 08:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vspeEvsaKSdu for ; Wed, 28 Jul 2021 08:42:54 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 807D33A159E for ; Wed, 28 Jul 2021 08:42:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 70F14389B4; Wed, 28 Jul 2021 11:46:37 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EL7NhIznfAfJ; Wed, 28 Jul 2021 11:46:32 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A2653899A; Wed, 28 Jul 2021 11:46:32 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 984F615B; Wed, 28 Jul 2021 11:42:42 -0400 (EDT) From: Michael Richardson To: "Martin Thomson" , tools-discuss@ietf.org In-Reply-To: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 15:43:00 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Thomson wrote: > I realize that this might be a little inflammatory as far as subjects > go, but bear with me. > There are probably a few narrow cases where rendering plain text is > better than HTML. The time when it's nice to have actual .txt files is when writing code, and one needs to search for, and then copy and pasting bits of requirement into= the code. But, if I'm really working on such a document, I can run xml2rfc -o text my= self. > Here's an alternative: style the HTML so that it looks like the text.= I tried this and it worked shockingly well. > Repo: https://github.com/martinthomson/rfc-txt-html > Demo: https://martinthomson.github.io/rfc-txt-html/diff.html > This isn't perfect, but it seems pretty good to me. I agree: it looks great. I also agree that we should obsolete the htmlizer. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEBevIACgkQgItw+93Q 3WUaewf7BMy3ACy5tmoev1GYQV+i2qWbigJPSREOBZrWKU7/Z8rmwju7GPcz+/eK VOD/IV9gDMqgG2AzhOhzxfQ8gxlKWenmULFQTJijlAroXldZWk9IHkkwdVUZpkHh jCRLZuNzhzYpPsiVWMmsyC9wAHPKB/nyryUOcQ45Em2wYqhshNB7F0pUtqiIf2b7 yMA4sj0jIe2qIL1VygK3SpFVC3lpfI5N3u+FZE7QCsTaqcC+ZCQaB9y+zpZ4ne+q uxOKm5u1Rv8lnZlOnxUXhVC4bBzh7SzshDCaUpTm4XuOnECPxRkyxXeCicKbncG/ 7W9QvjsWnNuCE+5GOi64a+wo9Ic5UA== =90Zp -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jul 28 09:00:41 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AC43A15BD for ; Wed, 28 Jul 2021 09:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhnlTzkGDPKY for ; Wed, 28 Jul 2021 09:00:34 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F6B3A15BA for ; Wed, 28 Jul 2021 09:00:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D07D2300BE8 for ; Wed, 28 Jul 2021 12:00:33 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lZYtRTOorikS for ; Wed, 28 Jul 2021 12:00:32 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 35984300231; Wed, 28 Jul 2021 12:00:32 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <19431.1627486962@localhost> Date: Wed, 28 Jul 2021 12:00:31 -0400 Cc: Tools Team Discussion Content-Transfer-Encoding: quoted-printable Message-Id: References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <19431.1627486962@localhost> To: Michael Richardson , Martin Thomson X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 16:00:39 -0000 Others have already said how important diff is to their work. Review = team members, especially checking whether previous comments were = addressed, use diff heavily. I have a script to run diff locally when I = am not online. The online diff and my script depend on text files. Russ > On Jul 28, 2021, at 11:42 AM, Michael Richardson = wrote: >=20 > Signed PGP part >=20 > Martin Thomson wrote: >> I realize that this might be a little inflammatory as far as subjects >> go, but bear with me. >=20 >> There are probably a few narrow cases where rendering plain text is >> better than HTML. >=20 > The time when it's nice to have actual .txt files is when writing = code, and > one needs to search for, and then copy and pasting bits of requirement = into the code. > But, if I'm really working on such a document, I can run xml2rfc -o = text myself. >=20 >> Here's an alternative: style the HTML so that it looks like the text. = I tried this and it worked shockingly well. >=20 >> Repo: https://github.com/martinthomson/rfc-txt-html >> Demo: https://martinthomson.github.io/rfc-txt-html/diff.html >=20 >> This isn't perfect, but it seems pretty good to me. >=20 > I agree: it looks great. > I also agree that we should obsolete the htmlizer. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 From nobody Wed Jul 28 09:15:53 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05263A165C for ; Wed, 28 Jul 2021 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWIZlHRpw5oS for ; Wed, 28 Jul 2021 09:15:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FE923A1659 for ; Wed, 28 Jul 2021 09:15:46 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16SGFhRe034718 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 28 Jul 2021 11:15:43 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1627488944; bh=H3S2oq7leRFfHz0dlwPaZ6lQPeQwzTOq8rvc6ODXrR0=; h=Subject:To:References:From:Date:In-Reply-To; b=gOV34Fqy2/bBQ8+neSxjoMw34RkeeJbvJUQMwbvZnhmIAlrA/Oi2prauLBGSZjS/S TtpIg83AIFE8rslcjS8ywoNpm5uNIoX/07dQDQb7ZdLfQX8AnAMoMtFfNkc/5+trhC 6uAkADzlJrqvIlrOiF2vvHvkxHbMBcupGLgHV+A0= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: tools-discuss@ietf.org References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <19431.1627486962@localhost> From: Robert Sparks Message-ID: Date: Wed, 28 Jul 2021 11:15:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <19431.1627486962@localhost> Content-Type: multipart/alternative; boundary="------------F97270E3DE1D5DA798DED241" Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 16:15:52 -0000 This is a multi-part message in MIME format. --------------F97270E3DE1D5DA798DED241 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/28/21 10:42 AM, Michael Richardson wrote: > Martin Thomson wrote: > > I realize that this might be a little inflammatory as far as subjects > > go, but bear with me. > > > There are probably a few narrow cases where rendering plain text is > > better than HTML. > > The time when it's nice to have actual .txt files is when writing code, and > one needs to search for, and then copy and pasting bits of requirement into the code. > But, if I'm really working on such a document, I can run xml2rfc -o text myself. > > > Here's an alternative: style the HTML so that it looks like the text. I tried this and it worked shockingly well. > > > Repo: https://github.com/martinthomson/rfc-txt-html > > Demo: https://martinthomson.github.io/rfc-txt-html/diff.html > > > This isn't perfect, but it seems pretty good to me. > > I agree: it looks great. > I also agree that we should obsolete the htmlizer. I don't think we can - what do you want to show for older RFCs? I think people expect the html-ized version, and we can't render v3 html for those. Further - the discussion so far is ignoring (or presuming a change in) the large set of submissions we get now (as plain text) that do not have rfcxml anywhere in their production process. > > -- > Michael Richardson . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss --------------F97270E3DE1D5DA798DED241 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/28/21 10:42 AM, Michael Richardson wrote:
Martin Thomson <mt@lowentropy.net> wrote:
    > I realize that this might be a little inflammatory as far as subjects
    > go, but bear with me.

    > There are probably a few narrow cases where rendering plain text is
    > better than HTML.

The time when it's nice to have actual .txt files is when writing code, and
one needs to search for, and then copy and pasting bits of requirement into the code.
But, if I'm really working on such a document, I can run xml2rfc -o text myself.

    > Here's an alternative: style the HTML so that it looks like the text.  I tried this and it worked shockingly well.

    > Repo: https://github.com/martinthomson/rfc-txt-html
    > Demo: https://martinthomson.github.io/rfc-txt-html/diff.html

    > This isn't perfect, but it seems pretty good to me.

I agree: it looks great.
I also agree that we should obsolete the htmlizer.

I don't think we can - what do you want to show for older RFCs? I think people expect the html-ized version, and we can't render v3 html for those.

Further - the discussion so far is ignoring (or presuming a change in) the large set of submissions we get now (as plain text) that do not have rfcxml anywhere in their production process.


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for discussion, not for action requests or bug reports.
* Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other bugs or issues to: ietf-action@ietf.org
List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
--------------F97270E3DE1D5DA798DED241-- From nobody Wed Jul 28 09:50:41 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37813A09DF for ; Wed, 28 Jul 2021 09:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 XyTD9uR-Nwn9 for ; Wed, 28 Jul 2021 09:50:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 F320A3A098B for ; Wed, 28 Jul 2021 09:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1627491032; bh=+sI2b2hDVxMPizKlHsWoFIUUY6scdPg3jEF/ss2srPE=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=gJLMRIXf/stzoPqPu2a7ezhTsQwv+pUlJKPDRg8I9V69KAQugHa64kEzastrNqll2 HGO2PVcM/c0uiPUYXvCgExkNDM2FQljtg6SR7GKRXBT6vjcqkke1zaXw1l7rD9/EdV Q7C1ijYFrHkhdnNGiaao0xs8bj5qQT5fIdP6g7OU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.16.44] ([212.205.152.82]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MEV3I-1mOm8I0ugk-00Fy3Y for ; Wed, 28 Jul 2021 18:50:32 +0200 To: tools-discuss@ietf.org References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <19431.1627486962@localhost> From: Julian Reschke Message-ID: Date: Wed, 28 Jul 2021 18:50:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <19431.1627486962@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:uDMm33aRXig6dkBYuBCy2IqhHbSeu6VSeeykwREycWTYnTv6C6L P0Whbr/C0WuFGLlPNOFOcVBjiyUf//b4XI4ZRpCWABr2EEZmYiIlLwIrYO2eaPZRzGzzOP/ FStWhUfsa0GHG69eVZvK7C8CxBEnBhCdBvwOaY4BBnbBrKUQbHArpinZJHjekuFUl/PECsU sibw4ZpN+EhIgxZGhZg9w== X-UI-Out-Filterresults: notjunk:1;V03:K0:TxCrF7+sFnw=:M61Jd/lIZAemZkbRWkDSQt XHMJ6b1wIV79j08uPPK3DoolcFjKW4/uomEAk4++SF8Wicva4lMsc71cAoh/7HJ1u1bY+MLjB J74JTJox80vFr+8VhiWF3LdAj3qe/Fp6UZ/b75x+awYNZoeJGXz+tCOzaBhj+JoCr+KGwtLhA Itfn6uX89zs/6ldHoRK1QMMiwum0ytfYaF6GvmrHQZw5u2SQY4hMlIpZNULlLX9BTJQSqPyLK 77A+vNED+nNAv7WOS3MXrOfnr263bnIPC4RFbSFWwURIN2WfM4Kctu7J/mGt95Mwso9pWDHj8 RVvUQkfZL8GZ5i/EV6pfMcV2HaOxUflUgTmUDGyu45RytuQeV5M/GoHWqGEvzu+xTSt8GkBsY m8BCwP1Mf+Sdib5pspRnh+FVcLRUfP8elFb2KfkUTZyFiV9YvYmfm8QQogBHaWneN/tEaH2KN Z1pVVPJHmZSVbyxh2gOX1mzeKyyrd20SqWPtAfsW4TlLORZ19onJ25xrpMlo650P313kcusrJ Xj8YwQKuWUQBwu3R93Rdpi7WUMu2xEMm5fYioXuSB72tQUHeXqsA0rxumcloygJ13jpA021Go IRw7Irvq5F3YbRQuEt4KgWj0x0YybX+kkjQLlVb14bxAz5jRxs7EKyaiB+s5J2lsoJown3yyt xfL3WQLiNpZ0R0IF4WaO0hOO1Jdm7jCXAfkuxGaULigkGx4Ca1kjTia1TebImWkmLaqe7/xlw 8amTLE6IIgSNZkkNTRnRc7mLg19nsKHLmCP0Mc0hqzYyUIvqwEwtyVpI7yqStRX0UNrEk45er mtuvqW06kfNd4WkmBKoXw95z/nVdQWWsxrudO7b1gHFur9Pp3xuLKtvt8UsQPcM9OzDKrFuoX R3RxWIIvpBKz2Lv5/ko6m0DLKmwUtiWsUVA/OFtS5b05lGjyuo//qR15MPWMRFkkhcEZdFWxr qVnvK7cau03Uq21WXvD1cNZGLdw+UqM+VfVAlsEKklh9J4hJdX47S/4rPzT5B1DfMiFRv/GiM 6sq6E7gmrRXnRwKSTamBuNGQY1t5g32u/CXIyU+M+wcmuxBSOp1GFOEA8tqcQb0QRg0yg0Cg/ wh+rj0TQ60xbDqahuB717BApa5KMZrUR6Ym1zHzD4Alv/ZP6RVor1CKHA== Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 16:50:40 -0000 Am 28.07.2021 um 17:42 schrieb Michael Richardson: > > Martin Thomson wrote: > > I realize that this might be a little inflammatory as far as subj= ects > > go, but bear with me. > > > There are probably a few narrow cases where rendering plain text = is > > better than HTML. > > The time when it's nice to have actual .txt files is when writing code, = and > one needs to search for, and then copy and pasting bits of requirement i= nto the code. > ... Why exactly doesn't that work for HTML? Loss of line breaks in prose? Best regards, Julian From nobody Wed Jul 28 10:15:11 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DF53A18C4 for ; Wed, 28 Jul 2021 10:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_FAIL=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 p30vABeN6flA for ; Wed, 28 Jul 2021 10:15:06 -0700 (PDT) Received: from implementers.org (implementers.org [92.243.22.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126373A18D0 for ; Wed, 28 Jul 2021 10:15:05 -0700 (PDT) Received: from [IPv6:2601:204:e600:411:d250:99ff:fedf:93cd] (unknown [IPv6:2601:204:e600:411:d250:99ff:fedf:93cd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id F2EDEAE269 for ; Wed, 28 Jul 2021 19:15:02 +0200 (CEST) From: Marc Petit-Huguenin To: Tools Discussion Message-ID: Date: Wed, 28 Jul 2021 10:15:01 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2021 17:15:11 -0000 Hi, We had this discussion already on ietf@ (https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/), but the problem is still there. Anything from arXiv is indexed, so I do not see why Internet-Drafts could not get the same treatment. It in fact put IETFers at a disadvantage. What need to be done, and how can I help? Thanks. -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug From nobody Wed Jul 28 20:40:02 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB1F3A141A for ; Wed, 28 Jul 2021 20:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=I0IU1GMK; dkim=pass (2048-bit key) header.d=taugh.com header.b=l9n5uekO 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 zQEX3Nyi0IUV for ; Wed, 28 Jul 2021 20:39:55 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54063A1415 for ; Wed, 28 Jul 2021 20:39:54 -0700 (PDT) Received: (qmail 38594 invoked from network); 29 Jul 2021 03:39:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=96c0.61022309.k2107; bh=O9VtexCXRM7/cYnFKqy73AGna5VEimKmnAOXhWrbbc8=; b=I0IU1GMK8WNERaWQiXqN608+byWLqUV1wCdrASbkbCMeaJGhBc0d8n+z52qHeXg5MSlBWGZfAcOJFaqEnj84ijWfn/liDnKBnW7HVyXEjmXmMLs1jk0W+doMRgfhuH92P76ugQlplQ1kZ2x+oFp8C7WZgBWMZFX3kIs2UG1OKyZBEZwvcTGni5dNjzUQBk5GrQr+tXtXMlyil/L2BAHNAUefrPa314yZw92Z4KJgfLX0WhvLXPV52kFJPknvMGbHU2Y59nx/Mmy2xfPXRhN5s3hmt2ow2Hx1RTJeOThxy90aGATk7h7H96KBu1boWuWkEp8GfpUw5pKcKhDDKsbBWQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=96c0.61022309.k2107; bh=O9VtexCXRM7/cYnFKqy73AGna5VEimKmnAOXhWrbbc8=; b=l9n5uekOf2ihDbuxEvy/TVfzghud4PnH/QV5ieQnEKMksAm+5+MFqJv0kOupGHF8j7KKhyNDSlaaqDnQo6+Ize7AlpyY93ScFQSECHNQ6toYwm/VMlHcVlNnY9dzOLdvAoFQUE1L1ZBBB+yNKLoX1YIM77Oc/oQZG9fmcBe1LlPD7s22V8jKMEIM0MoCdBsYB9Ze6rBuLMALU4NjRDjLw40kXw4xtbhPRySD73xDJOZBJEeiJJYOl6xFiwLxRUxglGFrSymlnPhp4olOXLAlou6RyRsqTnHyhrl1fTcKOXl45C02vJUrsk7bLTM6yx0h6TSbisjxck1x1g4zZgxF0A== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 29 Jul 2021 03:39:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 352A22548585; Wed, 28 Jul 2021 23:39:51 -0400 (EDT) Date: 28 Jul 2021 23:39:51 -0400 Message-Id: <20210729033952.352A22548585@ary.qy> From: "John Levine" To: tools-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 03:40:00 -0000 It appears that Marc Petit-Huguenin said: >Hi, > >We had this discussion already on ietf@ (https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/), but the problem is >still there. I thought we fixed it but I'll take a look. Might be meta tags, might be too convoluted paths from the home pages. R's, John From nobody Wed Jul 28 20:52:42 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 237C73A0766 for ; Wed, 28 Jul 2021 20:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=C8TUYWAo; dkim=pass (2048-bit key) header.d=taugh.com header.b=rNDvPXT9 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 Cec_wp1sD3DU for ; Wed, 28 Jul 2021 20:52:35 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF2D3A0765 for ; Wed, 28 Jul 2021 20:52:34 -0700 (PDT) Received: (qmail 40382 invoked from network); 29 Jul 2021 03:52:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=9dbb.61022602.k2107; bh=/vfwUQncj1t/D3JE4aYMJOzOoHxrsu6YrP+Zpky9I7w=; b=C8TUYWAoo+oEa64U2z32+whNzM/4IQG9p98VAF52psBj/Ahw1T0YwdpMvDhMY+J/EyVuBNa/TX9OPwp/+BJAXDEsKx7QVjcwY8U0etHBABPMA3qMVhlZRRG2/EJnWYQcm51VldWlYV4FFDYodiM0McbKYSfdAvyJwPWKSGr4Ip5Hw10czBYFsObwj0/5oOKOSh6EPehnfDy55oYGu/hfF8T2Vs9DXyRWuK+V14VLlFyjkD3KOMg6qTPAinCUKbFiYfcScSJF1MDV4+/S9EXNUlxUADPNR4ql0nACv2utkpv191ZFHQQIFuEdT3pkisEPQYWjQ+mEHN6I53m2YLxmIQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=9dbb.61022602.k2107; bh=/vfwUQncj1t/D3JE4aYMJOzOoHxrsu6YrP+Zpky9I7w=; b=rNDvPXT9NvY2wGE/AAykTlDnL3E7n6akHn7gWv4CsBPndw3fph9TjQsGlGf28wUhBfUcUAVt876RnDf1RkM7Z2cwbB/OK5gEi0OoZc0EcodKzljMfAaImb5iRIVFZAdJCseKpfrdZQqW6VHHZFnAWh0azLH7Vj0wfnJDf4bn+f/SBEkQTW3ljPZa8w8hcy2UdSWYLSGb8hUEuGw0nd4BxKmEkfnXmA2MgNOJCQjoro9ZW6IHLNOqQT1LzXIdq8YKccIawid5OlVy0VL3foaLK2u/KiULI0QS+fstsxxydcd5bBFA2xjMV3fPRjfNcRX4rnAT2sxDW9T6OvYf0HBEiQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 29 Jul 2021 03:52:33 -0000 Received: by ary.qy (Postfix, from userid 501) id EF66B254891D; Wed, 28 Jul 2021 23:52:32 -0400 (EDT) Date: 28 Jul 2021 23:52:32 -0400 Message-Id: <20210729035232.EF66B254891D@ary.qy> From: "John Levine" To: tools-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 03:52:40 -0000 It appears that Marc Petit-Huguenin said: >Hi, > >We had this discussion already on ietf@ (https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/), but the problem is >still there. > >Anything from arXiv is indexed, so I do not see why Internet-Drafts could not get the same treatment. It in fact put IETFers at a disadvantage. They're not even indexing RFCs, other than some old ones where it finds copies that the ACM has. Yow. R's, John From nobody Wed Jul 28 21:02:25 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC593A0888 for ; Wed, 28 Jul 2021 21:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpFfvnGxVioC for ; Wed, 28 Jul 2021 21:02:14 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 0C9233A0886 for ; Wed, 28 Jul 2021 21:02:13 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id ds11-20020a17090b08cbb0290172f971883bso13526272pjb.1 for ; Wed, 28 Jul 2021 21:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=06GennXs6lbPCzP5y/wBHDjWu/44xjvbbwA1TmRdtEU=; b=aB4RyXSokxF7ZLl1ALGkczqxewhdYS9KV+eRohpKgt1XIGgjmqG2omqvOHw5xChhMf uI2L5x/coMmSGIyqXs4ucOl/qZtdWPmOX/D7U71n4eHZy+mqS8W5ZMqYCZtgaLMGaztK vgNOMti3vN5UAhAc5l9jcIGbblBwigacZR0ois04jaCjBgY6naLFALb/45q/DedxuZHf 9LP8sMTfG7YAPipeYcHmU5TRn01Qm0LG9SP4VASq+uKiM7Kf0zHThnaHACyMeJmHacr4 x6+X7102Mp/F3EqDvGoF/VN4KqCtGBxSSis+DqrgXsbL1Vt/fdTKnucFA8kU2h11nQuW wASg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=06GennXs6lbPCzP5y/wBHDjWu/44xjvbbwA1TmRdtEU=; b=XG+7/B8PzdMGRV9Sqt9r4f1UV6s5sH4KpHDP3dlpafRkKP+GKRLL2wbuizSDGcbjuS bX5Cgf280AWrPb8QIoIeBH130W6PPzOej3lQPTXAT2BWN3p894ttLlMfz1OvKq1uzk8m ecpYCEzt8Amobf3NeAFWa4Hl0DUB//h0ZnZysNKEePhLoBOzMTSrgFE6NLD89UIOrQlZ ec6+GjgxqqijzZ+/eyD2HFSl7iPMkxm/vG9uGgo2H4hNS4HGVz2IMPNpseDiqiuXI2WT UIJ50mXYu30VYdDU3A/hV2kGUAvaRgHdHvt+yd3KQoX4Tt3r/pk/qXq4ENTrdiLnTPdR KowQ== X-Gm-Message-State: AOAM531iYzsyPZtgBoLLrAISTg5F1ysG0L5h21EIintmgO9YUUTGuHs+ lna6sBGqCOT9O/Ksf68mOZFiCqfoXMgCDg== X-Google-Smtp-Source: ABdhPJzXfxX7bkIlp0RWdSnEDTAfxFntHAkjF7V+tLoMZSvviaH0OdtCOPzG7DmmFv6EZvndc9MkGQ== X-Received: by 2002:a17:90a:bf0a:: with SMTP id c10mr3110641pjs.59.1627531332732; Wed, 28 Jul 2021 21:02:12 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id k20sm7719433pji.3.2021.07.28.21.02.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 21:02:12 -0700 (PDT) To: John Levine , tools-discuss@ietf.org References: <20210729035232.EF66B254891D@ary.qy> From: Brian E Carpenter Message-ID: <8ce4aa93-c280-4857-b386-ded7d0197610@gmail.com> Date: Thu, 29 Jul 2021 16:02:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210729035232.EF66B254891D@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 04:02:19 -0000 On 29-Jul-21 15:52, John Levine wrote: > It appears that Marc Petit-Huguenin said: >> Hi, >> >> We had this discussion already on ietf@ (https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/), but the problem is >> still there. >> >> Anything from arXiv is indexed, so I do not see why Internet-Drafts could not get the same treatment. It in fact put IETFers at a disadvantage. > > They're not even indexing RFCs, other than some old ones where it finds copies that the ACM has. Yow. > It depends, apparently. They have RFC 8799 (cited by 3, and one of those citations was only published this month). Brian From nobody Thu Jul 29 09:41:49 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA703A0C35 for ; Thu, 29 Jul 2021 09:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.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 Cv57K3kJxOya for ; Thu, 29 Jul 2021 09:41:42 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E40083A0C29 for ; Thu, 29 Jul 2021 09:41:41 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id n6so8317188ljp.9 for ; Thu, 29 Jul 2021 09:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QbUMALV0Yz28TR1Wxq/h66Zr9Girx22HroFyh4VzYdY=; b=TZqwbOyMJFX57KDWhugBoGI9putejxoYIVVY6yR34tNfLGc8xcExgOlbs7wMXmCj34 NlsDSKOPR3b2+n294qYQi5gX596WDe4Ems46UNy2Sm7l7YFbwQXrr4rZvu6zwUdsia8v EJzggNi0WVQHK2yXCF0YuQwUbC+NzUC7jBbyzgeq8BJ+KtO07DZj4g0sQpu033QaY1u7 UDRA9IpTJOT0onPhRN3aAabNwSY/jTBY1ljtVDyS9rYtU0mYcS7xWOhmuY96k4oZdk0P IpSoEvEw2NnrLI23SBzuQOr5M8etToJCsznsYvp9LOByvKiLydpE46Cz9WGkdzdQoRsZ ZyJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QbUMALV0Yz28TR1Wxq/h66Zr9Girx22HroFyh4VzYdY=; b=eKmZuDDPspmRca0APRQhKvqtoz59m9HQq1Pu5U3m/V6YKdxt0z3rj3A4yEaXjS3gS0 dPHI3uEYRgoFewdVvE5T++ABx3Jd8ZUSiTTixHK2Jih1QcIXJwYlmPTEA65kNH4GGTpW 3EMwZk0rEzqs9xqds/maUlGLrX2kkPKKtszmtvb8t3KMZEc0j92tWr5dgTlnzB7oT2JW Ke9irftbrVqvzMT+OfJkhA7fZ/eyra9FiyWKLBOBO+dhv0PeCY/EgEqDVSGEKbeSi/Xd J2rcgM4eA8zdkZSEaXnHRnOltVqG6AFUcRYJeCqaVdB2YVCDjaz9+ugLcczalOTP57x+ CHrg== X-Gm-Message-State: AOAM533RLdiI7F+h5hMgsNnwl17U37VbpI0js6Xj/1pQ774NDKwuTfr0 o56VqUD9nocnfgvC4nPIxQDC2AZj89VkBhIV1zyy+UmphWIi4w== X-Google-Smtp-Source: ABdhPJwZLrkeP6D3Ucq/vyEbJKDoi464S1SuyyvYzWKjwC7P9LBxbyVzqUuK6Kg3Mc0WaLCA5iDhef4RSSAUpheSrfw= X-Received: by 2002:a2e:82d5:: with SMTP id n21mr3441780ljh.126.1627576898245; Thu, 29 Jul 2021 09:41:38 -0700 (PDT) MIME-Version: 1.0 References: <20210729035232.EF66B254891D@ary.qy> In-Reply-To: <20210729035232.EF66B254891D@ary.qy> From: Warren Kumari Date: Thu, 29 Jul 2021 12:41:02 -0400 Message-ID: To: John Levine Cc: Tools Discussion Content-Type: multipart/alternative; boundary="000000000000dd71ce05c845c602" Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 16:41:47 -0000 --000000000000dd71ce05c845c602 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 28, 2021 at 11:52 PM John Levine wrote: > It appears that Marc Petit-Huguenin said: > >Hi, > > > >We had this discussion already on ietf@ ( > https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/), > but the problem is > >still there. > > > >Anything from arXiv is indexed, so I do not see why Internet-Drafts coul= d > not get the same treatment. It in fact put IETFers at a disadvantage. > > They're not even indexing RFCs, other than some old ones where it finds > copies that the ACM has. Yow. > Citation needed. Searching for bits from the abstract of a random selection of recently published documents gives: https://www.google.com/search?q=3DThis+document+defines+a+BGP+path+attribut= e+known+as+the+%22Tunnel+Encapsulation+attribute%22 https://www.google.com/search?q=3D%22This+document+describes+a+new+Uniform+= Resource+Name+%28URN%29+namespace%22 https://www.google.com/search?q=3D%22This+document+defines+a+process+experi= ment+under+RFC+3933%22 In an incognito window, the RFC Editor result was the first, second or third result for all of these... W > > R's, > John > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.or= g > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): > https://www.ietf.org/mailman/listinfo/tools-discuss > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --000000000000dd71ce05c845c602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 28, 2021 at 11:52 PM Joh= n Levine <johnl@taugh.com> wro= te:
It appears t= hat Marc Petit-Huguenin <marc@petit-huguenin.org> said:
>Hi,
>
>We had this discussion already on ietf@ (https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz= 9lE-kFcrFGI/), but the problem is
>still there.
>
>Anything from arXiv is indexed, so I do not see why Internet-Drafts cou= ld not get the same treatment.=C2=A0 It in fact put IETFers at a disadvanta= ge.

They're not even indexing RFCs, other than some old ones where it finds= copies that the ACM has.=C2=A0 Yow.

Citatio= n needed.

Searching for bits from the abstract of a random selection o= f recently published documents gives:=C2=A0

In an incognito= window, the RFC Editor result was the first, second or third result for al= l of these...

W

=C2=A0

R's,
John

___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for discussion, not for action requests or bug reports.
* Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other bugs or issues to: ietf-action@ietf.org
List info (including how to Unsubscribe): https:/= /www.ietf.org/mailman/listinfo/tools-discuss


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--000000000000dd71ce05c845c602-- From nobody Thu Jul 29 09:45:59 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61DE23A0CD8 for ; Thu, 29 Jul 2021 09:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_FAIL=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 o_2XLOJDQ9Yv for ; Thu, 29 Jul 2021 09:45:43 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (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 8B6863A0CEB for ; Thu, 29 Jul 2021 09:45:43 -0700 (PDT) Received: from [IPv6:2601:204:e600:411:d250:99ff:fedf:93cd] (unknown [IPv6:2601:204:e600:411:d250:99ff:fedf:93cd]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 45080AE269; Thu, 29 Jul 2021 18:45:35 +0200 (CEST) To: Warren Kumari , John Levine Cc: Tools Discussion References: <20210729035232.EF66B254891D@ary.qy> From: Marc Petit-Huguenin Message-ID: <3fd854fe-503c-d23b-6905-ae8a12ef33c6@petit-huguenin.org> Date: Thu, 29 Jul 2021 09:45:32 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 16:45:57 -0000 On 7/29/21 9:41 AM, Warren Kumari wrote: > On Wed, Jul 28, 2021 at 11:52 PM John Levine wrote: > >> It appears that Marc Petit-Huguenin said: >>> Hi, >>> >>> We had this discussion already on ietf@ ( >> https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/), >> but the problem is >>> still there. >>> >>> Anything from arXiv is indexed, so I do not see why Internet-Drafts could >> not get the same treatment. It in fact put IETFers at a disadvantage. >> >> They're not even indexing RFCs, other than some old ones where it finds >> copies that the ACM has. Yow. >> > > Citation needed. > > Searching for bits from the abstract of a random selection of recently > published documents gives: > https://www.google.com/search?q=This+document+defines+a+BGP+path+attribute+known+as+the+%22Tunnel+Encapsulation+attribute%22 > > https://www.google.com/search?q=%22This+document+describes+a+new+Uniform+Resource+Name+%28URN%29+namespace%22 > > https://www.google.com/search?q=%22This+document+defines+a+process+experiment+under+RFC+3933%22 > > > In an incognito window, the RFC Editor result was the first, second or > third result for all of these... > This is about Google Scholar. -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug From nobody Thu Jul 29 09:57:19 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999CB3A0DD7 for ; Thu, 29 Jul 2021 09:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=l+VxGc04; dkim=pass (2048-bit key) header.d=taugh.com header.b=Q6EbpqxS 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 BrfYttZGWDCe for ; Thu, 29 Jul 2021 09:57:11 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEBD3A0DD4 for ; Thu, 29 Jul 2021 09:57:11 -0700 (PDT) Received: (qmail 6837 invoked from network); 29 Jul 2021 16:57:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=1ab3.6102dde5.k2107; bh=v+WQ1+uJn4aO/6w8RVazaSH0ACRfjb3NI6cYiVYwHxY=; b=l+VxGc04SapGKULvJlSKU+cnQHMCtPMowALwz+VW91h1HRUpsxQOp4DLg+Q4uDj5H1rlmZLjC9/ZXx4Bi+O3Z1cLPe4lO0FLYr48Zf7LlEP0c9L53xmYRyXhSE5dhdj1yRHNIjQCHu/WMerswDouSsP/o3fFDWdJsb2eGqWyMLta8LcQWMwjIdK5pEiiuovWNF5QiicWO7mWLgRqtcL3c3lNZyaJ8DAGXElhn0sl50usVjadzYeS/wqTYH/KfJgFn7BkWzZXopyLl3hQvN+te2VGiU9CEVlufG+bTc66JUjILXvBtfBK1iugBnqH9ghLajLI1Hitb7Oeyq4kzq2mxg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=1ab3.6102dde5.k2107; bh=v+WQ1+uJn4aO/6w8RVazaSH0ACRfjb3NI6cYiVYwHxY=; b=Q6EbpqxSr6aSlOzfljimi+UojN+WGs4jAqrmztsu26GZZP2vaogFgUJWwhI31wsee/CX/RFqkxtVjUvvupymdnHXgNiYoTpu0sQeOHlIRVqiVgE3d3Tcw0fvTMFD7rSyueGo1NmxB7zG57gLWUbRLasxG313Jxt8LFVMJTQS5NbqxTyyCAlJCu1UIAGOarQSjhxX5ymRMzarDvT0NCuTHfJzAOUxMVw7IF6SC8TnxQvQwhlQ5VUoGBa3Sm4vbq5uOuN+upOvpasoMh0kUXVon/b4tdrDiSD8IN25BjZkjggnnyrWiCsi6umvrGG81VKZihsb4j3Hn4bHeN0X1fdBqA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 29 Jul 2021 16:57:08 -0000 Received: by ary.qy (Postfix, from userid 501) id 473F9254BA5E; Thu, 29 Jul 2021 12:57:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 9CC01254BA40; Thu, 29 Jul 2021 12:57:06 -0400 (EDT) Date: 29 Jul 2021 12:57:06 -0400 Message-ID: <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> From: "John R Levine" To: "Warren Kumari" Cc: "Tools Discussion" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210729035232.EF66B254891D@ary.qy> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 16:57:18 -0000 >> They're not even indexing RFCs, other than some old ones where it finds >> copies that the ACM has. Yow. > > Citation needed. Try site:rfc-editor.org or site:tools.ietf.org and you get nothing, > In an incognito window, the RFC Editor result was the first, second or > third result for all of these... There's two separate issues here. While Google does index our web sites, the results are pretty random. Once the tools server is retired, some sitemaps and meta tags would help. The sitemap on datatracker.ietf.org only includes IPR disclosures and liason statements which seems suboptimal. rfc-editor.org has no sitemap at all. The other issue is that Google Scholar isn't finding any of the three copies of RFCs on our servers. Our file formats leave something to be desired (there are industry standard HTML tags for bibliographic info which we don't use) but I don't think that's it, because it found a copy of a recent HTML RFC on Brian Carpenter's institution's site. I think I will try some experiments with sitemaps, and maybe try adding the industry standard citation tags that Google says they prefer. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Jul 29 09:59:33 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D0A3A0E08 for ; Thu, 29 Jul 2021 09:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari.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 lNmaAzmA0_oD for ; Thu, 29 Jul 2021 09:59:09 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694743A0E11 for ; Thu, 29 Jul 2021 09:59:09 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id a7so8382242ljq.11 for ; Thu, 29 Jul 2021 09:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vz4bQ/JPrZp2etTi8Wi0plUDloDXOknPeZKHfrcTRtg=; b=X2zfQ4dH9eyrdhxl1z/8OqcnEJlbi/53FRP3EC6CQw/bFObjJbH8ubpRNwigyBFrJE ohu2bSRuviVIdN8O8M5X+gHumEWwfAfQ2bkzfoYtl/wO6MeS0cxmfE26fI+gKbiDTuQx 6RpWAcJh5BbUJKU3GHpoCT17C0bjbyvRdQflfG/FwgHRo1YttxzAuwAt0t5FyncrvSQn GgEHt1uh1IwKkemkyjRq6bW8bQiRTJIwij0HRQLH3SxQVGh7aRSfNATCvVY40hUCmVQL g086H5wMPqzui3yZKePMjdvXXdhwdZdtssxZtloSspTqt9lNjKbuIbna+CP81uCFdXdT OH0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vz4bQ/JPrZp2etTi8Wi0plUDloDXOknPeZKHfrcTRtg=; b=iEW3ZU7DYV65rWTIsl/lxFtG6QMzr5uzpPoEknI0nx1KtGQYva9UrmWg45iFakGLaB PrFGRWj+ZAx9eOenjHsvmbHW0vdDf79ta/leCQm0OyAWRxJrDe80BCnRt3u6pj/CVfQZ JPZViUkLlf9J1CaqXGxKb5ifAlmN5qMQndEoTGGfbLm0QOiawU/tTiPI3U1yC4FKUjso wnxCffKcUeXqdPamOJr7m6Ygb0gQuPqHydiN8Cxm1orOHL3N8AtXQ7TkyOvfSQ65yndH MGU0JtMxZdE2cvt2TGMPbeAIXa7aKt8aC0dEu4m9+oYrfJxpaHaM0jY5Uk1HWp55FA2q bkmQ== X-Gm-Message-State: AOAM531YizcfZCdVGvFUzMy7BDcDD4FMgv/LoW8SzFLRpvT+k1IL8TiE CCC+lFBys93c4KB8YUEGDJ/wsl6ENB67b/+u5aRInQ== X-Google-Smtp-Source: ABdhPJxzZX/ihmBDFSIIEykLTnSWYlh/l/AGGQBLgfvlpFP+vYo77W3200YelLCBBGhySIRHIML5LtPdYqze655zXNI= X-Received: by 2002:a2e:82d5:: with SMTP id n21mr3486548ljh.126.1627577945796; Thu, 29 Jul 2021 09:59:05 -0700 (PDT) MIME-Version: 1.0 References: <20210729035232.EF66B254891D@ary.qy> <3fd854fe-503c-d23b-6905-ae8a12ef33c6@petit-huguenin.org> In-Reply-To: <3fd854fe-503c-d23b-6905-ae8a12ef33c6@petit-huguenin.org> From: Warren Kumari Date: Thu, 29 Jul 2021 12:58:30 -0400 Message-ID: To: Marc Petit-Huguenin Cc: John Levine , Tools Discussion Content-Type: multipart/alternative; boundary="0000000000004dcce605c8460521" Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 16:59:21 -0000 --0000000000004dcce605c8460521 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 29, 2021 at 12:45 PM Marc Petit-Huguenin < marc@petit-huguenin.org> wrote: > On 7/29/21 9:41 AM, Warren Kumari wrote: > > On Wed, Jul 28, 2021 at 11:52 PM John Levine wrote: > > > >> It appears that Marc Petit-Huguenin said: > >>> Hi, > >>> > >>> We had this discussion already on ietf@ ( > >> https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI= / > ), > >> but the problem is > >>> still there. > >>> > >>> Anything from arXiv is indexed, so I do not see why Internet-Drafts > could > >> not get the same treatment. It in fact put IETFers at a disadvantage. > >> > >> They're not even indexing RFCs, other than some old ones where it find= s > >> copies that the ACM has. Yow. > >> > > > > Citation needed. > > > > Searching for bits from the abstract of a random selection of recently > > published documents gives: > > > https://www.google.com/search?q=3DThis+document+defines+a+BGP+path+attrib= ute+known+as+the+%22Tunnel+Encapsulation+attribute%22 > > > > > https://www.google.com/search?q=3D%22This+document+describes+a+new+Unifor= m+Resource+Name+%28URN%29+namespace%22 > > > > > https://www.google.com/search?q=3D%22This+document+defines+a+process+expe= riment+under+RFC+3933%22 > > > > > > In an incognito window, the RFC Editor result was the first, second or > > third result for all of these... > > > > This is about Google Scholar. > > Oh, yes, you are right -- I'd completely managed to swap out the context of this thread... W > -- > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: https://marc.petit-huguenin.org > Profile: https://www.linkedin.com/in/petithug > --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra --0000000000004dcce605c8460521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 29, 2021 at 12:45 PM Mar= c Petit-Huguenin <marc@petit-= huguenin.org> wrote:
On 7/29/21 9:41 AM, Warren Kumari wrote:
> On Wed, Jul 28, 2021 at 11:52 PM John Levine <johnl@taugh.com> wrote:
>
>> It appears that Marc Petit-Huguenin <marc@petit-huguenin.org> said: >>> Hi,
>>>
>>> We had this discussion already on ietf@ (
>> https://mailarchive.= ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/),
>> but the problem is
>>> still there.
>>>
>>> Anything from arXiv is indexed, so I do not see why Internet-D= rafts could
>> not get the same treatment.=C2=A0 It in fact put IETFers at a disa= dvantage.
>>
>> They're not even indexing RFCs, other than some old ones where= it finds
>> copies that the ACM has.=C2=A0 Yow.
>>
>
> Citation needed.
>
> Searching for bits from the abstract of a random selection of recently=
> published documents gives:
> https://www.google.com/search?q=3DThis+docum= ent+defines+a+BGP+path+attribute+known+as+the+%22Tunnel+Encapsulation+attri= bute%22
>
> https://www.google.com/search?q=3D%22This+document+describe= s+a+new+Uniform+Resource+Name+%28URN%29+namespace%22
>
> https://www.google.com/search?q=3D%22This+document+defines+a+process+expe= riment+under+RFC+3933%22
>
>
> In an incognito window, the RFC Editor result was the first, second or=
> third result for all of these...
>

This is about Google Scholar.


Oh, yes, you are right -- I'd completel= y=C2=A0managed to swap out the context of this thread...
<blush>
W=

=C2=A0
--
Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug


--
The computing scientist=E2=80= =99s main challenge is not to get confused by the
complexities of his ow= n making.
=C2=A0 -- E. W. Dijkstra
--0000000000004dcce605c8460521-- From nobody Thu Jul 29 15:07:09 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EAA3A082E for ; Thu, 29 Jul 2021 15:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 YdKRU711GSPF for ; Thu, 29 Jul 2021 15:07:00 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2DA3A07F3 for ; Thu, 29 Jul 2021 15:06:59 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GbPl574RDz31P5; Fri, 30 Jul 2021 00:06:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann Date: Fri, 30 Jul 2021 00:06:57 +0200 X-Mao-Original-Outgoing-Id: 649289217.483917-1d8bde80955688ac002942f111cb291d Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tools Team Discussion X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Tools-discuss] Fwd: [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 22:07:07 -0000 Which markdown dialect(s) does the datatracker like these days? (I=E2=80=99m asking because I need to know whether
should be input = as =E2=80=9C =E2=80=9C at the end of line (original brittle way), = =E2=80=9C\\=E2=80=9D (not as widely used), or =E2=80=9C
=E2=80=9D = (ugly).) Gr=C3=BC=C3=9Fe, Carsten > Begin forwarded message: >=20 > From: Carsten Bormann > Subject: Re: [irsg] [EXTERNAL] Question about Codimd for w.g. minutes > Date: 2021-07-29 at 23:37:19 CEST > To: "STARK, BARBARA H" > Cc: Working Group Chairs > Archived-At: = > Archived-At: = > Message-Id: >=20 > On 2021-07-29, at 22:13, STARK, BARBARA H wrote: >>=20 >> The main edit I do is to put blank lines between all paragraphs. Then = I upload the .md file to datatracker. >=20 > I might throw a little tool that does that into the next kramdown-rfc = revision. Maybe just in time for other people=E2=80=99s minutes=E2=80=A6 >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Thu Jul 29 16:20:09 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B13A3A0EE1 for ; Thu, 29 Jul 2021 16:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOcZehA3Gh3A for ; Thu, 29 Jul 2021 16:20:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1A33A0EDE for ; Thu, 29 Jul 2021 16:20:03 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16TNK2AV011772 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Thu, 29 Jul 2021 18:20:02 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1627600802; bh=k6SUUnBFv3t2J2F7q3BNT/rvUOyn5CuCL30+RkoiR50=; h=Subject:To:References:From:Date:In-Reply-To; b=XmpqvZO+R3aQ/nDuSFGDJQ3ZKQX9R0gQgcZSmv+fbYDSiaVxLpa/UcsG8nNAIocXW kEeJFhNfth3TevcrhBZzbo/Y1ykSoBSbejSkmGppsqLAdhnBhItzet12SuAR3nMXmr R3BPyzsTvSApI2+D0ch0JF8GCH7fU08LE/M8Weiw= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: tools-discuss@ietf.org References: From: Robert Sparks Message-ID: <0592d397-65c5-71b2-2a09-e1ebbccc52e6@nostrum.com> Date: Thu, 29 Jul 2021 18:19:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Fwd: [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 23:20:07 -0000 I'm aiming to move all places markdown in the datatracker to render using https://github.com/Python-Markdown/markdown (not markdown2), providing extensions=['extra'] to the rendering call. RjS On 7/29/21 5:06 PM, Carsten Bormann wrote: > Which markdown dialect(s) does the datatracker like these days? > > (I’m asking because I need to know whether
should be input as “ “ at the end of line (original brittle way), “\\” (not as widely used), or “
” (ugly).) > > Grüße, Carsten > > >> Begin forwarded message: >> >> From: Carsten Bormann >> Subject: Re: [irsg] [EXTERNAL] Question about Codimd for w.g. minutes >> Date: 2021-07-29 at 23:37:19 CEST >> To: "STARK, BARBARA H" >> Cc: Working Group Chairs >> Archived-At: >> Archived-At: >> Message-Id: >> >> On 2021-07-29, at 22:13, STARK, BARBARA H wrote: >>> The main edit I do is to put blank lines between all paragraphs. Then I upload the .md file to datatracker. >> I might throw a little tool that does that into the next kramdown-rfc revision. Maybe just in time for other people’s minutes… >> >> Grüße, Carsten >> > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss From nobody Thu Jul 29 16:43:15 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB463A101C for ; Thu, 29 Jul 2021 16:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 7agpfvlSTyGT for ; Thu, 29 Jul 2021 16:43:09 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF983A101B for ; Thu, 29 Jul 2021 16:43:09 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GbRt26FbWz31Qd; Fri, 30 Jul 2021 01:43:06 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <0592d397-65c5-71b2-2a09-e1ebbccc52e6@nostrum.com> Date: Fri, 30 Jul 2021 01:43:06 +0200 Cc: tools-discuss@ietf.org X-Mao-Original-Outgoing-Id: 649294986.486762-a6519902558d83f293e244b7617cf54d Content-Transfer-Encoding: quoted-printable Message-Id: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> References: <0592d397-65c5-71b2-2a09-e1ebbccc52e6@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Tools-discuss] [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 23:43:13 -0000 OK, I=E2=80=99m mostly interested in minutes. It seems markdown non-2 only has the super-brittle original markdown = double end-of-line spaces and
. Not the choice I was hoping for, = but maybe what was to be expected (this is not a well-lit part of the = markdown landscape). Gr=C3=BC=C3=9Fe, Carsten > On 2021-07-30, at 01:19, Robert Sparks wrote: >=20 > I'm aiming to move all places markdown in the datatracker to render = using https://github.com/Python-Markdown/markdown (not markdown2), = providing extensions=3D['extra'] to the rendering call. >=20 > RjS >=20 >=20 > On 7/29/21 5:06 PM, Carsten Bormann wrote: >> Which markdown dialect(s) does the datatracker like these days? >>=20 >> (I=E2=80=99m asking because I need to know whether
should be = input as =E2=80=9C =E2=80=9C at the end of line (original brittle way), = =E2=80=9C\\=E2=80=9D (not as widely used), or =E2=80=9C
=E2=80=9D = (ugly).) >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> Begin forwarded message: >>>=20 >>> From: Carsten Bormann >>> Subject: Re: [irsg] [EXTERNAL] Question about Codimd for w.g. = minutes >>> Date: 2021-07-29 at 23:37:19 CEST >>> To: "STARK, BARBARA H" >>> Cc: Working Group Chairs >>> Archived-At: = >>> Archived-At: = >>> Message-Id: >>>=20 >>> On 2021-07-29, at 22:13, STARK, BARBARA H wrote: >>>> The main edit I do is to put blank lines between all paragraphs. = Then I upload the .md file to datatracker. >>> I might throw a little tool that does that into the next = kramdown-rfc revision. Maybe just in time for other people=E2=80=99s = minutes=E2=80=A6 >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >> ___________________________________________________________ >> Tools-discuss mailing list - Tools-discuss@ietf.org >> This list is for discussion, not for action requests or bug reports. >> * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org >> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >> * Report all other bugs or issues to: ietf-action@ietf.org >> List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss >=20 > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss From nobody Thu Jul 29 17:32:46 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A243A1230 for ; Thu, 29 Jul 2021 17:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFStPvdKWUjv for ; Thu, 29 Jul 2021 17:32:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4AB3A122E for ; Thu, 29 Jul 2021 17:32:39 -0700 (PDT) Received: from smtpclient.apple ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16U0WZ0s037830 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 29 Jul 2021 19:32:36 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1627605156; bh=pFkdPH782rodWD8skdlcAOESRUMMofI8yCgpHJFTw90=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=SC7A8As6r0RyRskEoUw8MIO3qnYzkktOKEiTzLNmu8Et/T3Iqy1+PnlZ0sYySUvw+ bO6PN6dfuPF0yR8LJnMXv5jhIzlYmDdgFEF9v9P3ZN0vOf6afCR+4wmgovEpziOIj2 uuyBUhXUD+5cnHyQfNPI4d+eXVhF/yk8MJVTzsKg= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be smtpclient.apple Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Robert Sparks Mime-Version: 1.0 (1.0) Date: Thu, 29 Jul 2021 19:32:30 -0500 Message-Id: References: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> Cc: tools-discuss@ietf.org In-Reply-To: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> To: Carsten Bormann X-Mailer: iPhone Mail (18F72) Archived-At: Subject: Re: [Tools-discuss] [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 00:32:45 -0000 Maybe we can provide out own extension that does better? It would be a boon if there were a suppurted python renderer that followed t= he sane-for-server-side part of codimd=E2=80=99s renderer.=20 Or maybe we push the rendering to the browser and leave the wont do js folks= behind? Sent from my iPhone > On Jul 29, 2021, at 6:43 PM, Carsten Bormann wrote: >=20 > =EF=BB=BFOK, I=E2=80=99m mostly interested in minutes. >=20 > It seems markdown non-2 only has the super-brittle original markdown doubl= e end-of-line spaces and
. Not the choice I was hoping for, but maybe w= hat was to be expected (this is not a well-lit part of the markdown landscap= e). >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 >> On 2021-07-30, at 01:19, Robert Sparks wrote: >>=20 >> I'm aiming to move all places markdown in the datatracker to render using= https://github.com/Python-Markdown/markdown (not markdown2), providing exte= nsions=3D['extra'] to the rendering call. >>=20 >> RjS >>=20 >>=20 >>> On 7/29/21 5:06 PM, Carsten Bormann wrote: >>> Which markdown dialect(s) does the datatracker like these days? >>>=20 >>> (I=E2=80=99m asking because I need to know whether
should be input= as =E2=80=9C =E2=80=9C at the end of line (original brittle way), =E2=80=9C= \\=E2=80=9D (not as widely used), or =E2=80=9C
=E2=80=9D (ugly).) >>>=20 >>> Gr=C3=BC=C3=9Fe, Carsten >>>=20 >>>=20 >>>> Begin forwarded message: >>>>=20 >>>> From: Carsten Bormann >>>> Subject: Re: [irsg] [EXTERNAL] Question about Codimd for w.g. minutes >>>> Date: 2021-07-29 at 23:37:19 CEST >>>> To: "STARK, BARBARA H" >>>> Cc: Working Group Chairs >>>> Archived-At: >>>> Archived-At: >>>> Message-Id: >>>>=20 >>>> On 2021-07-29, at 22:13, STARK, BARBARA H wrote: >>>>> The main edit I do is to put blank lines between all paragraphs. Then I= upload the .md file to datatracker. >>>> I might throw a little tool that does that into the next kramdown-rfc r= evision. Maybe just in time for other people=E2=80=99s minutes=E2=80=A6 >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>> ___________________________________________________________ >>> Tools-discuss mailing list - Tools-discuss@ietf.org >>> This list is for discussion, not for action requests or bug reports. >>> * Report datatracker and mailarchive bugs to: datatracker-project@ietf.o= rg >>> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >>> * Report all other bugs or issues to: ietf-action@ietf.org >>> List info (including how to Unsubscribe): https://www.ietf.org/mailman/l= istinfo/tools-discuss >>=20 >> ___________________________________________________________ >> Tools-discuss mailing list - Tools-discuss@ietf.org >> This list is for discussion, not for action requests or bug reports. >> * Report datatracker and mailarchive bugs to: datatracker-project@ietf.or= g >> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >> * Report all other bugs or issues to: ietf-action@ietf.org >> List info (including how to Unsubscribe): https://www.ietf.org/mailman/li= stinfo/tools-discuss >=20 From nobody Thu Jul 29 17:39:51 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECE3A1251 for ; Thu, 29 Jul 2021 17:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDh-v9r3F4tn for ; Thu, 29 Jul 2021 17:39:44 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 62BF33A1239 for ; Thu, 29 Jul 2021 17:39:44 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id b11so3664293wrx.6 for ; Thu, 29 Jul 2021 17:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=FEi22Ne9FDhokYOOWFFqyldnYDEEBunnYLFYgK9OcHw=; b=OZpgXfBJi9DEJgLsHYXzjic757qWxZvoOoqCVOGsW7tCxDJvcuu4qO0ALGCVUOiaSb WURATB2FjGN0xDrrbbL2pD5agQ7t/omG0u01UvCOSYkYEp0vAQd4UmYScb5ocbE3WXkm OVcfJsj3JwzwUZ4znN1kVAKrgwGPUnZTtkLoiDaum7xT9Rf2PlGs/KRpCVcAdnIMH38b C4mLwbgfYotMTzzdBr8UlbilGJou2sqS+eKhmstkPPWO481QoNvrr6qb9uGXTLRBVINz GtA5EnVZ6v8w8VVCcduV1dzQBnvplYJfYEdDuhrysuuXjC6f6xIn+lndLJ2j3clnWFlC Uy+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=FEi22Ne9FDhokYOOWFFqyldnYDEEBunnYLFYgK9OcHw=; b=F6y3tTUEsKdNfmXUTb43RS9qNVFSca/DlEjgC6qI+C4pd1TUuSdDz4P9qU489dNbDZ IiFIfHPI1tEUbxiGJhQ4VW2ZjxuIQtBun6Gs3eV25urNS6mqSybofSlBVmNDd7FoZUA4 +EscGZcT9WNCfrLAJLzV0iou2a7ozkhthSqNbgZ4CWFYDgUsEDHs7r8FVHAc+bObhQkY jL8faQinfH2xEMoag+fN0GDnCfocT7EZUkfYKqHaffzQ+tfd8MLzchbSc0leJtz7rkBT 6QXqDEMu05GwdEg9r72zCmfDKB0CV+MQ2J1aZAaGxCpSvPT3iFxBGUT4EGihIKkzsOT4 4uCw== X-Gm-Message-State: AOAM530blHBHv2m1YT6o9CyTzIjSh+mZQwu7GKqO78mx9Yxu4MoxhKeJ I9SRXc3pyT8b2jZvHGgOaUc= X-Google-Smtp-Source: ABdhPJzFiE7ruvJFubMxP7Q8DSShT4bqaNDbkosI8MBbrD2qDyxyA7XOmbuiAqdCiXxdVCVAy3Iqkg== X-Received: by 2002:adf:ebc5:: with SMTP id v5mr100708wrn.269.1627605580051; Thu, 29 Jul 2021 17:39:40 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:659:904e:d830:2ae7:6ebd? ([2601:647:5a00:659:904e:d830:2ae7:6ebd]) by smtp.gmail.com with ESMTPSA id n17sm63184wmo.18.2021.07.29.17.39.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jul 2021 17:39:39 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8C09EDD8-4A71-4DA7-9F50-A91416C5D09F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Thu, 29 Jul 2021 17:39:36 -0700 In-Reply-To: Cc: Bob Hinden , Carsten Bormann , tools-discuss@ietf.org To: Robert Sparks References: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Tools-discuss] [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 00:39:49 -0000 --Apple-Mail=_8C09EDD8-4A71-4DA7-9F50-A91416C5D09F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Robert, I hope we can make sure that the common tools like Codimd and the = Datatracker do compatible things. I ran into this today uploading the = 6man minutes. I now know more about mark down that I wanted to know :-) Bob > On Jul 29, 2021, at 5:32 PM, Robert Sparks = wrote: >=20 > Maybe we can provide out own extension that does better? >=20 > It would be a boon if there were a suppurted python renderer that = followed the sane-for-server-side part of codimd=E2=80=99s renderer. >=20 > Or maybe we push the rendering to the browser and leave the wont do js = folks behind? >=20 > Sent from my iPhone >=20 >> On Jul 29, 2021, at 6:43 PM, Carsten Bormann wrote: >>=20 >> =EF=BB=BFOK, I=E2=80=99m mostly interested in minutes. >>=20 >> It seems markdown non-2 only has the super-brittle original markdown = double end-of-line spaces and
. Not the choice I was hoping for, = but maybe what was to be expected (this is not a well-lit part of the = markdown landscape). >>=20 >> Gr=C3=BC=C3=9Fe, Carsten >>=20 >>=20 >>> On 2021-07-30, at 01:19, Robert Sparks wrote: >>>=20 >>> I'm aiming to move all places markdown in the datatracker to render = using https://github.com/Python-Markdown/markdown (not markdown2), = providing extensions=3D['extra'] to the rendering call. >>>=20 >>> RjS >>>=20 >>>=20 >>>> On 7/29/21 5:06 PM, Carsten Bormann wrote: >>>> Which markdown dialect(s) does the datatracker like these days? >>>>=20 >>>> (I=E2=80=99m asking because I need to know whether
should be = input as =E2=80=9C =E2=80=9C at the end of line (original brittle way), = =E2=80=9C\\=E2=80=9D (not as widely used), or =E2=80=9C
=E2=80=9D = (ugly).) >>>>=20 >>>> Gr=C3=BC=C3=9Fe, Carsten >>>>=20 >>>>=20 >>>>> Begin forwarded message: >>>>>=20 >>>>> From: Carsten Bormann >>>>> Subject: Re: [irsg] [EXTERNAL] Question about Codimd for w.g. = minutes >>>>> Date: 2021-07-29 at 23:37:19 CEST >>>>> To: "STARK, BARBARA H" >>>>> Cc: Working Group Chairs >>>>> Archived-At: = >>>>> Archived-At: = >>>>> Message-Id: >>>>>=20 >>>>> On 2021-07-29, at 22:13, STARK, BARBARA H wrote: >>>>>> The main edit I do is to put blank lines between all paragraphs. = Then I upload the .md file to datatracker. >>>>> I might throw a little tool that does that into the next = kramdown-rfc revision. Maybe just in time for other people=E2=80=99s = minutes=E2=80=A6 >>>>>=20 >>>>> Gr=C3=BC=C3=9Fe, Carsten >>>>>=20 >>>> ___________________________________________________________ >>>> Tools-discuss mailing list - Tools-discuss@ietf.org >>>> This list is for discussion, not for action requests or bug = reports. >>>> * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org >>>> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >>>> * Report all other bugs or issues to: ietf-action@ietf.org >>>> List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss >>>=20 >>> ___________________________________________________________ >>> Tools-discuss mailing list - Tools-discuss@ietf.org >>> This list is for discussion, not for action requests or bug reports. >>> * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org >>> * Report tools.ietf.org bugs to: webmaster@tools.ietf.org >>> * Report all other bugs or issues to: ietf-action@ietf.org >>> List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss >>=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss --Apple-Mail=_8C09EDD8-4A71-4DA7-9F50-A91416C5D09F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmEDSkgACgkQrut0EXfn u6iz4wgAoAe4IHRu/zIRXe/ElwPtsnDWZ9trE/2MR1mR5HDQBVUxmgkG6Mht+/7F ngs/JmBnMuhPlQNjJnq7Y1zYaPuvkTBlov3N9l183nITbR6+pUQ89DsU+70D1Bh1 edoETl3mTljivCttbauVIUofxuCuDxTDlDjMySBO5A+zhzrFLdbKw6UlUgVBEAQw Po6UQOkAm1j1NYwZfz0Z1VMBxBrOO7uGbndrHZUBZLD3vJ8S6kMXFFnBgizO56x1 rNFM3RGwJsN4NYPcPbBzeVNbVuw/+wPRUQgYxwhhaOLOf70oXoWcrwMFke1cxFl8 Pr57FNEuFi0pUwmRQUEJAS7WY83UiA== =NXTc -----END PGP SIGNATURE----- --Apple-Mail=_8C09EDD8-4A71-4DA7-9F50-A91416C5D09F-- From nobody Thu Jul 29 17:52:42 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831103A137D for ; Thu, 29 Jul 2021 17:52:32 -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 MV2gpnFBn1sr for ; Thu, 29 Jul 2021 17:52:28 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DE673A12DB for ; Thu, 29 Jul 2021 17:52:18 -0700 (PDT) Received: from smtpclient.apple (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GbTPq20YPz31Qn; Fri, 30 Jul 2021 02:52:15 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: Date: Fri, 30 Jul 2021 02:52:14 +0200 Cc: tools-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> To: Robert Sparks X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Tools-discuss] [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 00:52:41 -0000 On 30. Jul 2021, at 02:32, Robert Sparks wrote: >=20 > Maybe we can provide out own extension that does better? We could. GitHub went the other direction and stopped trying to fragment the = markdown community. What I called =E2=80=9CGFM=E2=80=9D really is the GFM of five years ago; = GitHub now does soft-wrapping like everyone else and it one of the = truest followers of commonmark. I think CodiMD is the outlier here because it is really easier to type = up things interactively using hard-wrapping; the benefits of = soft-wrapping come in when you store the documents, do edits and diffs = etc. So I think the upload could indeed offer an option to convert CodiMD = markdown to standard markdown (while still allowing people to upload = standard markdown as well). Or people continue to do the conversion on their laptops, e.g. = before/after they edit the notes. Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Jul 30 04:14:04 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08873A268B; Fri, 30 Jul 2021 04:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.296 X-Spam-Level: X-Spam-Status: No, score=-1.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] 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 7FitpJAhnAZk; Fri, 30 Jul 2021 04:13:53 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD633A2683; Fri, 30 Jul 2021 04:13:53 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GblC26rxbz31Xm; Fri, 30 Jul 2021 13:13:50 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Fri, 30 Jul 2021 13:13:50 +0200 Cc: Robert Sparks , Tools Team Discussion , rfc-markdown@ietf.org X-Mao-Original-Outgoing-Id: 649336430.505282-e5673245bdf204ac1ef334a82ca765a3 Content-Transfer-Encoding: quoted-printable Message-Id: <21540E71-F991-4F26-BC4D-79595A6F6DBB@tzi.org> References: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> To: Bob Hinden X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Tools-discuss] [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 11:13:59 -0000 On 2021-07-30, at 02:39, Bob Hinden wrote: >=20 > I hope we can make sure that the common tools like Codimd and the = Datatracker do compatible things. =20 I have been informed by a friendly HedgeDoc maintainer (HedgeDoc =3D = independent open-source version of CodiMD) that this is easy to achieve = [0]. Just insert --- breaks: false ... at the start of the CodiMD document and all will be standard(*). (This also can be set system-wide, but that might break existing = documents written without this.) I=E2=80=99d stick with the CodiMD default `breaks: true`, though, as = this is nicer for note-taking; see [1] for the discussion that led to = this being the default for hedgedoc. This is where the de-gfm tool that = is now in kramdown-rfc will come in handy. Or let CodiMD do the HTML = conversion, but then there is no standard markdown to put into repos = etc. Gr=C3=BC=C3=9Fe, Carsten [0]: https://demo.hedgedoc.org/s/yaml-metadata#breaks (*) note that the docs say --- breaks: false --- (probably because it=E2=80=99s more pleasingly symmetrical) but that is = not standard YAML, so I recommend the three-dot version (which is also = the one accepted in kramdown-rfc documents.). [1]: = https://community.hedgedoc.org/t/should-we-change-the-hedgedoc-default-for= -breaks-from-true-to-false/298 Beautiful =E2=80=9Cvote=E2=80=9D in there! From nobody Fri Jul 30 04:28:20 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E3C3A26ED for ; Fri, 30 Jul 2021 04:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziVAVhKKzNYU for ; Fri, 30 Jul 2021 04:28:13 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719A33A26EF for ; Fri, 30 Jul 2021 04:28:13 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GblWY6CTYz31WQ; Fri, 30 Jul 2021 13:28:09 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> Date: Fri, 30 Jul 2021 13:28:07 +0200 Cc: Warren Kumari , Tools Discussion X-Mao-Original-Outgoing-Id: 649337287.144787-e118d7eaa264377861e62a05d63bef62 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> To: "John R. Levine" X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 11:28:18 -0000 On 2021-07-29, at 18:57, John R Levine wrote: >=20 > The other issue is that Google Scholar isn't finding any of the three = copies of RFCs on our servers. Ages ago I had copies of all RFCs in some PDF form on our servers and = finally got some bibliography servers to index them. That must have = been 15 years or more ago, I don=E2=80=99t remember the details. Clearly, Google Scholar should be taught to find the canonical RFCs at = https://rfc-editor.org/rfc - having many secondary copies is an SEO = anathema. Internet-Drafts, hmm. Many are not arxiv quality, and we don=E2=80=99t = want the I-D repository as a dumping ground for people who just want to = get their garbage into Scholar. But the main problem is that the = references to the drafts will stay active even when the RFC has been = published(*) (or the I-D replaced), so we should be very careful with = what we offer under the URI that will be indexed. Let=E2=80=99s stop kicking the can on the doc.ietf.org thing! Gr=C3=BC=C3=9Fe, Carsten (*) E.g., I get = https://tools.ietf.org/id/draft-ietf-core-observe-09.html as the first = hit for CoAP Observe. No metadata block, seven versions off, ... From nobody Fri Jul 30 04:35:22 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340AB3A2721 for ; Fri, 30 Jul 2021 04:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=sS58+Dfj; dkim=pass (2048-bit key) header.d=taugh.com header.b=II1tn5Zl 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 TUbNMEgACwyn for ; Fri, 30 Jul 2021 04:35:15 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DE53A2725 for ; Fri, 30 Jul 2021 04:35:15 -0700 (PDT) Received: (qmail 17169 invoked from network); 30 Jul 2021 11:35:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=430f.6103e3f1.k2107; bh=azO9lkP5t7iUGTlVRiJOlT6YmGa7THtdp1XUBW/v6nk=; b=sS58+DfjQceUEK7HvZzX8NQMBYQeW8pUT/Pp0kSvodsvWakBM4ti4ovG6HYmiKR0waCzdn1vowOYFAK+8eW4Hq+DiI6rXepKDBZi9IUNkcPLDpAa/iwOaXzVYDimtYmX7MU14O+Z2LBuic8PA2flcA2vkZLtCf/spP+7ewI96VDyG4QHs4USTf9vfyqLhniuPErT+MS+E1GN7c6zwW14jFQFYu7YP+FihEXTuSKYvdxsrXPyeyLEW4fpl/pslQj0IIt5GDv5YeVeqGBW3qWv0TFzUhOdUiw27MGkLmPJueqnQXf2J5PISxTfjO+CoBGo5VD9dc/75xy1HV8KK60iSQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type; s=430f.6103e3f1.k2107; bh=azO9lkP5t7iUGTlVRiJOlT6YmGa7THtdp1XUBW/v6nk=; b=II1tn5ZltSVRQa77hAmjDtNWEHs9VelkQEakA4YE5ggAf5Tbw2jbNrvmJp5JXf8Om82FlTUTIWMR7Lu7HVtOamDyfmbiUKoyGRB+PbQOSIuuXfzO0CWUoGerqEHOxCZjvGftW6z85P9JG2GSVC/0GyFYC/5h31bH5xcC8aYhcrpS9gtL0sNs4OkwyLbKveqIVHp6ZFlppvTCBRopMONnPiTu7wnSGabA2S9/sht6ukfRiA4zrU014KZ1HED7pYlbNVj+LjJVf007nAvWtALBSOTBT2oDn6+CervykQW2P8dWgQtGdwnFDBDc+himoewt8L9BYX3EeLuNp0oDvLNqng== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 30 Jul 2021 11:35:13 -0000 Received: by ary.qy (Postfix, from userid 501) id BE9AB25555FA; Fri, 30 Jul 2021 07:35:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ary.qy (Postfix) with ESMTP id 3EED225555DC; Fri, 30 Jul 2021 07:35:11 -0400 (EDT) Date: 30 Jul 2021 07:35:11 -0400 Message-ID: From: "John R Levine" To: "Carsten Bormann" Cc: "Tools Discussion" X-X-Sender: johnl@ary.qy In-Reply-To: References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1312564875-1627644911=:25957" Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 11:35:21 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1312564875-1627644911=:25957 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > Clearly, Google Scholar should be taught to find the canonical RFCs at https://rfc-editor.org/rfc - having many secondary copies is an SEO anathema. Right. I hope some sitemaps will help. > Internet-Drafts, hmm. Many are not arxiv quality, and we don’t want the > I-D repository as a dumping ground for people who just want to get their > garbage into Scholar. But the main problem is that the references to > the drafts will stay active even when the RFC has been published(*) (or > the I-D replaced), so we should be very careful with what we offer under > the URI that will be indexed. I agree they're not what Scholar is looking for. I'm not worried about people gaming it, you should be able to get anything into Scholar if you put it on a web server with the right metadata, but the last thing I want is yet another reason people will imagine that every I-D is an Internet Standard. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly --0-1312564875-1627644911=:25957-- From david@herrmehren.de Fri Jul 30 04:49:01 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25EF3A2787 for ; Fri, 30 Jul 2021 04:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] 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 RFxm3zm_en5q for ; Fri, 30 Jul 2021 04:48:57 -0700 (PDT) Received: from chiron.uberspace.de (chiron.uberspace.de [185.26.156.166]) (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 CDD7F3A2783 for ; Fri, 30 Jul 2021 04:48:56 -0700 (PDT) Received: (qmail 5366 invoked from network); 30 Jul 2021 11:48:52 -0000 Received: from localhost (HELO localhost) (127.0.0.1) by chiron.uberspace.de with SMTP; 30 Jul 2021 11:48:52 -0000 To: Carsten Bormann Cc: rfc-markdown@ietf.org, Tools Team Discussion , Robert Sparks References: <43AD0E13-4450-4CB1-AC3E-4A73408B613F@tzi.org> <21540E71-F991-4F26-BC4D-79595A6F6DBB@tzi.org> From: David Mehren Message-ID: <0c842fa9-b9f9-f668-74d5-4f8e3936cbfb@herrmehren.de> Date: Fri, 30 Jul 2021 13:48:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <21540E71-F991-4F26-BC4D-79595A6F6DBB@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] [irsg] [EXTERNAL] Question about Codimd for w.g. minutes X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 11:50:09 -0000 Hi everyone, another HedgeDoc maintainer here. Am 30.07.21 um 13:13 schrieb Carsten Bormann: > I have been informed by a friendly HedgeDoc maintainer (HedgeDoc = independent open-source version of CodiMD) that this is easy to achieve [0]. HedgeDoc is actually the same project that released CodiMD 1.6 (which is the version currently deployed at codimd.ietf.org). We renamed to reduce confusion with the project that we forked from. More details can be found on our history page at [1]. > (This also can be set system-wide, but that might break existing documents written without this.) There currently is no system-wide setting that would override existing notes. An administrator can set the default content for *new* notes, as outlined in [2]. This may actually be the solution for your instance? I would recommend to upgrade the instance at codimd.ietf.org to HedgeDoc 1.8.2, as previous releases have multiple security vulnerabilities (see [3]). Best regards David [1] https://hedgedoc.org/history/ [2] https://github.com/hedgedoc/hedgedoc/issues/59#issuecomment-489188611 [3] https://github.com/hedgedoc/hedgedoc/security/advisories?state=published From nobody Fri Jul 30 08:09:56 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46A73A2512 for ; Fri, 30 Jul 2021 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 nsWpkOOV2YGn for ; Fri, 30 Jul 2021 08:09:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 D42F43A2D26 for ; Fri, 30 Jul 2021 08:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1627657787; bh=k3Q5UkjOX8WNTfr2wC48JXfthrep3EE1wyC2o6U96KY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=Gy1uTxOtzfzDzatuy869HbQJ+TGnk9CKQBs91w56c6t2dEtnt6k+/3iC77UFI3Ykz quvlszxlJ78+UY3Scz7aiV5E7pluaYugIhDs6VNneKSogF3te4/sv9LPhwGrn2Rggm RNWUovfG6gs5yQt3igQ/v8D7oZam+w9+bxo/1GJQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.1.70] ([212.205.152.82]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTRMi-1mb5hX0uy4-00ThNW for ; Fri, 30 Jul 2021 17:09:47 +0200 To: tools-discuss@ietf.org References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> From: Julian Reschke Message-ID: <297b8f75-ce58-ee79-f147-a164748bf7ff@gmx.de> Date: Fri, 30 Jul 2021 17:09:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:2lAQdlXUk0qCNNm27XnfIhPCC/ShG7wuzuuWiktG0KcMDCAGz+v EykWF8kdTCXdw9v77hOJMcZit6N1pEaA7Y93kwZind+6pSiMQ5VQptip14ibFtc3TFkTQ2B j5JV0ZVVG7nkwzzz3jf7GKP0DucDctTsoCt7/GtNluSLWAtt028B+btGPvUFhcvSxIq8PZL JKNtVfw9b44BEp/VT3Bgg== X-UI-Out-Filterresults: notjunk:1;V03:K0:Lr8x6BDAZsI=:M2evAIAlPnV8xpLXfGYoF+ W4dmw60IHY9S088VxeDiiJ0fmkPtNwlopje/6gb4c03eDdPx+GCShpuZoQrNoRCoqy6cy3ePI 0k/BIZXUe55TKUdLxAjNvW16405atsuUjwdseGJLYqvY9SSXv/bbuIekDDwfcnETyKBtNdeUp v7htH73zujYAl0VHiALRtMB9MaDLwBMgeshDO9nmC0R7DgbfbZQUCVRBAkJAoO7QRqUaERT9W X66Or2cNvUPUZF0mqiKe7Cxs7od6JxloMkNWV7uufoCR9IdeLneA+jBD2okbvAv0SV5aMTDQn 8QRvRSh47rD1rfnj6y3/S3zdxr1j7iEGW3wzB4isffyGJRHj3DBl1riCG/KjHMzp1xsBJGRVA 4f3VSBN7c8LOI1h3V4y05fkAERQjXl0SMCxO+DK5rlEP2oJP/THmYObwQiOMzVCosCxMJYzEc H/h2VFRzZourJvIXiwAYEB1w5APXyPyEr09OALcHjM4XFlSCuCKiHt8LZztB7rAwxYw6CcXK1 B8WIOQJEHwMzdoymMH4fJnmxDOac2mSKt5e1kQD/6Tw0CBcRtZQp0gQhUpjQwGFxEIYUoYqiG cVTZvOzMBfsuyifdPtCD8wFauCemsKVHRPUK8slFt5aSBME9/SKgXy2LWFDvPgQA8WOfS7s4F dj/acK2O5Uc3fc7qUDtxEkkTGCWtc5uXmUgkQNQ62rF8ehvk1MC74/5ohUi/igNylm/kQICZm ARFLF9gRLvtrS3YWz9nSzBoQDgh160rdKZIso1kJS9+QwvTxUsv4T3U5a72BEQ9h6y8cBJJhR MDINM1CJ8rr8pDrylOymRdnB5LToalWPGi3PRLyUdaWkM27cGB02CWfwq6XPRnG9CljzXN4DN PyEaZz+i93zhZMYMlWNrd+4vw2HKLY1ZQIoratzlZAjAabtTS6RVDF4ON53hR4sBMIYXinYdF 35sbfNeDqPLrefz5hqCD90y9DTXHXHoOxEtzS301poLADbAC+BLnbDjF+X2MyJkrWp2JbuOkw kkPjhP/mAOrA1iSKbQR1XIXX2GFNklfnJ0rQ0bu/d8r04jWB3lTHan2Db8ntz61hNLSau6ZB4 dxddn0YKkc1nzRSG6qOOcW/9uGjXdfSJ6X2svV8fgk8u+qQPBewaZpvxQ== Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 15:09:56 -0000 Am 30.07.2021 um 13:35 schrieb John R Levine: >> Clearly, Google Scholar should be taught to find the canonical RFCs at >> https://rfc-editor.org/rfc - having many secondary copies is an SEO >> anathema. > > Right.=C2=A0 I hope some sitemaps will help. > ... That would be surprising, but would be good to know. That said, as acting RFC Editor, why don't you just ask them? Best regards, Julian From nobody Fri Jul 30 12:17:25 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B213A0BA9 for ; Fri, 30 Jul 2021 12:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 TonEIG7TtitU; Fri, 30 Jul 2021 12:17:19 -0700 (PDT) Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 8C8383A0BA5; Fri, 30 Jul 2021 12:17:18 -0700 (PDT) From: Jay Daley Message-Id: <05C3AD55-F8FB-44A2-963E-E07F342F3CAA@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_608A72D5-ED8E-4C78-9F9D-DA09A27D9931" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Sat, 31 Jul 2021 07:17:15 +1200 In-Reply-To: Cc: "John R. Levine" , Tools Discussion To: Carsten Bormann References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 19:17:24 -0000 --Apple-Mail=_608A72D5-ED8E-4C78-9F9D-DA09A27D9931 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30/07/2021, at 11:28 PM, Carsten Bormann wrote: >=20 > On 2021-07-29, at 18:57, John R Levine wrote: >>=20 >> The other issue is that Google Scholar isn't finding any of the three = copies of RFCs on our servers. >=20 > Ages ago I had copies of all RFCs in some PDF form on our servers and = finally got some bibliography servers to index them. That must have = been 15 years or more ago, I don=E2=80=99t remember the details. >=20 > Clearly, Google Scholar should be taught to find the canonical RFCs at = https://rfc-editor.org/rfc - having many secondary copies is an SEO = anathema. >=20 > Internet-Drafts, hmm. Many are not arxiv quality, and we don=E2=80=99t = want the I-D repository as a dumping ground for people who just want to = get their garbage into Scholar. But the main problem is that the = references to the drafts will stay active even when the RFC has been = published(*) (or the I-D replaced), so we should be very careful with = what we offer under the URI that will be indexed. >=20 > Let=E2=80=99s stop kicking the can on the doc.ietf.org thing! Do you have a link to a more detailed statement of why we should have = doc.ietf.org ? Jay >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > (*) E.g., I get = https://tools.ietf.org/id/draft-ietf-core-observe-09.html as the first = hit for CoAP Observe. No metadata block, seven versions off, ... >=20 > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: = datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): = https://www.ietf.org/mailman/listinfo/tools-discuss --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_608A72D5-ED8E-4C78-9F9D-DA09A27D9931 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 30/07/2021, at 11:28 PM, Carsten Bormann <cabo@tzi.org> = wrote:

On 2021-07-29, at 18:57, John R Levine <johnl@taugh.com> = wrote:

The other issue is that Google Scholar isn't finding any of = the three copies of RFCs on our servers.

Ages ago I had copies of all RFCs in some PDF form on our = servers and finally got some bibliography servers to index them. =  That must have been 15 years or more ago, I don=E2=80=99t remember = the details.

Clearly, Google Scholar should = be taught to find the canonical RFCs at https://rfc-editor.org/rfc - having many secondary copies = is an SEO anathema.

Internet-Drafts, hmm. =  Many are not arxiv quality, and we don=E2=80=99t want the I-D = repository as a dumping ground for people who just want to get their = garbage into Scholar.  But the main problem is that the references = to the drafts will stay active even when the RFC has been published(*) = (or the I-D replaced), so we should be very careful with what we offer = under the URI that will be indexed.

Let=E2=80= =99s stop kicking the can on the doc.ietf.org thing!

Do = you have a link to a more detailed statement of why we should have doc.ietf.org ?

Jay



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

(*) E.g., I get https://tools.ietf.org/id/draft-ietf-core-observe-09.html = as the first hit for CoAP Observe.  No metadata block, seven = versions off, ...

___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for = discussion, not for action requests or bug reports.
* = Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other = bugs or issues to: ietf-action@ietf.org
List info (including = how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss

-- 
Jay Daley
IETF = Executive Director
jay@ietf.org

= --Apple-Mail=_608A72D5-ED8E-4C78-9F9D-DA09A27D9931-- From nobody Fri Jul 30 12:33:34 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302DB3A0C53; Fri, 30 Jul 2021 12:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.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 9dfqDpn4GvYN; Fri, 30 Jul 2021 12:33:27 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (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 CA0C93A0C4A; Fri, 30 Jul 2021 12:33:26 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 7AC1D600019; Fri, 30 Jul 2021 22:33:19 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1627673599; bh=3gKP/q65FSmbAHR1BcevbOX3ynuXuglgTqVDgMUlrAg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=05Uh7+fUU+Nw+Igk5ZJEgDo95pQK7YM4SfIpfBqbvjhs5+mzRKOAZY4NoRWE+D5iY R4vA22TqPJ5fqUOxeuV1nVqPPpHHPUrQEMM5/KIvzDwAvMfRhMxuLCj4Rr7OsnPh4G vGEz7VyOoNBm6BeiVaKiYf480I9ayhrl52tbBAkA= From: Lars Eggert Message-Id: <68705388-FC6C-4BE0-8E21-05153B637B6B@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D8E25ACF-C6C6-4B94-BC83-D19A2632BE53"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 30 Jul 2021 22:33:18 +0300 In-Reply-To: <05C3AD55-F8FB-44A2-963E-E07F342F3CAA@ietf.org> Cc: Carsten Bormann , "John R. Levine" , Tools Discussion To: Jay Daley References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> <05C3AD55-F8FB-44A2-963E-E07F342F3CAA@ietf.org> X-MailScanner-ID: 7AC1D600019.A3B52 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 19:33:32 -0000 --Apple-Mail=_D8E25ACF-C6C6-4B94-BC83-D19A2632BE53 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2021-7-30, at 22:17, Jay Daley wrote: > On 30/07/2021, at 11:28 PM, Carsten Bormann wrote: >>=20 >> Let=E2=80=99s stop kicking the can on the doc.ietf.org thing! >=20 > Do you have a link to a more detailed statement of why we should have = doc.ietf.org ? And what is meant by it? I have no other email that mentions = doc.ietf.org. Thanks, Lars --Apple-Mail=_D8E25ACF-C6C6-4B94-BC83-D19A2632BE53 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmEEU/4ACgkQVLXDCb9w wVcYcw/9E5VHJciz2P78txaSTaJxpOd2PlMsjXn1IcYEq1PPxscI+XDtdCKEq7K5 rtouOkzoH6xnr5MbB/McZMLHP69jwS1mbtNca6VbpteUd29TK8SqtQLe5GtfJeUE DDqmuG0lA2BU5VZ47uG2cvFsHozb3IN5v/v3G72ky79rQ2QeOCl98KfGwiXBtgbN /XXE140krnGYPghFTSFcMBzUqmyY4M6JUD19sOeyx++FCPFgvmp9SgyJN/cPsTMn CLl/OlfxsEsgfMltHEugxnAZ2FONqekLW+FyXinNnKY5SCQn7f5kLLkyWaOfXtl7 YivLy+7O6+pyY5vSdelcGIRz4LIjZdrP1+Vq6cimXkuADiv+yInCEvlupg0lyxQT A4A6o8gKUfBUk38HgHU0d9KfNU6TarGK6dEPVAvDYs6NmJ6EeUYlaB3Km8crhNXK kgTyFMtNG+p+MscxtGR/ODspS15rKBr1QFl+Bf2Qp0+adFQIC12Te15MYUvrGJCW M61f53/q5V/PO00VO2uUN8QFjazOARNWNh4YhfpYMrcvyAIZW4tfXt7OU0aSUkqD hON0xZxeO44SATLlt7c3mIKRBcZl4qHOYGMpbtxroT78GztlrB5g4d1v616B5fFG IqgLpv+F5UTGLiw0J5P0hMHfMpoVpu0T1RRHGx9tNwRHRfpFLwE= =XQqu -----END PGP SIGNATURE----- --Apple-Mail=_D8E25ACF-C6C6-4B94-BC83-D19A2632BE53-- From nobody Fri Jul 30 12:38:53 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E64B23A0CEE for ; Fri, 30 Jul 2021 12:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aruba.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaaXXysjuwTN for ; Fri, 30 Jul 2021 12:38:36 -0700 (PDT) Received: from smtpcmd10101.aruba.it (smtpcmd10101.aruba.it [62.149.156.101]) by ietfa.amsl.com (Postfix) with ESMTP id 28A0F3A0CA8 for ; Fri, 30 Jul 2021 12:38:35 -0700 (PDT) Received: from [192.168.1.234] ([2.232.93.8]) by Aruba Outgoing Smtp with ESMTPSA id 9YKzmoKu2nyXH9YKzmsb9d; Fri, 30 Jul 2021 21:38:29 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aruba.it; s=a1; t=1627673909; bh=r3gtCuvRfEx11zm5IEXCGPorVX02oe6fKOzRm+tQYPw=; h=Subject:To:From:Date:MIME-Version:Content-Type; b=fYG5vtfEJUcP8merM/s0fgcUK6HfzAeUOuJaotOPWlNiHwW67srDNocgoPOrD+2gU LDZP092UYuJwJjwSnLLllwOIf45nlohRpktaxDebYas6M3C4HlLoyV41iUh046ciYU MqD0h0VpibxiZLd7UoxXaeQKJd1CoA5CTB3OJAmDKE1VqSPdCjGm049HYsp1kCxN6j 8sDgg5lQzSQcab0RAo+E2F4hBZJNfeHRNfrAgyQl4YIioXXqBGZQqjgrPrJJ9deh8s nihzsEy1eBgwqcTAnp6RmH1N2F4Tu/GTv5NmFbcaUOElfD2eehDV6w2jrXvbfEXaVm N4k4d4dEC86lA== To: 111attendees@ietf.org References: Cc: tools-discuss@ietf.org Reply-To: tools-discuss@ietf.org From: Meetecho IETF support Message-ID: <4268651f-6bd7-10ce-6ed8-a758bd956062@meetecho.com> Date: Fri, 30 Jul 2021 21:38:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEBf1i1kcjY24kCLLBN+YDgvahFGZD5MBToTqVFqKSx3JreZKInS5aeNalTVvIijMmn1+xBwTsW4ZWRvl+iSecmDxbdbvWPEKAhdFMbsk0/ODKEl6vUz 8s6cBRl1xAJ4MTmP7if2bGTkXY0L7gGawXma9TlovKKKuXdOL+8AsAJxxnmV2bQIey/S6LSDpos/9cTQ9Hs2ePHfaTbAFPUcyFg= Archived-At: Subject: Re: [Tools-discuss] [111attendees] Positive observations and proposals for improvements to Meetecho (was: Re: Re: So, what are jabber scribes actually doing, these days?) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 19:38:51 -0000 All, chiming in just to say that we at Meetecho appreciate and value your feedback. We'll definitely take it into account when developing the future releases of the platform. We'll provide comments on the points raised as soon as we get the chance to parse them, i.e., when the meeting is over. Also, I'm cc'ing tools-discuss@ietf.org and setting the reply-to header to that list as well, as that's the right place to discuss enhancements and provide feedback that would be easier for us to collect. Best, Alessandro Il 30/07/21 19:37, Spencer Dawkins at IETF ha scritto: > I should have changed the Subject a LONG time ago! But this thread has > morphed into helpful observations and suggestions, so, if I might add a > couple of things ... > > I agree that Meetecho has been improving (and just for fun, the Meetecho > guys were participants in the MEDIACTL session I was co-chairing in > Hiroshima at IETF 76 in November 2009, and they roped in a team member > from Italy during the discussion using whatever the toolset was back > then, so many of you have no idea how MUCH they've improved 😀). > > I see that we've already mentioned detaching the chat window, and > usually I remember that we can detach the chat by Tuesday of each IETF > meeting week at the latest, which is almost certainly a result of not > having THAT much experience with Meetecho during the four months between > meetings. Now that we can use Meetecho for interim meetings, that will > help me remember more clearly, so good there, too. > > The one thing I've noticed this week is how difficult it is to figure > out who is speaking if they aren't sending video, and there's a long > list of people in the queue. The suggestion to move the speakers above > the queue would improve that, and so would simply displaying the active > speaker names in the screen space where their video would have gone, if > the person had been sending video.One reason that matters, is that it's > helpful for everyone to get the speaker's name right in the minutes. > That's not just for new attendees, I'm starting to forget what people > sound like, unless I'm talking to them regularly, or they have a very > distinctive speech pattern, so I've definitely depending on seeing names > when I'm taking minutes. . > > The one thing I was thinking about, as I read through this thread, was > that we are kinda *not *talking about what the IETF thinks the target > audience for our conferencing tool is. > > * For probably the last couple of IETFs, I have a GREAT setup for > remote participation (my laptop screen, plus two 25-inch monitors). > But I do have tiled windows on all three screens. > * If we think people who can't throw a few hundred dollars at monitor > screens are part of our target audience, that's worth noting. > * If we think we're going to have hybrid meetings, in at least some > scenarios, it's going to be good to use Meetecho in the conference > rooms (especially if we need to be distancing, so more spread out, > front to back in the conference rooms). > * Even if we aren't doing hybrid meetings, I've participated in some > working group meetings from my hotel room, but I wasn't tryng to > co-chair a meeting, or even to present at a meeting. > * When Michael Richardson and I talked to the Cellar working group > participants about switching to Meetecho for our (monthy) interims, > the first question we got was, "is there an iOS/Adroid client?" I > haven't checked Meetecho on my phone in years, but I'd bet offhand > that (1) it would work, but (2) it might not be as easy to use as > some other conferencing systems, on those devices. Do people have > experience with that? > > I'll let you folks continue to share these positive observations and > proposals. Make Good Choices, of course. > > Best, > > Spencer > > On Thu, Jul 29, 2021 at 6:15 PM Jay Daley > wrote: > > Thanks Bron.  Personally I think that’s a great usability adjustment > and will forward to the Meetecho team for them to consider. > > Jay > > > On 30/07/2021, at 10:58 AM, Bron Gondwana > wrote: > > > > On Fri, Jul 30, 2021, at 05:21, Jay Daley wrote: > >> No we have absolutely not pushed Meetecho into being "just a > contractor", they are a valued partner and we work very well > together.  If you have any doubts about that then ask them directly. > >> > >> It is disappointing that you have escalated a personal concern > that you have with our services into such a strong criticism when > that is entirely unsupported by any evidence. > > > > Jay, I agree with your sentiment here - this attitude to Meetecho > is counterproductive.  They've done great work for the last couple > of IETFs and the experience is improving each time.  I have > particularly appreciated the embedded slide management, and I'm sure > that will be even better next time too. > > > > Regarding the specific interface issues that remain, I do think > there's a question of "where do we propose improvements in a way > that will be noticed"?  I've seen the suggestion made very many > times that the "speaker" area (where the video shows) should have > additional lines for each person sending anything, rather than that > information being at the top of the participant list.  This is much > more like the experience with other chat systems, for example Zoom > shows either a photo or a blank item for somebody who isn't > currently sending video, but they're otherwise treated "the same" as > a person sending video in terms of real-estate and where to look for > their presence by default. > > > > Right now with meetecho, my eyes are normally at the video are > when people are speaking, but if a non-video person is speaking I > need to look across to the other side of the screen to see the audio > indication. > > > > And as was also suggested in this thread, you can't scroll the > participant list to find someone to chat to, because they jump to > the top when they are sending, then back to alphabetical position. > This is also a usability pain.  Separating "the list of > participants" (which wouldn't move about) and "the list of people > sending something" with the video and audio indications being > together in one place would be a significant improvement.  And as an > additional benefit, when you're looking at the chat window, you > would still be able to see all the details of who is sending > (including yourself - if you're sending then the indicator of your > own audio should be the same as the indicator of everyone else's > audio, rather than being in yet a third location up under your own > name). > > > > > > So those two names would appear in the right hand side, and also > still have their name in the participant list, and the video feeds > would each have a "here's what's being sent".  Chairs would always > have a presence on the right, with whatever they were currently > sending - and the "participants" tab would only have the list of > participants, and not be a place you needed to go to see activity, > so you could mostly keep the chat tab open. > > > > Bron. > > > > > > -- > >   Bron Gondwana, CEO, Fastmail Pty Ltd > > brong@fastmailteam.com > > > > > > -- > > 111attendees mailing list > > 111attendees@ietf.org > > https://www.ietf.org/mailman/listinfo/111attendees > > > -- > Jay Daley > IETF Executive Director > jay@ietf.org > > -- > 111attendees mailing list > 111attendees@ietf.org > https://www.ietf.org/mailman/listinfo/111attendees > > > From nobody Fri Jul 30 12:42:27 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA67E3A0CBB for ; Fri, 30 Jul 2021 12:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dml15QZRvxTR for ; Fri, 30 Jul 2021 12:42:18 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D86383A0CAE for ; Fri, 30 Jul 2021 12:42:18 -0700 (PDT) Received: from unformal.localdomain ([47.186.34.206]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 16UJgGtg057891 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Fri, 30 Jul 2021 14:42:17 -0500 (CDT) (envelope-from rjsparks@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1627674137; bh=WPNce3vMhk5Jft03Mashpk/TJs/FM6rSYIfPu2sXSis=; h=Subject:To:References:From:Date:In-Reply-To; b=vsFFtuktEWQAOkuhutbODT7UHXDf7vAar7Z9C1FQM/9lM/dwH84ryYqHwLy6GDdN4 DCCwlPEvBTzD2QYPDnvA7ZLdH2KajdR1LAdCa0NXb7bG5ru/NzLHfTi1QYZzUBrtEO pJ8hj04UkOedJVxrjvWZm1T/b+K5UjkAV03mxqrI= X-Authentication-Warning: raven.nostrum.com: Host [47.186.34.206] claimed to be unformal.localdomain To: tools-discuss@ietf.org References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> <05C3AD55-F8FB-44A2-963E-E07F342F3CAA@ietf.org> <68705388-FC6C-4BE0-8E21-05153B637B6B@eggert.org> From: Robert Sparks Message-ID: <9c923375-41df-f480-1742-f397a561fbc9@nostrum.com> Date: Fri, 30 Jul 2021 14:42:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <68705388-FC6C-4BE0-8E21-05153B637B6B@eggert.org> Content-Type: multipart/alternative; boundary="------------8E6D26EFADC6CEA509316BD9" Content-Language: en-US Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 19:42:26 -0000 This is a multi-part message in MIME format. --------------8E6D26EFADC6CEA509316BD9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit A quick skim of this might help provide context: https://mailarchive.ietf.org/arch/search/?q=doc.ietf.org On 7/30/21 2:33 PM, Lars Eggert wrote: > On 2021-7-30, at 22:17, Jay Daley wrote: >> On 30/07/2021, at 11:28 PM, Carsten Bormann wrote: >>> Let’s stop kicking the can on the doc.ietf.org thing! >> Do you have a link to a more detailed statement of why we should have doc.ietf.org ? > And what is meant by it? I have no other email that mentions doc.ietf.org. > > Thanks, > Lars > > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss --------------8E6D26EFADC6CEA509316BD9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

A quick skim of this might help provide context:

https://mailarchive.ietf.org/arch/search/?q=doc.ietf.org

On 7/30/21 2:33 PM, Lars Eggert wrote:
On 2021-7-30, at 22:17, Jay Daley <jay@ietf.org> wrote:
On 30/07/2021, at 11:28 PM, Carsten Bormann <cabo@tzi.org> wrote:
Let’s stop kicking the can on the doc.ietf.org thing!
Do you have a link to a more detailed statement of why we should have doc.ietf.org ?
And what is meant by it? I have no other email that mentions doc.ietf.org.

Thanks,
Lars


___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for discussion, not for action requests or bug reports.
* Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other bugs or issues to: ietf-action@ietf.org
List info (including how to Unsubscribe): https://www.ietf.org/mailman/listinfo/tools-discuss
--------------8E6D26EFADC6CEA509316BD9-- From nobody Fri Jul 30 14:00:45 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D421F3A105A; Fri, 30 Jul 2021 14:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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=akamai.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 czXvYrFTMDu1; Fri, 30 Jul 2021 14:00:33 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DB6F3A1066; Fri, 30 Jul 2021 14:00:28 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 16UL07fx009920; Fri, 30 Jul 2021 22:00:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=TQ7745MmV7Y078w/HNa/fQlKMX8XRPcZB/gtJZkj78E=; b=lcvfeME+ytE/5zstJ6RNSSvpTHjqiDdI1lET9zKJ4RZS6A0Iqw5jWSkAkJxoYj3de+ic hNbOhheIsD8Uihh7o8rH72mrkZyQ2OenVs+i/cvgHyqK0R/i3CExaMeSb3vyYqocGo3S C6KhRbN7miEMXZ1sQmSCusnple2JvN9b6/wlVjr7+MfRgRmEe7ywBh0PIirNoK9vkZCR kEUyi/289UN6XqU69wuXSNI5SmqybTNqNCRcorli3SUPzBKiz2jxsxHdexcCrjo7AtH/ 1931TX1m+jBaGGVylD0mKtZAYMEX+FN/Ty4usMlxV7vOwyZPzy2yJdY2xu/5wAabI6qn Sw== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 3a46sf7dsd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Jul 2021 22:00:26 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 16UKnfNm012056; Fri, 30 Jul 2021 17:00:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint7.akamai.com with ESMTP id 3a36pyeqxu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 30 Jul 2021 17:00:25 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 30 Jul 2021 16:00:25 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.023; Fri, 30 Jul 2021 16:00:24 -0500 From: "Salz, Rich" To: Carsten Bormann , "111attendees@ietf.org" <111attendees@ietf.org> CC: "tools-discuss@ietf.org" Thread-Topic: [111attendees] Why do we allow people to edit CodiMD meeting notes who are not logged in? Thread-Index: AQHXhYU2DXfZ4WM+WE6D1qot4aPtwqtcEY0A Date: Fri, 30 Jul 2021 21:00:24 +0000 Message-ID: <65C1CE9C-7D57-494C-9002-974B89009DA3@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.51.21071101 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: <38223A747FECA24F92A53677788868B5@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-30_11:2021-07-30, 2021-07-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 mlxscore=0 bulkscore=0 malwarescore=0 suspectscore=0 mlxlogscore=968 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107300142 X-Proofpoint-GUID: xs_nM2aM6ILUIb1i8fjTPVNjAFV7eyVF X-Proofpoint-ORIG-GUID: xs_nM2aM6ILUIb1i8fjTPVNjAFV7eyVF X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-30_11:2021-07-30, 2021-07-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 malwarescore=0 mlxscore=0 mlxlogscore=927 lowpriorityscore=0 phishscore=0 impostorscore=0 clxscore=1011 suspectscore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2107140000 definitions=main-2107300143 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.33) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint7 Archived-At: Subject: Re: [Tools-discuss] [111attendees] Why do we allow people to edit CodiMD meeting notes who are not logged in? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:00:39 -0000 VGhlIGRlZmF1bHQgaXMgImFueW9uZSBjYW4gZWRpdCIgYW5kIGl0IHNob3VsZCBiZSAiYW55b25l IGxvZ2dlZCBpbiBjYW4gZWRpdCIgIFlvdSBjYW4gY2hhbmdlIGl0IGJ5IGNsaWNraW5nIG9uICJm cmVlbHkiIHdoaWNoIGFwcGVhcnMgaW4gdGhlIHVwcGVyLXJpZ2h0IG9mIHRoZSBIVE1MLXZpZXcg cGFuZWwuICBDQydpbmcgdG9vbHMtZGlzY3VzcyB0byBnZXQgdGhhdCBkZWZhdWx0IGNoYW5nZWQg Zm9yIG5leHQgdGltZSwgaWYgcG9zc2libGUuDQoNCg== From nobody Fri Jul 30 14:00:56 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351D93A1051 for ; Fri, 30 Jul 2021 14:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEn5NtRrRlxM for ; Fri, 30 Jul 2021 14:00:33 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 397513A106F for ; Fri, 30 Jul 2021 14:00:19 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id g23-20020a17090a5797b02901765d605e14so16126490pji.5 for ; Fri, 30 Jul 2021 14:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zpwaejSEiOgpECjEJN4/L0EQ8sfrRrTs/pDR+as+EM0=; b=EwN8+mtKRLE+tHtNTBxRVALPKzGMjDd3E9YnhjLZj0g97K7v7WiUVq2g2uTz1UmHak gmzsC1dtDALqTBC+Lk3vXB7DbE9uEPyV7wyMQ7x43/+iDJTQvwmY/q6LpNhL+Mt3HXhx ARDM3jHyx+Uiz0nwSzz3Mz1pXQKVjAYqBu2ME/CRCknok5PCL1EaiO6PTlbs7RKA/tvr RK7ApbzRjO38pjK0GRELpjviU8JJGmzsgort9HPf2SKdOzQ7ELcrIY32mxBSD01jhLRy VmXtEEqA5lqZIzbYDv7MiKCsdeUyhPmBi+vLU1xMU/1qut10teHSGi+8VrJ2CigcGxO1 QD5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zpwaejSEiOgpECjEJN4/L0EQ8sfrRrTs/pDR+as+EM0=; b=EMWdu9fZvNZjWwKzm5zTsC9W3K0dofxzQk/OUw0SvMYGm3WEWU0IdhhyVPZS7FopBT FAmvr71Jwj31nHO0IWw35Yfzx3YQw3n/eWT2If0m+/fOXWtIi5pWDdYjNooSzXyB4x/A w2JnFm5qlKmCSwQZ43Lb/s5ZxbCPRDcITjT1XWhRTa4IzqTq27/fDRKmoabAI9uNRPik K1ip5beaKnAbNnLqJ3XyBLaBPzHJYLzopnHl4BDmBt4QfW2RrClVeSLf/431PRYCt+R1 8KRMqiRByWulsR3IKtMfWHOwSas5HDZ9lSuD3g3YnCo45PQWCWgQB+4nedhrdBJdeEUU 4MLA== X-Gm-Message-State: AOAM532+6qERlpEv9pCFbVHGMFWI6nDLyKErmWL7zm2YLyhroW+FAqL8 EfNcOmqcJGIzDGccSQEbpBS5pD6W5Ti18Q== X-Google-Smtp-Source: ABdhPJwNAtbYC3AyNfUetF6PKi1gJAmAS/PB8PAIh076WsHkksl/qKyfV2e36R0kiYgXs4VYZkhQ/Q== X-Received: by 2002:a63:b48:: with SMTP id a8mr1898494pgl.169.1627678817870; Fri, 30 Jul 2021 14:00:17 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c17sm3311619pfv.68.2021.07.30.14.00.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 30 Jul 2021 14:00:17 -0700 (PDT) To: John R Levine , Carsten Bormann Cc: Tools Discussion References: <20210729035232.EF66B254891D@ary.qy> <2f359f5-838c-f1fe-bdb0-156d98ddc0e5@taugh.com> From: Brian E Carpenter Message-ID: Date: Sat, 31 Jul 2021 09:00:14 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:00:39 -0000 Several times, I've been asked to claim I-Ds by Google Scholar and have rejected them. I doubt if there's an active feed, but if they analyze the= citations in a publication that cites an I-D, it will get into their syst= em. The fact that they point to a University of Auckland site for RFC8799 is direct proof that they either index the university's publication repository, or that they index the entirety of repositories based on symplectic.co.uk. They do have some very strange things, though. With a little effort, you can extract this citation: @article{carpenter1994aeiou, title=3D{AEIOU: Address extension by IP option usage}, author=3D{Carpenter, B}, journal=3D{Internet draft-carpenter-aeiou-00. txt}, year=3D{1994} } Regards Brian On 30-Jul-21 23:35, John R Levine wrote: >> Clearly, Google Scholar should be taught to find the canonical RFCs at=20 https://rfc-editor.org/rfc - having many secondary copies is an SEO anath= ema. >=20 > Right. I hope some sitemaps will help. >=20 >> Internet-Drafts, hmm. Many are not arxiv quality, and we don=E2=80=99= t want the=20 >> I-D repository as a dumping ground for people who just want to get the= ir=20 >> garbage into Scholar. But the main problem is that the references to = >> the drafts will stay active even when the RFC has been published(*) (o= r=20 >> the I-D replaced), so we should be very careful with what we offer und= er=20 >> the URI that will be indexed. >=20 > I agree they're not what Scholar is looking for. >=20 > I'm not worried about people gaming it, you should be able to get anyth= ing=20 > into Scholar if you put it on a web server with the right metadata, but=20 > the last thing I want is yet another reason people will imagine that ev= ery=20 > I-D is an Internet Standard. >=20 > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.= ly >=20 >=20 > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.= org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): https://www.ietf.org/mailman/= listinfo/tools-discuss >=20 From nobody Fri Jul 30 14:03:05 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CBF3A10CA; Fri, 30 Jul 2021 14:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=uHuU4FvS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LNOwmCI1 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 olITmiEtKksO; Fri, 30 Jul 2021 14:02:54 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6756A3A10B3; Fri, 30 Jul 2021 14:02:54 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 1846D32008FD; Fri, 30 Jul 2021 17:02:52 -0400 (EDT) Received: from imap43 ([10.202.2.93]) by compute6.internal (MEProxy); Fri, 30 Jul 2021 17:02:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=z5y4 0kXlg+VVCWNEmhjEL86KBeX2mk4I477m8YJ5jsI=; b=uHuU4FvSCJLPQlsWf/l/ npk0R4GjVNmI4B2baZkEasYEYNZh36kUzOdMYxO8Uvs+liaLhGrRVXt5l/HXylhP BIORBzeoAl0znkpZM3tPfNSq69BEk70KfJD2PFPg8U11WYtVdVI+n5fI7+8JdZt5 SvnGM6UPoR1LXPQ8TFsFVqdfxlyHlSPU1B1uHTWJyf89x/Ddxn+v5NsdMj9qdct9 iffxPfRXebZvfNuI1MqVe3cJEe/UupMtaMAJl7iJXaqSMOYmIo6BggIdJ8QSJhXX zz0rglX2I5Oyh0iWEXAXKLma7V6rqYFjRf5goZgFvHM01Q4TDIUTwRjJgSqb8tJs Cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=z5y40k Xlg+VVCWNEmhjEL86KBeX2mk4I477m8YJ5jsI=; b=LNOwmCI1jzV3OnlfvH+de/ n88AJRtXmRN1nDRNZxOdJk8Il7+A5VNY/eFf5l+P/JunJpdLdSlVQm5uoBmJ8JFN tU7D5LjCHOE2qO7+pJKLAFnhIgRo79crDVC7+GmpnXu8QIV8kk6z0yLT13qWRAl8 2hkHRFS03ihQOPokmfnjRV1gu1xrPAGX/c28t3nODHjkE1kAwP6kCjgo/vuSInN+ GSAgqRj9AU6ugh1IeKeq1tvBWAA6xh1W3fI5X1bJf1/sWE5+gdRDn8cnGVDSQ0A4 om/i+OQNrXHTdnxBS20ViiI8rR0+9BYqnpVJekOYZVZiwDx+i6Wu9VP16yX6QBeg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrheehgddugeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeffvdekfeegle eiueettddtffehveevffefkeduvddttdekiefgjeduvdfhvdduleenucffohhmrghinhep ihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2A3F3AC0DD0; Fri, 30 Jul 2021 17:02:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-1002-g563fbe43fc-fm-ubox-20210727.001-g563fbe43 Mime-Version: 1.0 Message-Id: <99ae28be-dd15-4018-bccc-a1f61ce19e47@dogfood.fastmail.com> In-Reply-To: <4268651f-6bd7-10ce-6ed8-a758bd956062@meetecho.com> References: <4268651f-6bd7-10ce-6ed8-a758bd956062@meetecho.com> Date: Sat, 31 Jul 2021 07:02:19 +1000 From: "Bron Gondwana" To: 111attendees@ietf.org Cc: tools-discuss@ietf.org Content-Type: multipart/alternative; boundary=6dbf78494a87456c8b6f6dbe44fec6f6 Archived-At: Subject: Re: [Tools-discuss] =?utf-8?q?=5B111attendees=5D_Positive_observatio?= =?utf-8?q?ns_and_proposals_for_improvements_to_Meetecho_=28was=3A_Re=3A_R?= =?utf-8?q?e=3A_So=2C_what_are_jabber_scribes_actually_doing=2C_these_days?= =?utf-8?b?Pyk=?= X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:03:04 -0000 --6dbf78494a87456c8b6f6dbe44fec6f6 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Ooh, we're going a full "suggestions for meetecho" thread? I'd like to = propose some things! *that we replace the current "raise hands" tool:* *... *which is based on an expired draft which isn't going to be refresh= ed - with a better tool that allows the chairs to: a) label each option b) have more than 2 options (max 9 maybe) c) select between "choose one" and "choose N" modes (checkbox vs radio b= utton) ... and which appears IN PLACE of the slides when enabled, so that meeti= ng participants don't have to navigate to a separate tab to interact.=20 More generally, it's too easy for some participants to be lost on differ= ent tabs where they can't see the slides. The multiple views where you = can see individual talking heads in more detail are not actually valuabl= e I don't think - if slides are showing they should be the bulk of the s= creen because they need to be read - and if a poll is showing then for s= ure it should be taking over the screen. *a "temporary mute" mode that keeps the audio stream open:* This is still an issue for me. I often mute myself while chairing so I = can take notes without my keyboard sound interrupting the chat - but it = means that I can't easily respond to somebody because the rejigging of t= he audio channel not only creates a hiccup in the incoming audio feed wh= ich means I might miss something someone says, but it also creates enoug= h of a delay that by the time I could have responded the other party's m= ental state has moved on. Timing is really important in conversation and we're already fighting wi= th the quarter second delay imposed by the size of the planet. Addition= al delay makes it unwieldy. *allow multiple connections by the same person to the same session:* I have multiple times wanted to switch device temporarily - from my desk= top computer to a phone / ipad so I can temporarily move to another loca= tion while continuing to follow a meeting. Multiple connection support = would mean I could switch over without a break. Sure it could be abused by people "sharing" a login, but that would be p= retty obvious if both parties tried to participate, and given that we al= low fee waivers anyway, it's unlikely to be abused significantly. Sure = there are Jabber naming issues, but we can avoid that by giving each jab= ber name with a serial number (which I believe already happens now?) ... I've already written these up separately in the past, but: *information about who is speaking in the same place as video feeds* See my previous email :) Basically the "participant list" should just b= e an ordered list of participants and only needs to be switched to when = seeing who is in the call or opening an individual message to them (and = people don't get moved out of order when they're sending something). Th= e "who is sending something" list should be all together with the video,= and chairs pinned even if they're sending nothing right now. Along with visual indicators of "currently sending audio" on people so w= e know who of those with their audio channel open are currently speaking= , this makes it easier to look in one place to see the source of all sou= nd, and eyes can generally flit between the right hand side (video and a= udio indicators) and the slides, without needing to also track via the p= articipant list. *flexible "assign chair"**:* This one hasn't come up in practice, but the chairs for meetings are pre= -assigned from datatracker. It would be great for ADs and the meetecho = reps in each meeting to be able to upgrade anybody to a chair role or re= move a chair role with a simple click. In real rooms, anyone can go sit in the chair at the front of the room, = and it's not abused because of social convention. I believe that we can= map that to this virtual space and still have it work sensibly. People= won't take the chair unless there's a legitimate reason to do it, and s= o long as it's logged - if someone does consistently abuse it we have pr= ocesses to eject them from the IETF for misbehaviour. This has become less important with the ability for individuals to turn = on both audio and video themselves, so the chair is going less busywork = just approving access, but it would be good to make it possible for some= one else to step into the chair if the regular chairs are unable to atte= nd or lose network, rather than making the meeting less able to run. Bron. On Sat, Jul 31, 2021, at 05:38, Meetecho IETF support wrote: > All, >=20 > chiming in just to say that we at Meetecho appreciate and value your=20 > feedback. We'll definitely take it into account when developing the=20 > future releases of the platform. We'll provide comments on the points=20 > raised as soon as we get the chance to parse them, i.e., when the=20 > meeting is over. >=20 > Also, I'm cc'ing tools-discuss@ietf.org and setting the reply-to heade= r=20 > to that list as well, as that's the right place to discuss enhancement= s=20 > and provide feedback that would be easier for us to collect. >=20 > Best, > Alessandro >=20 > Il 30/07/21 19:37, Spencer Dawkins at IETF ha scritto: > > I should have changed the Subject a LONG time ago! But this thread h= as=20 > > morphed into helpful observations and suggestions, so, if I might ad= d a=20 > > couple of things ... > >=20 > > I agree that Meetecho has been improving (and just for fun, the Meet= echo=20 > > guys were participants in the MEDIACTL session I was co-chairing in=20 > > Hiroshima at IETF 76 in November 2009, and they roped in a team memb= er=20 > > from Italy during the discussion using whatever the toolset was back=20 > > then, so many of you have no idea how MUCH they've improved =F0=9F=98= =80). > >=20 > > I see that we've already mentioned detaching the chat window, and=20 > > usually I remember that we can detach the chat by Tuesday of each IE= TF=20 > > meeting week at the latest, which is almost certainly a result of no= t=20 > > having THAT much experience with Meetecho during the four months bet= ween=20 > > meetings. Now that we can use Meetecho for interim meetings, that wi= ll=20 > > help me remember more clearly, so good there, too. > >=20 > > The one thing I've noticed this week is how difficult it is to figur= e=20 > > out who is speaking if they aren't sending video, and there's a long=20 > > list of people in the queue. The suggestion to move the speakers abo= ve=20 > > the queue would improve that, and so would simply displaying the act= ive=20 > > speaker names in the screen space where their video would have gone,= if=20 > > the person had been sending video.One reason that matters, is that i= t's=20 > > helpful for everyone to get the speaker's name right in the minutes.=20 > > That's not just for new attendees, I'm starting to forget what peopl= e=20 > > sound like, unless I'm talking to them regularly, or they have a ver= y=20 > > distinctive speech pattern, so I've definitely depending on seeing n= ames=20 > > when I'm taking minutes. . > >=20 > > The one thing I was thinking about, as I read through this thread, w= as=20 > > that we are kinda *not *talking about what the IETF thinks the targe= t=20 > > audience for our conferencing tool is. > >=20 > > * For probably the last couple of IETFs, I have a GREAT setup for > > remote participation (my laptop screen, plus two 25-inch monitor= s). > > But I do have tiled windows on all three screens. > > * If we think people who can't throw a few hundred dollars at moni= tor > > screens are part of our target audience, that's worth noting. > > * If we think we're going to have hybrid meetings, in at least some > > scenarios, it's going to be good to use Meetecho in the conferen= ce > > rooms (especially if we need to be distancing, so more spread ou= t, > > front to back in the conference rooms). > > * Even if we aren't doing hybrid meetings, I've participated in so= me > > working group meetings from my hotel room, but I wasn't tryng to > > co-chair a meeting, or even to present at a meeting. > > * When Michael Richardson and I talked to the Cellar working group > > participants about switching to Meetecho for our (monthy) interi= ms, > > the first question we got was, "is there an iOS/Adroid client?" I > > haven't checked Meetecho on my phone in years, but I'd bet offha= nd > > that (1) it would work, but (2) it might not be as easy to use as > > some other conferencing systems, on those devices. Do people have > > experience with that? > >=20 > > I'll let you folks continue to share these positive observations and=20 > > proposals. Make Good Choices, of course. > >=20 > > Best, > >=20 > > Spencer > >=20 > > On Thu, Jul 29, 2021 at 6:15 PM Jay Daley > > wrote: > >=20 > > Thanks Bron. Personally I think that=E2=80=99s a great usabilit= y adjustment > > and will forward to the Meetecho team for them to consider. > >=20 > > Jay > >=20 > > > On 30/07/2021, at 10:58 AM, Bron Gondwana > > wrote: > > > > > > On Fri, Jul 30, 2021, at 05:21, Jay Daley wrote: > > >> No we have absolutely not pushed Meetecho into being "just a > > contractor", they are a valued partner and we work very well > > together. If you have any doubts about that then ask them direc= tly. > > >> > > >> It is disappointing that you have escalated a personal conce= rn > > that you have with our services into such a strong criticism when > > that is entirely unsupported by any evidence. > > > > > > Jay, I agree with your sentiment here - this attitude to Meet= echo > > is counterproductive. They've done great work for the last coup= le > > of IETFs and the experience is improving each time. I have > > particularly appreciated the embedded slide management, and I'm = sure > > that will be even better next time too. > > > > > > Regarding the specific interface issues that remain, I do thi= nk > > there's a question of "where do we propose improvements in a way > > that will be noticed"? I've seen the suggestion made very many > > times that the "speaker" area (where the video shows) should have > > additional lines for each person sending anything, rather than t= hat > > information being at the top of the participant list. This is m= uch > > more like the experience with other chat systems, for example Zo= om > > shows either a photo or a blank item for somebody who isn't > > currently sending video, but they're otherwise treated "the same= " as > > a person sending video in terms of real-estate and where to look= for > > their presence by default. > > > > > > Right now with meetecho, my eyes are normally at the video are > > when people are speaking, but if a non-video person is speaking I > > need to look across to the other side of the screen to see the a= udio > > indication. > > > > > > And as was also suggested in this thread, you can't scroll the > > participant list to find someone to chat to, because they jump to > > the top when they are sending, then back to alphabetical positio= n.=20 > > This is also a usability pain. Separating "the list of > > participants" (which wouldn't move about) and "the list of people > > sending something" with the video and audio indications being > > together in one place would be a significant improvement. And a= s an > > additional benefit, when you're looking at the chat window, you > > would still be able to see all the details of who is sending > > (including yourself - if you're sending then the indicator of yo= ur > > own audio should be the same as the indicator of everyone else's > > audio, rather than being in yet a third location up under your o= wn > > name). > > > > > > > > > So those two names would appear in the right hand side, and a= lso > > still have their name in the participant list, and the video fee= ds > > would each have a "here's what's being sent". Chairs would alwa= ys > > have a presence on the right, with whatever they were currently > > sending - and the "participants" tab would only have the list of > > participants, and not be a place you needed to go to see activit= y, > > so you could mostly keep the chat tab open. > > > > > > Bron. > > > > > > > > > -- > > > Bron Gondwana, CEO, Fastmail Pty Ltd > > > brong@fastmailteam.com > > > > > > > > > -- > > > 111attendees mailing list > > > 111attendees@ietf.org > > > https://www.ietf.org/mailman/listinfo/111attendees > > > >=20 > > --=20 > > Jay Daley > > IETF Executive Director > > jay@ietf.org > >=20 > > --=20 > > 111attendees mailing list > > 111attendees@ietf.org > > https://www.ietf.org/mailman/listinfo/111attendees > > > >=20 > >=20 >=20 > --=20 > 111attendees mailing list > 111attendees@ietf.org > https://www.ietf.org/mailman/listinfo/111attendees >=20 -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --6dbf78494a87456c8b6f6dbe44fec6f6 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ooh, we're going a full "suggestions for meetecho" th= read?  I'd like to propose some things!

that we r= eplace the current "raise hands" tool:

... whi= ch is based on an expired draft which isn't going to be refreshed - with= a better tool that allows the chairs to:

a) label each o= ption
b) have more than 2 opt= ions (max 9 maybe)
c) select = between "choose one" and "choose N" modes (checkbox vs radio button)
=

... and which appears IN PLACE of the slides when enabled, s= o that meeting participants don't have to navigate to a separate tab to = interact. 

More generally, it's too easy for some pa= rticipants to be lost on different tabs where they can't see the slides.=   The multiple views where you can see individual talking heads in = more detail are not actually valuable I don't think - if slides are show= ing they should be the bulk of the screen because they need to be read -= and if a poll is showing then for sure it should be taking over the scr= een.

a "temporary mute" mode that keeps the audio stre= am open:

This is still an issue for me.  I often= mute myself while chairing so I can take notes without my keyboard soun= d interrupting the chat - but it means that I can't easily respond to so= mebody because the rejigging of the audio channel not only creates a hic= cup in the incoming audio feed which means I might miss something someon= e says, but it also creates enough of a delay that by the time I could h= ave responded the other party's mental state has moved on.

Timing is really important in conversation and we're already fighting = with the quarter second delay imposed by the size of the planet.  A= dditional delay makes it unwieldy.

allow multiple conn= ections by the same person to the same session:

I have = multiple times wanted to switch device temporarily - from my desktop com= puter to a phone / ipad so I can temporarily move to another location wh= ile continuing to follow a meeting.  Multiple connection support wo= uld mean I could switch over without a break.

Sure it cou= ld be abused by people "sharing" a login, but that would be pretty obvio= us if both parties tried to participate, and given that we allow fee wai= vers anyway, it's unlikely to be abused significantly.  Sure there = are Jabber naming issues, but we can avoid that by giving each jabber na= me with a serial number (which I believe already happens now?)
=

...

I've already written these up separately in the= past, but:

information about who is speaking in the s= ame place as video feeds
=
See my previous email :)&nbs= p; Basically the "participant list" should just be an ordered list of pa= rticipants and only needs to be switched to when seeing who is in the ca= ll or opening an individual message to them (and people don't get moved = out of order when they're sending something).  The "who is sending = something" list should be all together with the video, and chairs pinned= even if they're sending nothing right now.

Along with vi= sual indicators of "currently sending audio" on people so we know who of= those with their audio channel open are currently speaking, this makes = it easier to look in one place to see the source of all sound, and eyes = can generally flit between the right hand side (video and audio indicato= rs) and the slides, without needing to also track via the participant li= st.

flexible "assign chair":

This one hasn't come up in practice, but the chairs for meetings are pr= e-assigned from datatracker.  It would be great for ADs and the mee= techo reps in each meeting to be able to upgrade anybody to a chair role= or remove a chair role with a simple click.

In real room= s, anyone can go sit in the chair at the front of the room, and it's not= abused because of social convention.  I believe that we can map th= at to this virtual space and still have it work sensibly.  People w= on't take the chair unless there's a legitimate reason to do it, and so = long as it's logged - if someone does consistently abuse it we have proc= esses to eject them from the IETF for misbehaviour.

This ha= s become less important with the ability for individuals to turn on both= audio and video themselves, so the chair is going less busywork just ap= proving access, but it would be good to make it possible for someone els= e to step into the chair if the regular chairs are unable to attend or l= ose network, rather than making the meeting less able to run.
<= div style=3D"font-family:Arial;">
Bron.

On = Sat, Jul 31, 2021, at 05:38, Meetecho IETF support wrote:
All,

chiming in just to say that we at Meetecho appre= ciate and value your 
fe= edback. We'll definitely take it into account when developing the <= br>
future releases of the platfo= rm. We'll provide comments on the points 
raised as soon as we get the chance to parse them, i.e= ., when the 
meeting is = over.

Also, I'm cc'ing tools-discuss@ietf.org and setting the reply-to header&= nbsp;
to that list as well, a= s that's the right place to discuss enhancements 
and provide feedback that would be easier for = us to collect.

Best,
Alessandro

<= div style=3D"font-family:Arial;">Il 30/07/21 19:37, Spencer Dawkins at I= ETF ha scritto:
> I should= have changed the Subject a LONG time ago! But this thread has 
=
> morphed into helpful observ= ations and suggestions, so, if I might add a 
> couple of things ...

= > I agree that Meetecho has been improving (and just for fun, the Mee= techo 
> guys were pa= rticipants in the MEDIACTL session I was co-chairing in 
<= div style=3D"font-family:Arial;">> Hiroshima at IETF 76 in November 2= 009, and they roped in a team member 
> from Italy during the discussion using whatever the t= oolset was back 
> th= en, so many of you have no idea how MUCH they've improved =F0=9F=98= =80).

> I see that we've already mentioned d= etaching the chat window, and 
> usually I remember that we can detach the chat by Tuesday of= each IETF 
> meeting= week at the latest, which is almost certainly a result of not 
=
> having THAT much experience= with Meetecho during the four months between 
> meetings. Now that we can use Meetecho = for interim meetings, that will 
> help me remember more clearly, so good there, too.

> The one thing I've noticed this week is how diffi= cult it is to figure 
&g= t; out who is speaking if they aren't sending video, and there's a long&= nbsp;
> list of people in = the queue. The suggestion to move the speakers above 
> the queue would improve that, and so = would simply displaying the active 
> speaker names in the screen space where their video wou= ld have gone, if 
> t= he person had been sending video.One reason that matters, is that it's&n= bsp;
> helpful for everyon= e to get the speaker's name right in the minutes. 
> That's not just for new attendees, I'm s= tarting to forget what people 
> sound like, unless I'm talking to them regularly, or they ha= ve a very 
> distinct= ive speech pattern, so I've definitely depending on seeing names 
> when I'm taking minutes. = .

> The one thing I was thinking about, as I= read through this thread, was 
> that we are kinda *not *talking about what the IETF thinks = the target 
> audienc= e for our conferencing tool is.

>  = ; * For probably the last couple of IETFs, I have a GREAT setup for
<= /div>
>     remo= te participation (my laptop screen, plus two 25-inch monitors).
>     But I do= have tiled windows on all three screens.
>   * If we think people who can't throw a few= hundred dollars at monitor
&= gt;     screens are part of our target audience, tha= t's worth noting.
> &= nbsp; * If we think we're going to have hybrid meetings, in at least som= e
>    = ; scenarios, it's going to be good to use Meetecho in the conference
=
>     roo= ms (especially if we need to be distancing, so more spread out,
>     front to= back in the conference rooms).
>   * Even if we aren't doing hybrid meetings, I've part= icipated in some
> &n= bsp;   working group meetings from my hotel room, but I wasn't= tryng to
>  &nb= sp;  co-chair a meeting, or even to present at a meeting.
=
>   * When Michael Richar= dson and I talked to the Cellar working group
>     participants about switchi= ng to Meetecho for our (monthy) interims,
>     the first question we got was,= "is there an iOS/Adroid client?" I
>     haven't checked Meetecho on my phone= in years, but I'd bet offhand
>     that (1) it would work, but (2) it might = not be as easy to use as
>=      some other conferencing systems, on those devic= es. Do people have
> =     experience with that?

> I= 'll let you folks continue to share these positive observations and = ;
> proposals. Make Good C= hoices, of course.
> =
> Best,

> Spencer
>&nbs= p;
> On Thu, Jul 29, 2021 = at 6:15 PM Jay Daley <jay@ietf.org 

>     Thanks Bron.  Personally I= think that=E2=80=99s a great usability adjustment
>     and will forward to th= e Meetecho team for them to consider.

> = ;    Jay
>&= nbsp;
>   &= nbsp;  > On 30/07/2021, at 10:58 AM, Bron Gondwana <brong@fastmailteam.com
>     <mailto:brong@fastmailteam.com>&g= t; wrote:
>  &nb= sp;   >
>&nbs= p;     > On Fri, Jul 30, 2021, at 05:21, Jay Dale= y wrote:
>  &nbs= p;   >> No we have absolutely not pushed Meetecho into b= eing "just a
>  =    contractor", they are a valued partner and we work very wel= l
>    = ; together.  If you have any doubts about that then ask them direct= ly.
>   &nb= sp;  >>
> =      >> It is disappointing that you have esca= lated a personal concern
>=      that you have with our services into such a str= ong criticism when
> =     that is entirely unsupported by any evidence.
>      &= gt;
>   &nb= sp;  > Jay, I agree with your sentiment here - this attitude to = Meetecho
>  &nbs= p;  is counterproductive.  They've done great work for the las= t couple
>  &nbs= p;  of IETFs and the experience is improving each time.  I hav= e
>    = ; particularly appreciated the embedded slide management, and I'm sure
>     t= hat will be even better next time too.
>      >
>      > Regarding t= he specific interface issues that remain, I do think
>     there's a question = of "where do we propose improvements in a way
>     that will be noticed"?&nbs= p; I've seen the suggestion made very many
>     times that the "speaker" area= (where the video shows) should have
>     additional lines for each person se= nding anything, rather than that
>     information being at the top of the par= ticipant list.  This is much
>     more like the experience with other ch= at systems, for example Zoom
= >     shows either a photo or a blank item for so= mebody who isn't
> &n= bsp;   currently sending video, but they're otherwise treated = "the same" as
>  = ;   a person sending video in terms of real-estate and where t= o look for
>  &n= bsp;  their presence by default.
>      >
>      > Right now wi= th meetecho, my eyes are normally at the video are
>     when people are speaki= ng, but if a non-video person is speaking I
>     need to look across to the o= ther side of the screen to see the audio
>     indication.
>      >
>      &g= t; And as was also suggested in this thread, you can't scroll the
>     partic= ipant list to find someone to chat to, because they jump to
>     the top when= they are sending, then back to alphabetical position. 
>     This is als= o a usability pain.  Separating "the list of
>     participants" (which w= ouldn't move about) and "the list of people
>     sending something" with the = video and audio indications being
>     together in one place would be a signi= ficant improvement.  And as an
>     additional benefit, when you're look= ing at the chat window, you
&= gt;     would still be able to see all the details o= f who is sending
> &n= bsp;   (including yourself - if you're sending then the indica= tor of your
>  &= nbsp;  own audio should be the same as the indicator of everyone el= se's
>   &n= bsp; audio, rather than being in yet a third location up under your own<= br>
>     = name).
>   =    >
> &= nbsp;    > <image.png>
>      > So those two n= ames would appear in the right hand side, and also
>     still have their name = in the participant list, and the video feeds
>     would each have a "here's w= hat's being sent".  Chairs would always
>     have a presence on the righ= t, with whatever they were currently
>     sending - and the "participants" ta= b would only have the list of
>     participants, and not be a place you neede= d to go to see activity,
>=      so you could mostly keep the chat tab open.
=
>    &nbs= p; >
>   = ;   > Bron.
>=       >
>      >
>      > --
>      >&= nbsp;  Bron Gondwana, CEO, Fastmail Pty Ltd
>      > brong@fastmailteam.com <mailto= :brong@fastmailteam.com>= ;
>    = ;  >
>  =     >
>&= nbsp;     > --
>      > 111attendees mailing li= st
>   &nbs= p;  > 111attendees= @ietf.org <mailto:111att= endees@ietf.org>
>  = ;   <https://www.ietf.org/mailman/listinfo/111attendees>
<= /div>

>     -- 
>     Jay Daley
=
>     IET= F Executive Director
>&nbs= p;    jay@ietf.org <mailto:jay@ietf.org>

>     -- 
>     111attendees m= ailing list



=
-- 
111attendees mailing list


--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com


--6dbf78494a87456c8b6f6dbe44fec6f6-- From nobody Fri Jul 30 14:07:43 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E201A3A10BA for ; Fri, 30 Jul 2021 14:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.399 X-Spam-Level: X-Spam-Status: No, score=-4.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=f1Bj6yoX; dkim=pass (2048-bit key) header.d=taugh.com header.b=kDUpsRzV 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 KK7DTPwKpI3e for ; Fri, 30 Jul 2021 14:07:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812E83A10BC for ; Fri, 30 Jul 2021 14:07:36 -0700 (PDT) Received: (qmail 20871 invoked from network); 30 Jul 2021 21:07:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=5183.61046a16.k2107; bh=BQPCR5FOD1JIm8JqpnxZ+WuMUB9ytwMVKTmRlSzPeUA=; b=f1Bj6yoXLCJv5Z7WniusPsYzn58vUSbKXGqq5SiPzQ8JB84yoIcXGur3Z095usovRrqFTd8rlZ+5IPG2nEzYEope3okbNgYD51ALjgQGbmwPNtemtTsIx3tG9Ni4uXNy4IFfZrovoYhkjzSiPWzc28oZ1YiVco+e6CUStzw8qh54Ihg33QEMG2YFE3Wqp/Kx2VALoGiANQR/V6VQUlTLHVrUkVFfpISxcKYZiiy2v2TBqVU/nMe6PuauxAQrAh9lANilD9UkukWB60kf1Jeylrkdc88i/8fAaS6/asrsYcV+8wZ9gAV9ySx0Br6BX3tdLAmq9HvtP3lQqmbNBgmGFw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=5183.61046a16.k2107; bh=BQPCR5FOD1JIm8JqpnxZ+WuMUB9ytwMVKTmRlSzPeUA=; b=kDUpsRzVM7R2vutBjey7WTy7vJFJzMPfN4F5WDqmlQHl0nSlVgBNIWR0HquAghCXdoC1s5TV2IAhNookYBoppWR5DcUyt5Fp69rBdp8mgW8wHQEb9cfvUw4/Q1S6DoIilSytxD0hZI403TE364njZsc/SrXdxY3k38ftE/HHxK+t1y0/pJVWMpgaPh6zCDwjE9eFciFlYcM02ysmyL8cwFe2iUxCRxYJNP6d/YlzhlsI1hqB+/8rS8q9vdlBxneBYMbx0EdSep/EeJrG1JpxfnjrZ8inlZji4a/L7HSGwvBmtxvF64wBE42Nh+csXiO6tabRbVn8ErWa0rdXbbeXzQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 30 Jul 2021 21:07:34 -0000 Received: by ary.qy (Postfix, from userid 501) id 7F900255B688; Fri, 30 Jul 2021 17:07:33 -0400 (EDT) Date: 30 Jul 2021 17:07:33 -0400 Message-Id: <20210730210733.7F900255B688@ary.qy> From: "John Levine" To: tools-discuss@ietf.org Cc: julian.reschke@gmx.de In-Reply-To: <297b8f75-ce58-ee79-f147-a164748bf7ff@gmx.de> Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:07:42 -0000 It appears that Julian Reschke said: >Am 30.07.2021 um 13:35 schrieb John R Levine: >>> Clearly, Google Scholar should be taught to find the canonical RFCs at >>> https://rfc-editor.org/rfc - having many secondary copies is an SEO >>> anathema. >> >> Right.  I hope some sitemaps will help. >> ... > >That would be surprising, but would be good to know. > >That said, as acting RFC Editor, why don't you just ask them? Ask who, Google? Hahahahahahaha. Scholar like everything else at Google other than ad sales is completely automated. R's, John From nobody Fri Jul 30 14:14:43 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAA53A111A for ; Fri, 30 Jul 2021 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udKyZR1ZUbY9 for ; Fri, 30 Jul 2021 14:14:35 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 47FF83A110C for ; Fri, 30 Jul 2021 14:14:35 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id f8so7500754ilr.4 for ; Fri, 30 Jul 2021 14:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pFYX+JoJ88RObfnR+8qtH7zQARDW+xE6Sj4jKym8kp8=; b=nQ9JcwSJwt3BmxWT/erahPdh7ABEaSbxCmhGR/z+smA9bMnFxcVQSy6TUBE3bch2F9 tadHhkZc+jeVLbkaCA95UIJ9XowStWKEMf6+MlV4TWoW/pWdAfcELe6yCKXlhfDJtIcN o5VZaQuLtRaf81MkbUBCOgJ2SbJ+coNc6fTtw36H4M6kggAz8vs5PNT9IfvPaRpzGVgH ISBd54QBDEAp+Ff06/ooCl5ovJKoKMmG/rDTqZI02HZyA/KvlwjyYLaxjmeJyRWSTPT3 hTNGMcnKhhUYN8PyiFwJTj0Pga81qaLG5CTUMn4BVruwxY/lPTC78MXJAo+zKo7u23mJ iSwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pFYX+JoJ88RObfnR+8qtH7zQARDW+xE6Sj4jKym8kp8=; b=hY+vfpt8YGA/uzFU9qzyhBGWme0PunfOg6Eo0pzlBuDyPUB94s5ZXQHDY1TUcrY0bp QtLmW+NegZ/BkqKhTTaPMKS9437vrEDOd+kOGqbFUhoMNS/WfG/NHPhxo1qrAsvW4Ag4 FpxenjiCU0H78hitqx/aIvEsRhBMK2Qj7EVslBRpf6WhjlFeVq1huwsCqEEdl/52N0td 38IgwSZACYtU+qoenrQ+3IjU1B8FWjwCAOEvYPknQFYEs/yDTFF6k02GuKBp9+CVsBct r4hc2T0dWMK+QgIs0A/tqsjr5w/odp9CrKeQ6kPSzuvDu8spGM8Q1W5rjNaugdtf5+/s +BpQ== X-Gm-Message-State: AOAM5338Pr4z+lowhc+aOL1tdksHRIFxl+lKogjgodnaW56uVTRRgcDo 6T8PYhkn8anoLwZ+wjkkSxOFDuxsMmnKqm4I9lI4Wg== X-Google-Smtp-Source: ABdhPJy4jGB91SWoGYdE6ryhQuc3Yn6MsMef/aOU8CS+lSx+RhrAJ3jVLF/KKPYhupqn72U+QlYucdEGkyERBHbWpCM= X-Received: by 2002:a05:6e02:13d3:: with SMTP id v19mr2437105ilj.167.1627679672872; Fri, 30 Jul 2021 14:14:32 -0700 (PDT) MIME-Version: 1.0 References: <4268651f-6bd7-10ce-6ed8-a758bd956062@meetecho.com> <99ae28be-dd15-4018-bccc-a1f61ce19e47@dogfood.fastmail.com> In-Reply-To: <99ae28be-dd15-4018-bccc-a1f61ce19e47@dogfood.fastmail.com> From: Eric Rescorla Date: Fri, 30 Jul 2021 14:13:56 -0700 Message-ID: To: Bron Gondwana Cc: 111attendees@ietf.org, tools-discuss Content-Type: multipart/alternative; boundary="000000000000b5c5db05c85db4a9" Archived-At: Subject: Re: [Tools-discuss] [111attendees] Positive observations and proposals for improvements to Meetecho (was: Re: Re: So, what are jabber scribes actually doing, these days?) X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:14:41 -0000 --000000000000b5c5db05c85db4a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 30, 2021 at 2:03 PM Bron Gondwana wrote: > Ooh, we're going a full "suggestions for meetecho" thread? I'd like to > propose some things! > > *that we replace the current "raise hands" tool:* > > *... *which is based on an expired draft which isn't going to be > refreshed - with a better tool that allows the chairs to: > > a) label each option > b) have more than 2 options (max 9 maybe) > c) select between "choose one" and "choose N" modes (checkbox vs radio > button) > > ... and which appears IN PLACE of the slides when enabled, so that meetin= g > participants don't have to navigate to a separate tab to interact. > > More generally, it's too easy for some participants to be lost on > different tabs where they can't see the slides. The multiple views where > you can see individual talking heads in more detail are not actually > valuable I don't think - if slides are showing they should be the bulk of > the screen because they need to be read - and if a poll is showing then f= or > sure it should be taking over the screen. > EKR Raises Hand. *a "temporary mute" mode that keeps the audio stream open:* > > This is still an issue for me. I often mute myself while chairing so I > can take notes without my keyboard sound interrupting the chat - but it > means that I can't easily respond to somebody because the rejigging of th= e > audio channel not only creates a hiccup in the incoming audio feed which > means I might miss something someone says, but it also creates enough of = a > delay that by the time I could have responded the other party's mental > state has moved on. > > Timing is really important in conversation and we're already fighting wit= h > the quarter second delay imposed by the size of the planet. Additional > delay makes it unwieldy. > Note that this is a respect in which Meetecho is unusual. Most other VC systems which I am familiar with just stop sending on the track but keep the microphone open rather than dropping the media stream and re-calling getUserMedia(). To your list, I would add auto-unmuting (and even more importantly, muting) when people enter and exit the head of the queue. This would remove a lot of goofy behavior. -Ekr *allow multiple connections by the same person to the same session:* > > I have multiple times wanted to switch device temporarily - from my > desktop computer to a phone / ipad so I can temporarily move to another > location while continuing to follow a meeting. Multiple connection suppo= rt > would mean I could switch over without a break. > > Sure it could be abused by people "sharing" a login, but that would be > pretty obvious if both parties tried to participate, and given that we > allow fee waivers anyway, it's unlikely to be abused significantly. Sure > there are Jabber naming issues, but we can avoid that by giving each jabb= er > name with a serial number (which I believe already happens now?) > > ... > > I've already written these up separately in the past, but: > > *information about who is speaking in the same place as video feeds* > > See my previous email :) Basically the "participant list" should just be > an ordered list of participants and only needs to be switched to when > seeing who is in the call or opening an individual message to them (and > people don't get moved out of order when they're sending something). The > "who is sending something" list should be all together with the video, an= d > chairs pinned even if they're sending nothing right now. > > Along with visual indicators of "currently sending audio" on people so we > know who of those with their audio channel open are currently speaking, > this makes it easier to look in one place to see the source of all sound, > and eyes can generally flit between the right hand side (video and audio > indicators) and the slides, without needing to also track via the > participant list. > > *flexible "assign chair"**:* > > This one hasn't come up in practice, but the chairs for meetings are > pre-assigned from datatracker. It would be great for ADs and the meetech= o > reps in each meeting to be able to upgrade anybody to a chair role or > remove a chair role with a simple click. > > In real rooms, anyone can go sit in the chair at the front of the room, > and it's not abused because of social convention. I believe that we can > map that to this virtual space and still have it work sensibly. People > won't take the chair unless there's a legitimate reason to do it, and so > long as it's logged - if someone does consistently abuse it we have > processes to eject them from the IETF for misbehaviour. > > This has become less important with the ability for individuals to turn o= n > both audio and video themselves, so the chair is going less busywork just > approving access, but it would be good to make it possible for someone el= se > to step into the chair if the regular chairs are unable to attend or lose > network, rather than making the meeting less able to run. > > Bron. > > On Sat, Jul 31, 2021, at 05:38, Meetecho IETF support wrote: > > All, > > chiming in just to say that we at Meetecho appreciate and value your > feedback. We'll definitely take it into account when developing the > future releases of the platform. We'll provide comments on the points > raised as soon as we get the chance to parse them, i.e., when the > meeting is over. > > Also, I'm cc'ing tools-discuss@ietf.org and setting the reply-to header > to that list as well, as that's the right place to discuss enhancements > and provide feedback that would be easier for us to collect. > > Best, > Alessandro > > Il 30/07/21 19:37, Spencer Dawkins at IETF ha scritto: > > I should have changed the Subject a LONG time ago! But this thread has > > morphed into helpful observations and suggestions, so, if I might add a > > couple of things ... > > > > I agree that Meetecho has been improving (and just for fun, the Meetech= o > > guys were participants in the MEDIACTL session I was co-chairing in > > Hiroshima at IETF 76 in November 2009, and they roped in a team member > > from Italy during the discussion using whatever the toolset was back > > then, so many of you have no idea how MUCH they've improved =F0=9F=98= =80). > > > > I see that we've already mentioned detaching the chat window, and > > usually I remember that we can detach the chat by Tuesday of each IETF > > meeting week at the latest, which is almost certainly a result of not > > having THAT much experience with Meetecho during the four months betwee= n > > meetings. Now that we can use Meetecho for interim meetings, that will > > help me remember more clearly, so good there, too. > > > > The one thing I've noticed this week is how difficult it is to figure > > out who is speaking if they aren't sending video, and there's a long > > list of people in the queue. The suggestion to move the speakers above > > the queue would improve that, and so would simply displaying the active > > speaker names in the screen space where their video would have gone, if > > the person had been sending video.One reason that matters, is that it's > > helpful for everyone to get the speaker's name right in the minutes. > > That's not just for new attendees, I'm starting to forget what people > > sound like, unless I'm talking to them regularly, or they have a very > > distinctive speech pattern, so I've definitely depending on seeing name= s > > when I'm taking minutes. . > > > > The one thing I was thinking about, as I read through this thread, was > > that we are kinda *not *talking about what the IETF thinks the target > > audience for our conferencing tool is. > > > > * For probably the last couple of IETFs, I have a GREAT setup for > > remote participation (my laptop screen, plus two 25-inch monitors). > > But I do have tiled windows on all three screens. > > * If we think people who can't throw a few hundred dollars at monitor > > screens are part of our target audience, that's worth noting. > > * If we think we're going to have hybrid meetings, in at least some > > scenarios, it's going to be good to use Meetecho in the conference > > rooms (especially if we need to be distancing, so more spread out, > > front to back in the conference rooms). > > * Even if we aren't doing hybrid meetings, I've participated in some > > working group meetings from my hotel room, but I wasn't tryng to > > co-chair a meeting, or even to present at a meeting. > > * When Michael Richardson and I talked to the Cellar working group > > participants about switching to Meetecho for our (monthy) interims, > > the first question we got was, "is there an iOS/Adroid client?" I > > haven't checked Meetecho on my phone in years, but I'd bet offhand > > that (1) it would work, but (2) it might not be as easy to use as > > some other conferencing systems, on those devices. Do people have > > experience with that? > > > > I'll let you folks continue to share these positive observations and > > proposals. Make Good Choices, of course. > > > > Best, > > > > Spencer > > > > On Thu, Jul 29, 2021 at 6:15 PM Jay Daley > > wrote: > > > > Thanks Bron. Personally I think that=E2=80=99s a great usability a= djustment > > and will forward to the Meetecho team for them to consider. > > > > Jay > > > > > On 30/07/2021, at 10:58 AM, Bron Gondwana > > wrote: > > > > > > On Fri, Jul 30, 2021, at 05:21, Jay Daley wrote: > > >> No we have absolutely not pushed Meetecho into being "just a > > contractor", they are a valued partner and we work very well > > together. If you have any doubts about that then ask them directly= . > > >> > > >> It is disappointing that you have escalated a personal concern > > that you have with our services into such a strong criticism when > > that is entirely unsupported by any evidence. > > > > > > Jay, I agree with your sentiment here - this attitude to Meetech= o > > is counterproductive. They've done great work for the last couple > > of IETFs and the experience is improving each time. I have > > particularly appreciated the embedded slide management, and I'm sur= e > > that will be even better next time too. > > > > > > Regarding the specific interface issues that remain, I do think > > there's a question of "where do we propose improvements in a way > > that will be noticed"? I've seen the suggestion made very many > > times that the "speaker" area (where the video shows) should have > > additional lines for each person sending anything, rather than that > > information being at the top of the participant list. This is much > > more like the experience with other chat systems, for example Zoom > > shows either a photo or a blank item for somebody who isn't > > currently sending video, but they're otherwise treated "the same" a= s > > a person sending video in terms of real-estate and where to look fo= r > > their presence by default. > > > > > > Right now with meetecho, my eyes are normally at the video are > > when people are speaking, but if a non-video person is speaking I > > need to look across to the other side of the screen to see the audi= o > > indication. > > > > > > And as was also suggested in this thread, you can't scroll the > > participant list to find someone to chat to, because they jump to > > the top when they are sending, then back to alphabetical position. > > This is also a usability pain. Separating "the list of > > participants" (which wouldn't move about) and "the list of people > > sending something" with the video and audio indications being > > together in one place would be a significant improvement. And as a= n > > additional benefit, when you're looking at the chat window, you > > would still be able to see all the details of who is sending > > (including yourself - if you're sending then the indicator of your > > own audio should be the same as the indicator of everyone else's > > audio, rather than being in yet a third location up under your own > > name). > > > > > > > > > So those two names would appear in the right hand side, and also > > still have their name in the participant list, and the video feeds > > would each have a "here's what's being sent". Chairs would always > > have a presence on the right, with whatever they were currently > > sending - and the "participants" tab would only have the list of > > participants, and not be a place you needed to go to see activity, > > so you could mostly keep the chat tab open. > > > > > > Bron. > > > > > > > > > -- > > > Bron Gondwana, CEO, Fastmail Pty Ltd > > > brong@fastmailteam.com > > > > > > > > > -- > > > 111attendees mailing list > > > 111attendees@ietf.org > > > https://www.ietf.org/mailman/listinfo/111attendees > > > > > > -- > > Jay Daley > > IETF Executive Director > > jay@ietf.org > > > > -- > > 111attendees mailing list > > 111attendees@ietf.org > > https://www.ietf.org/mailman/listinfo/111attendees > > > > > > > > -- > 111attendees mailing list > 111attendees@ietf.org > https://www.ietf.org/mailman/listinfo/111attendees > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.or= g > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): > https://www.ietf.org/mailman/listinfo/tools-discuss > --000000000000b5c5db05c85db4a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jul 30, 2021 at 2:03 PM Bron = Gondwana <brong@fastmailteam.c= om> wrote:
Ooh, we're going a full "s= uggestions for meetecho" thread?=C2=A0 I'd like to propose some th= ings!

that we replace the current "raise hands" tool= :

... which is based on an expired draft which isn'= ;t going to be refreshed - with a better tool that allows the chairs to:

a) label each option
b) h= ave more than 2 options (max 9 maybe)
c) select between "choose one" and "choose N" mode= s (checkbox vs radio button)

=
... and which appears IN PLACE of th= e slides when enabled, so that meeting participants don't have to navig= ate to a separate tab to interact.=C2=A0

More generally, it's= too easy for some participants to be lost on different tabs where they can= 't see the slides.=C2=A0 The multiple views where you can see individua= l talking heads in more detail are not actually valuable I don't think = - if slides are showing they should be the bulk of the screen because they = need to be read - and if a poll is showing then for sure it should be takin= g over the screen.

EKR Rais= es Hand.


a "tempor= ary mute" mode that keeps the audio stream open:

This is= still an issue for me.=C2=A0 I often mute myself while chairing so I can t= ake notes without my keyboard sound interrupting the chat - but it means th= at I can't easily respond to somebody because the rejigging of the audi= o channel not only creates a hiccup in the incoming audio feed which means = I might miss something someone says, but it also creates enough of a delay = that by the time I could have responded the other party's mental state = has moved on.

Timing is really important in conversation and we&#= 39;re already fighting with the quarter second delay imposed by the size of= the planet.=C2=A0 Additional delay makes it unwieldy.

Note that this is a respect in which Meetecho is unusual. Most other VC = systems which I am familiar with just stop sending on the track but keep th= e microphone open rather than dropping the media stream and re-calling getU= serMedia().

To your list, I would add auto-unmuting (and even more importantly, m= uting) when people enter and exit the head of the queue. This would remove = a lot of goofy behavior.

-Ekr



<= div>
allow multiple connections by the same person= to the same session:

I have multiple times wanted to switch = device temporarily - from my desktop computer to a phone / ipad so I can te= mporarily move to another location while continuing to follow a meeting.=C2= =A0 Multiple connection support would mean I could switch over without a br= eak.

Sure it could be abused by people "sharing" a logi= n, but that would be pretty obvious if both parties tried to participate, a= nd given that we allow fee waivers anyway, it's unlikely to be abused s= ignificantly.=C2=A0 Sure there are Jabber naming issues, but we can avoid t= hat by giving each jabber name with a serial number (which I believe alread= y happens now?)

...
I've already written these up s= eparately in the past, but:

<= /div>
information about who is speaking = in the same place as video feeds

See my previous email :)=C2= =A0 Basically the "participant list" should just be an ordered li= st of participants and only needs to be switched to when seeing who is in t= he call or opening an individual message to them (and people don't get = moved out of order when they're sending something).=C2=A0 The "who= is sending something" list should be all together with the video, and= chairs pinned even if they're sending nothing right now.

Alo= ng with visual indicators of "currently sending audio" on people = so we know who of those with their audio channel open are currently speakin= g, this makes it easier to look in one place to see the source of all sound= , and eyes can generally flit between the right hand side (video and audio = indicators) and the slides, without needing to also track via the participa= nt list.

flexible "assign chair":

This one hasn't come up in practice, but the chairs for meetings are= pre-assigned from datatracker.=C2=A0 It would be great for ADs and the mee= techo reps in each meeting to be able to upgrade anybody to a chair role or= remove a chair role with a simple click.

In real rooms, anyone c= an go sit in the chair at the front of the room, and it's not abused be= cause of social convention.=C2=A0 I believe that we can map that to this vi= rtual space and still have it work sensibly.=C2=A0 People won't take th= e chair unless there's a legitimate reason to do it, and so long as it&= #39;s logged - if someone does consistently abuse it we have processes to e= ject them from the IETF for misbehaviour.

This has become less im= portant with the ability for individuals to turn on both audio and video th= emselves, so the chair is going less busywork just approving access, but it= would be good to make it possible for someone else to step into the chair = if the regular chairs are unable to attend or lose network, rather than mak= ing the meeting less able to run.

Bron.

On Sat, Jul 31, 2021, at 05:38, Meetecho IE= TF support wrote:
All,

chiming in j= ust to say that we at Meetecho appreciate and value your=C2=A0
feedback. We'll definitely take it into a= ccount when developing the=C2=A0
= future releases of the platform. We'll provide comments on the points= =C2=A0
raised as soon as we get t= he chance to parse them, i.e., when the=C2=A0
meeting is over.
Also, I'm cc'ing=C2=A0tools-discuss@ietf.o= rg and setting the reply-to header=C2=A0
to that list as well, as that's the right place to discuss = enhancements=C2=A0
and provide fe= edback that would be easier for us to collect.

Best,
Alessandro

Il 30/07/21 19:37, Spenc= er Dawkins at IETF ha scritto:
&g= t; I should have changed the Subject a LONG time ago! But this thread has= =C2=A0
> morphed into helpful = observations and suggestions, so, if I might add a=C2=A0
> couple of things ...
>=C2=A0
> = I agree that Meetecho has been improving (and just for fun, the Meetecho=C2= =A0
> guys were participants i= n the MEDIACTL session I was co-chairing in=C2=A0
> Hiroshima at IETF 76 in November 2009, and they roped= in a team member=C2=A0
> from= Italy during the discussion using whatever the toolset was back=C2=A0
<= /div>
> then, so many of you have no ide= a how MUCH they've improved=C2=A0=F0=9F=98=80).
>=C2=A0
>= ; I see that we've already mentioned detaching the chat window, and=C2= =A0
> usually I remember that = we can detach the chat by Tuesday of each IETF=C2=A0
> meeting week at the latest, which is almost certai= nly a result of not=C2=A0
> ha= ving THAT much experience with=C2=A0Meetecho during the four months between= =C2=A0
> meetings. Now that we= can use Meetecho for interim meetings, that will=C2=A0
> help me remember more clearly, so good there, t= oo.
>=C2=A0
> The one thing I've noticed this week is ho= w difficult it is to figure=C2=A0
> out who is speaking if they aren't sending video, and there's= a long=C2=A0
> list of people= in the queue. The suggestion to move the speakers above=C2=A0
> the queue would improve that, and so wou= ld simply displaying the active=C2=A0
> speaker names in the screen space where their video would have go= ne, if=C2=A0
> the person had = been sending video.One reason that matters, is that it's=C2=A0
> helpful for everyone to get the spea= ker's name right in the minutes.=C2=A0
> That's not just for new attendees, I'm starting to f= orget what people=C2=A0
> soun= d like, unless I'm talking to them regularly, or they have a very=C2=A0=
> distinctive speech pattern,= so I've definitely depending on seeing names=C2=A0
> when I'm taking minutes. .
>=C2=A0
> The one thing I was thinking about, as I read through this thread,= was=C2=A0
> that we are kinda= *not *talking about what the IETF thinks the target=C2=A0
> audience for our conferencing tool is.
>=C2=A0
>=C2=A0=C2=A0 * For probably the last couple of IETFs, I = have a GREAT setup for
>=C2=A0= =C2=A0=C2=A0=C2=A0 remote participation (my laptop screen, plus two 25-inch= monitors).
>=C2=A0=C2=A0=C2= =A0=C2=A0 But I do have tiled windows on all three screens.
>=C2=A0=C2=A0 * If we think people who can= 9;t throw a few hundred dollars at monitor
>=C2=A0=C2=A0=C2=A0=C2=A0 screens are part of our target audie= nce, that's worth noting.
>= ;=C2=A0=C2=A0 * If we think we're going to have hybrid meetings, in at = least some
>=C2=A0=C2=A0=C2=A0= =C2=A0 scenarios, it's going to be good to use Meetecho in the conferen= ce
>=C2=A0=C2=A0=C2=A0=C2=A0 r= ooms (especially if we need to be distancing, so more spread out,
=
>=C2=A0=C2=A0=C2=A0=C2=A0 front to back= in the conference rooms).
>= =C2=A0=C2=A0 * Even if we aren't doing hybrid meetings, I've partic= ipated in some
>=C2=A0=C2=A0= =C2=A0=C2=A0 working group meetings from my hotel room, but I wasn't tr= yng to
>=C2=A0=C2=A0=C2=A0=C2= =A0 co-chair a meeting, or even to present at a meeting.
>=C2=A0=C2=A0 * When Michael Richardson and I ta= lked to the Cellar working group
= >=C2=A0=C2=A0=C2=A0=C2=A0 participants about switching to Meetecho for o= ur (monthy) interims,
>=C2=A0= =C2=A0=C2=A0=C2=A0 the first question we got was, "is there an iOS/Adr= oid client?" I
>=C2=A0=C2= =A0=C2=A0=C2=A0 haven't checked Meetecho on my phone in years, but I= 9;d bet offhand
>=C2=A0=C2=A0= =C2=A0=C2=A0 that (1) it would work, but (2) it might not be as easy to use= as
>=C2=A0=C2=A0=C2=A0=C2=A0 = some other conferencing systems, on those devices. Do people have
=
>=C2=A0=C2=A0=C2=A0=C2=A0 experience wi= th that?
>=C2=A0
> I'll let you folks continue to share = these positive observations and=C2=A0
> proposals. Make Good Choices, of course.
>=C2=A0
>= Best,
>=C2=A0
> Spencer
>=C2=A0
> On Thu, Ju= l 29, 2021 at 6:15 PM Jay Daley <jay@ietf.org=C2=A0
> <mailto:jay@iet= f.org>> wrote:
>=C2= =A0
>=C2=A0=C2=A0=C2=A0=C2=A0 = Thanks Bron.=C2=A0 Personally I think that=E2=80=99s a great usability adju= stment
>=C2=A0=C2=A0=C2=A0=C2= =A0 and will forward to the Meetecho team for them to consider.
>=C2=A0
>=C2=A0=C2=A0=C2=A0=C2=A0 Jay
>=C2=A0
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 > On 30/07/2021, at 10:58 AM, Bron Gondwana <brong@fastmailtea= m.com
>=C2=A0=C2=A0=C2=A0= =C2=A0 <mailto:brong@fastmailteam.com>> wrote:
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > On Fri, Jul 30, = 2021, at 05:21, Jay Daley wrote:
= >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> No we have absolutely not pushe= d Meetecho into being "just a
>=C2=A0=C2=A0=C2=A0=C2=A0 contractor", they are a valued partner = and we work very well
>=C2=A0= =C2=A0=C2=A0=C2=A0 together.=C2=A0 If you have any doubts about that then a= sk them directly.
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 >>
&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >> It is disappointing that you have= escalated a personal concern
>= ;=C2=A0=C2=A0=C2=A0=C2=A0 that you have with our services into such a stron= g criticism when
>=C2=A0=C2=A0= =C2=A0=C2=A0 that is entirely unsupported by any evidence.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
=
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Ja= y, I agree with your sentiment here - this attitude to Meetecho
>=C2=A0=C2=A0=C2=A0=C2=A0 is counterprodu= ctive.=C2=A0 They've done great work for the last couple
>=C2=A0=C2=A0=C2=A0=C2=A0 of IETFs and the e= xperience is improving each time.=C2=A0 I have
>=C2=A0=C2=A0=C2=A0=C2=A0 particularly appreciated the emb= edded slide management, and I'm sure
>=C2=A0=C2=A0=C2=A0=C2=A0 that will be even better next time too= .
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > Regarding the specific interface issues that remain, I do= think
>=C2=A0=C2=A0=C2=A0=C2= =A0 there's a question of "where do we propose improvements in a w= ay
>=C2=A0=C2=A0=C2=A0=C2=A0 t= hat will be noticed"?=C2=A0 I've seen the suggestion made very man= y
>=C2=A0=C2=A0=C2=A0=C2=A0 ti= mes that the "speaker" area (where the video shows) should have
>=C2=A0=C2=A0=C2=A0=C2=A0 addit= ional lines for each person sending anything, rather than that
>=C2=A0=C2=A0=C2=A0=C2=A0 information bein= g at the top of the participant list.=C2=A0 This is much
>=C2=A0=C2=A0=C2=A0=C2=A0 more like the experien= ce with other chat systems, for example Zoom
>=C2=A0=C2=A0=C2=A0=C2=A0 shows either a photo or a blank it= em for somebody who isn't
>= ;=C2=A0=C2=A0=C2=A0=C2=A0 currently sending video, but they're otherwis= e treated "the same" as
>=C2=A0=C2=A0=C2=A0=C2=A0 a person sending video in terms of real-estat= e and where to look for
>=C2= =A0=C2=A0=C2=A0=C2=A0 their presence by default.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > Right now wi= th meetecho, my eyes are normally at the video are
>=C2=A0=C2=A0=C2=A0=C2=A0 when people are speaking, bu= t if a non-video person is speaking I
>=C2=A0=C2=A0=C2=A0=C2=A0 need to look across to the other side of = the screen to see the audio
>= =C2=A0=C2=A0=C2=A0=C2=A0 indication.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > And as was also suggeste= d in this thread, you can't scroll the
>=C2=A0=C2=A0=C2=A0=C2=A0 participant list to find someone to = chat to, because they jump to
>= ;=C2=A0=C2=A0=C2=A0=C2=A0 the top when they are sending, then back to alpha= betical position.=C2=A0
>=C2= =A0=C2=A0=C2=A0=C2=A0 This is also a usability pain.=C2=A0 Separating "= ;the list of
>=C2=A0=C2=A0=C2= =A0=C2=A0 participants" (which wouldn't move about) and "the = list of people
>=C2=A0=C2=A0= =C2=A0=C2=A0 sending something" with the video and audio indications b= eing
>=C2=A0=C2=A0=C2=A0=C2=A0= together in one place would be a significant improvement.=C2=A0 And as an<= br>
>=C2=A0=C2=A0=C2=A0=C2=A0 addi= tional benefit, when you're looking at the chat window, you
>=C2=A0=C2=A0=C2=A0=C2=A0 would still be = able to see all the details of who is sending
>=C2=A0=C2=A0=C2=A0=C2=A0 (including yourself - if you'= re sending then the indicator of your
>=C2=A0=C2=A0=C2=A0=C2=A0 own audio should be the same as the indic= ator of everyone else's
>= =C2=A0=C2=A0=C2=A0=C2=A0 audio, rather than being in yet a third location u= p under your own
>=C2=A0=C2=A0= =C2=A0=C2=A0 name).
>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 >
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > <image.png>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 > So those two= names would appear in the right hand side, and also
>=C2=A0=C2=A0=C2=A0=C2=A0 still have their name in t= he participant list, and the video feeds
>=C2=A0=C2=A0=C2=A0=C2=A0 would each have a "here's wha= t's being sent".=C2=A0 Chairs would always
>=C2=A0=C2=A0=C2=A0=C2=A0 have a presence on the righ= t, with whatever they were currently
>=C2=A0=C2=A0=C2=A0=C2=A0 sending - and the "participants"= tab would only have the list of
= >=C2=A0=C2=A0=C2=A0=C2=A0 participants, and not be a place you needed to= go to see activity,
>=C2=A0= =C2=A0=C2=A0=C2=A0 so you could mostly keep the chat tab open.
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >= ; Bron.
>=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 >
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 >
>=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 > --
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0Bron Gondwana, CEO, = Fastmail Pty Ltd
>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 >=C2=A0brong@fastmailteam.com <mailto:brong@fastmailteam.com>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ><= br>
>=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 >
>=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 > --
>=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 > 111attendees mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0111attendees@ietf.org <mailto:11= 1attendees@ietf.org>
>= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0https://www.ietf.org/mailman= /listinfo/111attendees
>=C2=A0
=
>=C2=A0=C2=A0=C2=A0=C2=A0 --=C2= =A0
>=C2=A0=C2=A0=C2=A0=C2=A0 = Jay Daley
>=C2=A0=C2=A0=C2=A0= =C2=A0 IETF Executive Director
&g= t;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0jay@ietf.org <mailto:jay@ietf.org>
= >=C2=A0
>=C2=A0=C2=A0=C2=A0= =C2=A0 --=C2=A0
>=C2=A0=C2=A0= =C2=A0=C2=A0 111attendees mailing list
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0111attendees@ietf.org <mailto:111attendees@ietf.org><= br>
>=C2=A0=C2=A0=C2=A0=C2=A0 <https= ://www.ietf.org/mailman/listinfo/111attendees>
>=C2=A0
>=C2=A0

--=C2=A0
1= 11attendees mailing list

--
=C2=A0 Bron G= ondwana, CEO, Fastmail Pty Ltd


_______= ____________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for discussion, not for action requests or bug reports.
* Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other bugs or issues to: ietf-action@ietf.org
List info (including how to Unsubscribe): https:/= /www.ietf.org/mailman/listinfo/tools-discuss
--000000000000b5c5db05c85db4a9-- From nobody Fri Jul 30 14:38:56 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8343A3A125C for ; Fri, 30 Jul 2021 14:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.097 X-Spam-Level: X-Spam-Status: No, score=-18.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id No7795feJAlv for ; Fri, 30 Jul 2021 14:38:37 -0700 (PDT) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 6A0333A1221 for ; Fri, 30 Jul 2021 14:38:37 -0700 (PDT) Received: by mail-yb1-xb35.google.com with SMTP id d73so18183003ybc.10 for ; Fri, 30 Jul 2021 14:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DoYmqjM15YpNDVEfAvOz02CNPSdTHJsq5ATO5NEJ38g=; b=q++cuMGvaUeZV//OzovbHGrm1F4KoW8sy3bWgwqySb0djFaDtSLhH5tSeF6hOY1UFV hs6elCd79MXxNLfcCgmQLYW0x+XPgzG38zaTS9lIv6wiF6mg8/sYMLhNalEr5WKOsA8J echG+3joJ44lUEhiM2Uv7eKEgAKGnypjJfsI7XGT6B4Xr3lm4CsYxekd9pyUEWOPHiRC Dc1UD8IR4B19HStWPoJvQWxMn/b/YgkjaKXm0bb8KCGDRuJzE6bq4TQIZNddJpgYs2th /3mrxC0+h7E2mkCeJv0HN7vwKauVDNtz1LGGKDwigCLfHnoyhro7y82wVZjc9a6d6+Vg twog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DoYmqjM15YpNDVEfAvOz02CNPSdTHJsq5ATO5NEJ38g=; b=bDt5cj5ICIqxSOeSiM2By7+08IhWmo/oPmitUGYXQkD49Fn/G96OUQiR2SSATHOp5J cZflKvcv6f+meSZJZouOJtJqetJRK+5753le0WOU+HTJ0LxYk3s0j2NFq04KlTvCbdfQ uHAQqi7Z6wdnet1Yx6th2B1P1Jc2hY8yuCEKF9nBM5MUVwt1Q5NYOewueQWhoOVIdNxb NNGcEfIf7AqKoaq6i8c5qnWEkbUrbGB4sCuM0kufg2O/HTpWCzVB+QhDtb/rN/IIucH4 WqBJXNUFmjqdcqXFwCqrosBxxEcurBGYxWEBTjrux2+XIu6GppOtKl5o2CTdhfhPNbgb ynuA== X-Gm-Message-State: AOAM531iJaCAjyiGl5aRAhsTOdorf2IjZp0uM3lbltw50CW5hwje6On9 xGboTAtQu6dgaFTfwiizwmxyJcpBPUzzRwynIBMcaQ== X-Google-Smtp-Source: ABdhPJyHOlIEnpw0Hfrh563SR9fwpwr2fponruMlVnEoFfiOWgovnqAYw58Lmqx+2DJvPjMZsjoCAOSZYeAUyQGDc50= X-Received: by 2002:a25:cece:: with SMTP id x197mr5750177ybe.402.1627681115580; Fri, 30 Jul 2021 14:38:35 -0700 (PDT) MIME-Version: 1.0 References: <297b8f75-ce58-ee79-f147-a164748bf7ff@gmx.de> <20210730210733.7F900255B688@ary.qy> In-Reply-To: <20210730210733.7F900255B688@ary.qy> From: Jeffrey Yasskin Date: Fri, 30 Jul 2021 14:38:23 -0700 Message-ID: To: John Levine Cc: Tools Discussion , Julian Reschke Content-Type: multipart/alternative; boundary="000000000000b4360105c85e0a4a" Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 21:38:46 -0000 --000000000000b4360105c85e0a4a Content-Type: text/plain; charset="UTF-8" I started writing an email to someone who appears to be the right internal contact, but I had to stop because this thread and the thread around https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/ don't have enough information to constitute a bug report. What have the rfc-editor.org maintainers done to attempt to fix this? Has anyone followed the steps Harald pointed to at https://scholar.google.com/intl/en/scholar/inclusion.html#troubleshooting? If the RFC series maintainers haven't even tried the documented troubleshooting steps, there's no point escalating. Jeffrey On Fri, Jul 30, 2021 at 2:07 PM John Levine wrote: > It appears that Julian Reschke said: > >Am 30.07.2021 um 13:35 schrieb John R Levine: > >>> Clearly, Google Scholar should be taught to find the canonical RFCs at > >>> https://rfc-editor.org/rfc - having many secondary copies is an SEO > >>> anathema. > >> > >> Right. I hope some sitemaps will help. > >> ... > > > >That would be surprising, but would be good to know. > > > >That said, as acting RFC Editor, why don't you just ask them? > > Ask who, Google? Hahahahahahaha. Scholar like everything else at Google > other > than ad sales is completely automated. > > R's, > John > > ___________________________________________________________ > Tools-discuss mailing list - Tools-discuss@ietf.org > This list is for discussion, not for action requests or bug reports. > * Report datatracker and mailarchive bugs to: datatracker-project@ietf.org > * Report tools.ietf.org bugs to: webmaster@tools.ietf.org > * Report all other bugs or issues to: ietf-action@ietf.org > List info (including how to Unsubscribe): > https://www.ietf.org/mailman/listinfo/tools-discuss > --000000000000b4360105c85e0a4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I started writing an email to someone who appears to = be the right internal contact, but I had to stop because this thread and th= e thread around https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22= bhd99buZz9lE-kFcrFGI/ don't have enough information to constitute a= bug report. What have the rfc-editor.org= maintainers done to attempt to fix this? Has anyone followed the steps= Harald pointed to at=C2=A0https://scholar.google.com/intl/en/sc= holar/inclusion.html#troubleshooting? If the RFC series maintainers hav= en't even tried the documented troubleshooting steps, there's no po= int escalating.

Jeffrey

On Fri, Jul 30, 2021 at 2:0= 7 PM John Levine <johnl@taugh.com= > wrote:
It a= ppears that Julian Reschke=C2=A0 <julian.reschke@gmx.de> said:
>Am 30.07.2021 um 13:35 schrieb John R Levine:
>>> Clearly, Google Scholar should be taught to find the canonical= RFCs at
>>> https://rfc-editor.org/rfc - having many secondary copies= is an SEO
>>> anathema.
>>
>> Right.=C2=A0 I hope some sitemaps will help.
>> ...
>
>That would be surprising, but would be good to know.
>
>That said, as acting RFC Editor, why don't you just ask them?

Ask who, Google?=C2=A0 Hahahahahahaha.=C2=A0 Scholar like everything else a= t Google other
than ad sales is completely automated.

R's,
John

___________________________________________________________
Tools-discuss mailing list - Tools-discuss@ietf.org
This list is for discussion, not for action requests or bug reports.
* Report datatracker and mailarchive bugs to: datatracker-project@ietf.org
* Report tools.ietf.org bugs to: webmaster@tools.ietf.org
* Report all other bugs or issues to: ietf-action@ietf.org
List info (including how to Unsubscribe): https:/= /www.ietf.org/mailman/listinfo/tools-discuss
--000000000000b4360105c85e0a4a-- From nobody Fri Jul 30 15:13:33 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BCD3A133C for ; Fri, 30 Jul 2021 15:13:31 -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 3AJ_FgzYnty6 for ; Fri, 30 Jul 2021 15:13:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212373A133A for ; Fri, 30 Jul 2021 15:13:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C5407389DD; Fri, 30 Jul 2021 18:17:22 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q4xryInK5qPZ; Fri, 30 Jul 2021 18:17:19 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 82B423897B; Fri, 30 Jul 2021 18:17:19 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 63B8A72; Fri, 30 Jul 2021 18:13:21 -0400 (EDT) From: Michael Richardson To: Robert Sparks , tools-discuss@ietf.org In-Reply-To: References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <19431.1627486962@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 22:13:32 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Robert Sparks wrote: >> > This isn't perfect, but it seems pretty good to me. >> >> I agree: it looks great. >> I also agree that we should obsolete the htmlizer. > I don't think we can - what do you want to show for older RFCs? I thi= nk > people expect the html-ized version, and we can't render v3 html for > those. but, if the file doesn't change then the HTML doesn't change, so it's just static content after it's been run once, isn't it? > Further - the discussion so far is ignoring (or presuming a change in= ) the > large set of submissions we get now (as plain text) that do not have = rfcxml > anywhere in their production process. I agree that diff creates an important requirement to keep generating and serving txt, and I'd forgotten that. (And I'm a big rfcdiff user) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEEeYEACgkQgItw+93Q 3WXNRAgAgwhG3xf1v3T1uqQjw3WVj478gdDt9P2OTUImpttcVX/5rMd74z5TuYEp By2yFl+lekauQe2nyvaTso0m5CAd0aS4Vdv5U3snceNu7qDdghzJd8zk1CgmaEdp 69zpGnPFdP/CPlHtS9dNWMFSd4rt0GHtE12yaXC0z1Er20G3Eiz74oGOPO1G6PiX Rca1nFq5xAe6fPzRYyPslj+w5wNLxNLlHNWw6H4hjpa+R0IVKWs2gZvABSM7ac0/ 3umk9bWqQc38h7HBWnLBP1U4yPj7qfFprRQJZ2o5lijKBE4j9WwjZzMnWn3916MN I9IdsPev0wrmXovTyRy4H8d2//mLRQ== =mgnn -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 30 15:14:53 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C048A3A1348 for ; Fri, 30 Jul 2021 15:14: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 A5L4Ed8pHoA5 for ; Fri, 30 Jul 2021 15:14:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02C13A11D9 for ; Fri, 30 Jul 2021 15:14:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 08C76389DD; Fri, 30 Jul 2021 18:18:43 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pLONoQiEI3Km; Fri, 30 Jul 2021 18:18:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C3573897B; Fri, 30 Jul 2021 18:18:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6DFA772; Fri, 30 Jul 2021 18:14:41 -0400 (EDT) From: Michael Richardson To: Julian Reschke , tools-discuss@ietf.org In-Reply-To: References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <19431.1627486962@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 22:14:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Julian Reschke wrote: >> Martin Thomson wrote: >> > I realize that this might be a little inflammatory as far as subje= cts >> > go, but bear with me. >> >> > There are probably a few narrow cases where rendering plain text is >> > better than HTML. >> >> The time when it's nice to have actual .txt files is when writing co= de, and >> one needs to search for, and then copy and pasting bits of requireme= nt into the code. >> ... > Why exactly doesn't that work for HTML? Loss of line breaks in prose? When I load the HTML into my programming editor, I see markup, not text. I don't really want to fish through a browser in another window. I also don't want paste to include any extra stuff. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEEedEACgkQgItw+93Q 3WXs6AgAuV73a5GxUz3DWq0Zl4ncHMoHUSkllLUrPlNU2N0yXmU2eVj7SxRas6g0 bW608No8S4b+oyjg8GzNt3A+iGTl6uM+g8WvmW/dzEfs+Hzg107tF7dHE20GVqj4 pME7idRaZPrOIFYEn6jt6F0u1bwc8wi0kmbZlbCXUPA6djKOPp3ovvM2ZBqpkdqp WOZVV3Txl+zKkNnd/qHqKzoseVvk1/tn0cgSOubglGBK8vUFUK5sdIRe7k71QVUP wvfQAG8d/pP6mthEMZh416rxRqOparYrlDd8iCDpx+mm67YtRLCMx2G4Cn+RvB/N xhi9nwzP/qCzMwlNVXVy7cIlmScYHQ== =Ro3m -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jul 30 15:16:03 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850BA3A1354 for ; Fri, 30 Jul 2021 15:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=V28N363l; dkim=pass (2048-bit key) header.d=taugh.com header.b=sfcmTVyT 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 UyWrBy_1xD5G for ; Fri, 30 Jul 2021 15:15:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CC5E3A134C for ; Fri, 30 Jul 2021 15:15:56 -0700 (PDT) Received: (qmail 34808 invoked from network); 30 Jul 2021 22:15:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=87f5.61047a1a.k2107; bh=1LdbCOSU/quZ1UKTTgnnMoh+ekM0GS0AgzxkPZ6JPUo=; b=V28N363lRNsrPFHeMe5CXwTavJNFcPb1jqURPsXw7Y39huZunx0Vx9ACShrkJ+h0IGEyOhQq/ddmYPXCzC547W1gFmmjGJ2uYGPoB42X4GPRvz7cMTl34jkHTenibamBgMYv+15E25Rxw5joPiUUaNXDnxXzMTXJyZouDjZtAJhmaDSJd3SAKkRFIE9PSa3u2GZCi/2/3ku9YGZTQtCfjB8LC327Wek9wTB5LyuDnIzu5kBcULclBImhvOxHeGX7PM97OL1SyTkIY72+ynX0lAZXkRYMCDwAW5eiq0AmjA5qPsju6gTtv9uafMjnTETDwrXK2n2bKdW2dPVd/a40Iw== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=87f5.61047a1a.k2107; bh=1LdbCOSU/quZ1UKTTgnnMoh+ekM0GS0AgzxkPZ6JPUo=; b=sfcmTVyTAA+w79wIYEpb7v7+XQ/76l3q4K5YnWQ3RNg7KQpRSbXRD0fznHPn7V/m0XywxPz1USu0iGKi5vG5ag/3hOev8hm4TeXf2GR4NXhS4UUqyLbivpq3X+qM1FvoLPQ0n21e4XzFcIygsjhFUhvylv4Uzu01L4/eqzhMAAQXPvpqhxWV9hDR9iRQEO33hLnMHcYEk+WC4MSJ8a3n0b7WWCO1vEZTB9591hlv8eW8KvN9+JSp/fVwLH8aipMP7UkA06trWtXH9RcwHIbvpcZI/p/SS4Hc5iYNAyqpnpIpieGaiU7F7FYcf7DeYQzq24K9bJ+UnagpELrrJzDX2g== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 30 Jul 2021 22:15:54 -0000 Received: by ary.qy (Postfix, from userid 501) id D4E56255BEA6; Fri, 30 Jul 2021 18:15:53 -0400 (EDT) Date: 30 Jul 2021 18:15:53 -0400 Message-Id: <20210730221553.D4E56255BEA6@ary.qy> From: "John Levine" To: tools-discuss@ietf.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] Google Scholar not indexing Internet-Drafts X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 22:16:02 -0000 It appears that Jeffrey Yasskin said: >-=-=-=-=-=- > >I started writing an email to someone who appears to be the right internal >contact, but I had to stop because this thread and the thread around >https://mailarchive.ietf.org/arch/msg/ietf/I0BIw22bhd99buZz9lE-kFcrFGI/ >don't have enough information to constitute a bug report. What have the >rfc-editor.org maintainers done to attempt to fix this? As far as I know, nothing. Like I said, I'll try some experiments when I have time. R's, John From nobody Fri Jul 30 15:42:02 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22783A143E for ; Fri, 30 Jul 2021 15:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76V5HcuNQAq8 for ; Fri, 30 Jul 2021 15:41:56 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2091.outbound.protection.outlook.com [40.107.22.91]) (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 9C64A3A143D for ; Fri, 30 Jul 2021 15:41:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gtTPaCzw+3bM477UG8ThnDgmmme045PjBNco4GLCRei3IMLEguTgaMnIqFUDLD1Ympof468SmJrFR0/h5T2obAx6zQLQBhIYMXggDu0zT4Hpqhj5v5ph4xVjhpazivCMwkg5BfoF67QJtHhMu1JZNf7UXdrSgtp+A+4nUjay1iSVTU0w7YvyTM4xwxBIDuKkuhmHGRYZc6RZyvAcflcZur5NozMYNt3CtHLPfeKP4MTyFi6qZYE7/7OGcXtmPj1PKwyLHFAm9Ls0IMGoQbm7lzprwEUccK/u5xjwh/BSo7ty4O4y0lwum5jt7HPlAghgGUOU+YBzf48cQd/X/rNTeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zF3Oi2OgvOk+Dwv76Ttu5lEzPDcc0o4ERcbU2o7R8k8=; b=X+nGBhM/PbNnJ7cYNXJ6aDGAAFjKcUDImkEFKgA8ANyEztJ/bGO7CLLdRRfKcREIL7lJVUHW6GxIwp/bn1vOBSl+wxIB9GHgbVI7KTaLVCdVpCiI9txL7KzOw+JCn2SAPjxkquo7G13p1FGAP9Fs5ZSAEWeYB2jjuMKAQmQv5EO/4v2sQLulOQh6vGA41rrTCJ7DGhRhCgA/UIXkwEr/sDyaVFRppvVkpwCKwwWnEdGN45RjzcdoOEd1IlOqmZAtiv+5b6QgkFRDalNwJ1lzxd7l8E0xARFCs+V/pYhYvm/aVybWBRczLs446mNpMEA+LxtA1HifDUVvwb0+a9buag== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zF3Oi2OgvOk+Dwv76Ttu5lEzPDcc0o4ERcbU2o7R8k8=; b=DAeVHNanqFCho1gmbLFBecm8J0VqWB8cEyvSx9FUsMfBYT7Gd33BtRPydvzhcLc2T6fhJb8wCgQkAx5r6BoBV4/CejSt9oX0jPOrVVqdC6fKg8GGozo1Jt2P6qAFITu7Y9x2ZT0GEnQpb7t/hQf5WZjIyZW0EN88l+r4JacHF0Y= Received: from PAXPR07MB7999.eurprd07.prod.outlook.com (2603:10a6:102:139::19) by PR3PR07MB6908.eurprd07.prod.outlook.com (2603:10a6:102:5e::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.16; Fri, 30 Jul 2021 22:41:53 +0000 Received: from PAXPR07MB7999.eurprd07.prod.outlook.com ([fe80::b0c3:854a:67b3:9b6e]) by PAXPR07MB7999.eurprd07.prod.outlook.com ([fe80::b0c3:854a:67b3:9b6e%6]) with mapi id 15.20.4394.008; Fri, 30 Jul 2021 22:41:53 +0000 From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" To: "tools-discuss@ietf.org" Thread-Topic: Agenda Web Page Thread-Index: AdeFkxKvFKekN38sQzGh9VR0NZUVew== Date: Fri, 30 Jul 2021 22:41:53 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aec27240-6692-4f11-d907-08d953ab3a9e x-ms-traffictypediagnostic: PR3PR07MB6908: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sGgojARRLrdko3iumpndMY/Z9wEUESHnyj709H+zuxZICqoZ3sy5qvwJZh3r9X2W2esjWrPp8a2znAnOAc6VC2rP1U4xq46Hy5JTzX6gtk+mewElc0xbCKsG59VeUgTJ5d7jw3vvO8g3cx9mV5XsA2mhaxznUDtYZiEpfftXWu+mZxg7hX0UWBCFRbUQ2WPfptKEd3I6j6WXD9/zQ/qpawCVGorZyP9GexgedZZPtOiMer4Dovi1/Td1xmcTgo2tWLr4wnJL84+OGvqycpvmxxHNfU057ipLAO6Uf2h6fRjHKovz8+v5697Sf+/kh4CZj7yEHKq67P/16KYpxvpKXNbOjzqMQ0i/YD8WxRarweKyHq9TxW7qCvR6z+h7ifHOpkivxt1pen5ic3yPL5jdf99STQuaT87KjIEFdRdPQpmUMaLqMetwPo/R9Tfzwa4ugqR3BQPtdNmqy/caqzKTiOJ1vtvLxDn8EL4hb38Oq2woKVxhuTCO1KKvDKUzdHAq+GgkrbW8OHK0499dQuaqHGK4qhQeCjwqoPVmQwjmk8JCstDc5Zaom2R5jht3x68h4QZGGOJ84HZJx4iriNlkM+corkUkPD+dMS804BlfVTLDShoGgT31MC8q9EGl2Joo5PStRhyLA4hEzSvN3prxeZCnkqszL3OSFM/1XMAIHCsnfGr80MQ3HVwEEqzbnPicrqqddavFrGpd085nck4u6A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PAXPR07MB7999.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(376002)(396003)(366004)(346002)(136003)(478600001)(86362001)(7116003)(7696005)(5660300002)(3480700007)(66574015)(6506007)(33656002)(83380400001)(4744005)(6916009)(26005)(38100700002)(8936002)(66476007)(316002)(2906002)(66946007)(76116006)(66446008)(9686003)(52536014)(66556008)(38070700005)(8676002)(186003)(71200400001)(55016002)(122000001)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?vyHaQL0o4xrzdvXsAoXfofzgAmBjKUCyXWmmOoIR1CDZvwXK2X2+LY8u6M7k?= =?us-ascii?Q?6vNrozynzf9JQbbsvXYLeJ4K3E000wV+zx20LJ0VZRl9LzlulFHH6RLHDeUs?= =?us-ascii?Q?2PeZO5DwLPPMHc9QbEH40jjqr8nhTxhYUb021OI79BQXD2BwdLzA2O/+D/1J?= =?us-ascii?Q?VURTvj68ngkNyuPaHo0YKH9zHajjdq5nts8KVxtu6foVvg8KYiYvHprxgv9U?= =?us-ascii?Q?2KR7bawYX8vRBFm8Xp2C65wPWaRz2SqLPL5QjfY6vPT+MIO9Rs9ruN3KF7lo?= =?us-ascii?Q?3zeCbB8MtydcTllv7i3b3gPy7bz5/6BQgRMaHNIMfHdlW6M63G7R2KyXPWnM?= =?us-ascii?Q?9ea35Kut0DUMY8VS5svTocYUqsBzAO00rKafVZx4C2BnJIO/RuJaYd4pHzNE?= =?us-ascii?Q?7jGD6WlYIUExz+a8BkPP5buY3IoVI+EMXWa61E51EnQQ4A2XCSKl+QVs5g/d?= =?us-ascii?Q?i53mu8khi5cpQRscrX6IELFrygQA5KdA/Q1X2uXyN36ne8B2DiRvfdbOGznO?= =?us-ascii?Q?hZGAAMQRY+l9vZcVrRehSQOV51hm36+60iDHxXVSodMelIY7RaMETeI3dING?= =?us-ascii?Q?6j2TfnJAYYz08/IChmIb2Ap+ZoUGiY+caJGtn7aWlVhusmWXOUVv+HKfoU/z?= =?us-ascii?Q?e5zVrEVR88i3qDSTt5hXKLMoul1DDeYOD5amzMbqOcNLsvah8E4Tw+PnhZBe?= =?us-ascii?Q?cnAMxZ0xbwkPVuwEGtcFVBPuagptyIAagoI7tKRvzny/WReoTnsVFaj2rYTk?= =?us-ascii?Q?MN3gAVAfZDeup29f3jwI4B6ZARJ9m8AFoex0zwfTT6whh1K6BdJrIy4X+g6a?= =?us-ascii?Q?zc5t2vPkpMoxipvIBmlEgEv9UTa3/HIB2xYeJ4USATR4LS8CS02K8jUIExER?= =?us-ascii?Q?MFKLIv4gGAhascu9g2oPn52XaCpEltMjImzgNUUd4rMwo0pDrf3YmgtCHtYQ?= =?us-ascii?Q?fWQmuWSiOHnyLdNbn+UXwpasu5GZgJ2yAAlkBiuCQHpMSrLzel+uyBdPoBaD?= =?us-ascii?Q?2hJ3tW1FOzV9iJM7pahvTGxZbYzYq2hHY/xQp7piHvTz+qJT00Nbjq/oBmJ9?= =?us-ascii?Q?cPFGqHPxmGqTGRSs+iz6yGgN5+fWpLnBUfws13hf6jLFcQj3TTGewPme7vCH?= =?us-ascii?Q?RWHG5bQZ16j6WQdCSbivFDBfiAnGDXiP2pRNe1CgsgRfeqYkaAGPdWLqVp2u?= =?us-ascii?Q?reJdUYINsn5X/AA1OXiQX8fDxLf2qBRPgYufuiNJuT9uwOYaR2oWCK3pQYni?= =?us-ascii?Q?lxzQrgpu8h77WUx/4ZUpqtyxCrn/3Gw7Cr5abcgyvCFSkhqUTLHt+ejqtU6S?= =?us-ascii?Q?LeW8iADqpUf95xWI5iGi1wke?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PAXPR07MB79991137E85A74CE66691E8C92EC9PAXPR07MB7999eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PAXPR07MB7999.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aec27240-6692-4f11-d907-08d953ab3a9e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2021 22:41:53.6263 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rdCc2acReZ7hyhHwVXdTrX5QRLKWSscAMT/FC9B436SWy/lLsAKyXQcPjH8INrH6qcVAJHI5C2fDlQuZOQilYV8WbcheaV38LTz2LJLPkHI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB6908 Archived-At: Subject: [Tools-discuss] Agenda Web Page X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 22:42:00 -0000 --_000_PAXPR07MB79991137E85A74CE66691E8C92EC9PAXPR07MB7999eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Refreshing the agenda page (to get the latest wg agendas and materials, or = just agenda updates) always revert the timezone to that of the meeting, for= cing to go back to the beginning of the page to reset the timezone to the p= referred location. After a discussion on the 111attendees list, it would appear that a few peo= ple (including myself) would be in favor to have the "Local" timezone optio= ns set as default. It is likely to inconvenience a far smaller set of indiv= iduals than setting the UTC or meeting zone (people whose browser is set to= a different locale than where they actually are, a minority in reduced tra= vel times). This condition could be different once we resume physical meetings, then th= e meeting zone would probably be the most desirable. Alternatively setting a cookie to enable the browser to remember which zone= is preferred would lessen the problem. Thanks, Best regards, Julien. --_000_PAXPR07MB79991137E85A74CE66691E8C92EC9PAXPR07MB7999eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

Refreshing the agenda page (to = get the latest wg agendas and materials, or just agenda updates) always rev= ert the timezone to that of the meeting, forcing to go back to the beginnin= g of the page to reset the timezone to the preferred location.

After a discussion on the 111at= tendees list, it would appear that a few people (including myself) would be= in favor to have the “Local” timezone options set as default. = It is likely to inconvenience a far smaller set of individuals than setting the UTC or meeting zone (people whose browser = is set to a different locale than where they actually are, a minority in re= duced travel times).

This condition could be differe= nt once we resume physical meetings, then the meeting zone would probably b= e the most desirable.

Alternatively setting a cookie = to enable the browser to remember which zone is preferred would lessen the = problem.

Thanks,

Best regards,=

Julien.

--_000_PAXPR07MB79991137E85A74CE66691E8C92EC9PAXPR07MB7999eurp_-- From nobody Fri Jul 30 15:42:50 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA43A144A for ; Fri, 30 Jul 2021 15:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPOlwlTRaW_f for ; Fri, 30 Jul 2021 15:42:43 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 67B0D3A1449 for ; Fri, 30 Jul 2021 15:42:43 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id k1so12770185plt.12 for ; Fri, 30 Jul 2021 15:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=gTlqYN66gX+1xJRJEpKr/OoMrkakAPWoV5dD611urVY=; b=jZjyO61w5opMCRtPS0cEa5B4dVxmqC6Swmt+e5uACE1WrXe5iOykH9x61AgcsS7A4T Hv2QgA2PZDncKXx9sC0yhTrVzsyPKa5BqlF4Zkwg2EjTWSsXMnB2MdV/iuFGeoT2dm52 U1N6H8ZvK6UIhMIbP3R+9Vx9fN3hGX26kidIjGF+/fOf4F8SvLTPDraGdzIJmb9uGht7 E2FJ2kyteexDGPd/kvsHnxNdy5WH5CUgtHSV4ukLsFeVGzWdU+NHW5VU9R2uOsRuJE0b kyKNT6F50UPUrtI7irSHYhHja1e1FB98YaoFPhYaDmjk6SGVpRJ8agsSWO93tifpbjVO ooPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=gTlqYN66gX+1xJRJEpKr/OoMrkakAPWoV5dD611urVY=; b=mNljBOUa1LPuu5T6EIWW+++vGCRp9cAqZ2D+i/GzJIIiiJR6lvqhckQQ53zRLOWOK8 PpBSBLcvd98V+Avtme91oFliHZhYhSNPqSyRs019gckckxKSDeyPCTJEPVkudsQfcpNg IMxpe+W2BofAh3rJuBiZvoOZ1mzjxyxY60XP4dlh7BEd40gdi9V2NeTPrQ4sx7tijp/g R18L2bQi8ptnnyd+1EZG8xfeQVnAfdUptNIZk9ICsWwOJxDWTHU2tTygRbcQtr7V0d9q FcE5v3CoGrZ3c6bvtmG2B5/KOaDmZZB3E9FnJtfgt5oXKEUzP3Eb3ckDBi9/vPrd3xQA 3qhQ== X-Gm-Message-State: AOAM5313520On/dN0mjFIAUEaLrU6pgPIh4U/NKIaAhd6Wc0Lpu//LeS fKHmH6CewPrTxwP+CxOuGgVMd4H3fP8= X-Google-Smtp-Source: ABdhPJwrWzRXRpme8TGzySSUJD0v6Zt5pVxSV1xKIOa4gCtzCuZe6jRzZ9z0vA1egH8X5lH5WzPJbQ== X-Received: by 2002:aa7:8ed0:0:b029:357:9c8:d13 with SMTP id b16-20020aa78ed00000b029035709c80d13mr5158229pfr.10.1627684962164; Fri, 30 Jul 2021 15:42:42 -0700 (PDT) Received: from smtpclient.apple ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id a13sm4147349pgt.58.2021.07.30.15.42.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jul 2021 15:42:41 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_5846CAA0-6A6C-491C-B24E-AABACEBD4C7B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <348DC877-AC0D-4974-9C96-FBE144650BFF@gmail.com> References: <251AF72F-CA8B-49F0-8C53-88C912D7C44F@gmail.com> To: tools-discuss@ietf.org Date: Fri, 30 Jul 2021 15:42:40 -0700 X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Tools-discuss] Fwd: MeetEcho Feature Request X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 22:42:49 -0000 --Apple-Mail=_5846CAA0-6A6C-491C-B24E-AABACEBD4C7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Begin forwarded message: >=20 > From: Dino Farinacci > Subject: MeetEcho Feature Request > Date: July 30, 2021 at 2:09:22 PM PDT > To: support@ietf.org >=20 > Didn't know where to send this. Here is a user based MeetEcho feature = request. >=20 > The blinking yellow dot is great to see who is talking. But it would = be good to blink it for the people in the queue. When the chairs move to = Q&A and the top of queue is speaking, blick that person. And if that = person is done and forget to remove themselves, then blink the next one. >=20 > Maybe temporarily you move the person to the top of the display just = in case its not a queue member talking. When they stop, leave them there = for 2 minutes so we know who has recently talked (so if there is a 3-way = interaction going we know who is part of it). >=20 > For a user, it is too hard to scroll to find the speaker when there = are a lot of participants. It works for < 100 participants but that is = probably the patience threshold for a user. >=20 > Food for thought, > Dino --Apple-Mail=_5846CAA0-6A6C-491C-B24E-AABACEBD4C7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Begin forwarded message:

From: = Dino Farinacci <farinacci@gmail.com>
Subject: = MeetEcho Feature = Request
Date: = July 30, 2021 at 2:09:22 PM = PDT

Didn't know where to send this. Here is a user based MeetEcho = feature request.

The blinking yellow dot is = great to see who is talking. But it would be good to blink it for the = people in the queue. When the chairs move to Q&A and the top of = queue is speaking, blick that person. And if that person is done and = forget to remove themselves, then blink the next one.

Maybe temporarily you move the person to the top of the = display just in case its not a queue member talking. When they stop, = leave them there for 2 minutes so we know who has recently talked (so if = there is a 3-way interaction going we know who is part of it).

For a user, it is too hard to scroll to find = the speaker when there are a lot of participants. It works for < 100 = participants but that is probably the patience threshold for a user.

Food for thought,
Dino

= --Apple-Mail=_5846CAA0-6A6C-491C-B24E-AABACEBD4C7B-- From nobody Fri Jul 30 15:43:08 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DBC3A144B for ; Fri, 30 Jul 2021 15:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kStzI4NcL0MH for ; Fri, 30 Jul 2021 15:42:56 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 143303A1481 for ; Fri, 30 Jul 2021 15:42:50 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id c16so12778268plh.7 for ; Fri, 30 Jul 2021 15:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=g0zoiLsQ8dFxV6uHccoPA4RZGmmtr3W1omH7qj8/Ymo=; b=QSLzZTdR+2tvHHTqbRaUhOSHzJRYVE/dTcGXgENbRXgry0dpVx9B3+V/+ws2apKjht LmzAd3EF0DGBD9Bcm3ECbHT1wv90mp9wpyICr6bo4SLup9e7tNHyiRj8LvspOG/pXJ/U w1NCNtH6g4wDPNeDeh2kbdbqA+2ENIEnfwWysM+QfAaMn4dpLc/rKowuADXzivO5MwHO VUowJnpqSIiMNI2UkinifO3bsvP+lMwDJAP/Uptf4YPU/IVDWPJJvxLnXDyDbwEvisx1 hDNGRTtgU9SjYu7wGWLF9fdgiKPjQnKH2aKUrSog36u5qXZatAzxU6vco/l+Bq+2D+rh jwGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=g0zoiLsQ8dFxV6uHccoPA4RZGmmtr3W1omH7qj8/Ymo=; b=P4qi280pwY+KM5Ocr0Tn2tcMsMTBpfb8LGoEmbHY+vsYJsNAdwTv8t/3PZXLl9rxKI vDdyKR9XDveYi2v4wdIcbT+jRMLX1HbJ8gOOJK86icpteeLbWGAurxjLamcFZywAsGCp zRVYEJkmXq45LrRbhatguaGk4bwklPgrawz4MZVYjWz349KoeepjtXvr8Xf2wPwnuw6Z mhEhKOG/i5Sn2EhB9y414cwvhs28FBhrHD3sW3kbyzP5Zlh/SbSjTt2TzbYCR9HqoI4R 6Iz4yal20KjR/kHrT0RfIviLIA/jISDH+aG25mM6JMPHqme7LqU1iXzIniJEYrjGY8EG Rj2w== X-Gm-Message-State: AOAM533uoWbl/V/wMgZyd4ACQBfBrdchLFKHrJq6CUGgr2t44a0Q5sWP 6InEn21XBE7db50ZQ0DWlZWhNyKFvJQ= X-Google-Smtp-Source: ABdhPJw8KVjpOOquapqSrph+qrAt82dGeuTQWFji9XX2qNz79BdpyLdqJEOFIXJH1t5HFndqpt2RAw== X-Received: by 2002:a17:902:e5ce:b029:12c:403b:7fb7 with SMTP id u14-20020a170902e5ceb029012c403b7fb7mr4306273plf.68.1627684969327; Fri, 30 Jul 2021 15:42:49 -0700 (PDT) Received: from smtpclient.apple ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id a13sm4147349pgt.58.2021.07.30.15.42.48 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jul 2021 15:42:48 -0700 (PDT) From: Dino Farinacci Content-Type: multipart/alternative; boundary="Apple-Mail=_65ABA902-85A4-4D98-B3C5-2361D19A863C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: References: <818C07B3-C0E3-4E76-B73C-EE179E3ED32A@gmail.com> To: tools-discuss@ietf.org Date: Fri, 30 Jul 2021 15:42:48 -0700 X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Tools-discuss] Fwd: One more MeetEcho Feature Request X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 22:43:02 -0000 --Apple-Mail=_65ABA902-85A4-4D98-B3C5-2361D19A863C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Begin forwarded message: >=20 > From: Dino Farinacci > Subject: One more MeetEcho Feature Request > Date: July 30, 2021 at 2:56:56 PM PDT > To: support@ietf.org >=20 > Put company affliation with participant name on the participant list = panel. That would be really useful. >=20 > MeetEcho is providing more information than we would normally have = with face-to-face meetings. So I see it as a huge advantage. Many make = arguments that there is no substitute for face-to-face, where I agree, = there are things that virutal tools provide which are valuable too. I = mean, who reads the blue sheets. ;-) >=20 > Thanks for consideration, > Dino --Apple-Mail=_65ABA902-85A4-4D98-B3C5-2361D19A863C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Begin forwarded message:

From: = Dino Farinacci <farinacci@gmail.com>
Subject: = One more MeetEcho = Feature Request
Date: July 30, 2021 at 2:56:56 PM PDT
To: support@ietf.org

Put company affliation with = participant name on the participant list panel. That would be really = useful.

MeetEcho is providing more = information than we would normally have with face-to-face meetings. So I = see it as a huge advantage. Many make arguments that there is no = substitute for face-to-face, where I agree, there are things that = virutal tools provide which are valuable too. I mean, who reads the blue = sheets.  ;-)

Thanks for = consideration,
Dino

= --Apple-Mail=_65ABA902-85A4-4D98-B3C5-2361D19A863C-- From nobody Fri Jul 30 16:36:02 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236BB3A1714 for ; Fri, 30 Jul 2021 16:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 crMvZsFUKYD1 for ; Fri, 30 Jul 2021 16:35:52 -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 0B5843A16EF for ; Fri, 30 Jul 2021 16:35:51 -0700 (PDT) Received: from smtpclient.apple (cpe-65-184-148-2.ec.res.rr.com [65.184.148.2]) (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 79D852A7C6; Fri, 30 Jul 2021 19:35:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bangj.com; s=201907; t=1627688150; bh=nG4eqLi9h7swwwU8t3tDh3zwGZz56S/WLaVxMbVWung=; h=From:Subject:Date:References:Cc:In-Reply-To:To:From; b=JmlBHH4Bua6AGXqIj6k3pkhdQvki5bGDTuQPh5Om3ZtVPNO9YUWrJNJch0KDsjxDi cWfM8yapkEfXJegi7E/XgX1xPOn+rrTlfYQ1Jvqpx4oSgCwUEv6tIXu4Ez4ohJ44Vd DvzC43Y6PVN4Ze86ifXhBCa/VbkfksjSt4bksrV+tT3my+QVHGRj+GGWdOy588RyMx i2ZR8yUt12Ae/XZMrIvN5Af52HKp0oDjsOf9m4rQH8tX3NmVl3EpYevp7zgnSHS6Vh 8yFMqGsLA5ezr20ZAYg0SK61ZD1s8dVcnC1wS1IbCYS1wfyk4pAm6bQQPK94C38iip p5PYc9aLeGSfQ== Content-Type: multipart/alternative; boundary=Apple-Mail-76BBF5C9-CB13-4B11-8D8D-FAA8E9FFDBDF Content-Transfer-Encoding: 7bit From: Tom Pusateri Mime-Version: 1.0 (1.0) Date: Fri, 30 Jul 2021 19:35:48 -0400 Message-Id: <9B00341E-0899-4FFD-9095-0434A4405790@bangj.com> References: Cc: tools-discuss@ietf.org In-Reply-To: To: Dino Farinacci X-Mailer: iPad Mail (18F72) Archived-At: Subject: Re: [Tools-discuss] Fwd: One more MeetEcho Feature Request X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 23:36:01 -0000 --Apple-Mail-76BBF5C9-CB13-4B11-8D8D-FAA8E9FFDBDF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Jul 30, 2021, at 6:43 PM, Dino Farinacci wrote: >=20 >> Begin forwarded message: >>=20 >> From: Dino Farinacci >> Subject: One more MeetEcho Feature Request >> Date: July 30, 2021 at 2:56:56 PM PDT >> To: support@ietf.org >>=20 >> Put company affliation with participant name on the participant list pane= l. That would be really useful. >>=20 >> MeetEcho is providing more information than we would normally have with f= ace-to-face meetings. So I see it as a huge advantage. Many make arguments t= hat there is no substitute for face-to-face, where I agree, there are things= that virutal tools provide which are valuable too. I mean, who reads the bl= ue sheets. ;-) >>=20 >> Thanks for consideration, >> Dino I would like to see affiliation more prominent as well. I would go a step fu= rther and have people list who is paying for their attendance. This is impor= tant sometimes for contractors, students, etc. Thanks, Tom --Apple-Mail-76BBF5C9-CB13-4B11-8D8D-FAA8E9FFDBDF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Jul 30, 2021, at 6:43 PM, Dino Farinacci <f= arinacci@gmail.com> wrote:

=
Begin forwarded message:

From: Dino Farinacc= i <farinacci@gmail.com<= /a>>

=
Put company affliation with participant name on the particip= ant list panel. That would be really useful.

Me= etEcho is providing more information than we would normally have with face-t= o-face meetings. So I see it as a huge advantage. Many make arguments that t= here is no substitute for face-to-face, where I agree, there are things that= virutal tools provide which are valuable too. I mean, who reads the blue sh= eets.  ;-)

Thanks for consideration,
Dino

I wo= uld like to see affiliation more prominent as well. I would go a step furthe= r and have people list who is paying for their attendance. This is important= sometimes for contractors, students, etc.

Thanks,<= /div>
Tom

= --Apple-Mail-76BBF5C9-CB13-4B11-8D8D-FAA8E9FFDBDF-- From nobody Fri Jul 30 16:50:44 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686273A17AE for ; Fri, 30 Jul 2021 16:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpngTY93mlsY for ; Fri, 30 Jul 2021 16:50:39 -0700 (PDT) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (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 A31A33A17AA for ; Fri, 30 Jul 2021 16:50:39 -0700 (PDT) Received: by mail-pl1-x629.google.com with SMTP id z3so11617546plg.8 for ; Fri, 30 Jul 2021 16:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1U+TWxpIfSBEjJO8Zw7CjWr8rZlnRvGDS9N3dn4UkbI=; b=X26UhAT19JZhBe2h441sAr+2ZB6MmO7VzRhd0i/az2U99OlwX5Sd64yZMSjB6RtnYm mDRqBISUvsZ+agc6U96QoWHUAl1cFrqYGRv3lQM9Q2PxwWYAc6BMIl/MjQlixekMUIp3 GYyGWw6wO+3FADWhqidxNLLpFpsMEwJnQpH3P4g72Wc3OEEIoDeN9sr64viXRzXGg0j/ Ooq4t329sUsw6Rk1vShteGZIzUwAzmlgpXK1+jzIW/coxePcOiPaE3NYBCGPziiL/0G7 6/mvrnAW4J5sBpMiSYUoCg2AoaHNpdKP0NmnA0hznLHgAsq91x8yu8iU5Nqiy6rdheGJ K6eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1U+TWxpIfSBEjJO8Zw7CjWr8rZlnRvGDS9N3dn4UkbI=; b=s+tmHtOC4AahwXiFNhNKiAzvcBxW6A6/j6LsejAcD7m0o2B76A02ZgTMpIzdw3RyD1 Ia0BM0cvYectUF+g1XnZUAqP72yo0dKq3eEiqNTA68Z5lN90XZvN9tPsIP9PBbNqc7Cg eSIGKUcyTAmLkkgpUAOT1UcV785A3QOsVE8Nw/dilr6T/+InCA2aamtQNow5uIlGvB+c AIRQiOsG9pAKox7fNBKfiuZPJI7J5m5i9boDtbehTMbraotnmhwxBdFu2niakxf1P4cy QsUqr+Ru5WttcGI4V9dx0zoS7c/BYmoTpwb7GKsbhsOmRiDVENAR0EmNeWXbINbBXOiI D3dw== X-Gm-Message-State: AOAM533V1sA7J+5K+zg/oUJH5FaP/ca+pF56VEc8fFlpkZ41fzbERb5y TPtrjB8TosaG1KsGUwZf3gPjmsXXHGc= X-Google-Smtp-Source: ABdhPJwFZ1z2MarvLBA1upg3GRFKkcIcgID3uApDVmi1z2b72ALsA4qfCtAFZm2hfdOODliitZn9lg== X-Received: by 2002:a63:d54b:: with SMTP id v11mr4372309pgi.450.1627689038970; Fri, 30 Jul 2021 16:50:38 -0700 (PDT) Received: from smtpclient.apple ([96.72.181.209]) by smtp.gmail.com with ESMTPSA id a85sm1523591pfa.46.2021.07.30.16.50.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Jul 2021 16:50:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Dino Farinacci In-Reply-To: <9B00341E-0899-4FFD-9095-0434A4405790@bangj.com> Date: Fri, 30 Jul 2021 16:50:37 -0700 Cc: tools-discuss@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <80EC5F8A-9396-4245-8F49-2C21EE931AE2@gmail.com> References: <9B00341E-0899-4FFD-9095-0434A4405790@bangj.com> To: Tom Pusateri X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Tools-discuss] One more MeetEcho Feature Request X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2021 23:50:42 -0000 > I would like to see affiliation more prominent as well. I would go a = step further and have people list who is paying for their attendance. = This is important sometimes for contractors, students, etc. How about "optionally list" who's paying. Because maybe the contractee = and contractor have a confidential agreement. Dino= From nobody Fri Jul 30 21:31:57 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC74C3A11CD for ; Fri, 30 Jul 2021 21:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vTSsd6QNAsjm for ; Fri, 30 Jul 2021 21:31:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 844083A11CB for ; Fri, 30 Jul 2021 21:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1627705900; bh=YjZqEvQ4w4sJJSfEdDc4rj5JlgmBpz8pOj7dYtIqS3c=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=AGUxebQ2GygUV6pT3BJ0vzsG6jiPhBuUH3ko2NsyteKMGJyda1G1cLH9mSQEaGd8S WSajONDJfWOmNkFae4geNZLUT/5FHygyVFiJhtr3oAejDTSTKuUwLnEWdcMPmCPjkH zWWOyy/3UmvUt1/KvB3dkNNRX5ybZBeXP8oz7Zws= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [172.16.1.70] ([212.205.152.82]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MqJqD-1mwmv12AJ1-00nMwi; Sat, 31 Jul 2021 06:31:40 +0200 To: Michael Richardson , tools-discuss@ietf.org References: <4d70a1ac-a275-420a-83f6-99dfd5b5385c@www.fastmail.com> <19431.1627486962@localhost> <15399.1627683281@localhost> From: Julian Reschke Message-ID: Date: Sat, 31 Jul 2021 06:31:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <15399.1627683281@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QAFTYEbtKr79XOmsYPSgr7AilhYy95xgXuntogyt26hjNJwzvRE onnQIgO+fsfzQreO+3mj+zFXZWTayc48q125SeW1hampmezro0j9ODIc2HbiUNT3WsOffmx 1Sj0Rw9Q3/IPzoGHZ5LPnCFDsVUPUWitev3y8DVa/zikrIGBB75QQ9s2Op+6u2wQv67BAHU ix2fyndpErgv2yX1QscKQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:BJHXDyaXqFg=:Zl5Enzdk3y8dy33IRRKfdS OAk161pPrDZ7X65rfGzy3HVER5BuAblywJWyoLJ2xLj/62TYhJ61bfPGIG6Pxn2tXa3NRw3ro 9awSjOE5jExyl1CnRFeqpSkqUdosps5c5ziiRH59J0gPKazxwBPJ2NWzxNpzctfZ6R1YQfoye a4XBIiBoajcpasoEuG8RVaf1BrOZPh48F6kuWgDAsrQCLp+BcVMXwtueRXx7XyrhGeJc9NNQO NbtuviwN+k21i344sPwkEYQZ/j2lW7pspERZLipqUSPhAe8WYw3upgwAzcgh0Y7XMYEKBGSSl 6nQaclB4ecasHAi2dfWCGMy84Yp5vKxJhXAGRKHDbgyyi1OZ+GCdigzAxy0XZ2yf/evbEyEh4 FnSKynAR+LqfmoRxT1WTgoxDPVexeF0BJClfnf5oeDchZ18WIIYxH9Mi7sAPeDHCkWL4g2AYT SfenUCYjne5aPY1nSqiNBmsVpWH3x6k1G9/5Y7Y51ZvBfnISMjx0E01A7NLDT91/j+ZUH3O2a eFawam66tPkcWhaatIKgwjSI5H2KgMoTlTq2QVWf0rPUuIa6rUqx07ygmTuOcgXqmTtHba3MM +6aWjoYRG4/mVo4Ibdr/ElgvSEiDe8VPNaihCnCtrBFAlaepDcz8xf1I9wG//Cnjuz27nvnjs yl8cK9HCqyy0K41E6HRpc2fLCmVU+DOYE0FelUyvYvh3qwwj1D5xKoIZz6gbS1Vm6CtHq+83s zhtPAldKgNAiVnGdOls7yW4RhIP3KWf406fl2Nh/gQBqFdh0ArDr3X/GeWb4RCBzwk8Y6Y0y3 pfSx1/46cz3y1A3GxYmJuEExVsTXnDH6aDEtaNs451U/hTBNK8gYNi7OJNANSnG+loKsG3g4O el18IulZICisx12Q3O6pIEimd6MKyzPuUiqtL7+prKodb5CUc/naZFCZoprs0DQsyGGxqfWwU 34+E+PxPnarRYb8E75F9N/8YFQI+tWNT1R67boOkVTJmx/t2qrxogN2oiAL51cd5OWo90QdwE DYqnwaCPUesLorOz2DLBWBraxNsiu1yp8Dtc/UsTt4+/vQF0nWNpbIKgKhGzHwx1rA0/lfgl6 0Zxkz4nWRj3yRxR3zf05Pjs1Qv13vRE4kIvJizOTaW4Y0+gHkIEqiwHZA== Archived-At: Subject: Re: [Tools-discuss] Why do we even have text formats any more? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 04:31:56 -0000 Am 31.07.2021 um 00:14 schrieb Michael Richardson: > > Julian Reschke wrote: > >> Martin Thomson wrote: > >> > I realize that this might be a little inflammatory as far as s= ubjects > >> > go, but bear with me. > >> > >> > There are probably a few narrow cases where rendering plain te= xt is > >> > better than HTML. > >> > >> The time when it's nice to have actual .txt files is when writin= g code, and > >> one needs to search for, and then copy and pasting bits of requi= rement into the code. > >> ... > > > Why exactly doesn't that work for HTML? Loss of line breaks in pr= ose? > > When I load the HTML into my programming editor, I see markup, not text. > > I don't really want to fish through a browser in another window. Ok. > I also don't want paste to include any extra stuff. "extra stuff" such as? Best regards, Julian From nobody Sat Jul 31 08:09:42 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5CB3A03EC for ; Sat, 31 Jul 2021 08:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QztFh1bRAdl0 for ; Sat, 31 Jul 2021 08:09:36 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680A73A03EA for ; Sat, 31 Jul 2021 08:09:36 -0700 (PDT) Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GcSNT1Q0Cz31W1; Sat, 31 Jul 2021 17:09:28 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: <348DC877-AC0D-4974-9C96-FBE144650BFF@gmail.com> Date: Sat, 31 Jul 2021 17:09:18 +0200 Cc: tools-discuss@ietf.org X-Mao-Original-Outgoing-Id: 649436958.698174-f2360fc295696bd121cb827935880364 Content-Transfer-Encoding: quoted-printable Message-Id: <6E864AAE-D3B8-435A-A007-8381A9A056FA@tzi.org> References: <251AF72F-CA8B-49F0-8C53-88C912D7C44F@gmail.com> <348DC877-AC0D-4974-9C96-FBE144650BFF@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: [Tools-discuss] Blinking "speaking" circles -- Re: MeetEcho Feature Request X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 15:09:40 -0000 On 2021-07-31, at 00:42, Dino Farinacci wrote: >=20 >> The blinking yellow dot is great to see who is talking. No, it=E2=80=99s not. It blinks every two seconds. That is way too slow in an animated = exchange. Make it be visible all the time someone is speaking, it might still have = some slow animation to it is attracting attention a little. (It also is on top of the picture, which is counterproductive. Maybe run a ripple through the background color behind the name=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jul 31 12:37:07 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF043A174B for ; Sat, 31 Jul 2021 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsQmzR0yqawg for ; Sat, 31 Jul 2021 12:37:01 -0700 (PDT) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 F2A8C3A174F for ; Sat, 31 Jul 2021 12:37:00 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id l19so20058725pjz.0 for ; Sat, 31 Jul 2021 12:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=rYLoj+yLB7GjMWg/q4tuituU5yy2PEfLXMj+mo1wAAo=; b=tFTL4KvK40kcrp22uESibcYjnL4M4oJ0gBq/FNrfuGRJ3LvXzdDQTjh79h6JrKp43b bBGyMB+dr1t7zh75CUQQb6En7fFBVyjtKQfLUb1Jl0YdOFPA70iNncU1RKYkDIcerDzD GcVpq1S2hOcxZs/URRQwCcdZMi0OlMSKGsV6LPIUC2t/uIQSQv6nMzp+A9hQdqc18Z0x vU6B43VsBKlxp7dbgf3gR9uXBUUxjtFqArHygBt6CidM9NmrN8yK0xuSc2OjpVCaSQ3s JBoh7wp1N5boEXcaQpvzLt8MBafvxk+FGb6jMkwcv/VGQLs3A18d8yeP4j20HwREF4f0 lvrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=rYLoj+yLB7GjMWg/q4tuituU5yy2PEfLXMj+mo1wAAo=; b=qeMtg9SLY7SfwtcdNGP9cIo5n7ln0za95/uXcXp4+93/713VBNkW9ch9LVf7uO+Jv2 ReA6DL7BsziNObwM6lWGZK8y578V/BluzYvVg9lhqQ0uVFj1CKwJt9h3ZCkF4RPw0DBR O/7K7hkgRr8QARmEEuiwFDoO3PphToxl67J7OCMdeV3hV8h0uFjpXkmWHgy30xnljU64 JpqYQnCsPUM3PyX/Fu8qTdoU85PbAP08uUn2pcYmcIctOepx4CPkUn5Dp58KsMNKRMs4 N7S1DifFZ1QMEY+Ux7/woFU5JPT8Uejt9ckn1RpCm+8bi1u00OBj/rPhGgm1F4MGIhJw Ep3g== X-Gm-Message-State: AOAM532ALASwi86UMdqLthF6S33e1AQghaf1TWrM7q6M/ELNASVS9m05 PU9njtc6k7iATn3WPh5GcjsRYIUM/JE= X-Google-Smtp-Source: ABdhPJz71RV4Ba6eLJl+UIzlsy7sRt8S1SDxmkxfvFW8EBweohdF2enXzsgFblkrrVd1sbKN/GDDmg== X-Received: by 2002:a17:902:e141:b029:12c:68bb:8ea3 with SMTP id d1-20020a170902e141b029012c68bb8ea3mr7908674pla.78.1627760219570; Sat, 31 Jul 2021 12:36:59 -0700 (PDT) Received: from smtpclient.apple ([2600:381:4c2e:4053:d8c2:6822:6e23:d256]) by smtp.gmail.com with ESMTPSA id x24sm6462980pff.175.2021.07.31.12.36.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jul 2021 12:36:58 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Dino Farinacci Mime-Version: 1.0 (1.0) Date: Sat, 31 Jul 2021 12:36:56 -0700 Message-Id: References: <6E864AAE-D3B8-435A-A007-8381A9A056FA@tzi.org> Cc: tools-discuss@ietf.org In-Reply-To: <6E864AAE-D3B8-435A-A007-8381A9A056FA@tzi.org> To: Carsten Bormann X-Mailer: iPhone Mail (19A5307g) Archived-At: Subject: Re: [Tools-discuss] Blinking "speaking" circles -- Re: MeetEcho Feature Request X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 19:37:05 -0000 I can go for that.=20 Dino > On Jul 31, 2021, at 8:09 AM, Carsten Bormann wrote: >=20 > =EF=BB=BFOn 2021-07-31, at 00:42, Dino Farinacci wro= te: >>=20 >>> The blinking yellow dot is great to see who is talking. >=20 > No, it=E2=80=99s not. >=20 > It blinks every two seconds. That is way too slow in an animated exchange= . >=20 > Make it be visible all the time someone is speaking, it might still have s= ome slow animation to it is attracting attention a little. >=20 > (It also is on top of the picture, which is counterproductive. > Maybe run a ripple through the background color behind the name=E2=80=A6) >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 From nobody Sat Jul 31 15:30:18 2021 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF33A1E36; Sat, 31 Jul 2021 15:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki7HgcdXEkiz; Sat, 31 Jul 2021 15:30:02 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 783BA3A1E37; Sat, 31 Jul 2021 15:30:02 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id mz5-20020a17090b3785b0290176ecf64922so26055519pjb.3; Sat, 31 Jul 2021 15:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=9YFAYIEnfRgygFLp3hFky3oTN7wrXbZIcKkG8Knq0Ps=; b=o+l5xWWHWmCpjz6Pc4weUQLMj9iOI5SBF/atQ5AlAZg5kvaJeHLfMzlUnL0JePiMUS A2MzW2SOte425jpcgzhBWOb0W2zNdxzq07ceEq4tWxdW8LqvJdZo+RX36Pe3LakniWXy ovB9gTUDuSN3SpAO4h7xGAtbnhq0daKvIY17MfMBfhK48b6uAwEr8jHYHnhHXDEoZ002 TZmB4tYEe5UAhtuhSDeUxq/L0qCFdOXWoNw+cRYAERvloYQqJZBF9APIiknO7i/TrDm1 SGUQgVxzXoEJlpAPmpaKiUeVwL2Av0/qoE1IzeRDXtQfAQsA0D2JLJYbyYn+KmKnq3CX nsYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=9YFAYIEnfRgygFLp3hFky3oTN7wrXbZIcKkG8Knq0Ps=; b=a2iCF8QYrjFPwGUNn3pgn1CRPbOxIFttebNLBUL5yotXTyh9JekEtZojWOPaAHrGox Uh62N1OqwgVbIG90lZ7GveqwmJ8uSUIbstDlmk1QISulHvP5f3cmZvjZrXg/nlI7Gzbo LGVnxXfTtpzi/xUu7FYlLmqko581JEBxK8pafEDMbAnb6HKVDP6zr8vNm9UcGei0lHWj 0ehiioQTZIktQqhGP8L/3DpnXCCfGZnn9j4BEcWDDXLFm43p1T3tQ/2tnam/mj2DZNB7 rKzrNJd5hMTAKX9NzSuNfv7gCT4L7AZtu+3o1Re/WoDj8OmLGiYFVzF3ZGlK+2HYlgSW 7rRg== X-Gm-Message-State: AOAM530yOwMkh8vd+tCqfI7kt+9qvmZrSwMo0PuYGHCtIYDGASt75QYa BpdLydv1A6+FaAl1c/UWMgfdh5ynwoFX1Q== X-Google-Smtp-Source: ABdhPJxh+5N/nZxMERTa+eo9tnIIGwbuBqGBcUT2jqoeDARMERPAD/el6e7cfc4RDkT65vgQ/b4MSA== X-Received: by 2002:a17:90a:fa14:: with SMTP id cm20mr10046591pjb.67.1627770600813; Sat, 31 Jul 2021 15:30:00 -0700 (PDT) Received: from ?IPv6:2406:e003:1188:5b01:80b2:5c79:2266:e431? ([2406:e003:1188:5b01:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y15sm7507723pga.34.2021.07.31.15.29.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 31 Jul 2021 15:30:00 -0700 (PDT) To: tools-discuss@ietf.org, emo-dir@ietf.org From: Brian E Carpenter Message-ID: <407cb4bb-b1f3-b991-e198-0a04b1f6bd1b@gmail.com> Date: Sun, 1 Aug 2021 10:29:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tools-discuss] Tools info on the main IETF web site X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2021 22:30:07 -0000 Who keeps an eye on the tools material on the IETF web site? While trying to assist a possible new contributor, I fell upon: https://www.ietf.org/about/participate/tutorials/process/creating-internet-drafts-and-rfcs/ which looks badly in need of a refresh to me. For example, it misses the excellent tutorial at: https://datatracker.ietf.org/meeting/104/materials/slides-104-edu-sessf-how-to-create-an-internet-draft-using-xml-or-markdown-markdown-01 We can have the best tools in the world, but they are no good to newcomers unless the main IETF web site is actively maintained. Regards Brian