[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of WSRM TC conf call 7/01/03
The prelim minutes are attached. If you want to ammend these minutes please post your requested changes before this Friday Evening. Roll call amendments should be posted asap. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
|
Preliminary Minutes WSRM TC Conference Call – 1 Roll Call
. Meeting quorate (24 voting members). 2 Minutes Discussion2.1 Appointment of Minute TakerMark Goodner will focus on the issues list resolutions. Tom Rutt will take minutes. 2.2 Approval of previous meeting minutesFace to Face Meeting Minutes: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/2366/WSRMf2fMin-053003.pdf http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/2687/MinutesWSRM-061703.htm Sunil moves to approve both minutes. Alan Wiesberger seconded. No opposition minutes approved. 3 Approval of Pending Issue Resolutions from Previous meetingsRel, 7, 9, 25, 30, 42, 48, 5, 6, 3 Requirements issues. Nobody opposed to moving these to closed status. Rel 14 - annotating the wsdl with documentation Mapping and binding issues. Consensus – too complex to do binding issues at this time. Do not change the use of wsdl. Annotation, non normative could be put in appendix. Intention is if we do not do. Agreed to Add new spec issue for non-normative annotation for use with wsdl. Nobody opposed to making pending resolution to rel 14 final. Rel 17 – Agreed resolution is to add text to requirements: Receiver must persist message ID to support duplicate elimination. The receiver is required to persist out of order messages to support ordered delivery. No objection to closing issue with the more accurate resolution in sentences above. Rel 33 actual wording agreed The receiver has received the message and the sender is no longer responsible to persist the message (i.e. the receiver now has responsibility for message persistence) Nobody opposed to closing Rel 33 with this resolution. 4 Discussion of Requirements Issues:Issues List: (From Mark Goodner): http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/2681/wsrm-reqm-issues.html 4.1 rel 44Peter Furniss stated that expired messages can be faulted or ignored. Pete Wenzel: This brings up possibility that sender and receiver can be out of synch Pete Furniss: If you receive the resent timed out message, you still ack the receipt of the prior message. Peter: Expiry time has to be within the persist duration. If you remember you got it before, you can repeat your ack of the earlier receipt. If you cannot be sure , because you never saw it, that you earlier gave a valid ack to in time arrival, you should not send a positive ack to the expired message (you could send a fault). Duplicate is the same message being sent twice. Magdolna: expired at receiver it must also be expired at sender. The sender could have dropped the whole tracking. Payrits: How long must receiver keep state of messages. It is indeterminate what is done after that. Peter explained persist duration: Do you legitimately burn all records at expiry time. This time after that would be the persist duration, which is a local configuration parameter. Scott: Our ack semantics do not guarantee delivery to implementation. Stated by someone: If you know its safe you can ack it. Peter: If it comes in late, it should be ignored, or should send back a fault. Peter: If you got the message on time, and it was valid when you got it, and you already acked it, and you know that is what happened, you could send a valid ack. Payrits: There may be no fault because we are using one way messageing. Magdolna: This is a spec issue. Re-clasify 44 as spec issue. Add new requirements Issue on reuse of message IDs. Resolve requirements issue for R44, as Senders must not reuse message IDs. Agreement on new requirement. Spec issue 44 on what happens if receiver receives an expired message. More general wording: semantics of time to live. Open up for email discussion towards a resolution. 5 Discussion of Specification issues(in Issues list from Mark Goodner) 5.1 Rel 13The existing specification contains a number of elements that may apply to many use cases beyond reliable messaging. For example, From / To may be useful for (unreliable) routing through an intermediary. Alignment on a set of common components meeting these general requirements across use cases should be sought Mark G stated we should close this issue with no action. Deal with each element on its own. Magdolna agreed to eliminate this as an issue Nobody opposed to close this issue with no action. We will deal with each proposed parameter on a case by case basis. 5.2 Rel 21 From ToIwasa: From and To can be useful in non HTTP bindings. Wants to keep in spec. Magdolna: do now know the reasons to keep. Remove them. Soap does not specify any soap addressing, it is using the underlying transport. The underlying transport provides info for endpoints. Bob Friund: Is there a necessary and sufficient way to identify endpoints. Magdolna: this is not only source for identifying endpoints. Magdolna, this is redundant and not needed. Payrits: Identify sender and receiver is nice, but it is not necessary. For which functionality of WSRM is it needed. Iwasa: If you implement RM in software you need something like from and to. There is no standard representing from and to for soap. To use RM you need to have from and to available. Payrits: Where does processor use this information. If he can implement without why should be have this. Sunil: not mandatory, could be available for use. Mark – could be required for intermediaries. Magdolna: is this enough for more than one intermediary. Mark – which wsrm node is ultimate sender and receiver. Payrits: Since we decided to leave out intermediaries, we do not need this. Peter: if from and to are to identify nodes on path, they need to be tightly tied to wsrm. This is not what it says at present. Mark G: the current definitions of from/to are ambiguous and they are optional. Peter; if they are not used for wsrm processing, why put them in. They are extra features. Peter: Do we have hundreds of wsrm specs, even if they are not an essential part of main target. Mark G: Keep from/to for now, and clarify as optional how they relate to wsrm. Leave this open, have further discussion on email thread. Joe Chiusano: he will send url on his articles in this area. Mark G: email thread needs to continue on discussion of definitions. Bob Freund: Iwasa should give more examples on its use. Need to continue discussions on the email thread. 5.3 Rel-36: messageID and groupID/seqNo redundancySummarized: Have one or the other or not both. Payrits: Unique message ID would be useful for other general sense. The Group ID could be a record number, with each in being a separate message. Tom Rutt asked why we would have both messageID and GroupId/SequenceNo. Payrits: MessageId could be used by other processing, such as security. Need sequenceNO/Group ID for ordered delivery. Bob Freund: whether the groupID/sequence no constitutes a message id. It has all the features. Tom Rutt: I, as a member of the TC, rather than as chair, would like to use groupID/sequenceNo for all wsrm needs. Magdolna: Remove groupID from header. Could Use MessageID for its purpose. After discussion, the name of the global unique portion of the pair is not important. Agreed that One global ID and sequence number is acceptable for all of WSRM use. Magdolna :Same Global Id could be used for group. Tom Rutt: this is supported by groupID/seqNo concatenated key. Bob Freund : the uniqueness message id is the concatenation of the globally unique id and an integer sequence number. Scott: you could send zero as a default value in the schema for the sequenceNo. This could be exploited when ordered delivery is not required. Joe Chiusano: RDBMS groupID is table name equiv, sequence ID is row id equiv. There has always been a quick path as globally unique id in index. Parallel is advantagious to exact message as fast path by global ID. Bob: the concatenation of keys still represents a unique id. Single concatenated id with global ID and integer sequence number. No opposition to closing with eliminating message id from WSRM headers, and using the groupID/sequence number as a concatenated unique ID for WSRM identity purposes. Close issue 36 with this resolution. 6 Discussion of Editor’s Draft Requirements DocumentPayrits: Action item to update before the next meeting. Can discuss at the next meeting. Next discussion on requirements could to be to approve. Be prepared for approving in near future. Action: Iwasa will work on a new editor’s draft on the reliablity spec. for next conf call. 7 Future Meetings and schedule discussionAgreed to make the next face to face Sept
3, 4 and 5, in This date change is needed to avoid conflict with BPL wg. There are hotels in the area. Need a car or limo. Dock will arrange the meetings for 3, 4 and 5. Finalized the dates. Dock will send out the information by email. Meetings currently planned for July 15, 29 th, and Aug 12, Aug 26, continue on the two week schedule. 23rd sept. first conf call after Boston face to face. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]