Doug:
That looks acceptable for allowing various
distributed schemes.
I will stop the chase for a better
definition, though a couple of last editorial suggestions:
-
This time
in an attempt to narrow more your def, I'd add the adjective "reliable":
"For any one reliable message the endpoint
that transmits the message." Or just "the endpoint that transmits a
reliable message."
-
This leads
me to notice that the expression "reliable message" is used a t
several places (see 2.3, also Fig 1 comment) but is never defined (although one
can suspect what it means) That would call for an addition to the glossary
like: "reliable message: a message that complies with the reliability protocol
defined in this specification". But that could be separate from your
issue.
Regards,
Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Monday, October 17, 2005
4:12 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i010 - a
proposal
Jacques,
sorry for the delay. Yes I left 'endpoint' in the definitions because
they refer to "the" message - implying what the sender/receiver is
for any _one_ message sent. I suppose I could change the text to make
that clearer, something like:
RM Source: For any one message the endpoint that transmits the message.
I'm
actually ok with using the term 'endpoint' when talking about one particular
message exchange.
I'll
fix the other two spots you pointed out. New version of diffs is attached
with all of these changes.
thanks
-Doug
Jacques Durand
<JDurand@us.fujitsu.com>
10/11/2005 05:34 PM
|
To
|
Doug Davis/Raleigh/IBM@IBMUS,
ws-rx@lists.oasis-open.org
|
cc
|
|
Subject
|
RE: [ws-rx] i010 - a proposal
|
|
Doug:
the defs of RMD and RMS still define them as
"endpoints", which will maintain the confusion.
How about RMS as "implementation of this specification
supporting the Send and Transmit operations, usually associated with the
endpoint reference of a WS or of its client", and RMD as
"implementation of this specification supporting the Receive and Deliver
operations, usually associated with the endpoint reference of a WS or of its
client."
That would just "associate" endpoints to the
RMS/RMD (not excluding several endpoints, as well as not excluding several
addressable RM entities cooperating as a single RMS or RMD).
Other places where "endpoint" is too tightly
associated with RMS or RMD:
Line 786-789: "This fault is sent by either the
RM Source or the RM Destination to indicate that the
endpoint
that generated the fault..." mentions
of endpoint to be removed in this paragraph too.
Line 1302: (Appendix B4) "The
sending endpoint discovers that message number 2 was not received..."
Jacques
From: Doug Davis
[mailto:dug@us.ibm.com]
Sent: Sunday, October 09, 2005 10:39 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i010 - a proposal
Per my AI for issue 10 here's what I came up with.
As much as I tried I really couldn't find a nice way to define RM Source and RM
Destination to make it clear that they were not limited to just one endpoint or
port. The closest I came was to add some text to the definitLinkion of each that talked about
how they were not limited to one endpoint blah blah blah... But I
thought that wouldn't be any better than my original proposal because it would
probably make people stop and think too much about what we were trying to say. So,
what I came up with was this:
- remove the "endpoint" in places where we said "RM Source
endpoint" and "RM Destination endpoint" - as Jacques suggested
- tweak the "exactly two parties" sentence we talked about during the
f2f
- remove the tying of the RM Source/Destination to the WS-Addr headers in the
CreateSequence section
- add just *1* sentence expanding the scope of the RM Source and RM destination
concept in the RM Model section. I tried to keep this sentence short so
to not over-complicate things but still allow the freedom I was looking for.
I've attached a pdf file of the spec with the change bars on. You should
find 9 changes. For easy finding they're on line #s: 80, 146, 213, 305,
313, 315, 435, 436, 475,
thanks
-Doug