On 4/3/15, 11:26 AM, "Martin Thomson" <[email protected]> wrote:
>I share Matt's reservations about the delimiting here. That part is >fundamentally broken. As do I. json-text-sequences (RFC 7464) was designed for this sort of thing, as Justin Richer mentioned. You could at least take the idea from there of using an ASCII RS as the separator, since it is not valid JSON. >I don't share his concerns about the canonicalization. That denies >PHB's basic thesis, which I agree with. If you have a transport that >is 8-bit clean, you can trivially preserve the JSON, as serialized and >you have exactly as many issues as JOSE has already. It would have to be both 8-bit clean, tolerate newlines, and if the payload isn't detached, you're severely limited in what could be sent. Limited to the point where I'm worried the approach would work terribly well in practice. Do we have one of these transports in mind, by the way? >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. >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). >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. >I don't see a significant gain in moving to COSE, unless you have a >lot more base64 to remove from the protected header. But if you are >shipping a lot of bytes in the header, I'd suggest that you might be >past the point where you should be concerning yourself with saving >space. I only see a gain in moving to COSE if you're going to use it throughout. For non-clean transports like http: URLs, you can always base64 at the end, and save some processing time and space. -- Joe Hildebrand _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
