Preliminary WS-RX Face to Face Minutes

Thurs September 22, PM Minutes

Minutes Style Conventions

Motion text

§ Motion Resolution text

Ų Action item text

Ų Potential new issue Text:

15 New issues since last con call

Marc G posted his summary at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00239.html

15.1Proposed-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>

Chris F: I do not think this is a problem. However, I do not have problem with the issue wording.

No objection to accepting proposed 1 as a new issue.

15.2Proposed-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>

Chris F proposed that this be turned into an editorial action item.

Jonathan: the reference is to a particular version of WS-addressing.

Paul F: since there is discussion, this should be raised as an issue.

No objection to accepting Proposed 02 as a new issue.

15.3Proposed-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>

Paul C: some specs refer to both rfcs. It is unclear is ws-addressing has done it correct.

Paul C: 2396 is standard def of URI/URL for long time. The IETF approved replacement standard 3986. At the same time IETF published 3987 for IRI (which refers to 3986).

No objection to accepting Proposed 04 as a new issue.

15.4Proposed-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>

Ų ACTION: Editors to incorporate proposed 04 from Seattle F2F as an edit to the draft.

15.5Proposed-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>

Chris F: RFC 2119 does not require upper case, however it is a convention. If any was not in the rfc 2119 sense we need to use a different word.

Doug B: some of the uses of the word optional are really cardinality constraints. The cardinality issue regards the whole spec.

Doug B will raise a separate issue on the cardinality.

Ų ACTION: editors to incorporate edits in Proposed 05 from Seattle F2F into draft spec..

15.6Proposed-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>

Agreed to accept proposed 06 as a new issue.

15.7Proposed-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>

Agreed to accept proposed 07 as a new issue.

15.8 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>

Agreed to accept proposed 08 as a new issue.

15.9 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>

No longer relevant. Do not accept as new issue.

15.10 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>

Chris F stated he needed to check the spec first.

Agreed to accept proposed 10 as a new issue.

15.11 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>

Ų ACTION: editors to incorporate proposed 11 from Seattle F2F into the draft spec.

15.12 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>

Ų ACTION: editors to incorporate propose 12 from Seattle F2F as editorial in draft spec.

15.13 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>

Paul C: this change will really affect the change bars. It should be done in its own spec.

Chris F: this should be done after the first CD. But I do not like the order selected.

Agreed to accept proposed 13 as new issue.

15.14 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>

Agreed to accept proposed 14 as a new issue.

16 Schedule for Candidate CD

Doug D presented the editors plans

Editors plans:

  Working Drafts:

    - 2 versions will be posted, one w/change bars, one w/o

    - Timing of WDs will be based on editor's judgement.

      (When enough but not overwhelming number of changes have occurred)

  Committee Drafts:

    - 2 versions will be posted, one w/change bars, one w/o

Next WD will be posted on Sept. 30th and will include all 'editor pending' issues assigned to the editors by Sept 22.

CD candidate will be posted on Oct. 7th, and change bars will be based on diff w/OO version of submitted docs

Paul F: we can vote the Candidate CD to CD on OCT 20.

17 Thurs PM issue discussions

17.1 Issue 32 – serialization Optimization

Description

I've been thinking a bit about how we might optimize the serialization of the elements in the protocol; doing so without actually changing the abstract properties of the protocol itself.

Here's what we have today:

<wsrm:Sequence

xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@";>

<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

<wsrm:MessageNumber>1</wsrm:MessageNumber>

<wsrm:LastMessage/>

</wsrm:Sequence>

I think that if the properties were serialized as attributes, we would have a much more compact serialization:

<wsrm:Sequence

xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"

seqID="http://example.org/mysequence/1234"; msgNum="1"

last="true"/>

The serilaization savings for a Sequence element is 91 bytes per message.

For the SequenceAcknowledgement, we could collapse the acknowledgement range elements into a single attribute value that was a sequence of integers. e.g in the simplest case, here would be an example SeqAck:

<wsrm:SequenceAcknowledgement

xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"

seqID="http://example.org/mysequence/1234"; ranges="1 1 3 10">

where the @ranges attribute is a list of unsignedLongs. e.g.

<xs:simpleType name='rangeType'>

<xs:list itemType='xs:unsignedLong'/>

</xs:simpleType>

The ranges are expressed as "low hi low hi low hi ..."

In the example above, message #2, 3 and 4 are missing. Here's an example of a nack:

<wsrm:SequenceAcknowledgement

xmlns:wsrm="http://docs.oasis-open.org/wsrx/@@@"

seqID="http://example.org/mysequence/1234"; nack="2 3 4">

The savings on the SequenceAcknowledgement are 99 bytes/message using the optimized

serialization for a SequenceAcknowledgement with no gaps, 148 bytes for one with one gap,

195 bytes for one with two gaps, and 242 for one with three. Basically, it boils down to

an additional 47 bytes per gap (in this case using namespace prefix of wsrm) or 42 bytes

using the default namespace.

Justification

The point of this proposal is not limited to byte savings of serialization.

Rather, it has more to do with the efficiency with which the protocol properties can be

serialized and deserialized. Especially with the @range attribute, there are far fewer nodes

involved.

In terms of creation/serialization performance, I found an average savings in serialization

(using java) of:

Sequence - .0478 ms

SequenceAcknowledgement (with 2 gaps) - .19765 ms

I haven't had a chance to assess parsing performance benefits yet, but I have to imagine that

there would be some benefit.

Sure, scoff if you will, but in the context of an server implementation processing a

gazillion messages, the performance savings are non-trivial.

Think about providing RM support for a customer such as a Ford or FedEx.

The sheer volume of messages that they expect to be able to process daily is mind-boggling.

Of course, in the context of a message with a WS-Security header, the RM performance and

bandwidth overhead pales in comparison for the processing of the overall message, but IMO,

there's no reason that RM should exacerbate the issue. If there is a performance and

bandwidth optimization that we could effect without actually changing the protocol, I think

we should give it serious consideration.

As for extensibility, we could still have the Sequence and SequenceAcknowledgement elements

extensible via both attributes and elements. There's no reason to change that.

Related Issues

Origin

Chris Ferris

Owner

Chris Ferris

Proposal 12005-08-30

This isn't fully fleshed out in terms of line numbers and prose, etc. However, the gist

would be to have the protocol elements be as follows:

<wsrm:Sequence seqID="[xs:anyURI]"

msgNum="[xs:unsignedLong]"

last="[xs:boolean]"? .../>

<xs:simpleType name='rangeType'>

<xs:list itemType='xs:unsignedLong'/>

</xs:simpleType>

<wsrm:SequenceAcknowledgement seqID="[xs:anyURI]"

[ranges="[wsrm:rangeType]"|nack="[wsrm:rangeType]"] .../>

<wsrm:AckRequested seqID="[xs:anyURI]"

msgNum="[xs:unsignedLong]"? .../>

Chris F presented the Issue and the proposed solution, using attributes as opposed to elements. This results in an optimization in total octets transmitted which grows with the number of gaps. It also results in less text nodes in DOM api processing..

Doug B: I object to this proposal, and suggest we close with no action. This is an early optimization of a small part of messages. The size of payloads is much more significant. We could also employ ITU-T fast infoset, or any w3c binary encoding. This also allows improper combinations of attributes, which were not allowed in the previous element based Schema.

Chris F: I disagree with the importance of this optimization. With an RM processor in the middle of a processing sequence, it could become a bottleneck.

Vadim: this needs to be taken in the context of the entire processing chain.

Sanjay: I see this may help timings. Does anyone have a reason not to accept this optimization.

Paul C: the timings were from one implantation, it is not clear that our implementation will benefit form this. It results in a long attribute list.

Hamid: I agree with Paul C.

Hamid: I move to close this issue with no action. Motion failed for lack of a second.

Paul C: I am skeptical that this would be a useful proposal, but would like to try this out in our implementation.

Jonathan: text nodes in DOM is not the only criteria. Other APIs do not have that limitation.

Paul C: this proposal also makes it more difficult to use XPath to find things. This is a price to pay in moving from elements to attributes.

Jonathan: we need to be concerned about the impact on validation.

Chris F: but some constraints are already not enforced by schema (e.g, upper greater or equal to lower).

There was considerable additional discussion on the tradeoffs associated with such optimizations.

Chris F: the new proposal is easier to canonicalize. There is less white space in the proposal.

Paul F: it is premature for a vote. Perhaps a straw poll

Bob F: I need more time before I am ready for a straw poll.

Paul C: how about< like it, Hate it, Need more time>

Straw poll

Like it – 3

Hate it – 7

Needs more time – many hands

Paul F: we should take this discussion to the email list. TC members should do the research to determine its affect on their implementation.

Paul C: how long do we have.

Paul F: I propose we give TC members a month to make their determination.

17.2 Issue 33 - nack processing

Description

Although it is assumed that a NACK will trigger

retransmission of a given message from the source to the destination

there is no wording in the current version of the spec that describes

this feature adequately.

Justification

This will clarify to implementers the spirit of the spec

by spelling out in more concrete terms what is currently only implied.

Related Issues

Origin

Steve Winkler

Proposal 12005-09-08

Add the following to the spec directly before the text that is

incorporated as a resolution to i005:

Upon the receipt of a Nack, an RM Source SHOULD retransmit the message

identified by the Nack as soon as possible.

Chris F: we think it should be a MUST rather than SHOULD, except for error case.

Anish: I support SHOULD. There is a case when a NACK and ACK for the same message may arrive de-ordered in transit. RMS will se ack first, followed by NACK, and could conclude it does not have to resend.

Steve W: that is covered by resolution for Issue 5.

Anish: That covers the rmd sending, I am concerned with the RMS receiving.

Paul F: we could make it a MUST, with several caveats.

Shivaji: the SHOULD is a better solution than explaining all the corner points which we might not have thought of yet.

Lei: I also agree with SHOULD.

Serge: keep SHOULD, and make a reference to the exception in the spec.

Shivaji: If we try to cover every exception you might paint yourself into a corner.

Martin C: I move we adopt Steve W proposal to close issue 33, striking “as soon as possible”, seconded by Marc G.

Vote:

20 yes

1 no

9 abstain

Motion passes

§ RESOLUTION: Issue 33 closed by incorporating new text “Upon the receipt of a Nack, an RM Source SHOULD retransmit the message identified by the Nack”.

17.3 Issue 34 – Faults and piggybacking

Description

In Section 3.2 of the spec, it states that 'The

header block MAY be transmitted independently,

or included on return messages'. A similar statement is made in Section

3.3, 'The RM Source endpoint requests this Acknowledgment by including

an <AckRequested> header block in the message'. In both cases, the

header can be piggy-backed on a message going to the relevant endpoint.

If during the processing of this header, a fault occurs, the spec does

not state what should happen. Consider the case where an AckRequested

is piggy-backed on a non WS-RM message that happens to be going to the

correct endpoint. If the AckRequested turns out to be for an

UnknownSequence, the spec states that the fault processing should be as

per WS-Addressing, however any EPRs defined in the message are

potentially application EPRs and not WS-RM EPRs, so sending a fault to

the applications FaultTo EPR may not be the correct thing to do.

Justificatio

The piggy-backing of headers is an optimization and as

such, it is questionable whether their processing should affect the

processing of the original message. The spec should be clear on the

expected behaviour of the RM Source and the RM Destination in these

cases.

Related Issues

Origin

Daniel Millwood

Proposal 12005-09-08

Change the wording of the spec to be along the lines of "If a

fault occurs when processing an RM Header that was piggy-backed on

another message, a fault MUST be generated, but the processing of the

original message MUST NOT be affected.

Paul F suggested the TC accept proposal but leave it to the editors to add sufficient words to cover the case of must understand Fault.

Doug D moved and Steve W moved to accept the proposal, and also to instruct editors to add sufficient words to cover the case of mustUnderstand Faults.

Marc G: I would prefer to see the text.

Anish moves to amend the proposal as follows, Doug D seconded

"If a non-mustUnderstand fault occurs when processing an RM Header that was piggy-backed on another message, a fault MUST be generated, but the processing of the original message MUST NOT be affected.

No objection to amendment.

§ Resolution: amendment passes.

No objection to amended motion.

§ RESOLUTION: Issue 34 closed with amended proposal.

17.4 New proposed issue 13

Marc G this should be done after the CD.

Chris F: we already agreed to postpone its incorporation after the First CD.

Doug D proposal:

1) Change the order to be:

        CreateSequence

        Sequence header

        ReqAck header

        SeqAck header

        CloseSequence

        TerminateSequence

Chris F: I prefer to put the lifecycle stuff first

2) Change the order to be:

        CreateSequence

        CloseSequence

        TerminateSequence

        Sequence header

        ReqAck header

        SeqAck header

Abbie moves to close the issue proposed 13 with version 2) above. Seconded by Steve.

Straw poll

Current - 0

1) 8

2) 7

Serge: proposal 2 describes the context of a sequence, before using the concept.

Umit: proposal 1 will reduce forward references.

No objections to proposal 2.

Motion passes.

§ Resolution: Close new Proposed 13 issue with proposal 2) above.

17.5 New proposed issue 01

Anish proposed solution:

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.

Chris F: As I already stated I do not see a problem which needs to be corrected.

Anish: what is the reason to have the RMD provide the sequence identifier.

Chris F: if the destination generates them, it can ensure it will not generate a duplicate. That is the primary reason. If you set activity timeout, you can throw away not used sequences.

Stefan: This proposal breaks the existing uniqueness test for identifier. Two RMS requesngt same Sequence ID is more possible with Anish proposal.

Anish: suppose people use message ID scheme for unique URIs. This will ensure no overlaps.

Stefan: the current protocol takes care of this duplication problem.

Abbie: I do not see the benefit of Anish’s proposal of rms generated sequence ID. This causes new security problems.

Paul F: what about two create sequence with same ID with different Ack To header.

Jacques: To address Anish concern without extra signaling. Assuming a create sequence response can be correlated with create sequence request, the RMS can detect it got several create sequence responses for the same requested sequence ID. It is possible for the RMS to do this with the current protocol.

Anish: what part of wsa is normative? If we say all of ws-addressing is normative.

Chris F: I again ask Anish why he thinks this is a problem, worth adding all these extra mechanisms. We have something which does not have problems, with the minor annoyance of an occasional Idle sequence, which can be terminated.

Abbie Moves to close new proposed issue 01 with no change, Marc G seconded.

Serge: perhaps we can explore strategies to recover such idle sequences.

Paul F: this is a recursive problem. Making the create sequence more reliable before we start processing reliably is a problem. That is the problem with the Anish proposal. It is a minor annoyance to have an idle sequence established. It does not warrant changing the spec.

Anish: I disagree with the characterization of this as recursive. I wanted to understand why the submitters went the way they did. We did not talk about RMD allowing to override identifier proposed by RMS. I could agree to close with no action.

No objections to accept Abbie’s motion.

§ RESOLUTION: New proposed issue 01 closed with no change.

18 Meeting Closure

Action Items from this meeting already completed http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00247.html

S1 done

S10 done.

Tom Rutt agreed to post the open action items to Kavi by Monday.

Paul F commended the TC members for resolving many issues.

The TC commended Microsoft for the fine Hosting arrangements.

The TC commended the Chairs for running the meeting.

Motion to adjourn from Umit, seconded by Chris F.

Meeting adjourned at 4:05 PM Pacific Time.

ws-rx message

15 New issues since last con call

15.1Proposed-01

15.2Proposed-02

15.3Proposed-03

15.4Proposed-04

15.5Proposed-05

15.6Proposed-06

15.7Proposed-07

15.8 Proposed-08

15.9 Proposed-09

15.10 Proposed-10

15.11 Proposed-11

15.12 Proposed-12

15.13 Proposed-13

15.14 Proposed-14

16 Schedule for Candidate CD

17 Thurs PM issue discussions

17.1 Issue 32 – serialization Optimization

17.2 Issue 33 - nack processing

17.3 Issue 34 – Faults and piggybacking

17.4 New proposed issue 13

17.5 New proposed issue 01

18 Meeting Closure