Edit comment LC-2387 for XML Security Working Group

Previous: LC-2420 Next: LC-2543

Comment LC-2387: Comment Shortname:; Commenter: Taki Kamiya <tkamiya@us.fujitsu.com> on behalf of EXI Working Group; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
Section 4.2 "Well-known Type parameter values" defines a reserved value for EXI. It also states that: "Encryptors and Decryptors should handle unknown or empty Type attribute values as a signal that the cleartext is to be handled as an opaque octet-stream, whose specific processing is up to the invoking application. In this case, the
Type, MimeType and Encoding parameters should be treated as opaque data whose appropriate processing is up to the application."

It is not clear to me what is expected of a processor that does not implement EXI have encountered Type value of "http://www.w3.org/2009/xmlenc11#EXI". Since the value "http://www.w3.org/2009/xmlenc11#EXI" is well-known, the quoted paragraph does not seem to apply to the value.

When I think that the encryption of EXI stream as a whole is covered by section 2.1.4, I start to wonder what the mention of EXI in section 4.2 would add beyond that in terms of function. It appears as though the two mechanisms are functionally same with regards to how they relate to EXI, since both provide ways to encrypt and contain EXI streams within XML.; Related issues: (space separated ids); WG Notes: The XML Security WG agreed to the proposed resolution on the comment at the teleconference held on 10 August, see http://www.w3.org/2010/08/10-xmlsec-minutes.html#item04 .; Resolution: "Unknown" means "unknown to the processor"; if this language was referring to a value not specified in this document, then we'd likely have chosen other language. Please let us know whether you think this requires further clarification. The mention of EXI in section 4.2 is intended to enable XML Encryption to be transparent as far as EXI is concerned. For example, an SVG image could be encoded with MimeType="application/svg+xml", and Type="EXI"; the encryption engine could return a parsed DOM tree (or whatever else makes sense) immediately. The signaling and intended processing of the two models is therefore not the same.; (Please make sure the resolution is adapted for public consumption)