Subject: Re: [apps-discuss] draft-yevstifeyev-abnf-separated-lists-00.txt

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 06 Dec 2010 18:11:35 +0200

Hi all,

Some answers:

06.12.2010 16:45, Tony Hansen wrote:
> On 12/6/2010 2:36 AM, Mykyta Yevstifeyev wrote:
>> 2010/12/6, Tony Hansen<[email-masked]>:
>>>      n              = 0*DIGIT    ;minimum amount of elements
>>>      m              = 0*DIGIT    ;maximum amount of elements
>> Will be taken into consideration.
>> Or, maybe, just *DIGIT .
>
> *DIGIT is fine
Will be corrected in the next version of the draft.
>
>>> Your draft is inconsistent. In one place, you use "m" and another place
>>> you use "o".
>>>
>>> I don't see why you use "o" at all -- I recommend you just use "m".
>> o = m-n as m is maximum and n we have already used as it is mimimum.
>> So we can use only he differebce between them.
>
> We *can*, but that doesn't mean we *should*.
>
> Other ABNF constructs use "m" and "n" directly -- they do *not* use 
> the difference.
>
> I think using the difference for this case is just asking for trouble 
> and will introduce subtle errors in future protocols that use this 
> construct.
>
> Consider the normal 5234 ABNF rule <a>*<b>element. <a> is the minimum 
> and <b> is the maximum. It is *not* <a>*<b-a>element.
>
> The 822 ABNF rule <a>#<b>element, which your rule is updating, also 
> used the same minimum and maximum values -- it did *not* use the 
> difference.
However we MUST use *n* elements and MAY use all more *(m-n)*. If we say 
that we use the we MAY use more *m*, it is possible that we use *(m+n)* 
togetger, but we MUST use at most *m* while
*m+n is not m*
>
> Note also: your introduction is incorrect. It talks about ABNF having 
> the # rule. However, it does not. The original 822 ABNF had the # 
> rule, but it was dropped when ABNF was extracted for the *234 series.
Maybe I meant the construction form RFC 2616.
>
>>> It would be useful to have examples of where this production would have
>>> been useful, such as some RFCs or I-Ds that have been written using the
>>> "old way" and how they would be better written using the "new way".
>> At the moment there are no acceptable examples - however I think the
>> construction will be useful in future.
>
> Two points: Examples of future use would still be useful.
>
> And not having examples of places where this would have been useful in 
> the past is going to make it a very hard sell.
>
> There was a reason the #rule was dropped from the *234 series of RFCs 
> -- it wasn't found to be useful enough to keep for a general purpose 
> ABNF rule.
>
>     Tony Hansen
>     [email-masked]
>

06.12.2010 17:01, Barry Leiba wrote:
> On Mon, Dec 6, 2010 at 4:23 AM, Mykyta Yevstifeyev<[email-masked]>  wrote:
>> I am writing to reuqest the review of my draft folowing the advice of
>> Russ Housley
> ...
>> You are able to find it here:
>>
>> https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/?include_text=1
> It's short; I'll give it a review for form here.  I'll leave it to
> Dave to discuss why such list constructs aren't in 5234.
>
> Starting with a nit: How did you create this draft?  The abstract is
> in the "wrong" place (I initially thought it was missing), so it seems
> you're not using the latest tools.
>
> The abstract is too brief.  How about this?:
>
> OLD
>     This document specifies Augmented Backus-Naur Form (ABNF) notation
>     for separated lists. It updates RFC 5234.
>
> NEW
>     This document defines Augmented Backus-Naur Form (ABNF) notation
>     for representing lists separated by any specified character. It
> updates RFC 5234.
>
Will be taken into consideration.
> Introduction:
>     ABNF provides a possibility to express lists of elements, separated
>     by commas (",") via the construction<a>#<b>element.
>
> Where is that documented?  It's not in RFC 5234.
See above - in RFC2616 (however it is not a specification of ABNF).
>
> Section 2:
> The ABNF isn't right.  You don't show that<n>  and<m>  are optional,
> and you define them as having at least one digit each... and then you
> say that either or both can be omitted in some cases.
>
> Also, "<m-n>" as an arithmetic difference isn't meaningful in ABNF.
> Perhaps the text that's there is sufficient to make it clear, but I
> think it won't pass automated processing.  I'm not sure what the best
> way to handle that is.
>
See above.
> A section with a few examples would be helpful.
Will be added.
> Barry
Mykyta Yevstifeyev

---

From: Tony Hansen <[email-masked]>
Date: Mon, 06 Dec 2010 11:34:00 -0500

On 12/6/2010 11:11 AM, Mykyta Yevstifeyev wrote:
> However we MUST use *n* elements and MAY use all more *(m-n)*. If we 
> say that we use the we MAY use more *m*, it is possible that we use 
> *(m+n)* togetger, but we MUST use at most *m* while
> *m+n is not m*

m+n is not m, nor is m-n. The second number that is used is the * and # 
rules is not how many more are allowed beyond the minimum, but really is 
the maximum. That is, 2*3 and 2#3 mean a minimum of 2 and a maximum of 3 
-- it's not a minimum of 2 plus possible 3 more for a maximum of 5.

This rule should do likewise.

> Maybe I meant the construction form RFC 2616.

That's fine -- say so then.

Note that the #rule in 2616 also uses a minimum of n and a maximum of m 
-- it does not use a difference for the second number.

If you're going to offer this as an update to RFC 5234, you may wish to 
specify that the #rule be added in as well.

     Tony Hansen
     [email-masked]

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 06 Dec 2010 18:41:28 +0200

Hello all,

FYI, a new version of the my draft is available.
The link is given below.

The link to the draft:
https://datatracker.ietf.org/doc/draft-yevstifeyev-abnf-separated-lists/

Almost all comments and suggestions were taken
into account. Among other:
-updated ABNF;
-added Examples section;
-added Acknowledgments section;
-other minor changes.

Any suggestions for improvement are welcome.

All the best,
Mykyta Yevstifeyev

---

From: Tony Hansen <[email-masked]>
Date: Mon, 06 Dec 2010 13:08:14 -0500

I'm happy with the definitions of n, m and o that are given in -01.
>>> Note also: your introduction is incorrect. It talks about ABNF 
>>> having the # rule. However, it does not. The original 822 ABNF had 
>>> the # rule, but it was dropped when ABNF was extracted for the *234 
>>> series.
> Note that the #rule in 2616 also uses a minimum of n and a maximum of 
> m -- it does not use a difference for the second number.
>
> If you're going to offer this as an update to RFC 5234, you may wish 
> to specify that the #rule be added in as well.

You may wish to add to the Introduction that RFCs 733, 822, 1945, 2068, 
2543, 2616 and 2831 all defined a limited version of this rule, 
specifically for a comma separator.

More comments from version -01:

I disagree with adding SP / HT to the production list for a:

     a = VCHAR / SP / HT / <any other separator>

Your example that uses this:

     1^(SP)element indicates the list of elements separated by spaces
     which consists of any amount of elements but not less than 1.

has serious issues as a protocol element. It allows for arbitrary 
amounts of SP or HT followed by a single SP followed by arbitary amounts 
of SP or HT. What any self-respecting protocol would really want is a 
list separated by at least one SP or HT, as in

     1*(1*LWS element)

This is more obvious and exact. I'd hate to write a parser for 1^(SP), 
or debug protocol problems with it. (Is there really at least one SP 
character between those elements?)

The example

     ^(-)element indicates the list of elements separated by hyphens ("-")

cannot use a bare "-" like that. It must be specified as

     ^("-")element

Hope this helps.

I think it would be useful to find ABNF constructs in existing protocols 
that provide for lists and give examples of how their ABNF would have 
been simplified if this new ABNF construct were available.

     Tony Hansen
     [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Mon, 6 Dec 2010 13:19:43 -0500

> -added Acknowledgments section;

The changes to the ABNF are good, and they resolve my concerns from -00.

I note a remaining problem with the ABNF that I missed the first time:

   n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element))

The first clause on the right is incorrect: it specifies <n>
occurrences of <element> with *no* <a> between them.  As you add that,
you need to make sure to get the cases where n=0 and n=1 correct, as
well as where n=m (I think that last one is already OK).

This points out the difficulty of getting such a general list
construct defined correctly, and shows why it was removed.

I agree with Tony that if you can't include examples of how we should
have had this before, it'll be hard to convince the community and the
IESG that it's needed now.  We can always come up with things that
*might* be useful, but part of the challenge is keeping the language
as simple as possible (and no simpler).

Barry

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Dec 2010 15:16:10 -0500

--On Monday, December 06, 2010 13:08 -0500 Tony Hansen
<[email-masked]> wrote:

> I think it would be useful to find ABNF constructs in existing
> protocols that provide for lists and give examples of how
> their ABNF would have been simplified if this new ABNF
> construct were available.

and

--On Monday, December 06, 2010 13:19 -0500 Barry Leiba
<[email-masked]> wrote:

> I agree with Tony that if you can't include examples of how we
> should have had this before, it'll be hard to convince the
> community and the IESG that it's needed now.  We can always
> come up with things that *might* be useful, but part of the
> challenge is keeping the language as simple as possible (and
> no simpler).

And _that_, it seems to me, is the more fundamental problem with
this proposal.  One can always add more elements, constructors,
or decorations to a metalanguage like this one.  One can also go
minimalist: while some things would be quite tedious to express,
I don't believe there is anything that can be expressed in RFC
5234 ABNF, with or without this extension, that cannot be
expressed in classical/original BNF.   The advantage of a more
powerful metalanguage is that expressions become more concise,
often leading to greater clarity for those who understand it.
The disadvantage is that the language becomes harder to write
optimally and _much_ harder to examine for errors and debug.
Empirically, ABNF has already become daunting enough that we
need to talk about ABNF experts in the IETF, that people
routinely get grammars written in ABNF wrong, and that it is not
a metalanguage that most of those who can otherwise write specs
in the IETF feel that they can use efficiently and accurately.  

The question shouldn't be whether we can describe a new feature
of find syntax for it.   It should be whether that new feature
is really important enough to justify the additional complexity
it adds to the metalanguage, especially if the chosen syntax
makes the metalanguage more subtle and/or obscure.

IMO, that case has not been made at all convincingly yet.  The
sorts of examples that Barry and Tony suggest would be a useful
step in the process of convincing people, but I suggest that,
unless it can be shown that this construction actually
simplifies a large number of practical cases, every error we
find in the ABNF when documents that use the metalanguage are
examine is an argument against more operators and complexity.

    john

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Dec 2010 00:02:52 +0100

> examine is an argument against more operators and complexity.

Right.

We spent a considerable amount of time in 2008 and 2009 on HTTPbis ABNF 
work, and we ended up *keeping* the # syntax for the actual spec text, 
but added a normative mapping to RFC 5234 ABNF, and also have 
auto-generated appendices with the expanded notation.

See

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#notation.abnf>

and

<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#collected.abnf>

If we *were* adding features to RFC 5234, the one thing I'm missing most 
is a shorthand notation for defining a set of characters as a difference 
from another set, such as

   myoctdigits = DIGIT - ( "8" / "0" )

Without this feature, many people use prose production instead ("<VCHAR 
except ...>"), or create proper ABNF which then is hard to follow.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Dec 2010 00:06:55 +0100

On 07.12.2010 00:05, Bjoern Hoehrmann wrote:
> * Julian Reschke wrote:

Where the "0" was supposed to be a "9". It's later over here.

> (I suppose case-sensitive literals would be the next thing.)

Indeed.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 7 Dec 2010 09:41:06 +0200

Hello all,

> well as where n=m (I think that last one is already OK).
Maybe such constrution should be used:
n^(a)m element = ( n(*LWS element *LWS a) *o(*LWS a *LWS element) )
However this construction does not solve the problem when only
REQUIRED amount of elements are use as <a> will be used after the last
element.
> as simple as possible (and no simpler).
The construction will be used while definig the HTTP headers which
contain the list of element. Now I am thinking about some other
examples.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 07 Dec 2010 09:43:39 +0100

> contain the list of element. Now I am thinking about some other

If your use case is to specify new HTTP headers, I'd recommend that you 
stick with the RFC 2616 syntax (because you want to inherit the rules 
for implied LWS anyway).

If you can wait for HTTPbis, you can use RFC 5234 syntax with # as an 
extension as defined by HTTPbis.

Best regards, Julian

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Tue, 7 Dec 2010 13:05:29 +0200

Hello all,

I think I'll published the revised draft today with the folloeing constr:

n^(a)m = *LWS element <n-1>*<m-1>(*LWS a *LWS element)

like used in the HttpBIS WG draft. So this constr. will be available
on the ABNF spec.

> stick with the RFC 2616 syntax (because you want to inherit the rules
LWS rule can simply be copied to rge specification of discussed construction.
> extension as defined by HTTPbis.
Yes, I agree but I want to put this rule but improved to RFC5234 as it
doe *not* have this rule. And what means "If you can wait for HTTPbis
..."
All the best,
Mykyta Yevstifeyev

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 07 Dec 2010 00:05:08 +0100

(I suppose case-sensitive literals would be the next thing.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Wed, 08 Dec 2010 19:42:58 +0200

Hello all,

I have uploaded the new version (-02) of my draft
for ABNF for separated lists.

Here is the link:

Among other, there is updated ABNF for defined
construction which is OK for cases when n = 0,
n >= 1 and other cases.

Any suggestions are welcome.

All the best,
Mykyta Yevstifeyev

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 10 Dec 2010 06:33:12 +0800

Hi Mykyta,

I'd be interested in hearing your response to:

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=54772&tid=1291933409
https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=54773&tid=1291933409

This regards the use of LWS, the definition of ABNF for the new construct, and a few other things that you didn't address in this latest revision.

The new BNF seems more correct, though at a price in complexity (and a new syntactical invention).  The definition of 'f' is quite strange, especially since they don't seem to be linked back to n and m.

You don't need to be so rigorous in your definition of the expansion.  I'd prefer to see more rigour devoted to the ABNF for the ABNF.

--Martin

On 2010-12-09 at 04:42:58, Mykyta Yevstifeyev wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Mykyta Yevstifeyev <[email-masked]>
Date: Fri, 10 Dec 2010 09:44:18 +0200

Hello all,

Some notes:

> https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=54773&tid=1291933409
They generally refer to -01 version draft. Most of problems have been
solved in the -02 version. As for the second link, I'll try to take
these comments into account while prepaing the new version of the
draft or maybe response it later.
> This regards the use of LWS, the definition of ABNF for the new construct,
> and a few other things that you didn't address in this latest revision.
>
> The new BNF seems more correct, though at a price in complexity (and a new
> syntactical invention).  The definition of 'f' is quite strange, especially
> since they don't seem to be linked back to n and m.
>
I tried to found the construction which will return 0 if no elements
used and 1 if at least one elemnt is used. What I assigned for 'F' of
a definition of this construction. There is no simplier way to express
it. The problem I am trying to solve is if we have n=0 and do not put
the f(element) construction in the end, separator will occure at the
end of the list. And if we put just 'element', it will be obligatory 1
element even if we don't use any.
> You don't need to be so rigorous in your definition of the expansion.  I'd
> prefer to see more rigour devoted to the ABNF for the ABNF.
>
> --Martin
>
>
All the best,
Mykyta Yevstifeyev