[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Prelim Minutes of 3/9 Teleconf
Doug D: I see this as mostly harmless.
Was said by DougB not me - although
I agree with the comment :-)
-Doug
Tom Rutt <tom@coastin.com>
03/09/2006 05:35 PM
|
|
Textual Conventions
Ø Action
Item
Motion
§ 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
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i101
b> i098 clarify difference between "sequence" and "non-sequence" faults
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i098
c> i099 Correlating faults to Sequences using SOAP 1.1
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i099
d> i090 Use of offered sequences unclear in current spec
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i090
e> i089 suggest the restricted use of anonymous URI
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089
f> i021 An RM Policy applies two-way
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021
g> i008 Policy assertions granularity
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i008
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;
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17061/MinutesWSRX-030206.html
Tom moved and Marc G seconded.
§ Minutes
approved by unanimous consent.
4 Action Items
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: ---
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
None
8 Issue Discussion:
8.1 i101 Recommend
RMD Close rather than Terminate
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i101
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
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i098
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
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i099
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>
...
</wsrm:Detail> ?
</wsrm:SequenceFault>
After line 746 insert:
/wsrm:SequenceFault/wsrm:Detail
This optional element is intended for carrying application specific error information related to the fault being described.
/wsrm:SequenceFault:/wsrm:Detail/{any}
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]