<mnot> Scribe: vikas
Glen: Discussing Asynch Task Force
One way patern being discussed. WSDL group asking coordination group to take lead
Took use cases that went from one way with one transport session to multi way to multiple transport sessions. The group as a whole has come to a consensus at this level on what things should look like
When you start to map this to specification; thats when you come across issues that are still unresolved
mnot: Was there a discussion on one way request/response
glen: Did you accept that as use case
... Did not accept that as use case (correction)
mnot: It would be a nice proof point if you do that
glen: Some of the paths that we will go down will allow us to do it
mnot: clarifying use case: one request response multiplexed over multiple open transport session
glen: We do have consensus that it is perfectly acceptable to bind a single wsdl response to multiple underlying soap meps. We do not yet have a solid consensus, I think, to do that over multiple transport protocols
... I have heard from SAP that that was a wrong headed thing
umit: No that is not right
... If you have capability to present one way ... glemm interrupts... cross talk...
vikas: dialog between umit and glen, too fast to capture
anish: three different ways to do it;
do it as a binding, have multiple meps in different wsdl operations
glen: setting context, take request/request
<pauld> ping
glen: to make it work, we have two proposals
... glen: describing use case which has a timeline issue where reply to may have to be held back depending upon FaultTo
... Need SOAP MEP
... Our decision points: How you think about what is going on with SOAP MEP
... Mr. Chair, Can I help you with something
mnot: I can do it to you
all: laughs
glen: Some flexible SOAP MEP ; in message and flexible out message
... in messaage, don't know the out message until run-time
dhull: asks for clarification
glen: yes can be done
... continues..
... SOAP MEP in general... wheather they are really needed, how to describe binding, capabilities of channels
... interesting conversatio... but where it goes in getting stuff done is probably not going to be too far
... Too much actual process work to try and force ... we need to change SOAP
... What new SOAP meps do we define? What new binding? How many?
... How does that stuff bind in a clean way ?
... Ok, so... decision points
glnem: we have soap mep decision point
and this gets into our wwsdl issues
glen: some was something else in lc 101 discussion
... we decided in wsdl group that ,... well... no... silence.. aahh
... how do we make this discussion relevant to this group
mnot: Can you guys come up with a package that you can handoff to coordination group
glen: SAP/IBM has a proposal for SOAP binding
... Describing the proposal.. use two http connection behind the MEP, generated binding
... potential valid way to go
... another valid way... the ability to make flexible binding, change MEPs mid-flight, use wsdl extensibility to bind at message level and not operation level
... changing hats to sonic
... concerned about problems related to multi connection http binding
dorchard: adding on... cardinality of wsdl meps to soap meps. (1) Map wsdl meps to one or two soap meps (2) 1 wsld req/res mep always maps to one soap meps (3)
... (2) nothing to distinguish soap mep from wsdl mep
umit: soliciting interest in proposal
glen: set deadline, and get a package from task force
dhull: what part of our work hinges on asych tf
pauld: wondering.. interrupted by mnot...
... agrees with mnot
mnot: sharing his perspectives, bring up i59
... highlights concerns and unspoken requirements
<pauld> i was wondering on the packaging of this potential work (note, rec), who was going to deliver it, when and our dependency as a WG upon that work
anish: querying, what are people's dispositions on glen's and dorchard's points
glen: we did not give details to get a brainstorm going
anish: those who have opinions to share them
umit: two approaches are not compatible,
dorchard: are you championing your proposal
umit: no, what is scope of asych TF and WS-A related to this
anish: Just want to know what people think
pauld: communicate succintly, discussing dependency
glen: until TF is resolved, cannot come out CR
pauld: Looking for a decoupling with TF's work and this group's work
glen: no, no ; lets dig into dependencies
mnot: technical and charter dependency
... TF goign on for long time; progress not sufficient
... ready to go to CR with core documents
glen: agrees
... create work package and find a group to host the work
... then the TF's job is done
mnot: if the hosting working group accepts that
glen: may be none of the WG will like any packages
dhull: sharing his perspective
... going over a use case
... wsa is not specificying anything that cannot be put on the wire
... can put up a straw man proposal for how to put wsa on the wire
... wsa can map to soap bindings in multiple ways
hugo: verifying consenss and shares a concern
... the final plan is still not done.
<pauld> they're 99% complete, it's just that last 1% that's a b$#%$r
hugo: accept multiple ways to doing that. take a few ways and move on
mnot: need to decide on CR exit criteria
anish: lot of work has been done even though no final planyet
... have multiple proposals
... describes the proposals
... proposals are concrete
glen: takes responsibility
... for delay
anish: it is not that we are not doing anything
mnot: quantify when the cut-off i
anish: give TF a deadline
pauld: would like to see options as a one pager
mnot: Should regularly monitor TF's status
glen: Take proposals and present to WG
katy: Prioritize proposals
glen: no agreement on prioritites
katy: Usage scenarios discussion and prioritize usage scenarious
glen: 99% is done
dorchard: TF would have ideally wanted to have complete proposals.
... Past month's interesting happenings..
... Multi connection http bindings proposals
... simple paper writing is hard
... options are not clean, overlapping options and sub-options
... We are getting there
pauld: Concrete proposals look like they are quite complicated
dorchard: key issues are wsdl to soap mep mapping
pauld: looks like you are debating requirements
dorchard: we are going to hit the hockey stick and it will happen
glen: Choice between (1) Get something that meets short term requirements (2) Meet longer term requirements. That is the tricky point
pauld: don't cut anymore slack for TF because of time pressures; make decision
glen: TF is seeing light at the end of tunnel
... There is more TF work TBD, would be nice to have a deadline
... Sending something out a few telecons before the next F2F
... thinking out loud.. TF should be done before WSA comes out of CR
dhull: three points (1) Echo glen, good progress 99% done
... (2) Have enough for testing WSA
... discusses the test case
... Some technical decisions will need to be made to proceed with testing
... Confusion relates to mapping wsdl/soap meps to bits on wire
... it depends upon transport;
... giving a concrete example
... spending too much time analysing mappings
mark: 7 minutes to break
jeffm: TF does not have to make decisions, give us options
glen: that is what we are trying to do
<pauld> 2000/2001/2002/2003/2004/2005 will be the year of Web services
jeffm: discusses web services hype that started 4 yrs ago but has not been realized yet
... contrasts this with RPC 20 years ago
... schedule driving the TF may not help. People want more now
dorchard: soap 1.2 binding state machine is the complexity part
... Can use it or design around it
... Cannot change soap binding for asych
jmarsh: *frustrated* TF may push CR until october; unlikely to get traction in indigo
... puts forward a proposal
... move ahead with one way
... Start testing, get Core out
anish: validating his understanding of jmarsh
... instead of spec put a test suite
dhull: test suite might help
anish: Decision Tree is not really a tree
... It is more like a web
... tree nodes are not exclusive
pauld: key concern is schedule
... TF should deliver scenarios
<Jonathan> Proposal: Ask CG to cause SOAP 1.2 one-way MEP to be done; add Dave's one-way MEP to our test harness; TF close - use incubator for these other specs.
pauld: references jmarsh's proposal ; perhaps move with one way binding ; create test scenarious and move ahead
<anish> the important point is to specify things (at least a way) to do this to get interop. Interop is quite important here
mnot: BREAK********************************
<pauld> build test cases based on the SOAP 1.2 Email binding
reforming
resuming 10, 9 , 8 ...
mnot: wrapping up
... TFs save WG time
... this TF is successful in doing that; Moving forward we need to make decisions
... Need to figure out if we need to put CR criteria on the TF
... TF should report 2 weeks before next F2F
glen: ok
mnot: 2 constraints, charter asks for asynchrony mechanisms
... the scope for fixing asynchrony does not extend to entire web services
... curious about phone participants
... if the TF cannot give us a package by next F2F, will need to rethink position on i59 and CR
... i60 discussion
<pauld> http://169.254.197.20/ws-addr/lists.w3.org/Archives/Public/public-ws-addressing/2005May/0058.html
jmarsh: refers to mail from 24th
<TIBCO-dmh> Specifizierungsnahmenraümteverscheidung oder so etwas
jmarsh: Dependencies which prevent independent versioning
... Namespace is shared between core and SOAP binding.
... Need to document namespace policy
anish: clarifies dependency with jmarsh; splitting namespace? as suggested by mhadley
discussion between jmarsh and anish; too quick to capture
jmarsh: Reserve namespace for W3C defined specs.
... paco says core and soap binding should be versioned together
dorchard: discusses a scenario of new soap fault code. Is this backwards compatible?
... If it is compatible, use the same namespace
anish: Not true with SMTP binding
dorchard and jmarsh discussion on why core namespace should be closed
mhadley: is a non issue?
multiple discussions triggered by pauld on reserving use of namespace to W3C
continuing discussion on namespace reservation and encroachment by non-w3c
mnot: proposal to drop the issues with no action
dorchard: webarch document provides guidance on documenting namespace
mnot: strawpoll
... Who prefers to split namespace? 3 in person; none on phone
... Who prefers not to split? 7 in person; none on phone
... Not going to split.
dorchard and jmarsh discussion on documenting namespace controls
dorchard: Leave the namespace extensible
anish: why is this a wsa issue? Is a generic issue
rapid discussion between anish and jmarsh on anish's issue. point/counterpoint
mnot: off-topic warning
... i42 reference
mhadley: concern with anyone extending wsa namespace
dorchard: only this group can do it
mhadley: cool
discussion between glen, dorchard, jmarsh too fast to capture
<pauld> two separate issues: anyone else being able to add symbols to wsa namespace and a processor expecting/ignoring unknown values added to the wsa namespace by the w3c
mnot: Close i60 with no action
... That should be for WSDL issues: Time now 11:48pm, Lunch at 12:30pm
... Returning to LC issues
Next set of issues are dealing with LC58
mnot: LC 60 is the next one
... Next LC 79
... Next LC 91
... Finally LC 102
... Source Routing
GlenD: Should not preclude it
close LC60 declining request to support source routing
kate to reply on LC60 to submitter
mnot: resolving other issues can help resolve LC 58
anish: SOAP defines active intermediaries
mnot: move to specific issues
Discussion around lC 79
mnot: are the MAP immutable?
... Let's break for lunch
LUNCH ***************
<pauld> fulminates .. we're rehashing issue 9 and not the LC issue
DaveH: Not asking for semantic changes, just trying to clarify the spec.
DaveH: If we want to talk about it at all, we should be more detailed/precise about refPs, etc
Marc: MAPs targeted at the intermediary
DaveH: immutability is between source and the node the MAP is targeted at
Glen: What about Mark's case? HTTP -> intermediary -> SMTP where anonymous gets "rewritten"?
Mark: proposal is s/gathered by/targeted to/
Mark: Any objection to making this change?
DaveH: Would say "when that intermediary resends..." - active voice is better
Mark: Leave that to the editors?
DaveH: Unclear who's doing what...
Mark: Marc, can you take that on?
Marc: Clarify please?
DaveH: Make clear it's the targeted intermediary that is doing the resending.
DaveH: OK, editorial discretion, move on.
Mark: Yes, move on!
Mark: Any objections?
<GlenD> (no objections)
<GlenD> Next bullet - transport-specific representations
Jonathan: Shouldn't constrain bindings - good enough as is
Paul: Why constrain bindings
DaveH: This is about SOAP bindings not addressing bindings
Mark: Do we constrain this?
Anish: SOAP binding is independent of transports
DaveH: Is it permitted to define SOAP-over-email which lets you leave out WSA replyTo headers?
Jonathan: Can't use this SOAP binding and do that...
DaveO: So answer to 2nd question is "no"
DaveO: Binding is not required to put MAPs as headers, technically
<GlenD> (confusion about meaning of "binding")
<GlenD> UTB = Underlying Transport Binding, "WSA binding" = WSA binding
DaveO: Answer is still "no"
DaveO: I can write a UTB spec which serializes things in any way it wants
Jonathan: The SOAP header block always exists in the abstract, even if not explicitly as angle-brackets on the wire
<GlenD> (general nodding)
Mark: Generally you'd put this info in a primer, not the spec
Mark: Question 3 - is intermediary prevented from changing headers always or just when signed?
Jonathan: Under all circumstances.
Paul: Are we restating stuff from SOAP, or imposing WSA requirements on top (which would make all intermediaries require this spec?)?
Jonathan: SOAP canonicalization composes fine with this, so you shouldn't need WSA-aware intermediaries
Marc: Defaulting prevents you from removing an explicitly specified value...
DaveH: OK, won't beginners ask this same question, or should we just require them to know SOAP better?
Anish: seems like a really heavy hammer...
Mark: Lets's go through rest of intermediary qs first...
Tom: if sig is on whole message, removing a header will screw up signature...
Various: that's a general problem
Marc: I'll clarify this applies when the header in question is being forwarded
Mark: OK, any objection?
<GlenD> (no objection)
Vikas: SOAP spec wins when processing?
Mark: Doesn't do good to say that
Marc: If you need that precedence rule, your spec is broken
<GlenD> RESOLVED : CLOSE LC79
<GlenD> Comment 3
<TIBCO-dmh> ping
Glen: What about the "by default" change?
Jonathan: This is about the node, not the role. So it's ok.
<GlenD> (discussion of meaning of "next" and processing model)
<GlenD> (discussion of dynamic routing scenario and various ways to acheive it)
Mark: Change "are" to "MUST be"?
Glen: No, should add "by default"
Mark: Different issue
Mark: objections to closing?
<GlenD> (no objections)
RESOLVED: CLOSE LC91
<GlenD> Is this immutable only at infoset layer, or abstract?
<GlenD> Proposal is to move this to sec 3
Vikas: Do we need this, since the sentence before takes care of it? End-to-end means unchanged in the middle
Vikas: don't acknowledge message path in the core
Steve: There is a path, regardless of SOAP
Mark: Any objection to moving the text?
<GlenD> (no objection)
<GlenD> 2nd point - refps are mapped as header blocks - can disappear along the path
<GlenD> Suggestion is to exempt refps from this statement
<GlenD> Alternative is to do something to enable end-to-end transfer of refps....
Jonathan: abstraction leaks.. so let's support what we want on the wire and change the abstraction appropriately
Marc: Or we could not say anything about immutability in the core
Vikas: As long as it's transparent to you, it's end to end.
Jonathan: if we remove this, SOAP binding still acts the same way, so that's fine. If we write a new binding, should we preclude good reasons for changing these things en route?
Mark: Who thinks we should remove both?
<GlenD> 6 votes
Mark: Who thinks we should just remove the latter sentence?
<GlenD> 5 votes
Mark: Not live with either?
<GlenD> no objections to removing both
RESOLVED: LC102 by removing both of the first two sentences in section 3.2 of the core.
Mark: Do we need to do more here?
Vikas: OK by me
<GlenD> (discussion of "by default" proposal)
<GlenD> suggestion is to change wording to "By default, the resulting header blocks are targeted..."
<GlenD> (NO OBJECTIONS)
RESOLVED: CLOSE LC58 with no additional changes
<GlenD> (discussion of trust and security issues)
<GlenD> BREAK - 15 minutes
<pauld> Scribe: pauld
<GlenD> Scribe: GlenD
Mark: When we closed issue 4 Marc suggested he wanted to see a concrete example of securing an EPR. We said we'd entertain that if it came up in LC. Marc, is that what you're saying here?
Marc: Agreed to close 4 to move forward, but didn't like it. Agreed specifically because we could have an LC issue. Closing it now would be disappointing.
... This seems like a different suggestion than "an example"
Mark: not really
... Willing to leave it open if you come back with an example
Marc: We don't have a security model, just a feel-good statement. Charter says we need one.
Paul: What's the expectation here? Changes, or additions, or test cases?
Marc: To have a security model.
Mark: This is about reopening the discussion we previously had and closed.
Marc: This is about additions to the spec, not changes.
Paul: Is there a way we can compose this on top of what we've got? Also, it would be good to see a concrete proposal here...
Jeff: Marc says we haven't met our charter. If that is upheld, that will hold us up even more.
... better off dealing with this rather than waiting and dealing with it procedurally
Paul: We could produce a separate security document. From a schedule POV perhaps that would be parallelizable
Jeff: Need to consider security as you do base
Hugo: We're talking about security model and "security model" is very vague. We could say we've done the bare minimum.
Mark: Which is what we did before
Hugo: Marc, what are you looking for exactly?
Marc: Specify at least one way of proving that you can speak for both the sender of an EPR and the endpoint the EPR is addressed to. Enables interoperably using the EPR without a vague "well do you trust it or not". If we don't do it, it'll never happen.
... Why even spec it if no one can ship it safely?
Jonathan: Several possible outcomes - close w/no action. AIs for concrete proposals. Close issue in positive way - now that one isn't going to happen at this meeting. As such maybe we should shoot for either closing it or getting AIs?
Mark: Yeah baby
<umit> +1 to Jonathan
DaveH: Nervous about normatively specing any security stuff as opposed to stating general guidelines
... lots of ways to make sure a given msg is OK. Don't want a one-size-fits-all model. Our current stuff isn't very coherent, however. Would be good to do some work on it.
Marc: Not suggesting The One Way to do it - but *a* way everyone can use.
Mark: Worried about this because there's no concrete proposal yet. Suggests a hard problem.
DaveO: sympathetic to Marc's position
Jonathan: Tried to get Gudge re-engaged. We will try and help out with this.
Mark: Let's not make a decision about reopening/closing yet, and see if we can make progress.
... but reluctant to do even that
Hugo: we don't have this idea of three parties - sender, receiver, and EPR minter
(yes we do?)
scribe: simple security model would be OK.
Paul: would be helpful even just to have test cases
Marc: We need a security model
Bob: Lots of good practice out there re: bulletproofing, etc
Marc: yes, but not relevant
Mark: Marc, would you make a proposal?
Jonathan: OK to leave this open today, but in a month, not so much....
PROPOSAL: LEAVE LC87 open, but not reopen i004
Mark: Marc can you give us a proposal ASAP?
Marc: Sure
<scribe> ACTION: Marc will write a concrete proposal for resolving issue LC87
LC55 - Tim Ewald's issue
Mark: let's leave this open for now pending resolution of LC87
Jonathan: should we say something about the fact that you can, for security purposes, refuse to send to an EPR you've been passed.
Anish: is this an issue?
ok, leaving it open for now
LC75 / 88[
Bob explains the issue and proposal
Hugo: issue with using same message ID for retransmission
(discussion of message uniqueness and retransmission)
DaveH: This doesn't address my issue (neither enforceable nor necessary)
(more discussion)
DaveH: If messageid is optional, this matters a lot less...
... Slippery slope trying to define uniqueness in a useful way. Really asking people to be smart, which is SHOULD and not MUST...
Bob: various reasons you might use ID (correlation, dup detection, etc). Since cardinality is 0..1 it's optional unless expecting a reply
(discussion of the fact that WSA forces you to use MessageID if you are expecting a reply)
Jeff: we havent defined a layered model... transport vs. application vs. RM layers... not clear what the relationship between our spec and that sort of layered model is.
(discussion of requiring it for logging purposes, etc...)
Marc: are we assigning specific semantics to messageID, or just providing a field other specs are building semantics on?
Mark: let's look at other MID-related issues
<pauld> thinks making messageId optional prevents more use-cases than it enables
disagrees, but thinks we could benefit by being crisper about our semantics in general
<pauld> does wonder about removing our ability to use canned test documents though ..
Marc: facing a choice between really spec'ing MessageID as a useful field which people can use or not as desired, and treating it as a useful field with assigned semantics and have it ALWAYS be there.
Bob: if we can rely on semantics of MessageID, then it needs more definition. For instance, a method of constructing IDs which guarantees uniquenes....
DaveH: SMTP already includes a messageID. This may be happening at other levels anyway.
... We don't say anything about it except request-reply. If we're going to require it we should talk about it in way more detail.
Anish: could make it optional in core, but make it req'd in WSDL MEPs...
(discussion of adding a WSDL extension to switch on/off MessageID)
Umit: What if I don't use WSDL, how can I ensure messageID if I need it?
Paul: seems quite useful to have a req'd messageID that's unique, but we dont need to spec how to make it unique
... on the other hand not having it optional makes it hard to use canned docs in testing
Tom: both current reliability specs do their own thing
... worried about us trying to define globally useful thing
Steve: very useful to have this required, for lots of uses
Tom: not a bad thing to have it, but trying to make it work for everyone is hard/ill-advised
Anish: WSRX has begin/end along with ID, not an IRI... required is useful for monitoring/logging but when you bring in security they can't look at it anyway
DaveO: scalability problem in high-performance apps - messageID doesn't work in some cases.
Umit: this is just like action. messageID, even if it's not well-specified, should be required. Can't implement David's thingy without MessageID anyway (description offline)
DaveH: no problem making ID required in some context, just not for all of WSA
Hugo: why not propose calling it correlationID?
<pauld> an integer messageId is efficient for retrying but you don't need a 'roll-over'. how many Ids you remember within an interaction could just be a matter of policy - save the last 100 messages received etc.
Mark summarizes
two paths - generally useful, or just useful for our purposes (and we should make it more specific)
Jonathan: third path == status quo
Jeff: streaming stock quotes use case... droppage is OK. Some contexts don't need it.
<pauld> notes messageId/correlationId is a commonly used pair of names in protocols .. we'd have correlationId/relationship which jars with this reader
Jonathan: status quo is best we can do
DaveH: is anyone required to check for uniqueness if they're required everywhere?
(all - no)
Mark: Who thinks we need to have messageID be applicable to more than just correlation?
6-7ish
Mark: Just correlation?
7ish
Mark: We're a little wishy washy
Jeff: "run away..."
(discussion of optionality)
straw poll:
0) Status quo
1) Make messageID optional in the core, even if reply expected, but in WSDL binding spec we say exactly when it's needed AND create a facility for specifying when messageID is required/not (WSDL extension)
2) Require messageID always
options are -
0) status quo
1) optional in core
2) required in core
0 got 11 votes
0 got 13 votes, sorry
0 got 12 votes
1 got 6
2 got 4
Mark: do we need a vote?
Glen: I'd like to see a vote
VOTE: Close LC86 with no action.
BEA = yes
BT = yes
CA = yes
Ericsson = yes
Fujitsu = yes
Hitachi = yes
IBM = yes
IONA = yes
Microsoft = yes
Nokia = yes
Oracle = no
SAP = yes
Sonic = no
Sonoa = yes
Sun = abstain
TIBCO = no
W3C = abstain
12 yes
3 no
2 abstain
MOTION PASSES
RESOLVED : close LC86 with no action
Jeff: Bob's proposal doesn't qualify the scope of the uniqueness
Mark: is that binding specific?
Tom: TCP connection is scope for HTTP
... binding specs uniqueness?
Jeff: do we say that in the core?
(more discussion of binding-specificness)
Umit says +1 to Jeff (uniqueness is from sender's perspective)
Paul: messages with same ID are same message
Jeff: up to sender to guarantee correctness in that context
DaveH: Better. Doesn't do much about logging, etc...
(discussion about proxies)
Jeff: sending endpoints responsibility to generate new ids for new messages
... allowable to drop dups
DaveO: good to define this based on the idea that the minter defines the scope of uniqueness.
... security specs demonstrate historical precedence of this idea
Bob proposes some text
<scribe> ACTION: Bob to revise his proposal for 75 and 78 and send it to the list
Anish: let's make WSDL 1.1 binding a note, so we don't have to wait for WSDL 2.0 to be done. Not a rec, so W3C won't have a problem with it. Keep WSDL 2.0 binding a rec-track document and move forward with it.
Mark: Would we fold in WSDL 1.1 into the WSDL 2.0 rec when we publish it?
Anish: either way
Marc: OK with this idea, but concerned with scheduling. When would we split?
... don't want to publish it before a last call
... Last call on the whole WSDL thing and then split it. Don't LC a note
Anish: but you can do so (media types note)
Jonathan: What's the difference between a note and a stable WD?
Hugo: details which need to be worked out. Issues with two recs. No issues with a note for 1.1. Rechartering might be needed, though? Easy way to go if in fact everyone wants to go there...
Mark: this might not be something we want to do until issues with WSDL stuff are resolved
... lets let this sit a bit
Hugo: worried about spending time figuring out what to do, and depending on what options we agree on it might add more time...
Mark: no concall on Monday - BUT everyone should be looking at the issues list
ADJOURN