Re: ABNF sets and sequences

[Dave Crocker <[e-mail]>]

At 12:56 AM 7/9/00 -0400, Keith Moore wrote:
>having this notation will not significantly simplify or clarify
>the specification for Internet mail.

1.  The construct that is at issue cannot reasonably be specified in 
current ABNF.

2.  The construct occurs regularly, such as for 822-like headers, labeled 
parameters in Received headers, etc.  This is not a small or occasional issue.

3.  Putting the qualifier in the prose is a good way a) to get missed, or 
b) not to get specified.

Absence of this, for in RFC 1894, is what re-triggered my interest in this 
topic.  One might argue that misunderstanding this relaxation of the 
apparent syntactic requirement for ordering is "merely" a matter of 
acculturation -- one must be fully plugged in to the protocol development 
community.  That is a requirement that has scaling problems.

While few implementation errors can be documented by this unfair 
requirement, growth of the Internet should encourage us to make common 
constructs easier to specify and harder to miss.


>Now it may be that there is some other justification for this notation.  I 
>just don't know what it is..

The working group felt it was worth adding earlier.  We just couldn't 
figure out how.  I now believe that was because we tied it to alternation 
(a / b) rather than concatenation (a b) and repetition, where it belongs.

In any event, the point you raise reduces to whether the community thinks 
it is useful to have the construct in ABNF.  I do; you don't.  Others will 
decide.


> > >2. unlike the rest of ABNF, such a syntax would not easily be
> > >translated into something that a parser generator could
> >
> > ASN.1 parsers handle it just fine.
>
>I fail to see how this is relevant.

See below.


>ASN.1 is a language for describing the structure of data

as is ABNF.


>(BER maps that structure onto a presentation), but ASN.1
>is not a language for writing a parser for some already-defined
>presentation of data.  You can write an RFC 822 parser in yacc,

yacc is the programming language, not ASN.1.


>but you can't write one in ASN.1

asymmetric comparison:

         <822 headers, or whatever> : abnf : yacc

should be compared with:

         <822> : asn.1 : <???>


>ASN.1 is not widely regarded as a particularly good notation for
>describing protocols.   one of ASN.1's many mistakes is trying

It is used.  It works.  Some like it; some don't.  That's all fine, but 
entirely irrelevant.

You made a specific claim of non-implementability.  I cited an existence 
proof to contradict your specific claim.

I was not making a wholesale statement of support for ASN.1 and a wholesale 
attack on it is not relevant.  Nor are other issues about ASN.1 relevant.


> > >3. notation that isn't used very often actually hinders readability
> >
> > The motivation for this is that it IS needed with regularity, namely for
> > every list of labeled parameters.  Such lists are ALWAYS 
> unordered.  That's
> > the reason for the labels.
>
>in many of these cases (e.g. any time the list of labels is extensible)
>it's a bad idea to specify the parameter labels as literals anyway.
>
>in other words, it's bad style to write
>
>         list = *( "thing1" / "thing2" / "thing3" / extension-thing )

You keep using the alternation construct.

Let's get specific about how the construct probably should be used:

RFC 1894:

>2.2 Per-Message DSN Fields
>
>    Some fields of a DSN apply to all of the delivery attempts described
>    by that DSN.  These fields may appear at most once in any DSN.  These
>    fields are used to correlate the DSN with the original message
>    transaction and to provide additional information which may be useful
>    to gateways.
>
>      per-message-fields =

         SET (

>           [ original-envelope-id-field CRLF ]
>           reporting-mta-field CRLF
>           [ dsn-gateway-field CRLF ]
>           [ received-from-mta-field CRLF ]
>           [ arrival-date-field CRLF ]
>           *( extension-field CRLF )

         )


and in draft-ietf-drums-msg-fmt-07.txt:

>name-val-list   =       [CFWS] [name-val-pair *(CFWS name-val-pair)]

becomes

>name-val-list   =       [CFWS]  SET [name-val-pair *(CFWS name-val-pair)]


and

>fields          =       *(trace
>                           *(resent-date /
>                            resent-from /
>                            resent-sender /
>                            resent-to /
>                            resent-cc /
>                            resent-bcc /
>                            resent-id))
>                         *(orig-date /
>                         from /
>                         sender /
>                         reply-to /
>                         to /
>                         cc /
>                         bcc /
>                         message-id /
>                         in-reply-to /
>                         references /
>                         subject /
>                         comments /
>                         keywords /
>                         optional-field)

becomes something like:

>fields          =

                 SET (
>                           *(trace
>                           *(resent-date /
>                            resent-from /
>                            resent-sender /
>                            resent-to /
>                            resent-cc /
>                            resent-bcc /
>                            resent-id))
                 )
                 SET (
>                         *(orig-date /
>                         from /
>                         sender /
>                         reply-to /
>                         to /
>                         cc /
>                         bcc /
>                         message-id /
>                         in-reply-to /
>                         references /
>                         subject /
>                         comments /
>                         keywords /
>                         optional-field)
                 )


(small point of curiosity, for Pete or whoever:  the current syntax for 
<message> seems to mean that message headers are either fields or 
obs-fields, but not a combination?)

Anyhow, folks, I would appreciate some technical feedback on this. The 
philosophical line of debate is probably played out.

d/

=-=-=-=-=
Dave Crocker  <[e-mail]>
Brandenburg Consulting  <www.brandenburg.com>
Tel: [phone],  Fax: [phone]
675 Spruce Drive,  Sunnyvale, CA 94086 USA