tag 999 error handling guidance needed (opsdir review)

[cabo]

Archived-At: https://mailarchive.ietf.org/arch/msg/last-call/AF4-C6Qibc_qg8A8BOoeV52RAEQ

The use of 999 is already marked as exceptional in 3.1: https://www.ietf.org/archive/id/draft-ietf-cbor-edn-literals-09.html#section-3.1-2

Maybe we indeed want to add some language that avoids a situation where tag 999 items start to pollute into tools that are not prepared to handle them.

[chrysn]

My kneejerk reaction is that this is coming from not being familiar with tags -- handling any unknown tag is usually a stop-and-fail on the consumer side (maybe not at parsing time when building a DOM-like structure, but then at traversing time) unless working on a very general level (at which 999 may or may not be understood).

From that, a sentence to add would start with "As with any other tag a consumer is not expecing. …".

[cabo]

My kneejerk reaction is that this is coming from not being familiar with tags -- handling any unknown tag is usually a stop-and-fail on the consumer side (maybe not at parsing time when building a DOM-like structure, but then at traversing time) unless working on a very general level (at which 999 may or may not be understood).

While that may be true, I do feel that tools may want to handle 888 and 999 specially even before they bump up in an application’s tag processing. This could be worth a sentence.

E.g., tools like cbor-diag might provide flags that say “ellipsis expected” or “unknown application prefixes expected”, and throw errors (or warnings) if these occur without such a pre-warning.

Grüße, Carsten

[chrysn]

At least the way I'm writing it, the EDN tool's main way to pass on data (when not doing manipulations on EDN level) is to encode it to CBOR, and that encoding will fail unless there is an explicit preprocessing step that turns ellipses into 888 etc. Stating clearly that EDN tools are not supposed to emit 888/999 just because they are fed ellipses/unknown-literals is what I thought was in there already, but at any rate would be a welcome statement. (It's a bit of extra work when the EDN tool internally uses 888/999, but that I'd only expect of edn-cbor converters and not of EDN editing tools, and the converters could also just fail processing in presence of those unless there is a switch).