|Jacques Durand||Apr 20, 2004 11:54 am|
|Subject:||Action 032304-2 proposal|
|From:||Jacques Durand (JDur...@us.fujitsu.com)|
|Date:||Apr 20, 2004 11:54:57 am|
Title: Action 032304-2 proposal
Action 032304-2 proposal (from Sunil / Jacques)
- Issue 1: RetryMaxTimes and RetryTimeInterval are really meaningful only for Callback reply pattern. The spec is silent on this limitation. For Poll reply patttern, the resending effort can be associated with the polling: The spec is silent on the resending policy in that case.
- Issue 2: RetryMaxTimes and RetryTimeInterval have a precise interpretation, that actually is just one way to do the resending effort. Other ways should not be excluded.
- Issue 3: there is no indication of how often a Poll request will be sent. Yet this should be controlled by the RMP (and remain transparent to the application). A parameter to control this (time period, or number of messages, or both) need be defined.
Proposal Outline: ------------------
1- RM Agreement items can be either Required / optional :
Update section 1 to reflect that:
- some RM Agrement Items are "required" by this specification: an implementation must be able to represent them and their value. They are critical to the specified reliability mechanisms: GuaranteedDelivery, NoDuplicateDelivery, OrderedDelivery, GroupMaxIdleDuration GroupExpiryTime, ExpiryTime, ReplyPattern
- Some RM Agrement Items are "optional" for this specification: Two communicating parties do not have to both agree on using them. An implementation may represent them and use them to locally control the execution of reliability features: RetryMaxTimes, RetryTimeInterval, PollFrequency
2- Introduce PollFrequency optional agreement item, as a way to control the frequency of polling.
3- update Section 3.1 (guaranteed delivery) to stress the optionality of agreement items that control resending, and cover all reply patterns. E.g. For each poll, after looking at the Poll response, the RMP will resend all messages that have not been acknowledged or faulted. Poll frequency is also controlled.
4- Mention that some agreement items are set by business partners, some are intended to be set more dynamically, depending on network conditions, messaging load.
-----Original Message----- From: Tom Rutt [mailto:to...@coastin.com] Sent: Monday, April 19, 2004 8:25 AM To: wsrm Subject: [wsrm] List of open WSRM Action Items
The list of open action items, as of 4/13 teleconf follows:
Action 032304-2 (Sunil & Jacques) Pending
Sunil and Jacques will provide a proposal on retry parameters to the group before the end of the public review period. still open
Action 033004-3 (Jacques) Pending
Jacques took action item to propose new FAQ text for the ws-reliability features. - open
Action 033004-4 (Mark G) Pending
Why does the spec have a different name than the TC?
Marc G agreed to propose a new question with new answer to clarify the matter. - open
Action 033004-5 (Jacques) Pending
Jacques took action to clearly state what the relation with ebMS is. He agreed to draft a question with an answer. - open
Action 033004-6 (Tom) Pending
Need a general question on how can ws reliability be used with other ws reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.
Tom Rutt agreed to send a suggested question and proposal out. - open
Action editors-1 (Marc and Doug) Pending
Marc G and Doug B to updated issues list to reflect agreements in CD .992. - open
Action 041304-1 (Jacques) Pending
- Jacques will send an email to initiate email discussion on poll response for fault conditions
Action 041304-2 (Iwasa) Pending
- Iwasa to action to consolidate all the agreed comments in text with change bars against CD .992. A list indicating which meeting minutes agreed changes were applied should also be included.
Action 04304-3 (Sunil) Pending
Sunil took action to consolidate all agreed comments on Schema.
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.