Re: ABNF sets and sequences

[Robert Elz <[e-mail]>]

    Date:        Mon, 10 Jul 2000 11:42:21 +0900
    From:        Dave Crocker <[e-mail]>
    Message-ID:  <[e-mail]>

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

I'm not sure that makes much of a difference, ABNF is recursive, everything
includes everything else.  One possibility for an alternation is a single
concatenation, and a concatenation can be a single repetition, which can
be just an unadorned element, which can be a group, which is just an
alternation inside parentheses.

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

I think it might be useful if it can be fully defined, and demonstrated.


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

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

Which looks fine, until someone reads it and says "see, all the extension
fields included need to be adjacent to each other" as the SET construct
only affects the objects directly in the group, not those one level
further down.  To avoid this, a more complex operator definition is
needed for SET, or text is needed to explain that no, it is after all legal
to have an extension field, then one of the defined fields, and then
another extension field.

  | 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)]

Which makes exactly what difference???

I think Keith's point was that as written, name-val-list already allows
the name-val-pairs to occur in any order (because which particular name-val-pair
is the first, and which is the second, isn't defined.

  | and

  | becomes something like:
  | 
  | >fields          =
  | 
  |                  SET (
  | >                           *(trace
  | >                           *(resent-date /
  | >                            resent-from /
  | >                            resent-sender /
  | >                            resent-to /
  | >                            resent-cc /
  | >                            resent-bcc /
  | >                            resent-id))
  |                  )

This isn't achieving what you'd hope - it as it was without the
SET will generate exactly the same as it does with the SET.  There
is no SET covering the resent-* headers included, they're just one
element in the included concatenation.  On the other hand, the *( / / /)
allows the elements included to appear any number of times in any
order.

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

Again there, the SET adds nothing, the fields can already occur any
number of times in any order.   The problem that Pete's current grammar
has, if it has one, is that it doesn't include "Only one From:" header,
it allows any number of the things (and all those other headers as well).
If you remove the *() from that, and include [ ] around all the elements
that are optional, yu get closer to what you intended, but even that
doesn't correctly allow the relationship between From and Sender to be
included, nor the "must have one destination field" (though I forget if
we decided to keep that rule - but for ABNF purposes, assume we did).

And since "optional-field" would need to become *optional-field rather
than [optional-field] you get back to the same problem that all the
optional-fields that are included would have to be adjacent.

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

If you want a proper technical debate I think we'd need a proper technical
specification to review.  As it is now, philosophy is about all that can
be debated, there aren't enough details for anything else.

kre