RE: [dss] base64

["Edward Shallow" <ed.shallow@rogers.com>]

A good SOAP Library should not deserialize elements of type="string"
(MimeType text/xml containing XML data) into their corresponding
language-dependent nested objects (Java) or hashes (Perl), but some do
commit this error. That is to say, the SOAP layer in some toolkits explodes
the XML content into the nested structure deserialized for the service
implementor. This may ultimately go away. Perhaps there is a better more
neutral mechanism.

The EPM had to define its XMLDSIG elements as base64Binary for this reason.
Encoding conflicts is another gotcha. Don't know if ID conflicts is a
problem, we don't have that circumstance. 

Ed    

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: October 7, 2003 2:36 PM
To: Tim Moses; Rich Salz
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] base64

At 09:14 AM 10/7/2003 -0400, Tim Moses wrote:

>Trevor - Personally, I was surprised to see the <Document> element 
>containing Base64-encoded.  I don't believe there is a need for this.  
>I think the requester should have a direct, integrity-protected, 
>connection to the signature server.  There should be no opportunity for 
>any hanky-panky in the link.  Obviously, Base64-encoding is not an
integrity mechanism.

Makes sense.  I'll change <Document> to contain a choice of:
  - <BinaryData> which is base64'd data and a MIME type
  - <XMLData> which is arbitrary XML

Rich, your schema mentions transferring XML both in the clear and
base64-encoded, and says something about "encoding" - are there character
encoding issues that would necessitate base64'd XML, where the InputDocument
might be in a different encoding than the protocol message?

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