W3C home > Mailing lists > Public > xml-encryption@w3.org > December 2001

Re: Minor comments for Last Call drafts of 20011018

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Sat, 15 Dec 2001 01:10:42 +0900
To: reagle@w3.org
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xenc <xml-encryption@w3.org>
Message-ID: <OFBA251C70.0172FA1B-ON49256B22.00556A30@LocalDomain>


> >> >Name and value of each entity [is this the formal definion of entity
> >> > from xml1.0 or something else -JR] that is effective for the XML
> >> > document causing X.
> >I think you mean parameter entity then?
> No, I mean not parameter entity but general entity, especially parsed
> entity.
>This still leaves me confused: the entity part and the "effective".

I'm being concerned about the use of entity references in a decrypted octet
stream.  If there is no information on bindings of entity name and value,
such an octet stream cannot be parsed.

>I expect the "parsing context" is a DOM specific term, is there
>something we can reference there?

I'm not sure the term is DOM-specific, but what the term intends was
affected by XML Fragment [1].

>The REQUIRED URI attribute value of the dcrpt:Except element MUST be a
>non-empty same-document URI reference [URI] (i.e., a number sign ('#')
>character followed by a fragment identifier) or XPointer expression (as
>profiled by [XML-Signature, Section])

To my understanding, "fragment identifier" can be renamed by "barename
XPointer".  If so, this text could be shortened as follows:

The REQUIRED URI attribute value of the dcrpt:Except element MUST be a
non-empty same-document URI reference [URI] (i.e., a number sign ('#')
character followed by an XPointer expression (as profiled by
[XML-Signature, Section]))

>and identify an enc:EncryptedData or enc:EncryptedKey element.

As I commented before, identifying the enc:EncryptedKey element does not
make sense because this transform does not anything for the element.

[1] http://www.w3.org/TR/xml-fragment

Tokyo Research Laboratory
IBM Research
Received on Friday, 14 December 2001 11:07:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:05 UTC