Re: [arch-d] draft-iab-protocol-maintenance / JSON feedback

[Martin Thomson <[e-mail]>]

Thanks Rob,

I realize that different people might reach different conclusions about JSON.  It has a rich and storied history that a single paragraph cannot effectively capture.  My goal in writing that was to give just a glimpse into that mess.  For some, this is evidence that JSON is an irreconcilable mess.  For others, it is a failing at the IETF to implement practices that ensure specifications and deployments concur.  Yet others look at the ECMA spec and see that community as having provided a definition that works as a means of describing what is interoperable.  As you say, some others might see the loose specification as a virtue as it motivated deployment.

My view is that each of these perspectives is correct and useful.  Including yours.  Though, like the somewhat loose protocol definitions of the 1980s, I don't think that RFC 4267 is what JSON needs.  Nor is anything else the IETF has produced on JSON sufficient.  That isn't to say that they weren't worthwhile exercises or that time was wasted on those efforts.

I wasn't close enough to those efforts to say what was learned.  Maybe the ECMA specification isn't the last word on the JSON story.  That's not the point here.  This only demonstrates how hard it can be to clean up a mess once made.  And maybe that sometimes the mess can get too big to ever clean, depending on the actual outcome with JSON, that is.

On Mon, Jul 18, 2022, at 07:56, Rob Sayre wrote:
> Hi,
>
> I'm sympathetic to concerns raised in the document, but I think the 
> JSON example is not a very good one.
>
> JSON was deliberately underspecified because it would work most of the 
> time* in languages where typical payloads could get by using an 
> "eval()" function, rather than requiring an implementation at all, 
> JavaScript and Python being the most common. RFC4627 was an 
> after-the-fact production, the problems were already there.
>
> So, the JSON case is actually showing that loose specification can 
> drive adoption (like HTML etc). I do not think that's the point you 
> intended to make.
>
> thanks,
> Rob
>
> * the problems mentioned in the draft are real, but rare and often not obvious
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss