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

[Vadim Goncharov <[e-mail]>]

On Sat, 11 Jul 2026 17:38:25 -0600
Joe Hildebrand <[e-mail]> wrote:

> > On Jul 11, 2026, at 5:20 PM, Vadim Goncharov <[e-mail]>
> > wrote:
> > 
> > On Sat, 11 Jul 2026 15:59:20 -0600
> > Joe Hildebrand <[e-mail]> wrote:
> >   
> >>> On Jul 11, 2026, at 11:32 AM, Vadim Goncharov <[e-mail]>
> >>> wrote:
> >>> 
> >>> Is
> >>> https://mailarchive.ietf.org/arch/msg/cbor/yEkzpxlj-xDGlBVCkibFG6XlOjM/
> >>> enough umbrella covering point 2b for all such possible features at
> >>> once?    
> >> 
> >> In my opinion, yes.  However, !pragma<<>> is an even easier argument,
> >> since it wouldn't require as drastic a change to the ABNF or as much
> >> look-ahead on # comments.  
> > 
> > Now it would be bikeshed for character?..  
> 
> Which we won't do, assuming we agree that there is at least one choice that
> would work.

I agree except small nuance: if *just* a syntax error is sufficent, then we
can stop now. If however we want *meaningful* error "this implementation
supports RFC NNNN syntax but the input contains syntax from later
specification", then we have to choose *something* recognizable. I'd prefer
second (and vote on /^#pragma/ regexp - implementations will likely still have
information in which column, for error reporting, so probably it's not big
burden).

We can have compromiss here, though: if we can't agree about recognizable
pattern for, say, 3 days - we can always fallback to "just syntax error" here.

> >>> 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)    
> >>> 
> >>> Do we consider h_2'str'_3 together with arbitrary per-extension encoding
> >>> indicators (200_ms, float_32le<<>>) a new feature or still part of a bug
> >>> to be fixed?    
> >> 
> >> In my opinion, both are new features that can be added later, but am
> >> willing to hear why that's wrong.  
> > 
> > I have impression that almost everyone (except Rohan & Carsten) agreed for
> > using unified t<<>> and b<<>> for both concatenation and indefinite-length
> > strings: the latter would look t_<<>>, and this implies having
> > extname_ei<<>> form, e.g. t_2'str' or t_2<<'foo', "bar">>. This fixes bug
> > of h'1234'_2 ambiguity. While allowing arbitrary encoding indicators for
> > per-extension discretion is, strictly speaking, not here - majority if it
> > is already in this soultion, so there is just a very little step.
> > Especially given that things like IP_2'1.1.1.1' are meaningless (even if
> > someone insists it is IP'1.1.1.1'_2 but still belongs to ext, not arg), so
> > per-extension interpeting of EIs is in fact already here, it is just dark
> > area not covered yet.  
> 
> That argument makes sense to me, but we would need to come to agreement VERY
> quickly if that turned out to be true.

This is bug that I've reported for more than a month (see that fight with
Carsten under "to chairs") which wasn't reacted, it must be fixed in any case.
Due to absence of reaction there just were no other proposals to fix other than
mine extname_ei<<>> which offered t_<<>> and float_32le<<>> as a bonus.
Probably other variants are possible, but time was lost (I did my best).

> So that would add another criterion:
> 
> - If a feature that does not have the two people necessary to remove it is
> not complete, it may be finished, but everyone involved must realize that if
> we don't converge on a solution quickly, the entire document is at risk.
> 
> I'm less sure about this criterion than the others, as it's really quite
> likely to end up with the work as a whole failing.

Same principle as above is applicable: when it is possible to defer to future
document, just do it. Like:

  | Interaction of app-prefixes and encoding indicators in form name_ei<<>>
  | or name_ei1'arg'_ei2 will be fully specified in future revisions of this
  | document.

and then specify just t_<<>> and b_<<>> - does it sound as reasonable fallback
for case if solution won't be found quickly?

-- 
WBR, @nuclight