- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Mon, 11 Mar 2002 16:23:34 +0900
- To: reagle@w3.org
- Cc: merlin <merlin@baltimore.ie>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
>> I basically agree on this, but I think we should state such a restriction >> on X in Section 2.1.2. I tried to make some tweak to Section 2, which is >> attached below. Could you check if I misunderstand anything? >> (See attached file: 20020308.html) > >Looks good, now in the editors' draft [1]. My two questions: > >1. Do we even need to talk about Z? According to decryptIncludedNodes, Z is >always a nodeset, but it's not even mentioned in the "if XML" in step 2, >and it is mention in the "if octets" in step 3. Sorry, the description of Z, i.e., "Z is a node-set obtained by the following steps:", is wrong. It would be something like "Z is a node-set or octet stream obtained by the following steps:". >2. I'm a little confused by this wording, "If an xenc:EncryptedData element >node being decrypted is the first node in X, the value of its Type >attribute MUST NOT be xenc;Content. Otherwise, the value MUST be >xenc;Element or xenc;Content." > >Can we be confident that we have the ordering of the nodes in X? XPath defines the "document order" of nodes and the order is what I intended. >Perhaps we should give a little motivation (to help me and eventually >others understand). Perhaps, > >If an xenc:EncryptedData element node being decrypted is the first node in >X, the value of its Type attribute MUST NOT be xenc;Content. This prevents >an ill-formed XML document with element content appearing at the start of >the document. If the xenc:EncryptedData is not the first node in X, the >value MUST be xenc;Element or xenc;Content. This prevents binary data >from appearing out of place in an XML document. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Monday, 11 March 2002 02:24:18 UTC