Preliminary Minutes WSRX TC Teleconf
Dec 01, 2005 –
Tom Rutt agreed to take the
minutes.
From Kavi,
Meeting is Quorate
2
Review and approve of Agenda
Agenda:
1) Roll Call
2) Review and approval of the
agenda
3) Approval of the Nov 17, 2005
meeting minutes
4) AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
5) Planning for Sunnyvale F2F
a> Dial-in facility
b> Working Drafts for the F2F discussions
6) New issues since last conf-call
Watch for Marcs email
7) Issue Discussion:
a> i066
Remove LastMessage
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i066
b> i064 Create Sequence Refused Fault is too
restrictive
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i064
c> i070 Receive is defined twice in
wsrm-1.1-spec-cd-01
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i070
d> i057 Classification of References (normative
vs. non-normative) is needed
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i057
e> i060 Definition for "Reliable
Message"
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i060
f> i061 Anonymous AcksTo
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i061
g> i058 State Transition Table
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i058
8) Any other business
Marc G asked that I 057 should get an owner, since there
have been no discussions.
Marc G attack 64 and 70 before 66.
Editors Umit take Action item to
come up with proposal for I 057.
3
Approval of the previous meeting minutes
http://www.oasis-open.org/committees/download.php/15547/MinutesWSRX-111705.htm
Tom R moved, Bob F seconded to approve 11/17 minutes
§
No objections, Minutes of 11/17 approved.
4
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0031: Open two issues around cancel / fill proposal and use
cases
Owner: Stefan Batres
Status: Open
Assigned: 2005-09-21
Due: 2005-09-29
Leave Open
--------------------------------------------------------------------------------
#0052: Need a bridge for the Sunnyvale F2F
Owner: Jacques Durand
Status: Open
Assigned: 2005-11-07
Due: ---
Leave Open
--------------------------------------------------------------------------------
#0053: Editors team to produce a RDDL document to be placed
at the namespace URIs (3).
Owner: Gilbert Pilz
Status: Open
Assigned: 2005-11-10
Due: 2005-12-08
Leave open
--------------------------------------------------------------------------------
#0054: Editors team to identify where the second definition
of receive came from.
Owner: Umit Yalcinalp
Status: Open
Assigned: 2005-11-10
Due: 2005-12-01
Closed, Doug sent to mail list.
5
Sunnyvale
F2F Planning
Planning for Sunnyvale
F2F
5.1
Dial-in facility
Jacques: The meeting room will have the ability to dial in
to a bridge.
Sun agreed to sponsor a ˝ day of the conference.
Jacques: since we need several sponsors, can you give times
you want dial in connections.
Sanjay: how about 4 time windows, each ˝ day long. We should continue on the email list for this.
5.2
Working Drafts for the F2F discussions
Umit: The editors will take all of
the issues in the editor’s pending list, and will get a new stable WD by next
week’s concall.
Sanjay: Will this be before the next Conference Call.
Paul C: I thought we would have it by today.
Umit: the editors are asking for a
delay for a week.
Paul C: Perhaps we could have one earlier which is less
complete. I would have preferred a week
lead time before the f2f.
Sanjay: the CDs are the major voted documents.
Doug D: I will try to get the core spec out by Monday.
Paul C: there are 15 outstanding issue resolutions. I want to have sufficient time for review. Monday is better.
Sanjay: would that include issues resolved today.
Umit: I cannot make the promise
for the policy spec. That will have to
wait until next Thursday.
Anish: I can help with the policy
document.
Sanjay: let the editors try to get the core spec by Monday and
the policy spec as early as possible before Thursday.
Mark G: I would like to know when the f2f topics will be
selected. We also need to talk about interop at the F2f.
Sanjay: TC members should send their inputs to the f2f
agenda, so we can have a draft agenda by next week call.
6
New issues since last conf-call
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00242.html
-------------------------------
6.1
Proposed-01
Title: Semantics of offered Sequences
Origin: Matt Lovett
http://lists.oasis-open.org/archives/ws-rx/200511/msg00205.html
Description:
The current specification explains how a RM Source may offer
a Sequence
to the RM Destination, but does not
explain what this really means. It
can be read as a protocol
optimization, with no deeper semantics. It
could alternatively be assumed that
the 2 sequences are linked in some
way - perhaps application replies
are expected to travel back on this
sequence (and no other); perhaps
the offered Sequence is supposed to
close/terminate when the other
Sequence closes/terminates. Someone might
even assume that offers will only
be made for request-reply
applications, wheras
the absence of an offer implies fire-and-forget
messaging. (I am not advocating
this interpretation!)
We should clarify the specification, so that the reader is
fully aware
of the semantic import of offering
(or accepting the offer of) a
Sequence.
Justification: The capabilities in the spec should have
clear semantics
Target: core
Type: design
Proposal:
I think that we should clearly state that there is no deep
semantic to
offering a Sequence, it is merely a
protocol optimization. I think that
the right way to explain that is to
add a note into the text that
introduces offer, saying that the
use of offer is semantically identical
to not using offer, and then
initiating another Sequence between the two
endpoints. Describing this is a
little tricky, as we don't want to talk
about creating a Sequence from RM
Destination to RM Source.... and we
don't have a term in the spec for
the middleware layer that implements
RM in either direction. Here is a
concrete proposal:
Add the following as a continuation of line 256 (using line
numbers from
wsrm-1.1-spec-wd-06.pdf):
Note, offering a Sequence within the <wsrm:CreateSequence> element is
simply a protocol optimization.
There is no semantic difference between
offering a Sequence, and choosing
not to offer one and subsequently
creating a Sequence to carry
messages from the Ultimate Receiver to the
Initial Sender.
Related issues: None
§
No objections to accepting proposed 01 as a new
issue., with Matt as owner
6.2
Proposed-02
Title: How does a RM Destination reject an offered Sequence?
Origin: Matt Lovett
http://lists.oasis-open.org/archives/ws-rx/200511/msg00206.html
Description:
Section 3.1 lines 254 - 256 in wsrm-1.1-spec-wd-06.pdf says:
<wsrm:CreateSequence>
MAY carry an offer to
create an inbound sequence which is
either accepted or rejected in the
<wsrm:CreateSequenceResponse>.
However, there is no way to reject the offered sequence
without faulting
the entire CreateSequence
message, as lines 348 - 352 also say:
/wsrm:CreateSequenceResponse/wsrm:Accept
This element, if present, enables an RM Destination to
accept the offer
of a corresponding Sequence for
the reliable exchange of messages
transmitted from RM Destination to RM
Source. This element MUST
be present if the corresponding
<wsrm:CreateSequence> message contained
an <wsrm:Offer>
element.
I believe this is inconsistent. We should either define how
a RM
Destination can accept an inbound Sequence while rejecting
the offer, or
adjust the text in lines 254 - 256
to say that it is not possible.
Justification: The specification should be consistent.
Target: core
Type: design
Proposal:
As noted above, I can see 2 alternatives. I believe the way
to go is to
say that it is not possible to
reject an offered Sequence without
rejecting the entire CreateSequence message.
Reword lines 254 - 256 to read:
<wsrm:CreateSequence>
MAY carry an offer to
create an inbound sequence which is
then accepted in the
<wsrm:CreateSequenceResponse>.
If the RM Destination is unable to accept
the offered Sequence then it MUST
respond with a CreateSequenceRefused
fault.
Related issues: none
§
No objection to accepting proposed 02 as a new
TC issue, with Matt as owner,
6.3
C – Bob F new issue, Lost Terminate sequence
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00244.html
§
No Objection to accept proposed c lost terminateSequence as a new issue with Bob F as owner
6.4
D Bob new issue 2
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00245.html
§
No objection to accepting d as new issue with
Bob F as owner.
6.5
E – Anish new issue
http://lists.oasis-open.org/archives/ws-rx/200512/msg00011.html
§
No objection to accept e as new issue, with Anish as owner.
7
Issue Discussion:
7.1
b> i064 Create Sequence Refused Fault is too
restrictive
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i064
Umit explained the issue. She suggested arbitrary details to be
included.
Marg G moved to accept proposal
for issue 64. Doug D seconded.
§
No opposition, issue 64 closed by incorporating
proposal.
7.2
c> i070 Receive is
defined twice in wsrm-1.1-spec-cd-01
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i070
Doug D explained that he fixed this in the latest draft.
Doug D: moved to close issue 70, since it has been resolved
by editorial removal of the redundant definition. Seconded by Mark.
§
No objections, issue 70 closed by editorial
removal of redundant definition in next draft.
7.3
a> i066 Remove LastMessage
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i066
Doug D reviewed the status. Anish stated that
the last message marker can be used for queue management, but I do not agree
that this is an important use case.
Paul C: I have noticed several threads on this issue. How do you propose to resolve this issue.
Doug D: to remove the last message mechanism from the
protocol.
Paul C: can one of the proponents explain why it was there
in the first place.
Steve W: the new close semantics make the lastMessage feature obsolete.
Doug D: I think last message is useless even without close
sequence.
Tom R: removal simplifies the state machine considerably.
Anish: What I was thinking about
was that the last message marker gives the RMD knowledge of the range of
sequence numbers that will be in the sequence. I was looking at what sort of resources could
be freed up with this knowledge. I do
agree that this is possibly a use case that is not that important, or that other
mechanisms can alleviate this problem. This
issue becomes very minimal if terminate Sequence is given a response. I was worried about a sequence without expiry
time and which had the TerminateSequence message
lost. Given all this I will not push back
on removing lastMessage Feature, since its utility
may be marginal.
Jacques: Having introduced closedSequence
operation allows removal of one use case for the lastMessage
mechanism. So I believe the lastMessage is redundant.
With fixing terminateSequence, I believe we
can remove lastMessage.
Bob F: we do not support retention of lastMessage.
However we propose that in a close
sequence, an optional lastMessage number be provided.
Doug D: could this be opened as a new issue, because I do
not see how it is necessary.
Bob F: I could agree to add this as a new issue.
Anish: I am not sure how adding
last Message to close will help. Close
is to close the sequence, to stop delivering anything it has not delivered yet.
With that semantics, how does lastMessage help.
Bob F: I can see an optional point where communication of lastMessage Number is send from RMS to RMD. We will hammer on this. We agree to deal with this as separate issue.
Jacques: I am not convinced that last message in close
sequence has utility, if the RMS can clearly terminate sequence.
Doug D moves to close issue 66 by
removing lastMessage feature, Seconded by Matt Lovett.
§
No objection, issue 66 closed by removing lastMessage Feature.
Move issue to pending.
7.4
d> i057 Classification
of References (normative vs. non-normative) is
needed
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i057
Action item given to Umit
to provide a proposal.
7.5
e> i060 Definition for
"Reliable Message"
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i060
1- Add a terminology entry. It could
be:
Reliable message: a message submitted
by the Application Source to an RM Source via the "Send"
operation, for
transmission over the protocol defined in this specification.
2- In 3.1: associate the main protocol
requirement (Sequence element) with the definition of
"reliable
message" instead of with a vague requirement of being subject to some DA:
Replace:
"Messages for which the delivery
assurance applies MUST contain a <wsrm:Sequence>
header block."
With:
"Reliable Messages MUST contain a
<wsrm:Sequence> header
block."
(DA and protocol being in fact
separately defined, DA should now more abstractly mandate the use of
"reliable messages" if we
still want to pre-req one to the other.)
Jacques: this is mostly an editorial issue. There are several sentences which use this expression, however we do not have a clear definition for
this expression. We have one proposal
for definition.
Chris F: the draft does not define the term because it is
implied. There is no such thing as a
reliable message. It is a bad term. There is a message which is delivered
reliably.
Jacques: transferred reliably needs to be defined better. We could state it to be a message with a sequenceElement in it.
Sanjay: do you have a preferred definition.
Jacques: I prefer to define a reliable message as one which
has a sequenceHeader bloc.
Paul C: I do not hear a concrete proposal.
Jacques I propose to add entry to terminology section:
“
Reliable transmission – transmission of message which
contains wsrm:sequenceHeader.
“
Chris F: we should look at the current uses of the
term. The phrase “reliable message”
could be changed instead of having to define the term officially. I suggest replace in 2.3 invariants substitute
“reliable message” to be “message to be transmitted reliablty”
Jacques: If we do not define reliable message we should
replace the usage of that term, as suggested by Chris. However, I am concerned that we need to have
precise definitions of what messages are the objects of the reliability
protocol. The clearest way to do this is
to provide a precise definition.
Jacques: I do not think we are ready to close this issue
today.
Chris F: I propose the change 2.3 invariant to
“
The
RM Source MUST assign each message to be delivered reliably a message number
(defined below) beginning at 1 and increasing by exactly 1 for each
subsequent message to be delivered reliably
“
Matt Lovett: I like Chris F proposal, I move to accept
it. Chris F: Second the motion to change
2.3 invariant text .
Jacques: can Chris make it clear if this totally removes
reliable message being used from the text.
Umit moved to table the motion,
seconded By Steve W.
§
No objections to table the motion. Motion is
tabled.
Doug D: does someone have the slides used in the document.
Marc G: ping me offline about this.
7.6
f> i061 Anonymous AcksTo
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i061
After the first paragraph in the SeqAck section (currently section 3.2)
add something like:
Sending Sequence Acknowledgement Header
blocks back to the AcksTo EPR could have an impact on
current
SOAP implementations. While this specification discusses the
ability to add, or piggy-back, a Sequence
Acknowledgement Header block to a
message that is targetted to the AcksTo
EPR, the precise mechanism
for
determining when any particular message is targetted,
or not, to the AcksTo EPR is out of scope
for this
specification. However, WS-Addressing
does give some guidance on EPR comparision.
Using the WS-Addressing's
anonymous IRI in the AcksTo EPR may further impact
implementations. When
the AcksTo EPR uses the anonymous IRI, Sequence
Acknowledgements MUST be sent on the appropriate
protocol
binding-specific channel. For example,
in the HTTP case, Sequence Acknowledgements would
be expected to
flow on the HTTP response flow. It is
worth noting that this may result in new SOAP
messages being
generated and sent in certain situations.
For example, if on an HTTP request flow
the SOAP
message contained a wsa:ReplyTo that didn't use the
anonymous IRI, then it is possible to a
new SOAP
message may need to flow back on the HTTP response flow for the sole purpose of
carrying a
Sequence Acknowledgement. Because the anonymous IRI is a general
purpose IRI that can be used by
many
concurrent RM Sequences, Sequence Acknowledgements that are sent to the AcksTo EPR using these
protocol
binding-specific channels SHOULD only be sent when it can be determined that
the channel is
related to the
RM Sequence. For example, Sequence
Acknowledgements should only be piggy-backed on
HTTP response flows where the message
that was sent on the HTTP request flow referenced the Sequence
in question
through the use of a Sequence or AckRequested Header
block.
Anish: I have no objections to add
guidance, but do not want to confuse implementers. WS Addressing does not give guidelines on EPR
comparison, in the W3c CR. EPRS are not
identifiers.
Doug D: I have no problem with removing that sentence.
Anish: The second issue is about
the statement about a “new soap message for sequence ack”.
That may be true, but this depends on
what type of binding is in use. You may
have a binding restriction to not sending anything on the back channel, thus ackTo cannot be anonymous. I want to state that we should be careful in
the wording for the second paragraph to not push implementers one way or
another.
Doug D: I say MAY and SHOULD to not require anything. However for the HTTP case the statements are
accurate.
Chris F: there may be cases where anonymous is not
appropriate to use. That is why Doug
Stated MAY.
Anish: this depends on a
particular HTTP binding. Am I prevented
from having multiple http bindings. My concern Is mostly
editorial. I do not object to guidance, I can suggest
alternative wording offline.
Chris F: adding text that there may be times when anonymous
is inappropriate.
Doug D: I am willing to let Anish
propose new changes.
Anish I would rater take an action
item to come up with new text.
Umit: I would like to look at
concrete examples. I have anonymous ack to with non anon reply to. BP 1.1 causes problems
Tom: the problem is with BP 1.1 regarding empty http body
for one way wsdl operation.
Doug D: the ack Requested uses the
ackTo for its response. There is no control over this by RMS. I beliver
that anonymous URL for ack to applies to whatever
back channel there is.
Chris F: there are cases for which anonymous is not
acceptable.
Anish: if the back channel does
not exist, as in BP, you cannot use anonymous.
Doug D: what is the wsdl you are
using for this ack requested?
Anish: this might not be for RX,
but if soap message is not expected back, can you put it on the back channel.
TC members should discuss this on the list.
7.7
g> i058 State
Transition Table
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i058
No time to discuss
8
Any other business
None
Meeting ended at 5:30 ET.