[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: raw dump of the ws-rx chat log
[12:49] Room information was updated by: Dug
USA Toll Free Number: 888-566-0007
USA Toll Number: +1-210-234-0004
PASSCODE: 19235
Mute/Unmute: *6
[12:59] Steve Carter: I'm not hearing much on the bridge
[13:01] Dug: brb - calling the operator
[13:04] TomRutt: i hear a low level crackle on the bridge
[13:04] Martin: is everyone getting silence?
[13:04] Gil: nope
[13:04] Gil: anything but
[13:05] Dug: operator isn't answering my request, still trying....
[13:06] Gil: SCRIBE: Gil
[13:06] Gil: TOPIC: Agenda
[13:06] Gil: MarcG: Would like to discuss the status of the issue list.
[13:07] Gil: Sanjay: We'll add it to the agenda after (5)
[13:07] Gil: TOPIC: Minutes
[13:08] TomRutt:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21859/Minute
sWSRX-011107.htm
[13:09] Gil: RESOLUTION: minutes approved
[13:09] Gil: TOPIC: AI review
[13:10] Gil: Sanjay: AI117 - Marc Goodner
[13:10] Gil: MarcG: (done)
[13:10] MrGoodner: Issue link:
http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml
[13:10] Gil: Sanjay: Close AI #117
[13:11] Gil: Sanjay: AI #114 - Chris is not on the call and I haven't seen
any activity
[13:11] Matt Lovett:
http://www.oasis-open.org/archives/ws-rx/200701/msg00055.html
[13:11] Gil: ... AI #125 - Matt Lovett
[13:11] Gil: Matt: done - follow up later in call
[13:11] Gil: Sanjay: Close AI #126
[13:12] Gil: ...: Gil completed AI #126 - close it
[13:12] Gil: TOPIC: New Issues
[13:12] Gil: MarcG: One new issue from Gil - related to AI #126. Its PR038
[13:12] Gil: Sanjay: Not a whole lot to talk about
[13:13] Gil: Sanjay: Issue accepted.
[13:13] Gil: TOPIC: Issue List Status
[13:13] Gil: MarcG: Most issues that were pending are now in review.
[13:13] Dug: FYI - all but 007 are in the spec
[13:13] Gil: ... Next update will probably move everything over to review.
[13:14] Gil: ... We need to start reviewing so we can mark the issues as
closed.
[13:14] Gil: Doug: All issues except PR007 are in the spec.
[13:14] Gil: ... The main TC's document list has the latest version.
[13:14] MrGoodner: Latest RM spec link:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21883/wsrm-1
.1-spec-wd-16.pdf
[13:15] MrGoodner: Latest RM Policy:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/20902/wsrmp-
1.1-spec-wd-11.pdf
[13:15] Gil: Doug: That's correct
[13:15] MrGoodner: Latest MC:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21705/wsmc-1
.0-spec-wd-01.pdf
[13:15] MrGoodner: Latest zip (all of the above in one):
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21882/Latest
WSRX.zip
[13:15] Gil I love joint scribbing
[13:16] Gil: TOPIC: PR035
[13:18] Gil: Sanjay: Let's timebox this discussion to 25 minutes
[13:18] Gil: Matt: This is my attempt at wordsmithing what Chris said last
week.
[13:18] Gil: ... Everyone knows what you mean but the phrasing is tricky.
[13:19] Gil: ... Phrase "process to conclusion" is causing some
difficulties.
[13:19] Gil: ... Peter Niblett thinks people are looking for an "end-to-end"
view of what is going to happen to the messages.
[13:20] Gil: Jacques: Overall adding DA definitions is a very good idea for
"users" (IT people that are responsible for implementing business
functionality).
[13:21] Gil: ... RMS and RMS are not necessarily required to implement these
DAs, but we need a common definition of what they mean.
[13:21] 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)
[13:21] Gil: ... We keep talking about "delivery assurances" and "delivery"
in the abstract.
[13:21] Matt Lovett: Doug: I'd appreciate that - I don;t have my work email
here
[13:22] 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.
[13:22] Gil: ... "Delivery" is a contract. We should use the word "delivery"
and "deliver" in these definitions.
[13:22] Gil: ... That would help those areas where "process to conclusion"
is causing problems.
[13:23] Gil: ... Rest of my comments are more about the details of Matt's
wording.
[13:23] Iwasa: Sanjay, Could you add me on the roll? I've just joined the
call.
[13:23] Sanjay: Added Iwasa to the roll.
[13:23] Iwasa: Thank you, Sanjay.
[13:24] Gil: ... Some problems in the area of "At Most Once" messages being
delivered simply because they haven't been acknowledged.
[13:24] Gil: Sanjay: Matt, could you work with Peter and Jacques to update
your definitions.
[13:25] Gil: RESOLUTION: AI #126 remains open
[13:26] Gil: Sanjay: PR009 and PR020 are both related to DA's so lets skip
them.
[13:27] Gil: TOPIC: PR0037
[13:27] Gil: Ashok: (reviews status of PR0037)
[13:27] Dug: I think this is Ashok's latest proposal:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg
00057.html
[13:27] Gil: ... I've tried to create 3 different style of the RMAssertion
[13:27] Gil: ... First is the RMAssertion like it was on its own.
[13:28] Gil: ... Second is with the security token nested within it
[13:28] Gil: ... Third is with the security transport token nested within it
- including the transport binding assertion.
[13:29] Gil: ... What we want to spell out is that somewhere with the policy
you must define the security tranport policy.
[13:29] Gil: MarcG: On the requirement that you must that the transport
binding included.
[13:30] Gil: ... When you first brought this up you had concerns about
pullin in bits of policy from different domains.
[13:30] Gil: ... Are you still concerned with this?
[13:30] Gil: Ashok: I think this is ok.
[13:31] Gil: MarcG: What we intended from the original statement was that
the SequenceTransportSecurity assertion is not a substitute for
sp:TransportBinding
[13:31] Gil: Ashok: The wording there is currently a bit skimpy, but still
correct.
[13:32] Gil: Sanjay: In section 2.5.2 it still says "This assertion is
effectively meaningless . . ."
[13:32] Gil: Ashok: That should be removed.
[13:32] Gil: MarcG: I'm not seeing wspptional on these. Is that intentional?
[13:33] Gil: Ashok: Yes. If you use "wspptional", after normalization, you
will end up with policy alternatives that don't have the assertion.
[13:33] Gil: ... If you want that policy you should just use it.
[13:34] Gil: MarcG: But don't you need an additional wspolicy if you are
nesting policies?
[13:34] Gil: Ashok: WS-Policy is still working on that, but not currently.
[13:34] rsalz: We can/should consider that an editorial matter.
[13:34] Dug: +1 Marc
[13:35] Gil: MarcG: (notes most policy experts are at WS-Policy F2F) We need
to give people more time to review this proposal.
[13:35] Gil: TOPIC: PR001
[13:35] Gil: TOPIC: PR001
[13:36] Gil: Sanjay: Doug suggested we separate MC into its own spec. We
agreed to this on the concall of (???)
[13:36] Gil: Doug: (reviews status of MC spec)
[13:36] Gil: ... People should review the MC spec and raise issues as
needed.
[13:37] Gil: ... Left an open section to define WS-Policy assertions for MC.
[13:37] Gil: Sanjay: The set of issues that were open against MakeConnection
text have be re-assigned to MakeConnection spec.
[13:37] Gil: ... Need to review MC issues.
[13:38] Gil: Doug: 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.
[13:39] Gil: Doug: Moves to close with no action:
[13:39] Gil: Gil: Seconds
[13:39] Gil: Anish: This issue was filed by WS-Addressing working group?
[13:39] Gil: Doug: Yes
[13:39] Gil: Anish: We should email them about the resolution.
[13:40] Gil: Sanjay: For all PR issues, Marc is planning on communicating
the dispensation of those issues to whomever raised them.
[13:41] Gil: RESOLUTION: Proposal to close with no action passes by
unanimous consent.
[13:41] Gil yeah
[13:41] Gil: TOPIC: PR0015
[13:41] Gil:
[13:42] Gil: Doug: (reviews issue)
[13:42] Gil: ... Hoping that what then meant is that there is no way to tell
wether the RMD supports polling for messages.
[13:42] Gil: ... Think that the direction to go is with a WS-Policy
assertion.
[13:42] Gil: Marc: Yeah
[13:42] Gil: Anish: Good idea.
[13:42] Gil: +1
[13:43] Gil: ACTION ITEM: Doug to define WS-Policy assertion for MC so that
a service can advertise that it supports MC.
[13:43] Gil: TOPIC: PR028
[13:43] Gil:
[13:43] Gil: Doug: (reviews issue)
[13:44] Gil: ... Seems a bit like a duplicate of PR0015
[13:45] Gil: ... Can't tell if there is more to it than that.
[13:45] 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."
[13:45] Gil: Anish: Wondering if Jonathan meant something that happens
during sequence establishment?
[13:46] Gil: Doug: Maybe. There are two things that need to happen during
sequence establishment. The RMS needs to know that the RMD supports MC.
[13:46] Gil: ... 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.
[13:46] Gil: ... Similar to the way in which wsa:anon and wsa:none are used.
[13:47] Gil: Marc: Jonathan mentioned something about the example?
[13:47] Gil: Doug: (reads part of above)
[13:47] Gil: ... Don't know why this would be true.
[13:48] Gil: ... I don't really agree with his assertion.
[13:48] Gil: ... Move that we close this as a duplicate of PR0015
[13:48] Gil: Matt: (seconds)
[13:49] Gil: RESOLUTION: Motion passes by unanimous consent.
[13:49] Gil: TOPIC: PR0029
[13:49] Gil:
[13:49] Gil: Doug: (reviews issue)
[13:50] Gil: ... Mostly about the use of UUIDs in the MC anon URI.
[13:51] Gil: ... Maybe we can address this concerns by saying that the
client needs to use "something unique" instead of requiring a UUID?
[13:52] Gil: 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
[13:52] Gil: ... opaqueness arguements.
[13:53] Gil: Stefan: At one point we differentetiaed the poller using an
endpoint parameter. I'm not sure why we stopped doing that.
[13:53] Gil: ... The other thing is we should consider using a URI scheme.
[13:53] Gil: Doug: You are talking about reference parameters?
[13:53] Gil: Stefan: Yes.
[13:54] Gil: Doug: That would required receievers of these URIs to crack
open the ERP and examine the reference parameters.
[13:54] Gil: ... Its also a touchy subject for some members of
WS-Addresssing
[13:55] Gil: ... Option of URI scheme is an option, but we'd have to
register that scheme. It could work but there's a lot
[13:55] Gil: ... of overhead with this apporach.
[13:55] Gil: Anish: Using reference parameters is tricky for another reason.
What if there are multiple reference paramters and only one of them
[13:56] Gil: ... is the one we define? Do the other parameters figure into
the equation.
[13:56] Gil: ... A new URI scheme is feasible, but you need to be cautious.
[13:56] Gil: ... If an existing scheme can be used you should do that.
[13:57] Gil: Doug: What is the general sense of the TC about relaxing the MC
anon URI template so that it doesn't require a UUID?\
[13:57] Gil: I'm for it.
[13:57] Gil: Anish: Would you specify what uniqueness means? Is it a string
comparison or something more?
[13:58] Gil: Doug: Was assuming it meant a string comparison.
[13:58] Gil: ... Text would say that it needs to be globally unique but we
wouldn't specify an exact mechanism.
[13:58] Gil: ACTION ITEM: Doug to propose specific text to relax restriction
on MS anon URI template.
[13:59] Gil: TOPIC: PR030
[13:59] Gil:
[13:59] Gil: Doug: (reviews the issue)
[14:00] Gil: ... Now that MC is in its own spec, this issue should go away.
[14:00] Gil: ... If we try to limit it to WS-RM only, we kill its
usefullness.
[14:01] Gil: Matt: To say that the returned message must "relate to WS-RM"
is asking for trouble.
[14:01] Gil: Doug: Moves to close no action.
[14:01] Gil: Anish: (seconds)
[14:01] Gil: RESOLUTION: Motion passes by unanimous consent.
[14:02] Gil: TOPIC: PR031
[14:02] Gil:
[14:03] Gil: RESOLUTION: PR031 closed with no action by unanimous consent
[14:03] Gil: (PR030 and PR031 were mixed up due to crossed message links)
[14:03] Gil: TOPIC: PR030
[14:04] 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."
[14:05] Gil: Gil: Think this issue is covered by the AI for PR0015
[14:06] Gil: Matt: Agree with Gil. Resolution to PR0015 covers this issue.
[14:07] Gil: Doug: Moves to close this issue as a dup of PR0015
[14:07] Gil: Matt: (seconds)
[14:07] Gil: RESOLUTION: Motion passes by unanimous consent.
[14:08] Gil: Sanjay: Out of agenda items, so lets discuss the new issue.
[14:08] Dug: TOPIC: New issue from Gil: 38
[14:09] Dug: Gil: need clarity on how base spec references MC spce
[14:09] Dug: ... normative ref, elude to MC-like features?
[14:09] Dug: ...normative would tie the two specs together (timeline)
[14:10] Dug: ... non-normative ref could lead to tricky wording
[14:10] Gil: Jacques: We would like to see an implementation of the main
spec is conforming without MC
[14:11] Dug: s/spce/spec/
[14:11] Gil: ... Use of MC should not be required to conform to base WS-RM
[14:12] Dug: Gil: MC has always been optional even when it was in RM spec
[14:12] Dug: ... even if MC is optional we could have a normative ref to it.
[14:13] Dug: ... issues of normative/non-norm and optionality are orthogonal
[14:13] Dug: ... what should an RM endpoint do in the absence of MC
[14:13] Gil: Ashok: I agree with that.
[14:14] Gil: Doug: Gil you seem to have a particular direction in mind.
Could you come up with a sepific proposal?
[14:14] Gil: ACTION ITEM: Gil to propose specific wording around this issue.
[14:15] Gil: Marc: THis issue is taking us back in a very unfortunate
direction. This issue led to MakeConnection in the first place.
[14:15] Gil: ... We had discussed something like this but decided to propose
MakeConnection instead.
[14:15] 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?
[14:15] Gil: ... We don't need to constrain the spec to prohibit the use of
anon. This is going over old ground.
[14:16] Gil: Doug: Agree and second what Marc says. Don't want to see a
normative reference.
[14:16] Gil: Marc: Part of the reason we didn't go down the path of defining
the behavior in these cases
[14:17] Gil: ... is that we couldn't come up with a proposal that covered
all the uses cases. We end up dealing
[14:17] Gil: with transport specific issue. This is better dealt with in
WS-I. We don't need to do anything here.
[14:18] Sanjay: Doug, could you please scribe while Gil talks
[14:18] Dug: oops
[14:18] Dug: Gil: I think the problem here is that MC is not required - so
what does an RM endpoint do in the absence of MC?
[14:18] Dug: ... I think not defining how an RM component is asking for
interop problems.
[14:19] Dug: ... its not a transport. Its a problem with composing with WSA
[14:19] Dug: ... 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.
[14:20] Dug: ... ws-i can't make up specs.
[14:21] Dug: ... 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.
[14:22] Dug: Marc: I don't think new elements/features are needed to solve
this - so ws-i can do this.
[14:22] Dug: Gil: I'm not talking about new protocol elements at all
[14:22] 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
[14:22] Dug: 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.
[14:23] Dug: ... marc - you said we already discussed this - what did you
mean?
[14:23] Dug: Marc: back in March we discussed replay and the TC wanted to
support a broader set of scenarios.
[14:24] Dug: Anish: that was specific to req/res MEP.
[14:24] Dug: Marc: yes - replaying an unacked requested was one way to solve
that particular situation. But the tc wanted to solve more than just that
[14:25] Dug: 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.
[14:25] Dug: Sanjay: clearly we need to discuss this more. Gil's AI might
help focus the discussion.
[14:26] Dug: Sanjay: call adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]