Re: [Cbor] RFC7049bis processing of unknown tags

[Jeffrey Yasskin <[e-mail]>]

On Thu, May 7, 2020 at 4:42 PM Michael Richardson <[e-mail]>
wrote:

>
> 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.
>

That's all reasonable. :) Given the discussion, and Lawrence's quick
analysis of the existing tags, how do you currently feel about the state of
RFC7049bis's requirements around error handling?

* I'm not opposed to advice for parsers to have an option to treat a value
tagged with an unknown tag as equivalent to the value itself.
* I dislike the idea of any generic parser doing that by default, I think
based on reasoning like in
https://tools.ietf.org/html/draft-iab-protocol-maintenance-04.
* If a parser passes unknown tags up to the application, a higher-level
protocol can ignore them itself, skip their data item, return an error, or
do something else appropriate to the context. So if the RFC should
recommend a default in generic parsers, I'd vote for that one.
* I don't intend to draft this wording myself. :)

Jeffrey