This document:Public document·View comments·Disposition of Comments·
Nearby:Efficient Extensible Interchange Working Group Other specs in this tool
Quick access to LC-3041 LC-3042 LC-3043 LC-3044 LC-3045 LC-3065 LC-3066 LC-3067 LC-3068 LC-3069 LC-3070 LC-3071 LC-3072 LC-3073 LC-3074 LC-3075 LC-3076 LC-3077 LC-3078
Previous: LC-3041 Next: LC-3069
4. Section 3: As mentioned above, making the EXI options document and the EXI schemaId mandatory in every canonical EXI document is at odds with the efficiency objectives of EXI. In many or perhaps even most use cases that require efficiency, these can be (and are) provided out of band or specified by a higher-level protocol. As such, including them in every canonical EXI message introduces unnecessary overhead and provides no value since all cooperating nodes already have this information. Furthermore, forcing the inclusion of a schemaId in every message does not actually solve the problem of ensuring the sender and receiver use the same schemas. The EXI schemaId is not guaranteed to be unique and would be easy for a sender and receiver to end up using the same schemaId for two different versions of the same schema or even two completely different schemas (breaking any signature that depends on schemaId). There are more reliable ways to ensure senders and receivers are using the same schemas for encoding/decoding EXI documents. This problem is not unique to EXI canonicalization and the EXI canonicalization specification should not force a specific, sub-optimal solution on EXI users. As with EXI, users should be allowed to use the EXI options document and schemaId to address this issue, but they should not be forced to do so if they have a better, more efficient solution that is already working.