No AOB requested
Clarifications received from Jean Jacques.
Yves: Will remove references to the naming of the spec.
Noah updates on i41 - DONE
Henrik: 2nd action item is DONE
David Clay: Action items 3/4. Has posted to group, awaiting for comments. PENDING
Jack: To get together with Jeff Kay with respect to Jeff's issues... status unknown. New Action to Mark Nottingham to follow up with Jeff.
Mark Jones: AM Issue is the same as issue #82 in issues list: DONE. Henrik has some questions about Mark's posting and has lost track of the thread - Herve's thread. Henrik questioning the resolution. Mark Jones thinks that Herve's mail concurs with the resolution.
Glen Daniels: Link Text for the two specs. DONE
Hugo: Post i41 thread to dist-app DONE
Henrik: Add Herve's comments to i42
Stuart: Update AM status text DONE
Hugo: ???
Hugo: Update test/conformance document to reflect discussion from telcon. PENDING
DavidF: There was clear indication from last weeks telcon to start discussion of actor and mustUnderstand. A subgroup of folks from that telcon went to look at which issues to focus on. They decided issue #79 is a good starting point. Request Glen to summarise to ensure that the correct issue is being addressed.
Glen D: Really two separate issues.
#1 When there is a mustUnderstand fault there is no particular way for the fault processor to determine which particular header gave rise to the fault (where there are multiple mustUnderstand headers).
#2 How do the mustUnderstand and actor relate to each other. ..... [see Glen's summary email which is linked from the telcon agenda]
Henrik: Encourage folks to read the thread on soapbuilders. Not so much that you can see things that are not targetted at you... but that you don't have to (??).
Glen D: So the end-destination doesn't have to scan through the whole message scanning for blocks that do not appear to have been understood.
Noah: I mentioned (on soapbuilders) we should separate the notion of mustUnderstand from mustHappen (at some point in time).But it impinges on this rather vague notion of routing and path that we haven't really addressed - although we do in part because we have a notion of an endpoint. .... also some complication that the body is a synonym for an anonymous header, but we also have anonymous headers. Ordering... various options... complexity of ordering at various points along the chain which is all mixed together.
DougD: If we leave things the way they are - I am concerned with respect to processing at a client regarding what happens to a mustUnderstand block that never visited its actor.
Henrik: The SOAP spec. IS clear on these matters. Along the same lines I can imagine that I have a mechanism for routing with an overriding mustUnderstand that forces the message to be appropriately routed to the appropriate actors.
Martin: Because we have MU on a subset of headers in a message there is a concern that some implementations have features that don't quite follow the rules.
Glen D: Consistency could be based on every processor/actor honoring the MU semantics
Doug D: Doesn't really hold much water if the spec is so vague that it actually specify how to actually make it work, rather than ??
Glen D: This has been the perennial problem in determing what should be core.
Doug D: Some standardised extensions header would be a great way to do it.
Mark J: Re: Glen's characterisation of Henrik's idea -- we have modules/handlers that are fired anyway so we could manage to do this without even targetting.
Martin: Suggest that some WG come up with a strawman proposals to do this.
Noah: Would be interested in what how Gudge feels about the these abstractions and how we look at things in the contexts of the intermediaries and different message patterns. How would see a group seeing this whole message packing and routing problem.
Martin: How do we write an extension.... I think it might be a useful exercise.
Noah:
Jack: I don't think it is intuitive to drop mustUnderstand headers. I am for the second solution where the processing model at the end point is different from the model at intermediaries.
David F: So so you think the exercise Martin proposes is a good thing.
Jack: Well yes... but I'm adding a voice for the second alternative.
David F: Is there anyone interested in working with Martin?
Stuart: ...I'd lend a hand.
Noah: Do we take the view that the body is significant.
Martin: I did say ordering not withstanding.
David O: Is there some notion that there is annotation of previous processing.
Martin: Base assumption is that we can only look at the message we got.
Mark J: Qualify the proposal a bit... in the sense of the current meaning of MU it's fine to mark something as MU targetted at something an bypass its actor. Maybe final destination should check for both MU and MHappen.
Henrik: I would assert that we only need one must and we can build more must's tagged with MU.
Noah: Yes... but we should note that this only really work for new headers - it doesn't work so well for new attributes.
David O: The thing that I'll add - this really remind me of some things from XLink for describing .... there are some definite issues wrt to in-line annotation with attributes.
David F: ??
David O: One of the things we decided to do was use stand-off annotation.
Gudge: Are you arguing that we should be using headers... rather than attributes.
David O: There may be issues with inlined attributes...
David F: Please could you summarise your proposal.
Gudge: Proposing to define an extension Module with associated header elements and processing rules for [message routing] and I will do this by next Wednesday.
Paul D: Volunteered to help.
David F: I think that Gudge will post something to encourage discussion an that's how we'll deal with it.
Marwan joins call
David F: Issue 79 is clearly still under discussion. Do we think that it should be clarified by breaking into 2 issues.
Glen: I think we should split it.
Henrik: Concur.
David F: Glen please post something to split the issue.
Glen D; The decription posted to date contains that split.
David F: Action to Henrik to split the two issues in the list.
David F: Henrik please remind us of your proposal.
Henrik: Triggered by discussion on soapbuilder on the purpose of SOAPAction and absence of rules covering some of the edge cases. What I proposed was a mechanism for clarifying those. Leaves most of the design as-is and calls out more particular behaviour for the edges. There have been responses that wordsmith and others that look at a higher level.
Dick B: There's been a lot of discussion on what SA really means. What the ebXML community are doing is to use the header to indicate that the payload follows the syntax and semantics of ebXML
Doug D: ??
Dick B: ...well the 'intent' is that the message be processed according to the rules of ebXML.
Henrik: This is a fine use of SA.... you can have a large set of message all of whose 'intent' is ebXML so to speak. I think it is a useful mechanism from the POV of having a stable mechanism for dispatch and message routing.
Frank D: How would the ebXML community deliver equivalent functionality on a different transport. I'm of the view that the SA is there really for filtering at a Web Server.
Dick B: see Appendix 3 of (one of the) ebXML spec .... you'll see that in our bindings for SMPT we have carried the SA header over to SMTP....
Frank: Well that's my point... you are now requiring that other binding provide a similar mechanism.
Dick B: ??
Noah: Briefly remind folks of an emailed suggestion. Would like to establish a principle that all per-binding artifacts like SA should be 'hints' (without cracking the XML) and the principle is that the information should be within the envelope. We might say look the HTTP and SMPT bindings choose to carry certain things outside the envelope... however, in general we don't know how to carry these things over from one binding to another.
David F: I think that these are very sound principles. I'm curious about the thinking from the ebXML community.
Dick B: Got to remember the backgrounds of a number of ebXML participants with existing message brokers.... we wanted to find a mechanism and SA looked like a good one. Also the original ebXML used a mime-type parameter which was lost in the carry over to SOAP and SA looked like a good fillin.
David F: So what about non-MIME transports?
Dick: We just use the literal string ebXML.
Henrik: Observe there are many things that different protocols do differently... so there is a large set of feature differences when we bind to different protocols and I don't think SA is any different.
David F: Time is running out on this telcon .... so how do we proceed? Should we revamp the proposal based on this discussion?
Henrik: I think we need to do that. Question about how the process works ...
David F: We'll keep making proposals and modifying them until we have agreement.
Henrik: Marc H pointed out that the proposal did not originally address i22.
Marc H: The revisions mean that it does now address i22.
Action: Henrik will post a revised proposal in the next day or two.
None