W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2002

Re: Minor comments for Last Call drafts of 20011018

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 3 Jan 2002 17:47:00 -0500
Message-Id: <200201032247.RAA04104@tux.w3.org>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xenc <xml-encryption@w3.org>
On Friday 14 December 2001 11:10, Takeshi Imamura wrote:
> > 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.

Ok, I think I understand this. We can let the text be and see if it prompts 
questions from others...

> >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].

Akin to Fragment Entity?

> >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.

Is this because you do not think the scenario is a compelling one, or it 
isn't merely specified that way yet? Would you be opposed to generalizing 
this to work for EncryptedKey or EncryptedData? (If we don't support this, 
what does it mean when someone adds an EncryptedKey to an XML instance that 
has already been signed?)


Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Thursday, 3 January 2002 17:47:03 UTC

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