W3C XML Protocol teleconference, 16th May, 2001

1. Roll call

Present 41/33 Excused Regrets Absent

2. Agenda review, call for AOB


   David Fallside: Outlined the agenda. No AOB.

3. Approval of minutes from May 9 telcon


   Marc Hadley: In agenda item 5, I am incorrectly identified as
     Mark Nottingham.

4. Review action items


   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.

6. Issue #100


   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.

7. Issue #99


   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.

8. Agenda for next f2f meeting


   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.

9. Any Other Business


   None.

Meeting adjourned.