From nobody Fri Jul 3 05:35:23 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E360D1B2ECF for ; Fri, 3 Jul 2015 05:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jNgCZbL2z_Od for ; Fri, 3 Jul 2015 05:35:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611F21B2ECE for ; Fri, 3 Jul 2015 05:35:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 31F33BE3F; Fri, 3 Jul 2015 13:35:19 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wS85F9xkxdgO; Fri, 3 Jul 2015 13:35:19 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0E81FBE35; Fri, 3 Jul 2015 13:35:19 +0100 (IST) Message-ID: <55968186.50702@cs.tcd.ie> Date: Fri, 03 Jul 2015 13:35:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "tools-discuss@ietf.org Discussion" , Glen References: <55967FD3.3080805@cs.tcd.ie> In-Reply-To: <55967FD3.3080805@cs.tcd.ie> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= X-Forwarded-Message-Id: <55967FD3.3080805@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Tools-discuss] Fwd: Re: Proposed Statement on "HTTPS everywhere for the IETF" X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 12:35:22 -0000 Hiya, Please see [1] for my summary of the issues raised in the IETF list discussion of this topic. As you can see, there'll be a few tooling and ietf.org related things that might need tweaking if the IESG agree this statement. So two questions to start: 1) what's missing? what's hard(er) to do? 2) who're the right folks to have in that discussion and is there a good time to meet in Prague to chat f2f about it? Note that there's no expectation from the IESG side that all changes get done in a nanosecond, so no need for any of us to panic:-) And most of it is done already I think. Thanks, S. PS: I'm not subscribed to tools-discuss so please cc me on follow ups. -------- Forwarded Message -------- Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF" Date: Fri, 03 Jul 2015 13:28:03 +0100 From: Stephen Farrell To: ietf@ietf.org Hiya, I went back over the threads on this and extracted these actionable points [1] for either changes to the draft IESG statement or as things to check out wrt tooling. I'll bring up the tooling related stuff on tools-discuss and the IESG will consider the other changes suggested as well as the rest of the wide-ranging discussion (that I've not tried to summarise in [1];-) Please let me know if I've missed something. (Off-list is fine for that if you're just going to send a pointer to an on-list message I missed.) Thanks, Stephen. [1] https://trac.tools.ietf.org/group/iesg/trac/attachment/wiki/HttpsEverywhere/https-everywhere-suggestions.txt On 01/06/15 17:43, The IESG wrote: > Hi All, > > The IESG are planning to agree an IESG statement on "HTTPS Everywhere > for the IETF," please see [1] for the current text. > > We are seeking community feedback on this and welcome assistance > from the community in identifying any cases where a change or > additional guidance is needed to put this into effect. > > The IESG plans to finalise this statement just after IETF-93 in Prague. > > * Please send general feedback intended for discussion to ietf@ietf.org > > * Comments about specific issues arising can be sent to iesg@ietf.org > or tools-discuss@ietf.org as appropriate (use iesg@ietf.org if not sure) > > Regards, > Terry & Stephen (for the IESG) > > [1] https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere > > > From nobody Tue Jul 7 15:39:08 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAF21B29EB for ; Tue, 7 Jul 2015 15:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 ZRHyp9bgEk8d for ; Tue, 7 Jul 2015 15:39:02 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF551B29E9 for ; Tue, 7 Jul 2015 15:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1755; q=dns/txt; s=iport; t=1436308742; x=1437518342; h=from:to:subject:date:message-id:mime-version; bh=3/5i9Og1Dp5wafHerihwWjMKD7g3X9tf/XCaL5JAuGc=; b=kjJpb2TEF3ZvAkFiI6hApuUkwT9JJgbHQjXHS+gJ9J0d4+jOHLoFHBVr EYh9uBFH8IOIEwyI2xgVv1lWkHNx9ISk1RhO+9DuJUTZnRkA4ZY6Uq09J 5+WMXTQBbYiF8PrrFL2pZJxOsxBpDRqkAV3b5x5HSEq/E38yvEiRv5FIr s=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AdBACkVJxV/5pdJa1bgxJUYQW9ZwmBcYdVOBQBAQEBAQEBgQqEKoELAYEADxgEIYggDaZfpiUBAQEBBgEBAQEBARyTb4EUBYwch3wBgiqBUmWHB4F/llsmg3uCNoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,426,1432598400"; d="asc'?scan'208"; a="7814955" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 07 Jul 2015 22:38:59 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t67McxeE011997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 7 Jul 2015 22:38:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 17:38:59 -0500 From: "Fred Baker (fred)" To: "tools-discuss@ietf.org" Thread-Topic: Odd Datum Thread-Index: AQHQuQW2lOulFQrlpk6DDRmvcVsEmw== Date: Tue, 7 Jul 2015 22:38:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_45AA4500-B517-48DD-B519-B049751AC84E"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [Tools-discuss] Odd Datum X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:39:06 -0000 --Apple-Mail=_45AA4500-B517-48DD-B519-B049751AC84E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm looking at = http://datatracker.ietf.org/doc/search/?sort=3Dstatus&activedrafts=3Don&na= me=3Dv6ops. Let me point you to two drafts in it. draft-ietf-v6ops-siit-eam-01 is listed as a "WG Document". draft-ietf-v6ops-design-choices, which is also a WG Document, is listed = as being "in WGLC", but not as a WG document (a WG can do a last call on = a non-working-group draft). This is new. Looks like a bug. --Apple-Mail=_45AA4500-B517-48DD-B519-B049751AC84E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVZxVAUayAOS/EQ8MAQKrCBAAhKrgZXU8oZluJH1u7jsjz9zNQaYQvBeJ hc1RUnuz2q0VwlS4xr4LR1aF7M9zNvbXQ+vgLTP0dGzBbtxnJ4WJgTW3YJT44UYR HgjZOL4BWPj+KtK3LiQMQ7IZ2kfIcweR8QP43dydprn1gDKuzqcnbxDP1wep+l1i PSe//JgKvkro+GdoJzezgK/0hOBcgBeHQXVnQgw7XZzT/qbrQLpnIcBuo3Ftl5pt 1rkahBrgeub0eQ68ratX06QZU8UYTVVordvQp07BnU0rUlwyP7SWm+7IislDh0V3 FOooOLXXLMSma1fJsXKsuM9kqk7yIaAY7a6jmw2otWsr6fXQ2N5F3LkgsdwnVSHm 6H5iyB0JKKdDZQ8zsKVpjI2y6ASKmUsP2o0oSSVwNl2dp3zUeTLUOUB5/69Ibhdo fznGefzZHSZJIHPX1PzykiC0p8drMBwOqZqrDE7BKVbjvbQhcKrVHBf/H5x7BEjg HeamDZEvvOgGVIuh4DBKpguVTWFwIx72ftNBb5D63heaSnNl28DaECSdHjof6TFz pOlgYsZf4CRHCL8kvDPmKwloWLOQ+BJl3UwJJWHj2uWzqyWsqP9apREDeGTq0qqV SwmLhKm25i6dG2iIG7sdw2hlA2dlEHRTmVTHzyIre1NoPBlDl5q3625Nav/7eOk8 zmeF4wgVRig= =Q9PI -----END PGP SIGNATURE----- --Apple-Mail=_45AA4500-B517-48DD-B519-B049751AC84E-- From nobody Tue Jul 7 15:48:01 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F271B2A0F for ; Tue, 7 Jul 2015 15:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 HvAlNeMUYZYl for ; Tue, 7 Jul 2015 15:47:58 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727421B2A09 for ; Tue, 7 Jul 2015 15:47:55 -0700 (PDT) Received: from [172.16.21.103] (cpe-98-122-46-16.sc.res.rr.com [98.122.46.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 4A13DF627 for ; Tue, 7 Jul 2015 18:47:47 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 7 Jul 2015 18:47:54 -0400 To: Tools-discuss@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3059\)) X-Mailer: Apple Mail (2.3059) Archived-At: Subject: [Tools-discuss] TLS Forward Secrecy X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 22:47:59 -0000 I am working on an update for the IETF app and testing it in a = pre-release of iOS 9. Apple has enabled much stricter TLS default = settings in iOS 9 and OSX El Capitan. Currently, I have to set = NSTemporaryExceptionRequiresForwardSecrecy to NO in order to make a TLS = connection to any of the tools or datatracker IETF sites. =46rom the = Apple docs, this appears to mean that the site I am connecting to = doesn=E2=80=99t support Forward Secrecy and so I have to put in an = exception to not require this. If I don=E2=80=99t, the TLS connection = fails. Does anyone know if the current TLS settings are intentional with = respect to forward secrecy? An example URL that I am talking about is: = https://tools.ietf.org/wg/v6ops/charter.txt Thanks, Tom From nobody Tue Jul 7 16:34:35 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B23AA1B2A3C for ; Tue, 7 Jul 2015 16:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 banEaN11kiIc for ; Tue, 7 Jul 2015 16:34:33 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (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 334661B2A5F for ; Tue, 7 Jul 2015 16:34:33 -0700 (PDT) Received: by ykcp133 with SMTP id p133so5948951ykc.1 for ; Tue, 07 Jul 2015 16:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SIlj32X1N6IXhW9wY62L3exM7En0XP3PqyBaZVCVIbY=; b=0NhzzTpddkye1U6td/t8esTKcIAMAe4eEqZwpuE159Cf4+87KmLP7AK6I7cHdiatCE zP6Edq7/G/jPJNPrZiTqIxKUPPfn3lC4hKAnbqPZw4ksnjZPDqFOdMUcATYPAeKFEdFS Pp2WZYTB27Hr0TnC6tm+2YZKR4E6mkx1kkkqWxAyrN+s0U1fdAGgXIgEHQx01edD7YZ5 swizGYiE1T3IhJuKRLh20ka+yDdY6wyjSFt76rkiDvSI9JHOES76OZr//vorWi+Ff6C+ RiMhSMtym6WT0T37iKXmvB+AznpQiyQ+PKUfa+RFlpU+Y5H76BWUlMsJkba47GTiqrAS lujA== MIME-Version: 1.0 X-Received: by 10.129.97.5 with SMTP id v5mr7995701ywb.56.1436312072615; Tue, 07 Jul 2015 16:34:32 -0700 (PDT) Received: by 10.129.110.138 with HTTP; Tue, 7 Jul 2015 16:34:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 7 Jul 2015 16:34:32 -0700 Message-ID: From: Martin Thomson To: Tom Pusateri Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] TLS Forward Secrecy X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 23:34:34 -0000 On 7 July 2015 at 15:47, Tom Pusateri wrote: > Does anyone know if the current TLS settings are intentional with respect to forward secrecy? I connected to tools.ietf.org using PFS. SSLlabs shows lots of ECDHE options: https://www.ssllabs.com/ssltest/analyze.html?d=tools.ietf.org&s=64.170.98.42&hideResults=on From nobody Tue Jul 7 17:23:21 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CD01B2C0D for ; Tue, 7 Jul 2015 17:23:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 CoC72S1PZ-Or for ; Tue, 7 Jul 2015 17:23:19 -0700 (PDT) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 099E31B2C00 for ; Tue, 7 Jul 2015 17:23:19 -0700 (PDT) Received: by pacgz10 with SMTP id gz10so47578168pac.3 for ; Tue, 07 Jul 2015 17:23:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D73UPweb2+SPzzH8qMUaLplQpefKmJGVQaJ5o/26AhA=; b=RUUu6gpMdHEMo+ANFu4imgjdFvggHrnQMOxqOp468dqGgW5a2ThUIYvchJ4m5DJrjc pw1Lys+mAcg4D9xWZD1MuZD5y/kw2NqO1QrXVlmNRYy1z6BtxiNcqpS0MJYIZqWpMlbK BiP1tkTZ35yjjvPoL/0XajfzN1/pWNDDqUf7Gpb1VyE4/dyqDHIoT7PSDvIBLEIXQ6Tl UUm0fGBzSkvrYIzNcmm/a14zmRfpFIIIqOrct4lsMft/j8VDdi8bCQ9p/ibTrWE/K8fE PHA8fYe79uVznwTe/jhE5Gwd6ChnDTJ6JKxvnXsQ9xY5prtF9+o78C9EpPrXWwSzHLz5 6aqw== X-Gm-Message-State: ALoCoQmXg9c202+72kRUfV75uAxi+NOlp5SwC4UFNwh1mOKvkkIKJgpeC3lRPGIRRKrhlCpha2X2 X-Received: by 10.68.88.33 with SMTP id bd1mr14287212pbb.124.1436314998682; Tue, 07 Jul 2015 17:23:18 -0700 (PDT) Received: from tamias.lan (S0106185933484486.vc.shawcable.net. [174.6.214.147]) by smtp.googlemail.com with ESMTPSA id pb6sm309506pbc.75.2015.07.07.17.23.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 17:23:17 -0700 (PDT) Message-ID: <559C6D74.8010702@thaumas.net> Date: Tue, 07 Jul 2015 17:23:16 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] TLS Forward Secrecy X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 00:23:20 -0000 On 2015-07-07 3:47 PM, Tom Pusateri wrote: > Does anyone know if the current TLS settings are intentional with respect to forward secrecy? SSL Labs reports no forward secrecy for some recent browsers, including Android 5. I.e. they don't negotiate to ecdhe. Maybe something similar is happening with the iOS 9 client stack? https://www.ssllabs.com/ssltest/analyze.html?d=tools.ietf.org&s=64.170.98.42 https://developer.android.com/about/versions/android-5.0-changes.html#ssl -r From nobody Tue Jul 7 20:36:25 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0B11B2E0F for ; Tue, 7 Jul 2015 20:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 u_9PtVcE0xDI for ; Tue, 7 Jul 2015 20:36:23 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6C7D1B2DBC for ; Tue, 7 Jul 2015 20:28:01 -0700 (PDT) Received: from dark.mountain2sea.com (cpe-98-122-46-16.sc.res.rr.com [98.122.46.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 265BAF689; Tue, 7 Jul 2015 23:27:51 -0400 (EDT) Message-ID: <559C98D0.4070903@bangj.com> Date: Tue, 07 Jul 2015 23:28:16 -0400 From: Tom Pusateri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ralph Giles , tools-discuss@ietf.org References: <559C6D74.8010702@thaumas.net> In-Reply-To: <559C6D74.8010702@thaumas.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] TLS Forward Secrecy X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 03:36:24 -0000 On 07/07/15 20:23, Ralph Giles wrote: > On 2015-07-07 3:47 PM, Tom Pusateri wrote: > >> Does anyone know if the current TLS settings are intentional with respect to forward secrecy? > SSL Labs reports no forward secrecy for some recent browsers, including > Android 5. I.e. they don't negotiate to ecdhe. Maybe something similar > is happening with the iOS 9 client stack? > > https://www.ssllabs.com/ssltest/analyze.html?d=tools.ietf.org&s=64.170.98.42 > https://developer.android.com/about/versions/android-5.0-changes.html#ssl > > -r > > Thanks, I'll do some more testing and try to figure out what iOS 9 doesn't like about it. Tom From nobody Tue Jul 7 20:44:17 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 189111B2E25 for ; Tue, 7 Jul 2015 20:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 FmHKDyFGw-sf for ; Tue, 7 Jul 2015 20:44:15 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0DB1B2E21 for ; Tue, 7 Jul 2015 20:44:15 -0700 (PDT) Received: from [172.16.21.103] (cpe-98-122-46-16.sc.res.rr.com [98.122.46.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 23826F693; Tue, 7 Jul 2015 23:44:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3059\)) From: Tom Pusateri In-Reply-To: <559C98D0.4070903@bangj.com> Date: Tue, 7 Jul 2015 23:44:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2F493E78-F7BF-40D5-9645-518D0C85B897@bangj.com> References: <559C6D74.8010702@thaumas.net> <559C98D0.4070903@bangj.com> To: Ralph Giles , "tools-discuss@ietf.org Discussion" X-Mailer: Apple Mail (2.3059) Archived-At: Subject: Re: [Tools-discuss] TLS Forward Secrecy X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 03:44:16 -0000 > On Jul 7, 2015, at 11:28 PM, Tom Pusateri wrote: >=20 > On 07/07/15 20:23, Ralph Giles wrote: >=20 >> On 2015-07-07 3:47 PM, Tom Pusateri wrote: >>=20 >>> Does anyone know if the current TLS settings are intentional with = respect to forward secrecy? >> SSL Labs reports no forward secrecy for some recent browsers, = including >> Android 5. I.e. they don't negotiate to ecdhe. Maybe something = similar >> is happening with the iOS 9 client stack? >>=20 >> = https://www.ssllabs.com/ssltest/analyze.html?d=3Dtools.ietf.org&s=3D64.170= .98.42 >> = https://developer.android.com/about/versions/android-5.0-changes.html#ssl >>=20 >> -r >>=20 >>=20 > Thanks, I'll do some more testing and try to figure out what iOS 9 = doesn't like about it. >=20 > Tom >=20 Looks like this was a false alarm. It must have been a bug in the first = beta release of iOS 9. The second beta release is working fine without = the need for an exception. Tom From nobody Tue Jul 7 21:03:43 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A361B2E45 for ; Tue, 7 Jul 2015 21:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 xCpT2EWCHN3z for ; Tue, 7 Jul 2015 21:03:41 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (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 059131B2E3E for ; Tue, 7 Jul 2015 21:03:40 -0700 (PDT) Received: by pabvl15 with SMTP id vl15so124082650pab.1 for ; Tue, 07 Jul 2015 21:03:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Qv3X7MCog2onBkmgt8X3ZLfPjleDNzAUGUvjfD8z+tA=; b=TvdDdkT5h1tRut5XfR3bgl3Jw3gJVlz5aUeq2TPtxYTWj8ba2G6nH2VpGobdxEl+CW RlfurEe5R3v523YVobz+99POoi8PBeedlOYJp5QxaqySH+w1+ypkU/82qRVDxZjppmTe 1ArJMa8zyZbQ82VY9jRyuDFVMkW4d3K9jNfPdYkROfR5/CDY/LodWEvjoUS8dtzlO31P 8YewD/yYX0+1crImYwqOzAMZhkEU4fp1/aOXd1nFm2xgrqyWE1g6lodRpI/CwNejXQEJ W+Ehc/MXXozF4qdttmJuGVQnDDtkVqKy1Ka0uQ5Egi4/Tw9ti4Bjl06h4T5s1Dx8Hp2Q xU3w== X-Gm-Message-State: ALoCoQmAj/KUoEDiSHTxGbtRP1uAMxGQm/7IHUI/uYNNPBA4ys2mjNCGnwrIe909zHjuJcjevchs X-Received: by 10.66.165.8 with SMTP id yu8mr15988957pab.82.1436328220567; Tue, 07 Jul 2015 21:03:40 -0700 (PDT) Received: from tamias.lan (S0106185933484486.vc.shawcable.net. [174.6.214.147]) by smtp.googlemail.com with ESMTPSA id k5sm712258pdn.10.2015.07.07.21.03.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Jul 2015 21:03:39 -0700 (PDT) Message-ID: <559CA11B.9000402@thaumas.net> Date: Tue, 07 Jul 2015 21:03:39 -0700 From: Ralph Giles User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tom Pusateri , "tools-discuss@ietf.org Discussion" References: <559C6D74.8010702@thaumas.net> <559C98D0.4070903@bangj.com> <2F493E78-F7BF-40D5-9645-518D0C85B897@bangj.com> In-Reply-To: <2F493E78-F7BF-40D5-9645-518D0C85B897@bangj.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] TLS Forward Secrecy X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 04:03:43 -0000 On 2015-07-07 8:44 PM, Tom Pusateri wrote: > Looks like this was a false alarm. [...] > The second beta release is working fine without the need for an exception. Excellent, thanks for following up. Now, we just need to fix the the Android 5 issue! -r From rfc.webm.mime@chrisrebert.com Tue Jul 7 23:36:29 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071E81B3140 for ; Tue, 7 Jul 2015 23:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 0HqJBPim7bdN for ; Tue, 7 Jul 2015 23:36:28 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 338931B313F for ; Tue, 7 Jul 2015 23:36:28 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9B3AC20389 for ; Wed, 8 Jul 2015 02:36:27 -0400 (EDT) Received: from web6 ([10.202.2.216]) by compute3.internal (MEProxy); Wed, 08 Jul 2015 02:36:27 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=chrisrebert.com; h=content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=hSf /TFKz5CAwJDJgEWX2l7WePVE=; b=CUCLnw9CuWRqsy+LsKgVOjMy/wMZr+gfH+N 9FEROtA/uExINrZhNCoicdvhADPU/M7ZTxI9DLf6lYPyvNLjOjthneyzv5BBmi15 BnSJPQmEstbF/dX0FaOuyF/wMrOjgkovELxDuB/MHim1ctyiIH9PrMtfL7LxVy7/ 2MYW4udY= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=hSf/TFKz5CAwJDJgEWX2l7WePVE=; b=mUdUz M2X5vBvdTPb2rmm9cH4YUU47WcEsvg/0D9+ZtTp9nOdo3NuEPR1LoF4GTI32VfEZ wDIhHJ0E5qTZsqroLDnB0g/3xJgpy512ZiziHh9JvP1X5iD/rN44DYivmQrEPtwl bdjdfWH4BQmQ2rE+stIpYszfnisbJBta9iaHQo= Received: by web6.nyi.internal (Postfix, from userid 99) id 5DED650980; Wed, 8 Jul 2015 02:36:27 -0400 (EDT) Message-Id: <1436337387.3578654.318040777.1D23759F@webmail.messagingengine.com> X-Sasl-Enc: ngJJhxPbnNeXVMxI6noQL2TMN62diUMBeqN+f4sm3juc 1436337387 From: Chris Rebert To: tools-discuss@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-bfc056ae Date: Tue, 07 Jul 2015 23:36:27 -0700 Archived-At: Subject: [Tools-discuss] Idnits-2.13.02 feedback: Apostrophe bug in helpmsg X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 06:39:38 -0000 Hello, Part of the message output by `idnits --help` reads: > --nowarn Don\047t issue warnings, only ID-nits violations There should obviously be an apostrophe instead of the 4 characters "\047". Presumably this was a minor oversight from when the usage() AWK function was copied and translated into bash as the helpmsg() function. Line 3528 of the helpmsg() bash function can and should just use a literal apostrophe in its source code. Cheers, Chris From nobody Wed Jul 8 01:31:06 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C2F1B328E for ; Wed, 8 Jul 2015 01:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WKyi6FXo51qN for ; Wed, 8 Jul 2015 01:31:02 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707D91B328D for ; Wed, 8 Jul 2015 01:31:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,430,1432623600"; d="asc'?scan'208";a="53282912" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 08 Jul 2015 01:30:41 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 8 Jul 2015 01:30:41 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::6843:58b6:e8e4:4968%21]) with mapi id 15.00.1076.000; Wed, 8 Jul 2015 01:30:41 -0700 From: "Eggert, Lars" To: "tools-discuss@ietf.org Discussion" Thread-Topic: W3C Validator Suite Thread-Index: AQHQuVhf5B+0mb1iIUmjo0vfws9AcA== Date: Wed, 8 Jul 2015 08:30:40 +0000 Message-ID: <29CC57B1-891D-44CA-A044-B59EF6284B94@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_99492427-68CC-4AD9-8A30-037097EE6E7F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Subject: [Tools-discuss] W3C Validator Suite X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 08:31:04 -0000 --Apple-Mail=_99492427-68CC-4AD9-8A30-037097EE6E7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, do we have access to the W3C Validator Suite = (https://validator-suite.w3.org/) for validating IETF pages? If not, = could we set up a friendly deal with them? (Want to check during codesprint that the various facelifted datatracker = pages are valid HTML5.) Lars --Apple-Mail=_99492427-68CC-4AD9-8A30-037097EE6E7F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlWc360ACgkQIWcjmsUTWRpxPQCcCYlOxb/ApwENJqK5qs1uPvLk Mv8AoJbm6w5IZ+SbyfTk5Vx9M5RGvQ0S =By6y -----END PGP SIGNATURE----- --Apple-Mail=_99492427-68CC-4AD9-8A30-037097EE6E7F-- From nobody Thu Jul 9 05:06:49 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F3E1A8FD2 for ; Thu, 9 Jul 2015 05:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 luzO8RRj8oFe for ; Thu, 9 Jul 2015 05:06:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 CD6671A89E9 for ; Thu, 9 Jul 2015 05:06:46 -0700 (PDT) Received: from h205n24-s-oev-a31.ias.bredband.telia.com ([78.68.120.205]:53734 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZDAbF-0002G7-PY; Thu, 09 Jul 2015 05:06:46 -0700 Message-ID: <559E63C2.8070802@levkowetz.com> Date: Thu, 09 Jul 2015 14:06:26 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Eggert, Lars" , "tools-discuss@ietf.org Discussion" References: <29CC57B1-891D-44CA-A044-B59EF6284B94@netapp.com> In-Reply-To: <29CC57B1-891D-44CA-A044-B59EF6284B94@netapp.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="oLbcv1D9ER2ETDAXx4F0kKAbJFST4kOaR" X-SA-Exim-Connect-IP: 78.68.120.205 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, lars@netapp.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Subject: Re: [Tools-discuss] W3C Validator Suite X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 12:06:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oLbcv1D9ER2ETDAXx4F0kKAbJFST4kOaR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Lars, On 2015-07-08 10:30, Eggert, Lars wrote: > Hi, >=20 > do we have access to the W3C Validator Suite > (https://validator-suite.w3.org/) for validating IETF pages? If not, > could we set up a friendly deal with them? I don't know if we have access -- anybody else? > (Want to check during codesprint that the various facelifted > datatracker pages are valid HTML5.) Right.=20 FWIW, at the time I merged in your Facelift, I also added html5 verificat= ion to the test-crawler, using html5lib's parser in strict mode. In all case= s where it has reported html errors, the error matches what the w3c validator say= s, but the w3c validator also reports warnings which the html5lib parser doesn't= say anything about. If you'd like to add in some degree of validation using the w3c validator= -suite, I'd suggest hooking it in next to the html5lib validation in bin/test-cra= wl (in check_html_valid()). It tries to only validate one sample of a given= kind of URL, so that the extra runtime cost of validation doesn't hit us too h= ard. Best regards, Henrik --oLbcv1D9ER2ETDAXx4F0kKAbJFST4kOaR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVnmPCAAoJEE6bV0uPuxcaGUQP/3i6x618jp2wCwP1PwNsEPwG uuwSD/bri63trqcVmxi2fa4FM3OpPS1Sa3kvh4eYx8OtTHaJLJCOOymR7QxGvGGm SsiOMPYa8zs67zHWtwCPcJJ2lQQ42uJkDzoE/pIEyXQG6i2zsy8DTkfaMEGaKqTW wtlrWKuoQi3XN8liV02og5BvxRHwiRdR++rrertObuNb9wu/wT/amJNJPkPdXVUy RzxMeaRa7wVsNjyChH9dGPYZAyzUPNjWQFi41Ca9XwbkiO23DzHLbjzKjnBB7hlY uJHpNrj47sVjTe2WIDTkn1bCtZcQMQR3mBJHc17OvcOUCne3acKjXawZxjCc+CR6 WGCpl6YjU+dxKvJT0/XtQjXo/GzZ5DsAmYAaRhzrDue9acUYUjxfPygkXyEATaUF zTWlsZiCfGx03hKDKevb9smjkJLd375O4GbLRV5to2BWABbU+LLa6fCMrV373V0D RHMGXECjnR18ArbIbwznzOib5No/a9e3FpqlT4UGt3wkxDEayfv83l29xzrCPkNS JVOa5SZxPeqSjnlTpqYoBIXAVRw96F00FxTwJdWms2kPsckrIqZbYJseXFFtI1+F sOKfsZ2oBvnqtBWvhCSAbQvBSgRfrHpPOYZSSSZRwyQ/EfUbDLDfgZRp0ltEhbZp HW+WEjnkie8kiw1RAyQQ =6HVP -----END PGP SIGNATURE----- --oLbcv1D9ER2ETDAXx4F0kKAbJFST4kOaR-- From nobody Thu Jul 9 05:58:33 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6701AD36E for ; Thu, 9 Jul 2015 05:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 WjE7DAfYMNRS for ; Thu, 9 Jul 2015 05:58:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 8F8C11AD369 for ; Thu, 9 Jul 2015 05:58:30 -0700 (PDT) Received: from h205n24-s-oev-a31.ias.bredband.telia.com ([78.68.120.205]:60702 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZDBPJ-0004LH-AZ; Thu, 09 Jul 2015 05:58:29 -0700 Message-ID: <559E6FE1.8050908@levkowetz.com> Date: Thu, 09 Jul 2015 14:58:09 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Chris Rebert , tools-discuss@ietf.org References: <1436337387.3578654.318040777.1D23759F@webmail.messagingengine.com> In-Reply-To: <1436337387.3578654.318040777.1D23759F@webmail.messagingengine.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gDpRF2cbiEgDcTn9OeEjVdjhRns8rdWqL" X-SA-Exim-Connect-IP: 78.68.120.205 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, rfc.webm.mime@chrisrebert.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Subject: Re: [Tools-discuss] Idnits-2.13.02 feedback: Apostrophe bug in helpmsg X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 12:58:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gDpRF2cbiEgDcTn9OeEjVdjhRns8rdWqL Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Chris, On 2015-07-08 08:36, Chris Rebert wrote: > Hello, >=20 > Part of the message output by `idnits --help` reads: >> --nowarn Don\047t issue warnings, only ID-nits violatio= ns >=20 > There should obviously be an apostrophe instead of the 4 characters > "\047". >=20 > Presumably this was a minor oversight from when the usage() AWK > function was copied and translated into bash as the helpmsg() > function. > Line 3528 of the helpmsg() bash function can and should just use a > literal apostrophe in its source code. Thanks. Fixed in my source, will be part of the next release. Best regards, Henrik --gDpRF2cbiEgDcTn9OeEjVdjhRns8rdWqL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVnm/hAAoJEE6bV0uPuxcaGYgQAL13UIw1IRvA3voG+iFQCaFw FCYSVEfTF6niJumG3oqR3us5c9V2uOzZL0Pgk7aDdFpeWAUABKEQuRDaChbNcBFk mFJlHYkeC460tfO6YdWe0/GSypbQA+Fh6vP+P8MhIEvZnT2mNXVnMCOMN3Xaf7C5 bctZeHZGQp5YSJzVNa8RTSZC6gX+aPsXbUYTUs5rNUeXMQ6/R7nc9jJR96b3As6p Byl6UnLFR0MOarbkg2P8s3WLYPuBGQp1bzcEkHVge+0y5n0zhDpICweaWsQ2uly5 B/iDSrrZU0HnmPb0pSjR4uDxCrcYxGB4syTvPfJ0od3zsWoUbgFU2K2Mcjw6riF4 KVdJ8Thtx5ogtQHYO1kZMFK6akAoNWfDPPTHzNXsUSLWgiMEOAJC+Ki1e8iBVlNp fMLhCN6sSCGqyQ3KKU2F29v4MeU0mttA9Eabfnkj+xAqIUTaUJhN8aupsO0Pi7hd dXfmY2eCJPuV7iW6EjrlZuvyppHRS5r7sNRyBc0ETwNYSNE74mdVIbxBM2xi0dUR UDkCrZjpZQhMNdxrygrydcIH59V2SFs/GLGGMUNrfPFW+JQ6Ly+DJjl/cMBfNFuY Hq7A7q6ZLlxHWnVhz4W+7QD/Eev/WaHeu9k1hwzlZ1CKiiYCypRR+Hq7T0KS78YN 9MDAvPYbrikh8L6tAIuB =XNvq -----END PGP SIGNATURE----- --gDpRF2cbiEgDcTn9OeEjVdjhRns8rdWqL-- From nobody Thu Jul 9 06:25:33 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7AD1A9078 for ; Thu, 9 Jul 2015 06:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] autolearn=ham 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 EGzKrnWa1Z5K for ; Thu, 9 Jul 2015 06:25:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B3A591A9072 for ; Thu, 9 Jul 2015 06:25:30 -0700 (PDT) Received: from h205n24-s-oev-a31.ias.bredband.telia.com ([78.68.120.205]:63972 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZDBpS-0002z6-1I; Thu, 09 Jul 2015 06:25:30 -0700 Message-ID: <559E7636.3040608@levkowetz.com> Date: Thu, 09 Jul 2015 15:25:10 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Fred Baker (fred)" , "tools-discuss@ietf.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XlAvaKAPQRP7B1vRgdxOdmMC2PsIwtLmx" X-SA-Exim-Connect-IP: 78.68.120.205 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, fred@cisco.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Subject: Re: [Tools-discuss] Odd Datum X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 13:25:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XlAvaKAPQRP7B1vRgdxOdmMC2PsIwtLmx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Fred, On 2015-07-08 00:38, Fred Baker (fred) wrote: > I'm looking at http://datatracker.ietf.org/doc/search/?sort=3Dstatus&ac= tivedrafts=3Don&name=3Dv6ops. >=20 > Let me point you to two drafts in it. >=20 >=20 > draft-ietf-v6ops-siit-eam-01 is listed as a "WG Document". >=20 > draft-ietf-v6ops-design-choices, which is also a WG Document, is listed= as being "in WGLC", but not as a WG document (a WG can do a last call on= a non-working-group draft). >=20 > This is new. Looks like a bug. Both "WG Document" and "In WG Last Call" are WG document states: http://zin.tools.ietf.org:31417/help/state/draft/ietf taken from: https://tools.ietf.org/html/rfc6174 specifically https://tools.ietf.org/html/rfc6174#section-4.2.4 and https://tools.ietf.org/html/rfc6174#section-4.2.7 How would you suggest we improve the presentation and/or state names in o= rder to make the datatracker search page you refer to clearer/better? Should there maybe be a differently named state for last calls on non-WG = documents? Henrik --XlAvaKAPQRP7B1vRgdxOdmMC2PsIwtLmx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVnnY2AAoJEE6bV0uPuxcaKNwP/iIAjoU2IrOHSmErcAniZxr2 VX1+IG/2pLYlWk+1kazcbSBj1kBGC7ipJwbd+2E5aPT/b1WOQhbDyXCRCStapRXJ eR1cE2nKjNA0pOtp3Zc6/93Imk4RD+QK5RNWIxW+ODOmriimiokr8zhvQgkN6JQs rDwFQ0+ghfh7aiBruEKzgCgTRzP7YIzyqh8yDNyE7oiOPxb7rTT8w4RCI5b3rrux A9Oz7SANcbNA5Ap/tLe2T/enYVfnI3ljs74x5+ED6tlN6UW+m+JASX5iGLbyfKhG 7KMuVs2y24Fou5mPVWKZxysq8BxfscJi2yIR82oeiXgwmY/iW06na05zwzf4cuKG fmS9V3tDOc+ajYeZxDqDibRW5ZZV/bJhzGde8AfRIMRkhmwakI2dPjvf648P0ijW uws89wABSXswBVBtQO+4UQYPRZZO2Q3qZQoap0kAx0eQXCG9HVn8RtLVzZo5o0fY eiulN9JL0KuI6IynMngrRvOL2qfS5GKs5ULry5JqSTUdUILjKW3NoNT9LaUf6m9e MXb0Ewa1kjL7PKyUJ4ZCdvHS3q8l4H+NmTeyy5rbWhJ3nD23jDdUM7nbYYcJjI8e ILlFj24Z20LFhEqVeEYjEfB3QN2soc1VhmNBEx3l1/ObBbwX/VmjkFIHVuzNay6f CtHupx/3EfTKy3RKNyo2 =T8ra -----END PGP SIGNATURE----- --XlAvaKAPQRP7B1vRgdxOdmMC2PsIwtLmx-- From nobody Thu Jul 9 11:32:56 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE8D1B2AB8 for ; Thu, 9 Jul 2015 11:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.662 X-Spam-Level: * X-Spam-Status: No, score=1.662 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 tGkWjlFBTqxv for ; Thu, 9 Jul 2015 11:32:52 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13F41B2B1A for ; Thu, 9 Jul 2015 11:32:52 -0700 (PDT) Received: from [172.16.1.137] (unknown [64.203.236.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 5E237FA2E for ; Thu, 9 Jul 2015 14:32:37 -0400 (EDT) From: Tom Pusateri Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <778E0CEF-F425-4233-B1FF-03643EC25ADC@bangj.com> Date: Thu, 9 Jul 2015 14:32:51 -0400 To: "tools-discuss@ietf.org Discussion" Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) X-Mailer: Apple Mail (2.3067) Archived-At: Subject: [Tools-discuss] time required to retrieve drafts has increased X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 18:32:54 -0000 Lately, it seems like it takes much longer to retrieve the redirection = for an HTML version of a draft and then for the draft itself. butte-2% time curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =20= =09

The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01.

curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 30.849 total butte-2% time curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =09

The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01.

curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 36.465 total It=E2=80=99s taking on average around 33 seconds to get the redirect to = the appropriate version and then another 6 seconds on average to get the = draft: curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 0.01s user = 0.01s system 0% cpu 6.673 total This seems much longer than it used to be. Any insight? Thanks, Tom= From nobody Thu Jul 9 12:08:30 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955251B2B43 for ; Thu, 9 Jul 2015 12:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham 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 Pwz2qoravwwy for ; Thu, 9 Jul 2015 12:08:26 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD1F1A1EF5 for ; Thu, 9 Jul 2015 12:08:26 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id EA838F984; Thu, 9 Jul 2015 15:08:21 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 5511E2010E; Thu, 9 Jul 2015 15:08:01 -0400 (EDT) From: Daniel Kahn Gillmor To: Tom Pusateri , "tools-discuss\@ietf.org Discussion" In-Reply-To: <778E0CEF-F425-4233-B1FF-03643EC25ADC@bangj.com> References: <778E0CEF-F425-4233-B1FF-03643EC25ADC@bangj.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 09 Jul 2015 15:08:01 -0400 Message-ID: <878uapcfou.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Tools-discuss] time required to retrieve drafts has increased X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:08:28 -0000 On Thu 2015-07-09 14:32:51 -0400, Tom Pusateri wrote: > Lately, it seems like it takes much longer to retrieve the redirection for an HTML version of a draft and then for the draft itself. > > butte-2% time curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp > > >

> The document is available here: http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01. >

> > > curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user 0.01s system 0% cpu 30.849 total > butte-2% time curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp > > >

> The document is available here: http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01. >

> > > curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user 0.01s system 0% cpu 36.465 total > > It’s taking on average around 33 seconds to get the redirect to the appropriate version and then another 6 seconds on average to get the draft: > > curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 0.01s user 0.01s system 0% cpu 6.673 total > > This seems much longer than it used to be. Any insight? I see this lag when accessing 209.208.19.222, but not when accessing 64.170.98.42 or 2001:1890:123a::1:2a. $ time wget -O/dev/null https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp --2015-07-09 15:05:52-- https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp Resolving tools.ietf.org (tools.ietf.org)... 209.208.19.222 Connecting to tools.ietf.org (tools.ietf.org)|209.208.19.222|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 [following] --2015-07-09 15:06:27-- https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 Reusing existing connection to tools.ietf.org:443. HTTP request sent, awaiting response... 200 OK Length: 86603 (85K) [text/html] Saving to: ‘/dev/null’ /dev/null 100%[=====================>] 84.57K 462KB/s in 0.2s 2015-07-09 15:06:29 (462 KB/s) - ‘/dev/null’ saved [86603/86603] real 0m37.591s user 0m0.052s sys 0m0.008s $ time wget -O/dev/null https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp --2015-07-09 15:06:37-- https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp Resolving tools.ietf.org (tools.ietf.org)... 64.170.98.42 Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 [following] --2015-07-09 15:06:45-- https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 Reusing existing connection to tools.ietf.org:443. HTTP request sent, awaiting response... 200 OK Length: 86603 (85K) [text/html] Saving to: ‘/dev/null’ /dev/null 100%[=====================>] 84.57K 47.9KB/s in 1.8s 2015-07-09 15:06:47 (47.9 KB/s) - ‘/dev/null’ saved [86603/86603] real 0m9.116s user 0m0.048s sys 0m0.008s $ So i think it's only one host that has this delay. I'm seeing the delay regardless of whether i have functional reverse DNS on my own IP address. --dkg From nobody Thu Jul 9 12:17:56 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97E71A0011 for ; Thu, 9 Jul 2015 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 H8hFayVUQqwD for ; Thu, 9 Jul 2015 12:17:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 4B8B21A000F for ; Thu, 9 Jul 2015 12:17:53 -0700 (PDT) Received: from h205n24-s-oev-a31.ias.bredband.telia.com ([78.68.120.205]:53645 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZDHKS-00037W-3j; Thu, 09 Jul 2015 12:17:52 -0700 Message-ID: <559EC8C9.3050700@levkowetz.com> Date: Thu, 09 Jul 2015 21:17:29 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Kahn Gillmor , Tom Pusateri , "tools-discuss@ietf.org Discussion" References: <778E0CEF-F425-4233-B1FF-03643EC25ADC@bangj.com> <878uapcfou.fsf@alice.fifthhorseman.net> In-Reply-To: <878uapcfou.fsf@alice.fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pLaqaUsdakMKjNGcx66KdQrqkjiC35L8i" X-SA-Exim-Connect-IP: 78.68.120.205 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, pusateri@bangj.com, dkg@fifthhorseman.net X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Subject: Re: [Tools-discuss] time required to retrieve drafts has increased X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:17:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pLaqaUsdakMKjNGcx66KdQrqkjiC35L8i Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Daniel, Hmm. I see that the host in question is quite heavily loaded. Debugging= =2E Best regards, Henrik On 2015-07-09 21:08, Daniel Kahn Gillmor wrote: > , but not when accessing > 64.170.98.42 or 2001:1890:123a::1:2a. >=20 > $ time wget -O/dev/null https://tools.ietf.org/html/draft-ietf-dmm-fpc-= cpdp =20 > --2015-07-09 15:05:52-- https://tools.ietf.org/html/draft-ietf-dmm-fpc= -cpdp > Resolving tools.ietf.org (tools.ietf.org)... 209.208.19.222 > Connecting to tools.ietf.org (tools.ietf.org)|209.208.19.222|:443... co= nnected. > HTTP request sent, awaiting response... 302 Found > Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 [follo= wing] > --2015-07-09 15:06:27-- https://tools.ietf.org/html/draft-ietf-dmm-fpc= -cpdp-01 > Reusing existing connection to tools.ietf.org:443. > HTTP request sent, awaiting response... 200 OK > Length: 86603 (85K) [text/html] > Saving to: =E2=80=98/dev/null=E2=80=99 >=20 > /dev/null 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 84.57K 462KB/s in 0.2s =20 >=20 > 2015-07-09 15:06:29 (462 KB/s) - =E2=80=98/dev/null=E2=80=99 saved [866= 03/86603] >=20 >=20 > real 0m37.591s > user 0m0.052s > sys 0m0.008s > $ time wget -O/dev/null https://tools.ietf.org/html/draft-ietf-dmm-fpc-= cpdp =20 > --2015-07-09 15:06:37-- https://tools.ietf.org/html/draft-ietf-dmm-fpc= -cpdp > Resolving tools.ietf.org (tools.ietf.org)... 64.170.98.42 > Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:443... conn= ected. > HTTP request sent, awaiting response... 302 Found > Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 [follo= wing] > --2015-07-09 15:06:45-- https://tools.ietf.org/html/draft-ietf-dmm-fpc= -cpdp-01 > Reusing existing connection to tools.ietf.org:443. > HTTP request sent, awaiting response... 200 OK > Length: 86603 (85K) [text/html] > Saving to: =E2=80=98/dev/null=E2=80=99 >=20 > /dev/null 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 84.57K 47.9KB/s in 1.8s =20 >=20 > 2015-07-09 15:06:47 (47.9 KB/s) - =E2=80=98/dev/null=E2=80=99 saved [86= 603/86603] >=20 >=20 > real 0m9.116s > user 0m0.048s --pLaqaUsdakMKjNGcx66KdQrqkjiC35L8i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVnsjKAAoJEE6bV0uPuxca3CoQAKfg5TnULBJFXUGCtnd47Yai 1XYWSuPUobJRPE7BPNz8a8BLmRo0xzPydyFdzQ076eVNMkhmemqTx8MO96hmM7RF TQkHmfiPB3sg4Q8XQaZrqUXlcABXaPb3QRZNW7E+bYDNYL4PMfKxvsZpKVTRkqKw Dw0p5R7YExgwUWc1xsTZEhLDu34OqQu80Lvn9mmQ52txTyTJ6QjEDPu4UzRPCZV6 yVB7xPyyBxFGBuFptMrELX9maJNeu0QIJMqbtLKz3/B7mAPmo0F2LLfsbu8lhPXP rr2Q2pm+hQY4D0eHgD1i0tDEbPPA31X9Pet37fQfMeeHTXezoyWJebTFDWDA27jz IZV2wJkvmsr1St79ErgFKhX8zJkv6i2WE0nThEpaQ43Nr0bPBjqWLY85hHQQMNWQ MpKfbHVSG5co/br3tV1v+Yiu1kprX3fqcbVEu+bamHnlVnFuzpDixQXJ7EtPe4vT a0DdEZ6xabC+U5MyZ81MO7CiGW/paQ5wy18/ee52qgdm6tI+NHYRuNY9reN7WE9H tAqJxrxuA9jxSdVINUtbBD21NoNYS5ik/JXo2d4xRjAsMET6LwsrT3zAtOn/yWGX D6gz0ZeKTCdoTaezAsatqzrRkVE6wYXhr0U+ySd+RfekOCWgPqsJdu6DsgO73fj8 EquOwNAcMMpdg3p/nAt5 =IJ1V -----END PGP SIGNATURE----- --pLaqaUsdakMKjNGcx66KdQrqkjiC35L8i-- From nobody Thu Jul 9 12:18:37 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A05B1A0011 for ; Thu, 9 Jul 2015 12:18:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 FG5L9wtAdWTQ for ; Thu, 9 Jul 2015 12:18:34 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53C01A000B for ; Thu, 9 Jul 2015 12:18:34 -0700 (PDT) Received: from [172.16.1.137] (64.203.236.78.static-pool-1.pool.hargray.net [64.203.236.78]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9FC42FA3D; Thu, 9 Jul 2015 15:18:18 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) From: Tom Pusateri In-Reply-To: <878uapcfou.fsf@alice.fifthhorseman.net> Date: Thu, 9 Jul 2015 15:18:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <849D2D88-97DA-490C-ACE6-CF03D533D48A@bangj.com> References: <778E0CEF-F425-4233-B1FF-03643EC25ADC@bangj.com> <878uapcfou.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3067) Archived-At: Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] time required to retrieve drafts has increased X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:18:36 -0000 > On Jul 9, 2015, at 3:08 PM, Daniel Kahn Gillmor = wrote: >=20 > On Thu 2015-07-09 14:32:51 -0400, Tom Pusateri wrote: >> Lately, it seems like it takes much longer to retrieve the = redirection for an HTML version of a draft and then for the draft = itself. >>=20 >> butte-2% time curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp = =20 >> =09 >> >>

>> The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01. >>

>> >> >> curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 30.849 total >> butte-2% time curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp >> =09 >> >>

>> The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01. >>

>> >> >> curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 36.465 total >>=20 >> It=E2=80=99s taking on average around 33 seconds to get the redirect = to the appropriate version and then another 6 seconds on average to get = the draft: >>=20 >> curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 0.01s = user 0.01s system 0% cpu 6.673 total >>=20 >> This seems much longer than it used to be. Any insight? >=20 > I see this lag when accessing 209.208.19.222, but not when accessing > 64.170.98.42 or 2001:1890:123a::1:2a. >=20 > $ time wget -O/dev/null = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =20 > --2015-07-09 15:05:52-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp > Resolving tools.ietf.org (tools.ietf.org)... 209.208.19.222 > Connecting to tools.ietf.org (tools.ietf.org)|209.208.19.222|:443... = connected. > HTTP request sent, awaiting response... 302 Found > Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 = [following] > --2015-07-09 15:06:27-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 > Reusing existing connection to tools.ietf.org:443. > HTTP request sent, awaiting response... 200 OK > Length: 86603 (85K) [text/html] > Saving to: =E2=80=98/dev/null=E2=80=99 >=20 > /dev/null 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 84.57K 462KB/s in 0.2s =20 >=20 > 2015-07-09 15:06:29 (462 KB/s) - =E2=80=98/dev/null=E2=80=99 saved = [86603/86603] >=20 >=20 > real 0m37.591s > user 0m0.052s > sys 0m0.008s > $ time wget -O/dev/null = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =20 > --2015-07-09 15:06:37-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp > Resolving tools.ietf.org (tools.ietf.org)... 64.170.98.42 > Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:443... = connected. > HTTP request sent, awaiting response... 302 Found > Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 = [following] > --2015-07-09 15:06:45-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 > Reusing existing connection to tools.ietf.org:443. > HTTP request sent, awaiting response... 200 OK > Length: 86603 (85K) [text/html] > Saving to: =E2=80=98/dev/null=E2=80=99 >=20 > /dev/null 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 84.57K 47.9KB/s in 1.8s =20 >=20 > 2015-07-09 15:06:47 (47.9 KB/s) - =E2=80=98/dev/null=E2=80=99 saved = [86603/86603] >=20 >=20 > real 0m9.116s > user 0m0.048s > sys 0m0.008s > $=20 >=20 > So i think it's only one host that has this delay. I'm seeing the = delay > regardless of whether i have functional reverse DNS on my own IP = address. >=20 > --dkg Hmm, I=E2=80=99m at a coffee shop (but this delay was at home too) and = I=E2=80=99m consitently getting a long delay just trying resolve the = address: butte-2% time host tools.ietf.org tools.ietf.org has address 64.170.98.42 tools.ietf.org has address 209.208.19.222 ;; connection timed out; no servers could be reached tools.ietf.org mail is handled by 10 zinfandel.tools.ietf.org. tools.ietf.org mail is handled by 20 gamay.tools.ietf.org. tools.ietf.org mail is handled by 30 merlot.tools.ietf.org. host tools.ietf.org 0.01s user 0.01s system 0% cpu 10.188 total Thanks, Tom From nobody Thu Jul 9 12:50:26 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C382E1A00A0 for ; Thu, 9 Jul 2015 12:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 hNVXlYAaOjiS for ; Thu, 9 Jul 2015 12:50:24 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DB7D1A009B for ; Thu, 9 Jul 2015 12:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2149; q=dns/txt; s=iport; t=1436471424; x=1437681024; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mHMhLEGh8ch+2YnhlLIy7HYeMHIXatzpBbu6rfRYb84=; b=Jf6kMDqLK0ZBGFuNczCo2c5vmp+3WxdeLGgfVDZuwonm2npP9J2qE6qL CiaI8Tgsm9NNESkMoiIYmEOyHrtHNm2/TAV3tpnlKRThdTmOIc3Cm16aD K/Bjt2KNWasgsKjjfwkpBjF9GpMaruZTm/jVY/VmZmoGGL3dqv9bYqP40 c=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BEBQC9z55V/5BdJa1bgxKBNAa7KodoAoFhORMBAQEBAQEBgQqEIwEBAQMBeQULAgEIGC4yJQIEDgUOiBgIz0sBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uFBgeDF4EUAQSMKogDAYIsgVSDRIQ7gT2PHogMJoN7b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="asc'?scan'208";a="166834384" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 09 Jul 2015 19:50:23 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t69JoNx5020012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 19:50:23 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.49]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 14:50:23 -0500 From: "Fred Baker (fred)" To: Henrik Levkowetz Thread-Topic: [Tools-discuss] Odd Datum Thread-Index: AQHQukq8G0apw4HNgki087JKOuTkOp3T4DUA Date: Thu, 9 Jul 2015 19:50:23 +0000 Message-ID: <0FDF4654-1AED-45CE-AF04-7617F8487870@cisco.com> References: <559E7636.3040608@levkowetz.com> In-Reply-To: <559E7636.3040608@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.19.64.123] Content-Type: multipart/signed; boundary="Apple-Mail=_6677AA22-9277-430B-B215-656BB09AFBCE"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tools-discuss@ietf.org" Subject: Re: [Tools-discuss] Odd Datum X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 19:50:25 -0000 --Apple-Mail=_6677AA22-9277-430B-B215-656BB09AFBCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 9, 2015, at 6:25 AM, Henrik Levkowetz = wrote: >=20 > How would you suggest we improve the presentation and/or state names = in order > to make the datatracker search page you refer to clearer/better? >=20 > Should there maybe be a differently named state for last calls on = non-WG documents? My preference: I would like "is a working group document" to be a sticky state that I, = as a working group chair, can change. If a WG document falls out of = favor, I'd like to, without changing the name from draft-ietf-* to = draft--*, be able to change it to some variation on "individual = submission". Within "is a WG document", I'd like a second state that says "in = discussion", "in WGLC", "waiting for update", "waiting on lazy WG = chair", or whatever. --Apple-Mail=_6677AA22-9277-430B-B215-656BB09AFBCE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVZ7QfEayAOS/EQ8MAQJCbhAAxFM5zZkQsHW0Q19qG1mEpOoIINHUITCG JNfZ8tnxwEJfe/sxTN5tVuFvOJj++yJFqXuTG6IuDOnzPh8x27GADSkfJYqLV4Uk R+pF0NElGcIzQH3lipLEqD0fEVsEBq0SNGlRrotuC7cug6WWwZDNrkddsy3eZcDB R+qZm8XL0wX007c2DRbXNw5+4nS6SwFBzT3R5R3tsF9duEJuFfrw1KeKRF7pBWhL PffeKWRAtk7U2s1g0VIIhTl5rvDMFAV1fMPbPL1pJOrh03tNBkeNyYdONFHvibec 3n67oFy/62/WTqC5ROkHbDbTMvzcbealNpty0N0Tesc/XHXnqPIS1AVjZAXE4g9m 4cEEZuQ9qX+Db3A4kkcY7F0clWkpbqyQ1j2/HQde/46aedUjYEsSSZoLhgM4yUXS r+dTs30eD8qyD5VLjq/9Adk17wFygiryDn/CtKmMa6yzHn9FCTpgKLbOUTBet0L5 ik9kZfDUREDsDcIlSiXvS3qzRV0rt/0NKEFJVwZtmAmRFZhKKTn5xUsvCTv4phGc NquCJHPUgd+ynHBSiRqoyviaO1N29q2/KkdDtplwNI3n8DwuJyTA88uV1IBvsx21 us4oxRr8XkwHEwtgR0YXezMDrBfZuBjb9qdtP+2aDkhacK50MSOsAgT1gPnca0Lj 3XTQ7y0lC/g= =dMTh -----END PGP SIGNATURE----- --Apple-Mail=_6677AA22-9277-430B-B215-656BB09AFBCE-- From nobody Thu Jul 9 13:27:50 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32511A0120 for ; Thu, 9 Jul 2015 13:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 dAtCEVRgDRwC for ; Thu, 9 Jul 2015 13:27:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 D1A061A0117 for ; Thu, 9 Jul 2015 13:27:47 -0700 (PDT) Received: from h205n24-s-oev-a31.ias.bredband.telia.com ([78.68.120.205]:50878 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZDIQ7-0004fL-7B; Thu, 09 Jul 2015 13:27:47 -0700 Message-ID: <559ED92C.4000201@levkowetz.com> Date: Thu, 09 Jul 2015 22:27:24 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <559E7636.3040608@levkowetz.com> <0FDF4654-1AED-45CE-AF04-7617F8487870@cisco.com> In-Reply-To: <0FDF4654-1AED-45CE-AF04-7617F8487870@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AmgWxPFjSath5qoP0inT7DoWedTtFfMVc" X-SA-Exim-Connect-IP: 78.68.120.205 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, fred@cisco.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Cc: "tools-discuss@ietf.org" Subject: Re: [Tools-discuss] Odd Datum X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:27:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AmgWxPFjSath5qoP0inT7DoWedTtFfMVc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Fred, On 2015-07-09 21:50, Fred Baker (fred) wrote: >=20 >> On Jul 9, 2015, at 6:25 AM, Henrik Levkowetz >> wrote: >>=20 >> How would you suggest we improve the presentation and/or state >> names in order to make the datatracker search page you refer to >> clearer/better? >>=20 >> Should there maybe be a differently named state for last calls on >> non-WG documents? >=20 > My preference: >=20 > I would like "is a working group document" to be a sticky state that > I, as a working group chair, can change. If a WG document falls out > of favor, I'd like to, without changing the name from draft-ietf-* to > draft--*, be able to change it to some variation on > "individual submission". >=20 > Within "is a WG document", I'd like a second state that says "in > discussion", "in WGLC", "waiting for update", "waiting on lazy WG > chair", or whatever. Umm. Ok. Tracker-wise, I don't think that's too hard to do, but I think= it requires a number of policy decisions, both with respect to revising RFC 6174, and with respect to how to handle the transition of a draft named draft-ietf-something to an individual draft. I think the assumptio= n with today's states is that the WG draft will be set to 'Dead WG Document= ', rather than having it live on as an individual document with a name that makes it look as a WG document. Changes that I think would be possible without major policy changes would= include not showing the plain 'WG document' state in document lists, some= thing which seems to be as if it would address part of your discomfort. Henrik --AmgWxPFjSath5qoP0inT7DoWedTtFfMVc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVntksAAoJEE6bV0uPuxca3ioP/06JTcFQVfVRhElrH/6VRXEn osl0DpDvQ71e/GMSL9VnCwrAlDNMPSuv4qWUL7LujgtBiQr0zigIQqFxDM3INhXQ TfztGk2X4NxEgHXAikIHRela0eN9l7W9BiUPwlYNtYRBWitdKVat1i2YnVZMrJE1 PHySwn56SIGeQrbOgfBhGrYavroffte7vU4oIoX0L9BWL9FQiQ2UurZym5nhKMlk r07RDj+P8nJJO+Yp+euCqMeg0y22o14aTCwRU3H9huk1CIKH5Kqa0SY13rBVnyK/ yH9hs/8pmICB4+ud+eoEZacwCi3I1avY4rjfpn+njiUE1lCGBZN4DpyoXB5kpC/j RRPDh76I9ub6opg24OwTOsxeCt94dHfNSsiHtUAaB4Qd7pSvANQPmJ+zaNRy1INp 2OWkFzlMvW1PRnPrdvFNA62FujR9htgcfAZyj0DmVdfqc4xN3RY6xF7Pfs78UYav 80b1mWjsbq0094RfJyDXT0QNpqkR9YeybHIvNkrIz0pD44PJ/YISUALJuLVjRzPg O2+KaqYJkhENnrOQZb2wKWL65SSb3cmNs+7++5ga6cP0fI59UezxPtszclZ0IWHa g7+2BYTd+TqeCEJOiej7DJM010DGpqBlOxbt9fplSQWOER9Qgjw9tAe4qeeyFG7i 3ZmxRdhUfw09a+XIndz3 =5py8 -----END PGP SIGNATURE----- --AmgWxPFjSath5qoP0inT7DoWedTtFfMVc-- From nobody Thu Jul 9 13:30:09 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F172B1A0149 for ; Thu, 9 Jul 2015 13:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 HR65A1Nl8F1S for ; Thu, 9 Jul 2015 13:30:06 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FBA1A0141 for ; Thu, 9 Jul 2015 13:30:06 -0700 (PDT) Received: from [172.16.21.103] (cpe-98-122-46-16.sc.res.rr.com [98.122.46.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 0225CFA56; Thu, 9 Jul 2015 16:29:49 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3067\)) From: Tom Pusateri In-Reply-To: <849D2D88-97DA-490C-ACE6-CF03D533D48A@bangj.com> Date: Thu, 9 Jul 2015 16:30:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <81CE9894-13D5-401F-87CD-3F2AA77EFB50@bangj.com> References: <778E0CEF-F425-4233-B1FF-03643EC25ADC@bangj.com> <878uapcfou.fsf@alice.fifthhorseman.net> <849D2D88-97DA-490C-ACE6-CF03D533D48A@bangj.com> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3067) Archived-At: Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] time required to retrieve drafts has increased X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:30:08 -0000 On Jul 9, 2015, at 3:18 PM, Tom Pusateri wrote: >=20 >> On Jul 9, 2015, at 3:08 PM, Daniel Kahn Gillmor = wrote: >>=20 >> On Thu 2015-07-09 14:32:51 -0400, Tom Pusateri wrote: >>> Lately, it seems like it takes much longer to retrieve the = redirection for an HTML version of a draft and then for the draft = itself. >>>=20 >>> butte-2% time curl = http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =20 >>> =09 >>> >>>

>>> The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01. >>>

>>> >>> >>> curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 30.849 total >>> butte-2% time curl = http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp >>> =09 >>> >>>

>>> The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01. >>>

>>> >>> >>> curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 36.465 total >>>=20 >>> It=E2=80=99s taking on average around 33 seconds to get the redirect = to the appropriate version and then another 6 seconds on average to get = the draft: >>>=20 >>> curl http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 0.01s = user 0.01s system 0% cpu 6.673 total >>>=20 >>> This seems much longer than it used to be. Any insight? >>=20 >> I see this lag when accessing 209.208.19.222, but not when accessing >> 64.170.98.42 or 2001:1890:123a::1:2a. >>=20 >> $ time wget -O/dev/null = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =20 >> --2015-07-09 15:05:52-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp >> Resolving tools.ietf.org (tools.ietf.org)... 209.208.19.222 >> Connecting to tools.ietf.org (tools.ietf.org)|209.208.19.222|:443... = connected. >> HTTP request sent, awaiting response... 302 Found >> Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 = [following] >> --2015-07-09 15:06:27-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 >> Reusing existing connection to tools.ietf.org:443. >> HTTP request sent, awaiting response... 200 OK >> Length: 86603 (85K) [text/html] >> Saving to: =E2=80=98/dev/null=E2=80=99 >>=20 >> /dev/null 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 84.57K 462KB/s in 0.2s =20 >>=20 >> 2015-07-09 15:06:29 (462 KB/s) - =E2=80=98/dev/null=E2=80=99 saved = [86603/86603] >>=20 >>=20 >> real 0m37.591s >> user 0m0.052s >> sys 0m0.008s >> $ time wget -O/dev/null = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =20 >> --2015-07-09 15:06:37-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp >> Resolving tools.ietf.org (tools.ietf.org)... 64.170.98.42 >> Connecting to tools.ietf.org (tools.ietf.org)|64.170.98.42|:443... = connected. >> HTTP request sent, awaiting response... 302 Found >> Location: https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 = [following] >> --2015-07-09 15:06:45-- = https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01 >> Reusing existing connection to tools.ietf.org:443. >> HTTP request sent, awaiting response... 200 OK >> Length: 86603 (85K) [text/html] >> Saving to: =E2=80=98/dev/null=E2=80=99 >>=20 >> /dev/null 100%[=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D>] 84.57K 47.9KB/s in 1.8s =20 >>=20 >> 2015-07-09 15:06:47 (47.9 KB/s) - =E2=80=98/dev/null=E2=80=99 saved = [86603/86603] >>=20 >>=20 >> real 0m9.116s >> user 0m0.048s >> sys 0m0.008s >> $=20 >>=20 >> So i think it's only one host that has this delay. I'm seeing the = delay >> regardless of whether i have functional reverse DNS on my own IP = address. >>=20 >> --dkg >=20 >=20 > Hmm, I=E2=80=99m at a coffee shop (but this delay was at home too) and = I=E2=80=99m consitently getting a long delay just trying resolve the = address: >=20 > butte-2% time host tools.ietf.org > tools.ietf.org has address 64.170.98.42 > tools.ietf.org has address 209.208.19.222 > ;; connection timed out; no servers could be reached > tools.ietf.org mail is handled by 10 zinfandel.tools.ietf.org. > tools.ietf.org mail is handled by 20 gamay.tools.ietf.org. > tools.ietf.org mail is handled by 30 merlot.tools.ietf.org. > host tools.ietf.org 0.01s user 0.01s system 0% cpu 10.188 total >=20 > Thanks, > Tom >=20 No IPv6 at the coffee shop. At home, name resolution is fine. So = that=E2=80=99s a false datapoint. butte-2% time host tools.ietf.org =20= tools.ietf.org has address 209.208.19.222 tools.ietf.org has address 64.170.98.42 tools.ietf.org has IPv6 address 2001:1890:123a::1:2a tools.ietf.org mail is handled by 20 gamay.tools.ietf.org. tools.ietf.org mail is handled by 30 merlot.tools.ietf.org. tools.ietf.org mail is handled by 10 zinfandel.tools.ietf.org. host tools.ietf.org 0.00s user 0.02s system 19% cpu 0.111 total Things look a little better. IPv6 is faster than IPv4 from home (15s vs = 7s): butte-2% time curl -4 http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =09

The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01.

curl -4 http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 14.852 total butte-2% time curl -6 http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp =09

The document is available here: http://tool= s.ietf.org/html/draft-ietf-dmm-fpc-cpdp-01.

curl -6 http://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp 0.01s user = 0.01s system 0% cpu 7.474 total Tom From nobody Thu Jul 9 13:35:57 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776301A0161 for ; Thu, 9 Jul 2015 13:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham 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 ZDprZNbwmcBy for ; Thu, 9 Jul 2015 13:35:54 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA971A0151 for ; Thu, 9 Jul 2015 13:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3382; q=dns/txt; s=iport; t=1436474154; x=1437683754; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=pIvK9hIWkZPWKANwNU0OZtKQ9RwgoIHfwg8NwOERXR0=; b=RnlfNkWA3nX5U6MV9tPix5VElItPf+kvButG53TOPm0pKCqOzYybpnr4 yJ0IEfxYKgF8N0HNEgN10ETO949dM1W7vCnGkRw3o3/hGpUNnoyEyjt4n dLTq761/7VxVdkMPGdO0qP2AaexFAjBth7+AxTiKt9hP3B9gcdoPLZmYM 4=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CNAwCL2p5V/4YNJK1bgxKBNLsnCYdoAoFhOBQBAQEBAQEBgQqEIwEBAQMBeQULCxguVwYTiCYIz1kBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0uFBgeDF4EUBYwqb4cUgi2FGIQ7gT2PHoQtg18mhBseMYJLAQEB X-IronPort-AV: E=Sophos;i="5.15,442,1432598400"; d="asc'?scan'208";a="14099494" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-1.cisco.com with ESMTP; 09 Jul 2015 20:35:53 +0000 Received: from sjc-fred-88110.cisco.com (sjc-fred-88110.cisco.com [10.19.64.123]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t69KZqsV004711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Jul 2015 20:35:52 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: multipart/signed; boundary="Apple-Mail=_765BFEF5-B8BA-48F0-B8D6-93C3698BD4B5"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5 From: Fred Baker In-Reply-To: <559ED92C.4000201@levkowetz.com> Date: Thu, 9 Jul 2015 13:35:50 -0700 Message-Id: References: <559E7636.3040608@levkowetz.com> <0FDF4654-1AED-45CE-AF04-7617F8487870@cisco.com> <559ED92C.4000201@levkowetz.com> To: Henrik Levkowetz X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "tools-discuss@ietf.org" Subject: Re: [Tools-discuss] Odd Datum X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 20:35:55 -0000 --Apple-Mail=_765BFEF5-B8BA-48F0-B8D6-93C3698BD4B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 9, 2015, at 1:27 PM, Henrik Levkowetz = wrote: >=20 > Hi Fred, >=20 > On 2015-07-09 21:50, Fred Baker (fred) wrote: >>=20 >>> On Jul 9, 2015, at 6:25 AM, Henrik Levkowetz >>> wrote: >>>=20 >>> How would you suggest we improve the presentation and/or state >>> names in order to make the datatracker search page you refer to >>> clearer/better? >>>=20 >>> Should there maybe be a differently named state for last calls on >>> non-WG documents? >>=20 >> My preference: >>=20 >> I would like "is a working group document" to be a sticky state that >> I, as a working group chair, can change. If a WG document falls out >> of favor, I'd like to, without changing the name from draft-ietf-* to >> draft--*, be able to change it to some variation on >> "individual submission". >>=20 >> Within "is a WG document", I'd like a second state that says "in >> discussion", "in WGLC", "waiting for update", "waiting on lazy WG >> chair", or whatever. >=20 > Umm. Ok. Tracker-wise, I don't think that's too hard to do, but I = think > it requires a number of policy decisions, both with respect to = revising > RFC 6174, and with respect to how to handle the transition of a draft > named draft-ietf-something to an individual draft. I think the = assumption > with today's states is that the WG draft will be set to 'Dead WG = Document', > rather than having it live on as an individual document with a name = that > makes it look as a WG document. >=20 > Changes that I think would be possible without major policy changes = would > include not showing the plain 'WG document' state in document lists, = something > which seems to be as if it would address part of your discomfort. OK, I'll think about it in those terms. Yes, the point is that I want to = be able to make that designation go away - the (v6ops) working group = charter specifically calls for a draft to be able to be discontinued if = the working group stops being interested. --Apple-Mail=_765BFEF5-B8BA-48F0-B8D6-93C3698BD4B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBVZ7bJ0ayAOS/EQ8MAQIBRA//Udxz89JG1J4wufuI+Hjks+/DFR/IF5z2 hU5dxz7mk2/BYgmMN9s6pDbabjWoGlbkomTgcD77BRxJi+aXmojQqD532hFEPvc6 1vNMLKf265CsA+9femq6VoCfpmluZ4sLLTSCYG05/6M92iL/ZxrC5lmy558WI0xi 6itax4ML0tWfcTCxD48hY8gx614+YXgc6DZLtQyLiGkp7NAdTGV2AOesZD8XIo1/ b4OKADLW0X+26fVOVQaTodlLxw54d/epk2Z/j39ryKqzxAyPu0PUQ2xD++wmXP/K Cs8G9/HkhQ6hIu9XhB8M7lofhOWh2P8c84YViZVZY0w+61Jor3zvQbSaICHVmmD9 YJtvXW2ySP+GJI6zM9EGLj5org1gERxgxeH/u9FH3QbwR4oWi02PJfYkJcNXSqSj mAgVs5gJ8GGPsLgmrqmKqcm8sWqXOw3xvpBuwwiptds93ef16VEzccmRtGtbhDry N1OPaLO6a8+QUf/9uiPL0c6X/qP0pnBU1PPDrjLYOGwrHhl0wvvg5vMVmvvOxxwL u5o8ojkJCcihqQYgQj03na9Kj0ly+gzDFdUmO1h5a0bSBTjHx75zfOLSP/CHgzFr LrHSIWWlkZmc7bhnIEEnEVRpcr1CMLgwaxRCA6FetSqORJ1i3xIztjBcUXy9bsIo /Lvwd2CL5rc= =5kZJ -----END PGP SIGNATURE----- --Apple-Mail=_765BFEF5-B8BA-48F0-B8D6-93C3698BD4B5-- From nobody Fri Jul 10 02:02:24 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573301A21C6 for ; Fri, 10 Jul 2015 02:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fzxuP1VgG54T for ; Fri, 10 Jul 2015 02:02:21 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABCB81A1BB0 for ; Fri, 10 Jul 2015 02:02:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.15,446,1432623600"; d="asc'?scan'208";a="53773335" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 10 Jul 2015 02:01:00 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 10 Jul 2015 02:01:00 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::6843:58b6:e8e4:4968%21]) with mapi id 15.00.1076.000; Fri, 10 Jul 2015 02:01:00 -0700 From: "Eggert, Lars" To: Henrik Levkowetz Thread-Topic: [Tools-discuss] W3C Validator Suite Thread-Index: AQHQuVhf8V8CcAtXBk2ZLm1MhW/kOZ3TggQAgAFehIA= Date: Fri, 10 Jul 2015 09:00:59 +0000 Message-ID: <4F244554-0EE5-4D63-8CE3-57E7338DB88E@netapp.com> References: <29CC57B1-891D-44CA-A044-B59EF6284B94@netapp.com> <559E63C2.8070802@levkowetz.com> In-Reply-To: <559E63C2.8070802@levkowetz.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.2102) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/signed; boundary="Apple-Mail=_745DCB87-0736-424C-9112-0E8092CE3828"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] W3C Validator Suite X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 09:02:23 -0000 --Apple-Mail=_745DCB87-0736-424C-9112-0E8092CE3828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2015-7-9, at 14:06, Henrik Levkowetz wrote: >=20 > FWIW, at the time I merged in your Facelift, I also added html5 = verification > to the test-crawler, using html5lib's parser in strict mode. In all = cases where > it has reported html errors, the error matches what the w3c validator = says, but > the w3c validator also reports warnings which the html5lib parser = doesn't > say anything about. >=20 > If you'd like to add in some degree of validation using the w3c = validator-suite, > I'd suggest hooking it in next to the html5lib validation in = bin/test-crawl > (in check_html_valid()). It tries to only validate one sample of a = given kind > of URL, so that the extra runtime cost of validation doesn't hit us = too hard. Ah, you mentioned the validation earlier but it had slipped my mind. I = may try and hook the "nu validator" = (https://github.com/validator/validator) into that framework, which is = what drives the W3C site. Thanks, Lars --Apple-Mail=_745DCB87-0736-424C-9112-0E8092CE3828 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlWficsACgkQIWcjmsUTWRoQQwCeIxWixfFVas5l0y0ZNJpefEDe /pgAoOMyQigMbf8uUv3503f08tiOfCuT =Yb3r -----END PGP SIGNATURE----- --Apple-Mail=_745DCB87-0736-424C-9112-0E8092CE3828-- From nobody Fri Jul 10 04:25:25 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F356B1A9093 for ; Fri, 10 Jul 2015 04:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 pa3RV49mdQvB for ; Fri, 10 Jul 2015 04:25:22 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 BE5231A9092 for ; Fri, 10 Jul 2015 04:25:22 -0700 (PDT) Received: from h205n24-s-oev-a31.ias.bredband.telia.com ([78.68.120.205]:56650 helo=vigonier.tools.ietf.org) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZDWQW-0002Yh-NS; Fri, 10 Jul 2015 04:25:09 -0700 Message-ID: <559FAB70.6090908@levkowetz.com> Date: Fri, 10 Jul 2015 13:24:32 +0200 From: Henrik Levkowetz User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Eggert, Lars" References: <29CC57B1-891D-44CA-A044-B59EF6284B94@netapp.com> <559E63C2.8070802@levkowetz.com> <4F244554-0EE5-4D63-8CE3-57E7338DB88E@netapp.com> In-Reply-To: <4F244554-0EE5-4D63-8CE3-57E7338DB88E@netapp.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="VH0PtlWjBEGFkjUV8asWfaeDBBFGtjroc" X-SA-Exim-Connect-IP: 78.68.120.205 X-SA-Exim-Rcpt-To: henrik-sent@levkowetz.com, tools-discuss@ietf.org, lars@netapp.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Archived-At: Cc: "tools-discuss@ietf.org Discussion" Subject: Re: [Tools-discuss] W3C Validator Suite X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 11:25:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VH0PtlWjBEGFkjUV8asWfaeDBBFGtjroc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-07-10 11:00, Eggert, Lars wrote: > On 2015-7-9, at 14:06, Henrik Levkowetz wrote: >>=20 >> FWIW, at the time I merged in your Facelift, I also added html5 verifi= cation >> to the test-crawler, using html5lib's parser in strict mode. In all c= ases where >> it has reported html errors, the error matches what the w3c validator = says, but >> the w3c validator also reports warnings which the html5lib parser does= n't >> say anything about. >>=20 >> If you'd like to add in some degree of validation using the w3c valida= tor-suite, >> I'd suggest hooking it in next to the html5lib validation in bin/test-= crawl >> (in check_html_valid()). It tries to only validate one sample of a gi= ven kind >> of URL, so that the extra runtime cost of validation doesn't hit us to= o hard. >=20 > Ah, you mentioned the validation earlier but it had slipped my mind. > I may try and hook the "nu validator" > (https://github.com/validator/validator) into that framework, which > is what drives the W3C site. Sounds like a plan :-) Henrik --VH0PtlWjBEGFkjUV8asWfaeDBBFGtjroc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJVn6t3AAoJEE6bV0uPuxcag6kQAJMsUEHGmX88ZDmhitL9J2T9 e1Txwuhv7SLRuLwtl+q9SOIMC6Clgw1zVSE+w5kW92X3LtYkeKamxyBH+Ojd5GGj fiDcw/pO+uHwXQpF2BYa++lp7Qiv4Jps0T98gGDPV/T2wf0AaIkRMSxgp5BqvAFH uLUnymAylN96DTRWOCypAPgWUMmLS0g1W02n5+MRmdUOKBrRVeorDKak7tNfnSTN S7bdGM3/U+Orrkgm/Y4Qek9EECnXwVS4H/m6K7I5Mq7QxTHJcpBMMaQkBm9ZR6fL mbgGssOr9+ymtQDCqqat6Z3RuJspSMG2uASclrz0Qne/xPzo1phc+LL1854AiXUx 0BpfyMCtrGD7kQ28XHlcWZ0lvZWhsI6QJ053UkK74RFlFpSaI5mQPFbj+PC3SzFs 5OeyJEmehsv9xj8GCGUbQt4HSK7SJNJ/TJnUNdXKGafWqUnBU0r6s+OgH56SkYcJ Oz0kIhWr3cV/SCOmTNU0uM33XnmcVj91qAkzYA9VOes2QPebc0/ayQ0Eec/5p3oq ydfg0Z0x0b9kCxIvRQ70L80ESUqVERbdyfuIzhAwuilaaGfJeAAXE6X4Ow4IYF8z YeUDXRXUR5KYAFRKsYYYJ06UQqJGMH/9MmBM2rcthm6MA0379UnTnUR63C5sTJDE H9jy6iyncBH11JWNtlcO =xQ0l -----END PGP SIGNATURE----- --VH0PtlWjBEGFkjUV8asWfaeDBBFGtjroc-- From nobody Fri Jul 10 09:00:56 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC911B2A8D for ; Fri, 10 Jul 2015 09:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QbWysj1sOHOg for ; Fri, 10 Jul 2015 09:00:53 -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 654CA1B2A0C for ; Fri, 10 Jul 2015 09:00:53 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6AG0qr8057842 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Fri, 10 Jul 2015 11:00:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <559FEC30.9010504@nostrum.com> Date: Fri, 10 Jul 2015 11:00:48 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tools Team Discussion Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Tools-discuss] Raw 1st draft: SoW for improvements to the manual submission process X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 16:00:55 -0000 The transparency of the ID submission process needs to be improved, particularly for those submissions that are handled directly by the secretariat ("manual" and "forced" submissions). When an author uses the datatracker submission tool, SubmissionEvents are captured, noting when the draft was submitted, when it was approved by previous authors (and by who), when it was approved by a WG chair if such approval was necessary, and when it was posted into the repository. Currently, the document’s history shows only that a new version is available. The submission tool presents an option to authors to request that the secretariat finish the submission process. The datatracker captures the candidate document and sends email to the secretariat. Often the request is made because the submission tool was unable to extract the correct meta-data from the document. In this case, the secretariat populates the meta-data, and forces the post. In other cases, there are issues identified by id-nits that the secretariat helps diagnose, and the author is guided through fixing the issues and restarting the submission process with a repaired document. Again, SubmissionEvents are captured as the document goes through this process, but for drafts that are forced, the document history does not reflect these events. The secretariat also receives requests to post a draft by direct email, bypassing the submission tool altogether. (Currently, the secretariat receives around 10 such requests each meeting cycle). The secretariat operates the submission tool on behalf of the author. The SubmissionEvents currently captured do not reflect that this was a manual submission request. The secretariat currently relies on a combination of RT and personal email archives to keep track of the outstanding manual submission requests. This project will make the following improvements: When a document is posted via the normal submission process, DocEvents reflecting the SubmissionEvents for the initial submission, the approval of previous authors, and the approval of a stream authority (such as WG chairs for a WG -00) will be added to the document. That is, where documents currently typically have a first history entry of "New version available: whatever-00", The first entries will be "New version submitted", "New version approved by previous author: (name)", "WG -00 approved by (name)", "New version available: whatever-00". The entries for subsequent versions are analogous. When manual submission is requested via the submission tool, and the document is posted by the secretariat, DocEvents reflecting that the manual posting was requested, any approvals obtained, and that the document was forced will be added to the document. An example of the entries would be "Manual submission requested by (name)", "Meta-data set to by (name)", "WG -00 approved by (name)", "New version available: whatever -00". When manual submission is requested by direct email, the secretariat will have the ability to tell the tracker that the request was received and upload the document from the email request, but not handle the request immediately. After this indication, the document will be in the same condition as a document requesting manual submission via the submission tool. However the secretariat should not be forced to take that extra step if the request will be processed immediately. The submission tool should be modified to allow the secretariat to indicate they are submitting the document on behalf of an author at their request for manual submission. SubmissionEvents indicating that manual submission was requested will be created. Once the document is posted, DocEvents reflecting the history of the submission (as described for the above cases) will be created. A page will be created (readable by anyone) that shows the set of outstanding manual submission requests. Each entry will either show, or provide navigation to a separate page that shows, the SubmissionEvent history for the outstanding submission. When logged in as the secretariat, there will be easy navigation from each entry to the page that allows processing the request. Note that as of release 6.0.4, the manual submission process results in a DocEvent that says simple "New version available" without providing a link to the version that became available. This project will ensure that all paths that produce a "New version available" DocEvent include a link to the new version in the event’s description. From nobody Sat Jul 11 11:55:02 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4F21A8944 for ; Sat, 11 Jul 2015 11:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CuzOLxgyhrPq for ; Sat, 11 Jul 2015 11:55:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BF41A8955 for ; Sat, 11 Jul 2015 11:54:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 84C852002A; Sat, 11 Jul 2015 15:11:07 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D6E8463AEC; Sat, 11 Jul 2015 14:54:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B929C63751; Sat, 11 Jul 2015 14:54:57 -0400 (EDT) From: Michael Richardson To: Robert Sparks In-Reply-To: <559FEC30.9010504@nostrum.com> References: <559FEC30.9010504@nostrum.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: Tools Team Discussion Subject: Re: [Tools-discuss] Raw 1st draft: SoW for improvements to the manual submission process X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 18:55:01 -0000 --=-=-= Content-Type: text/plain Robert Sparks wrote: > The secretariat also receives requests to post a draft by direct email, > bypassing the submission tool altogether. (Currently, the secretariat > receives around 10 such requests each meeting cycle). The secretariat Do we know why the authors use this process? Is it people with aversions to web browsers, people who have been doing it this way for 20 years and won't change, or is it people whose networks are too slow? > When a document is posted via the normal submission process, DocEvents > reflecting the SubmissionEvents for the initial submission, the > approval of previous authors, and the approval of a stream authority > (such as WG chairs for a WG -00) will be added to the document. That > is, where documents currently typically have a first history entry of > "New version available: whatever-00", The first entries will be "New > version submitted", "New version approved by previous author: (name)", > "WG -00 approved by (name)", "New version available: whatever-00". The > entries for subsequent versions are analogous. On the topic of "surprise" authorship, will it be possible to ask the tool for a list of document on which my name exists, but which I have never approved? Could I also (co-?)approve documents that I know about, but which I didn't do the submission? I'm often surprised that I have to approve a new submission even though I was logged into the datatracker when I made the submission. (I realize that this is due to the evolution of the datatracker: we had submission before we had logins...) All the rest of your proposals also seem sensible. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVaFmfoCLcPvd0N1lAQKKjwf+OrQg/nxoiIvjZIZsigU17pgi5C5q1Gla YmExs5x57F+zx1fttsKKsRmTBSMK41/Kl8d5HvnLrsjKZTaLju68cKRpaRuudwnq 99NNQWZfhqEyDRrDsAzMhcfq6gHGIEbL4NcwknIY21REwiASOILleIBQd2wMUCcO 9hft9h+eAB912UcoFzJjR6WpV16HfR0A7zngd7IcFgb93+UCQd5Zv5zhxbACPCm0 37viWq4I+qp9/XTgxd4KTkgeSTorhfsc2w0kH60OmvcScOYHHCBhJrh+y2OSh/r+ bp03hfPx+MK73omiE94KYQpH5gCu9Ash5djUN5A3sU0xyDfDNy5nag== =KmIk -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jul 16 03:35:48 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9591B3323 for ; Thu, 16 Jul 2015 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 Yh9_lYaIObK6 for ; Thu, 16 Jul 2015 03:35:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4FF1ACE49 for ; Thu, 16 Jul 2015 03:35:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DCC1DBE7D; Thu, 16 Jul 2015 11:35:42 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtrc44cynw-5; Thu, 16 Jul 2015 11:35:42 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B92B6BE7B; Thu, 16 Jul 2015 11:35:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437042942; bh=jqjLeH+OokAcYQPNaBlpa4AEp5UQk/cSEpHJXXgZczU=; h=Date:From:To:CC:Subject:From; b=xv02LhLiIh4zLt4sXaoTUBpVcU8G9cm1F6YYx6VdeBBoweeHNaY6oYsV4cK4ZtSN0 SPAz74L+2VwTMVS5ggu8odO6OdUVv1a222c5pUfxC3PUvIG+vZWd8A7FCaIaP6RCS+ 6j+xeJVw4pQI7+VESDoc6Hlb1R2cZW9ZrUsycxwY= Message-ID: <55A788FE.7080509@cs.tcd.ie> Date: Thu, 16 Jul 2015 11:35:42 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "tools-discuss@ietf.org Discussion" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX Subject: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 10:35:47 -0000 Hiya, Carlo (cc'd) has told me that he's having problems with a discussion in which he's participating as folks are using archive links like [1] that require JS to follow. And his browser has JS turned off for security reasons. In my case, I allow JS from ietf.org, but he's not as regular a participant so it's reasonable that he does not. There are non-JS archives for all lists still, (in this case [2] I guess) but finding those is hard for folks who don't know where to go. I think in some cases the WG page archive pointer only goes to mailarchive.ietf.org, whereas in others (including rtcweb) you get a pointer to the mhonarc archive. And of course finding the right message in [2] when given [1] is time consuming, esp. if the message is not on page 1 of [2]. Is there something we can do to make this better/easier for folks who have JS always-off or disallowed for ietf.org? I'm not sure there's a great answer here as mailarchive.ietf.org does provide nice new features, and any good answer might end up with "folks should look out for this and jump in sending a link to the mhonarc archive" but I thought I'd ask as it is good practice for people to not trust JS from what is to them just some random web site when they're participating in an email discussion on a particular issue but perhaps not following the WG in all detail. (And that's inevitable for a WG like rtcweb:-) One probably stupid suggestion might be a form where I could paste in [1] and get a link to that message in mhonarc maybe, or a link on [1] to the message in mhonarc somewhere on the page displayed when one de-references [1]? Thanks, S. [1] https://mailarchive.ietf.org/arch/search/?email_list=rtcweb&gbt=1&index=VnStGD7Emmvc1-QOPRtY2cFF79E [2] https://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html From nobody Thu Jul 16 04:41:32 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEAD1B3A33 for ; Thu, 16 Jul 2015 04:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jmFuLCWSbRm4 for ; Thu, 16 Jul 2015 04:41:29 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2BF1B3955 for ; Thu, 16 Jul 2015 04:41:29 -0700 (PDT) Received: by pdjr16 with SMTP id r16so43270731pdj.3 for ; Thu, 16 Jul 2015 04:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tbMEanhdYT9gZp3+vNa31RM+75zdYtQ1IrXgyOcrJOs=; b=w89BCtu7Oe67+47RtQkoIlMKdAoVPCxzuDdgxYrh+S0JSxd9Nn2gVexLbfU/9+JHKF 0wPbe04d0XgiKXiF6zfFZrGiBboLPh2FvYOKBZOvBlMdsDoT18VRn8Kd0uKfgN3NlhlN CurcTFLWeag84LIkKumOS6UMIZd7xF8DNjTKIve22DfLeFqcS2g6U52CVrNgdFAzYpMW Kpn1DRO3QuvvhEMSgC1eGM4EviZomsyIOVLScKnRtp9LoMjPyszvmRbiiyJkbFwylRi2 DVVEd+4wDhxCFkq250iF3iBDXX0h+Hd/BaF31jPmXmQgXjlHRHgdnKVrzjkiPnHQK5s+ 5D/g== X-Received: by 10.68.57.206 with SMTP id k14mr17900704pbq.97.1437046888997; Thu, 16 Jul 2015 04:41:28 -0700 (PDT) Received: from [172.20.13.21] ([168.126.248.100]) by smtp.gmail.com with ESMTPSA id dl5sm7682303pbd.78.2015.07.16.04.41.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jul 2015 04:41:27 -0700 (PDT) Message-ID: <55A7986C.9060207@gmail.com> Date: Thu, 16 Jul 2015 23:41:32 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <55A788FE.7080509@cs.tcd.ie> In-Reply-To: <55A788FE.7080509@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 11:41:31 -0000 The most important thing IMNSHO would be a rock-solid promise that the https://www.ietf.org/mail-archive/web/WGHNAME/current/maillist.html archives will continue to be maintained. For almost all purposes I find them preferable. Regards Brian On 16/07/2015 22:35, Stephen Farrell wrote: > > Hiya, > > Carlo (cc'd) has told me that he's having problems with a discussion > in which he's participating as folks are using archive links like [1] > that require JS to follow. And his browser has JS turned off for > security reasons. In my case, I allow JS from ietf.org, but he's not > as regular a participant so it's reasonable that he does not. > > There are non-JS archives for all lists still, (in this case [2] I > guess) but finding those is hard for folks who don't know where to > go. I think in some cases the WG page archive pointer only goes to > mailarchive.ietf.org, whereas in others (including rtcweb) you get > a pointer to the mhonarc archive. And of course finding the right > message in [2] when given [1] is time consuming, esp. if the message > is not on page 1 of [2]. > > Is there something we can do to make this better/easier for folks > who have JS always-off or disallowed for ietf.org? > > I'm not sure there's a great answer here as mailarchive.ietf.org > does provide nice new features, and any good answer might end up > with "folks should look out for this and jump in sending a link > to the mhonarc archive" but I thought I'd ask as it is good > practice for people to not trust JS from what is to them just > some random web site when they're participating in an email > discussion on a particular issue but perhaps not following the > WG in all detail. (And that's inevitable for a WG like rtcweb:-) > > One probably stupid suggestion might be a form where I could > paste in [1] and get a link to that message in mhonarc maybe, > or a link on [1] to the message in mhonarc somewhere on the > page displayed when one de-references [1]? > > Thanks, > S. > > [1] > https://mailarchive.ietf.org/arch/search/?email_list=rtcweb&gbt=1&index=VnStGD7Emmvc1-QOPRtY2cFF79E > [2] https://www.ietf.org/mail-archive/web/rtcweb/current/maillist.html > From nobody Thu Jul 16 19:01:49 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F341B2EDF for ; Thu, 16 Jul 2015 19:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 VYMiRY16sc7T for ; Thu, 16 Jul 2015 19:01:47 -0700 (PDT) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26AF1B2EDB for ; Thu, 16 Jul 2015 19:01:45 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with comcast id tE1k1q0052TL4Rh01E1kU0; Fri, 17 Jul 2015 02:01:44 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-17v.sys.comcast.net with comcast id tE1i1q00B1KKtkw01E1i6j; Fri, 17 Jul 2015 02:01:44 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id t6H21fYH022052; Thu, 16 Jul 2015 22:01:41 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id t6H21diE022048; Thu, 16 Jul 2015 22:01:39 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Stephen Farrell In-Reply-To: <55A788FE.7080509@cs.tcd.ie> (stephen.farrell@cs.tcd.ie) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 16 Jul 2015 22:01:39 -0400 Message-ID: <878uafmtj0.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1437098504; bh=uVNbyVG/bvxKfYLKPVONxik4Vp/bjq19XsYspeYrWy8=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=uawKSYh0G4vrLJAGhQsjh+B4rtynnzhJS/iqaeAMjX1r8OwgvRS2ZVq6zXU4qnvLQ SRl8qC0RmNYhG/85/k4NbvYLRk6GdTjLGmA0gk86Qo8M1jtjYnxJ/Lz3CkD21QSNCS 6RGHveXL7ss6J6ixxASA97rPJ0tp6YuUqldZljnQ99Qd/h0ZmY8R+vIg22X49agiSO 69emu93pryYs6EoESQXhevUIvsYbOIozCirfG5JE398kM83d7lIKGY9mFqyuoWw09G 1NYORyPwMhAbEx/3x51Zn6QFaSzfcVSzynw97SAirb/9O4TcYnFGi3z5GLAez6uqJd 87+f2jepS3UwQ== Archived-At: Cc: lynX@the.internet.is.psyced.org, tools-discuss@ietf.org Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 02:01:48 -0000 Stephen Farrell writes: > Is there something we can do to make this better/easier for folks > who have JS always-off or disallowed for ietf.org? Have a web site that doesn't require Javascript? I mean, is there any desirable functionality that can't be implemented on the server side? Should we not classify mandatory Javascript as a problem self-inflicted by the IETF? I'm being a curmudgeon here, but my experience is that 99% of Javascript is pure eye-candy and often the "features" it implements are as much an inconvenience for the serious user as they are a benefit. Dale From nobody Fri Jul 17 06:03:27 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F011B3363 for ; Fri, 17 Jul 2015 05:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.888 X-Spam-Level: X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 DFf4UWq2qO0s for ; Fri, 17 Jul 2015 05:52:11 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 446871B3388 for ; Fri, 17 Jul 2015 05:52:11 -0700 (PDT) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 5BED41E52B4 for ; Fri, 17 Jul 2015 05:51:47 -0700 (PDT) Received: from mail-vn0-f50.google.com (mail-vn0-f50.google.com [209.85.216.50]) by c8a.amsl.com (Postfix) with ESMTPSA id 2CF9C1E52B9 for ; Fri, 17 Jul 2015 05:51:47 -0700 (PDT) Received: by vnk197 with SMTP id 197so483153vnk.3 for ; Fri, 17 Jul 2015 05:52:10 -0700 (PDT) X-Received: by 10.52.65.136 with SMTP id x8mr16384037vds.58.1437137530173; Fri, 17 Jul 2015 05:52:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.74.7 with HTTP; Fri, 17 Jul 2015 05:51:50 -0700 (PDT) From: Glen Date: Fri, 17 Jul 2015 05:51:50 -0700 Message-ID: To: Glen Barney Content-Type: multipart/alternative; boundary=bcaec5015f0bfabffd051b11a74c Archived-At: X-Mailman-Approved-At: Fri, 17 Jul 2015 06:03:25 -0700 Subject: [Tools-discuss] Glen (AMS IT) In Prague X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: glen@amsl.com List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 12:52:12 -0000 --bcaec5015f0bfabffd051b11a74c Content-Type: text/plain; charset=UTF-8 Greetings! For those of you who may not know me, I'm Glen Barney, the IT Director at AMS, which is the company that provides secretariat and IT services to the IETF. I'm just emailing to let you know that I'd love to say Hi to, or chat with, any of you, here at IETF 93 in Prague. One of the main reasons I come to the meetings, when I can, is to make myself available to you, members of the IETF leadership, ADs, Working Group chairs, and volunteers, in the event that you want to talk about anything related to AMS IT stuff. If you have questions, or comments, or suggestions, just want to talk, have a beer, or throw food at me, I absolutely want to talk to you and meet you here in Prague! I may be moving around quite a bit this meeting, but you can easily reach me in any of the following ways: Google Hangouts or Email: glenams@gmail.com (Most reliable way, text, voice or video!) Google Plus: https://plus.google.com/113536982200502888028 (Circle me or send me a message) Twitter: @glenamstweets (Follow and DM or send me a @mention) Jabber: glen@amsl.com I'm here in Prague through the end of Tuesday, and I will be present and available and hoping to meet as many of you as possible! Thanks! Glen Glen Barney IT Director AMS (IETF Secretariat) --bcaec5015f0bfabffd051b11a74c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings!

For=20 those of you who may not know me, I'm Glen Barney, the IT Director at= =20 AMS, which is the company that provides secretariat and IT services to=20 the IETF. I'm just emailing to let you know that I'd love to say Hi= to, or chat with, any of you, here at IETF 93 in Prague.

One of the main reasons I come to the meetings, when I can, is to make myself available to you, members of the IETF=20 leadership, ADs, Working Group chairs, and=20 volunteers, in the event that you want to talk about anything related to AMS IT stuff.=C2=A0 If you have questions, or comments, or suggestions, ju= st want to talk, have a beer, or throw food at me, I absolutely want to=20 talk to you and meet you here in Prague!

I may be moving = around quite a bit this meeting, but you can easily reach me in any of the = following ways:

Google Hangouts or Email:=C2=A0 glenams@gmail.com=C2=A0 (Most reliable wa= y, text, voice or video!)

Google Plus:=C2=A0 https://plus.google.co= m/113536982200502888028=C2=A0 (Circle me or send me a message)

T= witter:=C2=A0 @glenamstweets (Follow and DM or send me a @mention)

<= /div>
Jabber:=C2=A0 = glen@amsl.com

I'm here in Prague through th= e end of Tuesday, and I will be present and available and hoping=20 to meet as many of you as possible!

Thanks!

Glen
Glen Barney
IT Director
AMS (IET= F Secretariat)
--bcaec5015f0bfabffd051b11a74c-- From nobody Fri Jul 17 16:42:43 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E32D1A92F7 for ; Fri, 17 Jul 2015 16:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 6iipKe9b_DFL for ; Fri, 17 Jul 2015 16:42:40 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB741A92F2 for ; Fri, 17 Jul 2015 16:42:40 -0700 (PDT) Received: from fifthhorseman.net (31.208.broadband18.iol.cz [109.81.208.31]) by che.mayfirst.org (Postfix) with ESMTPSA id 15474F984; Fri, 17 Jul 2015 19:42:37 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id CFFC5200CE; Sat, 18 Jul 2015 01:42:18 +0200 (CEST) From: Daniel Kahn Gillmor To: "Dale R. Worley" , Stephen Farrell In-Reply-To: <878uafmtj0.fsf@hobgoblin.ariadne.com> References: <878uafmtj0.fsf@hobgoblin.ariadne.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sat, 18 Jul 2015 01:42:18 +0200 Message-ID: <87vbdipd0l.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: lynX@the.internet.is.psyced.org, tools-discuss@ietf.org Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 23:42:42 -0000 On Fri 2015-07-17 04:01:39 +0200, Dale R. Worley wrote: > Stephen Farrell writes: >> Is there something we can do to make this better/easier for folks >> who have JS always-off or disallowed for ietf.org? > > Have a web site that doesn't require Javascript? > > I mean, is there any desirable functionality that can't be implemented > on the server side? Should we not classify mandatory Javascript as a > problem self-inflicted by the IETF? > > I'm being a curmudgeon here, but my experience is that 99% of Javascript > is pure eye-candy and often the "features" it implements are as much an > inconvenience for the serious user as they are a benefit. I disagree strongly with this, even though i run my browser with javascript blocked by default. Sites like http://thread.gmane.org/gmane.ietf.tls/ make really good use of javascript for those who allow it. that said, i agree with earlier posters on this discussion that having non-js mail archives available is critically important. i want to be able to send reference links to people without having to ask them about their use of javascript. And of course, maintaining stable URLs over time is also an important goal, particularly for archival groups like the IETF. providing clear, predictable, stable per-message URLs should make it easy to have a javascripty archive interface rewrite the address bar to the relevant location. thanks to all of those who work on maintaining the IETF archives, they're a really valuable resource. --dkg From nobody Sat Jul 18 00:42:44 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42391ACE80 for ; Sat, 18 Jul 2015 00:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 NexcWOqYOKgW for ; Sat, 18 Jul 2015 00:42:42 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 A22D41ACE93 for ; Sat, 18 Jul 2015 00:42:42 -0700 (PDT) Received: by oige126 with SMTP id e126so83135276oig.0 for ; Sat, 18 Jul 2015 00:42:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hQhqu63mgl20Sf196u7nTjo7y87QTpbLJ1WFT4BOkCA=; b=egD5b6NFgUWmYGLdZxaYS/NpuB0Kr1xkxGEHhcbpAAMBIwvx90VVxD2h0k6Ne8XBHo LGqB9kfqXWjjWsUkV1j7JQzaQB4aTFiqHxjmcy15xz4TDUHDi69bVwEX4duqP++YVJiH vCi4dzWykNxGse3Gspu5+FIPQrUQl/NufCzH8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hQhqu63mgl20Sf196u7nTjo7y87QTpbLJ1WFT4BOkCA=; b=fB3c8EFBhBdp1lH0H4/44aTZi0g9DWCFvjyukZqjjJ/vqVjrkWHwtzd0+yBFtFIi0x 9FsdPMKIbaUcVx8C7chXl+YL0Qf2vjEPO6gl033AKrmDsW/VVB09OEa38rs/krKxaGyS 4a9lYlITWyz3dm82wEnwHr8b23H/Zi+bjjbNzofootLrXLcdT1Mq9QUmYXDs+dyxX/hn mCwJk7i/BdUaPDoyTSuxbVk8wgX5s+JZ9ZdJw7i7t46GwQLHdCpdNIb8Ex4+Krse6rsG 3EQBV8ACU93RZXpSK/cwy3Y0Y7TOebw51I3qY0Hrelz+ZbnYAY87rf60QT6sLFwi0O4D h8Ww== X-Gm-Message-State: ALoCoQljFR9P+aFH9Al2U0HevT3eHhhZJP7B0F0Ij8mfVbNgXAqkZRMfApWv4gfJQ+D5lN8bADTl MIME-Version: 1.0 X-Received: by 10.60.145.228 with SMTP id sx4mr16590690oeb.79.1437205362061; Sat, 18 Jul 2015 00:42:42 -0700 (PDT) Received: by 10.60.67.138 with HTTP; Sat, 18 Jul 2015 00:42:41 -0700 (PDT) Received: by 10.60.67.138 with HTTP; Sat, 18 Jul 2015 00:42:41 -0700 (PDT) In-Reply-To: <55A788FE.7080509@cs.tcd.ie> References: <55A788FE.7080509@cs.tcd.ie> Date: Sat, 18 Jul 2015 08:42:41 +0100 Message-ID: From: Dave Cridland To: Stephen Farrell Content-Type: multipart/alternative; boundary=047d7b5d30da13499f051b2173cd Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 07:42:44 -0000 --047d7b5d30da13499f051b2173cd Content-Type: text/plain; charset=UTF-8 On 16 Jul 2015 11:35, "Stephen Farrell" wrote: > Is there something we can do to make this better/easier for folks > who have JS always-off or disallowed for ietf.org? IMAP? I don't believe refusing to use JavaScript on the modern web is a practical choice anymore. It's a nice bit of idealism, and I appreciate the sentiment, but the benefit of JavaScript is that it gives you a deployable client for cases where a bespoke protocol or client may be unavailable. In this case, there's a protocol, widely implemented, that gives the kind of access that Carlo needs. There's thousands of tools available to handle imap in numerous ways, at least some of which must surely meet Carlo's needs. Archive URLs could even deference to html including the imap url, although that is the weakest area of support. Dave. --047d7b5d30da13499f051b2173cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 16 Jul 2015 11:35, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
> Is there something we can do to make this better/easier for folks
> who have JS always-off or disallowed for i= etf.org?

IMAP? I don't believe refusing to use JavaScript on the = modern web is a practical choice anymore. It's a nice bit of idealism, = and I appreciate the sentiment, but the benefit of JavaScript is that it gi= ves you a deployable client for cases where a bespoke protocol or client ma= y be unavailable.

In this case, there's a protocol, widely implemented, th= at gives the kind of access that Carlo needs. There's thousands of tool= s available to handle imap in numerous ways, at least some of which must su= rely meet Carlo's needs. Archive URLs could even deference to html incl= uding the imap url, although that is the weakest area of support.

Dave.

--047d7b5d30da13499f051b2173cd-- From nobody Sat Jul 18 01:03:15 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350FC1ACED4 for ; Sat, 18 Jul 2015 01:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 N19GB1MznqbL for ; Sat, 18 Jul 2015 01:03:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85251ACEC8 for ; Sat, 18 Jul 2015 01:03:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DFBDBE77; Sat, 18 Jul 2015 09:03:11 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03LophhaY0Gz; Sat, 18 Jul 2015 09:03:10 +0100 (IST) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B03CDBE56; Sat, 18 Jul 2015 09:03:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437206589; bh=NnCAuDNXw4djD4ce5iV53HAExq8S1cmsX1OG889HVtE=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=h/aUUKYO85tXGvcCR9TwySYs5Px42GMwMP5CE4kniuZuuoI6+vK1OWpssJRFSVQXK s/8w35oaE4SdsyJR1Lus3ejQz2SA3dLoTA+nWIsu0JiPbHSQTby/2d+jT/jIuij2GG h0rkPubx3xx9otyD/N7rL5AlMc3h9fnvXMmUudmw= Message-ID: <55AA083C.2090802@cs.tcd.ie> Date: Sat, 18 Jul 2015 09:03:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Cridland References: <55A788FE.7080509@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:03:15 -0000 Hiya, On 18/07/15 08:42, Dave Cridland wrote: > On 16 Jul 2015 11:35, "Stephen Farrell" wrote: >> Is there something we can do to make this better/easier for folks >> who have JS always-off or disallowed for ietf.org? > > IMAP? I don't believe refusing to use JavaScript on the modern web is a > practical choice anymore. Well, reasonable folks can disagree. While it may be a relatively small number, NoScript does have a base of users (including me). The mozilla plugins page says that has 2.1M users, though I've no idea how they calculate that of if it's believable. I would conjecture though that we have a higher percentage of IETFers who are part of that set compared to a random person on the Internet. So I would hope that the IETF continues to be cater for the javascript-intolerant as well as we do for the gluten-intolerant:-) S. > It's a nice bit of idealism, and I appreciate the > sentiment, but the benefit of JavaScript is that it gives you a deployable > client for cases where a bespoke protocol or client may be unavailable. > > In this case, there's a protocol, widely implemented, that gives the kind > of access that Carlo needs. There's thousands of tools available to handle > imap in numerous ways, at least some of which must surely meet Carlo's > needs. Archive URLs could even deference to html including the imap url, > although that is the weakest area of support. > > Dave. > From nobody Sat Jul 18 01:05:37 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1766C1ACEC1 for ; Sat, 18 Jul 2015 01:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 06YTn_bJu7Sa for ; Sat, 18 Jul 2015 01:05:34 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 A97C91ACEE0 for ; Sat, 18 Jul 2015 01:05:34 -0700 (PDT) Received: by obre1 with SMTP id e1so77867698obr.1 for ; Sat, 18 Jul 2015 01:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JVlfxS7Aiy04jl1cHOBN1yMhfsxspkuqTDbsUcbS4/M=; b=BeiY+fci1dlaULo1ydHOHNmGtC6SFcVJYbTkIrEMFkMR5BGIIxmXq3+8f1XMrCg+Vs aHz5u1Fbr5zehnKRohvSCc/Jzjqhhp0gXZjHKSdhvrV+yPyVXt1RcbYAESF6BbRuJ/Er i/IrAhMwy4kftzGEccAf5EKuvtPDlN5rOwcHQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JVlfxS7Aiy04jl1cHOBN1yMhfsxspkuqTDbsUcbS4/M=; b=T7hzgiQddCzUtnoy9tDzWa1QdRvFGt4QWFsOfGrU8+I3z8YbhDHiDm/d2HUKmoA65n HLFObDI1NqSVsSxpkm5psMwvsRC6pzKAEkvtn924evtkEo8lBJdLli5U0uekGtllYzni +7SJ5ldBAFz6OEdolWzzj6eOex0Wv34xGd8BboECW1ITp6CDROkV26p7d/WKQpvhCx++ LXweO9tRg8Qs7wvTuTmcvv//Ljnapul5YyJA2TuwCW2kCmTiGMzVdfegukoq8ijHYsq7 FFgg5p/wWMVE7J8nLU/n4g1qiP1+elgXLVKSYXGBzXE3D8+FkS1mH1KZiNnHVNI+nklI L/Kg== X-Gm-Message-State: ALoCoQmjkmN8IihS2hMJXlxiHnIEwvqCVMwPaIQuKsxeQKACUoCyUXvNOx1tteTgYJ3FWrP0LDs4 MIME-Version: 1.0 X-Received: by 10.202.187.138 with SMTP id l132mr16302883oif.31.1437206734195; Sat, 18 Jul 2015 01:05:34 -0700 (PDT) Received: by 10.60.67.138 with HTTP; Sat, 18 Jul 2015 01:05:34 -0700 (PDT) Received: by 10.60.67.138 with HTTP; Sat, 18 Jul 2015 01:05:34 -0700 (PDT) In-Reply-To: <55AA083C.2090802@cs.tcd.ie> References: <55A788FE.7080509@cs.tcd.ie> <55AA083C.2090802@cs.tcd.ie> Date: Sat, 18 Jul 2015 09:05:34 +0100 Message-ID: From: Dave Cridland To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113ccf4adc69c0051b21c4f7 Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:05:36 -0000 --001a113ccf4adc69c0051b21c4f7 Content-Type: text/plain; charset=UTF-8 On 18 Jul 2015 09:03, "Stephen Farrell" wrote: > > > Hiya, > > On 18/07/15 08:42, Dave Cridland wrote: > > On 16 Jul 2015 11:35, "Stephen Farrell" wrote: > >> Is there something we can do to make this better/easier for folks > >> who have JS always-off or disallowed for ietf.org? > > > > IMAP? I don't believe refusing to use JavaScript on the modern web is a > > practical choice anymore. > > Well, reasonable folks can disagree. While it may be a relatively > small number, NoScript does have a base of users (including me). The > mozilla plugins page says that has 2.1M users, though I've no idea > how they calculate that of if it's believable. I would conjecture > though that we have a higher percentage of IETFers who are part of > that set compared to a random person on the Internet. > > So I would hope that the IETF continues to be cater for the > javascript-intolerant as well as we do for the gluten-intolerant:-) > So you'd prefer to use an inappropriate tool inappropriately? > S. > > > It's a nice bit of idealism, and I appreciate the > > sentiment, but the benefit of JavaScript is that it gives you a deployable > > client for cases where a bespoke protocol or client may be unavailable. > > > > In this case, there's a protocol, widely implemented, that gives the kind > > of access that Carlo needs. There's thousands of tools available to handle > > imap in numerous ways, at least some of which must surely meet Carlo's > > needs. Archive URLs could even deference to html including the imap url, > > although that is the weakest area of support. > > > > Dave. > > --001a113ccf4adc69c0051b21c4f7 Content-Type: text/html; charset=UTF-8


On 18 Jul 2015 09:03, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
>
>
> Hiya,
>
> On 18/07/15 08:42, Dave Cridland wrote:
> > On 16 Jul 2015 11:35, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:
> >> Is there something we can do to make this better/easier for folks
> >> who have JS always-off or disallowed for ietf.org?
> >
> > IMAP? I don't believe refusing to use JavaScript on the modern web is a
> > practical choice anymore.
>
> Well, reasonable folks can disagree. While it may be a relatively
> small number, NoScript does have a base of users (including me). The
> mozilla plugins page says that has 2.1M users, though I've no idea
> how they calculate that of if it's believable. I would conjecture
> though that we have a higher percentage of IETFers who are part of
> that set compared to a random person on the Internet.
>
> So I would hope that the IETF continues to be cater for the
> javascript-intolerant as well as we do for the gluten-intolerant:-)
>

So you'd prefer to use an inappropriate tool inappropriately?

> S.
>
> > It's a nice bit of idealism, and I appreciate the
> > sentiment, but the benefit of JavaScript is that it gives you a deployable
> > client for cases where a bespoke protocol or client may be unavailable.
> >
> > In this case, there's a protocol, widely implemented, that gives the kind
> > of access that Carlo needs. There's thousands of tools available to handle
> > imap in numerous ways, at least some of which must surely meet Carlo's
> > needs. Archive URLs could even deference to html including the imap url,
> > although that is the weakest area of support.
> >
> > Dave.
> >

--001a113ccf4adc69c0051b21c4f7-- From nobody Sat Jul 18 01:26:26 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B241AD0CB for ; Sat, 18 Jul 2015 01:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 l6F8cvs40q8Z for ; Sat, 18 Jul 2015 01:26:23 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EC701AD0CA for ; Sat, 18 Jul 2015 01:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4E001BE56; Sat, 18 Jul 2015 09:26:22 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whaWzArES6j2; Sat, 18 Jul 2015 09:26:21 +0100 (IST) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1E1FEBE35; Sat, 18 Jul 2015 09:26:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437207981; bh=HITne6TzRzhgp4mRY90LnpaoYRFJCGjSHmoC58JkVGU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=1vTBps5TyLZeizhhghgkyPdRW/1Aqy4YPX/olwtyE9/cqhR2x6oW1sEqCZx3K5P+B tUAlm++05zfL+7YN3STc7dI3y5iqkj9uHR3E79b44UFxi5TS03jUFXnIoyP8IcEqoF ew/vpCCHXKWYmlkAIKrDpUeUwdi2Sh0gAthC8zHQ= Message-ID: <55AA0DAC.9040708@cs.tcd.ie> Date: Sat, 18 Jul 2015 09:26:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Cridland References: <55A788FE.7080509@cs.tcd.ie> <55AA083C.2090802@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:26:24 -0000 On 18/07/15 09:05, Dave Cridland wrote: > So you'd prefer to use an inappropriate tool inappropriately? I'm not sure what that means, but I wouldn't put it that way for sure:-) All I'd like is that we not forget that there are JS-intolerant folks in the world, in this particular case in relation to mail archives. I am not asking that JS not be used, and in fact I allow JS from ietf.org myself. S. From nobody Sat Jul 18 01:34:35 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF691AD255 for ; Sat, 18 Jul 2015 01:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VoKFcpw_u_PY for ; Sat, 18 Jul 2015 01:34:32 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 B3C5B1AD248 for ; Sat, 18 Jul 2015 01:34:32 -0700 (PDT) Received: by oibn4 with SMTP id n4so83606627oib.3 for ; Sat, 18 Jul 2015 01:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u9Kfmlwfoxm1ut43RDAjrhOomQ14h636Qc+8T4S0z8s=; b=Zi54Ddl0/gS1G3pkuGsHt4Qd3NFauSfebDu3uOhW5Ajnrb2l79pumTWmRHctXTThBr ei4v/i2+aZNsZi1A8iMu8r3trN1ZLZt4GlL2sivfARMj14pF1c3XyYbA4nJyDrd1Mxsq EAZ4qeHq0cX3xGKdy4t9+mtDfybo84y4fye6o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u9Kfmlwfoxm1ut43RDAjrhOomQ14h636Qc+8T4S0z8s=; b=gQFJa8LYS04JFBLycV2SHCunugQGs8LMU4KT2iYW0UyRWjHEmaiaq9vpOBLeiX/pOY f+wr1z44sN0EgglmrTikdgadNtB6PL4j1v1r2zvnZBmup9N26s+yO0j8sR3tU81KZyIf S3ifY25+MbaG0C3U9ko8iUCwsvFx/ca9p0jJayyV6P2jRcyjLy0idmI4iCDAAFxFprHQ IkPIon5RHdCvwOMfrBiP54PrX8NLWpxAhs+zunmIMij5GsJjOADp9h9ffhaf/2awONsW tgiVrwWAC3DVuNDDQfwu5kG/coO863zd9l2FCq7wPDmsJhrpWn2yCTi6TCczO2KSGRvz nApg== X-Gm-Message-State: ALoCoQldH22s9DSp3HHOTdanK+pbV9sdcokohkIuFPWOdsnlsBFxEVz/1+kz544meMC2DwJYoecI MIME-Version: 1.0 X-Received: by 10.60.16.228 with SMTP id j4mr3171933oed.59.1437208472131; Sat, 18 Jul 2015 01:34:32 -0700 (PDT) Received: by 10.60.67.138 with HTTP; Sat, 18 Jul 2015 01:34:32 -0700 (PDT) In-Reply-To: <55AA0DAC.9040708@cs.tcd.ie> References: <55A788FE.7080509@cs.tcd.ie> <55AA083C.2090802@cs.tcd.ie> <55AA0DAC.9040708@cs.tcd.ie> Date: Sat, 18 Jul 2015 09:34:32 +0100 Message-ID: From: Dave Cridland To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e0129403e733e14051b222c8e Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:34:34 -0000 --089e0129403e733e14051b222c8e Content-Type: text/plain; charset=UTF-8 On 18 July 2015 at 09:26, Stephen Farrell wrote: > > > On 18/07/15 09:05, Dave Cridland wrote: > > So you'd prefer to use an inappropriate tool inappropriately? > > I'm not sure what that means, but I wouldn't put it that way > for sure:-) > > All I'd like is that we not forget that there are JS-intolerant > folks in the world, in this particular case in relation to mail > archives. > > I am not asking that JS not be used, and in fact I allow JS from > ietf.org myself. > > Really, IMAP is entirely appropriate for accessing mail archives in near-realtime; this provides a secure access path with no code mobility, and covers a very wide range of uses with existing tools. How is this not handling people who prefer to run their browser with JavaScript turned off? > S. > --089e0129403e733e14051b222c8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 July 2015 at 09:26, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:


On 18/07/15 09:05, Dave Cridland wrote:
> So you'd prefer to use an inappropriate tool inappropriately?

I'm not sure what that means, but I wouldn't put it that way=
for sure:-)

All I'd like is that we not forget that there are JS-intolerant
folks in the world, in this particular case in relation to mail
archives.

I am not asking that JS not be used, and in fact I allow JS from
ietf.org myself.


Really, IMAP is entirely appropriate for accessing m= ail archives in near-realtime; this provides a secure access path with no c= ode mobility, and covers a very wide range of uses with existing tools.
=

How is this not handling people who prefer to run= their browser with JavaScript turned off?
=C2=A0
S.

--089e0129403e733e14051b222c8e-- From nobody Sat Jul 18 01:38:21 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895DC1AD2AF for ; Sat, 18 Jul 2015 01:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 mUMkne8g1UqG for ; Sat, 18 Jul 2015 01:38: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 736D91AD277 for ; Sat, 18 Jul 2015 01:38:18 -0700 (PDT) Received: from dhcp-898a.meeting.ietf.org (dhcp-898a.meeting.ietf.org [31.133.137.138]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6I8c7nL073928 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 18 Jul 2015 03:38:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <55AA106F.9010304@nostrum.com> Date: Sat, 18 Jul 2015 10:38:07 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "tools-discuss@ietf.org Discussion" References: <55A788FE.7080509@cs.tcd.ie> In-Reply-To: <55A788FE.7080509@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:38:19 -0000 On 7/16/15 12:35, Stephen Farrell wrote: > One probably stupid suggestion might be a form where I could > paste in [1] and get a link to that message in mhonarc maybe, > or a link on [1] to the message in mhonarc somewhere on the > page displayed when one de-references [1]? I'll note that the link you point to () has a link in the lower-right corner () that has the property you want (i.e., works fine without javascript). What we need to do is figure out way that biases people to use the latter link rather than the former. /a From nobody Sat Jul 18 01:41:13 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6951A6F12 for ; Sat, 18 Jul 2015 01:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QLCG6eFvnzgx for ; Sat, 18 Jul 2015 01:41:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6981A06FD for ; Sat, 18 Jul 2015 01:41:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C654FBE77; Sat, 18 Jul 2015 09:41:09 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVpK6gscZ3oO; Sat, 18 Jul 2015 09:41:08 +0100 (IST) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3D019BE56; Sat, 18 Jul 2015 09:41:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437208868; bh=/3IVFp5esafJYQ4k8fLGVWC6ip5m7wN1CjhwNIuMX/M=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=aq/J73MCum+6EQhdLGlM3GM2eiXwU3CqBLKLmdqYrh5q5/Ii3rE/QyclcsGRjclY6 fyIQ5Ayj8g2nt7gMWit/KfDf+eudj6BK8h7noC56Pgqf1/BlchWtaYbRF6cRMGbmoW hhUdsgdzOGJMmw2WeylOaM6hqnbPeZBcuC8U/RtI= Message-ID: <55AA1123.5000508@cs.tcd.ie> Date: Sat, 18 Jul 2015 09:41:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Cridland References: <55A788FE.7080509@cs.tcd.ie> <55AA083C.2090802@cs.tcd.ie> <55AA0DAC.9040708@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:41:12 -0000 On 18/07/15 09:34, Dave Cridland wrote: > On 18 July 2015 at 09:26, Stephen Farrell wrote: > >> >> >> On 18/07/15 09:05, Dave Cridland wrote: >>> So you'd prefer to use an inappropriate tool inappropriately? >> >> I'm not sure what that means, but I wouldn't put it that way >> for sure:-) >> >> All I'd like is that we not forget that there are JS-intolerant >> folks in the world, in this particular case in relation to mail >> archives. >> >> I am not asking that JS not be used, and in fact I allow JS from >> ietf.org myself. >> >> > Really, IMAP is entirely appropriate for accessing mail archives in > near-realtime; this provides a secure access path with no code mobility, > and covers a very wide range of uses with existing tools. > > How is this not handling people who prefer to run their browser with > JavaScript turned off? The context here are mail archive URLs in mail discussions. I'm not sure that imap helps really, even though doing the imap stuff is a really good thing. S. > > >> S. >> > From nobody Sat Jul 18 01:43:55 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742151ACD6A for ; Sat, 18 Jul 2015 01:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nsGJ35Js9xfI for ; Sat, 18 Jul 2015 01:43:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5531ACD68 for ; Sat, 18 Jul 2015 01:43:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E2A53BE77; Sat, 18 Jul 2015 09:43:51 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6XBn3sUT3jw; Sat, 18 Jul 2015 09:43:50 +0100 (IST) Received: from [31.133.139.135] (unknown [31.133.139.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 598E1BE56; Sat, 18 Jul 2015 09:43:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437209030; bh=bXRTA+31sL0gVl8VkAtTh5BHXaa9qhWMXX/HfL2fN7o=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=ItWtJxWdfjq00iNCdV4sHKS0nfwAhnYyGLyZINzXsaF1vEQryOQW8NIAPnbL7Cg31 mdz2XzSfCLymjbZh3J+evqpiOXTHhWLsuEVhccR/8Dpsb502uOIxyuoCIj3rBXyQgv D8PYtQ7DX+O2EZurrPwoPinY5rHuRcOMbB2kW5aA= Message-ID: <55AA11C5.8020909@cs.tcd.ie> Date: Sat, 18 Jul 2015 09:43:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Adam Roach , "tools-discuss@ietf.org Discussion" References: <55A788FE.7080509@cs.tcd.ie> <55AA106F.9010304@nostrum.com> In-Reply-To: <55AA106F.9010304@nostrum.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 08:43:54 -0000 On 18/07/15 09:38, Adam Roach wrote: > On 7/16/15 12:35, Stephen Farrell wrote: >> One probably stupid suggestion might be a form where I could >> paste in [1] and get a link to that message in mhonarc maybe, >> or a link on [1] to the message in mhonarc somewhere on the >> page displayed when one de-references [1]? > > I'll note that the link you point to > () > has a link in the lower-right corner > () > that has the property you want (i.e., works fine without javascript). > What we need to do is figure out way that biases people to use the > latter link rather than the former. Yeah, that might be as good as it gets. Or even better might be to also put on the mhonarc link for that message (if that's easy, I've no idea) and then somehow socialise using that one. S. > > /a > > From nobody Sat Jul 18 10:47:04 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B2F1A88C7 for ; Sat, 18 Jul 2015 10:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 NpradGDeOajw for ; Sat, 18 Jul 2015 10:47:01 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC61C1A88C9 for ; Sat, 18 Jul 2015 10:47:00 -0700 (PDT) Received: by wgbcc4 with SMTP id cc4so9762945wgb.3 for ; Sat, 18 Jul 2015 10:46:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jfHMpLNsFkfKWjA6O5dtwQYXgcn6wRwKuTcr3LDBS2A=; b=SRa+sqYfWJwdtG5vh+0iXTcGotqmbvh0QuakE75ZdcbqywbgjPokMfqHKk1edD/EBN 363uNj/KeVUdrUbmako6Q3IeyN8pytOGg4D8dH4mDAaZhzVIB3IsloFSvCeXTWKsUHG1 ZwjbE9iISHNW/pJVRsrH/uK2wJdVR32MHQQ2HCK5a5mmantRo7b37e++ToKx7EickoJ6 waSGMMtmqrgGGS6d/TfHClagByLcUxqGRnGf+HRqgB36cfwUokspVVl6q7Ku97fXzA9y NofeiUC8aewwAoEOiM/YESHuAWz2l6GQcdtX6yL8bh9Meh84F56B1VW+ykKcA1Pc+uu0 LFdQ== X-Received: by 10.194.57.170 with SMTP id j10mr39764427wjq.140.1437241619591; Sat, 18 Jul 2015 10:46:59 -0700 (PDT) Received: from [31.133.139.123] ([31.133.139.123]) by smtp.gmail.com with ESMTPSA id l6sm3446830wib.18.2015.07.18.10.46.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Jul 2015 10:46:58 -0700 (PDT) Message-ID: <55AA9111.5000208@gmail.com> Date: Sun, 19 Jul 2015 05:46:57 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , Dave Cridland References: <55A788FE.7080509@cs.tcd.ie> <55AA083C.2090802@cs.tcd.ie> <55AA0DAC.9040708@cs.tcd.ie> <55AA1123.5000508@cs.tcd.ie> In-Reply-To: <55AA1123.5000508@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: carlo von lynX , Tools Team Discussion Subject: Re: [Tools-discuss] mail archives without JS X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 17:47:03 -0000 On 18/07/2015 20:41, Stephen Farrell wrote: > > > On 18/07/15 09:34, Dave Cridland wrote: >> On 18 July 2015 at 09:26, Stephen Farrell wrote: >> >>> >>> >>> On 18/07/15 09:05, Dave Cridland wrote: >>>> So you'd prefer to use an inappropriate tool inappropriately? >>> >>> I'm not sure what that means, but I wouldn't put it that way >>> for sure:-) >>> >>> All I'd like is that we not forget that there are JS-intolerant >>> folks in the world, in this particular case in relation to mail >>> archives. >>> >>> I am not asking that JS not be used, and in fact I allow JS from >>> ietf.org myself. >>> >>> >> Really, IMAP is entirely appropriate for accessing mail archives in >> near-realtime; this provides a secure access path with no code mobility, >> and covers a very wide range of uses with existing tools. >> >> How is this not handling people who prefer to run their browser with >> JavaScript turned off? > > The context here are mail archive URLs in mail discussions. I'm not > sure that imap helps really, even though doing the imap stuff is a > really good thing. I dare say there is an IMAP use case, so an IMAP-accessible archive is a fine thing. But there is a use case for an HTTP(S)-accessible date or thread based archive (when looking for one specific message in a long thead, or for a thread whose date one vaguely remembers). I need that much more frequently than any other kind of archive search, and so far I have found the new tool too clumsy and slow for this kind of search. And no, I don't like the format of https://mailarchive.ietf.org/arch/msg/rtcweb/VnStGD7Emmvc1-QOPRtY2cFF79E as much as http://www.ietf.org/mail-archive/web/rtcweb/current/msg14136.html although both have some advantages over the other. Brian From nobody Sun Jul 19 03:50:29 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950651AC414 for ; Sun, 19 Jul 2015 03:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 EqIMPT_AwlMu for ; Sun, 19 Jul 2015 03:50:25 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB651AC413 for ; Sun, 19 Jul 2015 03:50:24 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id de08ba55.0.1286575.00-2191.3618041.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 19 Jul 2015 10:50:25 +0000 (UTC) X-MXL-Hash: 55ab80f17b5132ca-2cf02c9457235de753d82a70f10a47cf77b7dfc0 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 t6JAoLVm029995 for ; Sun, 19 Jul 2015 06:50:21 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6JAoCCX029933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 19 Jul 2015 06:50:16 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Sun, 19 Jul 2015 10:50:07 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6JAo752015989 for ; Sun, 19 Jul 2015 06:50:07 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6JAnw01015364 for ; Sun, 19 Jul 2015 06:49:58 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.240.119](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150719104954gw1000cepee>; Sun, 19 Jul 2015 10:49:56 +0000 X-Originating-IP: [135.110.240.119] Message-ID: <55AB80CF.2030307@att.com> Date: Sun, 19 Jul 2015 06:49:51 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tools Team Discussion Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=JfoLWz2V c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=tHvJy1wsfNMA:10 a=Q0LpwwsZAhIA:10 a=zOBT] X-AnalysisOut: [XjUuO1YA:10 a=48vgC7mUAAAA:8 a=slMX1fRx2l5zcr4q5JkA:9 a=QE] X-AnalysisOut: [XdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: [Tools-discuss] question on datatracker access to particular I-D version X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 10:50:27 -0000 I'm working on generating bibxml3 (bibxml for internet drafts) via django and the datatracker database. Is there a way to pull up a >particular version< of an I-D on the datatracker via the URL? That is, URLs such as http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf?version=3D02 http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 as opposed to http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf which pulls up the final document and lets you get at the earlier versions after additional clicks. Tony Hansen Full discussion: I'm also looking at the possibility of making an update to remove the entries and replacing them with a target on the element. I had *thought* that I could do this using a reference to the datatracker copy of the internet drafts. But there is an issue. For each internet draft, e.g. draft-ietf-example-foo-*, there are at least two entries: reference.I-D.draft-ietf-example-foo-00.xml =20 reference.I-D.ietf-example-foo.xml That is, there is a specific entry for each version of the document with the complete name of the document and version, PLUS a single entry for the document >series< that does not have any version number or the leading "draft-" prefix. This last entry is updated whenever a new version is created Picking a draft at random, and doing an ls -l on its variants shows this:= -r--r--r-- 1 tony tony 986 Jun 26 2014 reference.I-D.draft-hansen-rfc-use-of-pdf-00.xml -r--r--r-- 1 tony tony 1096 Jul 21 2014 reference.I-D.draft-hansen-rfc-use-of-pdf-01.xml -r--r--r-- 1 tony tony 1089 Jul 22 2014 reference.I-D.draft-hansen-rfc-use-of-pdf-02.xml -r--r--r-- 1 tony tony 982 Oct 27 2014 reference.I-D.draft-hansen-rfc-use-of-pdf-03.xml -r--r--r-- 1 tony tony 982 Jan 23 00:00 reference.I-D.draft-hansen-rfc-use-of-pdf-04.xml -r--r--r-- 1 tony tony 983 Feb 17 00:00 reference.I-D.draft-hansen-rfc-use-of-pdf-05.xml -r--r--r-- 1 tony tony 1089 Mar 9 00:00 reference.I-D.draft-hansen-rfc-use-of-pdf-06.xml -r--r--r-- 1 tony tony 1090 Mar 25 00:00 reference.I-D.draft-hansen-rfc-use-of-pdf-07.xml -r--r--r-- 1 tony tony 1090 Mar 25 00:00 reference.I-D.hansen-rfc-use-of-pdf.xml Currently the document series entry is always identical to the largest-numbered entry. The relevant bits of one of these files (-02) for this discussion are: I could certainly do a direct move of the existing target so that we get But that doesn't use the datatracker like I wanted. I could make the document series entry different from the individual-document entry, as in: But I don't know of any way to pull up a particular version of the I-D on the datatracker via the command line. That is, URLs such as http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 So, unless I can find a way to reference the individual version of a document on the datatracker, the individual-document entries would need to continue using the www.ietf.org/internet-drafts URL instead of a datatracker URL. From nobody Sun Jul 19 04:11:44 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BDC1ACCE5 for ; Sun, 19 Jul 2015 04:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 58f7TwRsf-2a for ; Sun, 19 Jul 2015 04:11:41 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B9151ACCE4 for ; Sun, 19 Jul 2015 04:11:41 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so3789512wib.1 for ; Sun, 19 Jul 2015 04:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vQRyTwGSMU/BQ2pxohPgaMRRuzD5ICZJ9qGAlKt1WzU=; b=qucb2ju/ixDRqCBajeRhwClWZl5Qh1bT80RBHPWWJyFOGQDFazowp1YU3QUPJxpGOD 7blF9pF3gFZIr5BxqHx+VVL1/iWY07syFMMihAppzkcuPwW8gvH0GXiKFTA5/lGzPVp5 3x649SgYgN0FJLq80caCUkBcQqS93sRtfzJwEl8K8B//UDAAAESXlNpLPpZjM7Zuapkj VwvlI/XmTPCsVk7VINy88LBnp4aCsQqyVT1p/yPEmuWFq8HppUhqLsivi+A73645Q8yz CTrpyXIVLr5Q39AI5L9Nmmcz8XO/UBlJoymwR2SKuBLlDsfEdvBzbrVyQPIFsElziC0a kRVA== X-Received: by 10.194.121.100 with SMTP id lj4mr45539837wjb.104.1437304300075; Sun, 19 Jul 2015 04:11:40 -0700 (PDT) Received: from ?IPv6:2001:67c:370:176:28cc:dc4c:9703:6781? ([2001:67c:370:176:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id m10sm6556187wib.17.2015.07.19.04.11.38 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Jul 2015 04:11:39 -0700 (PDT) Message-ID: <55AB85ED.90103@gmail.com> Date: Sun, 19 Jul 2015 23:11:41 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tony Hansen , Tools Team Discussion References: <55AB80CF.2030307@att.com> In-Reply-To: <55AB80CF.2030307@att.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] question on datatracker access to particular I-D version X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 11:11:43 -0000 It seems to me that there's a bug. Go to https://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02/ The links for html and pdf formats bring up the -02 version, as expected. The link for txt format brings up the latest version. Regards Brian On 19/07/2015 22:49, Tony Hansen wrote: > I'm working on generating bibxml3 (bibxml for internet drafts) via > django and the datatracker database. > > Is there a way to pull up a >particular version< of an I-D on the > datatracker via the URL? > > That is, URLs such as > > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf?version=02 > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 > > as opposed to > > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf > > which pulls up the final document and lets you get at the earlier > versions after additional clicks. > > > Tony Hansen > > Full discussion: > > I'm also looking at the possibility of making an update to remove the > entries and replacing them with a target on the > element. > > I had *thought* that I could do this using a reference to the > datatracker copy of the internet drafts. But there is an issue. > > For each internet draft, e.g. draft-ietf-example-foo-*, there are at > least two entries: > > reference.I-D.draft-ietf-example-foo-00.xml > reference.I-D.ietf-example-foo.xml > > That is, there is a specific entry for each version of the document with > the complete name of the document and version, PLUS a single entry for > the document >series< that does not have any version number or the > leading "draft-" prefix. This last entry is updated whenever a new > version is created > > Picking a draft at random, and doing an ls -l on its variants shows this: > > -r--r--r-- 1 tony tony 986 Jun 26 2014 > reference.I-D.draft-hansen-rfc-use-of-pdf-00.xml > -r--r--r-- 1 tony tony 1096 Jul 21 2014 > reference.I-D.draft-hansen-rfc-use-of-pdf-01.xml > -r--r--r-- 1 tony tony 1089 Jul 22 2014 > reference.I-D.draft-hansen-rfc-use-of-pdf-02.xml > -r--r--r-- 1 tony tony 982 Oct 27 2014 > reference.I-D.draft-hansen-rfc-use-of-pdf-03.xml > -r--r--r-- 1 tony tony 982 Jan 23 00:00 > reference.I-D.draft-hansen-rfc-use-of-pdf-04.xml > -r--r--r-- 1 tony tony 983 Feb 17 00:00 > reference.I-D.draft-hansen-rfc-use-of-pdf-05.xml > -r--r--r-- 1 tony tony 1089 Mar 9 00:00 > reference.I-D.draft-hansen-rfc-use-of-pdf-06.xml > -r--r--r-- 1 tony tony 1090 Mar 25 00:00 > reference.I-D.draft-hansen-rfc-use-of-pdf-07.xml > > -r--r--r-- 1 tony tony 1090 Mar 25 00:00 > reference.I-D.hansen-rfc-use-of-pdf.xml > > > Currently the document series entry is always identical to the > largest-numbered entry. > > > The relevant bits of one of these files (-02) for this discussion are: > > > value='draft-hansen-rfc-use-of-pdf-02' /> > target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt' > /> > > > I could certainly do a direct move of the existing target so that we get > > target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt'> > value='draft-hansen-rfc-use-of-pdf-02' /> > > > But that doesn't use the datatracker like I wanted. > > I could make the document series entry different from the > individual-document entry, as in: > > target='http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf'> > value='draft-hansen-rfc-use-of-pdf-07' /> > > > > > But I don't know of any way to pull up a particular version of the I-D > on the datatracker via the command line. That is, URLs such as > > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt > http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 > > So, unless I can find a way to reference the individual version of a > document on the datatracker, the individual-document entries would need > to continue using the www.ietf.org/internet-drafts URL instead of a > datatracker URL. > From nobody Sun Jul 19 04:26:09 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A26F1ACD0C for ; Sun, 19 Jul 2015 04:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 TdF_F5684A7h for ; Sun, 19 Jul 2015 04:26:06 -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 136841ACCEC for ; Sun, 19 Jul 2015 04:26:06 -0700 (PDT) Received: from dhcp-b65f.meeting.ietf.org (dhcp-b65f.meeting.ietf.org [31.133.182.95]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6JBQ22X036363 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Sun, 19 Jul 2015 06:26:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <55AB8949.8050705@nostrum.com> Date: Sun, 19 Jul 2015 13:26:01 +0200 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <55AB80CF.2030307@att.com> <55AB85ED.90103@gmail.com> In-Reply-To: <55AB85ED.90103@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] question on datatracker access to particular I-D version X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 11:26:08 -0000 Good find, Brian - I'll find the right folks to look at what happens there. (Specifically, referencing https://www.ietf.org/id/draft-hansen-rfc-use-of-pdf-02.txt results in a redirect to http://www.ietf.org/id/draft-hansen-rfc-use-of-pdf-07.txt which has more than one problem.) As you note the /doc/(doc-name)/(version-number) form is what Tony is looking for at the datatracker. RjS On 7/19/15 1:11 PM, Brian E Carpenter wrote: > It seems to me that there's a bug. > > Go to https://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02/ > > The links for html and pdf formats bring up the -02 version, as expected. > The link for txt format brings up the latest version. > > Regards > Brian > > > On 19/07/2015 22:49, Tony Hansen wrote: >> I'm working on generating bibxml3 (bibxml for internet drafts) via >> django and the datatracker database. >> >> Is there a way to pull up a >particular version< of an I-D on the >> datatracker via the URL? >> >> That is, URLs such as >> >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf?version=02 >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 >> >> as opposed to >> >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf >> >> which pulls up the final document and lets you get at the earlier >> versions after additional clicks. >> >> >> Tony Hansen >> >> Full discussion: >> >> I'm also looking at the possibility of making an update to remove the >> entries and replacing them with a target on the >> element. >> >> I had *thought* that I could do this using a reference to the >> datatracker copy of the internet drafts. But there is an issue. >> >> For each internet draft, e.g. draft-ietf-example-foo-*, there are at >> least two entries: >> >> reference.I-D.draft-ietf-example-foo-00.xml >> reference.I-D.ietf-example-foo.xml >> >> That is, there is a specific entry for each version of the document with >> the complete name of the document and version, PLUS a single entry for >> the document >series< that does not have any version number or the >> leading "draft-" prefix. This last entry is updated whenever a new >> version is created >> >> Picking a draft at random, and doing an ls -l on its variants shows this: >> >> -r--r--r-- 1 tony tony 986 Jun 26 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-00.xml >> -r--r--r-- 1 tony tony 1096 Jul 21 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-01.xml >> -r--r--r-- 1 tony tony 1089 Jul 22 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-02.xml >> -r--r--r-- 1 tony tony 982 Oct 27 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-03.xml >> -r--r--r-- 1 tony tony 982 Jan 23 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-04.xml >> -r--r--r-- 1 tony tony 983 Feb 17 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-05.xml >> -r--r--r-- 1 tony tony 1089 Mar 9 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-06.xml >> -r--r--r-- 1 tony tony 1090 Mar 25 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-07.xml >> >> -r--r--r-- 1 tony tony 1090 Mar 25 00:00 >> reference.I-D.hansen-rfc-use-of-pdf.xml >> >> >> Currently the document series entry is always identical to the >> largest-numbered entry. >> >> >> The relevant bits of one of these files (-02) for this discussion are: >> >> >> > value='draft-hansen-rfc-use-of-pdf-02' /> >> > target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt' >> /> >> >> >> I could certainly do a direct move of the existing target so that we get >> >> > target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt'> >> > value='draft-hansen-rfc-use-of-pdf-02' /> >> >> >> But that doesn't use the datatracker like I wanted. >> >> I could make the document series entry different from the >> individual-document entry, as in: >> >> > target='http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf'> >> > value='draft-hansen-rfc-use-of-pdf-07' /> >> >> >> >> >> But I don't know of any way to pull up a particular version of the I-D >> on the datatracker via the command line. That is, URLs such as >> >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 >> >> So, unless I can find a way to reference the individual version of a >> document on the datatracker, the individual-document entries would need >> to continue using the www.ietf.org/internet-drafts URL instead of a >> datatracker URL. >> From nobody Sun Jul 19 05:04:51 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A986C1ACDF0 for ; Sun, 19 Jul 2015 05:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zNleR4IsfJAL for ; Sun, 19 Jul 2015 05:04:47 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4FFC1ACD92 for ; Sun, 19 Jul 2015 05:04:05 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 5329ba55.0.1302996.00-2342.3663634.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 19 Jul 2015 12:04:05 +0000 (UTC) X-MXL-Hash: 55ab92356c6105a8-634449f720ea7cf699cf0d2c78d1d35fce2e05d3 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 t6JC440U016672 for ; Sun, 19 Jul 2015 08:04:04 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6JC3xTE016649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 19 Jul 2015 08:03:59 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Sun, 19 Jul 2015 12:03:38 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6JC3c4I012228 for ; Sun, 19 Jul 2015 08:03:38 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t6JC3UUa011927 for ; Sun, 19 Jul 2015 08:03:30 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.241.133](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150719120329gw1000cepfe>; Sun, 19 Jul 2015 12:03:29 +0000 X-Originating-IP: [135.110.241.133] Message-ID: <55AB9210.10207@att.com> Date: Sun, 19 Jul 2015 08:03:28 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Tools Team Discussion References: <55AB80CF.2030307@att.com> <55AB85ED.90103@gmail.com> In-Reply-To: <55AB85ED.90103@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=JfoLWz2V c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=zQP7CpKOAAAA:8 a=tHvJy1wsfNMA:10 a=XNgVQj4vTswA:10 a=zOBT] X-AnalysisOut: [XjUuO1YA:10 a=48vgC7mUAAAA:8 a=ssDXTBX-o_KJqJa2oGgA:9 a=QE] X-AnalysisOut: [XdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [Tools-discuss] question on datatracker access to particular I-D version X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 12:04:49 -0000 ah, excellent. I thought I had tried that particular variation, but I guess I didn't. Thanks! Tony On 7/19/15 7:11 AM, Brian E Carpenter wrote: > It seems to me that there's a bug. > > Go to https://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02/ > > The links for html and pdf formats bring up the -02 version, as expected. > The link for txt format brings up the latest version. > > Regards > Brian > > > On 19/07/2015 22:49, Tony Hansen wrote: >> I'm working on generating bibxml3 (bibxml for internet drafts) via >> django and the datatracker database. >> >> Is there a way to pull up a >particular version< of an I-D on the >> datatracker via the URL? >> >> That is, URLs such as >> >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf?version=02 >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 >> >> as opposed to >> >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf >> >> which pulls up the final document and lets you get at the earlier >> versions after additional clicks. >> >> >> Tony Hansen >> >> Full discussion: >> >> I'm also looking at the possibility of making an update to remove the >> entries and replacing them with a target on the >> element. >> >> I had *thought* that I could do this using a reference to the >> datatracker copy of the internet drafts. But there is an issue. >> >> For each internet draft, e.g. draft-ietf-example-foo-*, there are at >> least two entries: >> >> reference.I-D.draft-ietf-example-foo-00.xml >> reference.I-D.ietf-example-foo.xml >> >> That is, there is a specific entry for each version of the document with >> the complete name of the document and version, PLUS a single entry for >> the document >series< that does not have any version number or the >> leading "draft-" prefix. This last entry is updated whenever a new >> version is created >> >> Picking a draft at random, and doing an ls -l on its variants shows this: >> >> -r--r--r-- 1 tony tony 986 Jun 26 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-00.xml >> -r--r--r-- 1 tony tony 1096 Jul 21 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-01.xml >> -r--r--r-- 1 tony tony 1089 Jul 22 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-02.xml >> -r--r--r-- 1 tony tony 982 Oct 27 2014 >> reference.I-D.draft-hansen-rfc-use-of-pdf-03.xml >> -r--r--r-- 1 tony tony 982 Jan 23 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-04.xml >> -r--r--r-- 1 tony tony 983 Feb 17 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-05.xml >> -r--r--r-- 1 tony tony 1089 Mar 9 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-06.xml >> -r--r--r-- 1 tony tony 1090 Mar 25 00:00 >> reference.I-D.draft-hansen-rfc-use-of-pdf-07.xml >> >> -r--r--r-- 1 tony tony 1090 Mar 25 00:00 >> reference.I-D.hansen-rfc-use-of-pdf.xml >> >> >> Currently the document series entry is always identical to the >> largest-numbered entry. >> >> >> The relevant bits of one of these files (-02) for this discussion are: >> >> >> > value='draft-hansen-rfc-use-of-pdf-02' /> >> > target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt' >> /> >> >> >> I could certainly do a direct move of the existing target so that we get >> >> > target='http://www.ietf.org/internet-drafts/draft-hansen-rfc-use-of-pdf-02.txt'> >> > value='draft-hansen-rfc-use-of-pdf-02' /> >> >> >> But that doesn't use the datatracker like I wanted. >> >> I could make the document series entry different from the >> individual-document entry, as in: >> >> > target='http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf'> >> > value='draft-hansen-rfc-use-of-pdf-07' /> >> >> >> >> >> But I don't know of any way to pull up a particular version of the I-D >> on the datatracker via the command line. That is, URLs such as >> >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02 >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf-02.txt >> http://datatracker.ietf.org/doc/draft-hansen-rfc-use-of-pdf/02 >> >> So, unless I can find a way to reference the individual version of a >> document on the datatracker, the individual-document entries would need >> to continue using the www.ietf.org/internet-drafts URL instead of a >> datatracker URL. >> From nobody Fri Jul 24 02:59:36 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBBB1A0377 for ; Fri, 24 Jul 2015 02:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ia2VmfmCOMyx for ; Fri, 24 Jul 2015 02:59:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501261A0122 for ; Fri, 24 Jul 2015 02:59:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5BF32BE58; Fri, 24 Jul 2015 10:59:31 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_Kw_ATagsRO; Fri, 24 Jul 2015 10:59:29 +0100 (IST) Received: from [31.133.179.222] (dhcp-b3de.meeting.ietf.org [31.133.179.222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AF721BE35; Fri, 24 Jul 2015 10:59:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1437731969; bh=36jmzD3zW0OzOPWWJASzD/Bk4YyAvecLQWp9RU7q9eU=; h=Date:From:To:CC:Subject:From; b=jkWkmABgLo3ZZmTXbie6x31qV23CCjaMIcPPY9PXoXRklnWJc3bbx8YyBSLSE72o/ G/zXOzyaaIwWSKT+BxgQxGOEQQApEAEZUcaOdObgKYNvNMsQlFW1yX7PiE9gcdb/RQ QUBazJZiwZlg9YIZTvFR9c3D+AGBmajXW2zNZXpE= Message-ID: <55B20C7F.8040106@cs.tcd.ie> Date: Fri, 24 Jul 2015 10:59:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "tools-discuss@ietf.org Discussion" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Yoav Nir , tokbind-chairs@tools.ietf.org Subject: [Tools-discuss] weird tokbind wg page results X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 09:59:35 -0000 Hiya, Yoav (cc'd) and I are accessing [1] and his browser shows this as a concluded wG, whereas mine correctly shows this as an active WG. Using wget both of us see it as active. I guess this is some weird scripting thing somewhere. Yoav can tell you browser details. (Mine's FF-latest/ubuntu-latest). Any ideas? Ta, S. [1] https://tools.ietf.org/wg/tokbind/ From nobody Fri Jul 24 10:10:02 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06A31A0029 for ; Fri, 24 Jul 2015 10:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 uZvNOEI0-yI5 for ; Fri, 24 Jul 2015 10:09:59 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 357021A0064 for ; Fri, 24 Jul 2015 10:09:58 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 240AA134D3D24 for ; Fri, 24 Jul 2015 17:09:52 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6OH9tFc012429 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jul 2015 19:09:55 +0200 Received: from [135.224.220.40] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 24 Jul 2015 19:09:55 +0200 Message-ID: <55B27162.8010002@alcatel-lucent.com> Date: Fri, 24 Jul 2015 19:09:54 +0200 From: Martin Vigoureux User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.39] Archived-At: Subject: [Tools-discuss] heritage through replacement? X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 17:10:00 -0000 Hi, as Shepherd of draft-ietf-l2vpn-spbm-evpn-02 I had prepared the write-up for the document. I had also done a review of the doc. The author decided to republish as draft-ietf-bess-spbm-evpn-00. I had no opposition to that since the item is being handled by BESS since the closure of L2VPN. However when I marked draft-ietf-l2vpn-... as replaced by draft-ietf-bess-... I realized that the latter did not inherit the characteristics of the former (intended status, state, write-up, shepherd, ...). I had no precise expectation regarding that rather I was curious to know what would be the result. Now that I know, I wonder if some characteristics shouldn't be copied from one to the other, or even ideally that we be given the choice of what to replicate. Thoughts? -m From nobody Sat Jul 25 06:41:52 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D52411B2FCF for ; Sat, 25 Jul 2015 06:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rDycx9ey46iW for ; Sat, 25 Jul 2015 06:41:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700361B2FCE for ; Sat, 25 Jul 2015 06:41:46 -0700 (PDT) x-m-msg: CPCHECK Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id t6PDfaVo024758; Sat, 25 Jul 2015 16:41:36 +0300 Received: from IL-EX10.ad.checkpoint.com ([169.254.2.184]) by DAG-EX10.ad.checkpoint.com ([169.254.3.39]) with mapi id 14.03.0248.002; Sat, 25 Jul 2015 16:41:36 +0300 From: Yoav Nir To: Stephen Farrell , "tools-discuss@ietf.org Discussion" Thread-Topic: weird tokbind wg page results Thread-Index: AQHQxfd1gXuiSgY1G0qv0zv93DxgE53sMxcA Date: Sat, 25 Jul 2015 13:41:35 +0000 Message-ID: <4613980CFC78314ABFD7F85CC30277210129EA721F@IL-EX10.ad.checkpoint.com> References: <55B20C7F.8040106@cs.tcd.ie> In-Reply-To: <55B20C7F.8040106@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.29.34.193] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11c27c60d324f082ed8936e56a396bffbb496f5d2d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tokbind-chairs@tools.ietf.org" Subject: Re: [Tools-discuss] weird tokbind wg page results X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 13:41:51 -0000 SSBtYW5hZ2VkIHRvIHNlZSBpdCBvbiBib3RoIFNhZmFyaSBhbmQgRkYtbGF0ZXN0IGFuZCBieSBm ZXRjaGluZyB3aXRoIHdnZXQuDQoNCk5vdyBJIGRvbid0IHNlZSBpdCBhbnltb3JlLg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJyZWxsIFttYWlsdG86c3Rl cGhlbi5mYXJyZWxsQGNzLnRjZC5pZV0gDQpTZW50OiBGcmlkYXksIEp1bHkgMjQsIDIwMTUgMTI6 NTkgUE0NClRvOiB0b29scy1kaXNjdXNzQGlldGYub3JnIERpc2N1c3Npb24NCkNjOiBZb2F2IE5p cjsgdG9rYmluZC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IHdlaXJkIHRva2JpbmQg d2cgcGFnZSByZXN1bHRzDQoNCg0KSGl5YSwNCg0KWW9hdiAoY2MnZCkgYW5kIEkgYXJlIGFjY2Vz c2luZyBbMV0gYW5kIGhpcyBicm93c2VyIHNob3dzIHRoaXMgYXMgYSBjb25jbHVkZWQgd0csIHdo ZXJlYXMgbWluZSBjb3JyZWN0bHkgc2hvd3MgdGhpcyBhcyBhbiBhY3RpdmUgV0cuIFVzaW5nIHdn ZXQgYm90aCBvZiB1cyBzZWUgaXQgYXMgYWN0aXZlLg0KDQpJIGd1ZXNzIHRoaXMgaXMgc29tZSB3 ZWlyZCBzY3JpcHRpbmcgdGhpbmcgc29tZXdoZXJlLiBZb2F2IGNhbiB0ZWxsIHlvdSBicm93c2Vy IGRldGFpbHMuIChNaW5lJ3MgRkYtbGF0ZXN0L3VidW50dS1sYXRlc3QpLg0KDQpBbnkgaWRlYXM/ DQoNClRhLA0KUy4NCg0KWzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvdG9rYmluZC8NCg0K RW1haWwgc2VjdXJlZCBieSBDaGVjayBQb2ludC4NCg== From nobody Wed Jul 29 12:30:14 2015 Return-Path: X-Original-To: tools-discuss@ietfa.amsl.com Delivered-To: tools-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74111ACEE1 for ; Wed, 29 Jul 2015 12:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 emtowI9Ye_al for ; Wed, 29 Jul 2015 12:30:11 -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 8066F1ACEE0 for ; Wed, 29 Jul 2015 12:30:11 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t6TJUAWk006990 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Wed, 29 Jul 2015 14:30:11 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <55B929BD.2050609@nostrum.com> Date: Wed, 29 Jul 2015 14:30:05 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tools-discuss@ietf.org References: <55B20C7F.8040106@cs.tcd.ie> <4613980CFC78314ABFD7F85CC30277210129EA721F@IL-EX10.ad.checkpoint.com> In-Reply-To: <4613980CFC78314ABFD7F85CC30277210129EA721F@IL-EX10.ad.checkpoint.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Tools-discuss] weird tokbind wg page results X-BeenThere: tools-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IETF Tools Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 19:30:12 -0000 It's a server sync issue. One of the servers returned in an A lookup for tools.ietf.org is confused. RjS On 7/25/15 8:41 AM, Yoav Nir wrote: > I managed to see it on both Safari and FF-latest and by fetching with wget. > > Now I don't see it anymore. > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, July 24, 2015 12:59 PM > To: tools-discuss@ietf.org Discussion > Cc: Yoav Nir; tokbind-chairs@tools.ietf.org > Subject: weird tokbind wg page results > > > Hiya, > > Yoav (cc'd) and I are accessing [1] and his browser shows this as a concluded wG, whereas mine correctly shows this as an active WG. Using wget both of us see it as active. > > I guess this is some weird scripting thing somewhere. Yoav can tell you browser details. (Mine's FF-latest/ubuntu-latest). > > Any ideas? > > Ta, > S. > > [1] https://tools.ietf.org/wg/tokbind/ > > Email secured by Check Point.