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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Re: [wsrm] Proposal for CF4


Jacques,

I must have lost track of all the CF issues and their status.  Back on the 
15th I sent an email entitled "Proposed resolutions for ChrisF issues 
3,4,6,8,10" that started to cover this and thought we were done.  Your 
proposal covers other edits to "line 489" (way back then) which have 
happened in the meantime and introduces the need for another clarification. 
  Glad you remembered we were not done.

I agree with the direction your update to Section 5.1.3.5 but am unsure 
about using a general reference to section 3.2.1 from there, where the 
previous update lies.  If we provide the clarification you mention in 
section 3.2.1, that reference would cover both the general list of resend 
terminations and the specific list of (abnormal) group terminations.  Might 
be better to list the specific faults in 5.1.3.5 (provide the clarification 
there).  The reference would then go in the other direction -- something 
like "In some cases, the group containing this message terminates as well 
(see Section 5.1.3.5 for more information)." after the "delivery failure 
instead" bullets in 3.2.1.

I suspect the entire list of resend termination cases results in group 
termination for an ordered list.  Is the Receiver RMP required to use the 
GroupAborted fault in that case or should the clarification mention that 
group termination of an ordered group happens in all cases of resend 
termination?

thanx,
	doug

On 29-Jul-04 22:07, Jacques Durand wrote:

> Proposal for C.F. comment #4:
> 
> agree with C.F. (use MUST), although this is more a matter of 
> optimization vs ease of implementation
> 
> "A Sending RMP MUST NOT  resend a message for which an RM-Reply with one 
> of the following Fault types has been received, and must notify its 
> Producer of a delivery failure instead:
> 
>             "An Invalid Message Format fault code (Table 22)
>             "A NonSupportedFeature fault code
>             "A PermanentProcessingFailure fault code"
> 
> Also, group termination must be updated consequently:
> Section 5.1.3.5 (termination by ordering failure), the Triggering event 
> (in both Sender and Receiver)
> should be extended with:
> "...or a [sent] message is faulted with one of the codes mentioned in 
> section 3.2.1"
> (replace "sent" with "received", for Receiver)
> 
> Another a related issue, when a Sender receives Faults such as 
> GroupAborted, or PermanentProcessingFailure, is that not only resending 
> but also new sendings for the group should be stopped. That needs be 
> made more explicit.
> 
> 
> Jacques
> 


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