sounds ok to me.
Any reason why the issues are still
in 'pending' and not in 'review' ? I think they've all been applied
to the specs.
thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 |
Marc Goodner <>
01/09/2007 01:15 PM
To
Doug Davis/Raleigh/IBM@IBMUS, ""
<>, Paul Fremantle <>
cc
""
<>
Subject
[ws-rx-editors] RX PR issue list update
and MC issues
Before I ask to have this posted let’s
do a sanity check. Since this is the PR issue list I marked all the
MC issues as pending per moving them to a new spec and noted they will
be carried over.
For the current TC discussion of the
MC issues while it is a TC doc I suggest a new issue list here:
http://docs.oasis-open.org/ws-rx/issues/mc/Issues.xml
I prefer this doing this over reusing
the old pre-PR RM issue list as there is new schema since then that is
a lot easier to work with. I assume all of them will just get new issue
numbers in order as I copy them over. Maybe we could use a convention like
mc001 rather than the current i001 form to distinguish them from the PR
issue list numbers.
I assume we would also continue to use
the current RM PR issue list for the next PR round of RM and even MC when
it goes out.
Does that make sense? If yes then I’ll
go ahead and get the new issue list done and posted before this week’s
call.
Title: WS-RX TC Public Review Issues List
WS-RX TC Public Review Issues List
Date: 2007/01/09 - Revision: 9
Contents
Issue summary list by status
New
Active
Pending
Review
Deferred
Closed
Dropped
Statistics
Overall issue counts by related artifact type and broken out by each protocol.
ws-rm
ws-rmp
Detailed issue listing
Complete details in order of issue number
i001 -
WS-Addressing comment on ws-rm related to use of extended anonymous uri
i002 -
WS-RM editorial comment concerning MakeConnection
i003 -
WS-Addressing comment/question related to WS-RM MakeConnection
i004 -
Editorial comments
i005 -
Seq Ack Ranges overlap
i006 -
Destination of Seq faults
i007 -
RM Destination lacks a mechanism for cleanly terminating inbound sequences.
i008 -
Underlying protocol bindings
i009 -
"Duplicate Elimination" and "Message Ordering"
i010 -
Can AckRequested be sent independently or not
i011 -
Editorial issues from eBusinss Asia Committee
i012 -
Anonymous and AcksTo EPR scenarios
i013 -
SequenceAcknowledgement protocol response for AcksTo = wsa:anonymous
i014 -
Composition with WS-Addressing
i015 -
RMD polling
i016 -
2nd Protocol Invariant, none and nack
i017 -
What is the purpose of the WSDL?
i018 -
Piggyback message combinations
i019 -
Use of AckRequested
i020 -
Message ordering and duplication
i021 -
Piggy-backing problematic
i022 -
RMD cannot detect some incomplete Sequences
i023 -
CreateSequenceRefused fault should apply to sender and receiver
i024 -
When to send CloseSequenceResponse vs. SequenceClosedfault
i025 -
wsrm-1.1-schema-200608.xsd is invalid
i026 -
Retransmission
i027 -
Where do Sequence Faults go when the RMS is anonymous
i028 -
MakeConnection preconditions are unclear
i029 -
Opaqueness of URI identifiers not preserved by RM anon URI
i030 -
Facilities to support optional MakeConnection underspecified
i031 -
Scope of MakeConnection is unconstrained
i032 -
back-channel nit
i033 -
back-channel not defined
i034 -
Define gap
i035 -
Delivery Assurances
i036 -
Compliance vs. Conformance
i037 -
Policy Assertions Must be Independent
New Issues Summary
id
owner
title
protocol
type
i037
Policy Assertions Must be Independent
ws-rmp
design
Active Issues Summary
id
owner
title
protocol
type
i007
RM Destination lacks a mechanism for cleanly terminating inbound sequences.
ws-rm
design
*
i009
"Duplicate Elimination" and "Message Ordering"
ws-rm
design
i020
Message ordering and duplication
ws-rm
design
i021
Piggy-backing problematic
ws-rm
design
*
i022
RMD cannot detect some incomplete Sequences
ws-rm
design
*
i035
Delivery Assurances
ws-rm
design
Pending Issues Summary
id
owner
title
protocol
type
i001
WS-Addressing comment on ws-rm related to use of extended anonymous uri
ws-rm
design
i002
WS-RM editorial comment concerning MakeConnection
ws-rm
editorial
i003
WS-Addressing comment/question related to WS-RM MakeConnection
ws-rm
editorial
i004
Editorial comments
ws-rm, ws-rmp
editorial
i005
Seq Ack Ranges overlap
ws-rm
design
i006
Destination of Seq faults
ws-rm
editorial
i010
Can AckRequested be sent independently or not
ws-rm
design
i012
Anonymous and AcksTo EPR scenarios
ws-rm
design
i013
SequenceAcknowledgement protocol response for AcksTo = wsa:anonymous
ws-rm
design
i015
RMD polling
ws-rm, ws-rmp
design
i016
2nd Protocol Invariant, none and nack
ws-rm
design
i017
What is the purpose of the WSDL?
ws-rm
design
i018
Piggyback message combinations
ws-rm
design
i023
CreateSequenceRefused fault should apply to sender and receiver
ws-rm
design
i024
When to send CloseSequenceResponse vs. SequenceClosedfault
ws-rm
design
i025
wsrm-1.1-schema-200608.xsd is invalid
ws-rm
design
i026
Paul Fremantle
Retransmission
ws-rm
design
i027
Paul Fremantle
Where do Sequence Faults go when the RMS is anonymous
ws-rm
design
i028
Jonathan Marsh
MakeConnection preconditions are unclear
ws-rm
design
i029
Jonathan Marsh
Opaqueness of URI identifiers not preserved by RM anon URI
ws-rm
design
i030
Jonathan Marsh
Facilities to support optional MakeConnection underspecified
ws-rm
design
i031
Jonathan Marsh
Scope of MakeConnection is unconstrained
ws-rm
design
i032
Bob Freund
back-channel nit
ws-rm
editorial
i033
Bob Freund
back-channel not defined
ws-rm
editorial
i036
Pete Wenzel
Compliance vs. Conformance
ws-rm
design
Review Issues Summary
id
owner
title
protocol
type
Deferred Issues Summary
id
owner
title
protocol
type
Closed Issues Summary
id
owner
title
protocol
type
Dropped Issues Summary
id
owner
title
protocol
type
i008
Underlying protocol bindings
ws-rm
design
i011
Editorial issues from eBusinss Asia Committee
ws-rm
editorial
i014
Composition with WS-Addressing
ws-rm
design
i019
Use of AckRequested
ws-rm
design
i034
Paul Fremantle
Define gap
ws-rm
editorial
Statistics
ws-rm issue stats
spec
schema
soap
wsdl
policy
all
total
New
0
0
0
0
0
0
0
Active
6
0
0
0
0
0
6
Pending
24
1
0
0
0
0
25
Review
0
0
0
0
0
0
0
Deferred
0
0
0
0
0
0
0
Closed
0
0
0
0
0
0
0
Dropped
5
0
0
0
0
0
5
total
35
1
0
0
0
0
36
ws-rmp issue stats
spec
schema
soap
wsdl
policy
all
total
New
1
0
0
0
0
0
1
Active
0
0
0
0
0
0
0
Pending
2
0
0
0
0
0
2
Review
0
0
0
0
0
0
0
Deferred
0
0
0
0
0
0
0
Closed
0
0
0
0
0
0
0
Dropped
0
0
0
0
0
0
0
total
3
0
0
0
0
0
3
Detailed Listing
i001
WS-Addressing comment on ws-rm related to use of extended anonymous uri
spec -
design -
Pending
Description
In July comment was made to the WS-Addressing group concerning
interoperability issues related to the WS-Addressing WSDL binding and
the specific use of the anonymous address specified in the WS-RM public
review specification.
A WS-Addressing issue cr33
was subsequently opened.
It seems clear that after several meetings almost wholly focused on this
issue; the WS-Addressing working group is not converging on a
resolution. The working group is evenly split between "close with no
action" and "keep working toward some resolution".
There is a reasonable potential that close with no action may be the
result.
We therefore request that an issue be raised related to this use of
anonymous within the WS-RX Working Group such that alternative forms of
reconciliation may be explored.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
W3C WS-Addressing WG
Proposal 1
2006-09-25
Proposal 2
2006-10-19
Revised from original.
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i002
WS-RM editorial comment concerning MakeConnection
spec -
editorial -
Pending
Description
1) It's not specified in line 809 that MakeConnection appears as a
body element rather than a header. In fact, MakeConnection isn't
described as an element at all - it's described as an operation. See
line 312 as an example of clearer text.
2) Line 811 says "no SOAP envelopes will be returned on the
back-channel." I think "envelopes" should be singular.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
W3C WS-Addressing WG
Resolution
2006-09-28
Assigned to editors to resolve on Sept. 28th TC call.
i003
WS-Addressing comment/question related to WS-RM MakeConnection
spec -
editorial -
Pending
Description
As chair of WS-Addressing I am forwarding the following comment made by
one of our members.
I've been puzzling through the spaghetti of dependant specs for a while,
and haven't determined conclusively how to reconcile the WSDL in
Appendix B with the MakeConnection example in Appendix C.6.
The WSDL describes request-response operations such as CreateSequence,
with input CreateSequence and output CreateSequenceResponse messages.
While the WSDL doesn't describe a binding for this, it is easy to
imagine a straightforward way to bind this to a SOAP/HTTP
request-response.
However, the MakeConnection example shows a MakeConnection message
resulting in a CreateSequence response message, which then results in a
CreateSequenceResponse messages, followed by an HTTP 202. That is, the
first request corresponds to a one-way message (no problem here), the
first response corresponds to a request of a request-response, and the
second request corresponds to the response of a request-response.
What standard binding could be used to describe this behavior? I can't
find any of the specs (WSDL 1.1, WSDL 2.0, WS-I BP) that explicitly say
the WSDL-described request message must be mapped to an HTTP request,
but I'm also not aware of any implementation that allows requests to be
mapped to anything else. Is this just a too-obvious-to-state loophole
or am I missing something?"
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
W3C WS-Addressing WG
Proposal 1
2006-10-10
Proposal 2
2006-10-19
Resolution
2006-10-19
Proposal 2 accepted on Oct. 19th TC call.
i004
Editorial comments
spec -
editorial -
Pending
Description
Comments from Gil
Comments from Marc
Raised against / Related drafts
ws-rm revision: cd04
ws-rmp revision: cd04
Related Issues
Origin
Gilbert Pilz
Resolution
2006-10-26
Proposed changes (in description) accepted on Oct 26th TC call.
i005
Seq Ack Ranges overlap
spec -
design -
Pending
Description
The RM spec says, w.r.t. Seq Ack Ranges:
The ranges SHOULD NOT overlap.
Why isn't this a MUST NOT? It smells like an interop issue if we don't know if the other side can deal with it.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Doug Davis
Proposal 12006-10-19
Change it to a MUST NOT
Resolution
2006-10-26
Proposal 1 accepted on Oct 26th TC call.
i006
Destination of Seq faults
spec -
editorial -
Pending
Description
From spec: Line 893
RM Destinations that generate Sequence faults SHOULD send those faults to the same [destination] as Acknowledgement messages.
The text is a bit unclear. Does it mean that sending it is optional or is the EPR it sends it to optional? I think the intent was just the act of sending it is option, but it must go to the AcksTo EPR.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Doug Davis
Proposal 12006-10-19
RM Destinations that generate Sequence faults SHOULD transmit those faults. If the fault is transmitted, it MUST be transmitted to the same [destination] as Acknowledgement messages.
Proposal 2
2006-10-26
Destinations that generate faults related to known sequences SHOULD transmit those faults. If transmitted, such faults MUST be transmitted to the same [destination] as Acknowledgement messages.
Resolution
2006-10-26
Proposal 2 arrived at and accepted on Oct 26th TC call.
i007
RM Destination lacks a mechanism for cleanly terminating inbound sequences.
spec -
design -
Active
Description
Stipulate the following scenario: a client and server communicate using asynchronous, two-way, reliable messaging. During the initial sequence creation the client offers a sequence to the server and this offer is accepted. Some number of requests and responses are exchanged using the requested and offered sequences. At some later time the user of the client application causes that application to exit. It is obvious that the client-side RMS should clean up the outgoing, client-to-server sequence by sending a wsrm:TerminateSequence message (possibly preceded by a wsrm:CloseSequence message) to the server-side RMS. What is not clear is what steps the client-side RMD should take to clean up the incoming, server-to-client sequence. There are three basic courses of action:
1.) The client-side RMD could do nothing to clean up the incoming sequence. From a distributed systems viewpoint this seems less than optimal as it leaves the server-side RMS with a "dangling sequence". If the server-side RMS ever tried to use this dangling sequence it would engage the entire RMS machinery for messages that would never get through (send, retry, request acks, retry, request acks, etc.).
2.) The client could wait for a length of time sufficient for it to consider the inbound sequence to be "inactive", then exit. There are a couple of problems with this. Firstly the user that caused the client to exit may grow impatient and attempt to terminate the client by other means. Secondly, outside of the optional expiration time, there is no mutually agreed upon inactivity period for a sequence.
3.) The client-side RMD could send a message to the server-side RMS to indicate that the inbound, server-to-client sequence is being cleaned up. Since the direction of the wsrm:TerminateSequence message is specified by WS-ReliableMessaging 1.1 as being from the RMS to the RMD only, this leaves either the wsrm:SequenceTerminated or wsrm:SequenceClosed faults as the only viable messages for the client-side RMD to use. This brings up all the problems attendant with using faults/exceptions to indicate "normal" application behavior. The server-side RMS may construe the appearance of a fault as an indication of some lower-level problem, etc.
Note that, although this issue is discussed in the context of a client application attempting to exit, it is applicable in any situation where the process/VM that "contains" an RMD must exit in a relatively short period of time for whatever reason.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Gilbert Pilz
Proposal 12006-10-19
Amend the wording of section 3.6 (Sequence Termination) to indicate that a wsrm:TerminateSequence/wsrm:TerminateSequenceResponse exchange may be initiated by the RMD.
Proposal 2
2006-01-06
i008
Underlying protocol bindings
spec -
design -
Dropped
Description
There is interoperability issue with this specicication, since it doesn't define underlying protocol bindings (e.g.,HTTP bindings). The spec or its profile should explicitly define underlying protocol bindings.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Resolution
2006-10-26
Closed without action on the Oct 26th TC call.
Protocol bindings are out of scope of this group, but could be dealt with in WS-I RSP group
i009
"Duplicate Elimination" and "Message Ordering"
spec -
design -
Active
Description
2.1 This specification dose not define how to realize "Duplicate Elimination" and "Message Ordering".
It is a serious issue for industry organizations in Japan and Asia to adopt the specification.
We strongly recommend to define them to make various implementations interoperable.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
i010
Can AckRequested be sent independently or not
spec -
design -
Pending
Description
2.2 It is not clear whether AckRequest message can be sent independently or not.
The 3.8 describes:
"The RM Source MAY request an Acknowledgement Message from the RM Destination at any time by including an
AckRequested header block in any message targeted to the RM Destination."
In detail, is the following message which doesn't include <wsrm:Sequence>
, allowed to send? If so, the above sentence should explicitly describe it. See the first four lines in
Section 3.9.
<soap:Envelope>
<soap:Header>
<wsrm:AckRequested>
<wsrm:Identifier>http://example.com/test</wsrm:Identifier>
</wsrm:AckRequested>
</soap:Header>
</soap:Envelope>
By the way, the section 3.9 describes:
"The RM Destination informs the RM Source of successful message receipt using a SequenceAcknowledgement
header block. The RM Destination MAY Transmit the SequenceAcknowledgement header block independently or it
MAY include the SequenceAcknowledgement header block on any message targeted to the AcksTo EPR."
And it is clear the SequenceAcknowledgement can be sent independently.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Proposal 1
2006-11-01
Resolution
2006-11-09
Proposal 1 acepted on Nov. 9th TC call.
i011
Editorial issues from eBusinss Asia Committee
spec -
editorial -
Dropped
Description
2.3 Line697 Editorial
"see Section 3.5" should be "see Section 3.8" ?
2.4 Line667 Editorial
"see Section 3.1" seems not appropriate. It should be other appropriate section.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Resolution
2006-11-09
Resolved to thank the submitter and inform them the issue has been addressed on Nov. 9th TC call.
i012
Anonymous and AcksTo EPR scenarios
spec -
design -
Pending
Description
2.5 Line 704-709
The following sentences needs to be refined or requires examples.
" When the RM Source specifies the WS-Addressing anonymous IRI as the address of the AcksTo EPR,
the RM Destination MUST Transmit any SequenceAcknowledgement headers for the created Sequence in a
SOAP envelope to be Transmitted on the protocol binding-specific channel. Such a channel is provided
by the context of a Received message containing a SOAP envelope that contains a Sequence header block
and/or a AckRequested header block for that same Sequence identifier."
Maybe some examples help reader understand what it meant.
It is not clear whether the SequenceAcknowledgement must be sent on
*its* back-channel of the underlying transport protocol.
e.g.,
Here is the following scenario:
1.CreateSequence has "Anonymous" value for AcksTo element.
2.RM Source sends a message A with AckRequested on HTTP Request.
3.RM Source sends a message B on HTTP Request.
Question:
In this scenario, does RM Destination have to send Sequence Acknowledgement for message A on the HTTP Response in 2, but disallow to send it on HTTP Response in 3?
Or does the spec allow to send it on the HTTP Response in 3?
The spec is not clear about the above scenario. The spec should clarify it.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Proposal 1
2006-11-14
Proposal 2
2006-11-17
Resolution
2006-12-07
Proposal 2 accepted on December 7th TC call
i013
SequenceAcknowledgement protocol response for AcksTo = wsa:anonymous
spec -
design -
Pending
Description
2.6 Line339-348
It is not clear what the following sentences means:
CreateSequence\AcksTo = wsa:anonymous
Does it mean the SequecenAcknowledgement must be on the HTTP Response to the original message?
If so, it is beyond the WS-Addressing definition, I believe.
By the way, the spec doesn't allow wsrm:Anonymous to be used in AcksTo.
If the spec doesn't allow wsa:anonymous in AcksTo, then it should be explicitly described
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Proposal 1
2006-11-14
Proposal 2
2006-11-17
Resolution
2006-12-07
Proposal 2 accepted on December 7th TC call
i014
Composition with WS-Addressing
spec -
design -
Dropped
Description
2.7 Section3.9 and Appendix B
Needs explanation of ws-addressing composability.
It is not clear how ws-addressing/soap request message and response message maps to AckRequested and
SequenceAcknoweldgement message.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Proposal 1
2006-11-14
Resolution
2006-11-16
Closed with no action, explanation to be sent to submitter, on Nov 16th TC call.
i015
RMD polling
spec -
design -
Pending
Description
2.8 Section3.10
It is not described how you can identify whether the RM destination is polling a message.
This could be in RM policy assertion.
Raised against / Related drafts
ws-rm revision: cd04
ws-rmp revision: cd04
Related Issues
Origin
eBusinss Asia Committee
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i016
2nd Protocol Invariant, none and nack
spec -
design -
Pending
Description
The 2nd Protocol Invariant (sec 2.3) says:
Within every Acknowledgement Message it issues, the RM Destination MUST include one or more
AcknowledgementRange child elements that contain, in their collective ranges, the message number of every message accepted by the RM Destination. The RM Destination MUST exclude, in the AcknowledgementRange elements, the message numbers of any messages it has not accepted.
This isn't true in the case when the SequenceAck is either None or Nack.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Paul Fremantle
Proposal 12006-11-09
Change 2nd invariant to: Within every Acknowledgement Message it issues, the RM Destination MUST include one or more AcknowledgementRange child elements that contain, in their collective ranges, the message number of every message accepted by the RM Destination. The RM Destination MUST exclude, in the AcknowledgementRange elements, the message numbers of any messages it has not accepted. If no messages have been received the RM Destination MUST return None instead of an AcknowledgementRange(s). The RM Destination MAY transmit a Nack for a specific message or messages instead of an AcknowledgementRange(s).
Resolution
2006-11-09
Proposal 1 acepted on Nov. 9th TC call.
i017
What is the purpose of the WSDL?
spec -
design -
Pending
Description
The purpose of the WSDL is not terribly clear. I doubt one would actually describe a Web service
using this WSDL, as RM is generally considered an infrastructure-level protocol and WSDL typically
describes an application-level message exchange. In addition, if machine-processing of this WSDL is
expected, not all message exchanges are described – after a MakeConnection message comes _in_ to the service, a CreateSequence message may come _out_, yet CreateSequence is only described as an _in_ message in the WSDL. The limits of the WSDL in describing the complete exchanges of messages should be noted.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Jonathan Marsh
Proposal 1
2006-10-19
fix this editorially by adding the following explanatory text to "Appendix B. WSDL":
This WSDL describes the RM protocol from the point of view of an RM Destination. In the case where an endpoint acts both as an RM Destination and an RM Source, note that additional messages may be present in exchanges with that endpoint.
Also note that this WSDL is intended to describe the internal structure of the RM protocol, and will not generally to appear in a description of an RM-capable Web service. See RM-Policy [ref] for a higher-level mechanism to indicate that RM is engaged.
Resolution
2006-11-30
Proposal 1 accepted on Nov 30th TC call.
i018
Piggyback message combinations
spec -
design -
Pending
Description
1. Section 3.2 (P. 10)
This section describes piggy-back messages, but does not mention receivable
message combinations. So, which message combinations can be received could
be implementation-dependent.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Sadao Yashiro
Proposal 1
2006-12-17
Resolution
2007-01-04
Proposal 1 accepted on Jan 4th TC call.
i019
Use of AckRequested
spec -
design -
Dropped
Description
2. Section 3.8 (P. 19)
According to the specification, a receiver must return an Acknowledgement
when a message contains an AckRequested element, which requests an
Acknowledgement. However, it is not specified that a receiver must not
return an Acknowledgement when a message contains no AckRequested element.
So, I think the implementation should return an AckRequested element
whenever a user payload is received.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Sadao Yashiro
Proposal 1
2006-11-14
Resolution
2006-11-16
Closed with no action, explanation to be sent to submitter, on Nov 16th TC call.
i020
Message ordering and duplication
spec -
design -
Active
Description
3. No description on guaranteed message ordering and duplication
elimination.
Neither did the previous version. Did the TC determine to set them out of
scope?
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Sadao Yashiro
i021
Piggy-backing problematic
spec -
design -
Active
Description
WS-RM allows for the possibility of adding the wsrm:AckRequested and wsrm:SequenceAcknowledgement headers to
unrelated messages that are targeted to the "same" endpoint; a concept it refers to as "piggy-backing".
There are a number of problems with this concept:
See message for complete description.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Gilbert Pilz
Proposal 1
2006-10-20
Proposal 2
2006-01-06
i022
RMD cannot detect some incomplete Sequences
spec -
design -
Active
Description
WS-RM 1.0 [1] defined a sub-element of the wsrm:Sequence header that served to mark the containing message as the last message in a Sequence. WS-RM 1.1 [2] has removed this element. Consequently the RMD has no guaranteed way of determining whether it has received all the messages in a Sequence. This presents obvious drawbacks to an Application Destination that may wish to know if it has received all the data that the Application Source sent it. In addition to this it makes correctly implementing the "incomplete sequence behavior" semantics impossible since the RMD cannot always determine what is and isn't an "incomplete Sequence".
For example, suppose an RMS creates a Sequence, sends messages 1-10, then sends a CloseSequence. Suppose that messages 9 and 10 get lost but the CloseSequence message is received by the RMD. The RMS can determine that the Sequence is incomplete (final ack is missing 9 and 10 from the range), but the RMD has no way of knowing, nor is there any way for it to discover, that the Sequence is incomplete. If the IncompleteSequenceBehavior was "DiscardEntireSequence" then the RMS will conclude that all of the messages will be discarded whereas the RMD will, in all likelihood, deliver all of the messages to the Application Destination under the assumption that the Sequence is complete.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Gilbert Pilz
Proposal 1
2006-10-20
Proposal 2
2006-10-21
Proposal 3
2006-10-26
i023
CreateSequenceRefused fault should apply to sender and receiver
spec -
design -
Pending
Description
In section 4.6 the CreaetSequenceRefused fault is defined as a sender fault. This fault should apply to sender or receiver.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Marc Goodner
Proposal 1
2006-10-21
Resolution
2006-11-16
Closed with proposal 1 on Nov 16th TC call.
i024
When to send CloseSequenceResponse vs. SequenceClosedfault
spec -
design -
Pending
Description
In section 4.7 describing the SequenceClosed fault one reason the fault must be returned is that an RMD is “…asked to close a Sequence that is already closed.” However, in section 3.5 that describes CloseSequence it says that for a closed sequence the RMD must process all Sequence Lifecycle messages including CloseSequence. It also says that subsequent CloseSequence messages have no further effect.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Marc Goodner
Proposal 1
2006-10-21
Resolution
2006-10-26
Proposal 1 accepted on Oct 26th TC call.
i025
wsrm-1.1-schema-200608.xsd is invalid
schema -
design -
Pending
Description
Inside wsrm-1.1-schema-200608.xsd, the following constructs are invalid, according to my XML schema
processor. See message...
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Eric Rajkovic
Proposal 1
2006-10-24
Resolution
2006-11-16
Proposal 1 aaccepted on Nov 16th TC call.
i026
Retransmission
spec -
design -
Pending
Description
We do not normatively state that any messages must be retransmitted
unless the server Nacks them.
Since the Protocol Invariants are there to explain how we actually
ensure reliable transmission, that is the appropriate place to add this.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1
2006-11-02
Proposal 2
2006-12-14
Resolution
2006-12-14
Proposal 2 accepted on December 14th TC call.
i027
Where do Sequence Faults go when the RMS is anonymous
spec -
design -
Pending
Description
Suppose the faultsTo, acksTo and replyTo of a message are all WS-A
anonymous, but with different reference parameters. Which should the RMD
use to respond with a SequenceFault.
The answer seems to be the acksTo EPR. But if this is different from the
replyTo then the RMD cannot return the fault on the backchannel.
Furthermore, if the acksTo is WSRM Anonymous, then it isn't clearly
stated that the faults should be polled for using MC.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i028
MakeConnection preconditions are unclear
spec -
design -
Pending
Description
MakeConnection as defined today relies on the RM Anonymous URI template. The spec does not adequately specify the preconditions necessary for the exchange to be successful.
Prior to a MakeConnection message, do both the client and the server have to be in possession of a correctly constructed instance of the RM anon URI template? Of an EPR using this template? The example messages invent a subscription operation in step 1, which indicates that the precise URI and the intent to enable MakeConnection must be negotiated between the RMD and RMS out of band, yet nowhere are these preconditions enumerated. The RM protocol preconditions only list an EPR as a precondition, not the precise form of that EPR, and any intention that buffering of messages should be engaged. What happens if a client does a MakeConnection without all preconditions being satisfied also appears to be underspecified.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Jonathan Marsh
Owner
Jonathan Marsh
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i029
Opaqueness of URI identifiers not preserved by RM anon URI
spec -
design -
Pending
Description
See message for description.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Jonathan Marsh
Owner
Jonathan Marsh
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i030
Facilities to support optional MakeConnection underspecified
spec -
design -
Pending
Description
See message for description.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Jonathan Marsh
Owner
Jonathan Marsh
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i031
Scope of MakeConnection is unconstrained
spec -
design -
Pending
Description
See message for description.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Jonathan Marsh
Owner
Jonathan Marsh
Resolution
2006-12-14
MakeConection moved to new specification which will address this issue.
i032
back-channel nit
spec -
editorial -
Pending
Description
There are several uses of the term “back-channel” and two uses of “bsckchannel”
Please pick one and use it consistently
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Resolution
2006-11-09
Given to editors to correct spelling on Nov 9th TC call.
i033
back-channel not defined
spec -
editorial -
Pending
Description
The WS-RM spec uses the term “back-channel” several times without defining it outside of the use “protocol specific back-channel”
A cursory scan of rfc 2616 HTTP 1.1 does not define the term.
It is also not defined in SOAP 1.2 Parts 0-3
Where is the term defined?
That definition should be referenced or a definition provided
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Bob Freund
Owner
Bob Freund
Proposal 12006-12-14
Backchannel: When the underlying transport provides a mechanism to return a transport-protocol specific response (with a SOAP message) without initiating a new connection, we refer to this mechanism as a backchannel.
Resolution
2006-12-14
Proposal 1 accepted on December 14th TC call.
i034
Define gap
spec -
editorial -
Dropped
Description
Reading the spec to discuss Issue 22, I notice that we do not define what a "gap" is. It seems reasonably pertinent to some of the discussions we are having, and I think we should more clearly define it.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Paul Fremantle
Owner
Paul Fremantle
Proposal 1
2006-11-14
Resolution
2006-11-30
Closed with no action on Nov 30th TC call.
i035
Delivery Assurances
spec -
design -
Active
Description
See message
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Kevin Houstoun
i036
Compliance vs. Conformance
spec -
design -
Pending
Description
Section 1.3 of WSRM and Section 1.4 of WSRMP discuss "compliance"
of implementations with the specification. However, that term is
widely associated with specific (legal) obligations involving
(governmental or other) regulations, mandates and
testing/certification authorities. In this case, it would be better
stated as "conformance" to the specification.
Raised against / Related drafts
ws-rm revision: cd04
Related Issues
Origin
Pete Wenzel
Owner
Pete Wenzel
Proposal 1
2006-11-16
Resolution
2006-11-30
Proposal 1 accepted on Nov 30th TC call.
i037
Policy Assertions Must be Independent
spec -
design -
New
Description
See message
Raised against / Related drafts
ws-rmp revision: cd04
Related Issues
Origin
Ashok Malhotra
Proposal 1
2006-01-05
Action Item Complete Listing
=
