Prelim Minutes of OASIS WS-RX Teleconference

May 18, 2006

Start Time:4:00 PM Eastern Daylight Time

Paul Freemantle acted as chair.

Textual Conventions

Ų Action Item

Motion

§ Resolution

1 Roll Call

From Kavi:

xx of 4? voting members, meeting quorate

Tom Rutt agreed to take minutes.

2 Agenda Approval

Agenda

Dial-in: Thanks to Bob Freund/Hitachi

Tel: 1-866-705-2554 or

Tel: 1-913-227-1201 (Kansas)

Participant Passcode: 155640

Press *6 to mute or "un-mute" line.

IRC/Q Mgmt(thanks to DougD): http://webconf.soaphub.org/conf/room/wsrx

Agenda 1) Roll Call

2) Review and approval of the agenda

3) Approval of minutes:

May 10th 2006

Preliminary minutes: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00155.html

4) TC Schedule

5) AI Review

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

6) New issues since last conf-call

Wait for email.

7) i093 review

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

8) Issue Discussion:

i119 When to piggy-back RM headers

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

i089 suggest the restricted use of anonymous URI

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

i115 "must understand" attribute for extensions to RM components

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

i121 security threats and requirements

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

i122 security profiles

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

9) Any other business

Paul F asked to postpone discussion of I089 until a future call.

No objections to postpone discussion of Issue 089.

Doug D asked that this be postponed to the call two weeks from now.

3 Approval of the 5/11 minutes;

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

Tom R moved Marc G, seconded to approve 5/11 minutes as posted to Kavi

§ No objection minutes for 5/11 meeting approved.

4 TC Schedule

Paul F posted email: http://lists.oasis-open.org/archives/ws-rx/200605/msg00202.html

May 25th Editors produce a new WD

June 1st TC implements new policy on issue list - highly restrictive acceptance policy (only bug fixes)

June 15th Target for all issues closed

June 22 Editors produce final WD

June 29th Open Ballot on CD and PR

July 6th PR starts

Sept 4th PR ends

Sept 14th Final spec pre-CS ready for review

Sept 21st CS ballot starts

Sept 28th CS Ballot ends

Paul: WD review period could possibly add another week, beyond June 29.

Doug D: the June 1 concept of highly restrictive acceptance policy. What about moving new issues into a deferred status, unless they are bug fixes.

Paul F: that is a minor change to my proposal. I want major issues to the spec now in the issues list before June 1. We could defer additional issues which are not simple bug fixes after that time.

Marc G: the More restricted issues should be ones which affect interoperability, or are simple editorial fixes.

Marc G: we will need a new PR issues list.

Ų Action: Marc G will prepare to have an issues list for Public Review.

Doug D: we also have to add interop for any new features, such as the resolution to I089.

Paul F: at the last f2f we considered interop to occur during the public review. These new dates puts the interop in August which is holiday season. I will try to do a revised schedule showing the interop.

Marc G: something seems compressed after the PR end. I see the end of October for CS. I will talk to Paul F off line about this portion of the proposed schedule.

Ų Action: Paul F will address Marc G concerns and interop concerns in a next version of schedule, including the member ballot.

5 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 state tables will evolve to reflect I89. However this round will be towards clarifying what is in this version of the spec..The task is to tie squares on tables to paragraphs in the text.

Assigned: 2006-05-09

Due: ---

#0101: The chairs should clarify the schedule for completion of TC issue resolution

Owner: Paul Fremantle

Status: Closed

Assigned: 2006-05-17

Due: ---

6 New issues since last conf-call

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

6.1 Proposed-01 - Protocol precondition requires knowledge of policies

http://lists.oasis-open.org/archives/ws-rx/200605/msg00159.html

Title: The protocol preconditions require knowledge of policies

Description: From WD13 section 2.2 and lines 177-178 it says:

The RM Source MUST have knowledge of the destination's policies, if any,

and the RM Source MUST be capable of formulating messages that adhere to

this policy.

Justification: Since the only assertion that we make currently is that

RM is on, this seems extraneous. Furthermore the spec is more useful if

it does not presuppose knowledge of policy to make it work.

Proposal: Delete lines 177 and 178.

Paul

Paul F presented proposed 01.

Doug B: why is this interpreted as non abstract policy requirement? I need to know you support the protocol.

Gil: with security composition policy, the protocol is correct under certain conditions. Other side can state it does not play that game.

Sanjay: lets focus on accepting as a new issue.

Doug B: I am not sure this is an issue.

Anish: I think we should accept the issue and then debate later.

No objection to accepting proposed 01 as a new issue.

6.2 Proposed-02 - Inefficient close/terminate of offered sequences

http://lists.oasis-open.org/archives/ws-rx/200605/msg00174.html

Description:

Currently the spec allows one side to optimise creation of two sequences

using the Offer. However, to close and/or terminate a pair of sequences

requires a pair of request-response operations.

To properly initiate and terminate a two-way reliable messaging exchange

therefore has an overhead of 3 extra message exchanges (Create+Offer,

TermSeq outbound, TermSeq inbound). A simple improvement is to allow the

client to optionally close and/or terminate the offered sequence at the

same time as the outbound sequence. Note this is not attempting to tie the

two sequences together. It is an option to leave the offered sequence

open. The attached sequence diagram shows the overhead when a single

req-resp is used.

Target: core

Type: design

Proposal:

Based on WD12

At line 446 add:

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

At line 484 add:

/wsrm:TerminateSequence/wsrm:Offer

This element, if present, enables the RM Source to signal that it is

terminating an Offered Sequence. This MUST only be used to terminate a

sequence that was established through <wsrm:Offer>. It is RECOMMENDED that

a final SequenceAcknowledgement header for the Offered Sequence is

included with this message.

/wsrm:TerminateSequence/wsrm:Offer/wsrm:Identifier

This REQUIRED element MUST contain an absolute URI conformant with RFC3986

[URI] that uniquely identifies the offered Sequence that is to be

terminated.

/wsrm:TerminateSequence/wsrm:Offer/{any}

This is an extensibility mechanism to allow different (extensible) types

of information, based on a schema,

to be passed.

/wsrm:TerminateSequence/wsrm:Offer/@{any}

This is an extensibility mechanism to allow additional attributes, based

on schemas, to be added to the

element.

At end line 492 insert:

A TerminateSequenceResponse message sent in response to a message

containing wsrm:TerminateSequence/wsrm:Offer shall be taken to indicate

that the RM Destination has received the signal that the Offered Sequence

is terminated.

After line 405 insert:

/wsrm:CloseSequence/wsrm:Offer

This element, if present, enables the RM Source to signal that it is

closing an Offered Sequence. This MUST only be used to close a sequence

that was established through <wsrm:Offer>. A final SequenceAcknowledgement

header for the Offered Sequence MUST be included with this message.

/wsrm:CloseSequence/wsrm:Offer/wsrm:Identifier

This REQUIRED element MUST contain an absolute URI conformant with RFC3986

[URI] that uniquely identifies the offered Sequence that is to be

terminated.

/wsrm:CloseSequence/wsrm:Offer/{any}

This is an extensibility mechanism to allow different (extensible) types

of information, based on a schema,

to be passed.

/wsrm:CloseSequence/wsrm:Offer/@{any}

This is an extensibility mechanism to allow additional attributes, based

on schemas, to be added to the

element.

After line 435 insert:

A CloseSequenceResponse message sent in response to a message containing

wsrm:CloseSequence/wsrm:Offer shall be taken to indicate that the RM

Destination has received the signal that the Offered Sequence is closed.

twowayoverhead.PNG

Paul F: you cannot optimize the two way sequence termination. That is what this issue is about.

Doug B: I again do not see this as an issue. It is trying to optimize something that is already handled in the protocol. I would argue to close with no action if it is accepted.

Tom R: since it does not impact interop, I do not think it should be a new issue.

Chris F: I also think we should not have this be a new issue. It is a premature optimization

Chris F and Tom R objected to accept as new issue.

Vote: 15 no votes, 0 yes votes.

Not accepted as new issue.

7 i093 review

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

Gill stated that there has been no comments on the list to date. If we have problems later on about details we can have new issues.

Doug B: The changes Gil has made have improved the specification and made it more readable. There might be some remaining passing voice text, which would be purely editorial to change.

Marc G: I think that it is understandable, but the text has changed to say what was stated before in a different way. I am not sure the changes are all inline with the issue raised.

Marc G: in particular 2.3 protocol invariants line 186 to 190

Gil: The subject is the acknowledgement. If rfc 2119 sentence the subject cannot be an xml element, the subject needs to be an implementation which is being built. The changes are toward saying what does the rm destination have to do. It is the rm destination to issue acks. The subject was changed to reflect that the desination is the subject.

Doug D: what is wrong with the ack being the subject.

Doug B: RFC 2119 states the actors are the implementations.

Marc G: - 3.1 on sequence creation – lines 240 – 243.

Gil: the previous subject was the create sequence message. The RM source creates the offer.

Marc G: that explanation was helpful. Another example would be lines 284 – 287.

Gil: Do not discuss cardinality in discussion of sub elements. It is addressed in the exemplars and in the schema. I am not sure it adds to the spec.

Tom: are you saying there are no formal statements of cardinality

Gil it is in the exemplar, and in the schema, it does not have to be in the actual text.

Doug B: I would like to amend that we remove phrases from text which violate RFC 2119 and which are already covered in the exemplars.

Doug B: I move that we accept the changes Gil has made as starting point for further edits to our specs, Tom R seconded.

Marc G: I speak against this, since I am not done reviewing the detailed changes. The changes regarding cardinality, were reflected clearly in the previous text which was changes. We could do a better job of reflecting cardinality with proper text.

Doug B: Issues such as the one you just raised could be done moving forward from Gil’s changes. We could take time to get these current changes corrects, or we could treat specific issues with these changes as additional issues to be dicussed.

Marc G: I prefer we review the changes and get it right this time around. Particularly with text which has a common theme, we should do it consistently and correct. The explanations of elements should be done consistently and correctly.

Doug D: an alternative way is to removed “this required element” pattern and just rely on the exemplars. “this required element” is not currently correct since the parent element may itself be optional. The patterns are wrong. Would you be more comfortable with the removal of “this required element” or “this optional element”

Marc G: I do not like relying on exemplar, text should be include as correct specification of cardinalities.

Gil: I could produce another version with the cardinality pattern removed throughout. Would this help, or would it be more confusing.

Paul F: Did you feel that the edits you have are consistent, or are you not finished yet.

Gil I replaced all common patterns in a consistent way. I am happy with the edits. I would like to have others check my work.

Gil: The cardinality is the main issue I am concerned about.

Doug B suggested we take this to the mailing list and put on the agenda for the next week meeting.

8 Issue Discussion:

8.1 i119 When to piggy-back RM headers

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

Doug D: I used the comparison text from the earlier ws-addressing to come up with a criteria for determining equality of endpoints.

Gil: do we talk about canonicalization of parameters before comparison.

Doug D: that is covered.

Doug B: that is not an issue for this TC. There are many reasons ws addressing decided to remove the text to progress the doc. The comparison of EPRs is not a ws-rx issue, it is a ws addressing issue which was avoided.

Doug D: WS addressing does not have an identity mechanisms, however they allow for other domain specs to have their own concept of equaltity. If one assumed address is enough, that will not work if ref parms are required for proper routing. We should decide if ref parms are required to be compared to determine if piggybacking is allowed.

Stefan: The rules for comparing URIs are of concern. The eprs could be equivalent, but the algorithm may not see them as such.

Anish: are you talking about URIs for ref parms or for address.

Stefan: I was referring to a ref parm with URI type.

Sanjay: If all the ref parms must match, it could still be the same endpoint. And RF specific ref param in both eprs might be a solution. If we deal with this at all we have to be careful.

Gil I agree it has to be covered in our spec. If you do not have a way to define rules, there might be differences in implementation. Another way to solve this is to get rid of piggybacking altogether.

Jonathan M: the comparison bothers me. How can we compare the address itself. It is hard to compare URIs, with case sensitivity issues. How do you want to compare two address properties.

Jonathan: the IRI spec has a menu of comparison options, but ws addressing did not define a way to compare two address properties.

Doug D: I would like to get a sense of the tc if we want any comparison mechanism.

Chris F: with regard to eliminating piggybacking, that would mean we would have to require polling.. With regard to url comparison we could take the same kind of comparison as done with namespaces.

Paul F: At some point the RMS will do ack request to get a sequence ack. You do not have to do a valid epr comparison to be usefule. We could say “only piggyback headers if the comparison is exact.” This would only allow us to piggyback in some cases. I am against removing piggybacking entirely.

Tom R: any comparison of epr identity would be overly restrictive. There could be two eprs that could both take the piggyback, and this might be known outside the protocol.

Anish: I am not concerned about overly restrictive comparisons. Those which do not meet this, would have to rely on extra messages.

Straw Poll: do we need solution, or close with no action., get rid of piggybacking.

Anish fourth option is to keep it outside the spec, with a warning.

Paul F will do the straw poll on Kavi.

8.2 i115 "must understand" attribute for extensions to RM components