[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes 2/1 teleconf
Prelim minutes are attached for 2/1 teleconf. Please provide corrections to list before monday morning. -- ---------------------------------------------------- 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 2/1/2007
Prelim Minutes of OASIS WS-RX Teleconference Feb 1, 2007
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 Jan 25, 2007 meeting minutes Preliminary Minutes: http://lists.oasis-open.org/archives/ws-rx/200701/msg00105.html 4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 5) Approval of Latest Working Drafts. http://lists.oasis-open.org/archives/ws-rx/200701/msg00111.html 6) New issues 7) Discussion of PR Issues a> PR015 RMD polling http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i015 b> PR029 Opaqueness of URI identifiers not preserved by RM anon URI http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i029 c> PR035 Delivery Assurance http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 d> PR009 "Duplicate Elimination" and "Message Ordering" http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 e> PR020 Message ordering and duplication http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 f> PR038 Need to clarify relationship between the WS-RM specification and MakeConnection specification http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i038 8) Any other business Marc G suggested we move DA issues and issus 38 to top of list. Agreed to move 15 and 29 to the end. 3 Approval of the 1/25 Minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21917/MinutesWSRX-011807.htm Tom moved to approve 1/25 minutes, Doug D seconded.
§ No objections, minutes of 1/25 approved. 4 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 124 closed 130 closed 131 closed 5 Approval of Latest Working Drafts.http://lists.oasis-open.org/archives/ws-rx/200701/msg00111.html Sanjay: By approving this WG we are moving closed issues to pending status. Marc G: all the closed issues, except for those in the agenda for this meeting, are applied. Sanjay: the WG incorporate all issues pending, and 23, 37, and 39. Marc G moved to accept WG and move incorporated issues to closed, Doug D seconded. No objection, WGs approved and issues incorporated to be marked as closed. 6 New Issuesnone 7 Discussion of PR Issues7.1 c> PR035 Delivery Assurancehttp://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 Peter proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200702/msg00000.html Deliver definition Deliver: The act of transferring responsibility for a message from
the RM Destination to the Application Destination. Added 2.4 2.4 Delivery Assurances This section defines a number of Delivery Assurance assertions,
which can be supported by RM Sources and RM Destinations. These assertions can be
specified as policy assertions using the WS-Policy framework [WS-Policy]. For
details on this see the WSRM Policy specification [WS-RM Policy] AtLeastOnce Each message is to be delivered at least once, or else an error
MUST be raised by the RM Source and/or RM 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 the transfer to the Application Destination
of any message that it accepts from the RM Source, until that message has been
successfully delivered. There is no requirement for the RM Destination to apply duplicate message
filtering. 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 deliver a duplicate of a message that has already been
delivered. ExactlyOnce Each message is to be delivered exactly once; if a message
cannot be delivered then an error MUST be raised by the RM Source and/or RM 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 the
transfer to the Application Destination of any message that it accepts from the
RM Source until that message has been successfully delivered, and that it MUST NOT
deliver a duplicate of a message that has already been delivered. InOrder Messages from each individual 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 ensure that the ordinal position of each message in the sequence
(as indicated by a message sequence number) is consistent with the order in which
the messages have been sent from the Application Source. The requirement on the RM
Destination is that it MUST deliver received messages for each sequence in the order
indicated by the message numbering. This DeliveryAssurance
can be used in combination with any of the AtLeastOnce, AtMostOnce or ExactlyOnce
assertions, and the requirements of those assertions MUST also be met. In particular if the AtLeastOnce or ExactlyOnce
assertion applies and the RM Destination detects a gap in the sequence
then the RM Destination MUST NOT deliver any subsequent messages from that sequence
until the missing messages are received or until the sequence is closed. Policy addition: <wsrmp:DeliveryAssurance> <wsp:Policy> [ <wsrmp:ExactlyOnce/> | <wsrmp:AtLeastOnce/> | <wsrmp:AtMostOnce> ] <wsrmp:InOrder/> ? </wsp:Policy> </wsrmp:DeliveryAssurance> ? /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance This expression, which may be omitted, describes the message
delivery quality of service between the RM and application layer. When used by an RM
Destination it expresses the delivery assurance in effect between the RM
Destination and its corresponding application destination, and it also indicates
requirements on any RM Source that transmits messages to this RM destination.
Conversely when used by an RM Source it expresses the delivery assurance in effect
between the RM Source and its corresponding application source, as well as
indicating requirements on any RM Destination that receives messages from
this RM Source. In either case the delivery assurance does not affect the
messages transmitted on the wire. Absence of this expression from a wsrmp:RMAssertion
policy assertion simply means that the endpoint has chosen not to
advertise its delivery assurance characteristics. /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy This required element identifies additional requirements for the
use of the wsrmp:DeliveryAssurance. /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/ wsrmp:ExactlyOnce This expresses the ExactlyOnce
Delivery Assurance defined in [WS-RM]. /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/ wsrmp:AtLeastOnce This expresses the AtLeastOnce
Delivery Assurance defined in [WS-RM]. /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/ wsrmp:AtMostOnce This expresses the AtMostOnce Delivery
Assurance defined in [WS-RM]. /wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/ wsrmp:InOrder This expresses the InOrder Delivery
Assurance defined in [WS-RM]. Jacques suggestions: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200702/msg00002.html Peter:
By saying now (for
composition AtLeastOnce+InOrder): " the RM Destination MUST NOT deliver any subsequent
messages from that sequence until the missing messages are received or until
the sequence is closed." You are ruling out the following scenario: - I am interested in having the RM layer do its best to
transmit and deliver and tell me when it could not (error raised). So that's AtLeastOnce. But in addition I am also interested in having
the messages that are delivered, to be delivered in order - even if
there are gaps (e.g. the sender is monitoring quantitative indicators, and
periodically sending report messages but it is OK to loose a few messages
- as few as possible though - but the ordering is critical to reflect
accurately the "trends"). I would keep InOrder+AtLeastOnce
open enough by replacing your MUST NOT by SHOULD NOT above. Every flavor of ordered delivery
can then be controlled with additional parameters such as our IncompleteSequenceBehavior (when its value is "DiscardFollowingFirstGap” that would achieve your current definition) Minor edit, to catch-up with the new definition
of "Deliver" Thanks, Jacques There was discussion on Jacques proposed changes. Jacques: In order does not disallow gaps. In some cases it might not have to wait forever for missing message in sequence. We do not need to bring all flavors in general definition, however it should be able to be refined with further parameters, such as incompleteSequenceBehavour. Doug B moved to accept proposal to close issue 35 as worded by Peter Niblet, seconded by Doug D. Jacques: I can accept these definitions, even though I would prefer a wordsmithing. Ashok: I have a concern about the agreed policy assertions for RM assertions from last week. These DA assertions are being added to the RM assertions. They need to be fit into the structure for RM assertions. Marc G: The editors can resolve any such difficulties. No objection, issue 35 resolved with Peter Niblett proposal. Sanjay: Ashok can post any concerns on the agreed text on the mailing list. 7.2 Close related issuesd> PR009 "Duplicate Elimination" and "Message Ordering" http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 e> PR020 Message ordering and duplication http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 Marc G moved to close issues 9 and 20 as duplicates of issue 35, seconded by Jacqeus. No objection, issues 9 and 20 closed as duplicates of issue 35. 7.3 f> PR038Need to clarify relationship between the WS-RM specification and MakeConnection specification http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i038 email from Gil: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00115.html changes to lines 384 to 395: Implementations
MUST NOT use an endpoint reference in the Endpoint element that would prevent
the sending of Sequence Lifecycle 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.
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). When offering
a Sequence with such an IRI, an endpoint MUST ensure that it will provide the protocol back-channel
opportunities necessary to carry Sequence Traffic Messages for the offered Sequence, as well as any
Sequence Lifecycle Messages and/or Acknowledgement Requests that the anonymous RM Destination
expects to receive for this Sequence. In the absence of sufficient assurance that the endpoint
offering the sequence will provide these opportunities, 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. Anish: I am concerned that the mention of extension is taken away. Anish: you will not see issues until reliability problems occur. I would like to call out that we need to call out that if you do not have an agreed upon way of assuring a way to resend these messages, reliability will not occur. Jacques: I do not think we need an explicit reference to Make connection in the core spec. If there is a way to use the RM layer you are fine. Anish: I do not say we have to point to MC spec, but there are several ways to skin this cat (including resending a request with the response piggybacked). That is what is meant by extensibility. This spec does not say how it is done, and if you used this scenario you must make sure the appropriate mechanisms are in place. Gil: add one sentence “the base spec does not define a mechanism for this” Anish: I would be happy with that solution. Paul F: Make connection has two variants one which does use the URI. Jacques: I am ok with adding such a sentence, but it is a tricky editorial point. Regardless of make connection you might decide to use rms and rmd in particular ways to make this happen. Gil: add following before sentence “In
the absence of sufficient assurance” “Note that this specification does
not define any mechanisms for providing this assurance” Gil moved to close issue 38 with his proposal and the additional sentence, Jacques seconded. No objection, issue 38 closed with Gil proposal along
with additional sentence “Note that this specification does not define any
mechanisms for providing this assurance” a> PR015 RMD polling http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i015 Doug D proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00092.html Proposes New text in section 3.4 of Make Connection Spec for separate policy assertion. Doug D moved to close issue 15, Charleton seconded No objection, issue 15 closed with Doug D proposal 7.4 b> PR029 Opaqueness of URI identifiers not preserved by RM anon URIhttp://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i029 Doug D proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00087.html Jonathan: I do not think this completely resolves the issue, but cannot complain too much. Paul F: at one time we thought of adding this as reference parameter for UUID. I still think this is a cleaner solution, but it does not matter that much to me. Doug D: give resolution of CR33 in WS-addressing, this is an acceptable solution. Anish: the problem is with epr comparison when they include ref parms. Paul F: we would define our own ref parm for UUID, what is problem with other ref parms in epr? This UUID uniquely identifies who the destination of the anonymous URI is. Chris F: an EPR is not an identifier. We cannot use it as an identifier. Anish: in answer to Paul, we have to identify who the sender is. If the ref parm is necessary to identify the sender, we can have two eprs with same value of our ref parm, but have additional ref parms. Are these significant in the comparison of EPR for identity. Paul F: server not allowed to look at ref parm was a reason used in the past. However, the WS addressing proposed one use of ref parms to resolve our problem. I thing it is a neater option to solve our problems. Doug D: we have gone thru these discussions many times. If Paul wants to make his point, he can raise new issue Doug D moved to resolve issue 29 with his proposal, seconded by Gil. Tom: I speak in favor of the motion, since we are putting this into the ReplyTo header we should not rely on special epr comparison rules. If we were defining our own header, with an epr value type, we might be able to get away with a special comparison rule, using our ref par. But this is for use in replyTo. Gil: I also speak in favor. Jonathan: we could decide to change the syntax to text however. No objection to resolve issue 29 with Doug D proposal. 8 Any other businessSanjay: we can now produce a CD05 candidate for all three documents, and decide at some meeting if it has substantial changes. We can vote on this document’s progress in the next few meetings. If substantial changes are voted, we need to have a second public review. Paul C: as a result of moving make connection to another spec, we have changed schema. Do we have to change the namespace URI. We need to discuss this as an explicit decision. Doug D: I did update the namespace on everything, because it was required in my opinion. Paul C: a namespace change might affect some members decision on significant change. Tom R: Some members might think a small schema change is not a significant. We have taken away items so we need to change namespace. Paul C moved to change namespace identifier in the documents, to the current date, seconded by Doug D. No objection, namespace to be changed in next CD document for all three specs.. Bob F: ws addressing wishes a review of the metadata document by the members of this group. Meeting ended at 5:25 PM eastern time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]