Minutes of XML Protocol F2F Meeting, 11-13 September 2001, held in the Novell Campus Conference Center, San Jose CA.
0. Roll call
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- BEA Systems David Orchard
- Canon Herve Ruellan
- Ericsson Research Canada Nilo Mitra
- Fujitsu Limited Kazunori Iwasa
- Hewlett Packard Stuart Williams
- IBM John Ibbotson
- IBM David Fallside
- IBM Doug Davis
- Intel Highland Mary Mountain
- Interwoven Ron Daniel (partial)
- IONA Technologies Oisin Hurley
- Martsoft Jin Yu
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Microsoft Corporation Paul Cotton
- Netscape Vidur Apparao (partial)
- Novell Scott Isaacson (partial)
- Novell Winston Bumpus (partial)
- Oracle Anish Karmarkar
- Propel Daniela Florescu (partial)
- SAP AG Gerd Hoelzing
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Tibco Frank DeRose
- W3C Yves Lafon
- W3C Hugo Haas
- Xerox Ugo Corda
- AT&T Michah Lerner
- BEA Systems Jags Ramnaryan
- Canon Jean-Jacques Moreau
- Fujitsu Limited Masahiko Narita
- Intel Randy Hall
- Interwoven Mark Hale (partial)
- IONA Technologies Eric Newcomer
- Netscape Ray Whitmer (partial)
- Oracle Jeff MischKinsky
- SAP AG Volker Wiechers
- Active Data Exchange Richard Martin
- Active Data Exchange Shane Sesta
- Compaq Yin-Leng Husband
- Compaq Kevin Perkins
- Data Research Associates Mark Needleman
- DevelopMentor Martin Gudgin
- DevelopMentor Don Box
- Engenia Software Jeffrey Kay
- Engenia Software Eric Jenkins
- IDOOX Jacek Kopecky
- IDOOX Miroslav Simek
- Informix Software Charles Campbell
- Library of Congress Ray Denenberg
- Lotus Development Noah Mendelsohn
- Macromedia Glen Daniels
- Macromedia Simeon Simeonov
- Mitre Marwan Sabbouh
- Mitre Paul Denning
- OMG Henry Lowe
- Philips Research Yasser alSafadi
- Philips Research Amr Yassin
- Rogue Wave Murali Janakiraman
- Software AG Michael Champion
- Software AG Dietmar Gaertner
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- Vitria Technology Inc. Tony Lee
- WebMethods Randy Waldrop
- DaimlerChrysler R. & Tech Mario Jeckle
- DaimlerChrysler R. & Tech Andreas Riegg
- Informix Software Soumitro Tagore
- Library of Congress Rich Greenfield
- Rogue Wave Patrick Thompson
- Vitria Technology Inc. Richard Koo
- WebMethods Dave Cleary
|Tuesday, September 11th
|Morning Session I, 8.30a - 10.15a
- Local arrangements
- Assign scribes
- Review agenda; AOB?
- Approve minutes from Sept 5 telcon 
- Action items 
- Schedule review, see  
- Publication. What do we publish, and what changes
are needed in order to publication?
- XML SOAP 1.2, Ed. Copy Part 1 
- XML SOAP 1.2, Ed. Copy Part 2 
- XML SOAP 1.2, Ed. Copy Primer  (TBD)
- XML Protocol Abstract Model, Ed. Copy 
- XML Protocol Requirements, Ed. Copy 
|Break, 10.15a - 10.45a
|Morning Session II, 10.45a - 12.30p
- Publication /cont ....
- Resolution of issues, see Issue List .
- 25: clarify status of trailers. The
first proposal for handling trailers was prepared for the Dinard f2f  which was discussed briefly
at the f2f (see "Discussion of Issue #25 Trailers" in ) and consequently a new proposal was put forward . The latter generated much
email discussion (see threads starting at  and ).
- 22 and
95: SOAPAction. This was
discussed extensively at the Dinard f2f, and resulted in various "optional" and "deprecated" (loosely
defined) proposals . A new proposal has recently been put forward , and we will start with this. The
chair proposes that discussion on this topic be time-limited, and reminds participants to focus
on finding a commonly acceptable resolution.
- 4: specify action upon
encountering a DTD or PI.
- 77: clarify handling of 'midstream' errors
- 93: mU at client. Proposal 
was prepared for Dinard, but not discussed.
- The following 3 issues are binding issues but will be considered by the larger WG for resolution.
- 11(1st design issue): use of port 80; see also,
13: http port. Material was prepared for
Dinard f2f .
- 12: http error codes. Material
on this issue was created for the Dinard f2f . One
commentator says "Discussion of this issue tends to be polarised and has
lead to threads that have become 'exausted' without conclusion eg.  .
I also believe that viewspoints on the resolution of this issue are linked
with the viewpoints on the SOAP as a 'cameleon' protocol that takes on the
'character' of what it is bound to or as a 'platform' protocol that provides
messaging services that are largely independent of the underlying protocol.
This theme also leads to lenghty threads eg. ".
- 71: identifying blocks for processing. See
member thread and
public thread in mail archives.
- 73: identifying blocks for intermediaries without
complete message processing.
- 62: mU for extensions. Do we accept Oisin's proposed resolution?
- 63: standard failure for extensions. Do we accept Oisin's proposed resolution?
- 107: Clarify terms .... See telcon agenda
- 134: XMLBase support. Status of
investigations, see telcon minutes
|Lunch, 12.30p - 1.30p
|Afternoon Session I, 1.30p - 3.00p
|Break, 3.00p - 3.30p
|Afternoon Session II, 3.30p - 5.00p
|Wednesday, September 12th
|Morning Session I, 8.30a - 10.15a
|Break, 10.15a - 10.45a
|Morning Session II, 10.45a - 12.30p
|Lunch, 12.30p - 1.30p
|Afternoon Session I, 1.30p - 3.00p
|Break, 3.00p - 3.30p
|Afternoon Session II, 3.30p - 5.00p
- SOAP Underlying Protocol Binding Framework (See )
|Evening: WG Dinner?
|Thursday, September 13th
|Morning Session I, 8.30a - 10.15a
- TBTF cont/....
- RPC task force proposal review, see
- rpc:result, see Action Item 1 in  and references therein. Provides resolution to issues
- Relationship of Section 5 to Section 7, see Action Item 2 in , (proposal pending)
- Issue 78: Ordering of structs,
(dependent on Section 5/7 relation)
|Break, 10.15a - 10.45a
|Morning Session II, 10.45a - 12.30p
- RPCTF cont/....
- Review of conformance proposal, see  
|Lunch, 12.30p - 1.30p
|Afternoon Session I, 1.30p - 3.00p
- Usage Scenarios. The WG has created a number of scenarios  for
the purposes of ensuring that XMLP can actually deal with
applications and services found in the real-world, and to provide
a better understanding of XMLP's role in such situations. Time
permitting, we will break into smaller groups to draft
descriptions of XMLP used in various scenarios.
|Break, 3.00p - 3.30p
|Afternoon Session II, 3.30p - 5.00p
- Usage Scenarios cont/ ....
DAY 1: Tuesday September 11 (Frank DeRose scribe)
1. David reviewed agenda.
Items on the agenda include:
PUBLICATION OF DOCUMENTS
RESOLUTION OF ISSUES
PRESENTATION OF BINDING TF
PRESENTATION OF RPC TF
David discussed status of issues list.
MarkN suggested an AOB item in which we discuss Larry Masinter's message
asking for feedback on SOAP BEEP binding.
2. Minutes of September 5 telcon were reviewed. They stand as posted.
3. Action items were reviewed.
Action item 1: status unchanged. Adjuncts is still the working title for
part 2. We decided to discuss further when we discuss publication.
Action item 2: status unchanged.
Action item 3: Action item was completed.
Action item 4: status unchanged.
Action item 5: still pending, we don't expect anything on that yet
Action item 6: XML base is on the agenda for day 2 of the f2f.
Action item 7: status unchanged.
Action item 8: status unchanged.
Action item 9: completed.
Action item 10: completed.
Action item 11: Hugo closed and then reopened issue 45 due to an email from
Rich Salz. Hugo will take an action item to close issue 45 and the editors
will make the appropriate editorial change.
Action item 12: status unchanged.
4. XMLP WG Schedule review
David noted that the binding and RPC task forces had not yet completed their
David noted that editors need to get edits into the document in preparation
Paul Cotton noted that we need to consider whether the namespace URI's need
to get changed when we publish.
David: Before we go into Last Call in November, we need to:
-resolve _all_ issues on issues list
-figure out what to do with Abstract Model (document)
-finish work on transport bindings
-finish work on RPC
-finish work on encoding
F2F for going into Last Call is in November, in Burlington Mass. Details
posted on web site.
5. Discussion of publication
David proposed we publish Parts 1 and 2 of spec. Noted that AM draft is
awaiting completion of several pieces of work. It is premature to rev the WD
of the abstract model, and we will start work on usage scenarios in
Requirements Document during the f2f.
Stuart asked if any changes had been made to requirements document. David
said minimal, if any, changes were made.
Decision was made to promote Editors copies of parts 1 and 2 to WD (modulo
any changes we will make as a result of discussions at this f2f).
Ugo expressed concern about schedule of primer. David suggested that we not
hold up other documents by waiting for primer.
Went through issues that might stand in the way of publication of parts 1
Paul asked: Have any changes have been made to the namespace? Should we
change the namespace URI to align it with publication date?
Hugo stated: He didn't think that any significant changes had been made to
Paul stated: He didn't think it was necessary to change the URI if the
namespace had not changed.
We need to check the August 30 change to the documents. There was a new
element declaration. There was an element in the document that was not in
the schema. No declaration for the fault element.
Hugo raised issue 100 (clarification of the processing model).
Paul noted that any decisions we might make were pending changes that we would
make at the f2f.
Mark expressed agreement with Hugo that a URI change might be required by
Henrik suggested we ask implementors of SOAP 1.2 if a namespace change
would cause problems.
Doug Davis stated that issue 100 had already impacted Apache/Axis code.
Ron Daniel said we should establish a golden namespace that would be our
We took a poll on changing the namespace. 40% voted to change it, 30% said
they didn't care. No one or very few said don't change it. The Chair took
these numbers to mean that we change the namespace.
Chris Ferris said we should lay out a plan for how we are going to cycle
through namespaces between revs.
Mark Jones brought up an issue with the last paragraph of Section 2 in part 1.
Mark Jones will generate a description of the issue and submit it. The issue
concerned the fact that this paragraph states that relayed SOAP messages MUST
contain all SOAP header blocks.
Marc Hadley brought up the issue of the title of Part 2. This is the issue of
what to call Part 2. Possibilities include:
HTTP Binding, Encoding, RPC
Henrik pointed out that when we pointed this document as a rec, we would not
change its name. If you change the title, it's a different entity.
Doug Davis raised the issue: What will happen to the title when a new
transport binding is added?
Henrik: The new transport binding could go into yet a separate document.
HTTP Bind, Encoding, RPC: 4
No one strongly objected to either title.
David: There is definitely a preponderance in favor of "Adjuncts." So, chair
took that as a decision that we use "Adjuncts" for the WD.
Marc Hadley: Is it permissible to have a WD go out with placeholders, e.g. for
TBTF, Data model?
Henrik and Frank will get together to propose text by Thursday (Sept 13) for
the Data Model section of Part 2.
Marc Hadley: Should we remove Section 7 of Part 2 ("Security Considerations")?
Suggests we just drop it.
Chris Ferris: We should refer to security considerations in the binding
sections. Something on security should be added to the binding framework and
to specific bindings.
Marc Hadley: Perhaps a new security subsection to Section 6 (the HTTP binding
Henrik: We need to call out that SOAP doesn't provide a security framework
and that there are issues with HTTP security.
David: Proposal in 3 parts:
i) Remove existing Section 7.
ii) Add section discussing security to binding framework.
iii) Each individual binding would have a security section.
Part 1 should contain a statement that SOAP provides no security provision.
SOAP framework can be used to implement various kinds of security services
(integrity, encryption). A section should be added to the binding framework
that states that security shall be a consideration for a binding.
Marc: Wording and terminology in Encoding and Binding sections are not
consistent with the rest of the document. They are not written in terms of
Editors should add text noting that the reason for the inconsistency is
because we haven't rewritten these sections yet.
We agreed to publish Parts 1 and 2 as WDs.
6. Discussion of issues
Issue 25, status of trailers.
Anish Karmarkar gave presentation on the issue [Issue 25].
Henrik: In favor of 2nd Proposal, Choice 1 or Choice 2.
Oisin: In favor of 2nd Proposal, Choice 2
Marc Hadley: Do we know if anyone is using trailers? In favor of 2nd Proposal,
Henrik: Classic scenario: sign body block and put signature in trailer.
DSIG group will probably not do this, but will use a MIME based mechanism
Mark Jones: If you can rewrite bodies, you can always tuck trailer material
into a body.
Hugo: Procedural remark. Issue 101 and 82, difference between header and body.
Should we talk about the distinction between header, body, and trailers?
Marc Hadley: If distinction between header and body goes away, then everything
is a block and the distinction of a trailer disappears.
Chris Ferris: In favor of 2nd Proposal, Choice 2.
Mark Jones: If you take away trailers, you make it more difficult for memory
constrained devices to stream.
Oisin: Suggest introducing streaming strategy into spec. Stream this message,
but define granularity (element at a time, Body at a time, MIME entity at a
Frank: Must trailers be targets of references? If not, must processing rules
be defined to dictate how the trailers are targetted and processed?
Oisin: If we should do trailers, we should define processing for them at the
same level of detail as for headers. But, we don't need to do trailers.
Mark Jones: All control information should go into the envelope, all
the big data should go into attachments.
David Fallside summarizes:
i) Proposal 3 from Anish.
ii) Proposal 2, Choice 2.
iii) Proposal 2, Choice 1.
iv) Suggestion from Henrik: solicit feedback on actual use of trailers.
v) Concern that the trailer issue should be bundled with issue 82 and 101.
Doug Davis: Why can't we just not say anything about it?
Stuart Williams: Can we serialize trailers as Body items?
Nilo Mitra: When we validate usage scenarios, we can see if we can do all
usage scenarios differently than through trailers.
Decision: (Option iv) We will solicit feedback from the user community,
through an ednote in the spec. We will remove trailers (elements after the
body) from spec/schema, we may re-instate them if we receive strong feedback
to the contrary.
-- Issues 95 and 22, SOAPAction
Doug Davis gave presentation on the issue [issue95-22].
Marc Hadley: If we allow people to require SOAPAction, how will they specify
Henrik: We don't have to define how they will specify it.
Mark Nottingham: SOAPAction exists in many implementations, but the
implementors don't know where it is going.
Mark Jones: If we are not going to make SOAPAction normative, why mention
anything more than that we are not making it normative anymore.
Oisin: SOAPAction is an HTTP thing. If we want to formalize SOAPAction, we
have to discuss the reasons why it doesn't go into the envelope. Either it is
an HTTP specific thing, or it is a SOAP specific thing.
Henrik: agrees that SOAPAction is an HTTP specific thing.
Chris Ferris: There is no corollary for SOAPAction in SOAP itself. Not
representing it in SOAP and then popping it in to the HTTP binding is
Oisin: SOAPAction should be used as some hint. Do we retain the concept of a
hint? Then, we decide where to put SOAPAction.
Marc Hadley: The point of SOAPAction is so that you don't have to parse the
Mark Nottingham: We should remove SOAPAction.
Henrik: Avoid having recipient parse the whole body.
Vidur: Doesn't buy that you need a hint. You already have a hint.
Ugo: Concerned with hint. It is an unclear specification of what to do.
Mark Jones: This is just one class of hint. What about hints for streaming?
A general mechanism for specifying a hint in general.
Mark Nottingham: This feels like a feature in search of a need.
Chris Ferris: Could be a hint to a firewall. Perhaps it should be an attribute
of the envelope. You could get at it very quickly.
Doug Davis: A service provider can require SOAPAction even if we forbid it.
Henrik: Let's not rehash these arguments.
Frank: We need a hinting mechanism, but it needs to stand outside of HTTP.
Anish: Putting SOAPAction inside of the envelope means that there will be some
HTTP handlers that can't get at it.
John Ibbottson: Pointed out that ebXML used MIME Content-Type.
Chris Ferris: What's needed is a way of expressing a binding across
Henrik: You must register a Content-Type. One of the ideas in SOAP was to
allow people to send content type without having to register.
David Fallside recapitulates:
Things desired are: Backwards compatibility: General hint mechanism: Should
we standardize it
??: If SOAPAction didn't exist, it could still be required. We have to split
out the various claims on SOAPAction.
Highland: We need to concentrate on how we make the transition to a new rev
of the spec.
Marc Hadley: By making SOAPAction optional, we require an SDL.
Oisin: If a binding requires an additional HTTP header, it will be a different
binding from our canonical HTTP binding.
Mark Jones: A service description ought to be able to require any extra headers
it wants (including SOAPAction).
Ugo: What is the problem with dropping SOAPAction completely from the spec.
Henrik: Not in favor of dropping it. Wants to focus on the particular header.
Mark Nottingham: The presence of SOAPAction header in a message is optional,
but support for it in conformant implementations is required.
John Ibbotson: Any reference to SOAPAction in new version of spec requires
that the reader be familiar with previous versions.
Henrik: Does not want to dodge issue. Saying that people can do whatever they
want is not a viable option. We need to come up with an answer to what people
can do with SOAPAction.
Marc Hadley: Wants to have it optional at the discretion of the sender.
Highland: We are talking about a binding that was defined before the binding
framework existed. If we accept the proposal, it would sound like SOAPAction
could not be required in any binding.
Ugo: Why don't we keep SOAPAction as an optional HTTP header?
Oisin: Suggested edits to Doug's proposal.
Henrik: Expresses strong objections. We cannot mandate that no one can use
David discussed how to make progress on this issue with various individuals
Discussion of SOAPAction is postponed until Thursday. Various interested
individuals will meet Wednesday evening to discuss issue 25 further.
Issue 4, action upon encountering PI or DTD
Marc Hadley: Will take it as an action item to summarize the various issues
surrounding issue 4.
Paul Cotton: PI's are the only way the W3C mandates to include style sheets.
Issue 77, clarify handling of midstream errors
Suggested Proposal: A SOAP processor can only process a whole SOAP message.
A SOAP processor receiving a fragment of a SOAP message MUST discard it.
Frank: What happens if the SOAP message contains references to attachments
that don't exist.
Henrik and MarkN took an action to draft a proposal by Monday 17 Sept, in time
for the next telcon.
DAY 2: Wednesday 12 September (Stuart Williams scribe)
Meeting Start 09:00 PDT
Issue 93, MU Fault at Client
Doug: Presents his summary and proposal [issue93]
Only issue with proposal "Basically, leave it as it is." is if a client
chooses to ignore a mustUnderstand fault... is that a violation of the spec?
DF: I'm a little confused. "Server", "Client": what do we have to say about
DF: Still client/server distinction makes no sense to me.
HFN: Probably meaning HTTP client, HTTP server.
DD: If the receiver ???
MH: Should we be adding this to the HTTP binding spec. Basically, is the
binding the right place to be addressing.
DD: Well... yes but it may be appropriate to other bindings.
JI: So if we're regarding SOAP as fundementally one-way then we don't have
a request/response distinction and the recipient (of the mU fault) must
respond in accorandance to the SOAP processing model.
HFN: SOAP is fundementally one-way and the SOAP spec speaks carefully about
the distinction between the generation of a fault and what to do with a fault
once it has been generated.
DD: Server-side RPC at least implies that.
DF: I'm hearing from folks that there are different views of what is the right
thing to do depending on context.
OH: Need to take the view point of what should happen at a SOAP Node. We
probably need to explore this more fully. In context of RPC client/RPC
DD: I think that we're all in agreement that we can't ignore a mustUnderstand
DF: Do we need to put something about this in the RPC section?
HFN: I believe that it is already the case that we do say something.
Doug takes an action to send email back to Paul K indicating that the spec
already covers the issue.
Assent by WG.
DF: Given the amount of email received on this issue, not concerned about
consulting wider WG on this resolution.
-- Issues 11 and 13, use of port 80 and http port
Mark Nottingham presents on 11 and 13
With regard issue 11, Larry Masinter is basically suggesting that we use a
different port than default port 80. These issues have been around for some
time. IANA... Semantics of a Port. Large cavaet... ports are used by
administrators for a bunch of other things/concerns (access contol, QoS,
added value...). HTTP is not confined by definition to use on port 80 alone.
MN has talked to IETF on this topic (Keith Moore)... best-practice ID on use
of HTTP and port 80
DF: Who is the intended audience? (re Keith's ID)
MN: Primarily protocol designers...
DF: cf. Net Admins... this ID doesn't quite jive with current practice.
HFN: This draft has been around for some time... about 4 years... it's now
expired. Various people have had problems with the ID throughout its life.
Mark Jones: Why is this an issue for us? Can we be silent on the what port
issue and defer it to things like WSDL.
MN: I think that the problem is that if we make no statement in our spec.
folks will just default to using port 80.
HFN: ...broadly reuse of port 80 is probably 'worst' practice....
Ugo: Clarification: Is there clarification of what is a 'true' HTTP
MN: Pro Port 80 arguments from presentation...
Against Port 80 arguments from presentation...
Firewall scenarios from presentation...
HFN: offers example of hotel proxies...
MN: A much more often use of interception proxies that what to enforce caching
MN: Proposal One: Status Quo + Health Warning
MN: ...if you are concerned about the these issues my recommendation would be
to use explicit
MN: Proposal Two: New default port and URI scheme for SOAP and allow http://
and port 80 when necessary and with caveats.
MN: Questions for the WG (from presentation...)
DF: A couple of proposal on the table and implicitly the status quo...
HFN: Like to strongly advocate don't come up with a new port and a new uri
scheme. I see no indication whatsoever that any of the security issues etc.
would be addressed by a new port and URI scheme. We cannot address the
intrinsic architectural issues of port numbers.
MN: Tend to agree...
Frank: Would like someone to speak a little to the pain that a new URI scheme
would causes. Also re registration of new default, would be be insisting upon
MN: In a spec we would inform of registration of URL scheme and default port
and perhaps SHOULD or should wrt to their use.
MN: Pain of URI scheme is to implementors because they would have to write
software to handle a new URI scheme and to deployed applications.
YL: It takes several months to do a new URI scheme...
HFN: In general, interesting issues over URIs and not done properly new URI
schemes can be a huge kludge.
Ugo: Does the suggestion of a new URI scheme only come from Larry M?
MN: No, there others. There are only a limited number of people in the IETF
who think deeply about URI schemes.
Mark Jones: I think you'd only want to introduce a new URI scheme if you were
creating a new binding.
JI: Would a new URI scheme help at all with other issues like SOAPAction and
Frank: Nothing prevents us doing this prevents us doing this in two parts: new
port existing scheme...
MN: No... the scheme implies defaults, no-defaults imply port numbers in URIs
Frank: ebXML related issues...
DF: Sense that main force of opinion is to take a softer route along the lines
of a health warning. Our sense seems to be that there are associated deeper
issues around new port numbers and URI schemes that are outside our ability to
Ugo: So... going to a new port doesn't necessarily imply a new scheme.
MN: Certainly, not all ports have a URI scheme...
HFN: But that means that everybody will now have to use two ports because we
no longer know which ports are in use.
Discussion of how you would choose which ports to use.
Gerd: I believe it makes no sense to register a new port for the HTTP binding
for SOAP. We might be interested in a new port for SOAP independent of the
binding. It only makes sense to me for a protocol binding independent SOAP
MarkJ: So... if we're going down the route of proposing an alternate port for
SOAP/HTTP... do we do the same for SMTP.
MN: Couple of things about the two proposal. Proposal One... we ought to
associate the health-warning with the binding framework itself.
Anous: Should be careful about what we encourage.
DF: Dissent on proposal one?
DF: Mark, does this proposal apply to issues 11 and 13?
DF: Ammend wording from proposal #1 to be more generic relative to Mark Jones
observation on other protocols
ACTION: MN to draft text around proposal one for next telecon.
Discussion on considerations of alternate ports.
Thank you Mark...
Issue 12, HTTP Error Codes
Presentation from Stuart
Discussion about whether intermediaries really rewrite content based on
OH: Isn't usage of 500 a hint ?
SW: People have different opinions on this.
MN: What is the utility of using 500 ? Why do people really NEED to do this.
Leaning towards opinion that code is a hint to HTTP application code -
potentially dangerous. Prefer all 200 solution since this doesn't give
OH: Reason this has not proved a problem is because all WS are simple at the
HN: Why is this different to a WS for buying a plane ?
OH: Two are quite different use cases. They are qualitatively different
CF: Doesn't IE rewrite body content ?
HN: No, only when body is empty.
CF: Concerned that client may have difficulty in causing 500 to be emitted.
FD: In favour of 200 solution. 500 opens possibility for HTTP processing to
get in the way of SOAP.
HN: HTTP is HTTP. Browsers may deal with them in different ways, but other
HTTP clients don't have to.
FD: Can't believe that this problem will never occur.
HC: In favour of 200. Keeps clean separation. We shouldn't get into business
of mapping underlying protocol semantics.
DO: In favour of 500. Fits more naturally with what HTTP is about.
YL: Then we need 400 codes for each error ?
MN: Where do we stop ?
HN: We are playing in HTTP, so need to use HTTP semantics.
???: In favour of 200. If we choose 500 then also need 400 codes...
Break... (Discussion on the art of consensus)
DF: Frames a non-binding strawpoll.
Pro 2xx More than half present; A couple of people could not live with this
Pro 5xx Little interest:
DF: Reminds that we are low on attendees. Propose to look at some mixed usage.
Ugo: Seems to be an issue that we should examine in the more general context
of other bindings. May be clear choices in the case of HTTP. If we take a
different protocol with entirely different status semantic....
DF: We will try to bear that in mind.
Gerd: For me this is a real binding problem. This is something we should as
for a recommendation from the TBTF. I'm not sure that only 2xx or only 5xx is
the right thing to do.
DF: If we do decide to go the mixed route then we will need a proposal.
Frank: I disagree with the basic premise that we have two approaches. I would
be opposed to the mixed solution. I would also disagree that if we were to say
go with a 5xx approach that choice/logic also applies across other protocol
DF: Do I take it that you 'cannot live with' a mixed solution.
DF: Is there any dissent to going with a mixed solution....
MH: Just a comment... that does sound like a horrible political solution than
a good tech. soln.
David Orchard: Actually to me it sounds like a good technical solution.
DF: Well... yes to be blunt this does come down to some politics about some
give and some take. I would love to get to the point where we have a technical
solution. But, I'm not hearing one at the moment.
Chris Ferris: Referes to his TBTF HTTP binding protocol proposal for use of a
broader range of status codes and that 5xx is *not* a good catch all.
HFN: I like that... I think this (mixed approach) is a good approach. I think
pitching it as 200 v 500 is the wrong framing. We don't really have a crisp
defn of when to send a SOAP Fault. We don't have crisp defnitions of many
things. The same is true of HTTP where there are no strict rules about when to
use particular HTTP status codes.
SW: Just a reminder that the focal point for framing this issue
Frank: There is (or should be) a clean separation between SOAP generating SOAP
faults and HTTP generating HTTP status codes.
Winston Bumpus (new Novell rep): Introduces self. Question from DSML doing
LDAP in SOAP... when do you use a SOAP fault when you have errors within DSML
WB: Seeking clarification of whether SOAP Faults should be used for
DF: ...so in response to the question... "who the hell does generate a SOAP
OH: even more important having generated one... where the hell do we send it.
Frank: Error propagation...
HFN: So... the problem probably is that layering just doesn't work for us.
DF: We now seem to be drawing back from a more fine grained proposal.
MH: For me, the layer makes life simpler. What causes the confusion is the
mixing of them all up together.
DF: ...So I think the layer confusion, particular wrt HTTP is that people have
different views. Some people simply see HTTP as a transport below an
application layer and some people see it as reaching much further up into the
MH: That seems a good characterisation...
MN: I can't disagree with Henrik's reasoning. My objection comes from
operational considerations. Operationally people might take the semantics of
status codes to mean something that is typical to the web, but not whose
meaning is different for SOAP. Layering, I think, is a bit of a red-herring.
ChrisF: ...can we view the 500 as a bit of a hint so that the recipient of a
Some discussion around the Mark Baker proposal... acknowledgment that 3rd
option should have been more broadly framed than just 2xx and 5xx.
DF: Addressing HFN: Have you looked at Mark B's proposal and is it a helpful
way to go forward?
HFN: I've read it an spoken to Mark ....there is as some merit in the direction
of his proposal.
DF: Addressing Marc Hadley: Have you read Mark's proposal? [Yes], Mark has not
framed that as a political kludge.
MH: I think Mark's viewpoint is very much non-layerist - quotes...
MH: I would be prepared to explore Mark's proposal.
CF: It seems to be consistent with what I had previously proposed.
DF: Suggest we take a closer look at Mark's message. We will take this matter
to email and address it again in next week's telcon. We could take half an hour
to look at it.
CF: I'd also offer as a starting point the HTTP binding proposal that I made.
It's also somewhat consistent with Mark's proposal.
DO: We could spin off a small group to look at it today....
DF: We could certainly do that... anyone willing to do that tonight...
DF: I think we are already occupied this evening.
ACTION: Hugo to send message to WG with references to Mark Baker's email and
Chris Ferris's HTTP binding proposal indicating that we would like discussion
of these in time for the next telcon.
-- Issues 62 and 63, MU for extensions and standard failure for extensions
DF: Oisin, you had proposals for both of these at Dinard
OH: I understood that these Issues were in fact closed. The rewording of the
handling of mustUnderstand has really closed Issue 62. There has been no major
discussion of issue 63. We don't have a very rich failure model, but we do have
a faulure model. I think that more urgently we don't have a client and server
per-se and we have no way to know where that fault needs to be sent. I do think
that we need to be more explicit about that. Basically, on 63, I think that
that particular issues has been closed... Neither of these topics have been
the subject of significant discussion.
MH: Just to remind us that from Dinard we added more text/mechanism to more
accurately identify what has not been understood.
DF: Summary: Issue 62 resolved by mustUnderstand text. Issue 63 resolved by
additional text on mustUnderstand faults
ACTION: Oisin to communicate resolution to xml-dist-app.
Issue 71, identifying blocks for processing
DF: Hugo... you seem to have been tracking this issue.
HH: This is an issue about reserving particular URIs for particular roles. eg.
.../none and also consume and re-insert. Some folks objected about both...
mainly Henrik. Mark Jones noted that not providing an explicit actor imlicitly
targets the ultimate recipient; Re: consume and re-insert... that can be
deligated to a module/block definition.
MN: On the .../none one I think I can see why that might be useful and it is
low-cost for us. On the consume/re-insert seems to impose the semantics of
re-insertion on the actor. I think that our processing model may be, by design,
underspecified. We don't give much in the way of guidelines of how to do, say,
HFN: Just to clarify my position on the .../none thing, I was not taking a
position... I was just looking for real world scenarios that motivated the
MarkJ: I have some... eg. some shared authentication intended for multiple
intermediaties where I don't want the block removed along the path.
MN: In general that's the sort of scenario I had in mind, but I'm not so
convinced about the particular authentication example.
HFN: I'm not so sure how that differs from what we already have. We don't
really define what processing means. So if I have say a purchase order
referenced from multiple places... we don't say what processing that block
MJ: But... we do have a semantic model of what targetting a block means and
here we have a block that is *not* targetted at anyone. If we simply leave it
pointing at the default actor then we are targetting at the final
DF: Would these block have mustUndertstand attributes?
MJ: ...well no... more discussion.
HFN: Ok... so you have different semantics going in... but what comes out
might be the same.
DF: So is the heart of issue 71 that we have a .../none or ../any actor.
MN: 71 is about of bunch of things.
HH: 71 had 3 things to it that reduced to 2.
MN: I think that we have a fairly complete set of actors in the core spec.
perhaps with the exception of none.
DF: Need a clarification, last weeks telcon agenda showed 3 parts to Issue 71.
HH: What I committed to was getting further clarification on the issue from
MarkN and he responded.
MN: Propose that we define the .../none actor and close the issue.
MN: Regarding the first part (evaluation ordering) I think that has been
resolved previously... in Dinard closing that part of this issue.
HH: Quotes from minutes of 29th August on processing order.
DF: OK. Seem to be support for .../none actor. More discussion... ?
MN: SOAP Nodes may not consider themselves targetted by such block.
ACTION: Mark Nottingham to write this one up.
DF: Is this something we could see tommorrow...?
MN: Hmmm.... yes.
Issue 134, XMLBase support
DO: Update on XML Base.... XML Core WG unanimously voted that should XMLP-WG
choose to preclude of xml:base on the Envelope, Body and Header elements the
CG consider that that would be a bad thing to do.
DO: Reads XML CG minutes [http://lists.w3.org/Archives/Public/xml-dist-app/2001Sep/0078.html]
DF: This appears to be some push back from the XML CG.
12:30 Break for Lunch:
Issue 4, action upon encountering DTD or PI
MH: Presentation [@@]. Resolution for DTD's seems clear... ie disallow. Case
for PIs. Case against PIs. Proposal that a SOAP processor generate a fault on
the presense of DTD's or PI.
CF: Quotes W3C Stylesheet Rec for associating stylesheets with XML documents.
Suggest that we ask the XML CG for an opinion.
MH: That doesn't resolve the issue.
CF: Withdraws suggestion.
HFN: Might need to allow for stylesheet PI case.
MN: The rec states there are other ways of associating a stylesheet with a
document. One could conceive of an architected approach with say a module.
HFN: But that would make SOAP different... which might not be necessarily
MH: Use cases?
HFN: Maybe you wants some presentation component with your message...
Ugo: I don't think that the common practice is to use the PI approach because
that hard-codes the stylesheet to the document.
JI: There are potentially applications where you want to associate a
stylesheet with a message.
MH: But you might not want to us PIs to do that.
HFN: I think Chris brought up a good point that we consult XML CG. We don't
want to be in a one-off situation.
DF: My understanding is not about whether we were going to revisit allowing
the use of PIs. The issues is about what to do if a PI were to show up.
HFN: So what did you do for Schema.
DF: Well that was about associating a Schema with a PI... doesn't really apply.
SKW: Only other reasonable way to handle PIs is to ignore them.
CF: Having to seek them out is more complex when you can safely ignore them...
suggest we simply ignore them.
HFN: (to Marc) so why not ignore them.
MH: Well the framing was about handling DTD's and PIs to together... we could
DF: Is this an issue more egenral to XML?
CF: Don't want to preclude the containment of a DTD as part of the payload -
ie. not associated with the validation of this message, but as payload
Discussion... CDATA and base64 inclusion...
HFN: Is there wording we can leverage from elsewhere rather than having to
DF: Is it enough to say that SOAP message is defined by the envelope schema.
MH: We have a statement about not imposing a Schema validation requirement.
DF: We seem to be falling in two places: Status Quo... do no damage... pick
up on further general resolution of this type of issue in the XML environment
MH: The issue asks what should we do if one of these things DTD, PI, shows up.
MH: We could say that PI's are ignored. Don't think we can say that DTDs are
DF: Dug... any idea what Axis does with PI's and DTDs?
DD: I believe it ignores them.
MH: So do you turn off validation by the parser?
DD: I believe so.
DF: So this is a proposal that the presence of both DTD's and PIs simply be
SKW: So how about other major SOAP implementations... what do they do currently.
CF: External entities etc. could be really gnarly... I think I'm comfortable
with not allowing DTDs, but you are requiring that we explicitly look for DTDs.
I don't think you can really tell an XML parser to ignore them.
HFN: (missed comment)
CF: I think that what we're saying that is that an XML Protocol message must
carry all the information destined for the XML Infoset explicitly in the
Ugo: Yes that's how I would approach it, it's not to preclude implementations
that can do validation for doing validation.
DF:... I don't think that we yet understand this issue. These things are
happening at different levels. So thinking about the rationale for the
prohibition on DTDs was to prevent people from using DTD's to define the
content of a SOAP message.
CF: I am OK with a prohibition on both PIs and DTDs and that if a SOAP
processor receives one then the behaviour is undefined.
MH: But... that doesn't address the issue.
DF: It does it says its undefined ??
CF: It seems to impose some overhead to have to check for the absense of
DF: What do we need to do to resolve this?
MH: Take it to email...
ACTION: Marc Hadley to start Issue 4 thread on dist-app.
Issue 73, identifying blocks for intermediaries
MN: Issue about whether an intermediary needs to process (whatever that means)
the entire message. I think that with our processing model we can close this.
MN: Quotes relevant message. There was some discussion of this at the time
this came up...
MJ: Is this the header/body distinction?
MN: I think so... the other interpretation is that you don't have to parse
the entire message to determine whether some part of it is targetted at you.
DF: So your recommendation is that we close this.
No dissent recorded.
DF: Mark N take an action to report resolution and closure.
ACTION: Mark N report resolution and closure of Issue 73.
Issue 107, clarify terms
HH: Issue 107 is about a SOAP Node having to recognise all those blocks
targetted to it and the order in which it should process these. This issue
was addressed/resolved(?) in an email from Eric Jenkins... One thing that was
left to do was what the definition of a SOAP Application. Eric and Stuart
propose some definitions. Rolled on to an ACTION item on Chris F and Eric.
DD: The definition of SOAP Actor has changed somewhat to include a notion of
SKW: Aren't we trying to talk about the definition of SOAP Application.
HFN: So I understood that an action was raised against Eric and Chris.
CF: I think the issue can be closed... the AI arose separately from the
discussion and we can deal with this.
DF: In think folks are assuming that closure of this issue ispredicated on a
definition of SOAP Application.
HFN: Do we need to get a defn for SOAP Application... how much time do we
want to put into that?
DF: We seem to have circled this one several times and there seems to be a
DF: So... close 107 and raise new issue on SOAP Application defn.
ACTION: Hugo close issue 107 and open a new issue for a defn of SOAP
Issue 134, XMLBase support
DF: We are missing various inputs, so we will defer discussion of Issue 134.
7. Report from TBTF
DF: Recommendation etc from TBTF.... Mark N to present. Expectation is that
this will go into Part 1 of the spec. There is a place holder at Section 5.
We need to look at this proposal and evaluate it on its merits.
MN: Proposal for a binding framework. This is fairly new... given the date.
Mark walks through Framework document dated 2001/08/31 19:57:00 [Binding Framework] It is
important to note that this is descriptive framework. There is no requirement
that implementations be layered/structured in this way.
JI: Considering SOAP with Attachments...
MN: TBTF members... anyone want to speak...
MN: Elaborates on
MJ: I understand (big B) Binding as a way of mapping that XML Infoset through
whatever layers are required. We don't currently have a 'drill-down' how these
things happen. We don't have a composition model.
Frank: I think that say with MIME its the packaging that drives things not SOAP
CF: The XML Infoset which the envelope itself is augmented with a set of named
properties one of which could be named attachements whose value was then a
structure that represented
MJ: That's one view of this... I tend to think of this as an XML Infoset and
that it's down to the binding to make the choice of whether it leaves it in
the envelope or serialises it into an attachment or whatever.
CF: Well they are both reasonable abstractions... the main divide seems to be
around big B bindings and a nestable composition model. Is that fair Henrik?
HFN: It's a fair characterisation. There is still lots to discuss... document
here outlines the pillars of the house.
Frank: I think that this picture is way too SOAP-centric. I have a tendency to
look at it with an ebXML approach with a packaging framework pulling 'content'
from multiple places... (word pictures).
MN: resumes presentation...
DD: Can you give an example of a property...
HFN: Tries to move focus down to features...
JI: Is the assumption that the binding layer does nothing with the XML? Can
the binding add things into the envelope based on the value of the properties.
eg. request/response correlation when the underlying protocol doesn't do this
MN: resumes on features...
MN: I think this speaks towards John's question...
JI: So this boundary is a bit fuzzy...
HFN: Another way to look at this is that you have this functionality/feature
that you need to use...
JI: Is a feature a combination of an Infoset and a property...?
More discussion on features, properties and expressions.
CF: Describes an authentication....
JI: So the binding layer does have the permission put these artifacts in the
MH: Yes that's what I think we wanted to say, but I don't think that that's
what the proposal text says.
MN: resumes presentation with request/response illustrative example...
Ugo: Looking at these examples, the focus seems to know about the two
immediate nodes, but seems not to know anything about relaying over multiple
MN: Composing multi-hop paths is something that we might leave to an extension...
JI: Key thing is the ability to re-create those the infoset and properties...
HFN: More general thing of characterising a protocol, such as SMTP, into a set
of properties... that is a difficult problem to do.
DD: Re: it is up to the communication nodes to decide how a set of features
OH: What I got from our discussion is that the binding is the contract.
CF: Lets take the attachments scenario that takes attachments in the form of
say DIME or MIME and the bindings may have to negotiate which particular form
of expression might apply in a particular case.
15:15 Afternooon Break.
DF: Would like to summarise where we are with the current TBTF proposal. Need
some basis for moving forward.
DD: Editorial comment on "node on it is up to the communication nodes..."
Discussion of properties in general - what are they and do we need to talk
about them. For example, the diagram indicates properties only come from SOAP
although they may come from elsewhere. Comment that the diagram should have
something off to the side (of SOAP) where properties can come from and go to.
DF: The proposal talks about an entity called "SOAP", but the proposal does
not say what is meant by the term SOAP as used in the proposal.
HFN: I think of it like a diagram that might be HTTP on TCP on IP... it's
showing a relationship.
DD: If you model a binding as being outside of the SOAP node/processor... how
do you answer John's question about whether a binding can put things inside
HFN: I don't think we have anything to say about that...
DF: We're making a very gross distinction in this diagram and we have had a
great deal of discussion on this which is why these things are so crudely
DF: Is this ready to go into the WD?
MH: No I don't think it's ready...
CF: Agree with MH.
DD: Would it possible to give some larger examples?
DF: Would inclusion of examples address Marc's concerns?
MH: It might. It is not yet enough of a framework.
Ugo: I would like to see a concrete example of a binding along with the
Winston: Multiple examples would good.
HFN: Agree that this needs more work. I'm not sure whether the end goal is to
come out with something that is implementable. This is not an implementation
Highland: To answer Winston's concern. When I came into this I had all sorts
of idea's about what I would expect to see in a binding. One thing that we
could do is to frame a template for writing a binding...
DD: I share the concern. If this meant to provide a template for a binding
then it doesn't do that.
CF: It is unfortunate that Noah and Glen are not here because they have a
mature vision of how this should go.
MH: That's true, but this document does not capture that vision.
DF: So the general feeling I have from the group is that this is not ready
for primetime (a WD) ... although to be fair to the TBTF, the commitment from
them was for a snapshot.
DF: So I haven't heard anyone saying that we shouldn't be doing this... only
that we need to provide more clarity.
Highland: I'd like to know whether it really is the will of the group that
this needs to be better explained or does it need to be better directed.
DF: I think both Glen and Noah would described this as a prescriptive
framework and that may not have come through in the description given here.
Maybe the thing to do is take these comments ,including the prescriptive
comment, back to Glen and Noah and the TBTF.
HFN: I just want to emphasis that this is indeed the case. Anyone who has been
on any of the calls will know that we have been going round in loops. We need
to figure out how to name things and the like.
DD: I'm wondering when you talk about 'how to name things' do we really need
to do that? Do we need to take on anything so grandiose.
HFN: I would tend to agree with you... but there is a spectrum of opinion in
DF: The SOAP 1.1 spec has one binding in it and says you can go forth and
create other bindings... but there is no guidance/framework... and there is a
reasonable point-of-view that says there should be such a thing.
DF: When we started out, we started with both ends of a spectrum... we had
some notion of binding independent features at one end...
DD: Interrupts... well that's not going to work... even the defn of a feature
DF: ... that was one end of a spectrum. Consider that I might wish to write a
binding that does one-way messaging over TCP. The mapping between what I want
and the natural features of the protocol are close. I might then want to do
request response over TCP and that will need more mechanism...
DD: So what does this framework do?
SKW: Its a descriptive framework. Its about how to write a transport binding
HFN: ... creates some bricks...
HFN: So we want to be able to describe binding to a variety of different
protocols with different features etc... The attempt is not to try an come up
with some uber protocol binding... that's several PhDs. The binding is about
the glue to link to features defined outside the envelope.
DD: ...Ok... but I don't see that it need be that complicated.
DF: I think that Henrik hit on a good point there, that to write a
prescriptive document about how to write any binding to any protocol... that
would be several PhDs... and a large number of mappings between natural
features of bindings and desired features .....
Ugo: The difficulty that I have is that it's kind of abstract and top down...
I'd rather work from some instances of bindings and then see if there is a
framework to be found!
DF: So to reiterate, we convey the general sentiment back to the TBTF. And we
note here that there are probably some characterisations of the proposal that
haven't been heard.
CF: So is the consencus that we're "barking up the right tree" or that we're
"out of our minds"?
DF: We have spent the whole period since break talking about this...
OH: The document doesn't seem very ripe... and ambiguities build on top of
each other... are we trying to achieve too much...
PC: If you are going to prove this approach by induction, then do it first
for K=1... I have a feeling that we're just going round in circles... so lets
Ugo: I think we should do at least 2. We need to do more than just HTTP.
PC: Minimum required for victory... we don't need this framework for victory.
DF: (Addressing TBTF members) Remind me what did the TBTF take as next steps?
CF: Message exchange patterns...
HFN: The other thing that I remember is composability and naming... people are
using MIME multi-part and things.
DF: My understanding is that more concrete bindings were a next-step to
HFN: ...I think composability... the red-box... what is inside the red-box.
Highland: I have the minutes... quotes next steps from minutes.
DF: It seems that the situation at the moment is that the Framework as
presented leads some to say that we should be doing an instance of binding...
MH: I think that we have done several instances of bindings. That's where we
JI: The kind of structure that I'd like to see is that you work it through
using the language that you are trying to promote in this framework.
DF: Is that what the WG would like to see?
DF: Since we don't seem to be converging on any recommendations for the TBTF,
the chair will take an action to draft a response to the TBTF.
ACTION DF to draft response including suggested next steps to the TBTF.
DF: Next item on the agenda is the RPCTF proposal, however Frank (RPCTF
presenter) has had to leave early. So, we will consider AOB items.
8. AOB item
Ugo: Suggest we discuss the SOAP/BEEP situation. Suggest we evaluate the
whether this binding helps us formulate our framework. Also, from the ???
MN: I have responded as an individual... the timing is unfortunate... it is a
binding of BEEP to SOAP 1.1 ...it's very surprising that this has been placed
on an IETF standards track.
HH: Mentions that the review of the SOAP/BEEP Binding was not
mentioned on the recent IETF/W3C coordination call.
CF: Eamon has been diligent in seeking feedback... I think that the spirit is
right... the timing is bad. The BEEP movement has its own schedule. We're on
MN: We are not slowing down BEEP. We might slow the standardisation of one
usage of BEEP.
PC: Without even looking at the document itself... the notice on this makes it
clear that this is a individual submission.
MN: ...describes IETF process wrt to individual submissions.
MN: Huge amount of discussion about this submission on the IETF lists.
MJ: What do you suggest, that we complain to the IETF?
MN: We could express the opinion of this group that it is inappropriate that
the IETF advance this toward a standard at this time.
PC: When is the next IETF/W3C coordination group? We may need to motivate an
HH: The last one was the day before this announcement came out. The next
meeting will probably not be before a couple of months.
MJ: I'd like to get a sense of the IETF/W3C politics on BEEP.
DF: So are we suggesting that our reponse is that this seems to be very poor
way to go about coordination?
WB: People seem to be implying deviousness here but from my interacitons with
Marshall I don't see that.
MN: I have tried to make progress on involvement with SOAP on BEEP... to no
HFN: This not talking about good/bad intent. The fact of an RFC # and
standards track has significant meaning.
PC: How many people think it should go forward as a standard?
CF: This has been out there for a while, its no big surprise...
PC: I want to know if there is anyone who could persuade their company to make
comments to the effect that this should not be advanced on a standards track
in the IETF.
CF: I note that our notion of a framework includes the message "go-forth,
knock yourself out and make a binding". So are we willing to work closely with
DF: You heard from Mark that he has been trying to do just that... and on
behalf of the WG... but without success.
DF: (To PC) With regard your question, was it directed at the WG and/or
PC: Both... you can go to the IETF, you can go to your W3C staff contact....
MN: Marshall claims that the first draft came out about 3 months ago,
recites various claims,...
MN: In large part the difference is the different standing of the two
documents: a W3C rec and an IETF STD.
DF: Closing comments...
WB: As president of the DMTF ... we struggle with the challenge of work in
progress and process.... I think that this promotes SOAP...
MN: Maybe we should just consider this as unfortunate coordination situation.
I apologise if I have lead the discussion in other directions.
HFN: Process issue due to status of substantively referenced documents -
SOAP 1.1 (W3C-Note), SOAP with Attachments (W3C-Note).
MN: This issue has been raised and discussed on the IETF list.
DF: We should also raise this as a coordination issue with W3C staff.
DAY 3: Thursday 13 September (Highland scribe)
9. RPC Results Proposal - Frank DeRose (Issues 16 and 113)
Proposal originated from an email dated 8/24 [@@], from the RPC TF:
According to the proposal, the response element (the struct that contains
the return value and all the [out] parameters) for an RPC, would be
constructed according to the following rules:
if the return type of the procedure is nonvoid
if the return value of the procedure is nonnull
rpc:result is present with nonempty content
else // the return value of the procedure is null
Alternative 1: rpc:result is present, with empty content, and with the
Alternative 2: rpc:result is omitted
else // the return type of the procedure is void
rpc:result is omitted
The main issue with this original proposal was that there was no distinction
between VOID and NULL (and/or NILL) return values. Another key point was
the expression and meaning of NULL/NILL values. Other working groups have
this on their agendas(ex. XML Query). We need to coordinate with these
other activities to ensure interoperability. Both should be treated as
The WG decided on an updated proposal to close out the AI. Mark Jones proposed
separating out the case of void fron non-void, as these two instances were
clear cut. In the case of void, leave out <rpc:result>. For the non-void, more
work is needed - possibly in consultation with other groups - to distinguish
between null, absent, nil. More precisely:
if the return value of the procedure is non-void
rpc:result is present (work has to be done to coordinate the
representation/meaning of NULL/NILL/absent values with other standard groups)
else // the return value of the procedure void
rpc:result is omitted
Reference was made to an email which called out all the different RPC return
element scenarios [http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0170.html].
In summary, it was agreed that the decided upon text was "in the Ballpark" for
the open AI 2.
A proposal was made to use IDL representation within section 7 to clarify
return values. This proposal did not progress beyond its suggestion.
Relation of section 5 to 7:
Henrik showed text for section 4 in part 2 to replace the editor's note which
says that it is a placeholder for a SOAP data model for which part 2 will
provide a particular encoding.
MarkJ wanted to know if there was a proposal for the methodology for the data
model. Would it be formal or informal?
Henrik said it would be along the lines of the current section 5.
Oisin improved the text "...defines the data model as a directed graph".
Frank says that the current text is "showing its age". Things like simple
values are described in great detail. We could make references to XML schema
for some things.
Henrik said that it is built on XML Schema for everything except the direct
graph case. Ugo concurred.
Frank says that sec 3.5 of the requirements doc should be referenced in the
proposed text. David said that doing so was appropriate. Text was added on the
spot. Editors directed to put the text in.
Issue 78 tabled.
10. Discussion on SOAPAction (SA)
Mark N provided text for sec 6.1.1/part 2 on SOAPAction reflecting the group's
discussion from previous night. Main points are:
- presence should be optional in the message
- optional in implementations; services cannot require it
- decided not to refer to its use in SOAP 1.1 and no reference to service
- need a new HTTP response header and a new response status code (427: SA
Paul C said that 3rd para of proposed text was testable. If you send a message
with or without SOAPAction, you get a deterministic response or 427.
Doug asked what happens if someone sends a SA when it is not required> What is
the correct response?
Henrik said that a server can ignore it.
Doug was concerned about cases where SA is not required, but changes the
processing because it was inserted by the client.
Henrik said that SA is an optimization hint, it does not change the processing
Paul C clarifies his earlier statement with four test cases:
i) SA has a meaning to the application
-absent, not OK
ii) SA has no meaning to the application
-present, quietly ignore
Anish wanted clarification on when 427 is returned. If the application does
not like the value in SA, what does the application return?
This divides Paul's case (i - present OK) into two subcases: valid value and
Anish proposes that for invalid value, sender should return the correct value.
Mark N said that it is optional because we cannot ensure that the server
computes and sends it.
David F wants to know if we have to say who checks the value of SA.
Chris F says that it might be in the HTTP binding layer. It would be a property
of the binding. It should not be above the SOAP layer, as it is http specific.
Stuart proposes "...the correct operation of the http binding..."
Ugo wanted clarification on Paul's classification. On the "meaning"? One
meaning is optimization (i.e., a hint), another is to use it as a parameter
(e.g., putting the stock symbol here for a get stock quote request).
Stuart says it is the former. Doug said in that case it changes the meaning
of SA from SOAP 1.1.
Henrik said that it is not "SOAP Application" in the proposed text but should
be "SOAP receiver".
Changes were made to the text.
Hugo: value of URI is relative, and relative to the base, which is the request
URI; so take the requirement level out, and make it a statement. Agreed.
Ugo's concern can be resolved by removing the last part of the proposed first
sentence. Everyone agreed.
Doug is concerned about the word "optimise". He wants "hint to processing".
Concerned that we are not encouraging its future use, but changing the meaning.
Stuart said that the *critism* SOAPAction attracts is largely due to its vagueness.
Henrik thinks it is fine as is.
Anish says that if we want SA as a hint, we should say something stronger.
Winston: Agreed, and...
Chris: Didn't agree that it IS a hint. it may be a hint, or it can be used for
other things. We agreed to allow it to be required.
MarkN says that this is about the strongest statement we can make.
Ugo wants to know what will discourage future use. Answer by Henrik and MarkN:
The text does not encorage. DavidF points out that we have gone from SHOULD
(in SOAP 1.1) to MUST NOT.
PaulC put forward a proposal that invalid values be treated as absent value.
ChrisF made a friendly amendment: take Paul's wording and ....
MarkN: is there an interoprability issue with SOAP 1.1? Answer: 427 is sent
only if SA is required.
Stuart wants to know if the text is WD quality. DavidF would like to dispose
of Paul's proposal.
ChrisF asks about a case where SA is not required but it implements it.
Many voices: ignore it.
Yves: Issue 22 asks if there is SA in the header but no SOAP in the http body.
Henrik thinks this is a regular client SOAP fault.
PaulC says that the presence of SA does not change the resolution of issue 22.
It is treated like other client SOAP faults.
Doug questions that if you have some processor other than a SOAP processor at
the request URI without a body, must the client get back a SOAP fault in every
Chris: Why is it not a 400 bad request?
Henrik: The request is targetted at a SOAP node, which expects a SOAP envelope.
So it genarates a SOAP fault.
Oisin: SOAP fault does not always happen. If it is a SOAP receiver, it
generates a SOAP fault but if it is not a SOAP capable node, http processing
proceeds as usual.
Decided to handle Issue 22 will be handled via email, as its resolution is
indicated by the resolution to issue 95.
Anish: Why does issue 22 have anything to do with SA? Getting an empty body
should be independent of any binding. This fault should be generated
independnt of the underlying transport.
PaulC: This says that you can't wrap everything into SA and have no envelope.
Henrik points everyone to the SOAP client fault section. It covers the cases
of badly formatted message. Issue 22 is covered by the SOAp fault section.
The resolution section should say that this is orthogonal to the .....
Mark N wants to change OPTIONAL to optional. Many disagreed.
Various action items:
i) generate an Internet draft on status code (Mark N and others)
ii) (postpone) discussion on whether SA is a feature or a property
The WG agree that the text (modulo editing) goes into the Editor's Draft as a
new section 6.1.1. The WG will have opportunity to comment on the final text
of the spec before it is sent to the W3C for publication as a WD.
Closed issue 95 with this text and closed issue 22 with the proposal to refer
to the SOAP fault. No objections.
11. Discussion of Issue 4 ("none" actor):
MarkN provided draft text.
MarkN proposes removing text in the abstract model that says that none is
guaranteed not to be removed.
Hugo: What does removing the text mean?
MarcH: Be silent on the matter on whether blocks for none can be removed.
Henrik: AM may not be up to date. What is the publication plan for the AM?
Stuart: Document converted to XML. Terminology may need to be updated.
Agreed to close Issue 4.
Stuart will work on adjusting the AM text to agree with this.
12. Conformance proposal:
Hugo gave a presentation of current work on conformance. He has produced a
first list of testable assertions. The proposal will meet requirement 301A.
He noted that the testable assertions would be useful for checking that we
meet candidate rec implementation requirements.
Henrik said that from our perspective it is the integrity of the spec that
you test, not the implementaions.
DavidF said that schema did not initially have a formal testing requirement.
It is a grey area.
Stuart said that all that is required that the spec have testable assertions.
It is good to go beyond and make up test suites but all that is required are
Hugo said that writing the test suites will allow checking for such statements.
Henrik said that a compliance statement - what it means to be compliant with
the spec - would help. They did this in HTTP.
Winston: In DMTF, they provided three documents i) the compliance statement ii)
the test suite iii) the certification process
Oisin said that W's documents covered everything. We may not need the
certification process, i.e. (iii).
Oisin: After the spec is released, there will likely be ambiguities. Is there
a process by which these can be resolved? DavidF said that these will come
back to us. The last call review provides a mechanism and a time line for
Oisin wants to know about the process for resolving ambiguities found in
implementations after the spec becomes a Recommendation.
DavidF said that W3C does not have a formal certification process, and there
is no way to police conformance.
Winston: This area is complex. DMTF has contracted with Open Group to do this.
David F: Isn't the test itself a derivative work?
Henrik: The mantra has been taken from the IETF. The edge cases may exist, but
the goal is to have a broad community be able to interoperate.
Hugo: We should look at the SOAP builders list of tests. Good stuff. He is
getting approval from the spec authors to produce a derivative work under W3C
Henrik: In HTTP, they provided a huge table of features. Those submitting
implementions submitted a list of checkmarks of the features supported. This
list could be private.
Hugo: There is an public interopeability testing event. Is anyone going?
Doug: Regarding the testable assertions, do we restrict ourselves to only the
MUST and MUST NOT items?
Oisin: Conformance statements need to be made at a higher level e.g., SOAP
impl. must support the default HTTP binding. Then you can drill down from
these high level assertions.
Do MUSTS first and then do the SHOULDs for the conditional compliance.
DavidF: Are you suggesting doing testable assertions for core, encodings, http
Henrik: Have a list of features, ask questions like "do you do them?"... Keep
out of the document what it means to be compliant with the spec.
Hugo: The spec and the test document should be kept separate.
Stuart: Could we work backward and see if the SOAP builders test map into
statements in our spec?
Henrik: When do we start it?
Hugo: People maintianing the test document should update it everytime the spec
is changed. There are about 40 or so testable assertions. Each assertion might
have a few tests.
MarcH: Suggests putting markup into the spec DTD that allows us to track the
The WG agreed to charter a group of people to generate a document containing
testable assertions based on the latest spec. Testable assertions are to be
based on MUST and MUST NOT statements in the spec. Later versions of the
document may be based on SHOULD etc statements. Hugo will be the document's
editor, helped by Oisin, Marc H. They agreed to provide a draft outline in
time for (tuesday at the latest) the telcon after next.
13. Usage Scenarios:
DavidF: By last call, we will have to check that we can meet a reasonable set
of usage scenarios. We'll need to decide on a format, level of detail, etc as
part of creating the scenarios.
Nilo: Notes that the Primer proposal suggested using the usage scenarios as
examples for the primer.
David: In general, we are checking whether SOAP can play its intended role in
each scenarios. Note that SOAP may only be a part of a larger environment
needed to execute the whole scenario.
Doug: How careful should we be to not imply an implementation choice. e.g., f
or S1 and S2, it is the same from a SOAP perspective. S2 might be implemented
Henrik; These scenarios are not only from a SOAP node perspective. The talk
also from the user point of view.
Anish: If the usage scenario requires other components than SOAP, how do we
DavidF: This is not a best practice document, we don't have to optimise the
solution. The solutions should be reasonable.
JohnI showed a format for how to descroibe the usage scenarios [Usage scenarios].
Nilo: Should augment these with message descriptions/layouts.
Henrik: I like John's technique. Message layouts might imply implementations.
Doug: Should we use the language only in the spec?
WG agreed to use John's diagrams.
(Snn names refer to numbering style used in JohnI's presentation)
S1 (fire and forget)
Stuart: Some bindings may impose a constraint.
Henrik: You can pick a binding. it may not be the best bidning for the
Anish: Why double headed arrows between sender and xmlp processor?
Chris: Is it the intent to model properties with this? Fire and forget over
UDP (no ack) and TCP (ack at the transport level).
S2 (fire and forget to multiple receivers):
John: If you had a multicast property in the transport binding, it will be the
same as the previous case.
Doug: Should the handler be below the XP processor.
Chris outlines several choices. it should be shown in the figure.
Winston: Show multiple processors on the receiving side.
Henrik: There is another scenario on routing. S2 is about multiple recipients,
not multicast. Using term "multicast" is a solution.
S3 (request response)
Henrik: Use the term "feature" for request/response etc. which could be
implemented depending on the capabilities like the transport binding. Using
"feature" in this way you can build up increasingly complex scenarios.
Doug is concerned that all the diagrams are the same. All that seems to change
are the words in the pink boxes.
John: This is the rpc feature that uses the request-response feature.
Stuart: We are doing this to discharge an obligation to ourselves that our
solution meets the expected usage scenarios.
Doug: Does this prove that SOAP will actually be capable of doing these things?
Nilo: That's why we need messages. That's what users of the primer would like
DavidF: We need to augment these diagrams with some more concrete
representations, e.g. fragments of actual messages. We'll leave it as another
issue whether or not Nilo uses this formal representational style in the
Henrik said something about tying these to the test cases.
Doug said anything concrete will help.
Stuart: We could annotate this with an example, e.g. a fragment such as a
Nilo: Shouldn't there be a box for the request/response feature as well?
John: yes. He will edit appropriately.
S5 (request with ack)
David: What the nature of the status handler?
Stuart: This is like delivery confirmation.
Chris: Time is not modelled here.
S6 (request with encrypted payload)
Henrik: should there be a mechanism that says that some part could be
John asked Chris to help him flesh it out.
S8 (conversational message exchange)
Chris: is there a request - multiple response example?
John asked for help in drafting out the other scenarios.
He'll have it on the list by the end of next week. To be reviewed two telcons
14. Wrap Up
David will write a summary of the important decisions amde at the meeting and
make it available to all WG members before the next telcon. The f2f meeting
minutes may or may not be available in time for the next telcon. Also, we may
or may may not have the spec documents updated in time for next telcon. David
will put together a complete list of items closed.
PaulC: I want an action item to do the coordination on the xsi:nil, nulls etc
PaulC: What are results for the Feb meeting survey?
DavidF: These will be provided shortly.
David F thanked Novell.
Meeting adjourned 5:10pm.
-  5 Sept 2001, telcon minutes, http://www.w3.org/2000/xp/Group/Admin/#schedule
-  Current action items, http://www.w3.org/2000/xp/Group/Admin/#pending
-  XMLP WG Schedule, http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0019.html
-  Detailed Schedule, http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Jul/0087.html
-  SOAP 1.2, Ed. Copy Part 1, http://www.w3.org/2000/xp/Group/1/08/29/soap12-part1.html
-  SOAP 1.2, Ed. Copy Part 2, http://www.w3.org/2000/xp/Group/1/08/29/soap12-part2.html
-  SOAP 1.2 Primer, TBD
-  XML Protocol Abstract Model, Ed. Copy, http://www.w3.org/2000/xp/Group/1/08/14-am/xmlp-am.html
-  XML Protocol Requirements, Ed. Copy, http://www.w3.org/2000/xp/Group/xmlp-reqs-06/
-  RPCTF minutes, http://www.w3.org/2000/xp/Group/1/08/24-rpc.txt
-  SOAP 1.2 Testable Assertions, http://www.w3.org/2000/xp/Group/1/07/spec-ta
-  Conformance Issues, http://www.w3.org/2000/xp/Group/1/03/xmlprotocol-conformance
-  Issues list,
-  Issue 25 Proposal, http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/att-0009/01-prop25.htm
-  Dinard f2f minutes, http://www.w3.org/2000/xp/Group/1/06/f2f-minutes.html
-  See "Issue 25 Proposals from the f2f", in http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0084.html
-  SOAPAction proposal, http://lists.w3.org/Archives/Public/xml-dist-app/2001Aug/0266.html
-  mU at client proposal, http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0066.html
-  Issue #12 HTTP Status Codes, http://www.w3.org/2000/xp/Group/1/07/issue12.pdf
-  Issue #12: HTTP Status Codes 500 v 200, http://lists.w3.org/Archives/Public/xml-dist-app/2001Jun/0015.html
-  Another approach to status codes, etc. in HTTP binding, http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0134.html
-  A tale of two bindings, http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0241.html
-  XMLP Issues 11 and 13, http://www.w3.org/2000/xp/Group/1/07/port80-present.html
-  Transport Binding Task Force proposal, http://www.w3.org/2000/xp/Group/1/08/31/
- XML Protocol Working Group Charter,
- SOAP 1.2 WD,