Subject: [Cbor] Draft for an error indication tag (Fwd: I-D Action: draft-richter-cbor-error-tag-00.txt)

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Jan 2019 11:27:17 +0100

Jörg Richter has suggested defining a CBOR Tag for error indications, beyond what the “undefined” simple value can already do.
I have helped a bit in writing this up.
Maybe we can have a quick sanity check before we ask IANA to register this Tag.
(The suggested value will be 101, ASCII ‘e’ for error, exception.)

Grüße, Carsten

> Begin forwarded message:
> 
> From: [email-masked] <mailto:[email-masked]>
> Subject: I-D Action: draft-richter-cbor-error-tag-00.txt
> Date: January 29, 2019 at 11:22:56 GMT+1
> To: <[email-masked] <mailto:[email-masked]>>
> Reply-To: [email-masked] <mailto:[email-masked]>
> Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/rLnFJ7vaZKn5EcvR869Ol8tAqAk <https://mailarchive.ietf.org/arch/msg/i-d-announce/rLnFJ7vaZKn5EcvR869Ol8tAqAk>>
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>        Title           : Concise Binary Object Representation (CBOR) Tag for Error Indications
>        Authors         : Joerg Richter
>                          Carsten Bormann
> 	Filename        : draft-richter-cbor-error-tag-00.txt
> 	Pages           : 4
> 	Date            : 2019-01-29
> 
> Abstract:
>   The Concise Binary Object Representation (CBOR, RFC 7049) is a data
>   format whose design goals include the possibility of extremely small
>   code size, fairly small message size, and extensibility without the
>   need for version negotiation.
> 
>   In CBOR, one point of extensibility is the definition of CBOR tags.
>   While CBOR defines representations for null values and for an
>   undefined value, there is no convention for expressing errors or
>   exceptions in data structures, where the actual value desired could
>   not be calculated due to an error.  The present specification defines
>   a tag for such error indications, enabling the addition of varying
>   levels of detail.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-richter-cbor-error-tag/ <https://datatracker.ietf.org/doc/draft-richter-cbor-error-tag/>
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-richter-cbor-error-tag-00
> https://datatracker.ietf.org/doc/html/draft-richter-cbor-error-tag-00

---

From: Joe Hildebrand <[email-masked]>
Date: Tue, 29 Jan 2019 09:52:36 -0700

I like it.  One thing I would suggest is if a map is used, that a couple of keys are suggested, but not required:

{
  name: "maybe-a-uri-or-classname",
  code: 404, // HTTP-style error code
  message: "human-readable description",
  fileName: "file where error occurred"
  lineNumber: 12, // line in file where error occurred
  columnNumber: 6 // column in file where error occurred
}

This should get a bunch of error patterns to interoperate quickly, including most things derived from JavaScript's Error class.

> On Jan 29, 2019, at 3:27 AM, Carsten Bormann <[email-masked]> wrote:
> 
>> From: [email-masked]
>> To: <[email-masked]>
>> Reply-To: [email-masked]
>> Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/rLnFJ7vaZKn5EcvR869Ol8tAqAk>
>> 
>> 
>> https://datatracker.ietf.org/doc/draft-richter-cbor-error-tag/
>> 
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Jan 2019 16:51:25 +0100

On Jan 29, 2019, at 17:52, Joe Hildebrand <[email-masked]> wrote:
> 
> a couple of keys are suggested

The -01 I just submitted has those.
Please have a look at the slightly shortened keys and in particular at the discussion of the “fileName”…

https://tools.ietf.org/rfcdiff?url2=draft-richter-cbor-error-tag-01.txt

Grüße, Carsten

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 30 Jan 2019 12:37:57 -0700

+1.  Great addition.  I don't mind "source" over "file".  That makes it clear enough that you could put a (potentially relative) URI there if desired.

I also really like the security considerations.

typo of "reallu" in section 2.

> On Jan 30, 2019, at 8:51 AM, Carsten Bormann <[email-masked]> wrote:
>