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: Issue i002 thoughts/proposal


I had an action to send a proposal for issue i002 [1]. Here it is.

Issue i002 was raised during the 1st F2F. The issue was raised in the 
context of long running Sequences where it was possible for the AcksTo 
EPR to change. There was also some discussion on unending sequences (I 
think Steve Winkler brought this up). In a long running Sequence it is 
possible that the AcksTo EPR may change and therefore the RMS needs the 
ability to let the RMD know of the new AcksTo.

Subsequently, I have been talking with our mobile folks and they have 
brought up a different usecase (but which has the same issue):
In the mobile world there are cases where the RMS is expected to have 
different EPRs throughout the life of the Sequence (the device changes 
cells/location/countries or is intermitantly offline), therefore it 
necessary to provide the capability to change the AcksTo EPR for a 
particular Sequence in progress.

Here is the outline of a proposed solution:

1) The RMS is allowed to send a new message called wsrm:ChangeAcksTo 
with the following pseudo-schema --

<wsrm:ChangeAcksTo Version="xs:unsignedInt" ...>
   <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>

2) The RMD responds with wsrm:ChangeAcksToResponse or a fault with fault 
[Subcode] wsrm:ChangeAcksToDisallowed. wsrm:ChangeAcksToResponse has the 
following pseudo-schema --

<wsrm:ChangeAcksToResponse Version="xs:unsignedInt" ...>

The /wsrm:ChangeAcksToResponse/@Version has to contain the same value as 
the corresponding one in wsrm:ChangeAcksTo

Version numbers are strictly monotonically increasing numbers starting 
at 1 (the AcksTo EPR in the CS message being version 0).

The reason to have a version number in the exchange is because 
wsrm:ChangeAcksTo message may be retransmitted/lost/delayed/received 
out-of-order and it is necessary to prevent the RMD from regressing to a 
previous AcksTo.

On sending a wsrm:ChangeAcksToResponse message, the RMD sends subsequent 
acks to the new AcksTo EPR.




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