W3C home > Mailing lists > Public > www-xenc-xmlp-tf@w3.org > February 2002

Re: XMLP/XMLE Use cases and processing models

From: <noah_mendelsohn@us.ibm.com>
Date: Fri, 8 Feb 2002 23:44:21 -0500
To: david.orchard@bea.com
Cc: www-xenc-xmlp-tf@w3.org, xml-dist-app@w3.org, "'xenc'" <xml-encryption@w3.org>
Message-ID: <OF5E497186.5977434A-ON85256B5B.00173F76@lotus.com>
David: 

First of all, I'm speaking for myself, not for either the Protocols WG or 
for IBM. 

Obviously, there are lots of ways you could apply SOAP to scenarios like 
encryption.  I think it's fair to say that most of us in the protocols WG 
have assumed that in an encryption scenario, some or all header or body 
entries will be removed from the message by an encrypting intermediary, 
replaced by one or more header entries carrying the encrypted payload.  By 
SOAP rules, such new header entries must be namespace qualified, and that 
qualified name must be associated with a specification (we don't specify 
in what form) describing the encryption that has been performed.  So, the 
qualified name of the encryption result header is almost surely different 
from those that were input to the encryption (or output from the 
decryption.)

As you're probably aware, the schema recommendation was made modular to 
deal with situations like this.  While you can write a schema document 
encompassing "strict" validation of the whole SOAP envelope, there is no 
need to do so.  Validation (technically assessment) can be initiated at 
any node in an infoset.  More likely, processors will use schemas for the 
SOAP envelope with "lax" validation for header and body entries.  That 
means that schemas will validate entries for which schema information 
happens to be around and others will be skipped.  So, it's quite 
reasonable that SOAP implementations will selectively validate headers 
that are actually to be processed at one intermediary or another.  It's 
not necessarily the case that there exists in any one place a schema that 
describes the entire envelope as it enters one particular node.  Lax 
validation is likely to be used to skip headers destined for other nodes.

More fundamentally, as has been observed by others, the SOAP 
recommendation never mandates schema validation at all.  It's quite 
reasonable to build SOAP systems in which at least some header or body 
entries are checked directly by the consuming application, using 
techniques unspecified.  For example if we have simple routing headers, 
it's unclear whether a generalized validation will be the right way to go. 
 Some routing software may just directly check for the required elements 
and attributes.  Altogether, schema validation involves some performance 
overhead.  In some implementations it will be the way to go;  in others, 
performance or other considerations may dictate other checking techniques.

I hope this helps clarify the ways that I personally would expect the SOAP 
and schema architectures to work in concert.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------
Received on Friday, 8 February 2002 23:58:40 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:21:54 GMT