> * In section 4.1 I have a question about what you are using for payload
> content encoding. Part of this might just be a question of how you plan to
> move from ASN.1 to CBOR at some point in the future. I think that it would
> necessitate doing new media-types in that event. You appear to be doing a
> CBOR bstr wrapping on the ASN.1 encoding payload. I don't believe that there
> is any reason for doing this. I would expect that the payload would be the
> ASN.1 w/o any ASN.1. It is highly possible that I am just mis-reading what
> the text says and this is what you say.
>
> <pvds>
>
> What I wanted to do, and did not express very well.
>
> Keep the ASN.1 structure of the payload; (re-using code)
>
> Use straight binary coding instead of the base64-encoded (30% payload
> reduction)
>
> Wrap the binary in a CBOR major type 2 h'xxx' notation. (compatibility with
> multipart)
>
> Not sure if this needs a new media type, the http content-coding and
> transfer-coding registries were not very helpful.
>
> </pvds>
>
> [JLS] I do not believe that the wrapping of content with the CBOR binary
> text wrapping is needed at this point. If that is needed for the multi-part
> wrapping, then it is the job of the multi-part wrapping to deal with this
> problem. Multipart needs to be able to say I have a multipart of <plain
> text, json> neither of which are CBOR objects. Therefor there is no reason
> for you to use a CBOR wrapper for this and not just use the binary value.
>
> <pvds>
> You are right of course, the CBOR wrapping is not needed outside the
> multipart media type.
> However, CBOR wrapping for all payloads, reduces the choices when decoding
> the payload; They all start the same.
> And it adds 2-3 bytes on many.
> </pvds>
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
