RE: AD Evaluation of draft-ietf-imapext-2086upd

[Mark Crispin <[e-mail]>]

On Thu, 19 May 2005, Pete Resnick wrote:
> There is no technical issue with regard to reference to RFC 2234. The ABNF in 
> the document is correct and is correctly used as per that specification. The 
> only question is whether:
>   Formal syntax is defined using ABNF [ABNF] as modified by [IMAP4].
>   Non-terminals referenced but not defined below are as defined by
>   [IMAP4].
> is clear. (Specifically, whether the word "modified" is correct and whether 
> it is better to reference "IMAP4" or "IMAP".)

I now understand the problem.

Without arguing any of your other points, the "as modified by [IMAP4]" is 
wrong.  It's a remnant of something which is now moot.

The original text in RFC 2086 was "The following syntax specification uses 
the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as 
modified by [IMAP4]."

RFC 2060 inherited ABNF from RFC 822.  RFC 2234 obviously did not exist 
when RFC 2060 was issued.  RFC 822 had a "#" construct which indicated 
tokens separated by one or more commas; for example,
 	#("a" / "b" / "c")
could parse
 	b,c,,,,a

RFC 2060 modified the "#" construct so that it indicated tokens separated 
by one (and only one!) space; for example:
 	#("a" / "b" / "c")
could parse
 	b c a

RFC 2234 abolished the "#" construct entirely.  In modern times, the way 
that you would do the RFC 822 style "#" is with (assuming a definition of 
abc = "a" / "b" / "c"):
 	abc *(1*(0x2c) abc)
and the way that you would do the RFC 2060 style "#" is with
 	abc *(SP abc)

As both RFC 822 and RFC 2060 are obsolete, and that the current [IMAP] 
specification (RFC 3501) does not modify ABNF in any way, the text "as 
modified by [IMAP4]" is superfluous and should be removed.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.