Re: [Cbor] Robert Wilton's No Objection on draft-ietf-cbor-file-magic-11: (with COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Rob,

thank you for this input.

> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Hi,
> 
> Apologies for a late review, and there is just one none blocking issue that I
> wanted to raise:
> 
>   It is further
>   suggested to avoid values that have an embedded zero byte in the four
>   bytes of their binary representation (such as 0x12003456), as these
>   may confuse implementations that treat the magic number as a C
>   string.
> 
> I was less convinced by this statement because:
> (1) It seems like C treating this as null terminated string is probably not the
> right thing to do,

It is not, but I have seen too much code doing that with magic numbers (strncpy, that is).

> I'm not sure that we should be implicitly endorsing that.

Of course, we could decide that we make zero bytes prominent enough and mention that strncpy is not the way to do this.

> (2) When translating values from the Content-Format registry means that this
> issue is presumably unavoidable.  I.e., it looks like your example in 2.2.1
> violates this guidance.

It does.

This is easy to fix by using

0x63740000 + (ct / 255 + 1) * 256 + ct % 255 + 1

as the tag number (*).

So we have the choice between 

(1) not suggesting avoiding zero bytes or 
(2) making the above change to the content—format-number to tag-number mapping.

Grüße, Carsten

(*) Generally, this will not be a runtime computation, as the content-format number will be looked up manually and translated into a tag number using a formula at or before compiling — the difference is just the complexity of the formula.