Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

[Doug Davis <dug@us.ibm.com>]

See http://wsi.alphaworks.ibm.com:8080/interop/index.html

I don't see any mandate that msgID be
the same on retries, nor do the Tx specs say that.
This becomes an implementation issue.
If your Tx code is very close to your WSA code then
its very possible that a retry of a
Tx message (resent by Tx logic and not WSA or transport
logic) could have the same msgID.  However,
that's an implementation choice.  Some may
view Tx as a layer on top of WSA and
therefore when Tx initiated the resend it may not have
control over the msgID - it is delegated
to WSA.

In this case however we're talking about
retry of a Register which I don't believe was
even part of the interop event. And
in this case its not clear if we're talking about a Tx
initiated retry or a transport-level
retry.  If its Tx then I don't believe the spec can mandate
anything about the msgID (see above).
 If its a transport level retry then I'm wondering
where did that retry logic come from
since all I see below Tx is WSA and SOAP and neither
of those require a retry and therefore
the retry semantics (if any) are non-interoperable/undefined.

thanks,
-Doug

Mark Little <mark.little@jboss.com>

12/13/2005 07:12 AM

To	Doug Davis/Raleigh/IBM@IBMUS
cc	ws-tx@lists.oasis-open.org
Subject	Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable

Doug, one of us is remembering incorrectly and without
access to the doc 
I can't say who yet.

Mark.


Doug Davis wrote:

>
> Mark,
>   If I'm remembering correctly the retries didn't require the
> wsa:messageID to be
> the same each time.  The duplicate detection was done at the
tx 
> protocol level
> not at the WSA level - meaning the protocol knew how to deal with
> multiple
> Prepare messages - not multiple messages with the same msgID.  Those
are
> two very different things.
> thanks
> -Doug
>
>
>
> *Mark Little <mark.little@jboss.com>*
>
> 12/13/2005 05:36 AM
>
>                  
> To
>                  ws-tx@lists.oasis-open.org
> cc
>                  
> Subject
>                  Re:
[ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
>
>
>
>                  
>
>
>
>
>
> BTW, to your point of ease: the interop scenarios we had to do in
> January/February this year had many situations requiring timeouts
and
> retries. I certainly can't say I canvased everyone present, but I
didn't
> get the impression that that aspect was considered too much of an
> implementation headache.
>
> Mark.
>
>
> Christopher B Ferris wrote:
>
>
>
> >>>>
> >>>> I'm not sure that using ws-a messageId is the easiest...
it means 
> that
> >>>> impls need to remember messageId
> >>>> which can get onerous.
> >>>>
> >>>> The WS-A WG avoided the issue of EPR equivalence
mostly because of
> >>>> issues related to use of
> >>>> EPRs to identify something. IMO, in that spirit,
EPR comparison
> >>>> becomes one of comparing the
> >>>> <Address> element which comes down to URI equivalence
issues 
> which can
> >>>> go in a number of
> >>>> directions... the namespace URI approach (straight
string 
> comparison)
> >>>> or the approach which normalizes the URI
> >>>> first before comparing.
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Christopher Ferris
> >>>> STSM, Emerging e-business Industry Architecture
> >>>> email: chrisfer@us.ibm.com
> >>>> blog: http://webpages.charter.net/chrisfer/blog.html
> >>>> phone: +1 508 377 9295
> >>>>
> >>>> Mark Little <mark.little@arjuna.com> wrote
on 12/12/2005 03:20:16 PM:
> >>>>
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>> > There are multiple ways of making
the operation idempotent. 
> Using WS-A
> >>>>>>> > semantics is one and IMO is probably
the easiest way of 
> doing it: it
> >>>>>>> > goes back to traditional Retained
Results RPC mechanisms of 
> the late
> >>>>>>> > 1980's, where idempotency was imposed
at the comms level. If 
> we try to
> >>>>>>> > do it higher up the stack, within
the actual implementation, 
> then we're
> >>>>>>> > going to have to address the issue
of EPR comparisons: how 
> can I ensure
> >>>>>>> > this is the same operation if I
can't determine that the 
> parameters are
> >>>>>>> > identical?
> >>>>>>> >
> >>>>>>> > So, I think we're agreed that it
needs to be idempotent. But
> >>>>>>> > until/unless we address EPR comparisons,
I think the WS-A 
> retry route
> >>>>>>> > gets my vote.
> >>>>>>> >
> >>>>>>> > Mark.
> >>>>>>> >
> >>>>>>> >
> >>>>>>> > Christopher B Ferris wrote:
> >>>>>>> >
> >>>>        
> >>>>
> >>>>    
> >>>>
> >>    
> >>
> >>>>>>>>>> > >
> >>>>>>>>>> > > That is one way,
the other is to make the Register 
> message idempotent.
> >>>>>>>>>> > >
> >>>>>>>>>> > > Seems to me that
Register SHOULD be idempotent. It is 
> much simpler to
> >>>>>>>>>> > > simply process
> >>>>>>>>>> > > the Register as
if it had never been received... makes the
> >>>>>>>>>> > > implementation
of the client
> >>>>>>>>>> > > a bit simpler.
> >>>>>>>>>> > >
> >>>>>>>>>> > >  I also think
that the "AlreadyRegistered" fault is 
> probablematic. It
> >>>>>>>>>> > > doesn't reflect
> >>>>>>>>>> > > back the CoordinationProtocolService
EPR that the 
> RegisterResponse
> >>>>>>>>>> > > message does.
> >>>>>>>>>> > > So, from the perspective
of the registrant, it ISN'T 
> registered if it
> >>>>>>>>>> > > doesn't receive
the
> >>>>>>>>>> > > RegisterResponse
message since it doesn't know the
> >>>>>>>>>> > > CoordinationProtocolService
> >>>>>>>>>> > > EPR.
> >>>>>>>>>> > >
> >>>>>>>>>> > > From the perspective
of the registration service, 
> overlaying the
> >>>>>>>>>> > > previous registered
> >>>>>>>>>> > > EPR is effectively
an idempotent operation, and the 
> response can be
> >>>>>>>>>> > > the same as if
> >>>>>>>>>> > > it didn't have
the registration beforehand.
> >>>>>>>>>> > >
> >>>>>>>>>> > > IMO, making the
operation idempotent makes the 
> implementation much
> >>>>>>>>>> > > simpler and
> >>>>>>>>>> > > more robust in
the long run.
> >>>>>>>>>> > >
> >>>>>>>>>> > > Cheers,
> >>>>>>>>>> > >
> >>>>>>>>>> > > Christopher Ferris
> >>>>>>>>>> > > STSM, Emerging
e-business Industry Architecture
> >>>>>>>>>> > > email: chrisfer@us.ibm.com
> >>>>>>>>>> > > blog: http://webpages.charter.net/chrisfer/blog.html
> >>>>>>>>>> > > phone: +1 508 377
9295
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > > *Mark Little <mark.little@jboss.com>*
> >>>>>>>>>> > >
> >>>>>>>>>> > > 12/12/2005 11:36
AM
> >>>>>>>>>> > >
> >>>>>>>>>> > >    
> >>>>>>>>>> > > To
> >>>>>>>>>> > >    ws-tx@lists.oasis-open.org
> >>>>>>>>>> > > cc
> >>>>>>>>>> > >    
> >>>>>>>>>> > > Subject
> >>>>>>>>>> > >    Re:
[ws-tx] Issue 007 - WS-C: Make 
> Register/RegisterResponse
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>>>>
> >>>      
> >>>
> >>>> retriable
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > >    
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > > Actually I'll retract
this. As Kevin just reminded me, 
> we're using
> >>>>>>>>>> > > WS-Addressing anyway,
so surely lost messages and 
> retries can be coped
> >>>>>>>>>> > > with at that level:
using the same wsa:MessageID for 
> example, should
> >>>>>>>>>> > > sort this.
> >>>>>>>>>> > >
> >>>>>>>>>> > > Mark.
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > >
> >>>>>>>>>> > > Mark Little wrote:
> >>>>>>>>>> > >
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>>>>
> >>>      
> >>>
> >>>>>>>>>>>>> > > >
I think this makes proposal makes sense.
> >>>>>>>>>>>>> > > >
> >>>>>>>>>>>>> > > >
Mark.
> >>>>>>>>>>>>> > > >
> >>>>>>>>>>>>> > > >
> >>>>>>>>>>>>> > > >
Peter Furniss wrote:
> >>>>>>>>>>>>> > > >
> >>>>>>>>          
     
> >>>>>>>>
> >>>>>>>>        
> >>>>>>>>
> >>>>        
> >>>>
> >>>>>>>>>>>>>>>> >
> >> This is hereby declared to be ws-tx Issue 007.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Please follow-up to this message or ensure the 
> subject line starts
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>>>>>>>> > > Issue
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>>>>
> >>>      
> >>>
> >>>>>>>>>>>>>>>> >
> >> 007 - (ignoring Re:, [ws-tx] etc)
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> The Related Issues list has been updated to 
> show the issue numbers.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Issue name -- WS-C: Make 
> Register/RegisterResponse retriable
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Owner:  Alastair Green 
> [mailto:alastair.green@choreology.com]
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Target document and draft:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Protocol:  Coord
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Artifact:  spec
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Draft: Coord spec working draft uploaded 
> 2005-12-02
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Link to the document referenced:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>>>>>>>> > >
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>>>>
> >>>      
> >>>
> >>>> 
> http://www.oasis-open.org/committees/download.php/15738/WS-Coordination-
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> 2005-11-22.pdf
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Section and PDF line number:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> WS-Coordination spec, Section 3.2 
> "Registration Service" l. 294
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Issue type: Design
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Related issues:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Issue 008 - WS-C: Remove fault 4.6 
> AlreadyRegistered
> >>>>>>>>>>>>>>>> >
> >> Issue 014 - WS-C: EPR equality comparison is 
> problematic Issue
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> 009 -
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> WS-C/WS-AT: Is request-reply MEP useful?
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Issue Description:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Register/RegisterResponse should be retriable 
> exchange
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Issue Details:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> [This issue stems from Choreology Contribution 
> issue TX-20.]
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Section 9 of WS-AT defines the WS-Coordination 
> exchanges
> >>>>>>>>>>>>>>>> >
> >>  
> >>>>>>>>>>>>>>>> >
> >>     
> CreateCoordinationContext/CreateCoordinationContextResponse
> >>>>>>>>>>>>>>>> >
> >>     Register/RegisterResponse
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> as request-reply exchanges.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> (Whether this request reply MEP should be used 
> at all in the WS-TX
> >>>>>>>>>>>>>>>> >
> >> specs is addressed in a separate issue: see 
>  "Issue 009 -
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> WS-C/WS-AT:
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> Is request-reply MEP
> >>>>>>>>>>>>>>>> >
> >> useful?".)
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Substantively, it may be particularly 
> misleading to think of the
> >>>>>>>>>>>>>>>> >
> >> Register/RegisterResponse
> >>>>>>>>>>>>>>>> >
> >> exchange as a request-reply pattern. The 
> implication of using this
> >>>>>>>>>>>>>>>> >
> >> pattern is that there is a simple one message 
> in, one message out
> >>>>>>>>>>>>>>>> >
> >> exchange. The presence of a fault
> >>>>>>>>>>>>>>>> >
> >> (AlreadyRegistered) as a potential response to 
> Register hardens
> >>>>>>>>>>>>>>>> >
> >> that implication.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Current behaviour would lead to service being 
> informed it has
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> already
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> registered a
> >>>>>>>>>>>>>>>> >
> >> Participant, when it has in fact simply 
> succeeded in registering a
> >>>>>>>>>>>>>>>> >
> >> Participant. Superficially, the
> >>>>>>>>>>>>>>>> >
> >> AlreadyRegistered fault could simply be
> >>>>>>>>>>>>>>>> >
> >> viewed as being unnecessarily verbose: the 
> reaction of the
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> service to
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> the fault at run-time must be to treat
> >>>>>>>>>>>>>>>> >
> >> it as uninteresting, i.e. as equal in effect 
> to a successful
> >>>>>>>>>>>>>>>> >
> >> registration.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> In fact there is a deeper problem. Consider 
> the following scenario:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> A Coordination Service (CS) creates a 
> Coordinator (C) for a new
> >>>>>>>>>>>>>>>> >
> >> atomic transaction (AT), and emits a 
> CoordinationContext (CC).
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> The CC is transmitted to an application 
> service (AS). AS
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> (logically)
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> creates a P which sends Register (R) to the 
> Registration
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> Service (RS)
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> EPR for AT, embedding the EPR for receipt
> >>>>>>>>>>>>>>>> >
> >> of protocol messages outbound from C to P (CP 
> EPR).
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> The RS, on receiving Register, creates an EPR 
> for inbound protocol
> >>>>>>>>>>>>>>>> >
> >> messages from P to C (PC EPR), and embeds this 
> in the
> >>>>>>>>>>>>>>>> >
> >> RegisterResponse (RR), which it sends to P.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> AS and P crash before the RR message is 
> received by P, or the RR
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>>>>>>>> > > message
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>>>>
> >>>      
> >>>
> >>>>>>>>>>>>>>>> >
> >> drops and is never received by P. Either way, 
> AS (on recovery,
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> or after
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> waiting) causes P to resends R to RS. RS 
> examines the inbound
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> Register,
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> and determines that it has come from a known P 
> (see "Related
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> Issues",
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> "WS-C: EPR equality comparison should
> >>>>>>>>>>>>>>>> >
> >> not be relied upon"), i.e. that it is a 
> duplicate registration.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Currently, RS replies with an 
> AlreadyRegistered fault, sent to P. P
> >>>>>>>>>>>>>>>> >
> >> now knows that he is registered with C, but 
> has never received
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> the PC
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> EPR 
> (/RegisterResponse/CoordinationProtocolService element). Any
> >>>>>>>>>>>>>>>> >
> >> further retries of P send R to C will result 
> in the same situation.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> C will never be able to receive messages from 
> P. P will never
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> become
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> Prepared. The transaction will eventually 
> collapse through timeout.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Therefore, the Register/RegisterResponse 
> exchange must tolerate
> >>>>>>>>>>>>>>>> >
> >> duplicates. If a Register message is delivered 
> more than once
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> (either
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> by the transport, or through comms-failure- or 
> recovery-induced
> >>>>>>>>>>>>>>>> >
> >> retry) then the Registration Service should 
> respond on each
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> occasion
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> with a RegisterResponse containing the same PC 
> EPR, to ensure
> >>>>>>>>>>>>>>>> >
> >> reliable completion of the EPR exchange that 
> permits the subsequent
> >>>>>>>>>>>>>>>> >
> >> coordination protocol to operate correctly.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> NOTE.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> This change brings the R/RR exchange in line 
> with the behaviour of
> >>>>>>>>>>>>>>>> >
> >> the CreateCoordinationContext/...Response
> >>>>>>>>>>>>>>>> >
> >> exchange. There is a difference. R/RR is 
> likely to be
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> implemented as
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> a true idempotent operation. CCC/CCCR is
> >>>>>>>>>>>>>>>> >
> >> not: each CCCR embeds a new RS EPR, and a new 
> /Context/Identifier.
> >>>>>>>>>>>>>>>> >
> >> But each exchange can be harmlessly
> >>>>>>>>>>>>>>>> >
> >> replayed indefinitely, in the event of failure 
> to receive the
> >>>>>>>>>>>>>>>> >
> >> response message.
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Proposed Resolution:
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> Insert the following text in WS-Coordination 
> spec, Section 3.2
> >>>>>>>>>>>>>>>> >
> >> "Registration Service" immediately following 
> current l. 294
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >> "[New paragraph]The requester MAY send a 
> Register message for a
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> given
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> Participant more than once, and the underlying 
> transport could
> >>>>>>>>>>>>>>>> >
> >> deliver the Register message more than once.
> >>>>>>>>>>>>>>>> >
> >> On receipt of a Register message for a
> >>>>>>>>>>>>>>>> >
> >> given Participant, which has already been 
> processed
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> succesfully, the
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> Registration Service MUST send to the
> >>>>>>>>>>>>>>>> >
> >> requester a RegisterResponse containing the same
> >>>>>>>>>>>>>>>> >
> >> CoordinationProtocolService element (Endpoint 
> Reference for
> >>>>>>>>>>>>>>>> >
> >> Participant to Coordinator protocol messages) 
> as that contained in
> >>>>>>>>>>>>>>>> >
> >> all previous RegisterResponses generated by
> >>>>>>>>>>>>>>>> >
> >> the Registration Service which relate to the 
> Participant's
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>> request to
> >>    
> >>
> >>  
> >>
> >  
> >
> >>>>>>>>>>>>>>>> >
> >> register for this activity.
> >>>>>>>>>>>>>>>> >
> >> [New paragraph]"
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>>>>>>> >
> >>  
> >>>>>>>>>>>>>>>> >
> >>
> >>>>>>>>>>        
           
> >>>>>>>>>>
> >>>>>>>>>>        
 
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>>>>>>>>>>> > > >
> >>>>>>>>          
     
> >>>>>>>>
> >>>>>>>>        
> >>>>>>>>
> >>>>        
> >>>>
> >>>>>>>>>> > >
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>      
> >>>
>