[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 007 - WS-C: Make Register/RegisterResponse retriable
Doug Davis wrote: > > 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. You're right: one was an implementation choice and the other is what causes the issue Alastair raised ;-) > 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. Agreed, but I'm trying to stay clear of implementation. We can say within the specification that retries of protocol messages MUST use the same wsa:messageID. How that happens is an implementation choice. We may want to define this only on some message interactions, but that's secondary. > > In this case however we're talking about retry of a Register which I > don't believe was > even part of the interop event. We were, but I'd taken the leap that if it's a problem in one case, it may be a problem elsewhere and if we can fix it once "for all time" then we should. > 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). I think it can. See WS-RX for examples - you were involved with them ;-) > 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. Mark. > > 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]" > > >>>>>>>>>>>>>>>> > > >> > > >>>>>>>>>>>>>>>> > > >> > > >>>>>>>>>>>>>>>> > > >> > > >>>>>>>>>>>>>>>> > > >> > > >>>>>>>>>>>>>>>> > > >> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>>>>>>> > > >>>>> > > >>>>> > > >>>>>>>>>>>>> > > > > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>> > > >>>> > > >>>>>>>>>> > > > > >>>>>> > > >>>>>> > > >>>>>> > > >>> > > >>> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]