Subject: [apps-discuss] Some notes on ABNF notation for separated lists

From: Mykyta Yevstifeyev <[email-masked]>
Date: Mon, 13 Dec 2010 13:54:52 +0200

Hello all,

I have carefully reviewed all the messges which concern my ABNF
notation for separated lists. So some omments and thoughts:

Firstly, there have been a discusion about the form of notation.
Several variants have been proposed, the latest is
<n>*<m>[^<a>]element and I think it is quite acceptable. Moreover, the
corresponding form <n>^<a>element has been proposed. I think that will
be OK too. These proposals will be taken into consideration while
preparing the new version of the draft.

Secondly, there have been a discussion on to put or not to put the LWS
in the notation ABNF description. Maybe it is OK to remove it from the
definition but allow the user to put it manually in the <a> part.

Thirdly, it is a topic to discuss about the definition of separator.
However I don't think the form 1*VCHAR is bad or not acceptable for
this occasion. It is obvious that separator can be only visible chars.
But I think it would be useful to put the restriction on maximum
amount of chars in separator - maybe 56 is enough. what do you think
about this?

Lastly, the problem seems to be in security Consideration section. The
only issue mentioned while discussing was that spaces may occure in
the defined rule while we do not need them and this will cause the
problem. However as I'll correct the rule it will not create any
problems. However any suggestions for Sec. Cons. section are welcome
as well as other ones.

So I'll try to take all the comments into considerations. I'll let you
know when the new version of the draft will be available.

Best regards,
Mykyta Yevstifeyev

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Dec 2010 06:20:29 +0800

> this occasion. It is obvious that separator can be only visible chars.

There are two concerns: 

 - what is acceptable in the ABNF syntax for the  describing the separator
 - what is acceptable in the target grammar for the separator

The ABNF syntax needs to be constrained so that the ABNF parser is able to distinguish separator from other parts.  This is easy: use the existing ABNF for ABNF constructs to describe these limitations.

The target grammar should not be similarly constrained.  It should be possible to use any form of separator.

The existing <element> rule seems most appropriate.

> amount of chars in separator - maybe 56 is enough. what do you think

Arbitrary constraints on length aren't helpful.

--Maritn