Minutes
<TomRutt>
Sorry, my other meeting is going to go past 4m, so I cannot take minutes today
<TomRutt>
I posted last week's minutes (adding the role) on the server yesterday
agenda
Bob:
Haven't made a proposal on the "back-channel" issue but I have some ideas to discuss
DougD:
No proposal, but we have somethine we'd like to discuss
Resolution: Agenda approved
previous minutes
Resolution: previous minutes accepted by TC
Action Items
PaulF:
Last weeks AI's haven't been added but we can catch up . . .
TC Schedule
PaulF:
We have a number of issues. We have a deadline for getting them all closed by the end of next weeks call.
... but we've had very little discussion on the mailing list. Urge TC members to try and resolve issues on the mailing list.
DougD:
The issue's have owners. Perhaps we can twist their arms ?
PaulF:
Certainly. Or we could go through all the issues and get their owners to commit to doing something about them.
bob ouch, enough already!
MarcG:
Was there any discussion of the items that need to be moved to review status?
... We had a discussion on the Editor's list. People may not be aware that there is a new draft in progress that has a lot of
resolved issues applied to it.
New issues
Scan issues list
MarcG:
PR001 does not have an owner.
PR007: owned by Gil
chris notes that now he no longer has to leave early
Action: Stefan to put together concrete objections to Gil's strawman on PR007
<TomRutt>
I just updated the action item list from last week minutes
(sorry I dropped and missed the last bunch of issues)
PaulF:
Everybody who owns an issue needs to provide a summary of what needs to be decided
MarcG:
Would appreciate if people provide links to current proposals
PR Issues
MarcG:
Can we point out that the pending issues have all been applied to the latest draft?
PaulF:
Has that been sent to the TC?
PaulF:
(directs members of the TCs to review the latest draft)
MarcG:
Some discrepancies between issue list and latest draft (around PR011)
PR012
MarcG:
This is about anonymous and AcksTo EPR scenarios. It seems that we've come to consensus that PR012 and PR013 are so closely
related that they are virtually the same issue.
PaulF:
The issues is that when someone does an AckRequest to an anonymous AcksTo its clear that the ack has to flow on a back-channel.
The issue is with the timing of that ack.
... My proposal makes it clear that the ack has to go back on the back-channel corresponding to the AckRequest
MarcG:
My proposal basically clarifies but doesn't get too specific about the details on how this works over HTTP.
... The current text goes as far as we should go to specify this mapping.
Jacques:
I don't think we're out of scope by specifying doing what Paul suggested (e.g. tightening the restriction on which back-channel
the ack should flow on).
... We shouldn't confuse the use of the back-channel with protocol binding details.
... We can discuss the use of the back-channel without diving into the details of protocol-specific bindings.
... We're on the edge of our scope, but within it.
... As long as theses issues are addresses somewhere I would be happy and so would the author of this issue
... I'm not opposed to closing with no action, but I think Paul's proposal makes sense.
... Editorial note: the wording of [missed it] is convoluted.
... I have a slight preference for Paul's proposal, but as long as this concern can be handled somewhere [WS-I?], I'm ok.
PaulF:
My proposal doesn't mention HTTP specifically. I'd ask Marc why he thinks this goes too far?
MarcG:
(yields to Stefan)
Stefan:
The spec doesn't preclude doing something more restrictive, but the spec itself isn't the best place to put these restrictions.
... There is also a discrepancy between the mail discussion (SHOULD) and Paul's explanation (MUST)
PaulF:
That should be a SHOULD
Stefan:
I prefer close with no action, but I can live with SHOULD.
PaulF:
I don't think it will substantially harm the spec if we don't have this restriction, but I think we should be tight about
interop.
Gil:
(calls the question)
<Jacques>
I am OK with a SHOULD - probably more is needed outside the spec later to nail down possible interop snags
PaulC:
If we do a preference poll it sounds like we'll be evenly divided an no further along.
ChrisF:
You can't propose that we do 'A' or 'B'
Gil:
(moves that we accept PaulF's proposal)
Resolution: Motion passes by unanimous consent.
DougD:
"binding specific channel" or "binding specific back-channel"?
PR033
Bob:
I've been researching the use of the term "back-channel"
... It seems to be used mostly to refer to some degraded, sub-channel that does not interfere with the primary channel.
... But that's not how we use it.
<bob>
Backchannel - The term Backchannel as used in this specification means a transport binding specific facility that has the
capability of returning a soap body without creating a new connection
Jacques:
Bob's definition may need to be extended to make it clear that the back-channel is associated with another message. That's
the way we use it all over our spec.
PaulF:
Was working with Danish Gov to do interop between Axis+Sandesha and .NET using SMTP as a transport. Bob's definition wouldn't
work with this scenario.
Stefan:
WHat's a connection in SMTP?
ChrisF:
Sounds like they are doing asynch [missed rest]
Bob:
There is no mapping of anonymous to ReplyTO in the email binding.
... It's not an anonymous reply in that case.
ChrisF:
This doesn't sound like 'anonymous'
PaulF:
Another example: JMS
... Typically reply to a temporary queue set up for replies.
... This def doesn't seem to capture some of those semantics.
Bob:
Important factor is the fact that you don't have to create a new connection.
... MakeConnection is motivated by the fact that you have scenarios where you can only connect in one direction.
... If you simply state that something is an implicit address that doesn't necessarily map to the things that motivate MakeConnection.
ChrisF:
(reads definition of WS-A's anonymous) There is no mention of 'back-channel' in WS-Addr.
Bob:
True. We've been through this.
ChrisF:
Looking in SOAP binding . . .
... You won't find it there.
ChrisF:
So why don't we use their terms?
Bob:
WS-Addr, SOAP, et. al. language doesn't map well to the scenarios we are concerned about.
ChrisF:
Seems like we need to tighten up our language.
Bob and ChrisF: (back an forth about MEPs, transport level MEPs, application level MEPs, the difference between, etc.)
PaulF:
Sounds like this is something that should be resolved on the mailing list.
Action: Bob and Chris to propose language for PR033
PR001
DougD:
Looking for a way to move forward. Concerns that WS-RM will be impacted if we drag this issue out any longer.
... If you look what's currently in the spec, the functionality is somewhat orthogonal to WS-RM.
... It's layered on top of WS-RM to provide the functionality we need.
... In order to move the WS-RM spec forward, I wanted to propose to take Section 10 (and associated stuff) and move it into its
own specification.
... This spec would still be part of the TC's work (for purposes of charter, scope, etc.)
... We don't want to hold up the main portion of the WS-RM spec.
... Allows "main" WS-RM to move forward at its own pace. Allows MakeConnection scenario, issues, etc. to move at their own pace.
MarcG:
I support this notion.
... We need to deliver WS-RM and I don't see a problem with tackling MC later.
Jacques:
I agree that we can move the spec forward without the MakeConnection functionality.
... By splitting it makes MakeConnection appear even more general than it is today.
... MakeConnection will still be confined by the charter of this TC, although it "appears to be" general.
... Do the authors of this proposal think that the MakeConnection spec will become a completely independent entity? Or is it
a guidelin, or adjunct?
DougD:
It would be a spec by itself the same way that WS-RM Policy is its own spec. Nothing changes in this regard.
PaulF:
I'm concerned by this. I've been out with a bunch of customers all trying to use WS-RM. They all want to use WS-RM in the
anonymous case. They keep beating me up that Sandesha/WS-RM don't support this scenario very well. I'm worried that this split
will cause the solution to their problems to be delayed.
DougD:
I can understand your concerns but I don't understand how splitting changes anything.
... Core of WS-RM is about moving messages from point A to point B. The MakeConnection stuff is all about "how do you do this
in this particular case"? [refering to reliable responses over the HTTP back-channel]
PaulF:
Put that way, I think you are making a good point. Makes it easier to explain this to our customers.
... Even we had a draft to point to to say "this is where we are addressing this problem"
<umit>
what is the normativeness of this proposal in conjunction with the RM spec?
DougD:
I consider the core specification to be a primary concern. I note the example set by WS-TX.
... Hopefully MakeConnection won't be too far behind.
ChrisF:
I don't think this changes anything with the regards to the importance of MakeConnection.
... We're pretty close with the main WS-RM spec. This is the single, last, gnarly issue.
... It has the potential to disrupt the entire process. A radically new approach to MC would require a new, 60 day review period.
... Thus putting the whole spec in jepardy.
... We obviously think MC is important, but its more important to get the main spec done.
... We're not even close on consensus around PR001. We should focus on getting the core WS-RM and WS-RM Policy specs done and
out.
Stefan:
+1 We've all got pressure from out customers to get WS-RM out.
<Martin>
i put my self on q before stefan
Martin:
I'm against splitting. I think that as soon as you split MC off and it has its own lifespan, people are going to want more
and more generic things added.
... Composability will go out the window.
... The idea that separate specs can compose well is an illusion. If you want something to compose you need to do it in the same
spec.
Bob:
When we look at composability, it looks like MC is needed by a number of things [WS-SC for example]
... I think it makes sense to identify MC as a separate facility with its own namespace so it can be composed with other facilities
without confusion.
... But I am concerned that MC is starting to look like some new transport shim between HTTP and SOAP.
DougD:
That last bit seems to be a issue against MC in general and not a critique of splitting the specs.
Bob:
[scribe fell behind]
... MC should be typified as being a lower-level facitlity than it currently appears as part of the WS-RM spec.
Umit:
You're taking out an interop requirement around MC in the WS-RM spec
<Martin>
bob said it all, if u separate you need to generalise thefore it will take ages to complete
... Implementers of WS-RM will not be required to use MC in an interoperable way.
DougD:
It was always an optional feature. You could implement WS-RM without supporting MC.
Umit:
How are you going to refer to MC from the WS-RM spec?
DougD:
I'm leaning towards having the WS-RM spec say nothing at all about MC.
... WS-RM may not point to MC, but MC will probably point to WS-RM. Not sure about the strength of the linkages.
... TC will have to decide. If we adopted the Microsoft proposal, there would have to be a fairly tight connection because that's
the way the mechanism works. If we take Bob's route of making MC more general, the linkage might not be so tight.
<Martin>
we dont have the charter to generalize MC
Umit:
If MC is completely separate and optional, there will be a lot of variability in implementations and this hurts interop.
Jacques:
I understand the overall intent here but the assumption that MC can be cleanly separated seems doubtful.
<umit>
Martin, that is my concern.
... Today the RMD must understand MC feature (its sender-optional).
... If you split this feature, we will have conforming RMDs that don't understand MC. You can't add support for MC in a dynamic
way that won't effect the RMD.
... Can't see how the RMD could escape being effected by the support/non-support of MC.
<Martin>
if we spilt we should get both to committe spec before going for oasis standard
... SHould the TC move to pospone the MC case, we still need some sort of solution for two-way reliability for non-addressable
clients.
PaulC:
Some people have suggested that putting functional material in a single document is a way of forcing people to implement
it. The two have nothing to do with each other.
<Jacques>
Martin: +1. I take this proposal not as a claim at more generality, but as a tactical way to get core RM spec out asap...
... People will implement functionality or not as it meets the needs of their customers regardless of how you organize the documents.
... We have a large number of customers that want MC, but we have a much larger number of customers that want the basics of realiable
messaging. I think Doug's suggestion is a very pragmatic way of moving past the current statelmate.
Martin:
I agree with Paul that the document structure doesn't matter. But when people see another spec
... they will view it as a more general solution and we'll lose the connection to solving specifi WS-RM problems.
... Keeping MC in the same spec will constrain the scope to WS-RM concerns and keep us from drifting into fairy-land.
... COuld do 2 specs, but keep them bound together.
ChrisF:
Agree with PaulC.
<Stefan>
The TC could require that interop scenarios for MC required composition with RM no?
... MC is stil important. But we still don't have consensus around how MC should work.
... As far as charter and scope-creep, we are in control over our own destiny.
... Customers have been waiting for this for a long time, particularly the asynch case.
... The sooner we can get that functionality through the OASIS process, the better for everybody.
... PaulF has been working with the government in Denmark.
<Martin>
we dont have to rush to oasis standard for the sake of it
... Clearly this is important to a number of customers. We're just putting the two efforts on separate tracks and allowing them
to proceed on their own merits.
... I think the idea of publishing the MC as a PR or some such at the same time we publish the CDs for WS-RM and WS-RM Policy
is a good idea. It shows everyone that we
are actively working on the problem.
... Noone has been pushing MC harder than IBM, but we think its important to allow the core to proceed.
PaulF:
I think its important that the proposers of this idea come up with a very clear definition of what the new spec will be.
... We started with a very clear idea of what WS-RM and WS-RM Policy would be, because we started from the submissions specs.
... I'm hearind radically different ideas of what the MC doc would be from Bob and Doug.
PaulC:
What is the bar you are setting here?
PaulF:
Would like to see a charter for this new spec.
DougD:
We already have a charter.
PaulF:
Not talking about a group charter, but a description of what the MC doc will be.
Martin:
If we split do we just have to satisfy current PR comments or does it go to another PR.
PaulF:
I'm looking for a bit more here.
DougD:
If we came up with a psuedo-charter, doesn't that imply that the charter of the MC doc differs from the charter of the TC?
That's something we are delierately avoiding.
PaulF:
It could be a subset.
<bob>
gil, I will format and post the minutes
MOTION TO ADJORN ACCEPTED
<umit>
Gil, you are a good scribe.
Schreiber diagnostics output
[Delete this section before publishing the minutes]
citation-detection-scribed: Line 64: Check for possible unrecognized nick 'PR007'
citation-detection-scribed: Line 74: Check for possible unrecognized nick 'PR012 and PR013'
citation-detection-scribed: Line 76: Check for possible unrecognized nick 'PR015'
citation-detection-scribed: Line 78: Check for possible unrecognized nick 'PR018'
citation-detection-scribed: Line 80: Check for possible unrecognized nick 'PR009'
citation-detection-scribed: Line 82: Check for possible unrecognized nick 'PR020'
citation-detection-scribed: Line 84: Check for possible unrecognized nick 'PR021'
citation-detection-scribed: Line 86: Check for possible unrecognized nick 'PR022'
citation-detection-scribed: Line 88: Check for possible unrecognized nick 'PR026 and PR027'
citation-detection-scribed: Line 90: Check for possible unrecognized nick 'PR028 - PR31'
citation-detection-scribed: Line 236: Check for possible unrecognized nick 'Bob and ChrisF'
statistics: Schreiber found 218 input lines
edits: Schreiber found the following text-edit commands:
edits: Line 28: bob: s/UC/TC
command-scribe: Line 8: Gil is a nick for Gilbert Pilz who will be named as scribe
command-scribe: Schreiber detected that this section was scribed online
edit-substitute: command on line 28 succeeded, changed line 24 from 'UC' to 'TC'
edit-delete: Line 28 was deleted
system: Transformer: SAXON SA 8.8
[End of Schreiber diagnostic output]