- From: Joseph Reagle <reagle@w3.org>
- Date: Wed, 24 Oct 2001 15:34:43 -0400
- To: edsimon@xmlsec.com, xml-encryption@w3.org
[ Resulting document
http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
$Revision: 1.67 $ on $Date: 2001/10/24 19:32:42 $ GMT by $Author: reagle $
]
On Friday 19 October 2001 16:14, edsimon@xmlsec.com wrote:
> Section 3.2.1: The CipherReference Element
>
> There's a sentence fragment "Transforms is in the xenc namespace because
> the sequence of transforms" which is probably a cut-and-paste error
> because the xenc namespace reasoning is described in the second paragraph
> up.
Fixed.
> Section 3.4.1: The EncryptedKey Element
>
> Should the CarriedKeyName attribute really be a child element?
>
> Given that it may be often useful to exactly match the content of a
> ds:KeyName element ("where whitespace is significant" to quote the XML
> Signature spec), should we really use a corresponding attribute given
> that XML processors must normalize white space in attributes (see "3.3.3
> Attribute-Value Normalization " of "http://www.w3.org/TR/REC-xml")?
>
> Correct me if I'm missing something.
Good point. I'm amendable to the change but I'm curious as to others'
thoughts.
> Section 3.5: The ReferenceList Element
>
> In the schema definition, why not use <choice> rather than <sequence>?
> This will allow apps to order the references in the manner that best
> suits them and it makes no difference to the XML Encryption spec.
There's no reason not to. Again, I suppose it's what works best for
implementations: do they prefer to process the key and data references as a
group, or order as approriate...
--
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 Wednesday, 24 October 2001 15:34:58 UTC