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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

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


Subject: New proposed issues 7/14 - 7/20


I have captured two new proposed issues since the last call from the list. Please let me know if I have overlooked any. – Regards, Marc g

 

proposed-01

Is an implementation supporting a smaller max message number valid?

core - design - unassigned

 

Description

The existing specification includes the clause "If the message number exceeds the internal limitations of an RM Source or RM Destination ...". This allows a source or destination to handle unexpected failures gracefully. It does not clearly allow, require, or prevent the implementation to be designed or deployed with a message number limit. Should we support such a limitation? Related to i013.

Justification

Issue below presupposes a "yes" answer to this question. Should decide this larger question before deciding how to fill gap left if the answer is "yes".

Origin

Doug Bunting

Proposal 12005-07-14

I lean toward "no" but could be convinced otherwise. If "no" is the answer, the specification could change to make it clear a WS-RM compliant implementation _must_ support the full unsigned long range for the message number. That likely requires conformance terminology not presently in the specification; this issue is not intended to broach the even-more-general subject of conformance clauses. My proposal therefore comes down to "close, no action".

proposed-02

Sequence termination on Fault

core - design - unassigned

 

Description

The RM Destination imperatively terminates a sequence due to one of these unrecoverable errors:

- wsrm:SequenceTerminated
- wsrm:MessageNumberRollover
- wsrm:LastMessageNumberExceeded
                 

The semantics of sequence termination due to a fault occurrence are not clearly specified.

This uses the reworded issue

Justification

Unless an accurate and final acknowledgement status was sent back at the time the sequence is closed, the Source will not know if some non-acknowledged messages were actually received before the termination occurs. This gives the source two unpleasant options: (a) resend all non-acknowledged message in a new sequence, with the risk of causing undetectable duplicates, (b) not resend any, and these will be lost.

Origin

Jacques Durand

Proposal 12005-07-15

Two options need be discussed: Option (1): At the time a Destination-controlled termination gets into effect, a final and accurate Acknowledgement for the entire sequence is sent back. Option (2): After the fault was notified to Source, simply rely on regular termination procedure (either expiration-based, or under Source control, so that the Source can complete its resending of pending messages and get the final acks), meanwhile reject any message for this sequence that exceeds the ending number in case of MessageNumberRollover or LastMessageNumberExceeded.

 



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