4-20-06 telcon draft minutes

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: 

blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440

phone: +1 508 377 9295