Re: [dss] Action 05-04-18-04 text

[Trevor Perrin <trevp@trevp.net>]

Juan Carlos Cruellas wrote:
> 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

I'd like to suggest a variation.  First let me summarize the issue as I 
see it.

Initially we sent all documents in base64.  This could handle anything. 
  However, someone pointed out that since this was an XML protocol, we 
should be able to send XML documents without encoding.  We added that 
without much thought.  I don't think there was any rationale beyond 
making the protocol messages more readable.

Now, we're realizing that inheritance of ancestor context is a problem. 
  We would like to encode the XML documents and transmit them opaquely. 
  I think there are 2 issues:

1) What types of xml encoding should we support?
  - do we allow "inline xml"?  Isn't this asking for problems?
  - is it worth supporting escaped xml (for readability)?

2) How do we change the protocol?  Note that <dss:XMLData> only existed 
to provide a special-case for XML **since it didn't need encoding**. 
Everything else was shovelled into <dss:Base64Data>.  Now we're 
realizing that XML needs encoding too.  So there's no longer any reason 
for the distinction between XML and non-XML data.  It would be simpler 
to apply encodings uniformly to any input document.

So I suggest one of the following:

If we only want to support base64 encoding, we could eliminate the 
<XMLData> and <Base64Data> elements and put the base64'd content of any 
input directly under <Document>.  If we want to support multiple 
encodings, then we could do them as separate children of <Document> 
(e.g. <Base64Data>, <EscapedData>), or simply signal the encoding 
through an attribute (as is done below).


Trevor


> 
> "
> <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.
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in 
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>