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 3/9 Teleconf

Please post corrections before Monday morning

Tom Rutt

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

Title: Minutes of OASIS WS-RX Teleconference

Prelim Minutes of OASIS WS-RX Teleconference

March 09, 2006


Start Time:4:00 PM Eastern Time


Paul Freemantle acted as chair.


Textual Conventions


Ø  Action Item


§    Resolution


1         Roll Call

From Kavi:


xx of 52 voting members, meeting quorate


Tom Rutt agreed to take minutes.

2         Agenda Approval

1) Roll Call


2) Review and approval of the agenda


3) Approval of the Mar 2nd, 2006 meeting minutes


4) AI Review


5) Editors update

CD 2 and CD 3 posting etc


6) Raleigh F2F Planning

a> Dial-in sponsorship

b> Update from Doug on facilities

c> Any other issues

d> Post F2F timeline


8) New issues since last conf-call

Watch for Marc’s email


9) Issue Discussion:


a> i101 Recommend RMD Close rather than Terminate



b> i098 clarify difference between "sequence" and "non-sequence" faults



c> i099 Correlating faults to Sequences using SOAP 1.1



d> i090 Use of offered sequences unclear in current spec



e> i089 suggest the restricted use of anonymous URI



f> i021 An RM Policy applies two-way



g> i008 Policy assertions granularity



9) Any other business


Paul F stated the implementation SC had discussion on issue 89.  Paul would prefer to move issue 89 to end of agenda.



Dan Millwood asked that we have a review of the discussion of the SC on 89 first.


Agreed to limit discussion on 89.

3         Approval of the 3/2 minutes;



Tom moved and Marc G seconded.


§     Minutes approved by unanimous consent.

4         Action Items




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

Bob F: ws addressing group is proposing final text to w3c.  There were changes around the earlier resolution to issue cr004 from ws-rx regarding anonymous URI.  This will be sent to the group.


Tom: the ws addressing group is no longer suggesting reuse of the anonymous uri.  However they do not explicitly prohibit it.


#0085: Paul F to write up a more detailed proposal to Proposed 06 from 3/2

Owner: Paul Fremantle

Status: closed

Assigned: 2006-03-06

Due: ---

#0086: Chris F to provide further rational text for his proposal for I021

Owner: Christopher Ferris

Status: closed

Assigned: 2006-03-06

Due: ---

#0087: Anish provide explanation of the desired semantics for I 021

Owner: Anish Karmarkar

Status: closed

Assigned: 2006-03-06

Due: ---


5         Editors update

CD 2 and CD 3 posting etc


Doug D: CD 3 has not been completed.


Paul F: we need to update our committee draft folder.  It currently lists cd 1. The public page only lists CD1.  We need to ensure CD 2 and CD3 are in the proper folders in the public and private home page.


Ø  Action: Doug D will post CD2 and CD3 artifacts on the Kavi Site, with appropriate public page links.  Work with OASIS staff to get public posting.


Ø  Action: Paul F will give Doug D secretary status on Kavi.


Paul C: we have to be sure the namespaces are updated.


Paul C: the namspaces seem tied to the CD number.  We should be able to keep namespaces constant between CDs.


Ø  Action: Gill will ensure the proper file name for the namespace document.


6         Raleigh F2F Planning

6.1      Dial-in sponsorship

TIBCO volunteered for another period for the call.


Shivaji: who do I give the call in info to.


Paul F: send it to me, also the volunteers from the last week minutes should send me the call in details.

6.2      Update from Doug on facilities

37 percent has still not voted.


Doug stated there will be continental breakfast, Lunch and afternoon snack. There is planned to be network connectivity.  However there will not be incoming endpoints available.


Paul C: will this affect interop.


Paul F: Doug should send a note to the interop SC to see if this may be a problem.


6.3      d> Post F2F timeline

Paul F: we have a tight timeline after this face to face meeting.  We can adjust these dates at the face to face.  We wanted to have a public review early in April.


Marc G: I have heard about another interop round.


Paul F: the SC has discussed a public round with identified endpoints, after the public review draft is sent out.  The first interop is the one which is expected to find issues on the spec.


Marc G: when will we have F2F agenda, and it should include interop feedback on the first day.


Paul F: any suggestions for agenda should be send to Paul F and Sanjay.



7         New issues since last conf-call

Watch for Marc’s email



8         Issue Discussion:


8.1      i101 Recommend RMD Close rather than Terminate



Paul F posted http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00050.html


Based on CD3/WD10


At Line 365 insert the following sentence at the period.


For example, a client program may be in the process of being terminated;

a business application timeout may mean that there is no reason to

continue delivering undelivered messages; or a server may wish to

timeout an sequence that has not been used recently.


At line 367/368 replace the final sentence of the paragraph with:


To ascertain the final state of the sequence the RM Source MAY choose to

close the sequence before terminating it. 



At line 381/382 replace the first sentence of the paragraph with:


In the case where the RM Destination wishes to discontinue use of a

sequence it SHOULD close the sequence rather than terminate it, allowing

the RM Source to ascertain the final state of the sequence.



Bob F: on closure sequenceAckFinal is sent.  I have a concern about “state of delivery” of messages. If an RMD has implemented ordered delivery, and if there is a message out of order, there is an expressing of missing message.  However the application would not receive all of that, only up to the gap.


Paul F: I think this is worth point out as a new issue, however it is different than this one.


Tom R: I agree we could file a new issue on clarifying use with deliver status vs received status.  Implementations would likely make the waiting messages available to the receiving application at termination time.


Doug D moved to accept proposal for issue 101, Tom R seconded.

§    No opposition, proposal for issue 101 accepted.


8.2      i098 clarify difference between "sequence" and "non-sequence" faults



Gil posted proposal at: http://lists.oasis-open.org/archives/ws-rx/200603/msg00063.html

The lines 659-663 in http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf (excluding the first word of the sentence starting with "Sequence faults SHOULD . . .") should be changed to read:


The faults defined in this section fall into one of two categories; those faults that are the result of messages or operations within a specific Sequence and those faults that are not. By their nature the CreateSequenceRefused, UnknownSequence, and WSRMRequired faults cannot be correlated with a Sequence. All other faults defined in this section relate to the processing of WS-RM protocol messages or messages containing WS-RM header blocks targeted at a specific Sequence and are collectively referred to as "sequence faults".



Chris F moved to accept proposal from Gil to resolve i098, seconded by Charleton.


Doug B: why are we making this distinction.


Gil: you have to ensure the entity is authorized for the sequence.


Doug B: I understand why implementations need to treat messages and faults according to security policy, however I an not clear where this distinction needs to be made in the spec.


Gil: are you proposing a different solution.


Doug B: I am asking why we need to say anything about this.  Perhaps we can delete the text referring to sequence faults.


Gil: I would favor this change now, and have future issues raised as required.


Paul F: the spec already uses the term sequence faults, this adds a clarification of that term.


Doug D: I see this as mostly harmless.


§    No objections, issue i098 resolved with Gil’s proposal.


8.3      i099 Correlating faults to Sequences using SOAP 1.1



Gill proposal posted as: http://lists.oasis-open.org/archives/ws-rx/200603/msg00064.html

With reference to http://www.oasis-open.org/committees/download.php/16851/wsrm-1.1-spec-wd-10.pdf:


After line 710 insert:


        <wsrm:Detail> [Detail] </wsrm:Detail>


Change lines 738-741 (<wsrm:SequenceFault> exemplar) to:


<wsrm:SequenceFault ...>

    <wsrm:FaultCode> wsrm:FaultCodes </wsrm:FaultCode>



    </wsrm:Detail> ?



After line 746 insert:



This optional element is intended for carrying application specific error information related to the fault being described.



The application specific error information related to the fault being described.


(corresponding changes to wsrm-1.1-schema-200602.xsd left as an exercise for the monkeys)


Chris F moved, Doug D seconded to resolve I099 with Gil’s proposal.


§    No objection, accept Gill’s proposal to resolve I099, mark as pending.


8.4      Discussion from interop SC

Paul F discussed an issue about the interop scenarios, regarding the anonymous URI.


Paul F: two issues.  In order to get a missing response message, it is required to resend the actual request messages for which that is a response to.  This is not written down.


Tom R: why does the rms have to save after it gets an Ack.


Paul F: the problem is the response might be lost. The request was acked so the rms could delete the request.  However to get the response again the rms has to resend the request, even after it acked.


Gil: this is only a problem in synchronous case when rm semantics are applied to response. 


Glen D: this raises a concern, if you do not know if something other than rm machinery will occur.  It requires duplicate elminiation in some business cases.  The sender needs to know if ther will be duplicate detection.


Paul F: how is this different than rm in a one way case


Glen D: you might resend either way.


Tom R: I agree that to make this work both sides need to know what is going on.  Our sister WSRM TC has be discussing how to do reliability on synchronous response for a while. It requires both sides to know there is reliability on synchronous response. We could add things to our protocol to make such knowledge available.  We could use extra information on the Create Sequence to exchange this knowledge.


Chris F: In this case, the response must be carried on the http response.  To carry the response again you have to resend the message.  


There was considerable discussion on the repercussions of this apparent dilemma.


Paul F: other points need to be made.  The 2.4 scenario from Microsoft, talks about timing of when acks are delivered back.


Paul F: regarding Tom’s point, I agree that both sides need to know what is going on.  The offer cannot be treated as an uncorrelated sequence.  We need to add words that has special semantics in the request/response binding to soap.   The Apache stack cannot yet handle this, because it deletes on receipt of the ack.  


Doug D: if this scenario causes problems, we could take it out of the test cases.


Dave O: is the question for this upcoming interop event, or the follow on event. If it is only for this event, the case could be dropped.  It can be added later after the TC has concensus.


Paul C: we need solid pointers to the documents being discussed.  Having this on this interop gains us more data. If we successfully interop on this scenario, we can gain knowledge.  Why drop it on this list of things. It does not have to be implemented by all.


Tom R: this is related to the I021 discussions.  If the default on a request response endpoint is reliability for both request and response, we have to have the mechanisms in place to make this happen.  We could decide to not require reliability in response.  If reliability in response is required, the sender must do extra buffering beyond the first ack.


Further discussion ensued on the assumptions on behavior for this scenario which are not written down, with respect to the interop scenarios taking place. 


Meeting closed at 5:32 pm. Eastern time.


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

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