[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx-editors] RX PR issue list update and MC issues
+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 paul@wso2.com (646) 290 8050 "Oxygenating the Web Service Platform", www.wso2.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]