[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary Minutes of WSRM TC meeting 4/13/04
The prelim minutes are attached. Please post any changes to the list before friday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: firstname.lastname@example.org; email@example.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
Preliminary Minutes of WSRM TC
Conference Call –
(UTC - 5)
0 Draft Agenda:
Draft Agenda to WSRM TC Conference Call
1 Roll Call
2 Minutes Discussion
2.1 Appointment of Minute Taker
2.2 Approval of previous meeting minutes –
3 Status of Action Items
4 Discussions of Issues and editorial comments
5 Discussion of FAQ for WS-Reliability
1 Roll Call
Meeting is quorate.
2 Minutes Discussion
2.1 Appointment of Minute Taker
Tom Rutt will take minutes.
Minutes will serve to record issue resolutions.
2.1 Approval of previous meeting minutes
Jeff T moved to approve 4/06 minutes. Bob F seconded.
No Opposition, Minutes approved
3 Status of Action Items
Sunil and Jacques will provide a proposal on retry parameters to the group before the end of the public review period. – still open
In Two subsections for 6.3. Sunil took action to reword “no content” text. - closed
Jacques took action item to propose new FAQ text for the ws-reliability features. - open
why does the spec have a different name than the TC.
Marc G agreed to propose a new question with new answer to clarify the matter. - open
Jacques took action to clearly state what the relation with ebMS is. He agreed to draft a question with an answer. - open
Need a general question on how can ws reliability be used with other ws reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.
Tom Rutt agreed to send a suggested question and proposal out. - open
Sunil and Jacques will propose the detailed changes required to remove status=start from spec. - closed
If the request header has no message id element, how do you send a fault if there is no group ID. Group ID is mandatory in the reply.
Sunil and Jun took action item to come up with detailed replacement text for this concern. They will describe the various edge cases. - closed
Item added after posting:
Item added after posting:
Action editors-1 - Pending
Marc G and Doug B to updated issues list to reflect agreements in CD .992. - open
4 Discussion of Issues and editorial Comments
4.1 Clarification of Section 6.3
· Action 033004-2
Sunil: Changed the section headers to reflect the callback for the poll response.
Two subsections created.
Put in new text.
Doug: we seem to have gone from the poll request for things behind firewall, to something else. This new asynchronous polling request seems odd to me.
Sunil: This was agreed to.
Doug: I still do not understand rational for this. I will review before I re-open the issue.
Alan: is the behind firewall case the main case.
Sunil: the other use-case of poll is to avoid retries with large messages. The JMS transport binding case needs asynchronous poll.
No disagreement on these proposed changes to 6.3.
Sunil: there are some minor editorials on section 6.2. I will send a mail on this one.
Alan suggested compiling a list of page changes then voting on the entire set of changes on one motion.
Tom: agreed that this is the way to do it.
4.2 Group Start Clarification
· detailed updates entailed by removing @status
Title: detailed updates entailed by removing @status
Detail of changes in the draft, when replacing @status with @last, and adding more details on group sequence number:
-Example 1: remove @status="Start"
-Example 5: remove @status="Start"
-sec 188.8.131.52: Line 697, replace @status with @last.
-Example 6: remove @status="Start", remove @status="Continue"
-Table 3: replace @status with @last (which should be of type boolean).
-sec 184.108.40.206: Subsection (3) on Number attribute: add after Ln737:
"The Number attribute MUST have a value between 0 and 18446744073709551615 (maximum value for XMLschema unsignedlong). As the Number value is incremented of 1 for each message submitted to the Sender RMP, once the value reaches the maximum the group is terminated (see Section 5). "
-sec 220.127.116.11: Subsection (4) on Status attribute: replace (line752-762) with:
(title)(4) Last attribute:
This attribute is used to mark the end of a group, when its last message is known from the Sender before the message is sent. When this attribute is present, its boolean value has the following meaning:
- False: Indicating the message is not the last message of the group, or is not known to be the last message of the group. (default value)
- True: Indicating the message is known to be the last message sent within a group of messages.
-Table 16 (InvalidMessageParameter entry): replace the case with @status (-> @last)
-sec 5.1.1, line 1118. (handled with new proposed wording for Section 5)
-sec 5.1.2, line 1127. (handled with new proposed wording for Section 5)
-Sec 5.1.3, Termination T3, T4. (handled with new proposed wording for Section 5)
-Example 10: remove @status="Start"
-Example 12: remove @status="Start"
- change schema: remove @status and add @last.
· Re: [wsrm] detailed updates entailed by removing
Schema changes for this would be as follows:
- Remove SequenceNumberStatusType
- Remove the 'status' attribute definition in SequenceNumberType
- Add a new attribute by name 'last' of type xsd:boolean
and with default being 'false'
So the new definition of SequenceNumberType will be:
<xsd:attribute name="number" type="xsd:unsignedLong"/>
<xsd:attribute name="last" type="xsd:boolean"
<xsd:attribute name="groupExpiryTime" type="xsd:dateTime"
<xsd:attribute name="groupMaxIdleDuration" type="xsd:duration"
No opposition to these changes.
This will get incorporated into the consolidated changes document.
4.3 Missing Message IDs on request
· Action item 040604-2 - Proposals
Here are proposals on Action item 040604-2 by Sunil and Jun.
We should remove the first bullet item for InvalidPollRequest
in Table 16 (Section 4.5.1)
> 1. When the required RefToMessageId element is missing
since the receiver cannnot send fault back without receiving
We should add the following sentences before the example 9
Note that there MAY be cases where in the Receiver RMP MAY not be able
to send fault messages with invalid message headers such as:
- The replyTo attribute is missing or invalid when it is required such
as for Callback and Async. Poll cases
- The MessageId element is missing for Request element.
- The RefToMessageIds is missing for PollRequest element.
Tom: why use the word MAY in this case.
Sunil a vendor may send some kind of generic fault in this case.
Agreed to change to : “ the Receiver RMP is not able to”
We should add the following example after the example 9
Example 10 Fault Message for PollRequest message
If PollRequest element in Example 7 were missing soap:mustUnderstand
attribute, the InvalidPollRequest fault MAY be sent as follows.
<?xml version="1.0" encoding="UTF-8"?>
<ReplyRange from="0" to="5" fault="InvalidPollRequest"/>
<ReplyRange from="15" to="20" fault="InvalidPollRequest"/>
<ReplyRange from="713" to="6150" fault="InvalidPollRequest"/>
Sunil: I agree with this proposal.
No objections to accepting this proposal.
4.4 Aborting Ordered Delivery
Left open from discussion Last week’s meeting of Alan W Email:
[wsrm] Comments on CD 0.992
The current text implies a receiver can decide to abort an ordered delivery.
Need to clarify the semantics of aborting ordered delivery.
If allowed, it has been suggested that a specific fault code be defined for this case.
Tom: at least 2 cases:
case a) a prior message expires before it is delivered, no subsequent messages will ever get delivered.
Jacques: the spec is silent on what the Receiving RMP does in this case. The reason we remained silent, is that ordering goes along with guaranteed delivery. It knows it will not get acks for the aborted sequence, since it knows it did not get an ack for the expired message. The sender knows that the sequence is broken in this case.
Alan: I concur that the sender can induce that in this case.
Case b) the receiving rmp runs out of resources to continue processing that ordered sequence:
Alan: current spec in, Lines 563 - states It MUST not deliver the message. But it does not explain “too much effort”.
Jacques: from an editorial perspective we have to clarify this text.
A fault for PermanantProcessingFailure could be used in this case.
Alan: Another possibility is to have, in this case, a more definitive message.
Doug B: This error may give info earlier, but it is an optimization for a minimal use case. It can just drop the messages on the floor.
Alan: I disagree. The sender may have to wait a long time to deduce something is wrong on receiver.
Tom : It will involve useless retransmissions.
Alan: This is what I meant, he as to wait for the max number of retries to get knowledge of this problem condition. I do not see this as an optimization.
Doug: I was saying that the individual message getting lost is already handled by errors that the receiver may send. If the receiver corrupts its entire sequence information, it may not even know the condition exists.
Tom: How about the Receiver May respond with the permanentProcessingFailure error in case b).
Doug: I see no reason to call out the special case in our text.
Tom: Perhaps we should take out the text Alan is concerned about.
Alan: I assumed this text is providing that the receiver is entitled under its own criteria and discression to give up on ordered deliver due to local conditions.
Jacques: That is what the text is put there for. On the editorial side the text was there to remind us that the expiration case is not the only reason to break a sequence. Any other feature has the same kind of resource persistence possibility.
Tom: is it not enough to have the PermanantProcessingFaulure as a fault the rmp may send.
Jacques: The sending RMP cannot rely on faults. It can only rely on the fact that the ack was not received.
Tom: There is a Difference in opinion on whether the fault is an optimization. The protocol will work if the faults are not sent, however the sender will have to wait a long time (until expiry of messages) to know the sequence is aborted.
Jacques: The poll request could be used in such a case to get the knowledge that the message has not been faulted and has not been delivered.
Jacques: What would a poll response look like when the send inquires about a sequence which has been aborted.
If the poll response states they have been faulted that would be enough.
Tom: If the receiving rmp has lost knowledge of the group, what is the result of the poll response.
Jacques; in such a case the response for that groupID is empty. The general rule is the receiver is not supposed to get status info back on messages which have expired.
Tom: thus the sender has to be able to deal with no information back on the messages in the aborted group. The ultimate knowledge comes when the messages expiry before an ack or fault is received.
Jacques: This is an extreme case. The more typical case is the group has been aborted for local reasons.
Alan: if poll request is sent, the receive should let the sender know all messages which were received.
Tom: It will do that already.
Tom: the aborting of a sequence for local reasons is a rare event. The rarity of this event means we do not have to be concerned about how long the sender has to wait.
Tom: Why condone this failure mode, the current text sounds like this behaviour is an allowed part of the protocol.
Alan: the text states that this can happen.
Jacques: when such a thing happens, I.e., the message is too big for the storage on the receive side. We would use permanent processing failure in such a case. Why cannot we have the same for an aborted sequence.
Jacques: the sequence might get cut for many reasons
Tom: but is this not a failure case, the receiving RMP is no longer operating within the protocol bounds.
Jacques: we have not quantified unexpected quality of service.
Jacques: Nothing states that this is disallowed behaviour, as long as what you deliver is in order.
Bob F: we have not specified any max buffer size for a receiver to use for a group. Taking the case of using 10 as the max, how does the sender know the receiver has hit that resource limit. A resource limit has been hit, if we remain silent we admit the multiple retries. I come down on the side of the Receiver MUST send a failure in such a condition.
Jacques: if callbacks are not available. What happens/
Bob F: on request response case if the transport connection goes down the fault will not be delivered.
Tom: The MUST seems too strong for cases when the transport connection has failed.
Alan: there are two distinct issues when the receiver has aborted for local reasons:
1) Should he send a fault : No, Maybe, Must
2) The response to a poll in this case should be clarified.
Take this to the list.
Tom: part of this discussion is what happens if the rmp does not support callback or polling, and the transport connection is not available to send the fault in the response reply pattern.
Bob: you have a couple of mechanism to find this out.
Tom: we do not have a concept of message state in a sequence. For polling this might be important.
Ø Jacques will send an email to initiate email discussion on poll response for fault conditions
4.5 Group Termination conditions
· html for Jacques proposal
Tom asked if we can consider the group termination work of Jacques, posted last week, as agreed.
Nobody opposed, it is considered agreed.
5 Frequently Asked Questions:
Bob F: JMS is identified as a transport protocol. It is an API, not a transport provider.
Sunil: JMS is not a transport protocol. People use it as if it were an underlying transport in closed enclaves.
Bob F: just delete this from the list.
Mark Peel: Replace with message delivery protocols.
Agree to change this question
The remainder of the faq will be discussed at future meetings.
6 Discussion of Applying changes to CD .992
Sunil we have agreed on aset of changes at each meeting since the CD was approved.
Ø Action: Iwasa to action to consolidate all the agreed comments in text with change bars against CD .992. A list indicating which meeting minutes’ agreed changes were applied should also be included.
Ø Action: Sunil took action to consolidate all agreed comments on Schema.
We could agree on these changes at the F2F.
Bob F moved we adjourn at .
Meeting Adjourned at .