[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