Action 05-04-18-04 text

[Juan Carlos Cruellas <cruellas@ac.upc.edu>]

Ed,

Here it goes my first approach for the text where the new attribute at
<dss:XMLData> indicating the encoding mechanism, in section 2.4.2.
It would start inmediately after the first paragraph

"
<XMLData> [Optional]
This contains arbitrary XML content. It contains the encodingMethod 
attribute.
This attribute indicates the method used to encode such a content.
When this attribute is present, this attribute MUST have one of the
values enumerated below. If not present, its value MUST be considered to 
be "xml".

 "xml": this value indicates that the content of the element is inline xml.

 "escaped": this valuet indicates that the content of the element is an 
escaped string. The server MUST
  unescape it for obtaining xml data. If the result is a not well-formed 
XML data, then the
  server MUST report a RequestERROR.

 "base64": this value indicates that the content of the element is a 
base64 string obtained after
  base64 encoding of a XML data. The server MUST decode it for obtaining 
a XML tree. If the
  result is not a well-formed XML data, then it MUST report a RequestError.

<Base64Data> [Optional]
This contains a base64 encoding of data that are not XML.  The type of 
data is specified by its MimeType attribute.  The MimeType attribute is 
not required for XML signatures, but may be required when using DSS with 
other signature types.
The document hash for signing is created from the element content of 
<XMLData> (i.e. the <XMLData> tags are not included), or from the 
content of the <Base64Data> element after it is base64 decoded. "

Some remarks:
. we could try to identify a shorter name.
. I think that that now Base64Data element should only be used when the 
document
the requester wants to be signed is not XML....I have changed, in 
consequence,
the first sentence of its description. What do you think?
. I have not produced the corresponding xml schema modifications...

Regards

Juan Carlos.