IETF Logo Mail Archive

Re: [TLS] [Cfrg] Citing specs in specs

Jon Callas <jon@callas.org> Mon, 03 March 2014 06:52 UTC

Return-Path: <jon@callas.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CD61A0D3D for <tls@ietfa.amsl.com>; Sun, 2 Mar 2014 22:52:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham
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 2EPyYTm_jwbj for <tls@ietfa.amsl.com>; Sun, 2 Mar 2014 22:52:44 -0800 (PST)
Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by ietfa.amsl.com (Postfix) with ESMTP id 437E51A0CA3 for <tls@ietf.org>; Sun, 2 Mar 2014 22:52:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 008394E5D43F; Sun, 2 Mar 2014 22:52:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at merrymeet.com
Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-9KKeOzFwZl; Sun, 2 Mar 2014 22:52:31 -0800 (PST)
Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id 6605E4E5D423; Sun, 2 Mar 2014 22:52:31 -0800 (PST)
Received: from [10.0.23.100] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Sun, 02 Mar 2014 22:52:31 -0800
X-PGP-Universal: processed; by keys.merrymeet.com on Sun, 02 Mar 2014 22:52:31 -0800
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Jon Callas <jon@callas.org>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com>
Date: Sun, 02 Mar 2014 22:52:28 -0800
Message-Id: <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org>
References: <530FDC7A.4060404@cisco.com> <CABqy+srTqCXjOR4DMNgWyxf2pZ7dwZfWyznhBuJaY5w8VeuR4Q@mail.gmail.com> <5310B12E.4070603@cisco.com> <CABqy+srrbtdHOckjPqTj5SFuQwQEqXBjgc8kwagMi8E6ZRf=qg@mail.gmail.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <CF37EA5F.338D8%paul@marvell.com> <CACsn0cmewBrOzaRF5XXC1p1A_gUSwkdE1_7V-1x8nta-ESyA+A@mail.gmail.com> <CF38F2D4.33940%paul@marvell.com> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com>
To: Paul Lambert <paul@marvell.com>
X-Mailer: Apple Mail (2.1874)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4m64uscA0eMuo0eA9fUncu64cRQ
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Jon Callas <jon@callas.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Citing specs in specs
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: Mon, 03 Mar 2014 06:52:46 -0000

On Mar 2, 2014, at 3:40 PM, Paul Lambert <paul@marvell.com> wrote:

> Implementations are possible by using the readily available open source
> implementation.  This is a good thing, but it is also desirable
> to have a unambiguous description of the algorithms that is not 
> a C code file.  This is why we write RFCs...

It's hard to disagree with this, in a similar way that it's hard to disagree with the idea of peace on earth, living at one with nature, etc.

But in practice, code needs to be in a computer language rather than English and I've seen (and been involved with) a document that started with rough consensus and running code, translated that into English, and the English was (and is) devilishly hard to compile back into C.

Portably implemented algorithms are hard to do in any computer language. They're harder to do in words. I don't see how you're going to get an unambiguous description of the language in anything but a computer language. It doesn't have to be C, it could be Python, Ruby, or Algol-58 (which I mention because it was originally designed as an algorithmic description language). English is a suboptimal implementation language.

	Jon

v2.23.0 | Report a Bug | By Email