RE: proposal: test indicator (2)

[Stefano POGLIANI <stefano.pogliani@sun.com>]

Chris,

	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...

/Stefano

> -----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
> 
> ...
> 
> 7.9.2.5
> 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" >
>