Questions about the new draft #34
Comments
|
Yes this is accurate
Integer multiple with a minimum multiple of 1
L = N *4 N >=1 N integer
… On 30 Sep 2022, at 06:01 , Henk van Cann ***@***.***> wrote:
In commit fbc5bff <fbc5bff>
Under "conversions <https://github.com/WebOfTrust/ietf-cesr/blob/main/draft-ssmith-cesr.md#conversions>" last sentence:
"Likewise, this means that the length of any primitive in the T domain MUST be an integer multiple of 4 Base64 characters with a minimum length of four Base64 characters."
Is this correct? It doesn't make sense to me.
—
Reply to this email directly, view it on GitHub <#34>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETEPPB2Q3E7E7TLAUJBZ3WA3JAPANCNFSM6AAAAAAQZWWGD4>.
You are receiving this because you are subscribed to this thread.
|
|
Got it now |
|
Another question: how would you define 'naive conversion' This is my take: https://github.com/trustoverip/acdc/wiki/naive-conversion |
|
sorry 24 bit aligned
… On 30 Sep 2022, at 15:34 , Personal Sam Smith ***@***.***> wrote:
Non CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without pre-padding etc all the stuff CESR does to ensure aligns on 24 bit boundaries so CESR never uses the '=' pad character. But naive Base64 will pad if the length is not 14 bit aligned.
> On 30 Sep 2022, at 07:15 , Henk van Cann ***@***.*** ***@***.***>> wrote:
>
>
> Another question: how would you define 'naive conversion'
>
> This is my take: https://github.com/trustoverip/acdc/wiki/naive-conversion <https://github.com/trustoverip/acdc/wiki/naive-conversion>
> —
> Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETEPLHLITCNSUY2IQN3JLWA3RWVANCNFSM6AAAAAAQZWWGD4>.
> You are receiving this because you commented.
>
|
|
Thx, amended https://github.com/trustoverip/acdc/wiki/naive-conversion Next question. |
|
All four message serializations (JSON, CBOR, MGPK, CESR) may be interleaved in one stream. Message Bodies may be one of the four serializations. Attachments to Message Bodies are always CESR. The CESR pipelining codes enable the stream parser to detect what serialization is being for a given portion of the stream. For CESR encoded attachments and message bodies, the pipelining codes also allow interleaving Text CESR and Binary CESR with JSON, CBOR, MSGPK. So in reality there are 5 serializations supported. Text CESR, Binary CESR, JSON (text), CBOR (binary), MGPK (binary) |
|
The term composable is used with a very specific definition in CESR its called concatenation composability. So I don’t now from your question which definition of composable your are using with regards CBOR. CBOR can be interleaved but is not concatenation composable the way CESR is. |
|
Yes, I meant concatenation composability (CESR's). But now I got my question answered: Interleaved CESR doesn't magically grant concatenation composability to the guest hash map serialization. |
|
Yes. CBOR is binary only, it has no text domain representation so there is no possibility for it to be concatenation composable in both the text and binary domains. Likewise, JSON is text only and has no binary domain representation so there is also no possibility for it to be concatenation composable in both the text and binary domains. In a weak sense, some standards use JSON as the text domain, and CBOR as the binary domain to give a weak form of dual representation of full hash maps. CESR is a more elegant solution since its dual representation is at the individual primitive level not merely at the full hash map level. No more CBOR-JSON wars. |
|
If only they started seeing the beauty of it ;). Thx again, Sam, I am going through the white paper and I add some explanatory stuff to the glossary, concept.md (WOT-terms repo) and good old Q&A. |
|
In the end, the beauty will only be recognized after the fact of adoption. Once we have production libraries in the open, where people don’t have to really understand it to use it, then will people see how elegant it is. We need enough early adopters to at least prime the pump of adoption but we are not going to get the standards people or the big enterprises to adopt it at first. It will be after the little guys who don’t understand it but use it because its free and open and has features that look interesting, even if they don’t understand how it works under the hood, who will start the adoption growth. |
|
Non CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without pre-padding etc all the stuff CESR does to ensure aligns on 24 bit boundaries so CESR never uses the '=' pad character. But naive Base64 will pad if the length is not 14 bit aligned.
… On 30 Sep 2022, at 07:15 , Henk van Cann ***@***.***> wrote:
Another question: how would you define 'naive conversion'
This is my take: https://github.com/trustoverip/acdc/wiki/naive-conversion <https://github.com/trustoverip/acdc/wiki/naive-conversion>
—
Reply to this email directly, view it on GitHub <#34 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAETEPLHLITCNSUY2IQN3JLWA3RWVANCNFSM6AAAAAAQZWWGD4>.
You are receiving this because you commented.
|
|
Thx, copied to the glossary
|
|
24 bit aligned
…Sent from my iPad
On Oct 11, 2022, at 05:33, Henk van Cann ***@***.***> wrote:
Thx, copied to the glossary
Non CESR Base64 conversion. How people are used to using the Base64 encode and decode. Without pre-padding etc all the stuff CESR does to ensure aligns on 24 bit boundaries so CESR never uses the '=' pad character. But naive Base64 will pad if the length is not 14 bit aligned.
…
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
|
Yes, had this correct in place already in the Glossary item itself.
|
|
solved long time ago |
In commit fbc5bff
Under "conversions" last sentence:
"Likewise, this means that the length of any primitive in the T domain MUST be an integer multiple of 4 Base64 characters with a minimum length of four Base64 characters."
Is this correct? It doesn't make sense to me.
The text was updated successfully, but these errors were encountered: