OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: New proposed issues 9/15 - 9/20


Here are all of the new issues since the last conference call. As always please review if you have proposed any new issues to make sure they are reflected here. - Regards, Marc g

Proposed-01
Title:
Duplicate detection of wsrm:CreateSequence messages
Description:
wsrm:CreateSequence messages can be duplicated, delayed a/o resent by the RMS (for lack of response or lost CreateSequenceResponse). Therefore it is possible that one RMS create Sequence request message may result in creation of multiple (spurious) Sequences at the RMD. Each Sequence at an RMD may require resource reservation resulting in excessive resource utilization or unnecessary refusal from RMD to create new (legitimate) Sequences.
Justification:
WSRM spec is created to reliably deliver messages in an unreliable environment, where message may be lost, duplicated, delayed or received out-of-order. This unreliable environment applies not only to payload message but also to protocol signal messages such as wsrm:CreateSequence/wsrm:CreateSequenceResponse messages.
Typically on receiving a wsrm:CreateSequence message, the RMD reserves resources for the sequence (when it does not generate a fault) and responds with a wsrm:CreateSequenceResponse.
It is possible that the underlying network duplicates/delays/loses the wsrm:CreateSequence message OR it is possible that the RMS resends wsrm:CreateSequence message for a lack of response (or because the wsrm:CreateSequenceResponse message was delayed or lost). In such a scenario the RMD may end up unnecessarily reserving resources (till the expiration time/inactivity Timeout of the Sequence) for Sequences that were never requested. This may result excessive resource utilization or refusal of legitimate Sequence request because of spurious requests taking up all the RMS resources.
Target: core
Type: design
Proposal:
Require that the RMS include the wsrm:Identifier in the wsrm:CreateSequence request. I.e RMS decides on the identifier for the Sequence rather than the RMD. RMD merely echos the wsrm:Identifier in the wsrm:CreateSequenceResponse that was present in the wsrm:CreateSequence message (or faults).
If it is essential that the RMD generate the wsrm:Identifier for the Sequence (and I would like to understand why that is so -- I have some idea of why that may be the case, but not sure if that is the reason why it is so), then a different approach will have to be taken. Something along the lines of:
-- require the RMS to specify a suggested wsrm:Identifier in the CS and allow the RMD to ok that or override it in the CSR message.
Related issues: none
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
<http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00190.html> 
 
Proposed-02
Title: WS-Addressing Endpoint redefined in WSRM
Description:
Section 2.1 defines the term 'Endpoint'. This is the same definition used by WS-Addressing [1] in section 1. Instead of defining this term again in WSRM, just point to the ws-addr document.
Justification:
In the spirit of composability and defining something once and reusing it, it makes sense to just refer to the WS-Addressing definition. This also protects us from minor changes in definition in the ws-addr spec (which is not final yet).
Target: core
Type: editorial
Proposal:
Replace the current definition by a reference to the WS-Addr spec.
Related issues: none
[1] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00194.html> 
 
Proposed-03
Title: 2396 is obsoleted by 3986
Description:
There are several reference to RFC 2396. This RFC is obsoleted by RFC 3986.
Justification:
RFC 2396 is obsoleted by RFC 3986.
Target: all
Type: design
Proposal:
Either replace 2396 with 3986 OR like WS-Addressing, move to IRIs (RFC 3987).
Related issues: none
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
<http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00195.html> 
 
Proposed-04
Title: What does 'have a mustUnderstand attribute' mean?
Description:
Lines 270-272 talk about wsrm:Sequence having a mustUnderstand attribute to ensure that the RMD understands it. What it really should say is: have a mU attribute with a value of '1/true'.
Justification:
Lines 270-272 in [1] say:
"... The <wsrm:Sequence> element MUST have a mustUnderstand attribute from the namespace corresponding to the version of SOAP to which the <wsrm:Sequence> SOAP header block is bound."
Having a mU attribute does not ensure that the RMD will understand the SOAP header, since the value of the attribute can be '0/false'.
Target: core
Type: editorial
Proposal:
Change it to say: "... mustUnderstand attribute with a value of 1/true ..."
Related issues: none
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
<http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00204.html> 
 
Proposed-05
Title: Change 'optional' and 'required' in section 3 to RFC 2119 OPTIONAL and REQUIRED
Description:
Section 3 uses 'optional' and 'required' to mean the same thing as 'optional' and 'required' in RFC 2119. To keep the style consistent, these should be capitalized.
Justification:
Section 3 uses 'optional' and 'required' to mean the same thing as 'optional' and 'required' in RFC 2119. To keep the style consistent, these should be capitalized.
For example: page 15 line 342, page 15 line 336 in [1].
Target: core
Type: editorial
Proposal:
Change all occurrences of 'required' to 'REQUIRED' and 'optional' to 'OPTIONAL' in section 3.
Related issues: none
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
<http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00205.html> 
 
Proposed-06
Title: Presence of NACK and ACK range in the same message
Description:
Page 15, lines 344-345 say:
"This element MUST NOT be present if <wsrm:Nack> is also present as a child of <wsrm:SequenceAcknowledgement>."
Given that there can be multiple SeqAck headers in a message, this is true only for the same header and not across headers.
Justification:
WSRM allows multiple SeqAck headers, therefore one can Nack sequence "A" in one header and Ack Sequence "B" in another header in the same message.
Target: core
Type: editorial
Proposal:
Replace the sentence in question with "... MUST NOT be present if a sibling <wsrm:Nack> element is also present ..."
Related issues: none
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00208.html> 
 
Proposed-07
Title: Which version of WS-Addressing spec?
Description:
Page 25, lines 664-665 at [1] says:
"WS-ReliableMessaging faults MUST include as the [action] property the default fault action URI defined in the version of WS-Addressing used in the message."
This can be interpreted as any version of WS-Addressing is allowed with WSRM. WSRM spec should specify which version of WS-Addressing is used by the spec.
A related issue is that:
On page 25, lines 664-666 talk about the default "http://schemas.xmlsoap.org/ws/2004/08/addressing/fault";; as the Fault [action] property. This default is defined only for the SOAP binding and is meant to be used with WS-Addr faults not WSRM faults.
Justification:
Without clearly indicating which version of WS-Addressing is required/used by the spec, independent implementation will not interoperate. WS-Addressing specification has changed substantially (in certain sections/artifacts of the WS-Addressing spec) over the years.
Target: core
Type: design
Proposal:
Use the CR version of the spec [2] (in this paragraph as well as the normative reference for the spec) for now and make changes as the addressing spec transitions through the process of becoming a REC. Based on the WS-Addr schedule and WSRM schedule, WS-Addr is slated to become a REC before WSRM is final.
For the related issue:
change line 664 from --
"WS-ReliableMessaging faults MUST include as the [action] property the default fault"
to --
"WS-ReliableMessaging faults MUST include as the [action] property as defined by WS-Addressing [ref]."
and
delete lines 665-667
Related issues: none
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
[2] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00209.html> 
 
Proposed-08
Title: Why is wsa imported in the WSDL?
Description:
On page 49, lines 156-1358 in [1], there is a schema import of the wsa namespace in the wsdl:types section. Why is this needed?
Justification:
The wsa element/types are not used by the schema (embedded in the WSDL) or used in the definition of any of the message constructs. The only place it is used is for wsa:Action (as a WSDL 1.1 extensible attribute). To do that, it is not necessary to schema import the namespace.
Target: wsdl
Type: editorial
Proposal:
Remove the xs:import that imports wsa namespace.
Related issues: none
[1] should point to:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
 
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00210.html> 
 
Proposed-09
Title: Schema does not contain SecurityTokenRereference
Description:
Schema in Appendix A does not contain SecurityTokenRereference but section 3.4 does.
Justification:
Inconsistency between the spec and the schema.
Target: core, schema
Type: editorial
Proposal:
Once issue i029 is resolved, either fix the schema or the spec so that they match.
Related issues: i029
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00211.html> 
 
Proposed-10
Title: SequenceFault element refers to fault code rather than fault [Subcode]
Description:
On page 27, line 745 at [1] refers to fault code rather than fault [Subcode].
Justification:
Fault codes are either Sender or Receiver which map to S11:Client or S11:Server for SOAP 1.1. The text in question is actually talking about the fault [Subcode]s that are defined subsequently.
Target: core
Type: editorial
Proposal:
Either:
1) refer to fault [Subcode] instead of fault code
Or:
2) refer to fault [Subcode] instead of fault code and change the element from wsrm:SequenceFault/wsrm:FaultCode to wsrm:SequenceFault/wsrm:FaultSubcode to match the abstract property that is being conveyed.
I prefer (2).
Related issues: none
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00213.html> 
 
Proposed-11
Title: Why is SecureConversation a normative reference?
Description:
SecureConversation is listed as a normative reference, but it is never referenced from anywhere (which needs to be fixed). More importantly, only the security considerations section talks about SecureConversation but in a non-normative way.
Justification:
A non-normative reference is listed under normative reference.
Target: core
Type: editorial
Proposal:
Include the [SecureConversation] reference wherever the Security Consideration section talks about it and move it to the non-normative reference section.
Related issues: none
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00214.html> 
 
Proposed-12
Title: Schema type of wsrm:FaultCode element can be changed from xs:QName to wsrm:FaultCodes
Description:
Page 37, line 1027 of [1] makes the type of wsrm:FaultCode as xs:QName. This element is already restricted to the QNames listed in the schema type wsrm:FaultCodes.
Justification:
Although the schema is correct, it would be more appropriate and narrowly/tightly scoped by using the type wsrm:FaultCodes instead of xs:QName
Target: schema
Type: editorial
Proposal:
Replace line 1027 from -
<xs:element name="FaultCode" type="xs:QName"/>
to -
<xs:element name="FaultCode" type="wsrm:FaultCodes"/>
Related issues:
Editorial issue about changing wsrm:FaultCodes to wsrm:FaultCodeType, raised in the email at [2]
[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf
[2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00193.html
Origin: Anish Karmarkar <Anish.Karmarkar@oracle.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00215.html> 
 
Proposed-13
Title: Reorder spec sections
Description:
The current order in which the RM spec talks about the protocol elements is: 
        Sequence header 
 
      SeqAck header 
        ReqAck header 
        CreateSequence 
        TerminateSequence 
        CloseSequence 
I'd like to reorder them based on how we actually expect people to use them. 
Justification:
Helps in understanding the spec.
Target: wsrm spec
Type: design
Proposal: 
Change the order to be: 
        CreateSequence 
        Sequence header 
        ReqAck header 
        SeqAck header 
        CloseSequence 
        TerminateSequence 
Related issues: none
 
Origin: Doug Davis <dug@us.ibm.com> 
 <http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00217.html> 
 
Proposed-14
Title: CloseSequenceResponse and Acks
Description:
Using the CloseSequence operation a RMS will be able to get the true final accounting of the ACKs for a sequence - sort of.  There is one case that could be problematic.  Let's say that the CreateSequence operation is given a bad AcksTo EPR.  In this case no Acks will ever be received by the RMS - and this could be the reason for it closing the sequence.  However, if all ACKs are always sent to the AcksTo EPR then the RMS will have no choice but to eventually Terminate the sequence (or wait for it to timeout) without ever getting the true final accounting of Acks.  This would leave the RMS and RMD with a very different view of the state of the sequence.
Justification:
See above.
Target: wsrm spec
Type: design
Proposal:
To solve this I'd like to require that the CloseSequenceResponse message include the "final" Ack. 
So, using: 
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf 
Replace the text on line 608: 
  Upon receipt of this message the RM Destination MUST send a 
  SequenceAcknowledgement to the RM Source. 
With: 
  Upon receipt of this message the RM Destination MUST send a 
  SequenceAcknowledgement to the RM Source in the 
  CloseSequenceResponse message.
Related issues: i019, i028
 
Origin: Doug Davis <dug@us.ibm.com> 
<http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00218.html> 
 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]