Re: [apps-discuss] I-D Action:draft-yevstifeyev-abnf-separated-lists-01.txt

[Mykyta Yevstifeyev <[e-mail]>]

Hello all,

I have get known that there is a discussion of my draft on this list 
(IETF-discuss). So some notes
on what have been already posted:
>
> I wholly agree with Bill on this.
>
> You want something a little more complicated than you have already 
> specified:
>
> {n}^({a}){m}{e} => {e} {n-1}*{m ? m-n : ''}({a} {e}) ; where n > 0
> {e} *{m ? m-1 : ''}({a} {e}) ; where n == 0 or n undefined
This is not what is mentioned in my draft. Especially in the case when n=0.
>
> Note the n == 0 is a special case. Note that this assumes that m > n. 
> There seems little point in this construction if m == 1, but this does 
> handle that case.
If m=1, there is no need to use the defined construction. It is 
1<element> and nothing else.
>
> Aside from those sorts of problems, the definition of 'a' is a little 
> loose. You should try to build on the RFC 5234 ABNF in your definitions.
>
> The proposed rule has an ABNF definition something like (?):
>
> hat-rule = 1*DIGIT "^(" a ")" 1*DIGIT
> a = VCHAR / SP / HT / <any other separator>
>
> That's a lot of flexibility in the internal part. Too much 
> flexibility. Using parentheses means that they need to be 
> distinguished from the parentheses that might appear in the 'a' part.
>
> If you see this as a substitute for the "*" in a normal repetition 
> rule, that makes it easier. Given that it has length longer than 1 
> character, by providing a clear delineation of the start and end you 
> can be more flexible on the content. Either that or to restrict what 
> follows the ^.
>
> Preferably delineate better AND restrict content:
>
> repeat /= hat-rule
> hat-rule = *DIGIT "^" element "^" *DIGIT
OK. It will be taken into consideration.
>
> This restricts the content without preventing the use of more complex 
> content - you just have to use a rulename instead.
>
> You can't use elements (note the 's') here because that sort of 
> complexity is a real pain to specify.
What do you mean?
>
> That leaves examples:
>
> 1^";"^3element ; 1 to 3 elements separated by ;
> 1^SP^element ; 1 or more elements separated by SP rule
> ^","^3element ; 0 to 3 elements separated by ,
> ^%x20.20^element ; any number of elements separated by a two space 
> characters
Will be corrected.
>
> You should try to answer the question in the draft: why use the '^' 
> character instead of the '#' character? I guess that this is an 
> arbitrary choice more than anything else.
# is already used in RFC2616 and ^ is used in order to to make the 
conflict between these documents.
>
> --Martin
>
> On 2010-12-07 at 11:07:17, Bill McQuillan wrote:
> > I found several problems with this draft.
> >
> > In overview, the reason that we removed the #rule from ABNF was that it
> > was
> > very difficult to specify for a general case. This draft has the same
> > problem.
> >
> > The production given does not actually produce the desired results.
> >
> > > n^(a)m element = ( n(*LWS element) *o(*LWS a *LWS element))
> >
> > If the usage is:
> >
> > 5^(",")10 "abc"
> >
> > it would allow something like:
> >
> > abc abc abc abc abc abc , abc
> >
> > not:
> >
> > abc, abc, abc, abc, abc, abc, abd
> >
> > which was probably intended.
> >
> > -----
> >
> > The production:
> >
> > > a = VCHAR / SP / HT / <any other separator>
> >
> > does not seem to address the possibility of multi-character separators
> > very
> > clearly. What if I want to define a list like:
> >
> > abc and def and ghi and jkl
> >
> > can I use:
> >
> > ^(" and ")ident
> >
> > -----
> >
> > I also do not believe that *FWS belongs in such a general rule and
> > should
> > rather be defined by the actual usage. E.g.:
> >
> > 5^(*FWS "," *FWS)10 "abc"
> >
> > -----
> >
> > Typo: 2.1 Examples, fourth example should be: ^("-")element
> >
> > --
> > Bill McQuillan <[e-mail]>
> >
> > _______________________________________________
> > Ietf mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ietf
>
>
Bill,

All your propositions have been taken into consideration. These comments 
concern -01 draft.
As for FWS, it is *element so it can be used and can not be used.
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
I really believe that the construction I have used is acceptable for all 
cases. Now I am working on -03 version
of the draft so I'll get known when it will become available.

All the best,
Mykyta Yevstifeyev