RE: RE: [ws-rx-editors] List of open issues

You are right. It was resolved on the same call that we decided to move MC to a new spec, 12/14. So it was probably a cut and paste error in my updates.

I’ve made the appropriate change to the issue list, back against RM and pending.

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Wednesday, January 17, 2007 10:34 AM
To: Marc Goodner
Cc: Marc Goodner; Patil, Sanjay; ws-rx-editors@lists.oasis-open.org
Subject: RE: RE: [ws-rx-editors] List of open issues

issue 26 isn't about MC and I think its resolved but not applied (not sure why)

thanks
-Doug
__________________________________________________
STSM | Web Services Architect | IBM Software Group
(919) 254-6905 | IBM T/L 444-6905 | dug@us.ibm.com

Marc Goodner <mgoodner@microsoft.com>

01/17/2007 01:08 PM

To	Marc Goodner <mgoodner@microsoft.com>, "Patil, Sanjay" <sanjay.patil@sap.com>, "ws-rx-editors@lists.oasis-open.org" <ws-rx-editors@lists.oasis-open.org>
cc
Subject	RE: RE: [ws-rx-editors] List of open issues

OK, here’s the final draft. I’ll ask Robin to post this one after lunch unless any of you guys see anything wrong here.

All pending issues moved to review except 7, 13, 21 and 22.

From: Marc Goodner [mailto:mgoodner@microsoft.com]
Sent: Wednesday, January 17, 2007 9:42 AM
To: Patil, Sanjay; ws-rx-editors@lists.oasis-open.org
Subject: RE: [ws-rx-editors] List of open issues

This looks right to me. I’m working on the issue list right now. I’m checking the issues that need to be moved from pending to review since many of them have been applied. I should be done before lunch today.

Ashok’s issue does have an issue number, it is 37.

I believe that issue 26 on MakeConenction is still open as well.

From: Patil, Sanjay [mailto:sanjay.patil@sap.com]
Sent: Monday, January 15, 2007 1:37 PM
To: ws-rx-editors@lists.oasis-open.org
Subject: [ws-rx-editors] List of open issues

The PR issues list is not up-to-date yet. Following is what I gather as the list of open issues based on my notes. Please let me know if anybody has a different view.

-- Sanjay

Make Connection: 1, 15, 28, 29, 30, 31, Gil's yet to be raised new issue for - whether and how does the core spec refer the MC spec.

Delivery Assurance: 9, 20, 35
Policy: Ashok's issue for nested policy raised on 1/5 (with no number yet)
[attachment "Issues.html" deleted by Doug Davis/Raleigh/IBM]

id	owner	title	protocol	type
i001		WS-Addressing comment on ws-rm related to use of extended anonymous uri	ws-rm-mc	design	*
i009		"Duplicate Elimination" and "Message Ordering"	ws-rm	design
i015		RMD polling	ws-rm-mc	design
i020		Message ordering and duplication	ws-rm	design
i028	Jonathan Marsh	MakeConnection preconditions are unclear	ws-rm-mc	design
i029	Jonathan Marsh	Opaqueness of URI identifiers not preserved by RM anon URI	ws-rm-mc	design
i030	Jonathan Marsh	Facilities to support optional MakeConnection underspecified	ws-rm-mc	design
i031	Jonathan Marsh	Scope of MakeConnection is unconstrained	ws-rm-mc	design
i035		Delivery Assurances	ws-rm	design
i037		Policy Assertions Must be Independent	ws-rmp	design	*

id	owner	title	protocol	type
i007		RM Destination lacks a mechanism for cleanly terminating inbound sequences.	ws-rm	design
i013		SequenceAcknowledgement protocol response for AcksTo = wsa:anonymous	ws-rm	design
i021		Piggy-backing problematic	ws-rm	design
i022		RMD cannot detect some incomplete Sequences	ws-rm	design
i026	Paul Fremantle	Retransmission	ws-rm	design

id	owner	title	protocol	type
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
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
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

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
i027	Paul Fremantle	Where do Sequence Faults go when the RMS is anonymous	ws-rm-mc	design
i034	Paul Fremantle	Define gap	ws-rm	editorial

	spec	schema	total
New	0	0	0
Active	3	0	3
Pending	5	0	5
Review	15	1	16
Deferred	0	0	0
Closed	0	0	0
Dropped	5	0	5
total	28	1	29

ws-rx-editors message

WS-RX TC Public Review Issues List

Contents

New Issues Summary

Active Issues Summary

Pending Issues Summary

Review Issues Summary

Deferred Issues Summary

Closed Issues Summary

Dropped Issues Summary

Statistics

ws-rm issue stats

ws-rm-mc issue stats

ws-rmp issue stats

Detailed Listing

Action Item Complete Listing

i001	WS-Addressing comment on ws-rm related to use of extended anonymous uri	spec - design - Active
	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-mc revision: ed01 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. Issue moved against new spec.
i002	WS-RM editorial comment concerning MakeConnection	spec - editorial - Review
	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 - Review
	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 - Review
	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 - Review
	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 - Review
	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 - Pending
	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 2007-01-06 Proposal 3 2007-01-10 Resolution 2007-01-11 Proposal 2 accepted with edits as noted in minutes.
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 - Review
	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 - Review
	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 - Active
	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-mc revision: ed01 Related Issues Origin eBusinss Asia Committee Resolution 2006-12-14 MakeConection moved to new specification which will address this issue. Issue moved against new spec.
i016	2nd Protocol Invariant, none and nack	spec - design - Review
	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 - Review
	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 - Review
	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