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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

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


Subject: [ebxml-cppa] Messaging Day 2 highlights for CPPA, one observer report.



1. The Messaging TC began by trying 
to understand what underlies the continuing interest 
with overriding CPA values, when messaging headers are available
to provide similar values. 

The messaging TC is concerned with having
an agreement that supports the "dynamic" use of these headers to
control behavior. The CPPA TC is concerned with being able
to write agreements that specify what constant values should
appear in these headers. It was proposed that when there are
"perMessage" headers, that the CPA's 
corresponding items can have a value
such as "perMessage." In this way, if people wish to agree
to be able to change values message by message, changing
the value will not conflict with a CPA that has agreed
to have this "perMessage" value. There are now only a very
few headers with the possibility of "perMessage" agreements,
and the Messaging TC will supply these header attributes
for us so that we can figure out how to align our spec
with these choices. 

I think that by shifting a few attributes from having boolean 
enumerated values ("true" "false"), to having "true", "false"
and "perMessage," we remove the temptation to
talk about overriding the CPA values. It seems to be a
promising way to reconcile and align the CPPA and Messaging
groups conflicting views. As will be seen,
it conserves the idea that a CPA does specify the
agreements that have been made about how to implement
the BP level conversations.

It was next proposed that for these
dynamic elements the default value should be "perMessage".
The default value is intended to be in effect 
when the CPA omits the attributes
However, when a CPA exists in which these
values are set to a fixed value (for example, either "true" or
"false" for a boolean attribute), 
the occurrence of any value in the
corresponding message item must match the CPA's
value, and that furthermore, the MSH MUST throw
an appropriate error (I recall that it is the
ebXML "inconsistent" error). 

The important action items for CPPA
are to first consider whether this compromise
solution seems workable and second, to
identify and modify appropriately the two
or three items for which we need to support
"perMessage" agreed upon values-- that is,
a value used to indicate an agreement 
to let message headers determine the
values that are used. Neither CPPA nor
MSH specifies where these values come
from. It was suggested 
that they could come from some BSI
interface yet to be devised and thus
allow application level conditional choice
of some MSH behavior.

2. Changes were made to sections 7.4.5 and 7.4.6
that set up what seem to be appropriate constraints
on TimeToLive, PersistDuration, and other RM related
parameters. These parameters are allowed to be 
implemented independently of RM usage for some reason,
and this probably raises a smallish alignment issue
for CPPA.

3. As far as I can tell, Ackrequested, duplicateElimination,
and the signed or unsigned attribute on AckRequested are
the items that will need to be given "perMessage" semantics.
There was considerable indeterminate discussion about
the wisdom of having these things set on a perMessage 
basis. Without entering into the merits here, I think
the CPPA TC needs to
consider how to indicate perMessage values for these,
and what it means about how implementations using
these new values are to be described. Do they provide
an agreement on using RM? on providing NRR? 

4. The seemingly increasing duplication of functions at
two levels (application and messaging) needs to be 
clearly documented. The contrast between idempotent and
duplicateElimination needs to be documented, for example.
Also the differences between ReceiptAcknowledgement, a
signed Messaging Acknowledgement, and the BP characteristics
such as IntegrityCheck, NRR, and so on. There are even
possible problems involving BP level retries with MSH level
retries that will need some resolution.


The Messaging group has made it through their initial agenda
and their version 1.1 pending issue 
list and is to be commended for
arriving at consensus positions that will allow the CPPA
TC to document CPAs and how their parameters relate
to populating message fields, checking header values,
and specifying parameters for behavior for MSH behavior.


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


Powered by eList eXpress LLC