[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes for First day of Sunnyvale Face to Face meeting
The prelim minutes for the first day of sunnyvale Face to Face meeting are attached. Please post any corrections to the entire list. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes WSRX TC Teleconf
|
Preliminary Minutes WSRX TC Teleconf Dec 01, 2005 – Conventions Ø Action Item Motion § Resolution 1 Roll CallFrom Kavi, Meeting is Quorate 2 Assignment of ScribeTom Rutt agreed to take the minutes. 3 Administrivia4 Review and approve of AgendaAgenda: Day 1 - Wednesday Dec 14, 2005 ----- 8:30 Breakfast 9:00 Welcome by the host 9:05 Roll Call 9:15 Assignment of scribe(s) 9:20 Administrivia - Group Dinner 9:30 Agenda Bashing 9:45 AI Review 9:50 Review of issues log 10:00 New Issues since last conf-call 10:15 Recap of issues process 10:30 Break 10:45 Issue discussion: i080 Anish Karmarkar Remove ambiguity about the protocol being at least once on the wire i057 Umit Yalcinalp Classification of References (normative vs. non-normative) is needed i060 Jacques Durand Definition for "Reliable Message" i081 Jacques Durand RMS lacks support for InOrder 11:45 i050 Marc Goodner spec talks about delivery assurances but does not clearly relate them to the protocol 12:30 Lunch 1:30 i049 Tom Rutt Allignment and refinement of defintions for DA i021 Jacques Durand An RM Policy applies two-way i008 Tom Rutt Policy assertions granularity i006 Tom Rutt Source based delivery QoS policy assertion 3:45 Break 4:00 March F2F planning 4:15 i052 Umit Yalcinalp Should DA be separate assertion or parameter i075 Umit Yalcinalp Case of multiple RM Policies and DAs within an RMD scope 5:30 End of day 1 Day 2 - Thursday 15th December ----- 8:30 Breakfast 9:00 Review of Day 1/Agenda Bashing 9:15 i058 Tom Rutt State Transition Table Bob Freund to prsent and drive discussion 10:30 Break 10:45 Implementation/Interop Subcommittee Doug Davis to present plans and schedule 11:30 i078 Bob Freund Lost TerminateSequence i079 Bob Freund SequenceClosed fault and SequenceAcknowledgement(Final) 12:30 Lunch 1:30 RDDL presentation by Gil/Steve 2:00 Committee Draft Planning 2:30 Committee Specification Planning 3:00 Newly raised issues i061 Doug Davis Anonymous AcksTo 4:00 Review of action items 4:30 End . Paul C: the agenda is full. What happens if we get behind. Paul F: The timing is a separate issue than the ordering. If we are taking too long on small issue, we should move on to other issues. Paul C: there is no indication of which issues are important. Paul F: I suggest we move issue 80 out. Issue 50 is more important, but I thought we could address a few simpler issues first. Anish: Umit has to comment on my prior request. We can address Issue 80 after the break. Marc G: we might want some time on second day to talk about the issue process. Jacques: I would like to swap 08 and 06 to be after issue 52 and 75, in the afternoon. Marc G: Issue 21 could be repositioned. Agreed order: 49, 52, 75, 21. Jacques: During interop subcommittee discussion, we would like to discuss an application notes document, as is done in other OASIS TCs. Paul F: we should move lunch at 11:45, which would move issue 50 to after lunch. Paul C: what about committee draft planning. Can I move to progress the current drafts to CD status at that time. Chris F: I have not read them yet. I did not know they would be put up for vote at this meeting. Paul C: I think they are ready for a motion at this meeting, so I will bring this up at that time in the discussion. I thank the editors for getting the document out when they did. 5 AI Review#0053: Editors team to produce a RDDL document to be placed at the namespace URIs (3). Owner: Gilbert Pilz Status: Closed, editors did it. Assigned: 2005-11-10 Due: 2005-12-08 #0056: Ensure that the final WSA specifications include text for handling of anonymous IRI values for non-WSA EPRs Owner: Robert Freund Status: Still Open Assigned: 2005-12-13 Due: --- 6 Review of issues logMarc G: the only new issue from last week was my new issue. There is still a pending item to allow an issue to point at more than one target, and I will do this soon. The Pending issues have a proposal which needs to be applied by editors, The Done status is for when the editor’s have done the changes, but are still up for review. Resolved is for issues which have had the text voted positive by the TC. Marc G: I suggest we discuss a different issue taxonomy, e.g., adding a “new” category for issues which have not yet been accepted. Paul F: I would prefer we distinguished closed from dropped. Paul C: the reason I want to accept the current work of the editors, so we can batch the approval under one motion. What I do not like is waiting or approval by having a third working draft after the last CD. Sanjay: we might reconsider having a resolved status with quarterly CD progression. Paul C: Pending issues could have a status update at each meeting. TC members are responsible for Review issues. Paul F: I suggest we move this issues discussion until the second day of the F2F, to allow people to review Marc G new mail. 7 New Issues since last conf-callNew issue raised by Marc G to ensure that all XML in spec is well formed. Paul F: can the editors give us an overview of what they do before posting each WD. Paul C: all xml fragments need to be in separate files. Ø Action: Editors will report on the mailing list those procedures they use before posting a WD. Not accepted as new issue, Action item instead. 8 Recap of issues processMoved to second day. 9 Issue discussion:9.1 i057Umit Yalcinalp Classification of References (normative vs. non-normative) is needed Umit posted a proposal. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00131.html Paul C: I have four comments:
Paul C: all the above except the third could be changed now. Paul F: could we have a reference to both soap 1.1 and soap 1.2. Paul F: can we raise a new action item to have the editors update the references as suggested by Paul C? Glen D: we should agree before we raise an action item. Does everyone agree with Paul C. Umit: I would like to have two references for soap, 1.1 and 1.2. Paul F: since there are two behaviours Paul C: my updated recommendation is now:
Chris F: I am not sure about whether XML names 1.1 causes normative changes to our usage. Paul F: I suggest changes from names 1.1 will be small, if any. We could have problems raised as future issues. Anish: I suggest we could update ws-addressing to the CR version, at this time. Marc G: we have a deferred issue on this, if we take Anish’s suggestion we should open that issue now. Paul C: the WSS reference is the one I was not sure of. Chris F: we have to ensure that we keep our explicit dependencies when updating references. It might not be correct to always update to the latest reference, we need to actually look at the effect on our dependencies. Ø Action: Paul C will send out an email with a set of criteria for updating our references to the latest version. Paul C: we also need to know where the references are actually used. Paul C: If the reference can be used it is normative. Optional use is still normative. Matt L: The WSS reference is never used in the spec. Anish: WSSE prefix should be removed because we do not use it. Paul F: if we are not referring to it or not using name space, we should remove the reference to WSS. Anish: I move we remove the wsse prefix in the table, and remove the reference to wsse. Seconded by Gil Paul C: Lines 811 and 812 do reference wsse spec. Thus I can agree with removing the prefix from the table, but cannot agree with removing the reference. Paul C: I suggest friendly amendment to keep the reference to WSSE spec, but remove the wsse namespace prefix from the table. § Friendly amendment accepted. Paul C: I support the proposal to remove wsse prefix, and also agree with the proposal by Umit. § No objections to remove wsse namespace prefix from table, motion passes. Ø Action: editors to remove wsse namespace prefix from Table. Steve moved to accept Umit proposal to resolve issue 57, seconded by Umit. Peter N: the proposal is not clear on whether the “or” in the proposal should be asserted. Amendment: RTTM reference to be moved to Non-normative § Amendment Agreed § No objections, issue 57 to be resolved with Umit proposal, with RTTM reference as non-normative. 9.2 i060Jacques Durand Definition for "Reliable Message" There was some discussion on the status of the tabled motion from last meeting. The TC Agreed to start fresh on a new motion. Chris F email: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00124.html Herewith is the dispensation of my unrecorded AI regarding i060 [1] I searched through the document for the term "reliable mess*". Interestingly enough, I found more this time than last. Maybe Adobe needs to fix their find algorithm:-) I also searched (below) for "reliable delivery", but have made no proposed changes... that is only for discussion purposes. For each occurance of the term, I have listed the line number as per wd-07 [2] and the current text and proposed alternate text. Reliable mess* line 76-77: The primary goal of this specification is to create a modular mechanism for reliable message delivery. The primary goal of this specification is to create a modular mechanism for reliable delivery of messages. line 114-116: If an action IRI is used, and one is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then the action IRI MUST consist of the reliable messaging namespace URI concatenated with a '/', followed by the message element name. If an action IRI is used, and one is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then the action IRI MUST consist of the WS-RM namespace URI concatenated with a '/', followed by the message element name. line 125: Reliable Messaging Model no change line 128-130: The WS-ReliableMessaging specification defines an interoperable protocol that requires a Reliable Messaging (RM) Source and Reliable Messaging (RM) Destination to ensure that each message transmitted by the RM Source is successfully received by an RM Destination, No change line 160: Figure 1 below illustrates the entities and events in a simple reliable message exchange. Figure 1 below illustrates the entities and events in a simple reliable exchange of messages. line 161-162: The Reliable Messaging (RM) Source accepts the message and Transmits it one or more times. no change line 167: Figure 1: Reliable Messaging Model no change line 198-199: The RM Source MUST assign each reliable message a sequence number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent reliable message. The RM Source MUST assign each message within a Sequence a message number (defined below) beginning at 1 and increasing by exactly 1 for each subsequent message. line 204: Figure 2 illustrates a possible message exchange between two reliable messaging endpoints A and B. no change line 234-236: Additionally, over-aggressive re-transmissions have been demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of providing a reliable message exchange. Additionally, over-aggressive re-transmissions have been demonstrated to cause transport or intermediary flooding which are counterproductive to the intention of providing a reliable exchange of messages. line 693-694: The purpose of the <wsrm:SequenceFault> element is to carry the specific details of a fault generated during the reliable messaging specific processing of a message belonging to a Sequence. no change line 779-780: However, it is recommended that the security context be established first.Security contexts are independent of reliable messaging Sequences. no change line 796-803: That is, one aspect of security is to prevent message replay and the core tenet of reliable messaging is to replay messages until they are acknowledged.Consequently, if the security subsystem processes a message but a failure occurs before the reliable messaging sub-system records the message (or the message is considered "processed"), then it is possible (and likely) that the security subsystem will treat subsequent copies as replays and discard them.At the same time, the reliable messaging sub-system will likely continue to expect and even solicit the missing message(s).Care should be taken to avoid and prevent this rare condition. no change line 816: Availability – All reliable messaging services are subject to a variety of availability attacks. no change Reliable delivery line 78-79: It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between a source and a destination. line 160-161: First, the Application Source Sends a message for reliable delivery. line 184: Send: The act of submitting a message to the RM Source for reliable delivery. line 447-448: The RM protocol uses a <wsrm:Sequence> header block to track and manage the reliable delivery of messages. [1] http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i060 [2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15789/wsrm-1.1-spec-wd-07.pdf Cheers, Christopher Ferris Paul C: I have reviewed this, and I am fine with all of Chris F proposed changes. Jacques: I agree with Chris F changes and agree with them. However I send an email on Friday regarding some extra changes in the policy spec. Chris F: I did not review the policy spec. From Jacques email: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00105.html This proposal extends that proposed by Chris: …. In wsrm specification (0.7): ---------------------------- Additional updates: L448 (section 3.4) : "Messages for which the delivery assurance applies MUST contain a <wsrm:Sequence> header block." Reword as: "Messages for which a reliable delivery is required MUST contain a <wsrm:Sequence> header block." (rationale: Associate more clearly the notion of "reliable delivery" with the presence of Sequence header, now that it is the expression in use. Any reference to DAs is unnecessary here.) In wsrmp specification (0.2): ----------------------- L95: "..to ensure reliable message delivery." --> "..to ensure reliable delivery of messages." Jacques moved to accept Chris F proposed changes and two changes from Jacques email above, seconded by Chris F. § No objections, issue 60 resolved with proposal from Chris F and Jacques. 9.3 i080Anish Karmarkar Remove ambiguity about the protocol being at least once on the wire Discussion of meaning of “generate an error”. Anish moved (seconded by Umit) to resolve I 080 by accept parts 2 and 3 of email 85. with the following to replace part 1, “It is the responsibility of the RM Destination and Application Destination to fulfill the delivery assurances, or raise an error”. § No objection, issue 80 closed with proposed change. Discussion of raising another issue to change “raise an error” to “generate a fault”. 9.4 i081Jacques Durand RMS lacks support for InOrder Anish moved, Jacques seconded to accept Proposal 1 : i.e. to add a new invariant sentence, independent of DA in use. “These numbers MUST be assigned in the same order in which messages are sent by the Application Source.”, making it clear the new sentence is. § No objections, issue 81 closed with proposal 1. 9.5 i050Marc Goodner spec talks about delivery assurances but does not clearly relate them to the protocol Marc G moved to accept his proposal for Issue 50, from November, seconded by Paul C. Bob F: this mechanism is for transference of responsibility from RMS to RMD. What is a Delivery assurance fundamentally? If we did not have DA, one might presume that DA is what the protocol does. TCP has no prevision of an alternative to ordered delivery, the protocol just delivers everything in order. The uncertainty associated with DA usage as cause several issues to be raised in this TC. These DAs only talk about degrading functionality available from the protocol itself in the interface between RMD and AD. The provide no additional capabilities, and should be excised from the spec. The protocol must support at least once on the wire. Steve W: to clarify, you would like to replace DA with the most stringent behaviour for the protocol. Bob F: yes. Jacques: the charter ask that we fulfill and support DAs. The protocol supports all the DAs in the charter, I agree. We cannot just Ignore DAs because they are in the Charter. I do not think this makes thing more complex. We agree the behaviour of the RMS is not affected by DAs, but they are important for the RMS. Bob F: The fundamental protocol does provide messages in order, and duplicate elimination. The position I am taking, is that by slicing and Dicing things regarding the behavour of the RMD, which does not affect the protocol. I do not see use cases that are not covered by the full force DA. Anish: some of the reason for confusion in discussion of DAs is from the separation of protocol and RMD behaviour. The spec originally did not state this properly. We are now clear that DAs are for the contract between RMD and AD. If we always require ordered delivery from RMD to AD, this is a change of behaviour, especially for long sequences. Forcing RMD applications to deliver in order, when it is not required is a big cost. I do not think it complicates the protocol to support different DAs between RMD and AD. I have a proposal for Issue 6. Gil: I am confused about Bob’s proposal with respect to this issue. I thought the issue was regarding where we should discuss DA in the spec. I saw this as an issue on document organization, not changing capabilities. Marc G: the issue proposal is to clear up description of the DA terms. It did not make sense to advertise a capability that did not impact the protocol on the wire. Chris F: agree with Bob. Tom: the ordered delivery impacts both resources on the RMD side, and also delays experienced in the total system as seen from the RMS. Forcing ordered delivery on the system does have an impact of adding delays for delivery which may not be tolerated by the RMS, and also extra resourced for buffering messages at the RMD side. Umit: I agree that there are uses which are adversely impacted by requiring ordered delivery in all cases. Anish: what is the actual proposal. Marc G: it is posted to the Chris F: I did not hear Bob say that the messages must always be delivered in order. Glen D: I heard that he did propose that all messages be delivered in order. Bob F: I was trying to just limit my discussion to the protocol operation, not the application design at the API level. The protocol does not deal with the application to RMD interface. I am speaking in favor of Marc G’s proposed resolution. Jacques: Marc’s proposal replaces DA with “guarantee”. I do not see how this will help resolve the concerns which have been expressed about DAs. Marc G: replacing DA with Guarantee makes it a concept rather than a “thing”. The term, in my opinion, is what is causing the difficulty. The term Guarantee makes it an abstract concept. Jacques: that does not make a case for justifying this as a significant improvement. Paul F: I suggest we reconvene after lunch with the same queue. Break for Lunch Resume Umit: Does Marc G proposal require us to negate the resolution of I009, which added DA as a policy assertion. I suggest that this motion is not in order. Marc G: I provided new information, which means that I009 can be reconsidered as well. Gil: We decided I009 a certain way, now we are trying to reverse I009, and I do not see new information necessary to change our earlier resolution. Paul F: OASIS rules allow us to change things. Paul C: WS-policy should be used to impact visible policy. The DA do not impact protocol, and they do not impact both ends. Gil: from ws-policy:”other policy do not have wire manifestation, but do impact Services”. Anish: I concur with Gil and Umit that this is reverting the decision on I009. I think he should reopen I009. Anish: I move to amend Marc G proposal to remove the last two lines “remove section 2.5 by removing 233 267. Seconded by Gil. Paul C: I speak against this amendment. Glen D: I agree the amendment changes the thrust of Marc’s proposal, but I speak in favor of it. For Interop purposes there is benefit to know what “stuff will happen” based on a DA in use. Paul F: My view of WS-policy is not the same as expressed by Paul C, where it must affect behaviour at both ends. Paul C: we should not use ws-policy for application semantics. If it does not impact both ends. Glen D: it can impact both ends, just like windowing in TCP. Tom R: Behaviour may impacted by DA, as can be measured by a separate timer on delivery delay from AS to AD when buffering occurs due to ordered delivery. I agree that such a delay measurement is not available from the protocol itself, but it can, in some cases, be measured. The TCP protocol has requirements on the receiver service, that it must deliver octets in the same order they are sent. Gil: while the RMS behaves the same regardless of DA, the AS may decide it does not want to talk to a particular endpoint dependent on what DA is in use. Umit: ws-policy does allow for things which are not directly visible on the wire. Chris F: regarding the motion for amendment, what policy spec states is not relevant to this particular case. I do not think the proposal from Marc does enough just by renaming DA to Guarantee. My problem with DA as a whole, is that they are wildly misunderstood by everyone (everyone has a different opinion as to what they mean). We are using the same words to mean different things. The DA assertion provides a slippery slope which gets us to a place were we do not want to be. This is a QOS between RMD and AD, both logical entities. The protocol never changes, it is always the same. Advertising DA involves the “anding” of collective behaviour of AD and RMD. The protocol enables all sorts of DAs as it is. In practice people care most about exactly once. This is application stuff, and I speak against the motion. Anish: I disagree with Chris. We have cleared the confusion from the past. I think we all agree that the DA does not change what the protocol does, the RMS resends until is gets an ack. However applications do care sometimes about ordering of delivery, sometimes they do not. I do not like a partial solution to the problem I believe the 80/20 use cases do need DAs. We agreed that it ws-policy is not ready, we will abstract it out of our spec in order to progress the standard. Paul F: I am not hearing new points, or whether people are changing their minds. The amendment impacts whether policy does or does not impact DAs in use. Matt: Advertising DA by RMD thru policy is the question we are discussion. I do not believe a client will select its service provider based on delivery assurances, thus it does not have to be expressed by policy. Gil: use case 5, pub/sub, some devices cannot express order. We want to have applications have interoperable ways to express how they are using our protocol. For ws-policy to work the assertions must have understandable semantics. Interoperability, in a wide sense, is affected by which DA are in use. Glen D: Policy exists to ensure that all that is required is engaged. I think policy is appropriate for DA. Shivaji moved to call question on amendment. § No opposition to call the question on amendment. Paul F: voting yes on the amendment gives a motion that only changes the main document, leaving the DAs in the policy document. Voting No on the amendment leaves a motion which takes DA out of the policy spec. 10 in favor of amendment in room, 5 on line in favor 12 against amendment in room, 8 on line for no 15 yes, 20 no § Amendment fails Jacques: this motion is bundling too many things together. Rewording DA to guarantee is confusing and does not agree with our charter. I am against this motion. It could be split into two parts: a rewording exercise, and a removal of the Policy for DA. Paul F: we have a clear view on the policy portion of the motion. Steve W: I agree that renaming DA to guarantee does us no good, and does more harm. It will confuse people. Steve W moves that we amend Marc G proposal to only remove the expression of DA in Policy, and to not change the name. Seconded by Gil. Marc G: so the amended motion would be just to remove the da assertion stuff out of policy. Marc G: moves to call question on Steve W amendment motion, seconded by Chris F. Vote on Calling question: 16 yes 11 against. § Motion to call question fails for lack of 2/3 majority. Paul F: to clarify, if the amendment passes, the resulting motion will be to remove DA expression from the policy document. Chris F: I speak in favor of this amendment. Changing names does not help anything. Peter: I agree with Chris F, changing the name does not help anything. 22 in favor of amendment. 12 against amenedment. § Amendment passes. Resulting motion is to remove DA assertions from policy spec. Chris F: I would like to amend the resulting motion to use some of Bob F suggestions to add words to the spec, in the section which used to talk about DAs. Paul C: 176 -177 lines also have DA words Chris F moves, seconded by Doug D, to amend the resulting motion to also Replace lines 135 to 159 with the text “ The protocol supports reliability features which include ordered delivery, duplicate elimination, and guaranteed receipt for the RMD. It is expected that the AD and RMD will implement as many of these or as few of these characteristics as necessary to implement the AD. In any case the wire protocol does not change. “ And to remove DA from the glossary on lines 176 to 177. Chris F: I think having DAs in the spec was a mistake, since it does not affect the protocol. Resulting Motion if Chris Amendment passes: - Remove DA assertions from policy spec. - Replace lines 135 to 159 with the text “ The protocol supports reliability features which include ordered delivery, duplicate elimination, and guaranteed receipt for the RMD. It is expected that the AD and RMD will implement as many of these or as few of these characteristics as necessary to implement the AD. In any case the wire protocol does not change. “ - Remove DA from the glossary on lines 176 to 177 Anish: I do not understand how this helps anything. Glen D: Chris F stated that these things do not change what we define by the protocol. The messages exchanged between real instances may change, since if I timeout earlier it affects the behaviour of the system. There are things beyond the “protocol” that are important for the parties involved to know are in affect. There are cases when you need these things are we are screwed. Steve W: we care about removing DA from the spec. Without DA, applications have no real way of knowing how the RMD is going to behave. I am speaking against removing the descriptions of DAs from the spec. I would like to be able to use these features, and I would be like to see that the spec supports these features. Bob F: what constitutes a wire protocol? In defense of last sentence of new text in amendment, the state machine does not change based on which DAs are in use. Because the charter does not deal with RMD to AD interface, we do not lose anything. The RMD/AD and RMS/AS interfaces are outside the charter of this TC. I speak in favor of the amendment. Chris F: in response to Steve, our customers care as well. The application implementation will chose an AD depending on what is required by that application. § No objections to amendment. Resulting in motion: · Remove DA assertions from policy spec. · Replace lines 135 to 159 with the text “ The protocol supports reliability features which include ordered delivery, duplicate elimination, and guaranteed receipt for the RMD. It is expected that the AD and RMD will implement as many of these or as few of these characteristics as necessary to implement the AD. In any case the wire protocol does not change. “ · Remove DA from the glossary on lines 176 to 177 Anish: I speak against the resulting motion. Our charter includes DA, and our customers. Marc G calls the question, seconded by Paul C. § No objections to call question. Vote: 19 for 16 against § Motion passes, issue 50 resolved with proposed text change. 9.6 i049Tom Rutt Allignment and refinement of defintions for DA Drop issue because misaligned text no longer exists due to resolution of i050. 9.7 i052Drop issue since DA no longer exists in policy spec due to resolution of i050 9.8 i075Umit Yalcinalp Case of multiple RM Policies and DAs within an RMD scope Description As the 1-1 relationnship between RMD and port (or RMD-WSDL) is no
longer required (i010 allows RMS and RMD to span several endpoints) the specification needs
be clearer on how RM Policies apply, as an RMD will handle messages and sequences that are subject
to different RM policies - meaning protocol parameters as well as DAs. Justification RM policy
parameters are so far attached to the endpoint, while they actually concern the
RMD behavior, and this may cause an issue if one RMD serves several ports
with different policy parameters. Regarding DAs, same 1-n
issue: an RMD must be able to handle messages according to different DAs. While the DA to be enforced on a message can be resolved separately
from protocol concerns (e.g. based on endpoint info), that would require looking at extra
headers if this RMD is deployed as an intermediary. Also that would not work if DAs are to be
attached at a finer granularity than endpoint (e.g. message or operation). Proposal
12005-11-14 Associate more explicitly policies (and DAs) with sequences, e.g. either in CreateSequence, or CreateSequenceResponse, so that an RMD can apply different policies to different sequences just based on sequence ID. Umit: need to decide what scope of CreateSequence is, before coming up with replacement text. Doug: the policy on CreateSequence is determined by the wsdl annotations on the endpoint the create sequence is directed at. Ø Action: Doug D to add RM source back into the glossary. Paul F: RMD can respond with parameters in createSequence Response to state what is happening. Glen D: in the extreme the source can rely on an error response to know that rm is not supported by an endpoint. Umit: what is createSequence targeted to, and what is its scope. We need to nail this down. Steve W: the resolution to i010 has not been fully reflected. Is the sequence between two endpoints? Doug D: RMD is an endpoint for a particular message. Anish: sequence is between RMS and RMD. Umit: given ep 1 and ep 2. can I create a sequence with message to ep1 with a second message on sequence to ep 2. Ø Action: editors shall determine whether the resolution to i010 has been fully reflected in the text. Jacques: several endpoints may be served by the same RMD. What governs behaviour wrt each ept. Ack interval could be different for each Endpoint served by an RMD. Removing AI from endpoint policies is one way to resolve this, since it is a tuning parameter for the protocol. Another alternative to ensure all parameters related to the same RMD be consistent. Chris F: regarding confusion of what is endpoint etc, Some messages will escape one ESB cloud to arrive at another. Between clouds, there is an RMD between the ESB clouds. This is one huge pipe to reliably exchange messages between the two ESB clouds. It is more likely to derive the policies from the RMD rather than the multiple ADS. Anish: there is a mismatch between policy at port level and policy at RMD level. Paul’s idea allows knowledge of what is in effect for the sequence. Umit: the problem comes from attachment of policy to wsdl. If multiple endpoints are involved this could be problematic. Paul C: I hear that there are 3 proposals. Can we get a concrete proposal to review as a TC. I am not convinced we should take the parameters off of the WSDL. Anish: would you be opposed to both? Paul C: I see an advantage to doing both. Considerable discussion ensued on how the policy in use is conveyed. Gil: there is no way to convey these parameters without ws-policy. I speak in favor of Paul F suggestion of passing parameters in CreateResponse. Paul C: as in the past, we know how to exchange these parameters out of band. Bob F: Restricting to AI and Max number as the only parameters would simplify this discussion. Does allowance of policy extensions color the debate? Are we talking about the general extension case, or just these two. Anish: I am not sure AI is required, however we already have extensibility elements in create sequence request and response schemas. Paul F presented four options for discussion: · Option I: Recommend consistent policies for all endpoints and RMD · Option II: policies determined by destination of CS Request · Option III: Assert Policies via parameters carried in CS Response · Option IV (I with III) Jacques: I would prefer a more general discussion regarding policy. I am in favor with option II Anish moved to accept option IV, seconded by Jeff M Do Option I, and in addition allow (as an option) asserting policies in CSR, by including policy assertions in CreateSequence Response. Paul C: I am not convinced that there are no other options. I would vote against this motion, since I do not see how it resolves the issue. Sanjay: I ask Umit if option IV resolves the issue. Umit: I am not sure. This issue came from Jacques not from myself. Marc G: this issue seems implementation specific. I do not see how this motion resolves i075. Jacques: I would like to hear the results of a straw poll, then have someone craft appropriate text to resolve the issue. Matt: I would prefer the combination of I, II, and III. (call this Option V). Doug D: the policy of where the CS goes to is all that matters. You are going to get back its parameters in the CS response. Anish: that is ok for run time parameters, but if an extension has something like DA, you would want it to be consistent with everything on the sequence. Sanjay we do not seem ready to make a final determination on the resolution. Anish: I could create a more detailed proposal, if I know how the TC is leaning. Chris F moved to table motion until tomorrow so we can see Anish proposal, Anish seconded motion to table. Paul C: III seems to be an add on. Why is this not an answer to a different issue. Sanjay: does anyone have an additional Option. Straw poll, each can be selected more than once. Option I: - 4 Option II – 6 Option III – 6 Option IV – (I and III) – 5 Option V (I and II and III) - 8 No objections to table motion. Ø Action: Anish and Paul F will produce a more detailed proposal for discussion tomorrow. 9.9 i021Jacques Durand An RM Policy applies two-way Jacques: attaching an RM policy to an endpoint does not apply to messages sent from this endpoint, but only to messages which are received by that endpoint. Attaching rm policy to subject endpoint is to treat it as a receiver. Doug: what if you want to express a policy for reliability on the response? Tom: What Jacques is stating seems valid as a default for attaching policy at endpoint level. To attach policy regarding the response would require attaching policy at the message level. Marc G: the impacts of Jacques proposal seem to indicate the need for message level attachment to support reliability on outbound. There was a discussion on use of offer, .in this context. It was clarified that offer is a protocol optimization. Matt: people will want reliability in both directions, and we need to have a way to do this in the WSDL. Thus we have to work out how to do policy assertions to do this. Tom: setting policy at message level would meet the needs. However if two operations on an endpoint exist, one with reliability on request only, the other with reliability on request and response, will result in a reply to callback which has a create sequence for the reliable response, and no reliable sequence for the non reliable response. Jacques: attaching policy at message level complicates the standard. Gil: I agree with Jacques that this is complicated, given different retry intervals etc. We could express a mechanism at the endpoint level, whereby all the operations on that endpoint are reliable for in, all are reliable for out, or all are reliable for both in/out. Jacques: I am not against message level attachment; however it will be a bigger hammer than what we need for this nail. Tom: Gill’s proposal will require creating separate endpoints to cover the case of different requirements on reliability for different operations. In the end, this might be just as complex as attaching policy at the message level. Discussion on whether attaching at port level requires it apply to all operations (unless overridden). Glen: currently the nature of the policy determines whether it applies to all nested constructs in the wsdl when attached at a particular subject level. Sanjay:
Agreed to keep issue open, with further discussion. Ø Action: Gill will do concrete proposal for option 3 in straw poll for Issue 21.. 10 March F2F planningThere will be a Kavi ballot to select between two choices
11 Issues Discussion Resumed11.1i006Tom Rutt Source based delivery QoS policy assertion Tom: since we no longer have DA, the only policy left which might apply is ack interval, there seems to be little value left. Matt: Since the source can always issue an ack requested, there is no need to assert the policy parameter value. Chris F moved to close with no change, Marc G seconded. § No objection to close issue 006 with no change. 11.2Issue 57 resumedPaul C presented his proposal to refine Umit’s proposal for i057. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200512/msg00145.html 1. [SOAP] W3C Note, "SOAP: Simple
Object Access Protocol 1.1," 08 May 2000. Q: Should the TC add a normative
reference to SOAP 1.2? A: Given that Section 4 Faults
refers to both SOAP 1.1 and SOAP 1.2, I propose that a normative reference to
SOAP 1.2 should be added. 2. [XML-ns] W3C Recommendation,
"Namespaces in XML," 14 January 1999. Q: Should the TC update this
reference to Namespaces in XML 1.1 (http://www.w3.org/TR/xml-names11/)? A: Namespaces in XML 1.1 is meant
to be used with XML 1.1 document so I expect we should NOT
make this change since neither SOAP 1.1 nor SOAP 1.2 reference XML
1.1. See my suggestion below about
adding a reference to XML 1.0. 3. [WS-Addressing] D. Box, et al, "Web Services
Addressing (WS-Addressing)," August 2004. This reference should be
re-considered when the deferred Issue 42 is resolved. 4. [SecurityPolicy] G. Della-Libra, "Web Services
Security Policy Language (WS-SecurityPolicy),"
December 2002. Q: Should the TC update his
reference to the most recent version of the Security Policy document which is
dated July 2005 (http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/
<http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/> )? A. Since the July 2005 document
has been contributed to the OASIS WS-SX TC, I propose that we update this
non-normative reference to the most recent published version. 5. [XML] Q: Should the TC consider adding a
normative reference to XML 1.0 Third Edition?
Note that RMPolicy already refers to XML 1.0
Third Edition. A: Yes. I propose that a reference to XML be added to
the RM Abstract. I propose that the
text: >By using the SOAP [SOAP] and
WSDL [WSDL] extensibility model, be
changed to match the following text from RMPolicy: >By using the XML [XML], SOAP
[SOAP], and WSDL [WSDL 1.1] extensibility models, Note to Editors: RM uses the
reference form [WSDL] and RMPolicy uses the form
[WSDL 1.1]. I suggest you harmonize the
form of the "WSDL" references across the two documents. 6. RMPolicy
references a) [SOAP] I propose we also add a reference
to SOAP 1.2 and leave it to the Editor's to figure out where the reference
should be used. b) [XML-NS] I propose no change as per my
point above. c) [WS-Addressing] Not used in RMPolicy d) [SecurityPolicy] Not used in RMPolicy. e) [XML] A reference to XML 1.0 Third
Edition already exists in RMPolicy. [1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15789/wsrm-1.1-spec-wd-07.pdf [2]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15796/wsrmp-1.1-spec-wd-02.pdf
Bob F moved to accept Paul C proposal, seconded by Glen D. Chris F: I prefer second edition for XML 1.0 rather than third edition. Paul made Motion to amend (seconded by Chris F) by changing reference to XML 1.0 From third edition to second edition. § No objection, amendment to Bob F motion passed. § No objection to motion, issue 57 closed with Umit’s proposal plus amended Paul C proposal.. 5:30 End of day 1 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]