Minutes
Agenda
MarcG:
Would like to discuss the status of the issue list.
Sanjay:
We'll add it to the agenda after (5)
Minutes
Resolution: minutes approved
AI review
Sanjay:
AI117 - Marc Goodner
Sanjay:
AI #114 - Chris is not on the call and I haven't seen any activity
... AI #125 - Matt Lovett
Matt:
done - follow up later in call
...: Gil completed AI #126 - close it
New Issues
MarcG:
One new issue from Gil - related to AI #126. Its PR038
Sanjay:
Not a whole lot to talk about
Issue List Status
MarcG:
Most issues that were pending are now in review.
<Dug>
FYI - all but 007 are in the spec
... Next update will probably move everything over to review.
... We need to start reviewing so we can mark the issues as closed.
DougD:
All issues except PR007 are in the spec.
... The main TC's document list has the latest version.
PR035
Sanjay:
Let's timebox this discussion to 25 minutes
Matt:
This is my attempt at wordsmithing what Chris said last week.
... Everyone knows what you mean but the phrasing is tricky.
... Phrase "process to conclusion" is causing some difficulties.
... Peter Niblett thinks people are looking for an "end-to-end" view of what is going to happen to the messages.
Jacques:
Overall adding DA definitions is a very good idea for "users" (IT people that are responsible for implementing business functionality).
... RMS and RMS are not necessarily required to implement these DAs, but we need a common definition of what they mean.
<Dug>
if people would like I could paste Peter's text here so you could see what he was thinking? (Don't think he'd mind)
... We keep talking about "delivery assurances" and "delivery" in the abstract.
<Matt Lovett>
DougD: I'd appreciate that - I don;t have my work email here
<Dug>
wsrmp:DeliveryAssurance
When applied to an RMD endpoint, this element defines a policy assertion that identifies a requirement on any RMS that wishes
to send messages to this RMD (the "corresponding RMS". Any RMD that uses the WS-RM protocol to transmit messages to the RMD
SHOULD conform to the requirement expressed by this assertion. Conversely, when it is applied to an RMS endpoint this assertion
identifies a requirement on a corresponding RMD - any RMD using the WS-RM protocol to receive messages from this RMS SHOULD
conform to the requirement expressed by this assertion.
wsrmp:AtLeastOnce
Each message is to be transmitted or processed to conclusion at least once. The requirement on an RMS is that it SHOULD retry
transmission of every message sent by the AS until it receives an acknowledgement from the RMD. The requirement on the RMD
is that it SHOULD retry delivery to the AD of every message that it receives from the RMS. There is no requirement for the
RMD to apply duplicate message filtering.
wsrmp:AtMostOnce
Each message is to be transmitted or processed to conclusion at most once. The RMS is NOT REQUIRED to retry transmission of
every message sent by the AS that is not acknowledged by the RMD, although it MAY do so. The requirement on the RMD is that
it MUST filter out duplicate messages, i.e. that it MUST not redeliver any message to the AD that has already been processed
to completion by the AD.
wsrmp:ExactlyOnce
Each message is to be transmitted or processed to conclusion exactly once. The requirement on an RMS is that it SHOULD retry
transmission of every message sent by the AS until it receives an acknowledgement from the RMD. The requirement on the RMD
is that it MUST filter out duplicate messages, i.e. that it MUST not redeliver any message to the AD that has already been
processed to completion by the AD.
... "Delivery" is a contract. We should use the word "delivery" and "deliver" in these definitions.
... That would help those areas where "process to conclusion" is causing problems.
... Rest of my comments are more about the details of Matt's wording.
<Iwasa>
Sanjay, Could you add me on the roll? I've just joined the call.
<Sanjay>
Added Iwasa to the roll.
<Iwasa>
Thank you, Sanjay.
... Some problems in the area of "At Most Once" messages being delivered simply because they haven't been acknowledged.
Sanjay:
Matt, could you work with Peter and Jacques to update your definitions.
Resolution: AI #126 remains open
Sanjay:
PR009 and PR020 are both related to DA's so lets skip them.
PR0037
Ashok:
(reviews status of PR0037)
... I've tried to create 3 different style of the RMAssertion
... First is the RMAssertion like it was on its own.
... Second is with the security token nested within it
... Third is with the security transport token nested within it - including the transport binding assertion.
... What we want to spell out is that somewhere with the policy you must define the security tranport policy.
MarcG:
On the requirement that you must that the transport binding included.
... When you first brought this up you had concerns about pullin in bits of policy from different domains.
... Are you still concerned with this?
Ashok:
I think this is ok.
MarcG:
What we intended from the original statement was that the SequenceTransportSecurity assertion is not a substitute for sp:TransportBinding
Ashok:
The wording there is currently a bit skimpy, but still correct.
Sanjay:
In section 2.5.2 it still says "This assertion is effectively meaningless . . ."
Ashok:
That should be removed.
MarcG:
I'm not seeing wspptional on these. Is that intentional?
Ashok:
Yes. If you use "wspptional", after normalization, you will end up with policy alternatives that don't have the assertion.
... If you want that policy you should just use it.
MarcG:
But don't you need an additional wspolicy if you are nesting policies?
Ashok:
WS-Policy is still working on that, but not currently.
<rsalz>
We can/should consider that an editorial matter.
MarcG:
(notes most policy experts are at WS-Policy F2F) We need to give people more time to review this proposal.
PR001
Sanjay:
Doug suggested we separate MC into its own spec. We agreed to this on the concall of (???)
DougD:
(reviews status of MC spec)
... People should review the MC spec and raise issues as needed.
... Left an open section to define WS-Policy assertions for MC.
Sanjay:
The set of issues that were open against MakeConnection text have be re-assigned to MakeConnection spec.
... Need to review MC issues.
DougD:
Since PR001 was raised by WS-Addressing, and WS-Addressing has changed course to allow for additional URIs, we should close
this issue with no action.
DougD:
Moves to close with no action:
Anish:
This issue was filed by WS-Addressing working group?
Anish:
We should email them about the resolution.
Sanjay:
For all PR issues, Marc is planning on communicating the dispensation of those issues to whomever raised them.
Resolution: Proposal to close with no action passes by unanimous consent.
Gil yeah
PR0015
... Hoping that what then meant is that there is no way to tell wether the RMD supports polling for messages.
... Think that the direction to go is with a WS-Policy assertion.
Action: Doug to define WS-Policy assertion for MC so that a service can advertise that it supports MC.
PR028
... Seems a bit like a duplicate of PR0015
... Can't tell if there is more to it than that.
<Matt Lovett>
"
MakeConnection as defined today relies on the RM Anonymous URI template. The spec does not adequately specify the preconditions
necessary for the exchange to be successful.
Prior to a MakeConnection message, do both the client and the server have to be in possession of a correctly constructed
instance of the RM anon URI template? Of an EPR using this template? The example messages invent a subscription operation
in step 1, which indicates that the precise URI and the intent to enable MakeConnection must be negotiated between the RMD
and RMS out of band, yet nowhere are these preconditions enumerated. The RM protocol preconditions only list an EPR as a
precondition, not the precise form of that EPR, and any intention that buffering of messages should be engaged. What happens
if a client does a MakeConnection without all preconditions being satisfied also appears to be underspecified."
Anish:
Wondering if Jonathan meant something that happens during sequence establishment?
DougD:
Maybe. There are two things that need to happen during sequence establishment. The RMS needs to know that the RMD supports
MC.
... The RMD needs to knows that the RMS will be polling. Simply using the MC Anon URI template indicates that the sender intends
to poll.
... Similar to the way in which wsa:anon and wsa:none are used.
Marc:
Jonathan mentioned something about the example?
DougD:
(reads part of above)
... Don't know why this would be true.
... I don't really agree with his assertion.
... Move that we close this as a duplicate of PR0015
Resolution: Motion passes by unanimous consent.
PR0029
... Mostly about the use of UUIDs in the MC anon URI.
... Maybe we can address this concerns by saying that the client needs to use "something unique" instead of requiring a UUID?
Anish:
That sounds right. The first part of this issue seems correct and we should take that into account. I don't agree with the
... opaqueness arguements.
Stefan:
At one point we differentetiaed the poller using an endpoint parameter. I'm not sure why we stopped doing that.
... The other thing is we should consider using a URI scheme.
DougD:
You are talking about reference parameters?
DougD:
That would required receievers of these URIs to crack open the ERP and examine the reference parameters.
... Its also a touchy subject for some members of WS-Addresssing
... Option of URI scheme is an option, but we'd have to register that scheme. It could work but there's a lot
... of overhead with this apporach.
Anish:
Using reference parameters is tricky for another reason. What if there are multiple reference paramters and only one of them
... is the one we define? Do the other parameters figure into the equation.
... A new URI scheme is feasible, but you need to be cautious.
... If an existing scheme can be used you should do that.
DougD:
What is the general sense of the TC about relaxing the MC anon URI template so that it doesn't require a UUID?\
Anish:
Would you specify what uniqueness means? Is it a string comparison or something more?
DougD:
Was assuming it meant a string comparison.
... Text would say that it needs to be globally unique but we wouldn't specify an exact mechanism.
Action: Doug to propose specific text to relax restriction on MS anon URI template.
PR030
DougD:
(reviews the issue)
... Now that MC is in its own spec, this issue should go away.
... If we try to limit it to WS-RM only, we kill its usefullness.
Matt:
To say that the returned message must "relate to WS-RM" is asking for trouble.
DougD:
Moves to close no action.
Resolution: Motion passes by unanimous consent.
PR031
Resolution: PR031 closed with no action by unanimous consent
(PR030 and PR031 were mixed up due to crossed message links)
PR030
<Matt Lovett>
"The optional nature should be clarified in the spec, and further infrastructure should be deployed (e.g. a MakeConnectionRefused
error, possibly an rm:MakeConnectionEnabled policy assertion) to assist in interoperability in determining at run time, possibly
even at design time, whether a MakeConnection attempt has been, or will be, successful."
Gil:
Think this issue is covered by the AI for PR0015
Matt:
Agree with Gil. Resolution to PR0015 covers this issue.
DougD:
Moves to close this issue as a dup of PR0015
Resolution: Motion passes by unanimous consent.
Sanjay:
Out of agenda items, so lets discuss the new issue.
New issue from Gil: 38
Gil:
need clarity on how base spec references MC spec/
... normative ref, elude to MC-like features?
...normative would tie the two specs together (timeline)
... non-normative ref could lead to tricky wording
Jacques:
We would like to see an implementation of the main spec is conforming without MC
... Use of MC should not be required to conform to base WS-RM
Gil:
MC has always been optional even when it was in RM spec
... even if MC is optional we could have a normative ref to it.
... issues of normative/non-norm and optionality are orthogonal
... what should an RM endpoint do in the absence of MC
Ashok:
I agree with that.
DougD:
Gil you seem to have a particular direction in mind. Could you come up with a sepific proposal?
Action: Gil to propose specific wording around this issue.
Marc:
THis issue is taking us back in a very unfortunate direction. This issue led to MakeConnection in the first place.
... We had discussed something like this but decided to propose MakeConnection instead.
<Jacques>
Technically true - you can have normative refs to an optional feature. But... do we want main spec to imply that MC is the
[only] way to go for the polling aspect?
... We don't need to constrain the spec to prohibit the use of anon. This is going over old ground.
DougD:
Agree and second what Marc says. Don't want to see a normative reference.
Marc:
Part of the reason we didn't go down the path of defining the behavior in these cases
... is that we couldn't come up with a proposal that covered all the uses cases. We end up dealing
with transport specific issue. This is better dealt with in WS-I. We don't need to do anything here.
<Sanjay>
Doug, could you please scribe while Gil talks
Gil:
I think the problem here is that MC is not required - so what does an RM endpoint do in the absence of MC?
... I think not defining how an RM component is asking for interop problems.
... its not a transport. Its a problem with composing with WSA
... I think we need to define exactly what specs a conforming RM impl needs to support. Saying "there's no problem here" isn't
going to help anyone.
... ws-i can't make up specs.
... a non-addressable client sends CS, if Offer is anonymous - what does the RMD do with it? ws-i can't solve this. We need
to fix a hole in the spec.
Marc:
I don't think new elements/features are needed to solve this - so ws-i can do this.
Gil:
I'm not talking about new protocol elements at all
<Stefan>
i thought that defining things like this, how to use WS-A and WS-RM in certain scenarios, was exactly what WS-I profiles do
Anish:
we may need to define behavior. I agree with Gil - this could be an interop issue. We should address this in this TC instead
of ws-i.
... marc - you said we already discussed this - what did you mean?
Marc:
back in March we discussed replay and the TC wanted to support a broader set of scenarios.
Anish:
that was specific to req/res MEP.
Marc:
yes - replaying an unacked requested was one way to solve that particular situation. But the tc wanted to solve more than
just that
Gil:
if we want to say that a non-addressable client can resend an unacked request then we should put that in the spec. We shouldn't
avoid discussing the ways to solve these problems.
Sanjay:
clearly we need to discuss this more. Gil's AI might help focus the discussion.