W3C home > Mailing lists > Public > www-xkms@w3.org > December 2001

[Fwd: SOAP message style]

From: Stephen Farrell <stephen.farrell@baltimore.ie>
Date: Fri, 21 Dec 2001 11:39:49 +0000
Message-ID: <3C231F85.DA6C1B3E@baltimore.ie>
To: www-xkms@w3.org

Some (important!) messages that were sent to the -ws list.
Please us this (www-xkms@w3.org) from now on - new subscribers
won't see your mail otherwise.

Regards,
Stephen.



-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com
Return-Path: <www-xkms-ws-request@w3.org>
Received: from emeairlsw1.baltimore.com (emeairlsw1.ie.baltimore.com [10.153.25.53])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id AAA23988;
	Thu, 20 Dec 2001 00:30:00 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T57edffd17a0a9919350ad@emeairlsw1.baltimore.com>;
 Thu, 20 Dec 2001 00:12:00 +0000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ocasey.baltimore.com (8.9.3/8.9.3) with ESMTP id AAA02053;
	Thu, 20 Dec 2001 00:16:01 GMT
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id TAA19398;
	Wed, 19 Dec 2001 19:15:56 -0500 (EST)
Resent-Date: Wed, 19 Dec 2001 19:15:56 -0500 (EST)
Resent-Message-Id: <200112200015.TAA19398@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA19377
	for <www-xkms-ws@www19.w3.org>; Wed, 19 Dec 2001 19:15:52 -0500 (EST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA29952
	for <www-xkms-ws@w3.org>; Wed, 19 Dec 2001 19:15:53 -0500
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 19 Dec 2001 16:15:22 -0800
Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Dec 2001 16:15:21 -0800
Received: from red-msg-01.redmond.corp.microsoft.com ([157.54.12.68]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Wed, 19 Dec 2001 16:15:21 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="------------InterScan_NT_MIME_Boundary"
Date: Wed, 19 Dec 2001 16:15:21 -0800
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCE5E@red-msg-01.redmond.corp.microsoft.com>
Thread-Topic: SOAP message style
thread-index: AcGI62e3RjghON5pQGuYiFxMfpuR9Q==
From: "Blair Dillaway" <blaird@microsoft.com>
To: <www-xkms-ws@w3.org>
X-OriginalArrivalTime: 20 Dec 2001 00:15:21.0307 (UTC) FILETIME=[6993CAB0:01C188EB]
Subject: SOAP message style
Resent-From: www-xkms-ws@w3.org
X-Mailing-List: <www-xkms-ws@w3.org> archive/latest/238
X-Loop: www-xkms-ws@w3.org
Sender: www-xkms-ws-request@w3.org
Resent-Sender: www-xkms-ws-request@w3.org
Precedence: list
List-Id: <www-xkms-ws.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-xkms-ws-request@w3.org?subject=unsubscribe>
X-Mozilla-Status2: 00000000

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C188EB.699C63AE"

------_=_NextPart_001_01C188EB.699C63AE
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

The issue was raised as to which style(s) of SOAP messages should be
supported in defining the interface between XKMS complaint clients and
services. SOAP supports several styles with the two most common being
Document-Literal and RPC-SOAPEncoding. The XKMS 1.1 Note used the
former. As the WG develops its specification, we should make an explicit
decision as to which styles must and/or should be supported.

For those who aren't familiar with the two styles, I have provided
simple examples of 'Locate' message requests at the end. Its obvious
that the two message structures are quite a bit different. In
particular, The Document-Literal message looks like a typical XML
document structure with nested child elements. In comparison, the
RPC-SOAPEncoding message is:
	1) Quite a bit larger, due to additional namespaces and
extensive use of references
	2) Includes more information about the 'type' of information
being sent, such as the explicit nil and array type attributes.
	3) Uses a more complex style based on isolating multi-reference
values in independent elements which are then referenced by their
accessors. (see SOAP 1.1, Section 5, for the full discussion of 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.

The second point above is really the most important. SOAP encoding is
"based on a simple type system that is a generalization of the common
features found in type system in programming languages, databases, and
semi-structured data". Hence, the RPC-SOAPEncoding style lets the
originator include more information as to their view of data being sent.
This may benefit the recipient in providing hints (beyond XML schema) as
to how best to deserialize the message back into a "value graph"
representing the information in the message.=20

>From the standpoint of the XKMS WG, the issues boil down to:
	- Is there a benefit to one style over the other? The Doc-Lit
style is somewhat easier to encode/decode but the RPC-SOAPEnc style has
richer semantics. Unless we believe there is value in promoting 'type
model' fidelity between clients and services, it may be easiest to stay
with the Doc-Lit style.
	- If both styles are supported, then service developers will
need to pick a style to use. This will be reflected in their WSDL
contact If they want to support both styles, then they'll need separate
URLs for each with different WSDLs. Obviously, this would increase
complexity.
	- Allowing both styles creates a dilemma for client
implementers. Do they only support one style, in which case they can
only talk with some services, or do they support both which entails a
significant increase in complexity?
	- 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). The biggest impact is probably on
signature generation. With Doc-Lit encoding one could sign a reference
to the Locate element. With RPC-SOAPEnc you'd want to either sign a
reference to the Body element or an xPath selecting all the children of
Body. The latter seems preferable to avoid inclusion of namespaces
associated with the Body that aren't used in the contents.

SAMPLE Document-Literal Style SOAP Message

<?xml version=3D"1.0" encoding=3D"utf-8"?>
<soap:Envelope xmlns:soap=3D"http://schemas.xmlsoap.org/soap/envelope/"=20
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"=20
xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema">
   <soap:Body>=20
      <Locate xmlns=3D"http://www.xkms.org/schema/xkms-2001-01-20">
         <Query>
            <KeyInfo xmlns=3D"http://www.w3.org/2000/09/xmldsig#">
               <KeyName>key</KeyName>
            </KeyInfo>
         </Query>
         <Respond>
            <string>KeyName</string>
            <string>KeyValue</string>
         </Respond>
       </Locate>
   </soap:Body>
</soap:Envelope>

SAMPLE RPC-SOAPEncoding Style SOAP Message

<?xml version=3D"1.0" encoding=3D"utf-8"?>
<SOAP-ENV:Envelope =
xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema"=20
xmlns:SOAP-ENC=3D"http://schemas.xmlsoap.org/soap/encoding/"=20
xmlns:SOAP-ENV=3D"http://schemas.xmlsoap.org/soap/envelope/"=20
SOAP-ENV:encodingStyle=3D"http://schemas.xmlsoap.org/soap/encoding/"
xmlns:a2=3D"http://schemas.microsoft.com/clr/nsassem/XKMSTypes/XKMSTypes"=
=20
xmlns:i2=3D"http://schemas.microsoft.com/clr/nsassem/XKMSKeyService.KeySe=
r
vice/Key">
   <SOAP-ENV:Body>
      <i2:Locate id=3D"ref-1">
         <TransactionID xsi:null=3D"1"/>
         <Query href=3D"#ref-4"/>
         <Respond href=3D"#ref-5"/>
      </i2:Locate>
      <a2:LocateQuery id=3D"ref-4">
         <KeyInfo href=3D"#ref-6"/>
      </a2:LocateQuery>
      <SOAP-ENC:Array id=3D"ref-5" SOAP-ENC:arrayType=3D"xsd:string[2]">
         <item id=3D"ref-7">KeyName</item>
         <item id=3D"ref-8">KeyValue</item>
      </SOAP-ENC:Array>
      <a2:KeyInfo id=3D"ref-6">
         <Item href=3D"#ref-9"/>
         <Id xsi:null=3D"1"/>
      </a2:KeyInfo>
      <SOAP-ENC:Array id=3D"ref-9" =
SOAP-ENC:arrayType=3D"xsd:ur-type[1]">
         <item href=3D"#ref-10"/>
      </SOAP-ENC:Array>
      <a2:KeyName id=3D"ref-10">
         <Text id=3D"ref-11">mykey</Text>
      </a2:KeyName>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


------_=_NextPart_001_01C188EB.699C63AE
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.5770.4">
<TITLE>SOAP message style</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">The issue was =
raised as to which style(s) of SOAP messages should be supported in =
defining the interface between XKMS complaint clients and services. SOAP =
supports several styles with the two most common being Document-Literal =
and RPC-SOAPEncoding. The XKMS 1.1 Note used the former. As the WG =
develops its specification, we should make an explicit decision as to =
which styles must and/or should be supported.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">For those who =
aren&#8217;t familiar with the two styles, I have provided simple =
examples of &#8216;Locate&#8217; message requests at the end. Its =
obvious that the two message structures are quite a bit different. In =
particular, The Document-Literal message looks like a typical XML =
document structure with nested child elements. In comparison, the =
RPC-SOAPEncoding message is:</FONT></SPAN></P>
<UL>
<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">1) Quite a bit =
larger, due to additional namespaces and extensive use of =
references</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">2) Includes more =
information about the &#8216;type&#8217; of information being sent, such =
as the explicit nil and array type attributes.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">3) Uses a more =
complex style based on isolating multi-reference values in independent =
elements which are then referenced by their accessors. (see SOAP 1.1, =
Section 5, for the full discussion of 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.</FONT></SPAN></P>
</UL>
<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">The second point =
above is really the most important. SOAP encoding is &#8220;based on a =
simple type system that is a generalization of the common features found =
in type system in programming languages, databases, and semi-structured =
data&#8221;. Hence, the RPC-SOAPEncoding style lets the originator =
include more information as to their view of data being sent. This may =
benefit the recipient in providing hints (beyond XML schema) as to how =
best to deserialize the message back into a &#8220;value graph&#8221; =
representing the information in the message. </FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">From the =
standpoint of the XKMS WG, the issues boil down to:</FONT></SPAN>
<UL>
<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- Is there a =
benefit to one style over the other? The Doc-Lit style is somewhat =
easier to encode/decode but the RPC-SOAPEnc style has richer semantics. =
Unless we believe there is value in promoting &#8216;type model&#8217; =
fidelity between clients and services, it may be easiest to stay with =
the Doc-Lit style.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- If both styles =
are supported, then service developers will need to pick a style to use. =
This will be reflected in their WSDL contact If they want to support =
both styles, then they&#8217;ll need separate URLs for each with =
different WSDLs. Obviously, this would increase =
complexity.</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- Allowing both =
styles creates a dilemma for client implementers. Do they only support =
one style, in which case they can only talk with some services, or do =
they support both which entails a significant increase in =
complexity?</FONT></SPAN></P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">- If we add a =
simple integrity and confidentiality mechanism based on XML Signature =
and XML Encryption, we&#8217;d need to be cognizant of the possible =
message structure(s). The biggest impact is probably on signature =
generation. With Doc-Lit encoding one could sign a reference to the =
Locate element. With RPC-SOAPEnc you&#8217;d want to either sign a =
reference to the Body element or an xPath selecting all the children of =
Body. The latter seems preferable to avoid inclusion of namespaces =
associated with the Body that aren&#8217;t used in the =
contents.</FONT></SPAN></P>
</UL>
<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">SAMPLE =
Document-Literal Style SOAP Message</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&lt;?xml =
version=3D&quot;1.0&quot; =
encoding=3D&quot;utf-8&quot;?&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&lt;soap:Envelope =
xmlns:soap=3D&quot;<A =
HREF=3D"http://schemas.xmlsoap.org/soap/envelope/">http://schemas.xmlsoap=
.org/soap/envelope/</A>&quot; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:xsi=3D&quot;<A =
HREF=3D"http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001=
/XMLSchema-instance</A>&quot; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:xsd=3D&quot;<A =
HREF=3D"http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchem=
a</A>&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&lt;soap:Body&gt; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Locate =
xmlns=3D&quot;<A =
HREF=3D"http://www.xkms.org/schema/xkms-2001-01-20">http://www.xkms.org/s=
chema/xkms-2001-01-20</A>&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;Query&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; &lt;KeyInfo xmlns=3D&quot;<A =
HREF=3D"http://www.w3.org/2000/09/xmldsig">http://www.w3.org/2000/09/xmld=
sig</A>#&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;KeyName&gt;key&lt;/KeyName&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; &lt;/KeyInfo&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/Query&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;Respond&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; &lt;string&gt;KeyName&lt;/string&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; &lt;string&gt;KeyValue&lt;/string&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/Respond&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/Locate&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&lt;/soap:Body&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&lt;/soap:Envelope&gt;</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">SAMPLE =
RPC-SOAPEncoding Style SOAP Message</FONT></SPAN>
</P>

<P><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&lt;?xml =
version=3D&quot;1.0&quot; =
encoding=3D&quot;utf-8&quot;?&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&lt;SOAP-ENV:Envelope xmlns:xsi=3D&quot;<A =
HREF=3D"http://www.w3.org/2001/XMLSchema-instance">http://www.w3.org/2001=
/XMLSchema-instance</A>&quot; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:xsd=3D&quot;<A =
HREF=3D"http://www.w3.org/2001/XMLSchema">http://www.w3.org/2001/XMLSchem=
a</A>&quot; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:SOAP-ENC=3D&quot;<A =
HREF=3D"http://schemas.xmlsoap.org/soap/encoding/">http://schemas.xmlsoap=
.org/soap/encoding/</A>&quot; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:SOAP-ENV=3D&quot;<A =
HREF=3D"http://schemas.xmlsoap.org/soap/envelope/">http://schemas.xmlsoap=
.org/soap/envelope/</A>&quot; </FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">SOAP-ENV:encodingStyle=3D&#8221;<A =
HREF=3D"http://schemas.xmlsoap.org/soap/encoding/">http://schemas.xmlsoap=
.org/soap/encoding/</A>&#8221;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:a2=3D&quot;<A =
HREF=3D"http://schemas.microsoft.com/clr/nsassem/XKMSTypes/XKMSTypes">htt=
p://schemas.microsoft.com/clr/nsassem/XKMSTypes/XKMSTypes</A>&quot; =
</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">xmlns:i2=3D&quot;<A =
HREF=3D"http://schemas.microsoft.com/clr/nsassem/XKMSKeyService.KeyServic=
e/Key">http://schemas.microsoft.com/clr/nsassem/XKMSKeyService.KeyService=
/Key</A>&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&lt;SOAP-ENV:Body&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;i2:Locate =
id=3D&quot;ref-1&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;TransactionID xsi:null=3D&quot;1&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;Query href=3D&quot;#ref-4&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;Respond href=3D&quot;#ref-5&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/i2:Locate&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;a2:LocateQuery =
id=3D&quot;ref-4&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;KeyInfo href=3D&quot;#ref-6&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/a2:LocateQuery&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;SOAP-ENC:Array =
id=3D&quot;ref-5&quot; =
SOAP-ENC:arrayType=3D&quot;xsd:string[2]&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item =
id=3D&quot;ref-7&quot;&gt;KeyName&lt;/item&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item =
id=3D&quot;ref-8&quot;&gt;KeyValue&lt;/item&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/SOAP-ENC:Array&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;a2:KeyInfo =
id=3D&quot;ref-6&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Item =
href=3D&quot;#ref-9&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Id =
xsi:null=3D&quot;1&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/a2:KeyInfo&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;SOAP-ENC:Array =
id=3D&quot;ref-9&quot; =
SOAP-ENC:arrayType=3D&quot;xsd:ur-type[1]&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;item =
href=3D&quot;#ref-10&quot;/&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/SOAP-ENC:Array&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;a2:KeyName =
id=3D&quot;ref-10&quot;&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;Text =
id=3D&quot;ref-11&quot;&gt;mykey&lt;/Text&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&lt;/a2:KeyName&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; =
&lt;/SOAP-ENV:Body&gt;</FONT></SPAN>

<BR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">&lt;/SOAP-ENV:Envelope&gt;</FONT></SPAN>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C188EB.699C63AE--

--------------InterScan_NT_MIME_Boundary--


Return-Path: <www-xkms-ws-request@w3.org>
Received: from emeairlsw1.baltimore.com (emeairlsw1.ie.baltimore.com [10.153.25.53])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id BAA24612;
	Thu, 20 Dec 2001 01:17:03 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T57ee31877d0a9919350ad@emeairlsw1.baltimore.com>;
 Thu, 20 Dec 2001 01:06:18 +0000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ocasey.baltimore.com (8.9.3/8.9.3) with ESMTP id BAA03585;
	Thu, 20 Dec 2001 01:10:19 GMT
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA24826;
	Wed, 19 Dec 2001 20:10:13 -0500 (EST)
Resent-Date: Wed, 19 Dec 2001 20:10:13 -0500 (EST)
Resent-Message-Id: <200112200110.UAA24826@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA24758
	for <www-xkms-ws@www19.w3.org>; Wed, 19 Dec 2001 20:10:03 -0500 (EST)
Received: from zolera.com (IDENT:root@[63.142.188.177])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA03402
	for <www-xkms-ws@w3.org>; Wed, 19 Dec 2001 20:10:04 -0500
Received: from zolera.com (pool-141-154-58-4.bos.east.verizon.net [141.154.58.4])
	by zolera.com (8.11.0/8.11.0) with ESMTP id fBK1AwP29117;
	Wed, 19 Dec 2001 20:11:03 -0500
Message-ID: <3C213A84.4C7ADA23@zolera.com>
Date: Wed, 19 Dec 2001 20:10:28 -0500
From: Rich Salz <rsalz@zolera.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Blair Dillaway <blaird@microsoft.com>
CC: www-xkms-ws@w3.org
References: <AA19CFCE90F52E4B942B27D42349637902CDCE5E@red-msg-01.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=iso-8859-1
Subject: Re: SOAP message style
Resent-From: www-xkms-ws@w3.org
X-Mailing-List: <www-xkms-ws@w3.org> archive/latest/239
X-Loop: www-xkms-ws@w3.org
Sender: www-xkms-ws-request@w3.org
Resent-Sender: www-xkms-ws-request@w3.org
Precedence: list
List-Id: <www-xkms-ws.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-xkms-ws-request@w3.org?subject=unsubscribe>
X-MIME-Autoconverted: from 8bit to quoted-printable by ocasey.baltimore.com id BAA03585
X-MIME-Autoconverted: from quoted-printable to 8bit by bobcat.baltimore.ie id BAA24612
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by bobcat.baltimore.ie id LAA24866

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 =3D q =3D "foobar";              /* aliased */
    p =3D "foobar"; q =3D 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=3D'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 =91type=92 of information
>      being sent, such as the explicit nil and array type attributes.

There's a bit of a debate if "xsi:null=3D'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.=20
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=92d need to be
>      cognizant of the possible message structure(s). ...  With
>      RPC-SOAPEnc you=92d 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$

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


Return-Path: <www-xkms-ws-request@w3.org>
Received: from emeairlsw1.baltimore.com (emeairlsw1.ie.baltimore.com [10.153.25.53])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id BAA24810;
	Thu, 20 Dec 2001 01:32:48 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T57ee3fd53b0a9919350ad@emeairlsw1.baltimore.com>;
 Thu, 20 Dec 2001 01:21:55 +0000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ocasey.baltimore.com (8.9.3/8.9.3) with ESMTP id BAA03943;
	Thu, 20 Dec 2001 01:25:56 GMT
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id UAA25439;
	Wed, 19 Dec 2001 20:25:49 -0500 (EST)
Resent-Date: Wed, 19 Dec 2001 20:25:49 -0500 (EST)
Resent-Message-Id: <200112200125.UAA25439@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA25422
	for <www-xkms-ws@www19.w3.org>; Wed, 19 Dec 2001 20:25:45 -0500 (EST)
Received: from zolera.com (IDENT:root@[63.142.188.177])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA04604
	for <www-xkms-ws@w3.org>; Wed, 19 Dec 2001 20:25:46 -0500
Received: from zolera.com (pool-141-154-58-4.bos.east.verizon.net [141.154.58.4])
	by zolera.com (8.11.0/8.11.0) with ESMTP id fBK1QmP29158;
	Wed, 19 Dec 2001 20:26:53 -0500
Message-ID: <3C213E39.E2C10E41@zolera.com>
Date: Wed, 19 Dec 2001 20:26:17 -0500
From: Rich Salz <rsalz@zolera.com>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Blair Dillaway <blaird@microsoft.com>, www-xkms-ws@w3.org
References: <AA19CFCE90F52E4B942B27D42349637902CDCE5E@red-msg-01.redmond.corp.microsoft.com> <3C213A84.4C7ADA23@zolera.com>
Content-Type: text/plain; charset="us-ascii"
Subject: Re: SOAP message style
Resent-From: www-xkms-ws@w3.org
X-Mailing-List: <www-xkms-ws@w3.org> archive/latest/240
X-Loop: www-xkms-ws@w3.org
Sender: www-xkms-ws-request@w3.org
Resent-Sender: www-xkms-ws-request@w3.org
Precedence: list
List-Id: <www-xkms-ws.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-xkms-ws-request@w3.org?subject=unsubscribe>
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 7bit

Oops, I forgot the biggest reason:  RPCEncoding will be "optional" in
SOAP1.2.
	/r$

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


Return-Path: <www-xkms-ws-request@w3.org>
Received: from emeairlsw1.baltimore.com (emeairlsw1.ie.baltimore.com [10.153.25.53])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA09894;
	Thu, 20 Dec 2001 18:10:53 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T57f1cefb330a9919350ad@emeairlsw1.baltimore.com>;
 Thu, 20 Dec 2001 17:57:08 +0000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ocasey.baltimore.com (8.9.3/8.9.3) with ESMTP id SAA09398;
	Thu, 20 Dec 2001 18:01:10 GMT
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA05149;
	Thu, 20 Dec 2001 13:00:50 -0500 (EST)
Resent-Date: Thu, 20 Dec 2001 13:00:50 -0500 (EST)
Resent-Message-Id: <200112201800.NAA05149@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA05121
	for <www-xkms-ws@www19.w3.org>; Thu, 20 Dec 2001 13:00:39 -0500 (EST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10156
	for <www-xkms-ws@w3.org>; Thu, 20 Dec 2001 13:00:38 -0500
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 20 Dec 2001 10:00:08 -0800
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 20 Dec 2001 10:00:08 -0800
Received: from red-msg-01.redmond.corp.microsoft.com ([157.54.12.68]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966);
	 Thu, 20 Dec 2001 10:00:07 -0800
x-mimeole: Produced By Microsoft Exchange V6.0.5762.3
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 20 Dec 2001 10:00:07 -0800
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCE62@red-msg-01.redmond.corp.microsoft.com>
Thread-Topic: SOAP message style
thread-index: AcGI8xDnFWVNxZbHSaq4G2v74c9ldgAjE2vQ
From: "Blair Dillaway" <blaird@microsoft.com>
To: "Rich Salz" <rsalz@zolera.com>
Cc: <www-xkms-ws@w3.org>
X-OriginalArrivalTime: 20 Dec 2001 18:00:07.0440 (UTC) FILETIME=[28AE1100:01C18980]
X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id NAA05121
Subject: RE: SOAP message style
Resent-From: www-xkms-ws@w3.org
X-Mailing-List: <www-xkms-ws@w3.org> archive/latest/246
X-Loop: www-xkms-ws@w3.org
Sender: www-xkms-ws-request@w3.org
Resent-Sender: www-xkms-ws-request@w3.org
Precedence: list
List-Id: <www-xkms-ws.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-xkms-ws-request@w3.org?subject=unsubscribe>
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 8bit

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


Return-Path: <www-xkms-ws-request@w3.org>
Received: from emeairlsw1.baltimore.com (emeairlsw1.ie.baltimore.com [10.153.25.53])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA10363;
	Thu, 20 Dec 2001 18:38:48 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.5) with SMTP id <T57f1e50e330a9919350ad@emeairlsw1.baltimore.com>;
 Thu, 20 Dec 2001 18:21:15 +0000
Received: from www19.w3.org (www19.w3.org [18.29.0.19])
	by ocasey.baltimore.com (8.9.3/8.9.3) with ESMTP id SAA10507;
	Thu, 20 Dec 2001 18:25:17 GMT
Received: (from daemon@localhost)
	by www19.w3.org (8.9.0/8.9.0) id NAA08860;
	Thu, 20 Dec 2001 13:25:05 -0500 (EST)
Resent-Date: Thu, 20 Dec 2001 13:25:05 -0500 (EST)
Resent-Message-Id: <200112201825.NAA08860@www19.w3.org>
Received: from tux.w3.org (tux.w3.org [18.29.0.27])
	by www19.w3.org (8.9.0/8.9.0) with ESMTP id NAA08841
	for <www-xkms-ws@www19.w3.org>; Thu, 20 Dec 2001 13:24:57 -0500 (EST)
Received: from zolera.com (IDENT:root@[63.142.188.177])
	by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA13502
	for <www-xkms-ws@w3.org>; Thu, 20 Dec 2001 13:24:58 -0500
Received: from zolera.com (os390.zolera.com [10.0.1.9])
	by zolera.com (8.11.0/8.11.0) with ESMTP id fBKIPvP32749;
	Thu, 20 Dec 2001 13:26:02 -0500
Message-ID: <3C222D36.6070909@zolera.com>
Date: Thu, 20 Dec 2001 13:25:58 -0500
From: Rich Salz <rsalz@zolera.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: Blair Dillaway <blaird@microsoft.com>
CC: www-xkms-ws@w3.org
References: <AA19CFCE90F52E4B942B27D42349637902CDCE62@red-msg-01.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Subject: Re: SOAP message style
Resent-From: www-xkms-ws@w3.org
X-Mailing-List: <www-xkms-ws@w3.org> archive/latest/247
X-Loop: www-xkms-ws@w3.org
Sender: www-xkms-ws-request@w3.org
Resent-Sender: www-xkms-ws-request@w3.org
Precedence: list
List-Id: <www-xkms-ws.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Unsubscribe: <mailto:www-xkms-ws-request@w3.org?subject=unsubscribe>
X-Mozilla-Status2: 00000000
Content-Transfer-Encoding: 7bit

I didn't meant to imply that XKMS should profile/subset SOAP, merely 
that it wasn't a-priori going to result in bigger messages.

Since we agree on everything else, I'll just say: happy holidays.
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com
Received on Friday, 21 December 2001 06:39:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:14 GMT