[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 1/14 teleconf
Prelim minutes of 1/14 teleconf attached. Please provide corrections before 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/11/2007
Prelim Minutes of OASIS WS-RX Teleconference Jan 11, 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 1) Roll Call 2) Review and approval of the
agenda 3) Approval of the Jan 4th, 2006
meeting minutes 4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 5) New Issues 6) WS-Policy feedback 7) Issue progress review 8) Discussion of PR Issues PR021 Piggy-backing problematic http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i021 PR022 RMD cannot detect some
incomplete Sequences http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022 PR007 RM Destination lacks a
mechanism for cleanly terminating inbound sequences http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007 PR035 Delivery Assurance http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 PR009 "Duplicate
Elimination" and "Message Ordering" http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 PR020 Message ordering and
duplication http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 PR027 Where do Sequence Faults go
when the RMS is anonymous http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i027 9) Any other business 1 Approval of the 1/4 Minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21779/MinutesWSRX-010407.htm Tom moved to approve 1/4 minutes, Chris F seconded.
§ No objections, minutes of 1/4 approved. 2 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0117: Marc G will sort out with Chairs and editors on
apportioning existing issue against the core spec and the new Make Connection
spec Owner: Marc Goodner Status: Open – Marc will add new make connection spec to
list of target specs, and reassign issues accordingly. Assigned: 2007-01-03 Due: --- #0119: Ashok to prepare draft
feedback to policy working group, on need to be careful to avoid dependency
related problems Owner: Ashok Malhotra Status: Closed Assigned: 2007-01-11 Due: --- #0120: Ashok to raise new issue
about nesting policy assertions for RM Owner: Ashok Malhotra Status: Closed Assigned: 2007-01-11 Due: --- #0121: Gill will provide concrete language around item 2 in
his proposal for issue 21. Owner: Gilbert Pilz Status: Closed Assigned: 2007-01-11 Due: --- #0122: Gill will provide concrete language around item 2 in
his proposal for issue 21. Owner: Gilbert Pilz Status: Closed Assigned: 2007-01-11 Due: --- #0123: Gil to provide a concrete proposal to resolve issue
007 to include a finalAck in the closeSequence
and TerminateSequence message Owner: Gilbert Pilz Status: Closed Assigned: 2007-01-11 Due: --- 3
New Issues
Ashok Raised New Issue http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00019.html In
my original note (below) I pointed out that RM Policy had three assertions: 1.
<wsrmp:RMAssertion [wsp:Optional="true"]? ... > 2.
<wsrmp:SequenceSTR [wsp:Optional="true"]? ... /> 3.
<wsrmp:SequenceTransportSecurity
[wsp:Optional="true"]? ... /> Assertion
2 depends on assertion 1 and is invalid unless 1 is present. Assertion
3 depends on 1 and the presence of a sp:TransportBinding
assertion. Both must be present for
assertion 3 to be valid. These
dependencies lead to a problem with WS-Policy normalization if, say, you have a
policy containing only assertions 1 and 2 and both are marked 'optional'. Such a policy would normalize to 4 policy
alternatives { (1,2), (1), (2), () } One of the policy alternatives would contain
assertion 2 and not assertion 1 which is invalid. PROPOSAL: Make
assertions 2 and 3 possible nested elements of assertion 1. For
example: <wsrmp:RMAssertion [wsp:Optional="true"]? ... > <wsp:Policy> <wsrmp:SequenceSTR
[wsp:Optional="true"]? ... /> </wsp:Policy> </wsrmp:RMAssertion> (Only
either 2 or 3 must appear in the nested policy?) This
does not solve the problem of assertion 3 depending on sp:TransportBinding but, at least, solves part of the
problem. All the best, Ashok Accepted New Issue with Ashok as owner. 4
WS-Policy feedback
Ashok emai: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00025.html On
the 1/4 telcon I was given an action item to
suggested clarifying wording to the WS-Policy WG. This
clarification is motivated by the dependencies between the RM assertions as
discussed in my earlier notes. To
recap, there are three RM assertions: <wsrmp:RMAssertion [wsp:Optional="true"]? ... > <wsrmp:SequenceSTR [wsp:Optional="true"]? ... /> <wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... /> Assertion
2 depends on assertion 1 and is invalid unless 1 is present. Assertion
3 depends on 1 and the presence of a sp:TransportBinding
assertion. Both must be present for
assertion 3 to be valid. 1.
The WS-Policy Framework document says in section 3.1: "[Definition:
A policy assertion represents an individual requirement, capability, or other
property of a behavior.] The
word "individual" is not accurate.
If assertion
2 and assertion 1 are used the capability is defined by their combination. In
the security domain, several assertions may be needed to define a capability. Thus,
change the above sentence to something like "[Definition: A policy
assertion represents an requirement, capability, or
other property of a behavior that is defined, possibly, in combination with
other assertions in with assertion-specific semantics.] 2.
The Guidelines for Policy Assertions document discusses dependencies between
assertions in section 6. It
would be useful in this section to warn the assertion authors that dependencies
between assertions can create difficulties when policies are normalized. It may also be desirable to add an example of
a policy that contains two assertions whose validity depends on one
another. If both assertions are marked
'optional', then the two of the four policy alternatives which are generated will
contain only one of the two assertions and may be invalid. All the best, Ashok Chris F: we need a specific proposal to close the issue, with exact wording. This proposal is an outline of the solution. Paul F: from RX point of view we can move to make this feedback, and if we get more detailed feedback that is a bonus. Chris F: It is not clear that anything is broken. Paul F: the policy WG asked for feedback and this is our feedback Marc G: I do not agree with this feedback. There is an issue with the RM policy assertion, not with WS-Policy. We can fix it ourselves, with no changes required to policy itself. Regarding Guidelines feedback, we might do that, but only after closing the new issue. Chris F: the proposal for solution is on target, but we need to review in detail the entire solution. Then we have to take a closer look, do we really have multiple assertions that define a capability, or are there dependencies between capabilities. I agree that feedback to guidelines can come after we solve our problems. Anish: Issue with STR sequence assertion. Another problem is SequenceTransport Security, which has dependencies on transport security. The first issue does not require feedback, but the second issue should be sent to Policy WG. Paul F: Deadline for feedback is tomorrow. We have the issue work, and we have the feedback. Lets focus on what feedback we give Policy wg. Marc G: I would suggest feedback be sent by individuals if they feel it necessary. Cross dependency in our sequenceTransport Security could also be a problem in our spec. The wording could be improved, it does not have to be worded as a dependency. Details are in the transport assertions. Chris F: the feedback we can give is on guidelines and primer docs. We will have contributions soon on this. However, have we identified any problems with their policy framework. Paul F; I cannot see consensus for a WG response out of this meeting. Ashok can submit on his own behalf, but we will wait for resolving the new issue before sending feedback to ws- policy group. No disagreement. Action: Chris F will present a proposal on policy
assertions for WSRM Delivery assurances. 5
Issue progress review
Marc updated the issues list. Paul F: more work is needed on Issue List. We need concrete proposals for issues open. We have concrete proposals for all except the policy assertions on DAs. We have two proposals. Chris F: I am almost done with a proposal which I will send soon. Action: Chris F will present a proposal on policy
assertions for WSRM Delivery assurances. 6
Discussion of PR Issues
6.1
PR021 Piggy-backing problematic
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i021
Gill: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/pdf00005.pdf
Text regarding changes to 3.2 (regardings use of MAYs) from email are not yet included in the propoal I posted. We could add these. Chris F: My problems were in 3.8 and 3.9. regarding change of MAYs to CANs http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00035.html Doug D moved to accept Gil;s proposal with modifications for 3.8 and 3.8 suggested by Chris F (and with editors to also fix wording of 3.2, seconded by Gil. No Objections: Issue 21 Closed with agreed resolution. 6.2
PR022 RMD cannot detect some incomplete
Sequences
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022
Gil proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/pdf00009.pdf Gil: change wording that unless there is a good reason you add last message number to terminate or close sequence messages. Gil: there is an outstanding issue from Jacques, where discard is required, Should should be MUST. I disagree with this amendment. The Definition of SHOULD includes what Jacques is concerned about. Tom: this proposal resolves my concerns. Matt: the diagram might need minor editing to agree with text. Gill: I agree. Marc: there were a couple of other editoral nits, to leave to editors. I will send notes. Doug D: I sent a note to list. Message 42 on list Gill: I agree with these proposed edits. Matt moved to accept proposal from Gil to resolve PR022 , seconded by Doug D. No Objection, PR022 Closed with proposed change from Gil. 6.3
PR007 RM Destination lacks a mechanism for
cleanly terminating inbound sequences
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007
Gill proposal for 7: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/pdf00011.pdf Gil: there has been discussion on the Email list. We have come to agreement on state tables, which is reflected in this draft. There is a minor edit needed to fix the state table. Marc G: this seems good from my point of view. Agree that we Need additional column for state table for RMS. MrGoodner: responding party/receiving party throughout should be
sender/receiver instead Discussion of the details of state table changes ensued. Matt: Introduced a terminating state to RMD. It does put requirement to RMD to support this new state. Doug D:that’s fine Gil moved to accept proposal for PR007 with Matt’s state table changes and Marc G wording changes, seconded by Marc G. No objections, PR006 closed by accepting proposal for changes. 6.4
PR035 Delivery Assurance
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035 We can discuss Definitions from Jacques: Jacques original Note:: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00026.html Rationale
for a rewording of DA definitions that were used a year ago: AtLeastOnce Previous: -
Every message sent will be delivered or an error will be raised on at least one
endpoint. Some messages may be delivered more than once. Proposed: for every sent message, either the RMD has received the
message and successfully delivered it, or at least one of the AS or the AD is
made aware of a delivery failure. Note: There is no guarantee that if
delivered, the message is delivered just once. Also it may happen that both
delivery and failure notification occur for a message. [comment: pretty much same. Just relate it better to the
messaging model: re-emphasizes that " deliver" must be understood with the precise meaning
given in glossary, i.e. as delivery to
AD, not in its general sense. Same for errors raised.
Also mention that cases where message is delivered yet an error is raised, are
not ruled out - cannot be always prevented.] AtMostOnce Previous: Messages
will be delivered at most once without duplication or an error will be raised
on at least one endpoint. It is possible that some messages in a sequence may
not be delivered. Proposed: A
message shall not be delivered more than once by the RMD. Message duplicates
are identified based on Sequence ID and Sequence number. Note: there is no
guarantee that the message is delivered or that an error is raised if not. [comment:
the previous definition is not crisp enough - users expect more than to tolerate
accidental duplicate deliveries provided they have been flagged (why not just
prevent the delivery of duplicate if you can notify about it, which assumes you
can detect them in the first place?) In any case, I believe the protocol has
the ability to enable this stronger definition, which also defines duplicates] ExactlyOnce (can be added although just a combination of
other DAs) Previous: Every
message sent will be delivered without duplication or an error will be raised
on at least one endpoint. This delivery assurance is the logical
"and" of the two prior delivery assurances. Proposed:
This DA is equivalent to the combination of AtLeastOnceDelivery
and AtMostOnceDelivery DAs (i.e. combining their
requirements). [comment: previous no longer adequate with a new, tighter
definition of AtMostOnce. Prefer to just say that
this is a logical combination of two prior DAs. Also, do we really need this DA
if we can combine DAs?] InOrder Previous: Messages
will be delivered in the order that they were sent. This delivery assurance may
be combined with any of the above delivery assurances. It requires that the
messages within a Sequence will be delivered in an order so that the message
numbers are monotonically increasing. Note that this assurance says nothing
about duplications or omissions. Note also that it is only applicable to
messages in the same Sequence. Cross Sequence ordering of messages is not in
the scope of this specification. Proposed:
When delivering messages from a same sequence, an RMD does so in the same order
they have been sent by the application source (AS) to the RMS. This only means
a message will not be delivered if another message sent after it has already
been delivered. Note: The ordering concerns only messages from the same sequence
- not across sequences. Additional delivery constraints are not precluded by
this delivery assurance - e.g. to not deliver a message if a previous one is
still missing. [comment: reworded in order to be explicit that "send" must be understood as in glossary: passing a message from AS to RMS, not in its general sense. Also previous wording seems to imply that " messages will be delivered" is a guarantee, in first sentence, which may be confusing even if denied subsequently. Also avoiding references to "message numbers" in a general DA def. That already assumes a specific protocol (how are these numbers assigned, etc.) which is introduced only later in the spec.] Chris F comments; http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00036.html Jacques, Actually,
I think that the definitions you have suggested are not quite right. It is
important IMO
that the defnitions not prescribe the behavior of the
RMD, but rather describe the outcome as perceived external to the RMD/AD processing. My
reasoning is that we don't want to be specifying the implementation of the RMD. To
say that the RMD can only "deliver" the message to the AD once would
need a formal definiton of "deliver".
Does that mean that it will only ATTEMPT delivery to the AD once? What of that fails? What if there is transactionality
between the RMD and AD such that a failed processing of the message results in a rollback? Would a retry be in
violation of the expressed DA since the message is delivered more than once? I
think that the definitions should read something along the following lines: AtLeastOnce - describes a delivery assurance characteristic
of the processing of the messages within an RM Sequence received by the ultimate receiver such
that the each message in the Sequence, received by the RMD, is processed to conclusion at least
once. This means that a given message in the Sequence
that was
received and acknowledged by the RMD MAY be processed to conclusion more than once. It also means that duplicate filtering SHOULD NOT be
applied by the ultimate receiver. AtMostOnce - describes a delivery assurance characteristic
of the processing of the messages within an RM Sequence such that the messages within the
Sequence received by the ultimate receiver are processed to conclusion at most once. This
means that a given message(s) within the Sequence that was received and acknowledged by the RMD
might not be processed to conclusion. It
also means that
a given message within the Sequence MUST NOT be processed to conclusion more than once (ie.
duplicate filtering MUST be applied by the ultimate receiver). ExactlyOnce - describes a delivery assurance characteristic
of the processing of the messages within a Sequence such that each message within an RM
Sequence received by the ultimate receiver MUST
be processed to conclusion exactly once (ie,
duplicate filtering MUST be applied). It
also means that the receiving endpoint SHOULD make every effort to ensure that
each message within the Sequence received by the RMD will be processed to
conclusion. Cheers, Christopher Ferris Chris F: Jacques has definition for In order. This can be combined with others. Tom: I am happy about the wording of In order. Paul F: is this ready. Chris F: Matt Lovett wants to take a shot at clearing up the wording. Jacques sent a note on follow up, which we are still discussing regarding receipt and responsibilities. He notes my definitions do not use the word delivery. I would like to keep the details of delivery between RMD and AD. These contracts can vary (e.g., duplicate elimination might be in application), however the RMD must always ack. Action: Matt to provide a wordsmithed proposal for PR 0035. Anish: one difference in two proposals regard the fault case. These definitions are for the non fault case. When they are not met, faults can ocurr. These guaranteed either hold of the implementation will fault. Paul F: are there any other things we can talk about regarding the Policy assertions for DA. Chris F: my proposal for Policy DA assertions uses nested assertions. Is anyone concerned? No one objected in principal. Chris F: I think Ignorable would be better for these assertions. Tom: I think ignorable is acceptable for the DA policy assertions because the client protocol is invariant to their being in affect. This is different in the case of WS-Reliability, since the sender does not need to resend unless guaranteed delivery is in afecct. In WS-RM the sender always resends, and the receiver always acks. Chair F: this is my thinking chris: <wsrmp:DeliveryAssurance
...>
<wsp:policy> <wsp:All> [<wsrmp:ExactlyOnce/>|<wsrmp:AtLeastOnce/>|<wsrmp:AtMostOnce>] <wsrmp:InOrder/>? </wsp:All>
</wsp:policy> </wsrmp:DeliveryAssurance> Discussion on need for InOrder as its own nested assertion. Marc G: why do we need extra wrapper, deliveryAssurance. Discussion on nested policy, policy intersection, and use of ignorable. Agreed to have email discussion based on Chris F proposal after he posts it. 6.5
PR009 "Duplicate Elimination" and
"Message Ordering"
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009
defer 6.6
PR020 Message ordering and duplication
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020
defer 6.7
PR027 Where do Sequence
Faults go when the RMS is anonymous
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i027
Latest Email: http://www.oasis-open.org/archives/ws-rx/200701/msg00044.html I
agree. Re-reading
my proposal, I think this whole issue is CNA against the main spec, and therefore should be retargeted to the MC spec. Paul Gilbert
Pilz wrote: >
One comment in line . . . >
>>
-----Original Message----- >>
From: Paul Fremantle [mailto:paul@wso2.com] >>
Sent: Thursday, January 04, 2007 1:12 PM >>
To: ws-rx@lists.oasis-open.org >>
Subject: [ws-rx] PR027 review >> >>
PR027 was captured as an issue during the discussion of >>
MakeConnection. >> >>
The issue is this: >> >>
Suppose the acksTo address is a distinct anonymous
URI. >> >>
There are two options: >> >>
1) the acksTo may be the WSA anon + reference
parameters In >>
this case acks can only get
back either if the replyTo EPR >> matches the acksTo EPR. >> >>
2) the acksTo may be the RX anon + id >>
In this case I think acks must be polled for using >>
MakeConnection. Of course they may be piggybacked
onto other >>
messages destined for the same RX anon URI. This isn't
clear >>
from the spec. >> >>
I think we need to address case #2 in the new MC spec document. >> >>
I believe case #1 is already covered by the following text in the >>
specification: >>
Implementations MUST NOT use an endpoint reference in the >>
AcksTo element that would prevent the sending of
Sequence >>
Acknowledgements back to the RM Source. >> >>
I suggest we add the same text to AcksTo that we have
for Endpoint: >>
Implementations MAY use the WS-RM anonymous URI template and >>
doing so implies that messages will be retrieved using
a >>
mechanism such as the MakeConnection
message (see section 3.7). >
>
I think this opens up a interesting issue w/regards to
the MC split; to what >
extent and in which manner should the base spec refer
to the MC spec and >
vice versa? It
seems to me that there are two ways we can go on this: >
>
1.) The base spec obliquely refers to the MC spec in the manner you suggest >
(i.e. using phrases such as "mechanisms such as . . ."). The MC spec,
in >
turn, fills in the gaps in the base spec. >
>
2.) The base spec doesn't refer at all to the MC spec. The MC spec overrules >
portions of the base spec. >
>
I think (2) is a preferable solution to (1). (1) inevitably
leads to a base >
spec which doesn't stand alone and which, when implemented and/or deployed >
without MC support, has holes in it. To pick the most
glaring example, what >
should the base spec say about reliable responses to a non-addressable >
client? If it says "it can be done but you have
to use something like MC" >
you've got a hole because you aren't defining what
happens if you *don't* >
have something like MC. >
>
- gp > >>
I will let the monk^D^D^D^Deditors figure out where
this goes >>
in the new specs :-) >> >>
Paul >> >> Paul F gave an overview of this issue. Paul F: with regards to the main spec we can close this issue. Paul F: with regards to the make Connection spec we might want to add text for clarification. Doug D: I would prefer to close the whole thing without action. Gil: I am ok about closing this issue. However we may need to add another issue, on clarification of the behavior when make connection is not in use. Doug D: :would this be guidance or normative behaviour. Gil: the base spec cannot mandate the use of make connection. Doug D: Gil should open a new issue, which is broader than the scope of PR27. Doug D moved to close PR27 issue without action, seconded by Tom R No objection, Issue Pr27 closed with no action. Action: Gil to open new issue to clarify behavior when make connection is not in use. 7 Any other businessnone |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]