Full Agenda WSRM TC Conference Call –
Dec 16, 2003
The meeting of the WSRM TC will take place by teleconference
Tuesday Dec 16, from 5:30 to 6:30 PM Eastern Standard Time
(UTC - 5)
New numbers
Toll free
us: 1-888-737 5834
International 1- 719-457-4158
Code 171998
0
Draft
Agenda:
Draft Agenda to WSRM TC Conference Call – Nov 11, 2003
1 Roll Call (late
arrival no longer counts by OASIS rules)
2 Minutes
Discussion
2.1 Appointment
of Minute Taker
2.2 Approval of
previous meeting minutes
3 Feedback Discussion
of XML 2003 Demo
4 Discussions of
Issues
5 F2f Meeting
schedule and new conference bridge
1
Roll
Call
Meeting quorate.
2
Minutes
Discussion
2.1 Appointment
of Minute Taker
Tom Rutt will take
minutes.
Minutes will serve for issue resolutions.
2.1 Approval
of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/4379/MinutesWSRMTC1125.htm
moved to accept the 12/02 minutes. yy seconded.
opposition, 12/02 minutes approved.
3
Feedback
from XML 2003 Demo
4
Discussion of Jan F2F and New Conference
Bridge service
5
Discussion
of Issues
Iwasa put together a
new document, rev .84, which incorporates the latest
closed issues, 33 and 50.
5.1 Rel 33
Rel
33 was reopened and then later closed with the new definition of Ack being on delivery.
This needs to be
reflected in the Issues list.
5.2 Rel 50
This was also closed at
a wsrm teleconference. New text has been added to the draft .84.
Needs
to be reflected in the issues list.
5.3 Rel 52 and 57 and 82
The following proposal
is intended to resolve issues rel 52 and 57, and it
also resolves rel 82.
Latest Email proposal
from Task force:
This proposal (draft
g) is intended to close both Rel 52 and Rel 57:
-------
Rel
52: (New rules for state persistence, also, related "timing issues")
and Rel 57 Ordering and Missing Message Behavior
-------
Rel
57 is addressed as part of T5 of Rel 52 and hence
should be closed as resolved by resolution for Rel
52.
Add the following
text to a subsection which defines the two group termination parameters. This section should replace the existing “RemoveAfter” section of the document.
-------
x.x Group termination parameters
A
request message MAY contain one of the following group termination parameters:
-
Group Expiry Time – the date and time at which
the sender wishes the sequence group to terminate.
-
Group Max Idle Duration – On the receiver side,
if the time interval since the last message was received exceeds the group max
idle duration, then the sequence group may be terminated. On the sender side,
the same condition applies to the time since the last message was sent.
The
following assumptions pertain to the two group persistence control parameters:
a)
the First message in a group (the one with
status=start) MUST be used by the sender to indicate that time based group
persistence control is in use for the group.
-
If the first message in the sequence of a group
has neither group persistence parameter present, the group will be terminated
according to condition t4 or t5.
-
If the first message has either of the two group
persistence parameter present (either GroupExpiryTime,
or GroupMaxIdleDuration) then that parameter will be
used in the criteria used for terminating the group.
-
A fault MUST be returned if both group
persistence parameters are present in any request. An INVALID_GROUP_PARAMETER
fault shall be sent in this case..
-
If GroupExpiryTime is
in use, the sender must not send a message in that group with an ExpiryTime greater than the GroupExpiryTime.
b)
If guaranteed delivery is not requested for messages in the group, then the
group termination parameter which was sent on the first message in the group
must have a value sent on all subsequent messages in that group.
c)
If guaranteed deliver is requested for the group, subsequent messages in the
sequence do not need to repeat the group persistence parameter. When
guaranteed delivery is mandated for the group, it is RECOMMENDED that the
sender repeats the group persistence parameters in each message sent, until the
first acknowledgement has been received for the group. The receiver will continue to use the latest
received value for the parameter chosen by the sender to apply to the group, to
serve as the trigger for terminating the group. If a subsequent message uses a
different group parameter than the one used in a prior message or uses a group
termination parameter not sent on the “start” message for the group, an
INVALID_GROUP_PARAMETER FAULT MUST be returned.
d) In any subsequent message
the parameter which was sent in the first message can be changed by sending a
new value. A new value for GroupMaxIdleDuration
can either be increased or decreased. The protocol allows change (up or down)
of GroupExpiryTime, as long as it is never less than maxExpiryTimeReceived.
The
sender will know, when the receiver has replied to a message which contains new
group persistence parameter values present, that the receiver has knowledge of
the new values. If a reply to the
message with the new parameters is not received in time, the sender needs to
resend the group persistence parameters through a retry or in a subsequent
message of the sequence. An INVALID_GROUP_PARAMETER FAULT MUST be returned if the value is decreased to be less than the maximumExpiryTime received for the group.
e)
The sender can explicitly terminate the group by sending a message with status
value “END”. This is regardless to
whether a group termination parameter is in use for the group.
----------------------
Add a new section
x.y Group persistence
The
duplicate elimination feature requires persisting the message ID (GroupId and optionally the Sequence Number), after the
message has been processed and delivered (made available) to the application.
The general rule about message ID persistence, is that an RMP MUST persist the
ID of a message at least until the message expires regardless whether the
message has been delivered or not to the application.
It
is RECOMMENDED that an RMP removes the ID of a singleton message (message with GroupId but no SequenceNumber)
from its persistent store after it expires. However, unlike for singletons, it
is RECOMMENDED to NOT remove the ID of a message that belongs to a
non-singleton group, when the message expires. The reason is,
message IDs for groups can be stored efficiently as intervals of integers.
NOTE:
When doing duplicate checks for messages of a group, there is no loss of
performance in checking over all past message IDs of the group, whether expired
or not. The check will in fact be faster, because not discarding expired IDs
means fewer intervals to look up.
Add the following
new section:
x.z Group Termination and State
Removal Criteria
These
termination rules apply to both ordered and unordered groups.
In
all termination cases (t1, t2, t3, t4, t5) described in this section, it is not
necessary to remember the ExpiryTime of all messages
of a group, as only the maximum of all ExpiryTime
values is needed.
Termination
of a group, and removal of its state are two distinct
events.
o
When a group terminates, both in sender and
receiver, no message is expected to be sent or received for this group anymore.
When a group terminates, all subsequent messages with same group ID would be
handled as belonging to a new group, unless they are duplicates of previous
messages in the group, in which case they are treated as duplicates within this
group. If a message is received after
the termination of a group, with same GroupId as the
terminated group, it May be considered by the Receiver as belonging to a new
group (the Receiver is not required to verify that a new GroupId
value has not already been used in a previous group, as this test is
impractical).
o
When the state of a group is removed, any trace
of the group (including status, groupId, current
sequence number, as well as all received message IDs for the group (e.g. SequenceNumber intervals) are removed, and therefore not
available anymore for subsequent duplicate checks. State removal may occur
either at termination time or later, depending on the termination rules that
follow.
x.z.1 Termination (t1):
----------------
Triggering
event: GroupExpiryTime is over.
Receiver
side:
The
RMP MUST NOT accept any new message for this group and MUST terminate the
group. It is RECOMMENDED that its state be removed as soon as possible. No
duplicate check needs to be done against that group ever. If a "late
duplicate" arrives, it would never be delivered to the next layer, as its ExpiryTime, which is always earlier than GroupExpiryTime, would have expired.
Sender
side:
The
group MUST be terminated, and its state removed from the RMP.
x.z.2 Termination (t2):
-----------------
Triggering
event: GroupMaxIdleDuration is over.
Receiver
side:
The
group MUST be terminated. But unlike (t1), some of its past messages may not
have expired yet, and therefore their ID still be needed for duplicate
checks. If we define maxExpiryTimeInGroup
as the max of all ExpiryTimes of messages already
received for a group, an RMP MUST persist the state of a group even after
termination of the group, at least until maxExpiryTimeInGroup
is reached, in case duplicate elimination is required.
Sender
side:
The
group MUST be terminated, and its state removed from the RMP when the time
elapsed since the last sent message (including retries) exceeds GroupMaxIdleDuration.
x.z.3 Termination (t3):
----------------
Triggering
event: the RMP receives a status="end" message. The group had either GroupExpiryTime or GroupMaxIdleDuration
specified.
Subcase t3.1: The group was complete on receiver side.
Receiver
side:
The
group MUST be terminated. However, its state is removed according to (t1) or
(t2), depending which termination criterion was specified for the group.
Sender
side:
The
group is also known to be complete, and MUST be terminated and state is
removed.
Subcase t3.2: The group was not complete on receiver side.
In
this case, the group is not yet terminated.
Indeed, an "end" status only tells that "no greater seq number will ever be received after", but late
messages may still arrive for this group.
Sender
and Receiver Side:
Then
the Receiver RMP and Sender RMP MUST apply termination rules of (t1) or (t2),
depending which one of GroupExpiryTime or GroupMaxIdleTime was specified
x.z.4 Termination (t4):
----------------
Triggering
event: the RMP receives a status="end" message. The group had neither
GroupExpiryTime nor GroupMaxIdleDuration
specified.
Subcase t4.1: The group was complete on receiver side.
Receiver
side:
The
group MUST be terminated. The time of removal of its state is determined by the
maxExpiryTime received in the Group.
Sender
side:
The
group is also known to be complete, and MUST be terminated and the group state
removed.
Subcase t4.2: The group was not complete on receiver side.
Receiver
side:
In
this subcase, the RMP should keep the group
processing active: this event, by itself, does not cause the termination of the
group.
The
group can terminate in two ways:
a) When
the group becomes complete, or
b) When
the maxExpiryTime received for the group is reached.
In
either case a) or b), the time of group state removal is based on the maxExpiryTime received for the group.
Sender side:
The group is terminated either when:
a) all
the messages in the group are acknowledged, or
b) the expiry time of all the messages sent passes.
When
the expiry time of all messages sent passes, the sender group state is removed.
x.z.5 Termination (t5):
----------------
Triggering
event: In an ordered group, a message expires before delivery:
Either
the message expires in an out-of-order sequence on the Receiver side, or a
non-acknowledged message expires on the Sender side.
Receiving
side:
Triggering
event for Termination: In an ordered group, a buffered message expires before
delivery.
For
state removal:
-
If the group does not have termination parameter, then it will be removed when
the maxExpiryTime for all received messages passes.
-
If the group uses GroupExpiryTime, then removal
criteria as defined in t1 will apply.
-
if the group uses GroupMaxIdleDuration,
then removal criteria as defined in t2 will apply.
Sender
Side:
Triggering
event for Termination: A non-acknowledged message expires on the Sender side.
For
state removal
-
If the group does not have termination parameter, then it will be removed when
the maxExpiryTime for all sent messages passes..
-
If the group uses GroupExpiryTime, then removal
criteria as defined in t1 will apply.
-
if the group uses GroupMaxIdleDuration,
then removal criteria as defined in t2 will apply.
--------end of
proposal to resolve r52 and r57