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

 From a practical perspective, when parsing things that need EOL marks, 
ISTM that you can generally get good results by treating LF as EOL, and 
CR as WS. It works for CRLF, LFCR and naked LF. (I don't recall anything 
in the last few decades that treats a naked CR as EOL.)

This of course isn't enough to know what forms to produce when 
generating text.

	Thanks,
	Paul

On 11/18/17 4:57 AM, Carsten Bormann wrote:
> On Nov 16, 2017, at 23:31, Dave Crocker <dcrocker@gmail.com> wrote:
>>
>> 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.
> 
> Right.
> 
> 
>> 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.
> 
> Well, software development has focused on Unix line ends, tolerating DOS line ends in some spaces, for a while.
> That seems to work for so many languages, we can just emulate that.
> 
> Let’s take a page from RFC 7950 (YANG 1.1):
> 
>     line-break          = CRLF / LF
> 
> That is essentially the same I was proposing, but the explicit name “line-break” is probably better than NL by some.
> 
>> This, then, would require separate translation from native, local representation to the canonical form.  But that's a pretty simple definition effort.
> 
> Again, I think that most source control systems and programmers’ editors know how to do that.
> 
>>>     EOL = [CR] LF
>>> is probably the right way to describe line ends for these files.
>>
>> Possibly, unless folk really want
>>
>>    EOL = *CR LF
> 
> We don’t want to tolerate more than one CR here; these would be isolated CRs in todays line end worlds.
> 
>> 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
> 
> That generally works, except in certain strings, where it is good to identify actual line ends.
> 
>> (why not also include TAB?)
> 
> I can’t find the string TAB in RFC 20; I think you probably mean HT.
> HT is evil(**) and, approximately since the time 300 bit/s LA36 terminals(***) went out of use, should never be used(*).
> Easy fix as applied here: Simply don’t allow HT in specification source files.
> 
> Grüße, Carsten
> 
> (*) Outside certain very sheltered environments such as Linux Kernel development.
> (**) RFC 7386/7396 should be proof enough here.
> (***) https://archive.org/details/handbookofintera00duan p. 82; additionally insert fond memories here…
> 
> _______________________________________________
> abnf-discuss mailing list
> abnf-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/abnf-discuss
> 