[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 1/19/2006 Teleconf
|
Prelim minutes are attached.
Please send any corrections to the whole list before monday morning. Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/members/mrgoodner/ Prelim Minutes of 1/19/2006 Teleconf Thursday, January 19, 2006 12:58 PM
New action items from this meeting:
Agenda: 1) Roll Call See Kavi
2) Review and approval of the agenda Approved
3) Approval of the Jan 12, 2006 meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16299/MinutesWSRX-011206.htm Tom moved to approve, seconded by Chris No objections, approved.
4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
53 Editors team to produce a RDDL document to be placed at the namespace URIs (3). http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1081 Closed - See: http://lists.oasis-open.org/archives/ws-rx/200601/msg00104.html
56 Ensure that the final WSA specifications include text for handling of anonymous IRI values for non-WSA EPRs (Robert Freund) http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1126 Leave open
64 Marc G will work with Bob F and Anish to draft a concrete proposal for terminateSequence Response message (Marc Goodner) http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1165 Leave Open
65 Chairs to add RDDL to next week Agenda http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1166 Close (on today's agenda)
66 Doug B will raise a new issue on RFC 2119 Terminology Not to be used for cardinality constrints (Doug Bunting) http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1165 Leave open
67 Chairs to put the editors document policy on agenda for next meeting http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1166 Close - On today's agenda (namespace discussion)
68 Chairs will post a CD ballot after Editors post candidate CD text http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1167 Close
69 Editors add new issue for proposed 01 from Jan 12 meeting, mark as having agreed resolution http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1168 Close - See i085 http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i085
70 Paul F will discuss OASIS hosted TC teleconferences with the OASIS staff, making clear the unacceptable quality of some “free call” bridge services http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1169 Leave open Discussion has started on chairs' list but no OASIS staff input yet.
5) Administrative a> Open ballots b> Dates/Venue for the next F2F New proposal from Paul Cotton and Chris Ferris: http://lists.oasis-open.org/archives/ws-rx/200601/msg00081.html
Some objections to this proposal Discussion
Action: 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 other
6> Namespace Versioning Policy a> Formal approval b> Scope (applicability to WD, CD, CS) New issue was raised: http://lists.oasis-open.org/archives/ws-rx/200601/msg00137.html Motion from Chris Ferris, seconded by Paul Cotton: Accept proposed issue and proposal as amended: http://lists.oasis-open.org/archives/ws-rx/200601/msg00139.html
No objections Will be recorded as i088 and marked as pending.
7> RDDL document a> Formal approval http://lists.oasis-open.org/archives/ws-rx/200601/msg00104.html Motion from Gilbert Pilz seconded by Steve Carter: Accept the RDDL as TC material
No objections
b> Scope (applicability to WD, CD, CS) Sanjay suggests it would be best to go through exercise of publishing RDDL with CD and not wait until CS.
RDDL will be applied to CD and CS specs.
No objections
8) New issues since last conf-call http://lists.oasis-open.org/archives/ws-rx/200601/msg00133.html
Proposed-01
Title: suggest the restricted use of anonymous URI
Description/justification: When an AS uses an RMS to reliably send messages to an RMD, the RMS will need to be able to resend the un-acked messages at will. If the AS uses a target URL or wsa:To value such that the RMS can not, at its own discretion, initiate the (re)sending of messages then the RMS would be severely limited in its ability to complete its job. To this end the RM spec should discourage the use of wsa:To values that would put the RMS in this situation, like the anonymous URI. Of course, there may be times that using the anonymous URI _and_ RM can work and so we shouldn't totally ban the use of anonymous URI but we should make people aware that w/o some other mechanism, a generic WSA+RM soap stack would not be able to support this. Note, that while this is phrased in the context of wsa:To, for replies the RMD becomes the RMS and the wsa:ReplyTo becomes the wsa:To - so it would mean that we'd, implicitly, be discouraging the use of the anonymous URI in wsa:ReplyTo when people would want responses sent reliably.
Target: core
Type: design
Origin: Doug Davis dug@us.ibm.com http://lists.oasis-open.org/archives/ws-rx/200601/msg00080.html
Proposal:
After line 441 of [1] add:
Messages sent using this protocol MUST NOT use a wsa:To value that would prohibit the RM Source from retransmitting unacknowledged messages. For example, using the anonymous URI, without any additional transmission mechanism, would restrict an RM Source's ability to re-establishing a new connection to the RM Destination when a re-transmission of a message is needed.
Discussion: Doug - Warn people that when using anon uri in some places, i.e. ReplyTo, it may prevent proper use in some environments. It doesn't bar the use of it but provides warning/guidance. Umit - This seems a duplicate of i061 Doug - i061 is about back channels, this one doesn't deal with that
No objection to accepting as an issue
Umit / Paul discusion - Apparently WS-A has the subject of i061 on their agenda this week. Action: Umit will report back to our TC any results of discussion related to i061 at WS-A F2F
Proposed-02
Title: Use of offered sequences unclear in current spec
Description/Justification:
When an RMS sends a CreateSequence that includes an offer, the offer is meant to be an optimisation for creating a sequence back from the RMD to the RMS. Closer inspection highlights issues with this approach.
The RMS knows the endpoint of the RMD and sends it the CreateSequence message with the Offer, but the RMD is not informed of the endpoint it should use to send protocol messages back to the RMS for the offered sequence, or which AD endpoints the sequence can be used for.
Now, the RMD could assume that
a) It should send protocol messages to the same endpoint that it sends the CreateSequenceResponse message to for the inbound sequence.
b) It should send protocol messages to the same endpoint that it sends Acks to for the inbound sequence
c) It should send protocol messages to the same endpoint that it would have done if it had created the outbound sequence itself, which could be a, or b, or another endpoint as yet unknown to it.
but assumptions break interoperability and the RMD still doesnt know which application messages can use the sequence.
As an optimisation, the offer should not change the behaviour that would be observed without the optimisation.
Lets take an example. Two applications A and B use reliable messaging to query addresses from an address book application at endpoint X. They both use the same RMS and share the same sequence, and the RMD at endpoint X passes the messages onto the address book app where addresses are queried and need to be sent back. Application A sets a wsa:ReplyTo of Endpoint A for its replies. Application B sets a wsa:ReplyTo of Endpoint B for its replies. Both these endpoints support WSRM. When the replies are sent back, two sequences are established. One to endpoint A and one to endpoint B.
Now try and do the same with offer. The RMS creates the outbound sequence and offers a sequence the other way. Its accepted by the RMD. Now the application messages arrive at the RMD, are processed by the address book app and the replies need to be sent back to Endpoint A and Endpoint B.
Which endpoint does the offered sequence service? None, A, B, or both?
Further more, since the spec doesn't limit the offered sequence to just replies (it can be used for any msg going from the RMD to the RMS) this problem is made even worse. Even before the first application message from the RMS to the RMD is sent, the RMD could have a message for the RMS. How does the RMD know whether or not the wsa:To EPR in this message matches one of the possibly many RMS EPRs that the offered sequence is for?
The result is the creation of an offered sequence where its not clear which application messages can use it, or where to send the protocol messages.
Target: core Type: design Origin: Daniel Millwood MILLWOOD@uk.ibm.com http://lists.oasis-open.org/archives/ws-rx/200601/msg00086.html
Proposal:
Whilst there may be a subset of WSRM usecases where offer could make sense, I believe it is too open to interpretation to be interoperable. For the benefit of interoperability, it should be removed from the spec.
Delete from <wsrm:CreateSequence> in line 274, through to 277 Delete lines 309 through to 330 Delete lines 369 through to 384 Delete line 1043 Delete line 1060 Delete lines 1090 through to 1106
Discussion: No objection to accepting as an issue
Bob- what about new issue from AI 62? Action: Marc to follow up with Bob regarding new issue from AI 62
9) Issue Discussion: a> i082 Level of "response message" unclear, for SequenceResponse http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i082
New proposal from Jacques: http://lists.oasis-open.org/archives/ws-rx/200601/msg00147.html
Jacques: Explained proposal, intention is to clarify text to make it clear that there is not an implied MEP behind instances of "request message" or "response message". Sanjay - Concern on side effects of proposal Jacques - Have reviewed carefully and believes this clarifies text and does not have any side effect Chris -Doesn't see need for change, doesn't think there is an implied MEP in instances of these terms Jacques - Concerned that req/resp is loaded, just trying to reduce potential confusion Anish - Agree that these are loaded Sanjay - suggest going through points 1 and 4 as people seem more concerned about the proposed global changes Can we accept 1 and 4 and leave 2 and 3 to the editors Marc - No, I'm not comfortable with leaving 2 and 3 to the editors. I would like to review the proposed changes Dave O - I'm happy with it Jacques - I could reduce my proposal to 1 and 4 Chris - Prefer to keep it at 1 and 4, could give direction to editors to flag anything that smelled like an MEP
Motion from Chris Ferris seconded by Doug: Accept Jacques proposal for 1 and 4 No objections
Issue i082 can be marked as pending
b> i086 Alternative approach for MaxMessage http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i086
Paul: Explained issue and proposal. Deals with problem with problem of Java's handling of unsigned long
Motion from Chris seconded by Bob: Paul's proposal 1 in issue as amended by Anish's message (http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200601/msg00067.html)
No objection
Issue i086 can be marked as pending
c> i087 Acknowledgement Interval in CreateSequenceResponse http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i087
Paul: Explained issue and proposal. AI seems more like a protocol element than a policy parameter. Bob: This should remain optional Paul: Proposal makes it optional in CSR
Motion from Gil seconded by Jacques: Accept proposal 1 for i087 No objections
Issue i087 can be marked as pending
d> i075 Case of multiple RM Policies and DAs within an RMD scope http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i075
deferred
e> i083 Tom Rutt Fault Messages for Terminated Sequence http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i083
Tom: Explained new proposal, basically restricts to one fault type as some people had a problem with allowing optionallity of fault type in previous proposal. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200601/msg00124.html
Motion from Tom seconded by Matt: Accept proposal in message 124 http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200601/msg00124.html
No objections
Issue i083 can be marked as pending
10) Any other business
Marc I have some concerns about the CD draft, it seems that some of my comments agaisnt the earlier WD we not addressed Sanjay Were these raised as formal issues? Marc No, just comments to the list, thought editors ackowledged they had been adopted Doug Are you saying we moved the wrong WD to CD? Marc Not sure, I haven't completed my CD review. These don't seem like things that should block the CD but I wanted to note them. Sanjay Please post comments to the TC or editors list when you are done with your review
Paul I note that we are a long way from getting the CD approved Sanjay - I had programmed a reminder in the ballot, will follow up
Created
with Microsoft Office OneNote 2003 |
Prelim Minutes of 1192006 Teleco.one
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]