Marc G: I do not understand the rationale to delay. The proposals for 121, and for 122-124 have been out there for some time. I do not see why we should

Tom R: what about putting a time limit on discussion for each of these.

Paul F: I would like to spend time towards resolving each issue.

Anish: There have been conversations going on about 122 123 124, involving liaisons with ws-SX. Others (Pratik and Martin R) are working on proposals for these three issues, but cannot send until next Monday. More email is required for these three issues.

Anish: I might be worth discussion 121 on the call, but I would hope that we get to an AI on revised proposal to vote on next week.

Paul C: I thought the proposal from Pratik and Martin R was on 121 thread.

Anish: yes but it relates to the other issues.

Paul F: these proposals have been around a significant amount of time. I do not like to delay just because people have not provided a proposal.

Chris F: Why are we delaying further? I has been kicked around both in and out of committee. Reading thru some of the issues are nits and pics around the basic content of the proposals. Not making progress seems like not a good idea.

Paul F give 122-124 thirty minutes each.

Anish: I want to clarify that there has been quite a bit of activities lately. Pratik has been talking to several people. I would be ok with time bounding.

Paul F: give 30 minutes from when we get to it.

Anish: I suggest a reorder then.

Paul C: I am against a reorder.

Paul F: these are crucial issues to resolve before progressing. If there is agreement at 80% level, we can save the effort of an alternative proposal.

Anish: We would like to do that effort, to let the TC see the alternate proposal, whether it is accepted or rejected.

Paul F: I suggest we continue in the order.

Anish I object we move to end.

Paul F: Straw poll on moving 122-124to end:

14 leave

8 Move.

Agenda stays.

3 Approval of the 6/29 minutes;

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

Bob F moved, Tom R seconded to approve 6/29 minutes.

§ No objection minutes for 6/29 meeting approved.

4 AI Review

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

#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: ---

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

#0106: Bob address polling in the state tables (once the first round of state table changes are stabilized)

Owner: Robert Freund

Status: Still Open

Assigned: 2006-07-03

Due: ---

Bob F: There are two ways to put polling into state tables. configuring event causes get message to be transmitted does not fit into the context of a sequence beneath it. I am drifting to make it a separate underlying state table, transport aware, and perhaps dealing also with retrial.

Paul F: I have a simple view on that. I will contact you out of band.

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

#0107: Bob and Anish to develop proposal for i140 resolution

Owner: Robert Freund

Status: Still Open

Assigned: 2006-07-03

Due: ---

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

#0108: Doug B to send note describing his thoughts on the extensibility of Protocol Elements

Owner: Doug Bunting

Status: Still Open

Assigned: 2006-07-03

Due: ---

5 Administrative

Schedule tracking

Paul F: we are running a month behind our last published schedule. We should push hard to close remaining issues over next few weeks, to get public review initiated.

6 New issues since last conf-call

None

7 Update from the editor's

Doug D: all the issues have been incorporated in the latest editors drafts. We do not have a new update for the state tables yet.

Marc G will post a new issues list after the meeting.

8 Issue Discussion:

8.1 i139 Inappropriate Fault destination

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

Agreed to defer to when Jacques returns from leave of absence.

8.2 b> i121 security threats and requirements

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

Gil: I sent the new proposal out http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00000.html There have been some email discussion on this, with minor issues regarding encryption. I suggest we give this one more week before voting on a resolution.

Paul F: Are the discussions significant or minor

Gill: the only significant disagreement is on references to things in ws-sx. We should apply minor edits, and vote on that next week.

Tom R: by our charter we cannot refer to specs which are not ready, but can instead give a more abstract specification within the context of WS-RX. Some of the discussions have suggested we indicate our interpretation of where WS-SX is moving, and include this in the WS-RX spec, as necessary to help interop.

Anish: The token ref in create sequence should not be referenced as a SHOULD in the text for 121.

Paul C: if all the techniques were listed would you be concerned.

Anish: I would prefer that all be listed if there is a SHOULD recommendation.

Marc G: unique refs vs local refs to tokens is one issue in SX tx. I am confused about three techniques in SC, as mentioned by Anish. I do not agree with linking this to that issue.

Anish: I might be confused, but section 8 of SC does talk about these techniques.

Marc G: there is only one for the linking of SC to particular message.

Anish: I will send an email asking for any particular changes to the proposal.

Marc G: WS-RX should not describe how the SC is composed.

Paul C: I would like to amend the proposal now the get the issue flattened. I think we can fix the problems right now.

Gil: Bullet point 2 of 5.2.2.1 model for secure conversations: two ways to decide which token

1) Implicitly – create sequence in context, keeps that context

2) Explicitly – put SC token into create sequence.

Having two ways to tie SC to rm sequence makes two different mechanisms required to interop.

Regarding three mechanisms for secure conversation, I have not referenced the creation or maintenance of a secure conversation, or security session.

I think reintroducing TLS is simple, as are some others. However Pratik was asking for an explicit list of what needs to be signed or not signed, and this would required adding a table.

Paul C: is that last change additive and could be a new issue.

Gil : yes it could.

Chris F: I move we accept the proposal for I121 and later amend it, Marc G seconded.

Martin R Discussion: on multiple ways to create token, have a relationship to intended usage of token.

Anish: I am surprised Paul C is asking to close an issue with changes where we do not have exact text.

Anish: It might be better to have headers point to bodies. We can talk about embedding the scr in create sequence message. For explicit you could either put the token in a header or could use pointing to the create sequence in the body.

Umit I object the motion.

Paul C: I Move we could amend by including Changes 41 for encryption and ssl changes in message 28, seconded by Marc G

http://lists.oasis-open.org/archives/ws-rx/200607/msg00041.html

http://lists.oasis-open.org/archives/ws-rx/200607/msg00028.html

Anish: I still would rather wait until next week to vote on this.

Marc G: the SX TC does not even have CDs, so asking for a delay on this proposal seems inappropriate. They could be added to the things being described now.

§ No objection to accepting amendment from Paul C.

Chris F: I do not see why the other changes could not be made using this proposal as a basis. We should make substantial progress if possible.

Martin R: I was not referencing new mechanisms in WS-SX, the mechanism is in the submitted document and the editor’s draft.

Gil: with regard to the bullet point Anish has a problem with, it is tricky. You want to lead the discussion to what you think must be done. This is the part that ties to 122-124. We can agree to put something there, which might be need to be changed after resolution to 122-124.

Anish: I would prefer we leave the bullet out, and add it later after agreement on 122-124.

Paul C : I suggest we proceed with a vote.

Anish: I suggest that we remove the 5.2.2.1 bullet be removed. Not seconded.

Gil: the text makes no sense with that bullet missing. We should instead have wording to make more general.

Anish: I would rather have a bullet 2 which is more abstract.

Gill: So 39-41 will read: Integrity threats are generally countered via the use of digital signatures at some level of the communication protocol stack.

Anish moved to ammend, seconded by Chris F: replace bullet 2 with: The RM source SHOULD explicitly identify the security context that will be used to protect the Sequence.

anish + This is done so that, in cases where the CreateSequence message is signed by more than one security context, the RM Source can explicitly indicate which security context should be

used to protect the newly created Sequence.

§ Anish amendment accepted.

§ No objection to close issue i121 with motion including three changes in two amendments.

8.3 issues i122-124

c> i122 security profiles

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

d> i124 security composition policy

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

e> i123 security profile agreement

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

Marc G: there have been minor updates posted as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00036.html . The Header does not make sense with mustUnderstand not equal true, so this was changed. I added text pointing to the WS-SC drafts. SCR Reference concerns expressed by Gil, I added text to state you SHOULD use unique identifier.

Anish: uses Sequence STR, why is SHOULD not MUST.

Marc G: I discussed this with Sanjay on list, the fact that Create Sequence has extensibility point, a MUST is too strong.

Anish: This MUST is conditional, if you use the extensibility defined above, you MUST use it.

Marc G: I could accept a conditional MUST there, but prefer the SHOULD.

Chris F: I move to accept Marc G proposal with conditional MUST for header, seconded by Marc G.

Gil: I have some specific concerns on the current proposal, but have not had time to provide replacement text. How does RMS say I am using TLS session for sequence in this proposal. My concerns could be raised as separate issues.

Marc G: I recall these conversations. We could define a well known URI to use in STR saying to use credentials in TLS. This could be defined within WS-SX TC, independent of what we need to do. Another way is a parallel header binding to a tls sessions. Both of these warrant further discussion, based of the resolution text to this issue.

Chris F: everyone has been operating in good faith, and we may need to provide some further tweeks, but I would prefer we make progress. Points can be made to these other TCs which can provide solutions.

Gil: while a ref to tls session may seem simple, I would not like this spec to go out with this issue in the air. While I agree it could be done in the future, I would be more comfortable with us defining a mechanism to use TLS session this sequence was set up within.

Anish: I agree with Gil. The implementation may not recognize ws-sc, if it uses TLS.

Paul F: are there objections to motion on floor.

Ran out of time for completion of vote on motion.

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

No time for remaining issue discussions.

ws-rx message

1 Roll Call

2 Agenda Approval

3 Approval of the 6/29 minutes;

4 AI Review

5 Administrative

6 New issues since last conf-call

7 Update from the editor's

8 Issue Discussion:

8.1 i139 Inappropriate Fault destination

8.2 b> i121 security threats and requirements

8.3 issues i122-124