[Cbor] Re: EDN redux

[Rohan Mahy <[e-mail]>]

Since you have gone so far as to propose no ABNF, a radically simple
solution would be to not allow extensibility of app-strings. Define a set
of them now and be done.

thanks,
-rohan

On Wed, Aug 7, 2024 at 7:49 AM Carsten Bormann <[e-mail]> wrote:

> On 2024-08-07, at 15:41, Rohan Mahy <[e-mail]> wrote:
> >
> > The analogy with JSON is critically flawed because the JSON format is
> used "on the wire" as is, while EDN app-strings need to be converted to a
> specific format (often bstrs) in CBOR, each with their own grammar.
>
> I don’t see how that is a flaw of the analogy — this observation is even
> more of a motivation to keep up the separation (think: tag 999).
>
> > All other substantive applications of ABNF at IETF use a single pass
> definition of the grammar.
>
> This look at the past may have been true up to October 2017 (publication
> date of RFC 8288); I didn’t analyze all use of ABNF in the IETF.
> But, looking more closely, that is just an artifact of defining layers of
> a grammar in such a way that you don’t immediately see that they are layers.
>
> > Using the ABNF in another way goes against 40+ years of precedent.
>
> There is no “use of ABNF in another way”.  There is a use of ABNF
> according to the layering of the protocol.  Just as you wouldn’t cram SDP
> ABNF into a single layer SIP ABNF.
>
> > It is just weird and will trip up other implementers.
>
> I don’t agree with this prediction.
>
> > The examples given where someone wanted to include an ABNF in an
> app-string from an earlier specification which is broken or inconsistent,
> clearly signal to me that spec writers need to take the time to fix those
> problems by writing a clean ABNF rather than write new specs that import
> garbage productions wrapped with extra layers of encoding and processing.
>
> I was in the room when Julian Reschke explained the rationale for cleaning
> up RFC 5988 to become RFC 8288, echoing all the concerns we had found
> independently when doing RFC 6690.  Not everybody had this kind of
> background.  Indeed, many people did not immediately understand why the
> separation of layers makes sense.  But in the end, the benefits of proper
> layering prevailed.
>
> > Overall this two-pass concept has been optimized to make life harder for
> implementers
>
> It sure makes *my* implementations simpler, so I can’t follow.
>
> > and easier for people who want to specify new app-strings.
>
> That is indeed one benefit (not just easier, but likely more correct).
>
> > We should not be writing IETF specifications with that property.
>
> HTTP has decided to go for structured fields [1] as its layering on top of
> the text-based (HTTP/1.1) and binary (H2, H3) serializations.
> (For backwards compatibility reasons, they had to come up with something
> specific to HTTP, and they are experiencing problems in using ABNF as is.
> In EDN, we so far don’t.)
>
> [1]: RFC 8941, with the replacement draft-ietf-httpbis-sfbis in the
> RFC-editor queue
>
> More generally speaking, these days we are writing specifications while
> considering that extension points should be easy to employ (both when
> writing the specifications and when writing the implementations).
>
> I’m having a hard time understanding why CBOR EDN, which isn’t even meant
> as an interchange format, triggers this hardline “we must do it like we did
> 20 years ago” [for one understanding of what that may have been] response.
>
> As a way forward, we could simply remove the ABNF — it is available in the
> WG draft for implementers that want to base their work on ABNF.  That would
> be counterproductive, but might allow us to move forward in this
> inexplicable situation.  I would prefer a solution with less damage, though.
>
> Grüße, Carsten
>
>