W3C XML Protocol teleconference, 9th May, 2001
1. Roll call
PRESENT 42/36
- Data Research Associates Mark Needleman
- Active Data Exchange Richard Martin
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- AT&T Michah Lerner
- Canon Jean-Jacques Moreau
- Commerce One Jay Kasi
- Compaq Yin-Leng Husband
- Compaq Kevin Perkins (Scribe)
- DaimlerChrysler R. & Tech Mario Jeckle
- DevelopMentor Martin Gudgin
- Engenia Software Eric Jenkins
- Engenia Software Jeffrey Kay
- Ericsson Research Canada Nilo Mitra
- Hewlett Packard David Ezell
- Hewlett Packard Stuart Williams
- IBM David Fallside
- 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
- Mitre Marwan Sabbouh
- Mitre Paul Denning
- Netscape Vidur Apparao
- Novell Scott Isaacson
- Oracle David Clay
- Propel Daniela Florescu
- Rogue Wave Murali Janakiraman
- SAP AG Volker Wiechers
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Tradia Erin Hoffman
- Unisys Nick Smilonich
- Unisys Lynne Thompson
- Vitria Technology Inc. Waqar Sadiq
- W3C Yves Lafon
- WebMethods Randy Waldrop
- Xerox Ugo Corda
EXCUSED
- Active Data Exchange Shane Sesta
- Canon Herve Ruellan
- Commerce One David Burdett
- DaimlerChrysler R. & Tech Andreas Riegg
- DevelopMentor Don Box
- Library of Congress Rich Greenfield
- Macromedia Simeon Simeonov
- Microsoft Corporation Paul Cotton
- Netscape Ray Whitmer
- Oracle Jim Trezzo
- Rogue Wave Patrick Thompson
- SAP AG Gerd Hoelzing
- Software AG Dietmar Gaertner
- Sun Microsystems Chris Ferris
- Tradia George Scott
- Vitria Technology Inc. Richard Koo
- W3C Hugo Haas
REGRETS
- Informix Software Charles Campbell
- IBM John Ibbotson
- IDOOX Jacek Kopecky
- Cisco Krishna Sankar
- DataChannel Brian Eisenberg
- Bowstreet Alex Ceponkus
- Epicentric Julian Kumar
- Fujitsu Software Corporation Kazunori Iwasa
- Fujitsu Software Corporation Masahiko Narita
- Group 8760 Dick Brooks
- IBM Doug Davis
- Interwoven Mark Hale
- OMG Henry Lowe
- Tibco Frank DeRose
ABSENT
- Bowstreet James Tauber
- Epicentric Miles Chaston
- Informix Software Soumitro Tagore
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- IONA Technologies Oisin Hurley
- Philips Research Amr Yassin
- Philips Research Yasser alSafadi
2. Agenda review, call for AOB:
David Fallside: Outlined agenda.
No AOB
3. Approval of minutes from 2nd May telcon
Approved - no amendments.
4. Review action items.
AI1) David Clay 280301: Finished and posted to group. Waiting Feedback
Pending
AI2) David Clay 280301: Finished and posted to group. Waiting Feedback
Pending
AI3) Jeff Kay et al 110401: Closed. Will be raised again if issue.
Done
AI4) Hugo 260401: Done
AI5) Henrik/MarkJ 020501:Done
AI6) Gudge 020501: Done
AI7) Henrik 020501: Pending
AI8) Henrik 020501: Revised wording
Done
6. Part 1
Issue: "mustUnderstand" Attribute
Gudge's proposal posted to list and included in agenda announcement e-mail.
DavidF: We could:
1. Make it a normative part of the specification.
2. Make it a non-normative part of the specification (& therefore
a responsibility of a higher layer)
3. Document in archive but not be part of the specification.
Noah: had sent a response. Concerned about consideration in isolation
from consideration of ordering and processing by intermediaries.
Gudge: acknowledge his proposal doesn't guarantee intermediary has
processed "mustUnderstand" correctly.
Noah: Need to know what problem "mustUnderstand" is solving. What
"mustUnderstand" means is the "SOAP sender is in trouble if
the target processor does not do the requested processing"
Henrik: should processing be different at the end as compared to an
intermediary? Gudge's proposal can accommodate an intermediary
not doing something at the end.
DavidF: Gudge's proposal gives a solution to processing at the end.
Need proposal for ordering. Carry Gudge's proposal forward
and solicit solution to the second part (i.e. ordering and
processing by intermediaries).
Action: Noah: First draft of second part by Friday.
Noah: Solution to the second part may provide a solution for which
the first part is just a specific situation.
6. Part 2.
Glen Daniels: Summary. Concern about level of detail in "mustUnderstand"
fault.
Action: Glen: By Friday will summarize issue and post to Noah for incorporation.
Gudge: Can't put header fault information in the "detail" element. Can
only be used for fault information related to the body.
David Orchard: mustUnderstand led to very binary faults. There may be
partial failures (e.g. during security processing).
Concerned about creating a sibling element to "detail"
for header faults. Use namespace qualified child elements
of "detail"?
Noah: Observation of SOAP specific - schizophrenic. Body and header
are symmetric in that the body is just another element but
asymmetric in that a fault in the body is different to a fault
in the header. Should decide either to be symmetric (i.e. body
and headers are the same in every aspect) or asymmetric (i.e. the
body and header are different).
7. SOAPAction - Issue 95 & 22
DavidF: Should either continue with proposal or delete SOAPAction
completely from specification.
Q: Why SOAPAction exist?
Henrik: Concerned about a lot of duplicated discussions. Should the
group used for discussions be more restricted? Discussions
should concentrate on providing specific proposals for
wording. Should refine guidelines for discussions and
progressing issues. Marc Hadley and others have provided
input to original proposal to clarify edge cases.
Jeff Kay: Should remove SOAPAction.
Gudge: Made a proposal to revert back to SOAP method name as in SOAP1.0.
Why did it change from 1.0 to 1.1?
Henrik: SOAP interface and method in 1.0, became SOAPAction in 1.1 so
it was less oriented to RPC. It is meant to supply a hint
about the contents.
Noah: Is SOAPAction deterministically or non-deterministically related
to the body? This was originally targeted at performance by
providing information about the body without having to process
the whole message.
DavidF: Need the motivation for creating SOAPAction. It also needs to
be considered in the wider context of other transports.
Mark Nottingham: mime content-type could provide an alternative to
SOAPAction.
Henrik: content-type has no mechanism for nesting content-type.
Also SOAPAction is used to indicate this is a SOAP request
(coming in on the same URL and port).
David Clay: Is there a compatibility issue if SOAPAction is removed?
Why not use different URI to identify different use?
DavidF: Need motivation for SOAPAction. Compatibility - should it
be considered? Role is not just to ratify SOAP.
Action: Henrik: Include the motivation for SOAPAction in the proposal
and distribute to dist-app
8. Issues:
DavidF: 10 issues are of editorial nature. Will assign en-masse to
the editors. The Issue list maintainer will assign the
issues to the editors.
9. Agenda for F2F
DavidF: Need to start thinking about the agenda. Needs to be stable
by the 29th May. Send any agenda items to DavidF ASAP.
Would like to concentrate on proposals for resolving issues.
10. AOB
None. Closed