[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 1/25 Teleconf
Prelim minutes attached. Please provide corrections to list before next monday morning., Tom Rutt -- ---------------------------------------------------- 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 1/25/2007
Prelim Minutes of OASIS WS-RX Teleconference Jan 25, 2007
Start Time:4:00 PM Eastern Daylight Time
Paul F 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 Dial in: (Thanks to Microsoft) (866) 500-6738 or (203) 480-8000 PC: 2365501 IRC/Q Mgmt(thanks
to DougD): http://webconf.soaphub.org/conf/room/wsrx 1) Roll Call 2) Review and approval of the
agenda 3) Approval of the Jan 18, 2007
meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21894/2007-01-18.html reposted
with attendance list as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21917/MinutesWSRX-011807.htm 4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 5) New issues 6) Timetable 7) Discussion of PR Issues a> PR035 Delivery Assurance http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 b> PR009 "Duplicate
Elimination" and "Message Ordering" http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 c> PR020 Message ordering and
duplication http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 d> PR037 Policy Assertions Must
be Independent http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i038 e> PR038 Need to clarify
relationship between the WS-RM specification and MakeConnection
specification http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00064.html 8) Any other business Bob asked to add a new item on addressing, after item number 6. 3 Approval of the 1/18 Minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21917/MinutesWSRX-011807.htm Tom moved to approve 1/18 minutes, Doug D seconded.
§ No objections, minutes of 1/18 approved. 4 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0124:
Chris F will present a proposal on policy assertions for WSRM Delivery
assurances. Owner:
Christopher Ferris Status:
Still Open Assigned:
2007-01-16 Due:
--- #0125:
Matt to provide a final wordsmithed proposal for PR
0035. Owner:
Matt Lovett Status:
Done Assigned:
2007-01-16 Due:
--- #0127:
Doug to define WS-Policy assertion for MC so that a service can advertise that
it supports MC Owner:
Doug Davis Status:
Done Assigned:
2007-01-22 Due:
--- #0128:
Doug to propose specific text to relax restriction on MS anon URI template Owner:
Doug Davis Status:
Done Assigned:
2007-01-22 Due:
--- #0129:
Gil to propose specific wording around PR0038 issue Owner:
Gilbert Pilz Status:
Done Assigned:
2007-01-22 Due: --- 5 New IssuesDoug had new issue: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00088.html Title: Scope of CS/Offer/Endpoint Description: Current RM spec defines
CS/Offer/Endpoint as: /wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint An RM Source MUST include this
element, of type wsa:EndpointReferenceType
(as specified byWS-Addressing). This element
specifies the endpoint reference to which Sequence Lifecycle Messages,Sequence Traffic
Messages, Acknowledgement Requests, and fault messages related to the offeredSequence are to be sent. Implementations MUST NOT use an
endpoint reference in the Endpoint element that would prevent the sending of
Sequence Lifecycle Message, Sequence Traffic Message, etc. For example, using
the WS-Addressing "http://www.w3.org/2005/08/addressing/none" IRI
would make it impossible for the RM Destination to ever send Sequence Lifecycle
Messages (e.g. TerminateSequence) to the RM Source
for the Offered Sequence. Implementations MAY use the WS-MakeConnection
anonymous URI template and doing so implies that messages will be retrieved
using a mechanism such as the MakeConnection message. The inclusion of the "Sequence
Traffic Messages" actually isn't correct.
Sequence Traffic Message (ie. app messages) go
to other EPRs, like wsa:ReplyTo - just like RM was even being used. CS/Offer/Endpoint is supposed to be for RM
protocol messages (Close, Terminate, AckReq...). I think when we switched over to the new RM
terms we got a bit too excited :-)
The old text used to say: ...This element specifies the
endpoint reference to which WS-RM protocol messages related to the offered Sequence
are to be sent. Proposal: Remove "Sequence Traffic
Message" from the current definition of CS/Offer/Endpoint. It appears in 2 spots. thanks -Doug Paul F: is there anyone opposed to this proposal. Doug D moved to accept new issue and close by accepting proposal, Gil Seconcded. No objection, new issue accepted and closed by accepting proposal. 6 TimetablePaul F: we need to agree to dates, if issues are not closed at this meeting. Paul F: when can editors get a next draft CS Doug D: a day or two after the issues are resolved. We assume tables regarding changes something we can update later. Paul F: after that we need to commit to review the document thouroughly. We should have a short amount of time for this review for CS vote. Is one week enough, or do we need 1.5 weeks. Doug D: if the editors get it done by Friday, we can do it by the next meeting. If posted on Monday, we need to have it be another week. Paul C: why do we have to wait to batch together all changes? If we can clearly identify which issues are resolved why cannot we endorse the editor’s draft at that stage of issue resolution. Discussion on total CD diff vs last ed Diff. Paul F: ask editors to have a draft incorporating all agreed changes by today by Friday this week. We can vote this as a CD for next week. Martin: we also need a diff of this next CD against the last public review draft to be produced. Tom: editors can use tools to generate a diff, even if the result is rather ugly. They can also post the clean version. 7 AddressingBob F: addressing will have another last call review on the WSDL document, which is now called the metadata document. Can this TC review this new document?. Doug D: A week after receiving this note should be enough. Bob F: I am looking for feedback within the next four weeks, as to the applicability of the new spec to this wsrm TC. Paul F: agreed to consolidate comments from WG. We can have a meeting to send the comment in after we receive them from members. Bob F: I will post the document as of the 30th of this month. I need the statement by the 20th of February. Tom: they changed the policy for anonymous and non anonymous reply to. This should be reviewed by this TC. 8 Discussion of PR Issues8.1
a> PR035 Delivery Assurance
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 Matt email: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00098.html Hi
all, Following
on from the discussion about using "deliver" rather than "process to conclusion", here are some definitions that
Peter and I have worked on. We believe these definitions help define the
end-to-end DA, as they include the RMS behaviour. -- wsrmp:DeliveryAssurance When
applied to an RM Destination, this element defines a policy assertion that identifies a requirement on RM Sources. Any RM Source
that transmits messages to this RM Destination SHOULD conform to the
requirement expressed by this assertion. Conversely, when it is applied
to an RM Source
this assertion identifies a requirement on RM Destinations. Any RM Destination
that receives messages from this RM Source SHOULD conform to the requirement expressed by this assertion. wsrmp:AtLeastOnce Each
message is to be delivered at least once. The requirement on an RM Source
is that it SHOULD retry transmission of every message sent by the Application
Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that
it SHOULD retry delivery to the Application Destination of every message
that it accepts from the RM Source. There is no requirement for the RM
Destination to apply duplicate message filtering. wsrmp:AtMostOnce Each
message is to be delivered at most once. The RM Source MAY retry transmission of unacknowledged messages, but is NOT REQUIRED
to do so. The requirement on the RM Destination is that it MUST filter out
duplicate messages, i.e. that it MUST NOT redeliver any message. wsrmp:ExactlyOnce Each
message is to be delivered exactly once. The requirement on an RM Source
is that it SHOULD retry transmission of every message sent by the Application
Source until it receives an acknowledgement from the RM Destination. The requirement on the RM Destination is that
it MUST filter out duplicate messages, i.e. that it MUST NOT redeliver any
message. -- Some
additional comments: Doug
pointed out that we talk about the RMS and RMD here, but that the wsrmp spec doesn't quite call out
where the RMS and RMD are. For example, if a WSDL output message is decorated with the RM assertion
+ a DA, we would expect the server-side RMS to exist and do it's part,
and similarly the client side RMD has a role to play. I think that this is
a separate issue, and needs a bit of discussion, but the text for the
DAs should be ok however we resolve that. Jacques:
I hoped to get this out to you earlier so you could see our thought process, but I'm running out of time before the
call. I'm sorry that time got away from me! Thanks Matt Matt: this version uses the word deliver. This might require tweaking the definition of deliver in the spec. Matt: we should find space for these defs in the main spec, then reference them from the policy document. Jacques: Three reasons to move defs to core spec. (can be referred to by RM-policy spec) 1) what people look at first , they expect DA assurances 2) already mention of DA in section 2 of core spec, reader might require more formal mention in core. 3) to understand DA definitions need to understand messaging model, in section 2. Deliver has special meaning in section 2 of core spec. Tom: what about the def of ordered deliver, and the new def of Deliver off of the email list. They seemed agreed. Jacques: I send out a new def for ordered delivery. We also have to redefine delivery as proposed by Chris. Chris Note for delivery def: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00101.html I
think I am +1'ing Stefan's comments. The
problem, frankly, is with the definition and use of "deliver" in the
context of these definitons: Deliver: The act of transferring a
message from the RM Destination to the Application Destination. If
I have an RMD and AD that are using transactions to exchange messages, then
there may in fact be many "deliveries" of the message frm the RMD to the AD until one of them finally commits. Possibly,
if we changed the definition of "deliver" to be: Deliver: The act of transferring
responsibility for a message from the RM Destination to the Application
Destination. Then
these definitions would not be as problematic. the reason that I tried to avoid the use of the word deliver
in my definition of delivery assurance was to avoid this very problem. Cheers, Christopher Ferris Jacques Def of ordered delivery: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00103.html Proposing
for InOrder delivery assurance, in same style as
previous ones: Messages
from a same sequence are to be delivered in the same order they have been sent
by the Application Source. The requirement on an RM Source is that it MUST
annotate messages so that the order in which they have
been sent from the Application Source, is manifest in the message. The requirement on the RM Destination is that
it MUST deliver received messages for this sequence in the order indicated by
the annotation mechanism - e.g. sequence numbers. The RM Destination MAY decide
to delay delivery of, or to not deliver messages that would violate these
requirements. Jacques Also Jacques has extra proposed changes: http://www.oasis-open.org/archives/ws-rx/200701/msg00102.html I
am much more comfortable with these defs and - given
minor tweaking started by
Stefan - I feel I can explain them to my reviewers. I
also believe we need to modify the Deliver definition as Chris suggested. See
below in line, proposed edits following up on Stefan remarks. Jacques -----Original
Message----- From:
Stefan Batres [mailto:stefanba@microsoft.com] Sent:
Thursday, January 25, 2007 9:46 AM To:
Matthew Lovett; ws-rx@lists.oasis-open.org Cc:
Durand, Jacques R. Subject:
RE: [ws-rx] PR035, PR009, PR020:
DA defs Matt, Thanks
for putting this together. I've inlined a couple of
comments. --Stefan -----Original
Message----- From:
Matthew Lovett [mailto:MLOVETT@uk.ibm.com] Sent:
Thursday, January 25, 2007 5:36 AM To:
ws-rx@lists.oasis-open.org Cc:
Durand, Jacques R. Subject:
Re: [ws-rx] PR035, PR009, PR020:
DA defs Hi
all, Following
on from the discussion about using "deliver" rather than
"process to conclusion", here are some definitions that Peter and I
have worked on. We believe these definitions help define the end-to-end DA, as
they include the RMS behaviour. -- wsrmp:DeliveryAssurance When
applied to an RM Destination, this element defines a policy assertion that
identifies a requirement on RM Sources. Any RM Source that transmits messages
to this RM Destination SHOULD conform to the
requirement expressed by this assertion. Conversely, when it is applied to an
RM Source this assertion identifies a requirement on RM Destinations. Any RM
Destination that receives messages from this RM Source SHOULD conform to the requirement expressed by this assertion. wsrmp:AtLeastOnce Each
message is to be delivered at least once. The requirement on an RM Source is
that it SHOULD retry transmission of every message sent by the Application
Source until it receives an acknowledgement from the RM Destination. The
requirement on the RM Destination is that it SHOULD retry delivery to the
Application Destination of every message that it accepts from the RM Source.
There is no requirement for the RM Destination to apply duplicate message
filtering. [SB]
I think there should be a requirement to indicate an error if the assurance
can't be met. <JD> Indeed. I believe the duty to notify error
(whatever that means) is part of the DA, not something to do if DA is not met
(DA MUST always be met !) We can do
: "Each
message is to be delivered at least once, or else a "delivery error"
MUST be made available to either Application Source or Application Destination.
The requirement on an RM Source is that it SHOULD retry transmission of every
message sent by the Application Source until it receives an acknowledgement
from the RM Destination. The requirement on the RM Destination is that it
SHOULD retry delivery to the Application Destination of every message that it
accepts from the RM Source, in case of unsuccessful delivery. There is no
requirement for the RM Destination to apply duplicate message filtering." wsrmp:AtMostOnce Each
message is to be delivered at most once. The RM Source MAY retry transmission
of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on
the RM Destination is that it MUST filter out duplicate messages, i.e. that it
MUST NOT redeliver any message. [SB]
I find "that is MUST NOT redeliver any message" confusing. The
requirement is to filter out duplicates that arrive on the wire. But we can't
forbid redelivery of a message that arrived only once or for which duplicates
have been eliminated. e.g. RMD delivers message to AD in the context of a local
atomic transaction that gets rolled back, this text seems to say that the
message should not be redelivered. <JD>
Right - but the roll-back/retry case can be taken care of by a better
def of "Deliver" (see previous
mail). So I think Stefan means: "Each
message is to be delivered at most once. The RM Source MAY retry transmission
of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on
the RM Destination is that it MUST filter out duplicate messages, i.e. that it
MUST NOT deliver a duplicate of a message that has already been
delivered." (NOTE
that this DA does NOT allow an RMD to let a duplicate slip out and get by with
raising an error...) wsrmp:ExactlyOnce Each
message is to be delivered exactly once. The requirement on an RM Source is
that it SHOULD retry transmission of every message sent by the Application
Source until it receives an acknowledgement from the RM Destination. The
requirement on the RM Destination is that it MUST filter out duplicate
messages, i.e. that it MUST NOT redeliver any message. [SB]
Same comments apply. -- <JD>
merging the hard part of each updated DA above: "Each
message is to be delivered at least once, or else a "delivery error"
MUST be made available to either Application Source or Application Destination.
A message also MUST NOT be delivered more than once.
The requirement on an RM Source is that it SHOULD retry transmission of every
message sent by the Application Source until it receives an acknowledgement
from the RM Destination. The requirement on the RM Destination is that it
SHOULD retry delivery to the Application Destination of every message that it
accepts from the RM Source in case of unsuccessful delivery, and that it MUST
NOT deliver a duplicate of a message that has already been delivered." Some
additional comments: Doug
pointed out that we talk about the RMS and RMD here, but that the wsrmp spec doesn't quite call out where the RMS and RMD
are. For example, if a WSDL output message is decorated with the RM assertion +
a DA, we would expect the server-side RMS to exist and do it's
part, and similarly the client side RMD has a role to play. I think that this
is a separate issue, and needs a bit of discussion, but the text for the DAs
should be ok however we resolve that. <JD>
I suggest that these DA defs be inserted in the core
spec: that is where users look first. They can be associated (referred to) with
policy assertions in WS RM Policy spec. It is better that RM Policy doc refers
to core RM spec, than the reverse. Jacques:
I hoped to get this out to you earlier so you could see our thought process,
but I'm running out of time before the call. I'm sorry that time got away from
me! Thanks Matt Peter N: I am not sure of what Jacques means by made available to application destination. What do you mean by delivery error to destination? Jacques: Faulure is after receipt Peter N: If it cannot deliver message, how can it delivery failure notification. Jacques: in extreme cases, such as shutdown, it might not be able to deliver failure notification. Peter N: that is going beyond what we should be talking about. Sanjay: We had agreed that RMS resends until acknowledged. Is there a change in that invariant. One of the DAs seems to relax this invariant (MAY decide to retry). Jacques: This means you might give up after some time doing the retransimission. It is fairly permissive. Sanjay: Giving up after some time makes sense, however without DAs the RMS MUST keep retrying. Now we are introducing that with at most once DA is that the giving up might occur sooner. Gil: I am confused about whether the RMD should not ack until delivery? No so Gil: from the application source perspective I gave message to rms, it sent fo RMD, and it gets the ack back. I do not see context for sending delivery error message back to app source for a message it might have dumped from its resend cache. Anish: this involves sequence failre. Gil: do you have to be prepared to receive faults for messages which have also been acked? Stefan: the error has to be raised somewhere, It does not need to be always sent to sender. The receiver might be enough to receive the fault. Doug D: I am concerned about the MUST, when there might not be someone to receive the error. Matt: the system log could receive the error. Paul F: I think we need to reword this, “a delivery error must be raised”, either by rms or rmd.” We do not need to state where it goes. Putting this text in the main spec is problematic. The text about stopping retransmission earlier belongs only in the policy spec. Jacques: How rms and rmd are made aware of da is outside scope of definition. Agree we can just state that RM layer raises a fault in this case. It must be available to the application in some way. Anish: I agree with need for error being raised. From model perspective, assure DA is met or at least one app is made aware of error. If we do not say that, the definition of DA is incomplete.. Peter: fault could be raised at either or both ends. Peter Niblett: How about "Each message is to
be delivered at least once, or else an error must be logged by RM Source and/or
RM Destination" ? Jacques: that is ok with me. SHOULD only applies if you cannot deliver for whatever reason. Paul F: I do not think we can incorporate these changes without some further wordsmithing. Action: Peter N will incorporate consensus from 1/25 meeting into next proposal for PR035. 8.2
b> PR009 "Duplicate Elimination" and
"Message Ordering"
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 skip 8.3
c> PR020 Message ordering and duplication
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 Skip 8.4
d> PR037 Policy Assertions Must be
Independent
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i038 Ashok posted: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00057.html Based
on our discussions last week in which we decided that it would be desirable to
remove the dependence of the RM policy assertions on one another, here is a
proposal that attempts to accomplish this. The
RM assertion comes in 3 different flavors: 1.
<wsrmp:RMAssertion [wsp:Optional="true"]? ... /> 2.
<wsrmp:RMAssertion [wsp:Optional="true"]? ... > <wsp:Policy> <wsrmp:SequenceSTR /> </wsp:Policy> </wsrmp:RMAssertion> 3.
<wsp:Policy> <wsp:ExactlyOne> <wsp:All>
<wsrm:RMAssertion
[wsp:Optional="true"]? ...> <wsp:Policy> <wsrmp:SequenceTransportSecurity /> <wsp:Policy> </wsrm:RMAssertion> <sp:TransportBinding
...> ... </sp:TransportBinding> </wsp:All> </wsp:ExactlyOne> </wsp:Policy> The
third form says that an endpoint may have RM as an option but always requires
HTTPS to be used. All the SequenceTransportSecurity
assertion indicates is that RM's rules for protecting
the sequence over TLS are followed. If
we agree on these 3 assertions, the text in sections 2.5.1 and 2.5.2 would need
to be changed to reflect assertion 2 and 3 above. See attached Word Document. All the best, Ashok Marc G: We need to ensure that in section 2.2 we add the nested assertions into the main exemplar. Also add wsp:policy element as required element within rm assertion to support nested policy expressions. Paul F: can the editors take care of this. Doug D: Is this required even if not using the inner assertion? Marc G: yes it is a standard policy thing Marc G: I move to accept Ashok proposal to close PR 037, seconded by Colleen. No objection PR 037 closed with Ashok proposal. 8.5
e> PR038 Need to clarify relationship between
the WS-RM specification and MakeConnection specification
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00064.html
Gill proposal: http://www.oasis-open.org/archives/ws-rx/200701/pdf00013.pdf /wsrm:CreateSequence/wsrm:Offer/wsrm:Endpoint An RM Source MUST include this element, of type wsa:EndpointReferenceType (as specified by WS-Addressing). This element specifies the endpoint reference to which
Sequence Lifecycle Messages, Sequence Traffic Messages, Acknowledgement Requests, and fault
messages related to the offered Sequence are to be sent. Implementations MUST NOT use an endpoint reference in the Endpoint
element that would prevent the sending of Sequence Lifecycle Message, Sequence Traffic Message,
etc. For example, using the WSAddressing "http://www.w3.org/2005/08/addressing/none" IRI would
make it impossible for the RM Destination to ever send Sequence Lifecycle Messages (e.g. TerminateSequence) to the RM Source for the Offered Sequence. Replace Implementations MAY use the WS-MakeConnection
anonymous URI template and doing so implies that messages will be retrieved using a mechanism
such as the MakeConnection message. with The Offer of an Endpoint containing the
"http://www.w3.org/2005/08/addressing/anonymous" IRI as its address is problematic due to the inability of a source to connect
to this address and retry unacknowledged messages (as described in Section 2.3). In the absence of
an extension that addresses this issue, an RM Destination MUST NOT accept (via the /wsrm:CreateSequenceResponse/wsrm:Accept
element described
below) an Offer that contains the "http://www.w3.org/2005/08/addressing/anonymous" IRI as
its address. Discussion ensued on methods to attain agreements. Marc G: can always refuse a create sequence or a make connection operation request. Not every scenario can be defined within the scope of the specification. The ws addressing has produced metadata to allow expression of anonymous or non anonymous. Gil: Base spec has a hole in it in my opinion. We are asking for interop problems. Anish: Marc, re WS-addressing changes, that functionality exists now as policy rather than wsdl assertion. Also I think this is general goodness. Perhaps with tweaked wording it can say “if you want to support this kind of thing the spec does not say how to do it (you can use make connection or your own mechanism). That would make it an extension. Nobody is stopping you from doing what you want to. Jacques: I am concerned with this wording. It disallows some possible usages. Tom: WS addressing new policy assertion “anonymous” means that the endpoint is willing to accept reply to with wsa: anonymous URI. No implication of any more general “anonymous” mechanism (such as wsrm:anonymous). We would need our own analogous policy assertion re wsrm:Anonymous. Marc G: I agree with Tom. Paul F: I have sympathy for Gil’s position. However I would suggest change “extension” to “mechanism”. Discussion on rewording. Ran out of time. Action: Gill will provide a new proposal for Pr038 by Monday. Anish: this regards our third invariant. 9 Any other businessMeeting ended at 5:30 PM eastern time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]