This document:Public document·View comments·Disposition of Comments·
Nearby:Efficient Extensible Interchange Working Group Other specs in this tool
Quick access to LC-2103 LC-2104 LC-2105 LC-2106 LC-2107 LC-2108 LC-2109 LC-2110 LC-2130 LC-2132 LC-2133 LC-2164 LC-2165 LC-2166 LC-2167 LC-2168 LC-2169 LC-2170 LC-2171 LC-2172 LC-2173 LC-2174 LC-2175 LC-2176 LC-2177 LC-2178 LC-2179 LC-2180 LC-2181 LC-2182 LC-2183 LC-2184 LC-2185 LC-2186 LC-2187 LC-2188 LC-2189 LC-2190 LC-2191 LC-2192 LC-2193 LC-2194 LC-2196 LC-2197 LC-2198 LC-2227 LC-2248
Previous: LC-2190 Next: LC-2133
we would like you to take into consideration to introduce the boolean field "EXIBodyEncrypted" to the definition of the EXI header. This field could indicate that the EXI body of an EXI stream is encrypted with the implication that a standard EXI parser should reject such data with a corresponding notification code. The encryption-parameters itself could then be optionally described in the "user defined" section of the EXI header in conformance to the W3C recommendation "XML Signature and Encryption". In this way, it could be up to the single application itself to handle encryption of the EXI body after EXI encoding respectively decryption before EXI decoding and to set the proposed EXIBodyEncrypted-Flag appropriate. By this we believe that maximum efficiency and flexibility in encryption could be achieved, while keeping EXI conformity at the same time. We have notice that this point has been largely discussed, but again, in terms of efficiency it would open up the chance to follow the rule "first compression, then encryption" with minimum overhead and without the demand of another MIME-type-definition in an maybe otherwise necessary, additional envelope to cope with alternative, efficient XML encryption.