[Cbor] Re: Criteria for "rough consensus to keep"

[Joe Hildebrand <[e-mail]>]

Those both make sense to me.

— 
Joe Hildebrand

> On Jul 10, 2026, at 9:46 PM, Rohan Mahy <[e-mail]> wrote:
> 
> Hi Joe,
> 
> I think we want to consider two additional questions:
> 
> 0a. "Is all valid JSON, also valid EDN?". 
> I think the answer is yes.
> 
> 0b. "Does EDN need to be able to represent all valid CBOR?" With or without extensions? I think it does. I am ok if that requires extensions for which there is an existing extension point.
> 
> 
> On Fri, 10 Jul 2026, 07:34 Joe Hildebrand, <[e-mail]> wrote:
> Here is my suggestion for criteria, with the goal to produce a document that has the minimum subset of new features for which the WG has clear consensus in a relatively short amount of time:
> 
> 1. If the feature exists in RFC 8949 or RFC 8610, and is in -26, it will not be considered for removal.
> 
> Do we want to consider whether there are any RFCs that actually use the feature? (It is actually possible to enumerate this entire list using the datatracker). If so, there are features in RFC 8610 that I believe don't appear in EDN in any RFC (except 8610 itself):
> - comments inside h'' and b64''
> - hexfloat syntax: 0x1.8p0  and  0x18p-4
> - octal (0o11147) and binary (0b1001001100111) integer forms
> 
> Do we want to consider # end of line comments as "previewed" in RFC8610 since they are mentioned in G.6?
> 
> 2. If the feature has at least two participants in the WG who have a valid (as judged by the chairs) technical reason to remove it, it will be removed, iff:
>   a. There is a way to add the feature later through an existing extension point OR
>   b. There is a way to add the feature later using a syntax that will cause an implementation of this document to fail with an error when that feature is encountered.  We WILL NOT actually design that syntax, only show an existence proof that at least one such syntax exists.
> 
> 3. If there is disagreement on whether the feature is feature is possible to remove using the criteria of point 2, we err on the side of removing the feature.
> 
> 4. It is the responsibility of one of the people that desire the feature to be removed to provide a path forward from point 2 above that is technically valid.
> 
> 5. If there are features nobody wants to remove, we can't come to consensus on how they work, and there exists a way to add them later according to point 2 above, they will be removed.  The chairs can assign someone to do the work from point 2 in this case.
> 
> 6. No new features from here out, unless there is some technical reason why the document won't work without the feature, and there is unanimous consent on that reason.  (in other words: no new features)
> 
> 7. True editorial changes are still allowed, including more examples.  This includes small changes in the ABNF for the purpose of clarity.
> 
> I am good with the rest of the rules.
> Thanks,
> -rohan
>  
> I'm open to any suggestions for change in these criteria.  Coming to consensus on them quickly is more important to me than any of the particulars.
> 
> — 
> Joe Hildebrand
> 
> > On Jul 9, 2026, at 4:59 PM, Paul Hoffman <[e-mail]> wrote:
> > 
> > Greetings again. This thread is for the WG to discuss the criteria they want the WG chairs to use when determining which features to keep in draft-ietf-cbor-edn-literals-26. Please note that the IETF doesn't "vote", we aim to find rough consensus. Please see RFC 7282 for guidance on this (https://datatracker.ietf.org/doc/rfc7282/) and riff off that for this particular discussion.
> > 
> > --Paul Hoffman, for the chairs
> > 
> > _______________________________________________
> > CBOR mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> CBOR mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]