Re: [abnf-discuss] Should RFC 7405 be part of STD 68 now?

[Carsten Bormann <[e-mail]>]

On Dec 19, 2023, at 16:10, Dave Crocker <[e-mail]> wrote:
> 
> On 12/19/2023 12:40 AM, Carsten Bormann wrote:
>> Apart from that, is there anything that is getting in the way of promoting STD 7405 to be part of STD 68?
> 
> Widespread adoption is a good indicator that standards status is appropriate for a specification.
> 
> Combining specifications is a different matter.
> 
> The issue is whether it is a good idea to make the mandatory core of a specification bigger and more complex?

RFC 7405 is, what was it, 4 pages?
It solves one specific problem where ABNF shows its age more than in other places:
In 1978, it was natural to specify text-based protocols that were case-insensitive.

45 years later, this is now entirely out of fashion.
Not because of a fashion cycle, but because we are using text-based protocols in environments where it is easy to type letters in the case the protocol requires.
(Of course, RFC 7405 does not take away ABNF’s good support for case-insensitive ASCII, where that is still useful.)

The alternative to using RFC 7405 is doing unnatural acts (*), so one mostly simply references both, creating complexity in the spec using ABNF.

> That is, while the two specifications here might each be widely used, is it reasonable to impose a burden on all implementations that they implement both?

From my perspective of using ABNF for modern protocols:
Most emphatically, yes!

Given its almost trivial nature, it is way more of a burden to support RFC 7405 separately than to simply support it always.

> Simply adding 7405 to STD 68 will make it a requirement that all engines claiming to do ABNF must support this feature.  Is that reasonable?

Very much so.

Grüße, Carsten


(*)
From RFC 4997, IIRC the first RFC I contributed to where I was really miffed with being stuck with case-insensitive string literals:

   ; case-sensitive literals
   C            = %d67
   COMPRESSED   = %d67.79.77.80.82.69.83.83.69.68
   CONTROL      = %d67.79.78.84.82.79.76
   DEFAULT      = %d68.69.70.65.85.76.84
   ENFORCE      = %d69.78.70.79.82.67.69
   INITIAL      = %d73.78.73.84.73.65.76
   LENGTH       = %d76.69.78.71.84.72
   THIS         = %d84.72.73.83
   U            = %d85
   UNCOMPRESSED = %d85.78.67.79.77.80.82.69.83.83.69.68
   VALUE        = %d86.65.76.85.69
   VARIABLE     = %d86.65.82.73.65.66.76.69
   false        = %d102.97.108.115.101
   true         = %d116.114.117.101

Here is a more recent one (draft-ietf-jsonpath-base-21.txt, in RFC editor queue):

   escapable           = %x62 / ; b BS backspace U+0008
                         %x66 / ; f FF form feed U+000C
                         %x6E / ; n LF line feed U+000A
                         %x72 / ; r CR carriage return U+000D
                         %x74 / ; t HT horizontal tab U+0009
                         "/"  / ; / slash (solidus) U+002F
                         "\"  / ; \ backslash (reverse solidus) U+005C
                         (%x75 hexchar) ;  uXXXX      U+XXXX

Here we decided to eschew RFC 7405, which doesn’t make the spec any more readable.