Re: [Cbor] Cutting down base64 (b64'....') in diagnostic notation examples, before elision

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> wrote:
    > (1) Random observation, most relevant until we have elision:

    > If you randomly truncate a base64 string (no padding), there is only a
    > 1 out of 3 chance (actually 21/64) that the result will still be a
    > base64 string (no padding).  If you cut it down to a multiple of 4
    > characters, the result will always be valid.

That's a good point.
I wonder if this is worth sharing with the RPC people in some fashion.

    > (2) The current implementation of cbor-diag does not allow comments in
    > b64’…' (https://github.com/cabo/cbor-diag/issues/22).  However, they
    > already work in h’…’ byte strings, so…

    > h’47110815/.../‘

    > …or more verbosely…

    > h’47110815/... (rest of CWT omitted)/‘

Very Very Cool.

    > Because of the abovementioned bug, I’d use

    > b64’A7ii08iS'/... (rest of CWT omitted)/

    > …for now if b64 is needed (but see note about truncation above).

This email needs to go into some reference for people.

Maybe two slides posted to CBOR WG meeting tracker, URL sent around to
wgchairs.

"Is you internet-draft suffering from CBOR diagnostic notation bloat?"
"Is xml2rfc complaining about too long lines, and you just aren't sure how to
fix that?"
"Available now, for an unlimited time, the CBOR how-to-elide HOWTO"

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [