RE: SOAP message style

Rich,

Seems like we're in agreement that we should just stick with the Doc-Lit
style SOAP without some compelling reason to support the RPC-SOAPEnc
style, and there doesn't appear to be a compelling reason.   I agree
with most of your comments, but do have a different view on a couple of
key points as indicated below.

BTW, I'm leaving on vacation for 2 weeks and won't be able to continue
discussion of this topic until I return.

First, I disagree that XKMS can claim to support RPC-SOAPEncoding style
messages and also insist on a inlining style only.  The interface
between XKMS clients and servers is defined by the supported messages.
If we claim to support RPC-SOAPEnc style SOAP messages then its my
understanding we must handle messages using either inlining and
href/independent element.  The SOAP spec is clear that one can use the
href/independent element approach even for elements that aren't
multi-ref.  Since its legal to encode in either manner, the receiver
will need to accept both.  I did pick the included example to show
something of a worst case, but it was generated by a SOAP compliant
toolkit and is realistic.  I am against an approach that would try to
define a subset of the SOAP Section 5 encoding rules XKMS supports.

The fact that most SOAP toolkits support the RPC-SOAPEnc style is a big
reason this issue was raised.  But, I don't think this is an adequate
reason to support this style.  I do agree with your comments that one
has some control over the 'shape' of a SOAP message based on the object
model and toolkits being used.  But, XKMS isn't specifying object models
or toolkit behaviors.  Its only the messages and conformance to SOAP
(and ultimately XML-P) that matter.

I don't believe your statement in regards to the size of RPC-SOAPEnc
messages is correct.  You will be bringing in the SOAPEncoding
namespace, arraytype attibutes, etc. If you use this style I think you
will have larger messages.

I do agree the explicit null attributes and omitted elements have pretty
much the same semantic meaning.  My original statement was poorly
worded. The point I was trying to make was focused more on the use of
explicit array types and multi-reference elements.

Finally, to your point on XML Signatures.  I agree that use of the
RPC-SOAPEnc style does raise an issue as to how one includes an XML
Signature such as the ProofOfPossession(POP).  If you simply in-line, it
like we do in the Doc-Lit style messages, then the message would be in a
mixed SOAP style.  While legal SOAP, I think there are issues as to how
you capture this in a WSDL definition and the ease of implementation.
One option would be to move such signature elements to a SOAP header.   

That said, the more important issue with the XKMS use of XML Signature
is that it must be handled independently from the process of mapping
between some object model and the SOAP message contents.  So it really
doesn't matter if you're using a std toolkit to handle this operation
for the other XKMS data.  The reason is that the XML Signatures, like
POP, are computed over the XML being send inside the SOAP message.  For
the POP, we need the Prototype element (KeyBindingType) XML and XML
Signature SignedInfo.   Having an object model representation of the
Prototype element data does you no good.  Similarly, to verify the
signature you need the XML representation carried in the SOAP message.
You can't verify once you've passed the message through a deserializer
to map it into an object model.

Regards,
Blair

-----Original Message-----
From: Rich Salz [mailto:rsalz@zolera.com] 
Sent: Wednesday, December 19, 2001 5:10 PM
To: Blair Dillaway
Cc: www-xkms-ws@w3.org
Subject: Re: SOAP message style


I don't think it's quite that complicated.  Nothing in the XKMS data
formats requires shared references, so everything can be inlined.  (It
can also be href/id'd up the wazoo, as your example shows, but that's
the responsibility of the SOAP layer to handle.)

In my experience, the major factors that differentiate the two styles
are "limitations" enforced by RPCEncoding:
	1.  Can't use attributes for data (just meta-data)
	2.  Repeated elements (arrays) must be wrapped in a container.

If strings or complex data (structures and arrays) are aliased, and that
aliasing is significant, then you have to use href/id.  (For example, in
C:
    char *p, *q;
    p = q = "foobar";              /* aliased */
    p = "foobar"; q = strdup(p);   /* not aliased */
SOAP RPC Encoding allows you to make the two cases above explicit.)

So, for what it's worth, my encoding of Locate would be the *exact same*
as your doc-style Locate, except adding
   <TransactionID xsi:null='1'/>

>      1) Quite a bit larger, due to additional namespaces and extensive
>      use of references

Again, they COULD be, but no semantic info is lost if not, so they NEED
NOT be. SOAP message CAN be completely typed and self-describing, but
they need not be.

>      2) Includes more information about the 'type' of information
>      being sent, such as the explicit nil and array type attributes.

There's a bit of a debate if "xsi:null='1'" is the same as omit; ask
Andrew Layman up in your campus. :)

>      3) Uses a more complex style based on isolating multi-reference
>      values in independent elements which are then referenced by their
>      accessors.

See #1.

>      these rules). In some cases, an array element may appear as a
>      child of its accessor, but one should be prepared to handle the
>      independent element, accessor reference style shown.

Presumably any SOAP RPC toolkit could handle this, not leaving it to
XKMS to do.  From my experience, all SOAP toolkits do the full RPC stuff
(cf http://yahoogroups.com/soapbuilders for a mail list on soap
interop).

Now then, having said all that, I believe we should use document style. 
The killer reason is that you CANNOT encode an XMLDSIG document in SOAP
RPC, so using RPCEncoding would rule out being able to consider an
XMLDSIG element as part of an XKMS protocol exchange.

>      - If we add a simple integrity and confidentiality mechanism
>      based on XML Signature and XML Encryption, we'd need to be
>      cognizant of the possible message structure(s). ...  With
>      RPC-SOAPEnc you'd want to either sign a reference to the Body
>      element or an xPath selecting all the children of Body.

Why not just sign a refernece to the Locate, as with doc-lit?

	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

Received on Thursday, 20 December 2001 13:00:39 UTC