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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

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

Subject: RE: proposal: test indicator (2)

Agree with Stephano's comments.

Best regards,
At 01:06 AM 12/02/2000 +0100, Stefano POGLIANI wrote:
>       I do not re-iterate that I think that I would vote against this...
>...but, in case it will be approved, I would highlight the following:
>1.     it should NOT be the MSH to handle it but the Business Service 
>       Interface since it is modelled around the content of the CPA
>       (I assume the MSH is "independent on the CPA")
>2.     what happens if the CPA allows for Usage=Mode=Test and the
>       actual message does not contain any Usage clause? You mention that
>       it should be treated as a production, but should in this case 
>       the BSI "add" the "usage=production" to the header before 
>       passing to the application?
>3.     I would agree if in the actual header I have something like
>       <USAGE Mode=Test/>
>       but for the CPA I would suggest a syntax of the form:
>       <TestFlag_Allowed>
>       without any boolean value. Just the tag is present or not...
>> -----Original Message-----
>> From: christopher ferris [mailto:chris.ferris@east.sun.com]
>> Sent: Friday, December 01, 2000 12:49 AM
>> To: ebxml-transport@lists.ebxml.org
>> Subject: proposal: test indicator (2)
>> As discussed on yesterday's conference call (at length) here is
>> the second of two formal proposals for a test/production indicator. 
>> It differs only in that the CPA (TBD) will have the ability to 
>> identify whether the Usage/@Mode='test' is allowed, either at the
>> CPA or the Service/Action level and provides for a specific exception
>> process to be followed...
>> Cheers,
>> Chris
>> Proposal 2 Test indicator with pass-through semantics and CPA override
>> 7.9.2 CPAInfo
>> The TPAInfo element follows the From and To elements in the
>> Header element structure. The CPAInfo element is a composite set
>> of information that relates to the Collaboration Protocol Agreement
>> under which the message is governed. The CPAInfo element has five
>> child elements as follows:
>>      - CPAId 
>>      - ConversationId
>>      - Service
>>      - Action
>>      - Usage
>> ...
>> The Usage element has a cardinality of zero or one. It has a single 
>> attribute, Mode, which has two possible values; 'test' and 'production'.
>> A Message Service Handler implementation is REQUIRED to provide
>> the information implied by the Usage element, (e.g. that the message
>> is either a production or a test message) to the layer of software
>> above it in the stack (such as the receiving application). 
>> If the Usage element is NOT present in the ebXMLHeader document
>> of a given message, then that message is REQUIRED to be treated 
>> as if it were a 'production' message. 
>> The CPA [CPASPEC] provides the ability to disable the use
>> of the 'test' indicator either at the level of the CPA
>> or specifically for zero or more Service/Action pairs within
>> the CPA. The Message Service Handler is REQUIRED to check
>> the CPA to determine if use of the Usage element is permitted.
>> If not, then the Message Service Handler MUST respond with
>> a <FeatureNotSupported> error message [ref sect x.x].
>> This specification makes no claims on the behavior expected of
>> the application receiving a message which has a Usage Mode of
>> 'test'. It is up to the application receiving the message and
>> the Usage indicator as to how it is expected to handle processing
>> of a 'test' message.
>> The authors of this specification have added this element to
>> the specification of the ebXMLHeader so as to accommodate
>> mappings to other protocols which may choose to adopt ebXML
>> as their messaging protocol. It is RECOMMENDED that caution
>> be taken by IT organizations contemplating use of this feature
>> because of the implications it may have should a 'test' message
>> be treated as if it were a 'production' message.
>> Appendix A.1
>>      <!ELEMENT TPAInfo (..., Usage?)>
>>      ...
>>         <!ELEMENT Usage EMPTY>
>>         <!ATTLIST Usage  Mode  (test | production)  "production" >

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC