OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 4-20-06 telcon draft minutes

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

4-20-06 telcon draft minutes


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

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?

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

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
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

Chris: reviews the issue and the proposal (which is actually this message:
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


c> i106  SequenceAcknowledgement:Final assumption of deliverability

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
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
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.


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]