Re: [Cbor] Do we care about array-tags issue 6, clamped-uint8 arrays?

I find round-tripping with ES6 TypedArray to be a sufficiently compelling use case, that it should stay in.

That being said, the fact that typed arrays is prompted by and mirrors ES6 TypedArrays—a non-CBOR standard—also prompts me to call for having the tags assigned in the > 255 space. If more TypedArray types are defined in that spec, it is easier to assign the tags to CBOR in a larger block of numbers.

That issue, I feel, was never actually resolved on the merits. I believe that the assignment of tags in the 1-byte space (40-255) provides less flexibility and extensibility than assigning them in the 2-byte space (256-65535).* The case in point illustrates that between draft-ietf-cbor-array-tags-00 and draft-ietf-cbor-array-tags-03, the tag 1040 got introduced seemingly came out of nowhere and broke up the nice block of numbers. Since 1040 has been introduced anyway, that is a strong indication that everything should be in the 256-65535 space.

Sean

*or they could be called 2-byte space and 3-byte space: it’s not clear if there is a consistent definition that we have been using.

> On Jul 24, 2019, at 6:17 PM, Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org> wrote:
> 
> On Wed, Jul 24, 2019, 4:41 PM Carsten Bormann <cabo@tzi.org <mailto:cabo@tzi.org>> wrote:
> To make sure that we don’t create a trap for generations to fall into, a paragraph could be added to the security considerations..
> 
> That sounds like a good idea.
> 
> Jeffrey
> 
> Generally speaking, an implementation that wants to perform operations on input data will need to validate that to be appropriate for that beforehand.  The potential trap here might be that a Uint8ClampedArray might feel a lot more like a Uint8Array than other types do to each other so the validator would be misled.  So don’t do that…
> 
> Grüße, Carsten
> 
> 
> > On Jul 24, 2019, at 16:01, Jeffrey Yasskin <jyasskin=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote:
> > 
> > In https://github.com/cbor-wg/array-tags/issues/6 <https://github.com/cbor-wg/array-tags/issues/6> I complained that
> > tag 68, marking clamped-uint8 data, is weird, in that clamped-ness is
> > a property of further processing rather than the data encoded in CBOR.
> > I worried that we might introduce security issues by allowing a
> > potentially-malicious sender to decide how the recipient processes the
> > received data.
> > 
> > More abstractly, I believe this is the only tag in the document that
> > extends the CBOR generic data model.
> > 
> > I don't think the current text adequately describes when a recipient
> > should create a Uint8ClampedArray from potentially-untrusted input
> > data. But I 1) didn't object during the last call and 2) don't think
> > this is a big enough issue to try to hold up the process if other
> > folks think it's fine.
> > 
> > So, how do other folks feel about the marker for clamped uint8 arrays?
> > 
> > Thanks,
> > Jeffrey
> > 
> > _______________________________________________
> > CBOR mailing list
> > CBOR@ietf.org <mailto:CBOR@ietf.org>
> > https://www.ietf.org/mailman/listinfo/cbor <https://www.ietf.org/mailman/listinfo/cbor>
> > 
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor