For Base64Data the MIME type alreay indicates the content type. However, I
do see use cases where the data does not need to be converted to Base64.
Thus I suggest:
<XMLData>
<TextData>
<Base64Data>
Nick
> -----Original Message-----
> From: Trevor Perrin [mailto:]
> Sent: 08 October 2003 01:48
> To: Rich Salz
> Cc: Tim Moses;
> Subject: RE: [dss] base64
>
>
> At 08:27 PM 10/7/2003 -0400, Rich Salz wrote:
>
> >Using MIME types is in line with where SOAP 1.2 is headed, so I
> like that.
>
> Just to be clear - are you voting for one of these choices? -
>
> 1) XML can be plain or base64; everything else is base64 -
> <XMLData>
> <Base64XMLData>
> <Base64BinaryData> (with a MimeType attribute)
>
> 2) The way Rich's schema initially had it - like above, but also with the
> option for un-encoded non-XML text:
> <XMLData>
> <Base64XMLData>
> <Base64BinaryData> (with a MimeType attribute)
> <TextData> (" " ")
>
> 3) The way it currently is: everything is base64'd
> <Data> (with a MimeType attribute)
>
>
> >To do an XML DSIG you need to know if the input is XML or a bytestream,
> >which you can pretty much figure out from the MIME type (there
> are a bunch
> >of formats, but if you see the letters 'xml' you can make a safe
> guess :).
>
> And there's another complication - From XML-DSIG 4.3.3.2:
>
> "Unless the URI-Reference is a 'same-document' reference as defined in
> [URI, Section 4.2], the result of dereferencing the URI-Reference MUST be
> an octet stream. In particular, an XML document identified by URI is not
> parsed by the signature application unless the URI is a same-document
> reference or unless a transform that requires XML parsing is
> applied. (See
> Transforms (section 4.3.3.1).)"
>
> For each <InputDocument>, we're sending a 'RefURI' attribute which tells
> the server how to refer to it, so the server can figure out which
> to treat
> it as (i.e whether it's a same-document reference or not). I don't think
> we need to do anything else to support this distinction, but I'm not sure.
>
> Trevor
>
>
>
> To unsubscribe from this mailing list (and be removed from the
> roster of the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor
> kgroup.php.
>
>
>
