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: Prelim Minutes of 1/26 Teleconf


Prelim Minutes are attached.

Please provide corrections to list before Next Monday.


Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Preliminary Minutes WSRX TC Teleconf

Prelim Minutes OASIS TC Teleconf

Thursday January 26, 2006

 

4:00 to 5:30 EST

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi.

 

Meeting was quorate.

2         Review and approval of the agenda

1. Roll call

2. Approval of Agenda

3. Approval of minutes 19th January

4. Admin

a) F2F location and dates

b) CD2 status

c) Teleconference hosting

5. Action Items

6. New issues since the last call

7. Proposed approach to State tables

a) The specifications are normative over the table

b) Issues should be raised and fixed against the specs and should include changes to the state table

c) Use the state tables to drive and close issues and clarify the specifications.

8. Issue discussion

i075 Umit Yalcinalp Case of multiple RM Policies and DAs within an RMD scope

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

 

i078 Bob Freund Lost TerminateSequence

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

 

i084 Matthew Lovett RMS state table and SequenceClosedFault

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

 

i008 Tom Rutt Policy assertions granularity

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

 

i021 Jacques Durand An RM Policy applies two-way

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

 

i061 Doug Davis Anonymous AcksTo

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

 

i090 Daniel Millwood Use of offered sequences unclear in current spec

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

 

Tom Rutt: Suggests i008 has to go after I021.

 

No objections to move i008 after i021.

 

Sanjay: we need approval by TC of state table issues.

 

Paul F: that is the intent of Agenda item 7.

3         Approval of the Jan 19 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16132/minutes5jan2006.doc

 

Tom R moved, Bob F seconded to approve Jan 19 minutes.

Agreed to Add Bob F to attendance list

 

§    No opposition, Jan 19 minutes approved.

 

4         Admin

4.1                              a) F2F location and dates

Ballot results,

 

Agreed to IBM hosting at march 21-23 in Raleigh.

 

Doug D asked for another ballot for attendance to each meeting.

 

Paul F will conduct a suitable ballot to determine attendance.

 

Paul F: we need hosts for conference calls at the F2F.  We need people to host conference calls, due to the better quality of service.

 

Next Teleconf is already sponsored.

 

Bea volunteered for the following TC teleconf.

 

Nortel volunteered for the one after that.

4.1                              b) CD2 status

36 of 51 voted yes, both ballots passed.

 

Editors need to post CD2 on web site.

 

Paul C: that is the specs, the namespace docs and the schema.

 

Paul F: that is correct.

 

Ø  Action: Gill will post the CD2 specs appropriately.

 

 

4.2                              c) Teleconference hosting

 

 

5         AI Review

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

 

 

#0056: Ensure that the final WSA specifications include text for handling of anonymous IRI values for non-WSA EPRs

Owner: Robert Freund

Status: Open

Assigned: 2005-12-13

Due: ---

 

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

 

#0064: Marc G will work with Bob F and Anish to draft a concrete proposal for terminateSequence Response message

Owner: Marc Goodner

Status: Closed

Assigned: 2006-01-02

Due: ---

Anish: the proposal does not have complete text, but is a total proposal.

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

 

#0066: Doug B will raise a new issue on RFC 2119 Terminology Not to be used for cardinality constrints

Owner: Doug Bunting

Status: Open

Assigned: 2006-01-18

Due: ---

 

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

 

#0070: Paul F will discuss OASIS hosted TC teleconferences with the OASIS staff, making clear the unacceptable quality of some “free call” bridge services

Owner: Paul Fremantle

Status: Open

Assigned: 2006-01-18

Due: ---

Paul C: can we have our OASIS reps to bring this to the attention of the OASIS board.  I express my thanks to Paul F for getting this under discussion.

 

Paul F: People should contact their OASIS reps on this.

 

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

 

#0071: Sanjay to open a new ballot with new option and original Hursley dates as options, will only be able to vote for one or the ot

Owner: Sanjay Patil

Status: Closed

Assigned: 2006-01-26

Due: ---

 

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

 

#0072: Umit will report back to our TC any results of discussion related to i061 at WS-A F2F

Owner: Umit Yalcinalp

Status: Open

Assigned: 2006-01-26

Due: ---

 

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

 

#0073: Marc to follow up with Bob regarding new issue from AI 62

Owner: Marc Goodner

Status: Closed

Assigned: 2006-01-26

Due: ---

6         New issues since the last call

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

6.1                              Proposed-01

 

Title - Unexpected UnknownSequenceFault or SequenceTerminatedFault

 

Description / Justification – State table indicates insufficient specification of these faults condition.

 

Target - core / design

 

Type: design

 

Origin: Bob Freund, bob.freund@hitachisoftware.com

 

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

 

Proposal:

 

Ref WD08

 

Insert after line 706:

 

Receipt of SequenceTerminated by either the RMD or the RMS shall terminate the sequence if it is not otherwise terminated.

 

 

 

Insert after line 715:

 

Receipt of UnknownSequence by either the RMD or the RMS shall terminate the sequence if it is not otherwise terminated.

 

State Table:

 

 Ref 1.0:RMD

 

Change next state row 15, columns E-H to Terminated

 

Change next state row 16, columns E-H to Terminated

 

Ref 1.0 RMS

 

Change next state row 17 columns E-I to Terminated

 

Change next state row 18 columns D-H to Terminated

 

No objections to accepting Proposed 01 as a new issue. 

 

New issue from Anish.

 

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

 

Title: Where is the SequenceAcknowledgement sent on receipt of

AckRequested header?

Description: The spec does not say where the SequenceAcknowledgement

message is sent on receipt of the AckRequested header. There are two

possibilities: to the AcksTo EPR or to the ReplyTo (as a response) of

the message requesting the SequenceAcknowledgement.

Target: core

 

No objection to accepting Anish new Issue.

 

 

7         Proposed approach to State tables

Proposal from Paul F:

a) The specifications are normative over the table

b) Issues should be raised and fixed against the specs and should include changes to the state table

c) Use the state tables to drive and close issues and clarify the specifications.

 

Paul F asked for clarification.

 

Doug D asked how the state table will be included in the spec.

 

Paul F: If they are complete they should be included somewhere.

 

Bob F: I move that the state table be incorporated as a new appendix, to be formatted by the editors, to be maintained as part of the core document. Seconded by  Marc G.

 

Doug D: that should be done as part of issue 58.

 

Paul F: we should close issue 58 after we are happy with the state tables.

 

Bob F: we are resolving issues raised from the state table, but it will have to be fixed and maintained throughout progression of the main document.  Once the table is there, there will be new issues raised against the table as members see fit to make it agree with the text.  Thus we could close issue 58 with this understanding.

 

Paul C: proposals to change document semantics should require changes to state table.

 

Gil: I think that a proposal which requires a state table change tells me it is significant.

 

Tom R: people should keep

 

Doug D: is the state table normative.

 

Bob F: the location in an appendix should make it clear it is non normative.

 

Paul C: the table should be labeled as non normative.

 

Bob F: I agree to that friendly amendment.

 

§    No objection to Close issue 58 by adding informative state table as annex.

 

 

8         Issue discussion

 

8.1                              i075

Umit Yalcinalp Case of multiple RM Policies and DAs within an RMD scope

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

 

The third alternative seems to be most acceptable:  Use the policy governed by the endpoint which is the target of create sequence message.

 

Doug D moved to accept third proposal, seconded by Matt.

 

Anish: if I define a policy assertion, but do not have a policy parameter, but use an extensibility point, is this also a policy parameter.

 

Gil that would be part of the policy in effect.

 

Paul C: I think Anish is asking for us to be using the correct terminology.  What is the correct term used in WS-Policy.

 

Anish: That is correct.

 

Gil: If we do not have any parameters in our assertions now, there is nothing to conflict. If it does not participate it cannot conflict.  Perhaps we can not in wsrm policy doc on extensibility points to warn about potential conflicts.

 

Gil I advocate closing this with no action, with another issue on extensibility points in wsrm policy spec.

 

Marc G: That sounds like a different issue.  I do not want to lock extensibility point just yet.   We should probable kept the text for now.  The term “rm policy assertion and any parameters”.

 

Anish: I wonder if we need to say anything at all, since we do not now define parameters.  All we have is extensibility points.  What if they put the assertion in the CSR message?  Proposal 3 would disallow such assertion in CSR.

 

Doug B: the endpoint is the recipient of Create Sequence message.  You do not need to use extensibility points because our container is one big extensibility point.  This proposal sounds like a constraint on later extensions.

 

Paul F: We have a motion, with some objections.

 

Doug D: I move to amend motion with new proposal with close with no action. Seconded by Matt.

 

Sanjay:  We need to Add text along the lines

“The rmd could span multiple endpoints, and the problem of specifying  policy for any sequence is  a generic problem and is deferred to ws policy framework”

 

Discussion on what the policy framework actually specifies in this area.

 

Anish: we could use text along the lines of Gil.  We do not specify parms, but users of extensibility need to be aware of potential conflict problems.

 

Paul F: Is there anyone who does not agree with this approach.

 

Sanjay:

“The rmd could span multiple endpoints, and the problem of specifying policy for any sequence is  a generic problem and is out of scope for this document”

 

Doug D: which document does this text go into.

 

Sanjay: the WSRM policy spec is where it would go.

 

Marc G; I think we are drifting further a field from the current issue.

 

Gil:  Anish and I can take an action item on a warning for extensibility.

 

Marc G: what does that have to do with this issue.

 

Paul F: would you prefer that be a new issue, closing this one for now with no action.?

 

Marc G: Yes

 

Anish: This issue is about what happens when you include rm assertion in a port, and and endpoint has multiple ports, with potential conflicts.  I think the extensibility clarification is relevant to the issue at hand.

 

Doug D: I suggest we let Anish and Gil make a proposal, and if we like it we will adopt it.

 

TC Agreed to Table I075 motion and amendment under discussion.

 

Ø  Action: Anish and Gill will submit proposal to close issue 75, with a clarification on extensibility.

 

8.2                              i078

Bob Freund Lost TerminateSequence

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

 

Bob F summarized the issue and its proposed resolution.

 

Doug D: I am ok with the general direction of the detailed proposal from Anish.

 

Ø  Action: Anish will lead an effort to draft a complete proposal to close I078.

8.3                              i084

Matthew Lovett RMS state table and SequenceClosedFault

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

 

Matt suggested no change to the text while clarifying the state table.

 

Bob F: I suggested adding some clarification wording to the spec.  Lines 373 and 374

The quotations “closed” are confusing in this sentence.  It refers to “above’ which does not seem to be there.

 

Ø  Action: Bob F will provide proposal to close issue 084 with clarification text.

8.4                              i021

Jacques Durand An RM Policy applies two-way

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

 

Doug D: summarized most recent emails.

 

Doug B: It seems you could end up with multiple policies for business replies, and rm replies for all the to and froms.  It is the opposite direction as that proposed for I075.  Is the intent to make policy discovery complicated.

 

Doug D: can use metadata portion of EPR to signal that you want reliability on response message.

 

Tom: I am confused.

 

Paul F; the publishing endpoint does not specify the reliability of response.  It is up to RMS to specify that if it needs to be reliabile.

 

Doug D: the rm policy assertion is still there, but only for endpoint, but if you do not have wsdl what do you do

 

Doug D: There is still a policy assertion defined in this spec, but limit it to incoming messages only

 

Marc G: I would like to see a concrete proposal.  I need to think about the epr usage in this context.  I need to review this with other people.

 

Sanjay: EPR exchange could be made to work, however this issue is on policy attachment.  Your proposal does not seem to be symmetric and complete using epr exchange.

 

Doug D: The proposal for specifying RM on replies does not use wsdl assertions, but is an alternative.

 

Ø  Action: Doug D will provide a complete proposal for resolving issue 21, which does not use wsdl annotation for the reply reliability.

 

Dave O: I think that Gil’s proposal to separate the RM assertions for each direction should be explored as an alternative.

 

Paul F: can Gil present his proposal.

 

Gil: two separate assertions for RM inbound, and for RM outbound, to be attached to the WSDL.  To me it seems simpler than what Doug D is proposing, since it uses the same idiom, by using the policy language.  I would be able to take an action to give complete text.

 

Ø  Action: Gil will provide a complete proposal for resolving issue 21 with uses rm inbound and rm outbound policy assertions.

 

Tom R: I would like to be able to see both and make a decision.

 

Doug D: It seems to be odd to have a client specify how it wants to receive messages.  Having the server state how it will send messages in response (as client behaviour) seems odd to me.  

 

 

Meeting Adjourned, Ran out of time

 



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