Re: [apps-discuss] draft-farrell-decade-ni-02: glitch in examples

[Ari Keranen <[e-mail]>]

Hi James,

Thanks for the comments! And sorry for the late reply.

The base32 encoded versions of the CRCs were indeed wrong in the draft. 
Good catch. After getting it right only after a considerable amount of 
hacking, we came into conclusion that it's not worth the effort. If it's 
really that hard to get right, it should be made more simple.

Therefore, we changed the encoding from base32 to base16 (hex) for both 
the hash and the CRC. While adding a few character of length to the 
hashes (but not to CRCs since now the lengths align perfectly), this 
also removed all the complexities with padding that was a bit pain to 
both specify and implement.

Yet, I think it's better to calculate the CRC over the whole string 
since then we protect also the hash-algorithm part. Also, it's a bit 
simpler to implement since you don't have to parse the string and 
convert hash back to binary for the checksum (e.g., if you do the check 
in the UI). We clarified that the input needs to be in UTF-8.


Cheers,
Ari

On 4/11/12 5:34 AM, Stephen Farrell wrote:
>>
>> I am not sure what the correct checksums are.
>>
>> The example checksums (eokv and csdh) look wrong. I assume the 4
>> base32 chars in the checksum should encode 5+5+5+1 bits respectively
>> of the 16-bit CRC. Hence the last char encodes 1 bit, padded with 4
>> zeros: either 00000 or 10000, which should give 'a' or 'q' (not 'v' or
>> 'h').
>>
>> P.S. A CRC16 is calculated over an array of bytes. However the input
>> is defined as a text string. I guess ASCII/UTF-8 encoding is assumed.
>> It might be better to calculate the CRC over the bytes of the
>> truncated hash.
>
> Fair point. OTOH, that'd mean omitting the "nih:sha-256;" part but
> I guess that'd be not much harm.
>
> I suspect that you may be right about the checksum. Will check with
> co-authors more involved with CoAP (Ari basically) to see what they
> prefer, since its them that want the CRC.