| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]
Subject: 4-20-06 telcon draft minutes
- From: Christopher B Ferris <email@example.com>
- To: WS-RX TC <WS-RX_TC@us.ibm.com>
- Date: Thu, 20 Apr 2006 17:33:36 -0400
Not as fancy as Tom's minutes, but hopefully accurate
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
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
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
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
DougB: If someone raises an issue, we wouldn't throw
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
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?
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
Sanjay: given that we have no parameters now, isn't
this the more relevant issue?
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
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
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
Anish: issue is the narrower issue about the "parameters"
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
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
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
on the proposal. Some are confused that
I am creating a mU in wsrm namespace. New attribute that can be applied
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
Umit: take me off the queue. was going
to ask what the mental model was. Chris confirmed understanding as to what
Gil: Sympathy for Chris's point of view.
the problems of all the other specs in the world are not our problem. wish
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
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
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?
Umit: agrees with DougB. Can look at
this as two parties expressing their capabilities to eachother. Gil's approach
way. Another way is to send expression
of capabilities. Are you asking if this is a problem? Or to agree on this
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.
DaveO: Take the STR in the CS. had a
specific semantics. The fact that it is done as an extension, demonstrates
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
the CS and things are nicely connected
together. A number of people have championed the SOAP mU model. we don't
precludes us from defining a WSRM specific
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
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
how you extend and how you mark it as
required. Would need some sort of relationship language. Need to be able
which particular extension I am talking
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
factored and composable. Think that
the CS/STR was underspecified. TC removed that. Want to point out that
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
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
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
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
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
STSM, Software Group Standards Strategy
phone: +1 508 377 9295
| [Thread Prev]
| [Thread Next]
| [Date Next]
| [Thread Index]
| [List Home]