+1 from me. Paul
Marc Goodner wrote:
> 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.
>
>
> ------------------------------------------------------------------------
>
> 
>
>
> WS-RX TC Public Review Issues List
>
> Date: 2007/01/09 - Revision: 9
>
>
> Contents
>
> Issue summary list by status
>
> * New <#New>
> * Active <#Active>
> * Pending <#Pending>
> * Review <#Review>
> * Deferred <#Deferred>
> * Closed <#Closed>
> * Dropped <#Dropped>
>
> Statistics <#Stats>
> Overall issue counts by related artifact type and broken out by each
> protocol.
>
> * ws-rm <#ws-rm-stats>
> * ws-rmp <#ws-rmp-stats>
>
> Detailed issue listing <#Detail>
> Complete details in order of issue number
>
> * i001 - WS-Addressing comment on ws-rm related to use of
> extended anonymous uri <#i001>
> * i002 - WS-RM editorial comment concerning MakeConnection <#i002>
> * i003 - WS-Addressing comment/question related to WS-RM
> MakeConnection <#i003>
> * i004 - Editorial comments <#i004>
> * i005 - Seq Ack Ranges overlap <#i005>
> * i006 - Destination of Seq faults <#i006>
> * i007 - RM Destination lacks a mechanism for cleanly
> terminating inbound sequences. <#i007>
> * i008 - Underlying protocol bindings <#i008>
> * i009 - "Duplicate Elimination" and "Message Ordering" <#i009>
> * i010 - Can AckRequested be sent independently or not <#i010>
> * i011 - Editorial issues from eBusinss Asia Committee <#i011>
> * i012 - Anonymous and AcksTo EPR scenarios <#i012>
> * i013 - SequenceAcknowledgement protocol response for AcksTo =
> wsa:anonymous <#i013>
> * i014 - Composition with WS-Addressing <#i014>
> * i015 - RMD polling <#i015>
> * i016 - 2nd Protocol Invariant, none and nack <#i016>
> * i017 - What is the purpose of the WSDL? <#i017>
> * i018 - Piggyback message combinations <#i018>
> * i019 - Use of AckRequested <#i019>
> * i020 - Message ordering and duplication <#i020>
> * i021 - Piggy-backing problematic <#i021>
> * i022 - RMD cannot detect some incomplete Sequences <#i022>
> * i023 - CreateSequenceRefused fault should apply to sender and
> receiver <#i023>
> * i024 - When to send CloseSequenceResponse vs.
> SequenceClosedfault <#i024>
> * i025 - wsrm-1.1-schema-200608.xsd is invalid <#i025>
> * i026 - Retransmission <#i026>
> * i027 - Where do Sequence Faults go when the RMS is anonymous
> <#i027>
> * i028 - MakeConnection preconditions are unclear <#i028>
> * i029 - Opaqueness of URI identifiers not preserved by RM anon
> URI <#i029>
> * i030 - Facilities to support optional MakeConnection
> underspecified <#i030>
> * i031 - Scope of MakeConnection is unconstrained <#i031>
> * i032 - back-channel nit <#i032>
> * i033 - back-channel not defined <#i033>
> * i034 - Define gap <#i034>
> * i035 - Delivery Assurances <#i035>
> * i036 - Compliance vs. Conformance <#i036>
> * i037 - Policy Assertions Must be Independent <#i037>
>
>
> New Issues Summary
>
> id owner title protocol type
> i037 <#i037> Policy Assertions Must be Independent ws-rmp design
>
>
> Active Issues Summary
>
> id owner title protocol type
> i007 <#i007> RM Destination lacks a mechanism for cleanly terminating
> inbound sequences. ws-rm design *
> i009 <#i009> "Duplicate Elimination" and "Message Ordering" ws-rm
> design
> i020 <#i020> Message ordering and duplication ws-rm design
> i021 <#i021> Piggy-backing problematic ws-rm design *
> i022 <#i022> RMD cannot detect some incomplete Sequences ws-rm
> design *
> i035 <#i035> Delivery Assurances ws-rm design
>
>
> Pending Issues Summary
>
> id owner title protocol type
> i001 <#i001> WS-Addressing comment on ws-rm related to use of extended
> anonymous uri ws-rm design
> i002 <#i002> WS-RM editorial comment concerning MakeConnection
> ws-rm editorial
> i003 <#i003> WS-Addressing comment/question related to WS-RM
> MakeConnection ws-rm editorial
> i004 <#i004> Editorial comments ws-rm, ws-rmp editorial
> i005 <#i005> Seq Ack Ranges overlap ws-rm design
> i006 <#i006> Destination of Seq faults ws-rm editorial
> i010 <#i010> Can AckRequested be sent independently or not ws-rm
> design
> i012 <#i012> Anonymous and AcksTo EPR scenarios ws-rm design
> i013 <#i013> SequenceAcknowledgement protocol response for AcksTo =
> wsa:anonymous ws-rm design
> i015 <#i015> RMD polling ws-rm, ws-rmp design
> i016 <#i016> 2nd Protocol Invariant, none and nack ws-rm design
> i017 <#i017> What is the purpose of the WSDL? ws-rm design
> i018 <#i018> Piggyback message combinations ws-rm design
> i023 <#i023> CreateSequenceRefused fault should apply to sender and
> receiver ws-rm design
> i024 <#i024> When to send CloseSequenceResponse vs.
> SequenceClosedfault ws-rm design
> i025 <#i025> wsrm-1.1-schema-200608.xsd is invalid ws-rm design
> i026 <#i026> Paul Fremantle Retransmission ws-rm design
> i027 <#i027> Paul Fremantle Where do Sequence Faults go when the RMS
> is anonymous ws-rm design
> i028 <#i028> Jonathan Marsh MakeConnection preconditions are unclear
> ws-rm design
> i029 <#i029> Jonathan Marsh Opaqueness of URI identifiers not
> preserved by RM anon URI ws-rm design
> i030 <#i030> Jonathan Marsh Facilities to support optional
> MakeConnection underspecified ws-rm design
> i031 <#i031> Jonathan Marsh Scope of MakeConnection is unconstrained
> ws-rm design
> i032 <#i032> Bob Freund back-channel nit ws-rm editorial
> i033 <#i033> Bob Freund back-channel not defined ws-rm editorial
> i036 <#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 <#i008> Underlying protocol bindings ws-rm design
> i011 <#i011> Editorial issues from eBusinss Asia Committee ws-rm
> editorial
> i014 <#i014> Composition with WS-Addressing ws-rm design
> i019 <#i019> Use of AckRequested ws-rm design
> i034 <#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
> <http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0015.html>
> 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
> <http://www.w3.org/2002/ws/addr/cr-issues/overview.html#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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> W3C WS-Addressing WG
> <http://www.oasis-open.org/archives/ws-rx-comment/200609/msg00000.html>
> Proposal 1
> <http://lists.oasis-open.org/archives/ws-rx/200609/msg00014.html>
> 2006-09-25
> Proposal 2
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00016.html> 2006-10-19
> Revised from original
> <http://lists.oasis-open.org/archives/ws-rx/200610/msg00065.html>.
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> W3C WS-Addressing WG
> <http://www.oasis-open.org/archives/ws-rx-comment/200609/msg00001.html>
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/document.php?document_id=20491>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> W3C WS-Addressing WG
> <http://www.oasis-open.org/archives/ws-rx-comment/200609/msg00003.html>
> Proposal 1
> <http://lists.oasis-open.org/archives/ws-rx/200610/msg00053.html>
> 2006-10-10
> Proposal 2
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00066.html>
> 2006-10-19
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/20816/MinutesWSRX-101906.html>
> 2006-10-19
> Proposal 2 accepted on Oct. 19th TC call.
>
> i004 * Editorial comments * spec - editorial - Pending
>
>
> Description
>
> Comments from Gil
> <http://lists.oasis-open.org/archives/ws-rx/200610/msg00054.html>
>
> Comments from Marc
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00092.html>
>
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> ws-rmp revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec-cd-04.pdf>
>
> Related Issues
> Origin
> Gilbert Pilz
> <http://lists.oasis-open.org/archives/ws-rx/200610/msg00054.html>
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00113.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Doug Davis
> <http://lists.oasis-open.org/archives/ws-rx/200610/msg00062.html>
> Proposal 12006-10-19
> Change it to a MUST NOT
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00113.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Doug Davis
> <http://lists.oasis-open.org/archives/ws-rx/200610/msg00064.html>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00113.html> 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
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00113.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200701/msg00023.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00113.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Proposal 1
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200611/msg00007.html>
> 2006-11-01
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00110.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00110.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00134.html> 2006-11-14
> Proposal 2
> <http://lists.oasis-open.org/archives/ws-rx/200611/msg00202.html>
> 2006-11-17
> Resolution
> <http://www.oasis-open.org/committees/download.php/21521/wsrxMinutes-1207>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00152.html> 2006-11-14
> Proposal 2
> <http://lists.oasis-open.org/archives/ws-rx/200611/msg00202.html>
> 2006-11-17
> Resolution
> <http://www.oasis-open.org/committees/download.php/21521/wsrxMinutes-1207>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00153.html> 2006-11-14
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21335/MinutesWSRX-111606.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> ws-rmp revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec-cd-04.pdf>
>
> Related Issues
> Origin
> eBusinss Asia Committee
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00002.html>
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Paul Fremantle
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00075.html>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00110.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Jonathan Marsh
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00077.html>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Sadao Yashiro
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00003.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200612/msg00026.html> 2006-12-17
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200701/msg00017.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Sadao Yashiro
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00003.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00151.html> 2006-11-14
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21335/MinutesWSRX-111606.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Sadao Yashiro
> <http://www.oasis-open.org/archives/ws-rx-comment/200610/msg00003.html>
>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00088.html>.
>
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Gilbert Pilz
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00088.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00088.html> 2006-10-20
> Proposal 2
> <http://www.oasis-open.org/archives/ws-rx/200701/msg00021.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Gilbert Pilz
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00089.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00089.html> 2006-10-20
> Proposal 2
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00090.html> 2006-10-21
> Proposal 3
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00112.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Marc Goodner
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00093.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00093.html> 2006-10-21
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21335/MinutesWSRX-111606.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Marc Goodner
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00094.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00094.html> 2006-10-21
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00113.html> 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...
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00111.html>
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Eric Rajkovic
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00111.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200610/msg00111.html> 2006-10-24
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21335/MinutesWSRX-111606.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Paul Fremantle
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00030.html>
> Owner
> Paul Fremantle
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00030.html> 2006-11-02
> Proposal 2
> <http://lists.oasis-open.org/archives/ws-rx/200612/msg00034.html>
> 2006-12-14
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Paul Fremantle
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00031.html>
> Owner
> Paul Fremantle
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Jonathan Marsh
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00055.html>
> Owner
> Jonathan Marsh
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00056.html> for
> description.
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Jonathan Marsh
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00056.html>
> Owner
> Jonathan Marsh
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00057.html> for
> description.
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Jonathan Marsh
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00057.html>
> Owner
> Jonathan Marsh
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00058.html> for
> description.
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Jonathan Marsh
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00058.html>
> Owner
> Jonathan Marsh
> Resolution
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Bob Freund
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00069.html>
> Owner
> Bob Freund
> Resolution
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00110.html> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Bob Freund
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00070.html>
> 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
> <http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Paul Fremantle
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00001.html>
> Owner
> Paul Fremantle
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00148.html> 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
> <http://lists.oasis-open.org/archives/ws-rx/200611/msg00198.html>
> Raised against / Related drafts
> ws-rm revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Kevin Houstoun
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00198.html>
>
> 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
> <http://docs.oasis-open.org/ws-rx/wsrm/200608/wsrm-1.1-spec-cd-04.pdf>
> Related Issues
> Origin
> Pete Wenzel
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00199.html>
> Owner
> Pete Wenzel
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200611/msg00199.html> 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
> <http://www.oasis-open.org/archives/ws-rx/200701/msg00019.html>
> Raised against / Related drafts
> ws-rmp revision: cd04
> <http://docs.oasis-open.org/ws-rx/wsrmp/200608/wsrmp-1.1-spec-cd-04.pdf>
>
> Related Issues
> Origin
> Ashok Malhotra
> <http://www.oasis-open.org/archives/ws-rx/200701/msg00019.html>
> Proposal 1
> <http://www.oasis-open.org/archives/ws-rx/200701/msg00019.html> 2006-01-05
>
>
> Action Item Complete Listing
>
--
Paul Fremantle
VP/Technology and Partnerships, WSO2
OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
(646) 290 8050
"Oxygenating the Web Service Platform", www.wso2.com
