[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes from 1/4 teleconf
Prelim minutes are attached. Please provide corrections before Monday morning to the entire list. Tom -- ---------------------------------------------------- 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/4/2007
|
Prelim Minutes of OASIS WS-RX Teleconference Jan 4, 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 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 14, 2006
meeting minutes (preliminary:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200612/msg00058.html) 4) Sponsorship for future calls 5) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 6) Editors' update 7) Issue progress review 8) W3C WS Policy last call review 9) 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> PR021 Piggy-backing
problematic http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i021 e> PR018 Piggyback message
combinations http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i018 f> PR022 RMD cannot detect some
incomplete Sequences http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022 g> PR007 RM Destination lacks a
mechanism for cleanly terminating inbound sequences http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007 10) Any other business Marc G suggested that the issues be reordered 18 before 21. Also the DA issues can be delayed to the end. Paul F I have a proposal for 27, which we can add to the end. New order 18 21 2 07 35 9 20 27 1 Approval of the 12/14 Minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21674/MinutesWSRX-121406.htm
Tom moved to approve 12/14 minutes, Charlie seconded.
§ No objections, minutes of 12/14 approved. 2
Sponsorship for future calls
Looking for sponsors for calls beyond 1/11/2007. Bob F: Gil: Bea can do two calls. Marc G: Microsoft can do one call. 3
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
Report created 04 January 2007 03:57pm 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: Done by Ashok Assigned: 2006-12-07 Due: --- #0115: Stefan to put together concrete objections to Gil's strawman on PR007 Owner: Stefan Batres Status: Closed Assigned: 2006-12-14 Due: --- #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: Still Open Assigned: 2007-01-03 Due: --- #0118: Jacques and Chris F will work toward a proposal to
resolve PR 35 and 9 for Jan 4 call Owner: Jacques Durand Status: Done Assigned: 2007-01-03 Due: --- 4
Editors' update
Dug: all the issues resolved have been incorporated in the
spec. Also Make connection has been
separated into its own spec. 5
Issue progress review
Paul went thru the issues list to determine if all issues have owners prescribed. Paul: could Marc use minutes from 1/7 to attach the owner names. Marc G: I can do that. Paul: issue 12 and 18. Marc G: 12 is against make connection. Sanjay: 18 was closed on Dec 7. Marc G: the list you have is correct list of open issues 28 – 31 are part of make connection. We should deal with these after we close the others. Paul F: we have concrete proposals for all non-make
connection issues. 6
W3C WS Policy last call review
Ashok: mail: Sanjay asked for volunteers to
review the WS-Policy Last Call documents. I interpreted this to mean
"does WS-RX Policy work in the context of WS-Policy as embodied in the
Last Call documents". If this was not the intention, my
apologies, and we can try again. So, I reread the WS-RX Policy
Documents. Here is what I learned. The WS-RX Policy document defines 3
assertions. The first assertion is whether
Reliable Messaging is used or not. <wsrmp:RMAssertion [wsp:Optional="true"]?
... > Somewhat to my surprise, this
assertion says nothing about delivery assurances. In my view, applications may want
to specify whether they want duplicates removed from a sequence or they want the
messages ordered. So this assertion
seems underspecified. The second and third assertions are
about security considerations. The second assertion is <wsrmp:SequenceSTR [wsp:Optional="true"]?
... /> This says that an RM Sequence MUST
be bound to an explicit token that is referenced from a wsse:SecurityTokenReference in the CreateSequence message. This assertion is, in fact
dependent on the RM assertion and cannot be used unless the RM assertion is
present. The third assertion is <wsrmp:SequenceTransportSecurity [wsp:Optional="true"]?
... /> This assertion defines the
requirement that an RM Sequence MUST be bound to the session(s) of the
underlying transport-level security protocol (e.g. SSL/TLS) used to carry the CreateSequence and CreateSequenceResponse
messages. Further, this assertion must occur
in conjunction with the RMAssertion and a sp:TransportBinding assertion that
requires the use of some transport-level security mechanism (e.g. sp:HttpsToken). Thus, this assertion is dependent
on two other assertions. WS-Policy says in section 3.1
"A policy assertion represents an individual requirement, capability, or
other property of a behavior". But, as we have seen, two of the
assertions cannot stand independently. Consider the situation where a
policy contains the first and second assertion, both marked 'optional'. When such a policy is normalized,
we get four policy alternatives. One of
these alternatives will contain the second assertion and not the first. This is clearly an error. Thus, I think some change to the
WS-Policy wording may be desirable. We should also think about whether
we can fix this problem on our own. Clearly, the second assertion can
be limited to appear only as a nested assertion for the first assertion. This would solve the situation wrt the second assertion. But what about
the third assertion? This
requires the first assertion as well as the sp:TransportBinding assertion. So should we make both the first
and third assertions nested assertions of sp:TransportBinding? But that's not something we can do. We don't own that domain. All the best, Ashok Paul F: can we fix these problems ourselves. Ashok: nesting the security token assertion inside rm assertion could fix that. However the other is not in our control. Marc G: I could agree to investigate the nesting of the security token. We can also try to find ways to fix the transport security assertion. Chris: when you have two assertionts both marked optional which are interoperating, there are problems. Nesting may be an effective solution. The problem with the sp security transport dependency is not unique for us, so I do not think we have to do anything about it. Asir: what it the problem Ashok: with an expression that has both assertions as optional, the security association token cannot appear without the rm assertion.. There is a solution here to next the security token association nested with rm assertion. For Transport Security, it is more difficult to deal with. Anish: this seems like feedback to policy group to clarify the independence of assertions. With this security example, we might get an answer to the problem. Action: Ashok to prepare draft feedback to policy working group, on need to be careful to avoid dependency related problems. Action: Ashok to raise new issue about nesting policy assertions for RM. 7
9) Discussion of PR Issues
7.1
e> PR018 Piggyback message combinations
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i018
Gil: Dug had the last proposal for that one, on Dec 17. http://www.oasis-open.org/archives/ws-rx/200612/msg00026.html I think the resolution of this issue and that of PR021 should be
combined. In general I like this proposal, but I still have a problem with the
language about reference parameters; I don't know what it means to
"consider" a reference parameter. - gp From:
Doug Davis [mailto:dug@us.ibm.com]
Doug D moved to accept Doug’s proposal to resolve issue 18, Matt seconded. Jacques: one comment on recent mail from Doug on list regarding definition of piggybacking. Some combination of rm headers should not be considered piggybacking. It would be good to make this more explicit. Gil: This leads into issue 21, on defining what piggybacking is. Optionality of piggybacking is in eyes of sender. Ack request headers may be piggygacked. Paul F: how do we deal with that with the motion we have. Could PR 21 cover this. Gil: once we agree on text for 21, I could provide text for needed changes to resolution to 18. No objection, Issue 18 resolved by accepting proposal from Doug D. 7.2
d> PR021 Piggy-backing problematic
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i021
Gill Email: http://www.oasis-open.org/archives/ws-rx/200612/msg00060.html I've been reviewing the message
that accompanied this issue and I'd like to update/revise my position on the
points I made: 1.) Complicates SOAP processing: I
think the proposal on the table for PR018 basically eliminates this concern. 2.) Agreement on use of
piggy-backing: I'm still somewhat concerned about this aspect. I think the spec
should make it clear that the "MAY" in piggy-backing applies to the
piggy-backer; it's sender-optional. RMS and RMD implementations MUST be
prepared to handle piggy-backed SequenceAcknowledgement
and AckRequested (respectively) headers. 3.) EPR comparison: I still think
this is a real concern. We are talking about comparing EPRs,
something the WS-Addr group decided was too hairy to
get into. Waving our hands and saying that reference parameters must be
"considered" doesn't cut it. We should profile a small subset of the
options for EPR comparison and say "this is how you compare EPRs for the purposes of selecting a SOAP message on which
to piggy-back". We can afford to be a little conservative because a false
negative comparison (thinking two EPRs are
"different" when they are really "the same") isn't all that
harmful. - gp Gil: we allow this but it is sender optional. We need to clarify Pr 18 text to clarify that it is sender optional, and the receiver has to be prepared to have piggygacking present on not present. Gil: A more difficult problem is how to determine piggybacking address, which requires some kind of epr comparison by the implementation. We have not done an adequate job on determining how this epr comparison will happen. We should have at least one epr comparison algorithm. Tom: prescribing an algorighm that will work everywhere might not be necessary. The sender knows when it will work (e.g. anonymous) and when it knows somehow, it can try to piggyback. An error can result if it is not correct. Doug D: I would like to focus on point 2. This is true for messages which are not piggybacked. The use of Must understand attribute must be considered. Gil: acks lost due to non agreement on how piggybacking is to be sent is a special case. Paul F: we need a concrete proposal for Issue 21. Gil: would there be support for epr comparison? Marc G: I am not sure there is a proposal needed for this problem 3. I do not think we need to do anything for 2. We could close the entire issue without change. I do not think it is a good idea to go back to discussion of epr comparison. We have text about significance of ref parms already. Action: Gill will provide concrete language around item 2 in his proposal for issue 21. Stefan: the spec does not have to have an explicit algorithm Dave O: the epr comparison has not been discussed specifically with piggybacking. You cannot have interoperability of piggybacking out of the box without addressing the concern in 3). The right people are gathered here to solve this problem. The solution, if scoped to piggybaking, might be acceptable. I support doing it. Coleen: choosing one algorithm is not required. I agree with Tom’s point. Gil: lets take discussion of item 3 to mailing list. 7.3
f> PR022 RMD cannot detect some incomplete
Sequences
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022
http://www.oasis-open.org/archives/ws-rx/200612/msg00032.html Title: PR022: strawman
proposal From previous discussions on this
issue it is evident that the TC doesn't think that the motivating requirement
is pressing enough to justify any large changes to the spec (i.e. making TerminateSequence or CloseSequence
required). With that in mind I propose that we resolve this issue by doing the
following: 1.) Adding the mandatory LastMsgNumber element to CloseSequence.
As previously discussed, the description of LastMsgNumber
should be something along the lines of: The LastMsgNumber
element specifies the highest assigned message number of all the Sequence
Traffic Messages for the Sequence being closed. The RM Destination can use this
information, for example, to implement the behavior indicated by wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior. 2.) The use of CloseSequence
remains optional. Any agreement between the RMS and the RMD about the use of CloseSequence to allow the RMD to determine if it has succesfully received all the messages sent by the RMS is
out of scope. 3.) An RMS that sends a CloseSequence but does not receive a CloseSequenceResponse
is free to retry the CloseSequence message or not
depending upon local policy etc. - gp There were questions on the details of the proposal. Jacques: the wording uses SHOULD. There is a corner case when is should be a MUST. When it was agreed that the csr will send it and it does not, there should be an error sent. Gil: should we define another fault for this case. Jacques: we need to make RMS aware, of this situation. There has to be an error message about the expectation of a last message number, otherwise the entire sequence will be lost. Doug D: What about when RMS does not know about last sequence number. This is a special case. Jacques: it is when discard all is in use. Either the spec should say that when discard all is in use the last message must be sent, or an error will be sent. Paul: I think that SHOULD is a good enough word. People need good enough reasons to not obey a should requirement. Gil: I am sympathetic to Jacques concern in the area. If you make it MUST for the corner case, it could be MUST for all. Tom: we have to worry about the loss of state edge case for an RMS.. Stefan: whats wrong with: if RMS knows the last message number then it MUST include it in CS/TS ? Paul F: take Stefan’s wording, and have it apply to both close sequence and terminate sequence. Action: Gill will make new proposal for Issue 22. 7.4
g> PR007 RM Destination lacks a mechanism for
cleanly terminating inbound sequences
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007
Gil: both close sequence and termininate sequence should include a last number element. If agreed, I could write a concrete proposal Paul: discussion requires a concrete proposal. Action: Gil to provide a concrete proposal to resolve issue 007 to include a finalAck in the closeSequence and TerminateSequence message. 7.5
a> PR035 Delivery Assurance
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035
Jacques reviewed his original proposal for 35:
Jacques: I believe an entirely new section is needed. http://www.oasis-open.org/archives/ws-rx/200701/msg00013.html Proposal for these, concerning the wsrm core specification (complementary proposal from Chris
is about additions in WS RM Policy) Add a new 2.2 section (moving down
former 2.2 -> 2.3, etc) 2.2 Delivery Assurances The delivery assurances (DAs)
alluded to at the beginning of section 2, and enabled
by the reliable messaging protocol are defined below as AtLeastOnceDelivery,
AtMostOnceDelivery, ExactlyOnceDelivery
and InOrderDelivery. Their enforcement is
communicated or advertised between parties in the form of policy assertions
that are defined in WS-RM Policy specification. This specification does not
require that these DAs be signaled between RM Source and RM Destination over
the protocol described here. Users may choose to communicate these DAs via the
protocol, e.g. using extensibility points. AtLeastOnceDelivery:
When sending a message under this delivery assurance (DA), one of the two
following outcomes shall occur: either (1) the RMD has received the message and
successfully delivered it to the AD, or (2) either the AS or the AD is made
aware of a delivery failure. Note: it may happen that both (1) and (2) occur
for a message. It is also possible that the message is delivered more than
once. AtMostOnceDelivery:
When sent under this DA, a message shall not be delivered more than once by the
RMD to the AD. Message duplicates are identified based on Sequence ID and
Sequence number. Note: a message that is not delivered at all is compliant with
this DA. ExactlyOnceDelivery:
This DA is equivalent to the combination of AtLeastOnceDelivery
and AtMostOnceDelivery DAs. InOrderDelivery: When sent under this DA, messages from the
same sequence shall be delivered by the RMD in the same order they have been
sent by the AS, i.e. submitted to the RMS. Note: the protocol provides ways to
signal specific delivery behaviors regarding incomplete sequences (see IncompleteSequenceBehavior). -Jacques Marc G: why not use the definitions from the first CD. Jacques: these are inspired by the earlier definitions. I think these are better than the previous ones. The wording is more cautious. Tom: if the DAs could be combined, we could define in order as Chris did, and combine it with at least once if required. This could result in three policy assertions. Chris F: proposed three policy assertions for DAs. From: Christopher B Ferris
[mailto:chrisfer@us.ibm.com] Sent: Thursday, December 07, 2006
1:35 PM To: ws-rx@lists.oasis-open.org Subject: [ws-rx]
strawman proposal for delivery assurance in policy
for RM 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? Christopher Ferris Anish: I am not in agreement with the “ignorable” part. The Client may need to know if a DA is in use. Gil: I think it is Ignorable. It should not effect interop. Marc G: I would not like to depend to the newest changes to the Policy spec. You do not want to hurt a client that Anish: Our charter is to wait for w3c spec to be at a particular state. anish: this is what the charter says: anish: "If
an above specification is outside of a standardization process at the time this
TC moves to ratify its deliverables, or is not far enough along in the
standardization process, any normative references to it in the TC output will
be expressed in an abstract manner, and the incarnation will be left at that
time as an exercise in interoperability." Tom: there are both lax and strict forms of intersection algorithm
in the new policy spec version. This
should be considered when discussion “ignorable” 7.6
b> PR009 "Duplicate Elimination"
and "Message Ordering"
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009 no time 7.7
c> PR020 Message ordering and duplication
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020 no time 8 Any other businessDoug D: I have separated out the make connection into a new spec. Can I make a new draft of the main spec without Make connection. Paul: we agreed to go forward with two new editors drafts. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]