text: David Fallside: Outlined the agenda. No AOB.
  Marc Hadley: In agenda item 5, I am incorrectly identified as Mark Nottingham.
  2001/03/28 David Clay: AM & glossary mapping. This is done. 2001/03/28 David Clay: "Module" definition. This is still open It may change based on the resolution of the ongoing discussions about "mustUnderstand", etc. 2001/05/02 Henrik: Issue list - split I#79. Done - new issues are I#99 & I#100. 2001/05/09 Noah: Generate a proposal on ordering. Done - will be discussed today (item 6 on agenda). 2001/05/09 GlenD: Generate a proposal on "mustUnderstand" faults. Done - will be discussed today (item 7 on agenda). 2001/05/09 Henrik: Post motivation for "SOAPAction" on dist-app. Done - we will discuss next week.
  DavidF: This is the question: is "mustUnderstand" a local or global contract. It was a spin off of issue 79. In addition, we should consider adding clarifications described in Noah's document to the spec. Noah: My document consisted of 3 parts: (1)Goals, (2)Clarification on how SOAP 1.1 works today, and (3)tentative proposal for header dependency processing. I assume you're suggesting putting parts of section 2 in our spec? DavidF: Yes. Henrik: Should we add the clarification points as issues? Noah: Good idea. To summarize the SOAP 1.1 clarification points: . Multiple headers are allowed. The ones to the "anonymous" actors are processed last. . If a header with "mustUnderstand" gets to its actor, it must process it correctly or generate a fault. There is no guarantee that it will get to that actor. . "mustUnderstand" is only useful when you have confidence that the header will get to the actor (outside of the SOAP spec). DougD: Is it possible that the current spec is "wrong" in this area? It seems useless in many applications. Noah: The positive side is that it is a building block. It is likely to be useful with some reliable routing scheme. DavidC: Does the proposal provide a routing plan? Noah: Not really. It provides handling dependencies between multiple actors header blocks. DavidC: Isn't there an implicit routing to visit all actors? Noah: I don't think so. Henrik: I agree with Noah. SOAP is a distributed message model - it doesn't specify a routing path. There may be many types of path implementations, eg. multicast, etc. Noah: Still, a message may never get to a specific actor. JayK: Q: Is it not true that the endpoint will process the message last, and will fault if any "mustUnderstand" was not handled? Noah: That is not sufficient because some intermediaries may have sequence dependencies - this is not solved by SOAP. Henrik: Agreed. MarkJ: To solve this you must guarantee topological order. HenriK: Suggest new requirement: intermediaries must not re-order headers. The first will stay first, etc. DavidF: Due diligence is required on new headers and attributes. Proposal: we need to think more about ordering. Henrik, can you draft a proposal? Henrik: Yes, I may call on Noah and GlenD for help. DavidO: The order processing discussion seems similar to the "XML Processing Model" which is currently being worked on. DavidF: Will you do due diligence on that & report back? DavidO: Yes.
  GlenD: To recap: when a "mustUnderstand" fault occurs there is no way for the receiver to know exactly what caused it. There are 2 alternatives in my proposal: (1) new elements in the fault element to specify the QName where the failure occurred. (2) a new header with copies of the misunderstood headers. Gudge: Q: will the fault return the namespace declarations? GlenD: Yes. Gudge: Another Q: Because of the schema we can't add new headers without breaking the SOAP 1.1 spec. Could we put the new info in the "detail" element? GlenD: You are correct. Yes, we could do it that way. Henrik: The fault could be from a variety of things - order, state error, etc. Consider sending back something like a WSDL description of the expected message. GlenD: That could result in a very long fault message. DavidC: I'm wondering, could we specify a general fault mechanism that could handle this additional info? Also, can only a single fault be returned (not several)? DavidF: Is there a proposal? GlenD: It might be nice to be able to aggregate multiple faults. But this breaks the current SOAP spec & requires a new fault code.
  DavidF: We need to generate proposals to address the outstanding issues. We will probably breakout into subgroups to come up with proposals. GlenD: Should we identify the target issues in advance? DavidF: Yes, I will begin that effort and start priming the WG to start thinking about specific issues and proposals.
  None. Meeting adjourned.