[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes for wsrx TC teleconf 12/14/2006
Please provide corrections to the attached prelim minutes before next monday. Tom Rutt Have a happy holiday vacation. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Minutes of OASIS WS-RX Teleconference
Prelim Minutes of OASIS WS-RX Teleconference Dec 14, 2006
Start Time:4:00 PM Eastern Daylight Time
Sanjay acted as chair.
Textual Conventions
Ř Action Item Motion § Resolution
1 Roll CallFrom Kavi: meeting is quorate
Tom Rutt agreed to take minutes. 2 Agenda ApprovalAgenda 1) Roll Call 2) Review and approval of the
agenda 3) Approval of the Dec 7, 2006
meeting minutes Draft minutes
http://lists.oasis-open.org/archives/ws-rx/200612/msg00009.html 4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 5) New issues 6) Discussion of PR Issues a> PR001 WS-Addressing comment
on ws-rm related to use of extended anonymous uri http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001 b> PR026 Retransmission http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i026 c> PR033 back-channel not
defined http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i033 d> PR035 Delivery Assurance http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 e> PR009 "Duplicate
Elimination" and "Message Ordering" http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 f> PR020 Message ordering and
duplication http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 g> PR021 Piggy-backing
problematic http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i021 h> PR018 Piggyback message
combinations http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i018 i>
PR022 RMD cannot detect some incomplete Sequences http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022 j> PR007 RM Destination lacks a
mechanism for cleanly terminating inbound sequences http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007 7) Any other business No comments, agenda approved. 1 Approval of the 12/07 Minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21521/wsrxMinutes-120706.htm Tom moved to approve 12/07 minutes, Paul K seconded.
§ No objections, minutes of 12/07 approved. 2 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php Report created 14 December 2006 01:33pm EST #0113: Sanjay to follow up with Paul to create a review plan
Note that there is a new ignorable attribute Owner: Sanjay Patil Status: Still Open Assigned: 2006-12-07 Due: --- #0114: Paul to talk to some of the people and find a middle
ground proposal for PR26 Owner: Paul Fremantle Status: Closed, with Matt Lovett proposal Assigned: 2006-12-07 Due: --- #0115: Stefan to put together concrete objections to Gil's strawman on PR007 Owner: Stefan Batres Status: Still Open Assigned: 2006-12-14 Due: --- #0116: Bob and Chris to propose language for PR033 Owner: Robert Freund Status: Done Assigned: 2006-12-14 Due: --- 3
New issues
None 4
Discussion of PR Issues
4.1
a> PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i001
Doug Davis submitted email: http://www.oasis-open.org/archives/ws-rx/200612/msg00024.html On last week's call we were asked
to write up something that would describe the scope/details of the proposal we
made w.r.t. moving MakeConnection
into a new spec. I think the text below
should cover that. Proposal: Move MakeConnection
into a new specification Details: Move the MakeConnection
(and related portions of the RM spec) into a new specification that will be
developed by the WS-RX TC. The overall
scope of the TC itself will remain the same. The scope of this new
specification will be limited to the development of a mechanism that will
establish a transport-specific back-channel.
This back-channel will be used in situations where an anonymous URI is
used as the destination EPR for messages and there is no existing/appropriate
back-channel available. The
specification will try to address the use-cases that have be identified during
the recently discussions in the WS-RX TC.
These include: -
Attempt to not restrict the RM processing model
choices when switching from async to sync MEPs -
Support for multiple endpoints behind a virtual
RM processor -
Support for gateway scenarios (on RMS and RMD) -
Support for allowing an RMS to advertise its
support for MC -
Support for allowing an RMD to advertise its intention
to use MC -
Support for anonymous AcksTo
(in particular for the Sequence Faults) -
Support for unreliable-in/reliable out scenarios -
Retain the notion of the RMS being the initiator
of new Sequences -
Support for uniquely identifying anonymous endpoints As this specification will compose
on top of the base WS-RM specification, the base WS-RM specification's issues
will be prioritize over the MC issues.
The list of PR issues that this new specification will
address are: i001 WS-Addressing comment on ws-rm
related to use of extended anonymous uri ws-rm design
* i015 RMD polling
ws-rm, ws-rmp design
i027 Where do Sequence Faults go when the
RMS is anonymous ws-rm design
i028 MakeConnection
preconditions are unclear ws-rm design i029 Opaqueness of URI identifiers not
preserved by RM anon URI ws-rm design i030 Facilities to support optional MakeConnection underspecified ws-rm design
i031 Scope of MakeConnection
is unconstrained ws-rm design
thanks -Doug Marc G: I agree with Doug’s summary. Marc G: I move we proceed to resolve PR001 with Doug’s proposal in email, seconded by Bob F. Anish: I do not see that this should affect the priority of progression. I would like to see the work on both of these specs proceed in parallel. I so not think one has to be prioritized over the other. Sanjay: we need to continue to resolve Make connection issues. Jacques: I agree it is good to separate the Make connection. If we do it in this TC we must restrict ourselves to requirements involving Reliable messaging. We need to avoid working on a overly general solution. Sanjay: what about the wording of Doug’s proposal. Jacques: I would like to remain within the scope of our charter when we go forward on the split off spec. Colleen: The TX group split off core items, and it worked well. Martin C: We need to get both done to fulfill charter. I do not care about one or two docs, however we should have an orderly way to deal with the existing issues. Lets move forward. Anish: The prioritization is binding tc to actions. We approve the agenda each meeting, that should suffice. I would like to remove the prioritization part. Anish: Move to amend by removing prioritization part from Doug’s proposal, Seconded by Martin C Marc G: we can get the core document out there quicker, since we do not have to hone the make connection issues. I think it is better to sequence the work. Sanjay: prioritization depends on getting input contributions to evaluate. We need to assign action items to complete the work. The prioritization is not at the core of this proposal, since it is part of the normal work of this TC. I would like to focus on the splitting of documents. Anish: I suggest the use cases MC addresses are important for RM. We might start a task force to complete the MC work in a timely manner. Doug D: The prioritization is a statement that our customers need RM now. I think it is a slight favoritism to core RM issues. Jacques: I understand concern of Anish. It should not be interpreted to slow down the core spec. I do have a reserve for pushing out the MC work later on might prevent us to look at cases like reliable request response. We should move forward with MC work in parallel with the core spec, to make possible reliability in response over Firewall. Sanjay: we should determine who can do work on the spec by when. Lets postpone discussion of prioritrization. Martin G: if we split, rm spec goes out for another public review. We work on Make connection spec before its public review. It would nice to get both to committee spec together. Paul C: we should: - pass the motion un amended, - create a new task force, - resolve remaining core issues, put out for second public review - resolve Make connection issues. Paul F: I propose an amendment to this motion, at the time we do this the editors create the new document, and vote on the make connection as it is today version as a committee Draft. Martin C: I do not understand the waiting for working on Make connection. Paul C: the public review is on rm and rm policy, during that time we can work on make connection. Martin C: That seems fine. Anish: the MC document has no external dependencies, so there is no need to delay it. Whether MC should be included has been voted in the affirmative twice in this TC. If we deprioritize this work, it could be seen as a separate and kill motion. Marc G: this feature was added with a small vote margin. Taking out of core spec is the best way to work together in the TC to move forward. This will remove the controversy we have seen in the past. Dave O: I share Anish’s concerns to avoid separate and kill. Maybe it will work out as Marc G proposes. However we need to get interoperable implementations against all required features. Jeff M: how does moving a venue resist controversy? Doug D: I agree that separating it out will help move things along. We can address the core stuff in a timely manner, while working out the details on the additional features of Make Connection., Doug O: When I see things get factored off, that is a way to split the conformance requirements for implementations, rather than technical merit. Jeff M: There is no assurance that the second spec will ever become OASIS standard. Jacques: considering the prioritization in Doug’s proposal, I favor the amendment from Anish. The wording of the prioritization is not precise. From Chat:
anish: the reason i'm in the queue is:
MC spec is to enable certain core RM usecases. It
happens to be that MC is generally useful. But it is important to ensure that
RM is composable with MC and that the MC spec does
not require changes to the RM spec itself. Therefore it is important to ensure
that the work goes on in parallel Paul C: I move to call the question on the amendment, Chris F seconded. Yes means proceed to vote, no means continue discussion Vote on motion to call question: 20 Yes 9 No Call of question passed. Vote on amendment 14 Yes 11 No 5 Abstain Ammendment to remove prioritizations passed. Anish called question for amended motion, Chris F seconded. No objection to call question. Vote proceeds on main motion. Vote for main motion: 23 Yes 3 No 6 Abstain Amended proposal is accepted to resolve PR001. Sanjay: lets separate out the make connection text as current into its own draft spec. Doug D: I could have this done before the next phone call. Sanjay: that is next year. Paul C: we need to distinguish which issues are for which document. Action: Marc G will sort out with Chairs and editors on
apportioning existing issue against the core spec and the new Make Connection
spec. 4.2
b> PR026 Retransmission
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i026 http://lists.oasis-open.org/archives/ws-rx/200612/msg00034.html > While the Sequence is not closed or
terminated, the RM Source >
SHOULD retransmit unacknowledged messages. >
Moved by Doug D, seconded by Gil to close PR026 with proposal from Sanjay. No objection to close PR026 with Sanjay proposal. 4.3
c> PR033 back-channel not defined
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i033
bob: Backchannel: When the underlying transport provides a
mechanism to return a transport-protocol specific
response without initiating a new connection, we refer to this mechanism as a
backchannel. Chris F: SMTP does not have a back channel. Paul F: In my view SMTP has a reply to, but that is not a back channel. Chris F: the text bob quoted deals with the connection orientation of an underlying protocol. It means not to start a new transport connection. Bob F: the definition is targeted at the Make Connection mechanism. That use case was that the reply to endpoint is not addressable. The Back channel does not apply to SMTP use cases. I believe the approach of defining the back channel to be transport capability is the way forward. Peter N: The word back channel is only used for anonymous URI. So the description should be limited to the anonymous URI, An SMTP reply to would not be an anonymous URI. Discussion ensued on the scope of back channel. Anish: the definition does not require the backchannel to be able to carry a soap message. By this definition a low level small pipe ack would be considered a back channel, however it could not carry soap message. Bob F: for Make connection to work the back channel must be able to carry a soap body. Chris F: I do not agree that SMTP has a back channel, the smtp reply to can be spoofed, a connection return message cannot be spoofed. Paul F: TCP has the ability to spoof addresses. Chris F: however the connection provides integrity. Paul F: I prefer Matt’s original definition - Backchannel: When the underlying transport provides a mechanism to return a transport-protocol specific response, we refer to this mechanism as a backchannel Jacques: The back channel, regardless of addressability of reply endpoint, will always work. That is the primary requirement. Thus I do not like the broader definition from Paul. I prefer the inclusion of connection in the definition. Bob F: SMTP RFC 2821 is protocol, and RFC2822 is definitions of elements that can be carried on any protocol. The restriction of the definition to a connection is crucial. SMTP does not have a connection. Chris F: the proposed definition uses the word “transport protocol”. The definition relates to the connection orientation of the transport protocol. Anish: I do not want people to assume that we are not using protocols other than TCP. HTTP is the level we are talking about, it always has an http response coming back. Gil: This group does need to define back channel. The wsaRM anon uri has a strict use of back channel. However wsrm:anon has a different use of the backchannel. The definition cuts to the heart on why make connection works. The requirement that the backchannel can carry a soap message should be a necessary attribute for the back channel. Doug D: Dug: Backchannel: When the underlying
transport provides a mechanism to return a transport-protocol specific response
(with a SOAP message) without initiating a new connection, we refer to this
mechanism as a backchannel. Doug D moved to resolve issue pr033 with text above, Marc G seconded. No objection to resolve issue pr033 with agreed definition of back channel. 4.4
d> PR035 Delivery Assurance
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035
Mail from Jacques: http://lists.oasis-open.org/archives/ws-rx/200612/msg00031.html After more discussion with issues
originators: they want mostly a couple of things: 1. Definitions for the reliability
assurances mentioned in the charter (At-least-once, At-most-once...) . These are informally defined in the charter but these
definitions really belong in the spec, using the precise terminology introduce
by the messaging model, and also referring to protocol elements. For example,
there are several mentions of " message duplicate" , but no clear definition of
this term (how is a message identified ? with wsa:MessageId?
or by sequence ID + sequence # ? the latter is only alluded to in the 2.4
example) Rationale: even if the support and
requirement for reliability assurances is out of scope, product developers need
to refer to common definitions when they decide to implement these. Their
implementation will affect the design of RMD product from the start. 2. RM Policy assertions that
identify these reliability assurances. Rationale: for those implementors who have decided to implement reliability
assurances, the users of their products need to be able to exchange agreements
or capabilities on these. For those service providers who require or support
these assurances, there needs to be an interoperable way to advertise them. Note: clearly there may be more reliablity assurances than the minimal set mentioned in the
charter - and in particular, there may be several flavors of ordered message
delivery. Also different flavors of what to do in case of
failure. But a minimal set is needed in a first phase. So... sounds a bit like "deja-vu" , but
note that the above proposal does NOT make any requirement on implementations,
and does NOT impose that the protocol vary with the delivery assurance. Only
that a core set of definitions and policy representations be present for
those who choose to implement them and to share them. Regards, Jacques Jacques presented his email. Chris F sent mail: http://lists.oasis-open.org/archives/ws-rx/200612/msg00008.html Previous to the LC draft of the
WS-Policy 1.5 - Framework spec, there was no means by which you could
include an assertion that had no client impact and/or on-the-wire
manifestation. All assertions had to be
both understood and would manifest themselves in the interactions between the
two parties. However, in the LC draft, the
WS-Policy WG introduced a new attribute: wsp:Ignorable, of type boolean, that could
be added to an assertion to indicate that at the policy consumer's discretion,
that assertion could be
omitted from consideration in the intersetcion
algorithm. Thus, a service provider that wanted to
advertise a QoS capability of the service, sich as a delivery assurance, that in fact placed no
requirements on the part of the client, such that the client could choose to
ignore it if it didn't understand
that assertion. Effectively, it is a means for the service prvider
to advertise in its policy "here
is an assertion, but you don't need to do anything about it, or even understand
it and you can still interoperate
with me". One of the concerns that we had
previously with regards to delivery assurances (DA) was that regardless of what DA
was, or was not inforce, the protocol was exactly the
same in all cases. Thus, prior to the changes
introduced in the WS-Policy LC draft, there was really no means of defining a
policy assertion that could
advertise a DA and also provide a means by which the client could choose
whether it wanted to
consider it in the intersection. Given that WS-Policy now has this
new feature, and given the concerns that have been raised by FIX and others, perhaps we might
consider addition of policy assertions that reflected the semantics of the DAs
we previously had in the input specification, with a strong recommendation that
service providers leverage the wsp:Ignorable='true'
attribute to allow for a client to omit the assertion from consideration in the
intersection algorithm. e.g. <wsrmp:ExactlyOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/> <wsrmp:AtMostOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/> <wsrmp:AtLeastOnceDelivery wsrmp:InOrder='true|false' wsp:Ignorable='true'/> This approach would give the client
(RMS) the choice as to whether to engage with the service as it
could use the policy intersection mode of 'strict' to ensure that it only
interacted with a service
provider that supported RM and offered the DA it required. Alternatively, a
client that
didn't care what the DA was at the service provider could use the lax mode of
intersection to omit
the assertion from the intersection algorithm. Considerations: - only ONE
DA could be advertised per service endpoint, as there is nothing in the message that would
indicate which was in play since the protocol operates the same in all cases.
There is nothing in WS-Policy that can enforce such a constraint (that an
assertion be exclusive of others in any alternatives in the policy statement).
We would need to have a constraint like: A Policy statement MUST NOT contain
more than one of the DA assertions in its collective alternatives.
A Policy statement MAY include the same DA assertion in more than one
alternative. - Should probably provide guidance
on use of the wsp:Ignorable
attribute (e.g. SHOULD be used unless the
service is being deployed with knowledge that all consumers of the service will both
understand that assertion and be willing to include it in the policy
intersection) Thoughts? Sanjay: if the outline is acceptable, Chris F could produce a more exact proposal. Marc G: I have sympathy for what Jacques and Chris are proposing. I will post my thoughts to the list before the next call. Sanjay: are there objections to Jacques general proposal. Jacques: my main point is that people expect the DAs at least once, and ordered delivery. People expect to do this thru policy assertions. Chris has a proposal which may meet these concerns. It does not affect the protocol directly. Action: Jacques and Chris F will work toward a proposal to
resolve PR 35 and 9 for Jan 4 call. 5
Any other business
Meeting adjourned at 5:35 PM Eastern Time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]