Re: [Cbor] RFC7049bis processing of unknown tags

[Michael Richardson <[e-mail]>]

Jeffrey Yasskin <[e-mail]> wrote:
    > 3) While RFC7049-bis is already
    > somewhat overstepping the bounds of a standard in specifying
    > error-handling options, it'd be even farther out of bounds to specify
    > parser API options. :)

I disagree strongly with this part :-)

It's is a regular and common mistake in IETF/many specifications that they do
not adequately explain what the behaviour is supposed to be when a newer
option shows up.  We probably spend 70% of our time at the IETF making sure
that we don't break old code.
Is that too high?  Well, maybe, because we don't spend the effort up-front.

As an example: IKE (IPsec) has a major and minor version.
We have no idea what it would mean to increment the minor version.
Having a minor version was a waste of time.

(I crafted the text for the VendorID payload in IKEv1.
I believe that I got it right, and made sure that we could make
use of private extensions without conflicts in the number space)

As for API options, yes, we often do need to give advice on providing ways to
put things into compatibility mode, and what that means.  At no point are we
writing down some enum or #define though.

I believe that I am less concerned about having rfc7049bis render some
existing parsers "non-compliant" --- they *ARE* still compliant to RFC7049.

I am a user of parsers, I have occasionally had to write my own conversions,
but mostly I would say that I am not up to speed on some of the details.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-