[Top] [All Lists]

Re: Last Call: 'Augmented BNF for Syntax Specifications: ABNF' to Draft Standard

2004-05-25 01:30:00

I assume this last-call is a request to advance the ABNF spec without changes.

Without wishing to oppose such a move, maybe this is a reasonable time to raise a question about the way ABNF is specified with respect to case (in)sensitivity.

Currently, productions that contain literal (US-ASCII) letters are defined by RFC234 as indicating any combination of upper and/or lowercase for those letters. This seems to be at odds with modern approaches to protocol and data design, which (driven to some extent by I18N issues) tend to prefer that data elements are case sensitive. An obvious example of this is XML.

I had a real experience not so long ago of using ABNF and needing to specify case sensitive keywords in an IETF WG specification -- the "official" solution of using character codepoint values was, in my view, most unhelpful with respect to readability.

I don't claim it's helpful to revise ABNF at this juncture of the process, but maybe it's time to start thinking how to more easily specify case sensitive text. Some thoughts that occur to me are (without judgement as to whether they are good or bad):

(a) require a using specification to indicate case sensitivity (which I regard as an option today, but there is a concern about possible confusion if not done sufficiently clearly).

(b) add some kind of case-sensitivity "declaration" to ABNF (probably not very helpful when ABNF is presented as fragments throuout a document).

(c) add some kind of alternative literal string syntax to indicate case sensitivity (e.g. like the Python convention for different string conventions, which uses a prefix letter before the literal; u"xyz" indicates a Unicode string, or r"abzcd" one in which the '\' is not interpreted).


At 10:41 24/05/04 -0400, The IESG wrote:
The IESG has received a request to consider the following document:

- 'Augmented BNF for Syntax Specifications: ABNF '
  RFC 2234 as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg(_at_)ietf(_dot_)org or ietf(_at_)ietf(_dot_)org mailing lists by 

The file can be obtained via

Implementation Report can be accessed at

IETF-Announce mailing list

Graham Klyne
For email:

<Prev in Thread] Current Thread [Next in Thread>