Re: [abnf-discuss] ABNF colloquialism for end-of-line

Dave Crocker <dcrocker@gmail.com> Thu, 16 November 2017 15:31 UTC

Return-Path: <dcrocker@gmail.com>
X-Original-To: abnf-discuss@ietfa.amsl.com
Delivered-To: abnf-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E6C129410 for <abnf-discuss@ietfa.amsl.com>; Thu, 16 Nov 2017 07:31:59 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 3675QVgPN512 for <abnf-discuss@ietfa.amsl.com>; Thu, 16 Nov 2017 07:31:57 -0800 (PST)
Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::231]) (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 0B0F8129A9F for <abnf-discuss@ietf.org>; Thu, 16 Nov 2017 07:31:25 -0800 (PST)
Received: by mail-ot0-x231.google.com with SMTP id u10so15471323otc.12 for <abnf-discuss@ietf.org>; Thu, 16 Nov 2017 07:31:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=F2TY6eDlGfAUJ3oYg19Nv5YmAtGDt1a1BDArIhcnP3o=; b=CYX9R1U1DhRlBMS0qu1lFy3dNLCs3Y44VSGYoJszGXPKtLuBLI2kRsaf39BxGi3WD2 Op+BgSuFwOtS6PTxbLxvOpDB6Xyy7F1H8F5poSCYAZj9Q+Y7ZNZbG7PfeKhIkce3WKaq V4J74gvOxIrGEZChWbS9ugAdUd8AEIogfR80Eo8JyyeSnsvMAMWCoaET8LWVaAk/bSqw tDdEjmit5vK1ohq3DYSEwLWtmoWHS5XSLqnCcNiD6uHKF3PctBgoD//YzxJyaTOSn6Cr P7AlJFmI42iUyj15MTgERHqdQ3MH7hXfFkbv1xGWvQqbIMG8IfcCVsMe7or9+lK+TsSx JoXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F2TY6eDlGfAUJ3oYg19Nv5YmAtGDt1a1BDArIhcnP3o=; b=pL/QZ1Crps9HG3ZzyA/4Ik3fLNRziF9D04xdYaCfUt6CnwDIfurqNizx7vygD1xMIS yMKcPIni2glrW3VsBNJpno4k9bOYNpqj0s3Vnqb4lDfCn7wWsv4Wm1Maf/NOQU1kiaXk kS8pYiN322u+6VYXXVD0dBuZCCBGwE+XqOa4taDVWYMZr6iu/4k/G0auhf3jaH94ftze IP+cH1v1FQ1M9SuiahD85jYJk70tB4/Bq2r+WA6R2GHKP2eqbrzoG2x83O8vXvA+DuNK JzinnOfHLop2opRRZ72Wt06th5q1Ihgz5Y/ndr1/S8n8Fbnir4GK+FZuV+W9ydgGUzR9 uxng==
X-Gm-Message-State: AJaThX6llC02T5pdtAX7kD/nZI17aw5enJNgDsK5uWVpbDNwftr0zcjr mRC9O1qq7JfdRHB0MiDKVzU=
X-Google-Smtp-Source: AGs4zMYRha4QOkjVh2DczyQXUNue9g6CGeAdTrksfv/lxJ3N12xtZiwGyOtSRBO9WeMtWO/VUnhxrw==
X-Received: by 10.157.7.202 with SMTP id 68mr1373384oto.289.1510846283932; Thu, 16 Nov 2017 07:31:23 -0800 (PST)
Received: from ?IPv6:2602:304:cda0:8800:19a4:c255:db4e:853e? ([2602:304:cda0:8800:19a4:c255:db4e:853e]) by smtp.gmail.com with ESMTPSA id d42sm566962ote.45.2017.11.16.07.31.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 07:31:22 -0800 (PST)
To: Carsten Bormann <cabo@tzi.org>
Cc: ABNF-Discuss <abnf-discuss@ietf.org>, Sean Leonard <dev+ietf@seantek.com>
References: <97E6D6C0-7010-46D6-8641-670F10A2504C@seantek.com> <3fbd228d-c6cf-be73-c7f2-f6b15979b852@gmail.com> <477FA5E8-FBAA-47D4-98A6-79DBAE4498C7@tzi.org>
From: Dave Crocker <dcrocker@gmail.com>
Message-ID: <7db503ef-3db4-9a72-6d14-001831742600@gmail.com>
Date: Thu, 16 Nov 2017 07:31:19 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <477FA5E8-FBAA-47D4-98A6-79DBAE4498C7@tzi.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/abnf-discuss/UESvCA64XTUI_6Iv-E-R5d0tSpY>
Subject: Re: [abnf-discuss] ABNF colloquialism for end-of-line
X-BeenThere: abnf-discuss@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "General discussion about tools, activities and capabilities involving the ABNF meta-language" <abnf-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/abnf-discuss/>
List-Post: <mailto:abnf-discuss@ietf.org>
List-Help: <mailto:abnf-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/abnf-discuss>, <mailto:abnf-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 15:31:59 -0000

Carsten,

On 11/15/2017 6:35 PM, Carsten Bormann wrote:
> Hi Dave,
> 
> On Nov 15, 2017, at 23:37, Dave Crocker <dcrocker@gmail.com> wrote:
>>
>> Given that the thread in CBOR says 'matching rules', I'm guessing that the goal here is to describe freeform data coming from the net.  Hence, requiring a simple, canonicalized data form is not appropriate.  (This is an essential point; if it's not correct, then what follows won't be either.)
> 
> The thread title unfortunately is misleading.
> 
> The ABNF is not for on-the wire packets, but for defining the syntax of the CDDL language (which then defines the syntax of the on-the-wire data items).
> 
> So this ABNF is about files on computers, which probably run a form of Linux/Unix or Windows (and very likely not pre-2001 classic MacOS).  So

I take your point, but suspect there is still an issue.  At the least, 
being clear /and explicit/ about this in the specification document(s) 
will be helpful.

The issue I suspect is the intended portability of the file.  If the 
file is intended to be portable, then it, too, needs to be in a 
canonical form.  It's a type of 'over the wire' even though it isn't 
part of a wire protocol.

This, then, would require separate translation from native, local 
representation to the canonical form.  But that's a pretty simple 
definition effort.


>     EOL = [CR] LF
> 
> is probably the right way to describe line ends for these files.

Possibly, unless folk really want

    EOL = *CR LF


> 
> The context for this (with one exception) is
> 
>     NL = COMMENT / EOL
>     COMMENT = ";" *(SP / VCHAR) EOL
>     VCHAR = %x21-7E
> 
> Maybe NL is not the best name for the encompassing rule, but it is used only in one additional rule:
> 
>     WS = SP / NL

Yeah, maybe not the best.  If ruleset is not really treating it 
semantically as end of line.

So while there is an historical basis for saying EOL, I'd think that in 
this context, it would sufficient and simpler just to have:

   WS = SP / CR / LF

(why not also include TAB?)



> PS.: If ABNF had cuts, I’d write
> 
>     EOL = [CR ^] LF
> 
> to get better errors on stray CRs.  Maybe not so important these days.

Sorry.  Not sure what you mean.  "cuts"? "^"?

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net