Preliminary Minutes WSRX TC Face To Face Meeting
(Sep 21, 2005) - AM
-----
1
Roll Call
<from Kavi>
2
Assignment of scribe(s)
Tom Rutt agreed to take minutes.
3
Agenda Bashing
Sanjay stated the agenda may have to be reshuffled for Day
2.
Gil: asked to make sure members would read his large
security posting before its discussion.
Paul C: we should use the f2f opportunity to have Gil
present the paper.
4
AI Review
#0002: OASIS Staff should fix typographical error in charter
of missing space between “produces” and “do” the next time the charter is
updated.
Owner: James Bryce Clark
Status: Still Open – waiting for response from Jamie
Assigned: 2005-07-06
Due: 2005-07-08
#0012: Chair took an action item to get a ruling from Jamie
on CVS repository usage.
Owner: Paul Fremantle
Status: Still Open – waiting for response from Jamie, The
chairs will follow up on getting details on the availability of a test server.
Editors stated this is urgent to complete soon.
Assigned: 2005-07-17
Due: ---
#0025: Propose a "namespace change policy" for the
schemas produced by the TC
Owner: Christopher Ferris
Status: Completed
Assigned: 2005-08-23
Due: ---
#0029: Editors to propose a resolution to proposed 02 for
voting at the next meeting
Owner: Anish Karmarkar
Status: Closed with email from Chris F.
Assigned: 2005-09-06
Due: ---
Action: Anish to provide proposal
for I003 closed
Action: Doug Davis to provide proposal on I010 closed
Action: Ashok to provide proposal
for I 24 open
Action: Stefan to raise new issue and use case – still open
5
New Issues since last conf-call
There are so many new issues Marc G did not have time to
prepare a summary for discussion.
6
Recap of Issues Process
Sanjay gave a presentation on the Issue process which has
been agreed by the TC.
Status:
- Active
- Editor-pending
- Editor-done
- Resolved
- Closed
Paul C: the editors need to tell the TC which issues are
incorporated in each working Draft. The
new Drafts have not included this information.
I suggest a lightweight process, where once the editors tell us that an
issue is incorporated, the issue list should be updated automatically with
label (editor’s done), with it put on the agenda to
ask for consent of the change as a result.
Martin C: If we can get people to formally verify an edit it
would be better.
Sanjay: It is not always easy to get volunteers to review
the incorporation of each issue revision.
Paul C: It seems that if we do not get such a volunteer we
should incorporate a timeout into the review process.
Anish: until now the editors have
reviewed each others work before posting the drafts.
Doug B: I do not see the need to separate resolved from
closed status. I would like to hear what
this separation adds.
Sanjay: if we skip resolved and go immediately to closed, we lose the formal review process.
Paul C: we need to know which issue resolutions are
incorporated in each CD. There is
advantage to know which issues are closed in each CD. That is an advantage to having this separation. It should not be closed until it is in a CD.
Chris F: everyone has the responsibility to review
incorporation of changes. Why is it not
enough to record which draft an issue resolution was incorporated into.
Umit: I need to know if we need
change bars between drafts.
Paul C: I prefer Changes be shown between WDs for the TC.
However CDs should have change bars to the preceding CD.
Anish: I would prefer two versions
be posted, one with and the other without change bars.
Chris F: sometimes changes are difficult to show in change
bars (such as major reorganizations).
7
Review of issues log and current status
Mark posted the issue list at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14604/ReliableMessagingIssues.xml
Paul C: none of the issues are marked as “done”. This needs to be fixed, so we know which
resolutions have been completed.
Anish: editors should indicate the
status of a done issue in the change log for each doc. The editor’ should send a not to the TC or
change the Issue list.
Anish: when an editor posts the
doc they should include in the email description which issues are incorporated
into that new draft, as well as in the change log in the draft itself.
Sanjay asked the editor’s team if they agree to this
proposal.
The Editors agreed to the proposal from Anish.
8
Update from the editors
Umit: I would like the TC to agree
to a change bar proposal.
Sanjay: can one of the editors make a change bar proposal to
the TC?
Paul C: the current PDF docs do not show change bars.
Changes between CDs should be shown.
Between WDs the change bars should
also be shown.
Tom R: the tool can be used to compare each successive WDs to produce WD change marks,
also the tool can compare successive CDs to produce CD change marks.
ACTION: Gil will write up a change bar proposal for both WDs and CDs to the TC.
9
Wed Morning Issues Discussion
11:00 (90 min) Issues 6, 8, 9 and 20 (related to DA)
9.1
Issue 020 Meaning of At Most Once DA
Tom: Issue 20 is a pacing issue. Depending on the resolution of this, the
sender may have to do something different when at most once is in place.
Tom: there are three interpretations of “at most once”
1 At most once means
that the sender will never retransmit a message, regardless of whether it is acknolweged by the destination.
2 The sender may
retransmit messages, but is not required to to so,
however the destination will not deliver duplicates
3 The sender must
retransmit messages, however the destination may drop
messages in times of resource saturation, but will never deliver a duplicate.
Jacques: the key
issue is whether the protocol operation can take advantage of the DA contract
in use.
Chris F: the design of the current ws-rm
protocol is for “at least once”. The
protocol will acknowledge everything it receives. However, using this protocol you can support
other DAs, such as At Most Once. I would
be concerned that we try to accommodate protocol changes. I say we go with interpretation 3.
Anish: the spec is not clear that
the protocol is “at least once on the wire”.
There are a few places in the spec which need clarification.
Gil: What Chris has
been saying needs to be captured early in the spec. The section on delivery assurances can easily
mislead the reader, if the protocol is first and the DAs are subservient to the
protocol. I believe Chris’s approach is
backwards, we could decide what DAs we want to support, and then have the
protocol be designed to do that.
Paul F: if we change the semantics of the protocol, we have
to seriously review this, due to interop problems.
Gill: what would the effects of the sender not
retransmitting be on the protocol? I
need to understand what problems this would cause to the receiver..
Chris F: the ack list would have
permanent gaps, and that would allow the size of the ack
message to grow without bound in very long sequences.
Action: Anish will propose text to
clarify in the current document the protocol is at least once, and that the DAs
are subservient to this protocol.
Jacques: I see the no resend as just another protocol
parameter. This might be to performance
issues. Maybe if you want at most once
you can tune the operation of the protocol.
Hamid: we need to clarify if at
most once is for the sender of receiver.
At most once, for me, is to hold for the receiving side. With regard to the must/may/or mustNot retransmit for the sender, if the sender does not
retransmit, it may not get thru the network.
The sender must retransmit, and it gets either an ack
or an error. With an error the sender
must retransmit.
Tom: what would happen if the policy parameter “resend
interval” is set to be very large, and the sender does not retransmit very often.
Chris F; In such a case the
protocol would be very slow.
Ashok: Is the contract between two
parties.
Paul C: Sometimes specs presume we know the design
principle. Sometimes it is not
articulated in the spec. However in this
case, the design principle of protocol should be explicity
states. E.g. X-query has no side
effects, but that is not explicitly stated.
Anish: If we do say something
about at most once deliver, with the protocol at least once at the wire level,
you cannot do any optimization on RMS side.
Thus it does not make sense to talk about at-most once in the spec at
all. Why do we talk about at-most once
at all.
Chris F: The source always has the option of not sending
messages, as long as it sends the correct sequence numbers for those sent. However sending a message without
retransmission is not reliable messageing. I do not see the need for such an
optimization.
Anish: Why even talk about “at
most once” at the receiving end, if the sender cannot optimize the
retransmission.
Paul F: we need to differentiate the name of what the
protocol properties are on the wire, and the DAs at the endpoints. The protocol is about what happens on the
wire.
Anish: if that is what we are
doing why do we talk about DAs. If we are just defining a
protocol.
Paul F: sending an ack for
something received, says you do not need it to be retransmissed.
Considerable discussion ensued on the operation of the
current protocol.
Bob F: Discussions about this type of contract I find
disturbing. This
protocol is passing something from one place to another, and get an indication
when the other has taken responsibility.
Such things as acking message which were not
received is counter to the intention of the protocol. We need to stay on track to the intended
primary use of the protocol.
Anish: do you mean that things like
Nack do not belong in the protocol.
Bof F: Things like sending acks for things which were not received will cause
incorrect knowledge by the sender.
Chris F: the NACK is an optimization of the protocol, added
at request of Tibco, where in a clean network where
the chances of loss are small. Take an
optimistic approach to only send nacks when you are
not receiving messages. It does not
change the protocol.
Vadim: The DA are
separate between source / rms, and rmd /destination.
The protocol is between rms and rmd .
Tom R: If we agree that the protocol is inherently “at most
once” then the use of the term “at most once” should be dropped. For the DA which Chris is speaking about (3),
if it exists the title should be changed to be something different than “at
most once”.
Gil: I agree that the term “at most once” is misleading if
it does not affect the sender behaviour. Perhaps the spec could clarify that “at most
once” is outside the scope of the specification.
Umit: I suggest we close the issue
with a proposal to clarify that the protocol is at least once. If someone wants to change
the protocol to affect other behaviors that is a separate issue.
Anish: I agree that there are two
separate issues. The editors already
took an action to clarify that the protocol is at least once on the wire. This issue regards what we want the
correspondence to be between protocol and the DAs. This is not an editorial issue.
Jacques: I can agree on Paul F proposal to not mix da terms with protocol terms. The current protocol does not support “at
most once”. I suggest we either put “at
most once” out of scope of the spec, or change the protocol to support “at most
once”.
Chris F: the DA has nothing to do with what goes on the
wire. At least once on the wire is what
I said, but it is not a DA, .At most once on the sending side means that the
RMS does not need to transmit each message it is handed by the sending app, but
once it does send a message it must retransmit until it receives an ACK. At most once on the receiving side means that
the sender can drop a message, even if it has been acked.
Action: Abbie to raise new issue
to have state diagram in the spec.
Bob F: I move we accept proposal submitted by Chris Ferriis message 121, Rebecca seconded. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00121.html
There was discussion on why the discussion did no start with
this formal proposal.
Serge: At most once
and at least once seem odd for Delivery assurances. Reliability means everything must be
delivered to the application, thus “at most once” does not belong in the
protocol. I would recommend we drop “at
least once’ and “at most once” and keep only “exactly once”.
Paul F: these terms are confusing. If we used the term
“reliable”. At most once means
duplicate elimination. The concept of Idempotency is avoided with duplicate elimination.
Gil: I would like to propose an amendment. The proposal on the table has use of the
term “as defined below”. I propose an
amendment to remove “at most once” from the list as defined below.. Seconded
by Tom Rutt.
Chris F: I always intended the DA “at most once” to be between
the RMD and destination.
Motion before amendment
“
At line 162 of the WS-ReliableMessaging spec, delete the following
paragraph:
WS-ReliableMessaging provides an interoperable protocol that a Reliable
Messaging (RM) Source and Reliable Messaging (RM) Destination use to provide
Application Source and Destination a guarantee that a message that is sent will be
delivered.
The guarantee is specified as a delivery assurance. The protocol supports
The endpoints in providing these delivery assurances. It is the responsibility
of the RM Source and RM Destination to fulfill the delivery assurances, or raise an
error. The protocol defined here allows endpoints to meet this guarantee for the
delivery assurances defined below.
and replace it with the following text:
The WS-ReliableMessaging specification defines an interoperable protocol
that enables a Reliable Messaging (RM) Source and Reliable Messaging (RM)
Destination to ensure that each message transmitted by the RM Source is
successfully received by an RM Destination, or barring successful receipt,
that an RM Source can, except in the most extreem circumstances,
accurately determine the disposition of each message transmitted as perceived by the
RM Destination, so as to resolve any in-doubt status.
The protocol allows the RM Source and RM Destination to provide their
respective Application Source and Application Destination a guarantee that
a message that is sent by an Application Source will be delivered to the Application
Destination.
This guarantee is specified as a delivery assurance. It is the responsibility of the RM
Source and RM Destination to fulfill the delivery assurances on behalf of
their respective Application counterparts, or raise an error. The protocol defined here
allows endpoints to meet this guarantee for the delivery assurances defined below. However,
the means by which these delivery assurances are manifested by either the RM Source
or RM Destination roles is an implementation concern, and is out of scope of
this specification.
“
Paul C: the issue is not worded in the terminology used in
the spec. The spec talks about
senders. We could improve our common
understanding. This motion on the floor
clarifies the wording on the spec.
Gil: the second para leads me to
believe that the rm source has something to do with
at most once. If it does not care it
might not resend a non acked message. It seems to apply that the responsibility for
DAs exists on both sides of the transmission.
Anish: Chris F proposal asserts
that the protocol is on the wire, and DA are contracts
on either side of the wire between rm and its
user. What if we allow rms and rmd to optimize the
protocol based on the DAs. Do we allow
the rms and rmd to agree on
DA with handshake, allowing them to optimize operation of the protocol based on
this agreement?
Chris F: even MQ does not guarantee AT LEAST ONCE. There are cases where “bad things” happen at
the receiving end.
Gil: What does the spec describe. It describes a protocol. However the protocol is within the respect of
the DAs which are supported. The
terminology of the DAs seems to be providing problems.
Vote on amendment:
Ammendment text::
Delete line 151 to 153 from the spec.
4 Yes
21 No
11 abstain.
Amendment fails.
Break for 15 Minutes:
Amendment by Umit,
seconded by Chris F.
“
The WS-ReliableMessaging specification defines an interoperable protocol
that requires a Reliable Messaging (RM) Source and Reliable Messaging (RM)
Destination to ensure that each message transmitted by the RM Source is
successfully received by an RM Destination, or barring successful receipt,
that an RM Source can, except in the most extreem circumstances,
accurately determine the disposition of each message transmitted as perceived by the
RM Destination, so as to resolve any in-doubt status.
In addition, The protocol allows the RM Source and RM Destination to provide their
respective Application Source and Application Destination a guarantee that
a message that is sent by an Application Source will be delivered to the Application
Destination.
This guarantee is specified as a delivery assurance. It is the responsibility of the RM
Source and RM Destination to fulfill the delivery assurances on behalf of
their respective Application counterparts, or raise an error. The protocol defined here
allows endpoints to meet this guarantee for the delivery assurances defined below. Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance. However, the means by which these delivery assurances are manifested by either the RM Source or RM Destination roles is an implementation concern, and is out of scope of
this specification.
Note that the underlying protocol defined in this specification remains the same regardless of the delivery assurance.
“
Martin C: the protocol includes more than the wire messages,
it also includes the state machine.
Chris F: this spec only covers the protocol between RMS and
RMD. It does not include the interaction
between RM processors and their users.
Sanjay: my understanding is that the underlying protocol
does not change.
Paul F: what about observable on the wire behaviour is not affected.
Tom R: what Chris F wants is the protocol to keep the
mandatory behaviour that the rms
must retransmit messages that are not acked. This is part of the protocol definition.
Chris F: I speak in favor of the motion. The observable behaviour
of what flows on the wire does not change with the DA.
Jacques: what is the meaning of the note. The protocol operation changes if the policy
parameters are manipulated.
Bob F: the protocol is an algorithm, It may react to parameters and policy
statements.
Tom R: the note is unstable. It is unnecessary, and could
change if we add da parameters in the future.
Umit: if the protocol changes we
would change the note at that time.
No objection to approval of amendment.
Tom R: If we accept this resolution, the definition of “at
most once” still needs to be clarified to explain what it means for the sender and the
Receiver. Would such a clarification
issue be ruled out of scope.
Paul F: It would be acceptable under our TC rules.
Anish: I think we need more discussion before we
vote on this resolution. I believe that
simple changes to the protocol would accommodate all the DAs in the list more
appropriately.
Serge: Is this wording better than what is there?. I believe it
clarifies what the intent of the existing spec is.
Chris F: I think it is important to resolve this. This should close this issue. It results in a simple protocol that is
always the same, independent of DAs on each end. This is important. My customers only want “at least once”, and
do not give a hoot whether “at most once” is optimal or not, because they only
want reliable messaging.
Bob F: I would like to speak for calling this motion and going to
vote. We have language to address the
issue as raised. There may be other
issues that arise later to accommodate use cases we view in scope. It is the responsibility of members to raise
use cases into scope.
Chris F: I move to call the question, Bob F seconded.
Vote on calling the question:
22 yes
10 no,
4 abstain.
Vote on amended motion:
27 yes
13 no
0 abstain
Resolution: Close issue 20 with amended proposal.
9.2
Issue 9:
Declaration of QoS policies core
Description
In the
specification, the delivery assurances are part of a private
contract
between the RM destination and the application destination.
They are not
published and they are not visible to the "outside" world
- i.e. to the source.
Justification
"I certainly
CAN see a use case for giving the client the visibility as to the QoS capabilities
of
the service endpoint and using that information to decide whether it wanted to
use that
service
or select another that offered the desired QoS."
Proposal presented by Chris F as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00124.html
The issue has to do with providing
the RMD with the capacity to advertise its DA QoS. It
is somewhat related to issue i024, raised by Ashok.
However, I don't believe that the resolutions need to be tied to one another.
Basically, there is currently no
specified means of declaring the DA applied at a given RMD endpoint. It has
been
suggested
that the RMS (or AS) might have a vested interest in knowing, a priori to
establishing a Sequence with
an RMD
what DA would be applied. For instance, it may require that the messages be
processed InOrder. If the
RMD were not enforcing InOrder DA at the RMD, then the source endpoint might
choose not to engage with that
endpoint.
I would propose that one way to
resolve this would be to define RM policy assertions that specify the DA.e.g. a psuedo-schema for this
would be as follows:
<wsrm:RMAssertion>
<wsrm:DeliveryAssertion
mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ... >
...
</wsrm:DeliveryAssertion>?
...
</wsrm:RMAssertion>
Thus, an endpoint could declare its
DA QoS in the policy statement
associated
with the endpoint.
Thoughts?
Paul C: this proposal does not have to say where this claim
is attached, to allow us to close the issue?
Anish: Where it is attached in the
WSDL is not part of this proposed text.
That is part of issue 9.
Ashok: which messages would this affect. Which
messages would be impacted by this resolution.
Gil is that not what issue 24 is about.
Claus: I do not think
the serialization of the assertion is part of this resolution. I would like to focus on whether this is
needed, before we do the detailed design of the assertion.
Asir: This appears to be a parameter. How many assertions are intended.
Chris F: One is attended.
Gill: There is a use case behind this in the Use case
document.
Chris F: There are side issues, on granularity of where it
is asserted, as well as which side is affected.
I propose that we constrain the declaration on qos
policy to decide on whether we have the parameter defined. I also did not intend that the text above be
a formal proposal, but an opening to discussion. I can come up with detailed text after lunch
for voting, if we agree to the intent of this qos
parameter.
Paul F: we already have issues on where QOS policies are
attached.
Anish: I agree with Chris, and
agree it should be included as an assertion.
Paul C: I am not sure of the use cases that justify a
parameter for things which are only relevant to the receiving side
implementation. I need convincing that
there is a use case for this.
Jacques: this is a proposal for the qos
for DA. It is legitimate in that
sense. However where it is attached
should be left as further discussion.
Are we asking for a formal description of a DA, or are we also asking
that this be able to be published by source.
Martin C: I cannot understand why anyone would oppose this.
Umit: The use case is we need to
enable a receiver to indicate the required DA for a receiver.
Paul C: I do not want my web service to have search for this
level of detail. It can be a private
contract between the rmd and its receiving user.
Gil : use case 5 has a publish
scenario. The Client may not be capable
of dealing with a given QOS level.
Paul C: then under this proposal a receiver does not have to
assert this qos policy?
Several members responded in unison: its use is optional.
Chris F: The delivery assertion claim is stating “this is
what I am doing over here”. It does not
say how it is implemented. It provides
the other side with an understanding of what is going on at one side.
Doug B: These DAs are not part of the RM protocol was just
decided. I am not sure why this
attribute belongs in the part with the policy.
Also, if one indicate a service which only supports idempotent
operations, is at most once acceptable.
Chris F: Is the RMD actively insuring a delivery
assurance. Or is it happening between
the behaviour of the RMD and its receiving
application.
Umit: I do not understand why we
need to clarify use cases for such a simple concept.
Clarification: it is feasible to just assert “At most once”
Tom R: yes, that would affect behaviour
between the source and RMS, or the RMD and its receiver.
Paul C: if this is only used at the destination, how useful
is it. If some people see it as useful,
I can concede on this point.. However I would like to
see the actual text changes.
Paul
C: there are 6 combination there.
Does the destination support only one?
What if the destination supports all 6?
Chris F: the assertion is meant to pertain to one service
instance.
Umit: ws
policy would allow one to send more than one of the values.
Paul F: but that would be confusing to the user.
Paul F: Chris F agreed to a more concrete proposal over
lunch.
12:30 (60 min) Lunch