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

Joe Touch <touch@isi.edu> Tue, 07 September 2010 16:08 UTC

Return-Path: <touch@isi.edu>
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 DA1A03A6A5D for <port-srv-reg@core3.amsl.com>; Tue, 7 Sep 2010 09:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.67
X-Spam-Level:
X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, 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 UEIH8juKjXlc for <port-srv-reg@core3.amsl.com>; Tue, 7 Sep 2010 09:08:03 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 03C823A67D0 for <port-srv-reg@ietf.org>; Tue, 7 Sep 2010 09:08:02 -0700 (PDT)
Received: from [75.217.225.25] (25.sub-75-217-225.myvzw.com [75.217.225.25]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o87G85rS023935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Sep 2010 09:08:16 -0700 (PDT)
Message-ID: <4C866366.4010104@isi.edu>
Date: Tue, 07 Sep 2010 09:08:06 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Stuart Cheshire <cheshire@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> <CE67781A-2EB0-4476-8AE6-368A3B179453@apple.com>
In-Reply-To: <CE67781A-2EB0-4476-8AE6-368A3B179453@apple.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: o87G85rS023935
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: port-srv-reg@ietf.org
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 16:08:04 -0000

On 9/6/2010 11:00 PM, Stuart Cheshire wrote:
>> On 6 Sep 2010, at 16:02, Joe Touch wrote:
>>
>> ABNF may be hard for you to understand
...
> 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.

I believe we need to publish something, esp. since some programmers will 
want to use what we publish - or a derivation thereof - as code to 
validate the strings.

> 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 ABNF we are using includes regular expressions, which is the common 
way to express tokens.

> 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.

It describes attempts to over-optimize the description to make it 
compact - which happened back in mid-Dec, and you were cc'd in that 
discussion.

I checked that thread, and we had been developing the ABNF up to a 
point, then Olafur suggested we paste in the copy from the "clarify" 
doc, which introduced the error (indicated below).

       SRVNAME = (ALPHA / *([HYPHEN] ALNUM)) /
                        ^
                 (1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM))
       ALNUM   = ALPHA / DIGIT   ; A-Z, a-z, 0-9
       HYPHEN  = %x2d            ; "-"
       ALPHA   = <See [RFC5234]>
       DIGIT   = <See [RFC5234]>

 From our discussions back in Dec, and correcting to make this easier to 
read (From RFC5234), the intended ABNF would have been:

       SRVNAME =  ALPHA *([HYPHEN] ALNUM)
       SRVNAME =/ 1*DIGIT ((HYPHEN ALNUM) / ALPHA) *([HYPHEN] ALNUM)
       ALNUM   = ALPHA / DIGIT   ; A-Z, a-z, 0-9
       HYPHEN  = %x2d            ; "-"
       ALPHA   = <See [RFC5234]>
       DIGIT   = <See [RFC5234]>

This missed the multiple hyphen case, which can be corrected easily:

       SRVNAME =  ALPHA *(*HYPHEN ALNUM)
       SRVNAME =/ 1*DIGIT ((HYPHEN ALNUM) / ALPHA) *(*HYPHEN ALNUM)

Joe