W3C XML Protocol teleconference, 16th May, 2001
1. Roll call
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- Canon Jean-Jacques Moreau
- Commerce One Jay Kasi
- Compaq Yin-Leng Husband
- Compaq Kevin Perkins
- DaimlerChrysler R. & Tech Mario Jeckle
- DevelopMentor Martin Gudgin
- Engenia Software Eric Jenkins
- Ericsson Research Canada Nilo Mitra
- Fujitsu Software Corporation Kazunori Iwasa
- Hewlett Packard Stuart Williams
- IBM David Fallside
- IBM John Ibbotson
- IBM Doug Davis
- IDOOX Miroslav Simek
- Intel Randy Hall
- Jamcracker David Orchard
- Library of Congress Ray Denenberg
- Lotus Development Noah Mendelsohn
- Macromedia Glen Daniels
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Mitre Paul Denning
- Novell Scott Isaacson
- Oracle David Clay
- Philips Research Amr Yassin
- Rogue Wave Murali Janakiraman
- Rogue Wave Patrick Thompson
- SAP AG Volker Wiechers
- SAP AG Gerd Hoelzing
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Tibco Frank DeRose
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- Vitria Technology Inc. Tony Lee
- W3C Hugo Haas
- W3C Yves Lafon
- WebMethods Randy Waldrop (scribe)
- AT&T Michah Lerner
- Canon Herve Ruellan
- Commerce One David Burdett
- DaimlerChrysler R. & Tech Andreas Riegg
- DevelopMentor Don Box
- Engenia Software Jeffrey Kay
- Fujitsu Software Corporation Masahiko Narita
- Hewlett Packard David Ezell
- Library of Congress Rich Greenfield
- Macromedia Simeon Simeonov
- Mitre Marwan Sabbouh
- Oracle Jim Trezzo
- Philips Research Yasser alSafadi
- Software AG Dietmar Gaertner
- Sun Microsystems Chris Ferris
- Vitria Technology Inc. Richard Koo
- Data Research Associates Mark Needleman
- Active Data Exchange Shane Sesta
- Active Data Exchange Richard Martin
- Bowstreet Alex Ceponkus
- Bowstreet James Tauber
- DataChannel Brian Eisenberg
- Epicentric Julian Kumar
- IDOOX Jacek Kopecky
- Interwoven Mark Hale
- IONA Technologies Eric Newcomer
- IONA Technologies Oisin Hurley
- OMG Henry Lowe
- Propel Daniela Florescu
- Tradia Erin Hoffman
- Tradia George Scott
- Xerox Ugo Corda
- Epicentric Miles Chaston
- Group 8760 Dick Brooks
- Informix Software Soumitro Tagore
- Informix Software Charles Campbell
- Interwoven Ron Daniel
- Netscape Ray Whitmer
- Netscape Vidur Apparao
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
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
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?
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.
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?
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?
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
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