Re: [ebxml-msg] Question about OPTIONAL

[Arvola Chan <arvola@tibco.com>]

David:

I vote for option 1: Stop processing and send back an Error --
NotSupported/Error.

I don't like option 2 because it violates the definition of
SOAP:mustUnderstand.

It should be the responsibility of the sending application to
understand the error code NotSupported and retry the
transaction without asking for the unsupported feature if
necessary.

I agree with Marty that if the two parties are governed by a
CPA, it should be extremely rare for one party to request
for a feature that is not supported by the other party.

Regards,
-Arvola

-----Original Message-----
From: Martin W Sachs <mwsachs@us.ibm.com>
To: David Fischer <david@drummondgroup.com>
Cc: ebXML Msg <ebxml-msg@lists.oasis-open.org>
Date: Thursday, November 08, 2001 10:31 AM
Subject: Re: [ebxml-msg] Question about OPTIONAL


>
>While these mismatches must be detected, the should be very infrequent if
>the trading partners use a CPA or virtual CPA.
>
>Regards,
>Marty
>
>***************************************************************************
**********
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>***************************************************************************
**********
>
>
>
>David Fischer <david@drummondgroup.com> on 11/08/2001 10:22:10 AM
>
>To:    ebXML Msg <ebxml-msg@lists.oasis-open.org>
>cc:
>Subject:    [ebxml-msg] Question about OPTIONAL
>
>
>
>I am discussing the use of OPTIONAL modules with IIC, and I need to get a
>question answered.
>
>What do we want to do if, for instance, an AckRequested element is on the
>message but the Receiving MSH does not support RM.  I see three options:
>
>1)  Stop processing and send back an Error -- NotSupported/Error
>2)  Continue processing but send back an Error -- NotSupported/Warning
>3)  Ignore and continue processing (no error).
>
>Since AckRequested has mustUnderstand="1", option 3 is not really an option
>(unless we change).  I think business users would prefer that a PO goes on
>through (option 2) and I am leery of stopping a message when there is no
>error
>in the message so I don't really like option 1.
>
>SOAP 1.1 section 4.2.3 SOAP mustUnderstand Attribute says:
>
>. . .with a value of "1" the recipient of that header entry either MUST
>obey the
>semantics (as conveyed by the fully qualified name of the element) and
>process
>correctly to those semantics, or MUST fail processing the message. . .
>
>Can we specify the behavior of option 2 with a value mustUnderstand="1"?
>
>Thoughts?
>
>Regards,
>
>David Fischer
>Drummond Group.
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>
>
>
>----------------------------------------------------------------
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.oasis-open.org/ob/adm.pl>