Prelim Minutes of OASIS WS-RX Teleconference

June 15, 2006

Start Time:4:00 PM Eastern Daylight Time

Paul F acted as chair.

Textual Conventions

Ų Action Item

Motion

§ Resolution

1 Roll Call

From Kavi:

Over xx of voting members, meeting is quorate

Tom Rutt agreed to take minutes.

2 Agenda Approval

Agenda:

1) Roll Call

2) Review and Approval of the Agenda

http://www.oasis-open.org/apps/org/workgroup/ws-rx/event.php?event_id=11216

3) Approval of the June 8 Minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18670/MinutesWSRX-060806.html

4) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

5) TC Schedule tracking

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00008.html

6) New Issues since the last call

Watch for email

7) Issue discussion

i133 Duplicate text in fault section

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i133

i127 Make Accept/AcksTo consistent

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i127

i129 Define "discard"

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i129

i130 what does ack interval refer to

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i130

i122 security profiles

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122

i123 security profile agreement

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123

i124 security composition policy

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124

i121 security threats and requirements

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121

i125 Protocol precondition requires knowledge of policies

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125

i126 unclear text regarding wsa:Action

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i126

8) Any other business

Paul C suggested the security issue be moved together.

Paul F: Suggest to move 125 and 126 before 122.

No objection.

3 Approval of the 6/8 minutes;

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18670/MinutesWSRX-060806.html

The only change from prelim minutes was to change one quote from Doug D to Doug B.

Tom R moved, Doug B seconded to approve 6/8 minutes.

§ No objection minutes for 6/8 meeting approved.

4 AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

#0100: Tom Rutt & Bob volunteered to work on state table revisions with Jacques

Owner: Jacques Durand

Status: Still Open The proposal will be in step with the latest draft, and will not include polling.

Assigned: 2006-05-09

Due: ---

--------------------------------------------------------------------------------

#0102: Marc G will prepare to start an issues list for Public review comments

Owner: Marc Goodner

Status: Still Open

Assigned: 2006-05-22

Due: ---

--------------------------------------------------------------------------------

#0104: Gill will clarify his proposal for i121 to clarify the relationship between requirements and the threats

Owner: Gilbert Pilz

Status: Closed

Assigned: 2006-05-30

Due: ---

--------------------------------------------------------------------------------

#0105: editors to determine if issue 106 resolution has been incorporated into the WD.

Owner: Doug Davis

Status: closed, correct in latest editors draft.

Assigned: 2006-06-12

Due: ---

--------------------------------------------------------------------------------

5 TC Schedule tracking

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00008.html

From Paul F:

June 1st Editors produce a new WD

* June 8th TC implements new policy on issue list - highly restrictive

acceptance policy

To be clear, Robert's Rules is still in force, but the aim is that the TC focuses on removing bugs from the spec beyond this point.

* June 22nd Target for all issues closed

* June 29th Editors produce "release candidate" Working Draft

* July 6th TC review period done

* July 10th Editors produce final WD

* July 13th Open ballot on CD and PR

* July 20th Ballot closes

* July 24th Public review begins

* Sept 14th Interim WD with any PR comments folded in

* Sept 5-15 Online Interop

* Sept 22nd Public review ends

* Sept 28th New WD for review with all PR comments folded in

* Oct 5th Review ends

* Oct 9th CS ballot starts

* Oct 16th CS ballot ends

Paul F: the email list should be used more productively to save time on the calls.

6 New Issues since the last call

Marc G email http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00108.html

6.1 proposed-01 Consistent use of wsrm: in normative text

http://lists.oasis-open.org/archives/ws-rx/200606/msg00075.html

Title: Consistent use of wsrm: in normative text

Justification: we're inconsistent in the spec(s) when it comes to referencing RM elements. Sometimes we say "wsrm:SequenceAck" and sometimes we just say "SequenceAck". We need to be consistent in whether or not we use "wsrm:" - and also the font :-)

Proposal:

[flip of coin...] Change all references to RM elements to just the element name w/o the "wsrm:" and use the fixed (courier?) font.

e.g. "....the SequenceAcknowledgement element...."

Doug D: we would keep prefixes for other specs.

No objection to accept as new issue

Marc G moved to accept proposal to close proposed 01, seconded by Bob F.

§ No objection , agreed to close proposed 01 with proposal suggested.

6.2 proposed-02 RM SeqID Globally Unique

http://lists.oasis-open.org/archives/ws-rx/200606/msg00076.html

Title: RM SeqID Globally Unique

Justification:

in WD13.pdf, line 142 the spec says:

The RM Destination creates a new Sequence and returns its globally unique identifier.

That's the only spot we talk about the seqID being globally unique.

We do say that the Offered SeqID needs to be "unique" and we say that Sequence headers (acks...) MUST use unique seqID's but we never actually say that the seqID returned by the CS needs to be unique. To be explicit we should say that.

Proposal:

In WD13.pdf, line 286 says:

The RM Destination MUST set the value of this element to the absolute URI (conformant with RFC3986 [URI]) of the Sequence that has been created by the RM Destination.

I proposal we change it to:

The RM Destination MUST set the value of this element to the absolute URI (conformant with RFC3986 [URI]) that uniquely identifies of the Sequence that has been created by the RM Destination.

And remove the word "globally" from line 142 (the sample flow text). We should either not use the word 'globally' at all or use it for all instances of 'unique' - [flip coin]: I propose we remove it.

-Doug

Motion from Bob F to accept as new issue, and to close it with the proposal, seconded by Marc G.

§ No objections, proposed 02 closed with proposed resolution.

6.3 proposed-03 No mechanisms to convey that messages should be polled.

http://lists.oasis-open.org/archives/ws-rx/200606/msg00083.html

Title: Polling mechanism does not provide a way for the RMS to let the

RMD know that there are pending messages that should be polled.

Description/justification:

We have a polling mechanism that allows messages to be polled. This is

quite helpful for RMDs that are behind the firewall. But there is no

mechanism for the RMS to let the RMD know that there are messages that

the RMD should poll for. I.e., unless the RMD polls for a message, it

will not know whether it should have polled!

Having a mechanism for the RMS to let the RMD know that there are

pending messages is helpful in at least two scenarios:

1) RMD just polled for a message (perhaps because it periodically does

that), and would like to know if it should poll again because there are

additional pending messages. The RMD wants to minimize message delivery

delays, but the only way to do that is to increase the polling period,

which can result in unnecessary sending/receiving/processing of

messages. Given that the RMD has already polled for a message, it is

extremely convenient (with a minimal cost) to allow the RMS to inform

the RMD that there are additional message waiting.

2) The RMD and RMS have ongoing communication (not necessarily a

wsrm:MakeConnection), it is advantageous for the RMD to let the RMS know

that there are pending messages by allowing the pending status to be

piggy-backed on ongoing communication messages.

Core: core

Type: design

Proposal:

Outline of the proposal --

Allow two new headers wsrm:MessageStatusRequested and

wsrm:MessageStatus, which can be piggybacked on other messages, that

query and convey that there are pending messages.

<wsrm:MessageStatusRequested ...>

[<wsrm:Identifier> xs:anyURI </wsrm:Identifier>]?

[<wsrm:Address> xs:anyURI </wsrm:Address>]?

...

</wsrm:MessageStatusRequested>

<wsrm:MessageStatus pending="xs:boolean" ...>

[<wsrm:Identifier> xs:anyURI </wsrm:Identifier>]?

[<wsrm:Address> xs:anyURI </wsrm:Address>]?

...

</wsrm:MessageStatus>

-Anish

Jacques: why are two separate message header types required?

Anish: first header type is for the entity that is polling. Second header is for other direction to inform the rmd about pending status.

Doug D moved, Gil seconded to accept proposed 03 as new issue.

§ No objection, motion to accept proposed 03 as new issue.

There was discussion that the impact on the state table should be included in any proposal for this issue.

6.4 proposed-04 Offer/Accept elements are incomplete

http://lists.oasis-open.org/archives/ws-rx/200606/msg00084.html

Hi all,

Here is another new issue based off WD 13.

Thanks

Matt

Title - Offer/Accept elements are incomplete

Description:

The use of Offer/Accept to create an inbound sequence should carry

equivalent information as a CreateSequence/CreateSequenceResponse (in the

other direction). A simple test for this is to look at the child elements

of CreateSequenceResponse and compare them to Offer, and then apply the

same test to Accept & CreateSequence. Currently there are differences:

CreateSequenceResponse compared to Offer: (e.g. the information the RMD

transmits to the RMS)

Both have: Identifier, Expires

- These are ok, though the meaning of Expires is different, as on Offer it

is the RMD's decision, so this is a statement rather than the start of a

negotiation.

Offer has additional: Endpoint

- This is ok, and is a necessary addition (see i090)

CreateSequenceResponse has additional: AcknowledgementInterval,

IncompleteSequenceBehaviour

- The RMS should not dictate these settings, and we cannot assume that

they are the same as for the outbound sequence, so we should add these

elements to the Offer.

CreateSequence compared to Accept: (e.g. the information that the RMS

transmits to the RMD)

Both have: AcksTo

Accept has additional: none

CreateSequence has additional: Expires

- This is ok, as the RMD has the final say on Expiry. There is no need to

have a matching element in the Accept.

Justification

The Offer/Accept mechanism should have the same information exchange as a

CreateSequence/CreateSequenceResponse. If it does not then Offered

sequences are in some way less capable/flexible/well-defined as 'normal'

sequences, which seems inconsistent.

Target core, schema

Type: design

Proposal:

Add the following to the CreateSequence exemplar (surrounding lines shown

for context), there are 2 inserted lines:

<wsrm:Offer ...>

<wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

<wsrm:Endpoint> wsa:EndpointReferenceType </wsrm:Endpoint>

<wsrm:Expires ...> xs:duration </wsrm:Expires> ?

!! Insert from here

<wsrm:AcknowledgementInterval Milliseconds="xs:unsignedLong" ... /> ?

<wsrm:IncompleteSequenceBehavior> wsrm:IncompleteSequenceBehaviorType

</wsrm:IncompleteSequenceBehavior> ?

!! End of insert

...

</wsrm:Offer> ?

Add the following after line 250

/wsrm:CreateSequence/wsrm:Offer/wsrm:AcknowledgementInterval

This element, if present, specifies the duration after which the RM

Destination will transmit an acknowledgement. If omitted, there is no

implied value.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:AcknowledgementInterval/@Milliseconds

The acknowledgement interval, specified in milliseconds.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:AcknowledgementInterval/@{any}

This is an extensibility mechanism to allow additional attributes, based

on schemas, to be added to the element.

/wsrm:CreateSequenceResponse/wsrm:Offer/wsrm:IncompleteSequenceBehavior

This element, if present, specifies the behavior that the RM Destination

will exhibit upon the closure of an incomplete sequence.

A value of ?DiscardEntireSequence? indicates that the entire sequence will

be discarded by the RM

Destination if the sequence is closed when there are one or more gaps in

the SequenceAcknowledgement/Final.

A value of ?DiscardFollowingFirstGap? indicates that messages in the

sequence beyond the first gap will be discarded by the RM Destination when

there are one or more gaps in the

SequenceAcknowledgement/Final.

The default value of ?NoDiscard? indicates that no acknowledged messages

in the sequence will be discarded by the RM Destination.

Finally, the schema needs to be updated to introduce the 2 new child

elements to the Offer.

Matt: the proposal is to insert elements to give a symmetric view of the sequence and an associated OfferedSequence.

Marc G moved to accept proposed 04 as new issue, and to close with proposed resolution, Bob F seconded.

§ No objection, proposed 04 closed with proposed resolution.

7 Issue discussion

7.1 i133 Duplicate text in fault section

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i133

Marc G sent email message http://lists.oasis-open.org/archives/ws-rx/200606/msg00091.html

Jacques stated that such a fault could be generated by RMS. He would like to clarify that this proposal is for when the fault is generated by the RMD.

Jacques sent an updated proposal: http://lists.oasis-open.org/archives/ws-rx/200606/msg00119.html

Marc G: I am uncomfortable with some of changes proposed by Jacques.

Bob F: the role reversal of rms/rmd for offered sequences is becoming more symmetric as we finalize the spec.

Marc G: the text I proposed is close to the text which has been in the fault section for a long time. I am more comfortable not adding language about RMS and RMD.

Jacques: I guess my point might be raised as a new issue. I can accept the proposal from Marc G.

Matt moved to accept Marc G proposal to close i133, seconded by Marc G.

Sanjay: given new text

WSRMRequired is a fault generated by endpoints that require the use of WS-RM and receive a message that did not use the protocol

Can you use the same endpoint in to wsdls, one with wsrm required the other without.. This text should pertain to messages.

Doug D: If application receives message from underlying it could fault if not received reliability. I do not see this for individual messages.

Marc G: since assertion can apply to message level. Change endpoint to rm-destination.

Umit: also need to change second ½ of sentence.

Anish: add text “that require the use of rm on the received message”

Marc G: propose: amendment to bold sentence “WSRMRequired is a fault generated an RM Destination that requires the use of WS-RM on a received message that did not use the protocol.”

§ Amendment agreed.

§ Amended proposal passes to close i133.

7.2 i127 Make Accept/AcksTo consistent

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i127

Marc G moved to close 127 with proposal, Matt seconded.

§ No objection issue 127 closed with proposed resolution.

7.3 i129 Define "discard"

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i129

Doug D proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00100.html

Bob,

my concern over the current wording is that it wasn't clear to me exactly which messages would make it past the RMD - I think I know what it was trying to say but, for example, the definition of “DiscardEntireSequence” wasn't very clear that the RMD is _required_ to not send any messages on to the AD until the sequence is closed down (or terminated) so that it could see if there were any gaps. I do understand your concern over the word "delivered" but it does still live on in the spec - even after i106, it appears in the glossary among other places. And that definition is consistent with how its being used in the text I proposed. However, does this new text sound any better to you? (I tried to revert back to the original text as much as possible):

/wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior

This optional element, if present, specifies the behavior that the RM Destination will exhibit upon the closure, or termination, of an incomplete sequence. For the purposes of defining the values used, the term 'discard' refers to the RM Destination never allowing a particular message to be processed by the Application Destination.

A value of “DiscardEntireSequence” indicates that the entire Sequence MUST be discarded by the RM Destination if the Sequence is closed, or terminated, when there are one or more gaps in the final SequenceAcknowledgement.

A value of “DiscardFollowingFirstGap” indicates that the messages in the Sequence beyond the first gap MUST be discarded by the RM Destination if the Sequence is closed, or terminated, when there are one or more gaps in the final SequenceAcknowledgement.

The default value of “NoDiscard” indicates that no acknowledged messages in the Sequence will be discarded by the RM Destination.

thanks,

-Doug

Doug D: the old text was misleading, sequence being discarded is not strong enough. It does not state the rmd will not let anything pass its processing.

Bob F: while I can live with the text proposed by Bob, nowhere else are we this prescriptive about implementation details for the RMD. In order delivery, duplicate elimination etc are not visable on the wire, we do not describe the rmd/ad interface in any normative manner. This detailed requirement seems to tie things down quite a bit.

Doug D: I think the definition of “discard” in the first paragraph scopes this as not being anything new. I want to be more descriptive of what we mean by discard.

Jacques: I think that Doug D goes to great length to avoid the word “deliver” however that is the crux of the matter. This wording implies “Not deliver the message”. I can live with this wording.

Doug D moved to close i129 with his modified proposal, seconded by Matt L.

Doug B objects to unanimous consent.

§ Due to time constraints, meeting agreed to table the motion on i129.

7.4 i130 what does ack interval refer to

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i130

Doug B: current wording is that ackInterval is minimal amount of time, new wording changes it to be maximum amount of time. I do not think changing the semantics is something we should be doing under this issue.

Doug D: I have interpreted it as a maximum amount of time.

Doug B: neither wording talks about most recent message in sequence. Multiple messages in sequence is another factor. I see it as a minimal interval to wake up and send an ack.

Paul F: is it not the longest time to wait before sending an ack?

Doug B: is was not wanting to define it using multiple messages. A message is sent on sequence, after this interval is up the rmd may send sequence ack.

Paul F: Doug D proposal states it as a maximum.

Doug D: I saw this as a helper for the rms to do retries, not for the RMD.

Doug B: I will retry after my retry interval is used up and you have not acked the messages I care about. We are delving into implementation details, which are not required to fix the words. “after which” rather than “before which”.

Ų Doug B and Doug D will provide a proposal to resolve i130

7.5 i125 Protocol precondition requires knowledge of policies

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125

Email proposal from Paul F: http://lists.oasis-open.org/archives/ws-rx/200606/msg00107.html

I've been looking again at 125 -

(i125 Protocol precondition requires knowledge of policies

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125).

Firstly, I think this is a leftover from when the spec allowed an RMS to

start a sequence without a CS/CSR. If you look at the March 2003 spec,

where that is possible, it has this precondition in it.

Note that the preconditions are "prior to the processing of the initial

sequenced message".

So I propose that we replace the current pre-conditions with this:

The correct operation of the protocol requires that a number of

preconditions MUST be established prior to the processing of the initial

sequenced message:

* For any single message exchange the RM Source MUST have an endpoint

reference that uniquely identifies the RM Destination endpoint.

* The RM Source MUST have successfully created a Sequence with the RM

Destination.

* The RM Source MUST be capable of formulating messages that adhere to

the RM Destination's policies.

* If a secure exchange of messages is required, then the RM Source and RM

Destination MUST have a security context.

Marc G moved to close i125 with Paul F proposal, seconded by Anish.

§ No objections, issue 125 closed with proposal from Paul F.

7.6 i126 unclear text regarding wsa:Action

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i126

Marc G moved to close i126 with proposed resolution in http://lists.oasis-open.org/archives/ws-rx/200606/msg00005.html , seconded by Gill.

§ No objection, i126 closed by adopting Chris F proposed resolution.

7.7 i122 security profiles

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122

Marc G: there has been progress on the list, and the group is coming closer to consensus. I believe another week or so of discussion is required.

Gil: we need to define where such a beast is defined. We should define this. We need to be clear about scoping issues around a wsrm:sequence and a wss session used to protect it. Security session needs to live longer than wsrm:sequence. This would need to be clarified before we can support the Microsoft proposal.

Bob F: the need for SSL comes due to soap intermediaries, which can be independent of finalt destination. SSL is only effective for point to point situations.

Gil: there may be trust models allowing multiple ssl connections, with trusted intermediaries. There could be blended approaches. I agree that SSL is not really appropriate with intermediaries. SSL could work for restricted point to point uses. It is not wsrm which limits the model.

Dave O: I am not happy with the word “limited”, rather than “widely deployed”.

Anish: we are looking at the proposal on the table. We want to look at overlap with ws-tx use case. We also want to enable TLS and ssl in conformant solutions. We also want to ensure the conformance requirements can be met by our implementation (i.e, we want to ensure the wording of the optionality).

Marc G: It is intended to be optional to support or not support. The sequence creation can be refused if the receiver does not want to accept the STR mechanism. The STR is an open reference.

Paul F asked for a time frame for consensus between the concerned parties.

Paul C: we are working on this quite vigorously.

Gil: there might be some face to face time at WS-I. meeting.

7.8 i123 security profile agreement

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123

7.9 i124 security composition policy

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124

7.10i121 security threats and requirements

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121

Gill will create another go around to integrate the proposal into the document as a properly stated spec chapter.

Marc G: I will send a email out Regarding difference between authentication mechanisms.

8 Any other business

Gil: Should we have the meeting canceled for next week, since so many will be at WS-I.

Paul F : people who cannot attend should give regrets.

Need minute taker for next week, Tom Rutt cannot take minutes.

Doug D: The editors draft folder will have the latest versions marked as “latest version”.

Paul C: what is the identifier for a particular version.

Doug D: it is better to go back to the previous working draft if that is ok. However, there is a particular URL under the latest link, which could be used.

ws-rx message

1 Roll Call

2 Agenda Approval

3 Approval of the 6/8 minutes;

4 AI Review

5 TC Schedule tracking

6 New Issues since the last call

6.1 proposed-01 Consistent use of wsrm: in normative text

6.2 proposed-02 RM SeqID Globally Unique

6.3 proposed-03 No mechanisms to convey that messages should be polled.

6.4 proposed-04 Offer/Accept elements are incomplete

7 Issue discussion

7.1 i133 Duplicate text in fault section

7.2 i127 Make Accept/AcksTo consistent

7.3 i129 Define "discard"

7.4 i130 what does ack interval refer to

7.5 i125 Protocol precondition requires knowledge of policies

7.6 i126 unclear text regarding wsa:Action

7.7 i122 security profiles

7.8 i123 security profile agreement

7.9 i124 security composition policy

7.10i121 security threats and requirements

8 Any other business