OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ebxml-msg] Issue73:http://schemas.xmlsoap.org/soap/envelopenamespace

Do we have a call tomorrow?  I can't find any coordinates.

If so, I would like to suggest we discuss this topic first -- which takes
precedence, the Schema or the Text.



-----Original Message-----
From: Christopher Ferris [mailto:chris.ferris@sun.com]
Sent: Monday, February 18, 2002 6:39 AM
To: Doug Bunting
Cc: ebXML Messaging
Subject: Re: [ebxml-msg] Issue73:


I agree with all your points on the importance of
validating the received messages before processing... However,
SOAP does not *require* either DTD processing or XML Schema
validation. This does not preclude XML Schema validation
to assess the validity of the received message. I thnk that
at best we can *strongly recommend* that the practice
of validating the received message(s) against the XML
Schema instance to assure receipt of a both well-formed
and valid message before turning it over to further
processing by the MSH. I don't think that we can
necessarily *require* that this be done.

w/r/t the process=lax v strict issue, that raises an
interesting point that probably should be addressed
by the XML Protocol WG regarding the SOAP schema.



Doug Bunting wrote:

> While writing my previous email (on issue 56) to Dick, I recognised an
> assumption not supported in the document (I think).  I've been assuming
> the receiver MUST (at least SHOULD) validate a message against the ebXML
> Messaging schema.  If that's not supported by our documentation and the
> SOAP envelope schema, we're in a whole world of security hurt.  (Just
> for example, code is often written assuming something is in the DOM tree
> because the schema requires its presence.  That code fails in ugly ways
> when those assumptions are violated by an non validating XML parser.)
> Due to the changes currently proposed resolving issue 73, I don't think
> we have the assurance of XML validation if we ever did in the past.
> Two things determine whether or not an XML instance is validated against
> a schema.  First, the parser responsible for reading the instance must
> be configured to perform validation.  I don't recall whether or not SOAP
> requires such a parser configuration.  Second, the specific elements of
> interest must be declared within a processContents="strict" block.
> Without strict interpretation of the block, a validating
> parser MAY or MUST (depending on the precise declaration) skip the block.
> The schema found at [1] does not match our hacked version at [2] in one
> important way: The one we threw together for our own use required
> validation of the SOAP extension elements found in the Envelope and
> Header.  [2] instead uses processContents="lax".  This means a
> validating parser MAY skip the contents of the Header and Envelope elements.
> [1] http://schemas.xmlsoap.org/soap/envelopenamespace
> [2] http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd
> To make the suggested change to our msg-header.xsd file, we must change
> the document in a few more ways than previously suggested.  In addition
> to removing mention of our specific schema location for the SOAP
> namespace, we must STRONGLY RECOMMEND the XML parser be configured to
> interpret processContents="lax" as processContents="strict".   (I'd
> prefer MUST to avoid long sentences describing requirements in this
> area for any level of security assurance.)  If the SOAP specification
> doesn't do this for us already, we should also require the XML parser to
> validate received documents.
> thanx,
>     doug

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC