[TLS] who do I poke to fix the URLs in the header?

Dave Garrett <davemgarrett@gmail.com> Thu, 30 April 2015 00:35 UTC

Return-Path: <davemgarrett@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1A2F31A8A63 for <tls@ietfa.amsl.com>; Wed, 29 Apr 2015 17:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BOmv2ZDJLOM8 for <tls@ietfa.amsl.com>; Wed, 29 Apr 2015 17:35:24 -0700 (PDT)
Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 498F21A8A55 for <tls@ietf.org>; Wed, 29 Apr 2015 17:35:24 -0700 (PDT)
Received: by qkgx75 with SMTP id x75so25243114qkg.1 for <tls@ietf.org>; Wed, 29 Apr 2015 17:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=FK1Sf3fnYzJn+mWEarVmKTkn8F/EkYMTAtV6R0P5kuE=; b=YMqlarOwEYVmfDDGWz4i1DSgZJ6OIJy2A/Acd2ymc1LTZ6bc3jX96XFywToakFEfQN v6h0ou0OQ1QxMasX+AoixG8PhbrbG4c4U3W0u54+2HBbGx6kZuszORMazkjqIxW3U+Fj i+I0L1rJ51Kc/q8yi3U7TsryiIWuwDMssOlT3cn96ST6suPs8nSLPPw5HvXME9pjIp65 GZ9qilNHesm9W2qQ6Lv2pfMKNhn+3W17FyVHPRsFX+hQxudpmSqsds0cUz8xdadfln5v NNYbIoHPXw0WzYDEhauq7OLuPdJnlC4v7wkCKSWJEUfEAJB5AScHhpV/8YQKNxE/gx5X nD9A==
X-Received: by with SMTP id p62mr1973292qha.76.1430354123579; Wed, 29 Apr 2015 17:35:23 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. []) by mx.google.com with ESMTPSA id n62sm395976qge.27.2015. for <tls@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 29 Apr 2015 17:35:22 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Wed, 29 Apr 2015 20:35:21 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201504292035.21721.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/AgDJxKFbIECkHlKbV36lx_X3hX0>
Subject: [TLS] who do I poke to fix the URLs in the header?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Apr 2015 00:35:26 -0000


Where does the "Status of This Memo" and "Copyright Notice" text get pulled from? There seems to be some black magic involved in the build process, and I don't see where that text lives. I'd like to request the two URLs be updated, but I don't know where to ask.

status has:
which redirects to:
which does support TLS, and should be:

copyright has:
which redirects to:
which does support TLS, and should be:
the initial URL also supports TLS, so this works:
however that redirects to HTTP, not HTTPS (...sigh)

So, yeah... I'd like the new TLS spec to actually attempt to use TLS in its URLs, where possible. To do this needs:
1) Update those two URLs in the template for these sections to use the HTTPS equivalent (in the case of "status", also change "current" to "active").
2) Get someone to fix the redirects on trustee.ietf.org to redirect to HTTPS, at minimum when already coming from HTTPS.

Actually using TLS by default might also be a plan...

As to other URLs in the document, I added a couple 's'es in my minor fixes branch/PR. There are additional domains that do support HTTPS, technically, but they get cert errors... because of course they do.

The RFC references have an odd inconsistency here. In the numbered working group drafts, they properly generate with HTTPS links:
However, in the editor's copy (draft-ietf-tls-tls13-latest), they generate with HTTP links:

That needs fixing if just for consistency.

Also, tools.ietf.org should of course be using HTTPS by default, but it's not.