In the table below, red is in the WG decision column indicates that the Working Group didn't agree with the comment, green indicates that a it agreed with it, and yellow reflects an in-between situation.
In the "Commentor reply" column, red indicates the commenter objected to the WG resolution, green indicates approval, and yellow means the commenter didn't respond to the request for feedback.
|Commentor||Comment||Working Group decision||Commentor reply|
|LC-2543 <a href='mailto:email@example.com'>MURATA Makoto </a> (archived comment)||
||The WG agrees with the interpretation that PRFAlgorithmIdentifierType prohibits Parameters elements.
The WG also agreed and updated the schema and specification to add type="anyURI" to AlgorithmIdentifierType for the Algorithm attribute, resulting in the following updated definition:
<element name="Parameters" minOccurs="0"/>
<attribute name="Algorithm" type="anyURI"/>
|LC-2544 <a href='mailto:firstname.lastname@example.org'>MURATA Makoto </a> (archived comment)||
||The working group decided to not make any change here as xenc-schema-11.xsd does not require any definitions from xmldsig-11-schema.xsd. All that is required is ds:DigestMethod from xmldsigschmema.xsd; so the current inclusion is correct and does not include unnecessary material.
Thus the schema import is correct as is the normative reference to XML SIgnature 1.1 (e.g. to pick up normative changes that are not necessarily reflected by schema changes)
The file gh-example.xml in generic-hybrid-ciphers was corrected; the associated specification was already correct.
|LC-2387 <a href='mailto:email@example.com'>Taki Kamiya </a> on behalf of EXI Working Group (archived comment)||
||"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.
|LC-2420 <a href='mailto:firstname.lastname@example.org'>Thomas Roessler </a> (archived comment)||
||Slash removed, correcting error, see http://lists.w3.org/Archives/Public/public-xmlsec/2010Aug/0073.html||yes|
|LC-2541 <a href='mailto:email@example.com'>MURATA Makoto </a> (archived comment)||
||Updated XML Encryption 1.1 to change "[XMLENC-CORE1]" to "(XMLENC-CORE1, this document)" in the media type section of XML Encryption 1.1 to avoid generating normative self reference.
There is now no reference to the document itself as a normative reference.
|LC-2542 <a href='mailto:firstname.lastname@example.org'>MURATA Makoto </a> (archived comment)||
||changed the base64 note in the algorithms section (section 5) from
*note: Note that the same URI is used to identify base64 both in "encoding" context (e.g. when needed within a CipherValue element) as well as in "transform" context (when identifying a base64 transform)
*note: The same URI is used to identify base64 both in "encoding" context (e.g. when used with the Encoding attribute of an EncryptedKey element, see section 3.1 The EncryptedType Element<file:///Materials/Builds/xmlsec2/Drafts/xmlenc-core-11/Overview.src.html#sec-EncryptedType>) as well as in "transform" context (when identifying a base64 transform for a CipherReference, see section 3.3.1 The CipherReference Element<file:///Materials/Builds/xmlsec2/Drafts/xmlenc-core-11/Overview.src.html#sec-CipherReference>).
For visibility I also added the following to the end of section 3.1:
Encoding is an optional (advisory) attribute which describes the transfer encoding of the data that has been encrypted.
(the previous MimeType paragraph outlines its use in conjunction with MimeType and gives base64 as an example)
|LC-2386 <a href='mailto:email@example.com'>Taki Kamiya </a> on behalf of EXI Working Group (archived comment)||
||Handling an EXI stream as an octet-stream of media type application/exi is perfectly fine. In that case, one wouldn't want to use the EXI type parameter, and would not expect EXI-specific handling of the encryptor or decryptor to apply.||yes|