today's conf call - raw notes

[Doug Davis <dug@us.ibm.com>]

For those who want to see the raw notes
from today's call:

[15: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 
[15:59] Steve Carter: I'm not hearing much
on the bridge
[16:01] Dug: brb - calling the operator
[16:04] TomRutt: i hear a low level crackle
on the bridge
[16:04] Martin: is everyone getting silence?
[16:04] Gil: nope
[16:04] Gil: anything but
[16:05] Dug: operator isn't answering my request,
still trying....
[16:06] Gil: SCRIBE: Gil
[16:06] Gil: TOPIC: Agenda
[16:06] Gil: MarcG: Would like to discuss the
status of the issue list.
[16:07] Gil: Sanjay: We'll add it to the agenda
after (5)
[16:07] Gil: TOPIC: Minutes
[16:08] TomRutt: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21859/MinutesWSRX-011107.htm
[16:09] Gil: RESOLUTION: minutes approved
[16:09] Gil: TOPIC: AI review
[16:10] Gil: Sanjay: AI117 - Marc Goodner
[16:10] Gil: MarcG: (done)
[16:10] MrGoodner: Issue link: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml
[16:10] Gil: Sanjay: Close AI #117
[16:11] Gil: Sanjay: AI #114 - Chris is not
on the call and I haven't seen any activity
[16:11] Matt Lovett: http://www.oasis-open.org/archives/ws-rx/200701/msg00055.html
[16:11] Gil: ... AI #125 - Matt Lovett
[16:11] Gil: Matt: done - follow up later in
call
[16:11] Gil: Sanjay: Close AI #126
[16:12] Gil: ...: Gil completed AI #126 - close
it
[16:12] Gil: TOPIC: New Issues
[16:12] Gil: MarcG: One new issue from Gil
- related to AI #126. Its PR038
[16:12] Gil: Sanjay: Not a whole lot to talk
about
[16:13] Gil: Sanjay: Issue accepted.
[16:13] Gil: TOPIC: Issue List Status
[16:13] Gil: MarcG: Most issues that were pending
are now in review.
[16:13] Dug: FYI - all but 007 are in the spec
[16:13] Gil: ... Next update will probably
move everything over to review.
[16:14] Gil: ... We need to start reviewing
so we can mark the issues as closed.
[16:14] Gil: Doug: All issues except PR007
are in the spec.
[16:14] Gil: ... The main TC's document list
has the latest version.
[16: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
[16: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
[16:15] Gil: Doug: That's correct
[16:15] MrGoodner: Latest MC: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/21705/wsmc-1.0-spec-wd-01.pdf
[16: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
[16:15] Gil I love joint scribbing
[16:16] Gil: TOPIC: PR035
[16:18] Gil: Sanjay: Let's timebox this discussion
to 25 minutes
[16:18] Gil: Matt: This is my attempt at wordsmithing
what Chris said last week.
[16:18] Gil: ... Everyone knows what you mean
but the phrasing is tricky.
[16:19] Gil: ... Phrase "process to conclusion"
is causing some difficulties.
[16:19] Gil: ... Peter Niblett thinks people
are looking for an "end-to-end" view of what is going to happen
to the messages.
[16:20] Gil: Jacques: Overall adding DA definitions
is a very good idea for "users" (IT people that are responsible
for implementing business functionality).
[16:21] Gil: ... RMS and RMS are not necessarily
required to implement these DAs, but we need a common definition of what
they mean.
[16: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)
[16:21] Gil: ... We keep talking about "delivery
assurances" and "delivery" in the abstract.
[16:21] Matt Lovett: Doug: I'd appreciate that
- I don;t have my work email here
[16: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.
[16:22] Gil: ... "Delivery" is a
contract. We should use the word "delivery" and "deliver"
in these definitions.
[16:22] Gil: ... That would help those areas
where "process to conclusion" is causing problems.
[16:23] Gil: ... Rest of my comments are more
about the details of Matt's wording.
[16:23] Iwasa: Sanjay, Could you add me on
the roll? I've just joined the call.
[16:23] Sanjay: Added Iwasa to the roll.
[16:23] Iwasa: Thank you, Sanjay.
[16:24] Gil: ... Some problems in the area
of "At Most Once" messages being delivered simply because they
haven't been acknowledged.
[16:24] Gil: Sanjay: Matt, could you work with
Peter and Jacques to update your definitions.
[16:25] Gil: RESOLUTION: AI #126 remains open
[16:26] Gil: Sanjay: PR009 and PR020 are both
related to DA's so lets skip them.
[16:27] Gil: TOPIC: PR0037
[16:27] Gil: Ashok: (reviews status of PR0037)
[16:27] Dug: I think this is Ashok's latest
proposal:  http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00057.html
[16:27] Gil: ... I've tried to create 3 different
style of the RMAssertion
[16:27] Gil: ... First is the RMAssertion like
it was on its own.
[16:28] Gil: ... Second is with the security
token nested within it
[16:28] Gil: ... Third is with the security
transport token nested within it - including the transport binding assertion.
[16:29] Gil: ... What we want to spell out
is that somewhere with the policy you must define the security tranport
policy.
[16:29] Gil: MarcG: On the requirement that
you must that the transport binding included.
[16:30] Gil: ... When you first brought this
up you had concerns about pullin in bits of policy from different domains.
[16:30] Gil: ... Are you still concerned with
this?
[16:30] Gil: Ashok: I think this is ok.
[16:31] Gil: MarcG: What we intended from the
original statement was that the SequenceTransportSecurity assertion is
not a substitute for sp:TransportBinding
[16:31] Gil: Ashok: The wording there is currently
a bit skimpy, but still correct.
[16:32] Gil: Sanjay: In section 2.5.2 it still
says "This assertion is effectively meaningless . . ."
[16:32] Gil: Ashok: That should be removed.
[16:32] Gil: MarcG: I'm not seeing wsp

ptional
on these. Is that intentional?
[16:33] Gil: Ashok: Yes. If you use "wsp

ptional",
after normalization, you will end up with policy alternatives that don't
have the assertion.
[16:33] Gil: ... If you want that policy you
should just use it.
[16:34] Gil: MarcG: But don't you need an additional
wsp

olicy
if you are nesting policies?
[16:34] Gil: Ashok: WS-Policy is still working
on that, but not currently.
[16:34] rsalz: We can/should consider that
an editorial matter.
[16:34] Dug: +1 Marc
[16:35] Gil: MarcG: (notes most policy experts
are at WS-Policy F2F) We need to give people more time to review this proposal.
[16:35] Gil: TOPIC: PR001
[16:36] Gil: Sanjay: Doug suggested we separate
MC into its own spec. We agreed to this on the concall of (???)
[16:36] Gil: Doug: (reviews status of MC spec)
[16:36] Gil: ... People should review the MC
spec and raise issues as needed.
[16:37] Gil: ... Left an open section to define
WS-Policy assertions for MC.
[16:37] Gil: Sanjay: The set of issues that
were open against MakeConnection text have be re-assigned to MakeConnection
spec.
[16:37] Gil: ... Need to review MC issues.
[16: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.
[16:39] Gil: Doug: Moves to close with no action:
[16:39] Gil: Gil: Seconds
[16:39] Gil: Anish: This issue was filed by
WS-Addressing working group?
[16:39] Gil: Doug: Yes
[16:39] Gil: Anish: We should email them about
the resolution.
[16:40] Gil: Sanjay: For all PR issues, Marc
is planning on communicating the dispensation of those issues to whomever
raised them.
[16:41] Gil: RESOLUTION: Proposal to close
with no action passes by unanimous consent.
[16:41] Gil yeah
[16:41] Gil: TOPIC: PR0015
[16:41] Gil: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i015
[16:42] Gil: Doug: (reviews issue)
[16:42] Gil: ... Hoping that what then meant
is that there is no way to tell wether the RMD supports polling for messages.
[16:42] Gil: ... Think that the direction to
go is with a WS-Policy assertion.
[16:42] Gil: Marc: Yeah
[16:42] Gil: Anish: Good idea.
[16:42] Gil: +1
[16:43] Gil: ACTION ITEM: Doug to define WS-Policy
assertion for MC so that a service can advertise that it supports MC.
[16:43] Gil: TOPIC: PR028
[16:43] Gil: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i028
[16:43] Gil: Doug: (reviews issue)
[16:44] Gil: ... Seems a bit like a duplicate
of PR0015
[16:45] Gil: ... Can't tell if there is more
to it than that.
[16: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."
[16:45] Gil: Anish: Wondering if Jonathan meant
something that happens during sequence establishment?
[16: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.
[16: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.
[16:46] Gil: ... Similar to the way in which
wsa:anon and wsa:none are used.
[16:47] Gil: Marc: Jonathan mentioned something
 about the example?
[16:47] Gil: Doug: (reads part of above)
[16:47] Gil: ... Don't know why this would
be true.
[16:48] Gil: ... I don't really agree with
his assertion.
[16:48] Gil: ... Move that we close this as
a duplicate of PR0015
[16:48] Gil: Matt: (seconds)
[16:49] Gil: RESOLUTION: Motion passes by unanimous
consent.
[16:49] Gil: TOPIC: PR0029
[16:49] Gil: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i029
[16:49] Gil: Doug: (reviews issue)
[16:50] Gil: ... Mostly about the use of UUIDs
in the MC anon URI.
[16:51] Gil: ... Maybe we can address this
concerns by saying that the client needs to use "something unique"
instead of requiring a UUID?
[16: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
[16:52] Gil: ... opaqueness arguements.
[16:53] Gil: Stefan: At one point we differentetiaed
the poller using an endpoint parameter. I'm not sure why we stopped doing
that.
[16:53] Gil: ... The other thing is we should
consider using a URI scheme.
[16:53] Gil: Doug: You are talking about reference
parameters?
[16:53] Gil: Stefan: Yes.
[16:54] Gil: Doug: That would required receievers
of these URIs to crack open the ERP and examine the reference parameters.
[16:54] Gil: ... Its also a touchy subject
for some members of WS-Addresssing
[16: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
[16:55] Gil: ... of overhead with this apporach.
[16:55] Gil: Anish: Using reference parameters
is tricky for another reason. What if there are multiple reference paramters
and only one of them
[16:56] Gil: ... is the one we define? Do the
other parameters figure into the equation.
[16:56] Gil: ... A new URI scheme is feasible,
but you need to be cautious.
[16:56] Gil: ... If an existing scheme can
be used you should do that.
[16: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?\
[16:57] Gil: I'm for it.
[16:57] Gil: Anish: Would you specify what
uniqueness means? Is it a string comparison or something more?
[16:58] Gil: Doug: Was assuming it meant a
string comparison.
[16:58] Gil: ... Text would say that it needs
to be globally unique but we wouldn't specify an exact mechanism.
[16:58] Gil: ACTION ITEM: Doug to propose specific
text to relax restriction on MS anon URI template.
[16:59] Gil: TOPIC: PR030
[16:59] Gil: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i030
[16:59] Gil: Doug: (reviews the issue)
[17:00] Gil: ... Now that MC is in its own
spec, this issue should go away.
[17:00] Gil: ... If we try to limit it to WS-RM
only, we kill its usefullness.
[17:01] Gil: Matt: To say that the returned
message must "relate to WS-RM" is asking for trouble.
[17:01] Gil: Doug: Moves to close no action.
[17:01] Gil: Anish: (seconds)
[17:01] Gil: RESOLUTION: Motion passes by unanimous
consent.
[17:02] Gil: TOPIC: PR031
[17:02] Gil: http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i031
[17:03] Gil: RESOLUTION: PR031 closed with
no action by unanimous consent
[17:03] Gil: (PR030 and PR031 were mixed up
due to crossed message links)
[17:03] Gil: TOPIC: PR030
[17: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."
[17:05] Gil: Gil: Think this issue is covered
by the AI for PR0015
[17:06] Gil: Matt: Agree with Gil. Resolution
to PR0015 covers this issue.
[17:07] Gil: Doug: Moves to close this issue
as a dup of PR0015
[17:07] Gil: Matt: (seconds)
[17:07] Gil: RESOLUTION: Motion passes by unanimous
consent.
[17:08] Gil: Sanjay: Out of agenda items, so
lets discuss the new issue.
[17:08] Dug: TOPIC: New issue from Gil: 38
[17:09] Dug: Gil: need clarity on how base
spec references MC spce
[17:09] Dug: ... normative ref, elude to MC-like
features?
[17:09] Dug: ...normative would tie the two
specs together (timeline)
[17:10] Dug: ... non-normative ref could lead
to tricky wording
[17:10] Gil: Jacques: We would like to see
an implementation of the main spec is conforming without MC
[17:11] Dug: s/spce/spec/
[17:11] Gil: ... Use of MC should not be required
to conform to base WS-RM
[17:12] Dug: Gil: MC has always been optional
even when it was in RM spec
[17:12] Dug: ... even if MC is optional we
could have a normative ref to it.
[17:13] Dug: ... issues of normative/non-norm
and optionality are orthogonal
[17:13] Dug: ... what should an RM endpoint
do in the absence of MC
[17:13] Gil: Ashok: I agree with that.
[17:14] Gil: Doug: Gil you seem to have a particular
direction in mind. Could you come up with a sepific proposal?
[17:14] Gil: ACTION ITEM: Gil to propose specific
wording around this issue.
[17:15] Gil: Marc: THis issue is taking us
back in a very unfortunate direction. This issue led to MakeConnection
in the first place.
[17:15] Gil: ... We had discussed something
like this but decided to propose MakeConnection instead.
[17: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?
[17:15] Gil: ... We don't need to constrain
the spec to prohibit the use of anon. This is going over old ground.
[17:16] Gil: Doug: Agree and second what Marc
says. Don't want to see a normative reference.
[17:16] Gil: Marc: Part of the reason we didn't
go down the path of defining the behavior in these cases
[17:17] Gil: ... is that we couldn't come up
with a proposal that covered all the uses cases. We end up dealing
[17:17] Gil: with transport specific issue.
This is better dealt with in WS-I. We don't need to do anything here.
[17:18] Sanjay: Doug, could you please scribe
while Gil talks
[17:18] Dug: oops
[17: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?
[17:18] Dug: ... I think not defining how an
RM component is asking for interop problems.
[17:19] Dug: ... its not a transport. Its a
problem with composing with WSA
[17: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.
[17:20] Dug: ... ws-i can't make up specs.
[17: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.
[17:22] Dug: Marc: I don't think new elements/features
are needed to solve this - so ws-i can do this.
[17:22] Dug: Gil: I'm not talking about new
protocol elements at all
[17: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
[17: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.
[17:23] Dug: ... marc - you said we already
discussed this - what did you mean?
[17:23] Dug: Marc: back in March we discussed
replay and the TC wanted to support a broader set of scenarios.
[17:24] Dug: Anish: that was specific to req/res
MEP.
[17: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
[17: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.
[17:25] Dug: Sanjay: clearly we need to discuss
this more.  Gil's AI might help focus the discussion.
[17:26] Dug: Sanjay: call adjourned