4-20-06 telcon draft minutes

[Christopher B Ferris <chrisfer@us.ibm.com>]

Not as fancy as Tom's minutes, but hopefully accurate
nontheless.

4-20-06 telcon draft minutes

Agenda:

1) Roll Call

Sanjay conducted roll. Meeting is quorate.

Sanjay relates to the TC that he lost the roll for
the previous meeting. Members present on that
call are asked to send a note to Sanjay confirming
their attendance.

2) Review and approval of the agenda

Suggestions to postponing i089. No objections.

3) Approval of the Apr 13, 2006 meeting minutes

Postponed until next week because of the lack of attendance
info.

4) AI Review 
   http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

Action #94: Marc to send in something tomorrow.
Action #97: namespace for new CD. outstanding
Action #99: dougb - still outstanding

5) Recap of TC schedule discussion from Mar F2F - When to stop raising
new issues?
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17492/MinutesWSRX-f2f-032306.html#_Toc131830366
.
Sanjay: Takes about 4 months after we have a CD for
public review. Would like comments/suggestions from TC members.
DougB: don't understand.... freezing issues just means
that people who participate in the comments period do so before the document
goes out for public review.
Sanjay: not my intent. If TC members have issues, we should set deadline
by which they need to have been raised.
That would allow us to schedule 2-3 weeks to resolve
the last remaining issues, etc. Main intent is to ask if we WANT to set
a deadline.
DougB: If someone raises an issue, we wouldn't throw
it away.
Sanjay: when we say "freeze" it is a soft
deadline. Wants to make the TC schedule more predictable. We presently
have 5 issues open,
would it be reasonable within the next 3 weeks that
all the major issues be raised.
Chris: You can't have a deadline for issues unless
you have a stable CD. We are still awaiting a stable CD.
Sanjay: asking for deadline that is not based on a
stable CD.
Chris: putting cart before the horse.
TomR: Let's get a draft we can review.
MarcG: agree, let's get a working draft published.
Sanjay: thinks editors have a draft that all issue
resolutions are incorporated
Gil: that is correct.
Sanjay: requests that editors put that in reviewable
location as soon as possible. We want a predictable
schedule.

6) New issues since last conf-call
   Watch for Marcs email

New issue proposed-01: http://lists.oasis-open.org/archives/ws-rx/200604/msg00041.html
no objections to accepting as new issue

New issue proposed-02: http://lists.oasis-open.org/archives/ws-rx/200604/msg00055.html
Anish: reviews the issue
Chris: notes email sent before the telcon... this
is not an issue
Anish: does the ws-policy spec say how to treat wsp:optional?
Umit: yes
Ashok: yes
Chris: it is documented in the ws-policy spec
Gil: two issues, one is narrow specese how you roll-up
wsp:optional, the second is to do with
semantics, even if we resolve the issue of how this
works, you may not be happy with the results
Anish: what Chris is saying is that is what policy
says. Second issue is the lack of definition
of "parameters"
Sanjay: given that we have no parameters now, isn't
this the more relevant issue?
Anish: yes
Sanjay: any objections as raising this as an issue?
Gil: have to disagree with Chris, it is not clear
to most people how this works.
Anish: another way is not talk about overriding at
all.
Ashok: policy spec uses the word merge, really does
not describe what merge means or does
Sanjay: think that is something we should discuss
when we get to the end of the issue
Chris: it is not the TC's job to clarify the ws-policy
specs
Bob: trying to ask chairs if they would clarify the
portion of the charter as relates to referenced
specifications that are at some level, that we have
to deal with them abstractly. wouldn't that moot the
question?
Sanjay: good point. Charter says something like the
referenced specs should be sufficiently advanced
before the spec goes final. Think that abstracting
out all of policy would be working backwards
Bob: think it would help us move on
Umit: tend to agree with Chris. These concepts are
not specific to the WS-RX TC. However, if there
is a section of the spec which is not clear, it is
good feedback to the ws-policy spec. Wouldn't
find that time wasted. Agree that trying to solve
the generality problem may not lead us anywhere.
We should not try to solve another framework's problems
in this TC.
Anish: it is within the scope to describe the behavior
we would like. What is important is what we would
like. In interest of moving forward, we can narrow
the issue to the specific text that deals with
"parameters". I will review the relevant
specs and try to see what Chris is seeing.
MarcG: are you withdrawing the issue and submitting
a new one?
Anish: splitting it
MarcG: want to know what the issue is for the issues
list
Anish: issue is the narrower issue about the "parameters"
text
Sanjay: clarifies
Anish: either way, just delays it one week
Sanjay: would be clearer if we had two issues

New AI: Anish to send revised issue dealing specifically
with the "parameters" text

no other new issues

7) Issue Discussion:
a> i114  Figure 2 (cd3) is out of date with the changes to the
protocol 
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i114


Chris: reviews the issue and the proposal (which is
actually this message:
        http://lists.oasis-open.org/archives/ws-rx/200604/msg00028.html)
Sanjay: can we wait until we have proposal that covers
the Close() before resolving this?
MarcG: also discuss the surrounding text
Chris: will include that as well as new diagram that
includes Close() operation

b> i089  suggest the restricted use of anonymous URI
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089


Deferred

c> i106  SequenceAcknowledgement:Final assumption of deliverability
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i106


Sanjay: Bob, you had asked that this be deferred?
Bob: yes, would prefer that we move on to i115 and
we can have discussion of this
issue if there is time.

d> i115  "must understand" attribute for extensions to
RM components 
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i115
8) Any other business
Sanjay: Gil, please desccribe issue
Gil: we have extensibility points on
all our lifecycle operations and headers, etc. but we don't say what an

RMS or RMD should do when it sees an
extension point used that it doesn't understand. We need to say what happens.
There may be cases where an extension
is important and if we don't have rules, then we are up a creek. early
feedback
on the proposal. Some are confused that
I am creating a mU in wsrm namespace. New attribute that can be applied
to extension
elements that can be used to indicate
to another endpoint when an extension is needed.
Chris: very much opposed to this.<rants/>.
very much opposed to this.
MarcG: it was pointed out in the chat
that there is a line in the spec that says that extensions SHOULD be ignored,
so it is
currently addressed.
Umit: take me off the queue. was going
to ask what the mental model was. Chris confirmed understanding as to what
was
being proposed.
Gil: Sympathy for Chris's point of view.
the problems of all the other specs in the world are not our problem. wish
there
was a SOAPwide or Schema-wide equivalent
to soap:mU. Suppose RMS wants to indicate that some security extension
MUST be understood. How can RMS indicate
to RMD that it MUST NOT ignore. Shame that we have to do it specific to
RM.
Will suck if every spec has to do this.
Sanjay: Clarification. The attribute
you are proposing, would that appear on the current headers we have defined
or on the
extension elements themselves?
Gil: doesn't understand the question.
Don't intend it to apply to any of the elements in the spec. This attribute
is designed
for the extension elements.
DougB: could have achieved the same
effect if you indicate the same thing in a separate SOAP header.
Anish: for every extensibility, you
would have to create a separate SOAP header?
DougB: yes
Umit: agrees with DougB. Can look at
this as two parties expressing their capabilities to eachother. Gil's approach
is one
way. Another way is to send expression
of capabilities. Are you asking if this is a problem? Or to agree on this
particular
solution.
Gil: the proposal is putting forward
a particular solution. What Doug says is true. We can inser SOAP headers
and mark with
mU. Seems to be a messy solution to
stick in all these other SOAP headers. It is a kludge.
Chris: +1 DougB and Umit. SOAP mU is
not a kludge. It is fundamental to everything we are doing in Web services.
More ranting.
DaveO: Take the STR in the CS. had a
specific semantics. The fact that it is done as an extension, demonstrates
that people
will want to extend the protocol. Could
have used the SOAP mU, but didn't. There are reasons why you want to do
that. The nice
thing about the STR decorated with the
wsrm:mU is that the processor doesn't have to troll through the message
to see what is there.
We could have an explosion of dependencies.
We could have to track all the dependencies. This way, you say you are
extending
the CS and things are nicely connected
together. A number of people have championed the SOAP mU model. we don't
think
precludes us from defining a WSRM specific
mU model.
MarcG: in the contributed spec, the
STR was not just taking advantage of an extensibility point, it was specified
with a MUST. I don't 
see using that as an argument that you
need a new attribute you can attach to anything you want to. Concerns me
that this could
get nested and don't like the potential
for how this will get used. Think the spec is already clear that you can
ignore the extensibility
points. Suggest we close with no action.
Chris: DaveO said you have to troll
through the message. Disagree.
DaveO when you get the CS, you don't

Chris: the STR is still in the CS
DaveO: you have to point back into it.
have to come up with my own RMMustUnderstandFoo. ad nauseum. this will
by value or
by reference point back into the message.

back and forth between DaveO and Chris

Gil: with regards to sprinkling, would
not have problem with indicating that the wsrm:mU can only be applied at
the
top-level element of an element that
extends say a CreateSequence. That it can not be arbitrarily nested. Has
to be at the top
level, Perhaps that will address the
"sprinkling" talk. Although the contents of the SOAP header does
not have to refer to the
extension using xpath, there is an explicit
relationship with the context. Seems to me that there is a relationship
between
how you extend and how you mark it as
required. Would need some sort of relationship language. Need to be able
to assert
which particular extension I am talking
about.
DaveO: exactly this issue of combinatorial
extension. Don't want to end up having to create three headers for E1,
E2 and E3.
Simpler to do this in the context of
where they are used. We have always talked about how all these WS-* specs
are well
factored and composable. Think that
the CS/STR was underspecified. TC removed that. Want to point out that
there
are other aspects of the SOAP process
model. roles, etc. This isn't taking the entire SOAP process model. It
is taking a 
small portion and applying in a specific
context. The composability we haven't proven yet.
Chris: don't think it scales
MarcG: +1
Umit: +1. has concerns with composability,
Seems attractive, but if you put a lot of these in the protocol, who uses
the new marker?
RM, TX, Security? Who decides the mU?
As you increase the composition, it becomes less clear who/what is responsible
for
making the determination.
Anish: don't understand that
Gil: don't understand
Umit: not asking a question, making
a statement. SOAP mU is falt. There is no composition problem.
Gil: that seems completely backwards
to me.
DaveO: you can do like security specs
and make non-backwards compatible, requiring all extensions MUST be 
understood. Seems like the ideas that
Umit mentioned would create the same sorts of problems. we cannot propose
an
uber solution. we need something specific
to RM. maybe it will get refactored, just because there is a general problem
and not a general way to solve it shold
not preclude the TC solving the problem
Sanjay: adjourned.

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295