Re: [port-srv-reg] we need to make progress

Stuart Cheshire <cheshire@apple.com> Tue, 07 September 2010 05:59 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: port-srv-reg@core3.amsl.com
Delivered-To: port-srv-reg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF50E3A659B for <port-srv-reg@core3.amsl.com>; Mon, 6 Sep 2010 22:59:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.45
X-Spam-Level:
X-Spam-Status: No, score=-106.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Szjt3thZ+VVf for <port-srv-reg@core3.amsl.com>; Mon, 6 Sep 2010 22:59:39 -0700 (PDT)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id B38BE3A6782 for <port-srv-reg@ietf.org>; Mon, 6 Sep 2010 22:59:39 -0700 (PDT)
Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out4.apple.com (Postfix) with ESMTP id 43FD1AD9B39A for <port-srv-reg@ietf.org>; Mon, 6 Sep 2010 23:00:08 -0700 (PDT)
X-AuditID: 1180711d-b7b8eae0000035ac-d2-4c85d4e86534
Received: from gertie.apple.com (gertie.apple.com [17.151.62.15]) by relay13.apple.com (Apple SCV relay) with SMTP id 26.94.13740.8E4D58C4; Mon, 6 Sep 2010 23:00:08 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=us-ascii
Received: from [10.0.1.43] (c-24-6-164-127.hsd1.ca.comcast.net [24.6.164.127]) by gertie.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L8D007J84O78510@gertie.apple.com> for port-srv-reg@ietf.org; Mon, 06 Sep 2010 23:00:08 -0700 (PDT)
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <F730936E-D01C-401A-847D-5524C35B8BB0@isi.edu>
Date: Mon, 06 Sep 2010 23:00:07 -0700
Message-id: <CE67781A-2EB0-4476-8AE6-368A3B179453@apple.com>
References: <6EC7B8A7-C3B3-4E63-85A9-0DC31F4D45B4@nokia.com> <58FA4E25-57CE-4D07-BFBA-A708F3616128@apple.com> <4C812B37.1030504@isi.edu> <E3F75759-04AF-469E-9481-9ADA9D8B7829@apple.com> <F730936E-D01C-401A-847D-5524C35B8BB0@isi.edu>
To: port-srv-reg@ietf.org
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [port-srv-reg] we need to make progress
X-BeenThere: port-srv-reg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of updates to service name and transport protocol port registry <port-srv-reg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/port-srv-reg>
List-Post: <mailto:port-srv-reg@ietf.org>
List-Help: <mailto:port-srv-reg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/port-srv-reg>, <mailto:port-srv-reg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Sep 2010 05:59:46 -0000

On 6 Sep 2010, at 16:02, Joe Touch wrote:

> ABNF may be hard for you to understand

I heard someone say once that an algorithm (or protocol) design can be so simple that it obviously has no errors, or so complicated that it has no obvious errors.

The issue I'm trying to raise is not the particular error I may (or may not) have found, but the deeper concern that I'm not confident that it does not have more errors in addition to that. The issue is that unless a reasonable proportion of the IETF community can look at the ABNF definition and state with confidence that it is obviously right, then we may publish something that's not right.

Processing a computer language generally consists of tokenizing followed by parsing. Tokenizing consists of turning text into logical units; parsing consists of turning those tokens into the language's structure. ABNF is a good way of expressing parsing rules; it is often not a good way of expressing tokenizing rules. The rules for stating what's a valid service name is a tokenizing problem, not a parsing problem. The awkward and convoluted ABNF in the document reflects this poor fit.

I suspect that most people reading this document skip over the ABNF bit, so it has not had good scrutiny. It's also not adding much to the document if it's text that most readers skip over.

Stuart Cheshire <cheshire@apple.com>
* Wizard Without Portfolio, Apple Inc.
* www.stuartcheshire.org