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

[Mark Little <mark.little@jboss.com>]

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]"
> >>>>>>>>>>>>>>>> > > >>
> >>>>>>>>>>>>>>>> > > >>
> >>>>>>>>>>>>>>>> > > >>
> >>>>>>>>>>>>>>>> > > >>  
> >>>>>>>>>>>>>>>> > > >>
> >>>>>>>>>>                    
> >>>>>>>>>>
> >>>>>>>>>>          
> >>>>>>>>>>
> >>>>>          
> >>>>>
> >>>>>>>>>>>>> > > >
> >>>>>>>>                
> >>>>>>>>
> >>>>>>>>        
> >>>>>>>>
> >>>>        
> >>>>
> >>>>>>>>>> > >
> >>>>>>            
> >>>>>>
> >>>>>>      
> >>>      
> >>>
>