On 6 April 2015 at 12:20, Joe Hildebrand (jhildebr) <[email protected]> wrote: > Do we have one of these transports in mind, by the way?
At least one: HTTP CoAP too, I guess. >>Saving the base64 encoding probably saves more bytes than moving to a >>completely >>new format. > > Probably, but I'm also worried the need to keep the original text around > after parsing to avoid the need for canonicalization. The extra memory > associated with that isn't a good fit for smaller devices, and is an > attractive nuisance for developer shortcuts. I get the nuisance factor, but shortcuts only lead to signature verification failure (including failure to verify). Given that jose has the exact same problem, I'm not super-concerned. >>If you really cared about saving bytes, you would drop the text labels >>and move to a schema-based binary encoding, or at least integer keys. > > ASN.1 is a schema-based binary encoding, so we already have one of those in > CMS. Integer keys help, but help a lot more in an encoding that uses 1 byte > for the oft-used small integers (as CBOR does). Don't make me get out the schema vs. encoding bat. PER allows types to consume <1 byte if you want to get aggressively parsimonious. >>A format without OIDs could be extremely compact. But part of the >>point of JOSE is to avoid that muck, and the gains aren't significant. > > Aren't OID's just a particular approach for minting unique byte strings? > Registries and tag: URNs, are all other approaches in this space. Indeed. The reason I mentioned them is that they are especially wasteful of bytes. _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
