Minutes of XML Protocol F2F Meeting, 11-13 September 2001, held in the Novell Campus Conference Center, San Jose CA.

0. Roll call

Present 29/23 Excused Regrets Absent

Agenda

Tuesday, September 11th
Morning Session I, 8.30a - 10.15a
  • Introductions
  • Local arrangements
  • Assign scribes
  • Review agenda; AOB?
  • Approve minutes from Sept 5 telcon [1]
  • Action items [2]
  • Schedule review, see [3] [4]
  • Publication. What do we publish, and what changes are needed in order to publication?
    • XML SOAP 1.2, Ed. Copy Part 1 [5]
    • XML SOAP 1.2, Ed. Copy Part 2 [6]
    • XML SOAP 1.2, Ed. Copy Primer [7] (TBD)
    • XML Protocol Abstract Model, Ed. Copy [8]
    • XML Protocol Requirements, Ed. Copy [9]
Break, 10.15a - 10.45a
Morning Session II, 10.45a - 12.30p
  • Publication /cont ....
  • Resolution of issues, see Issue List [13].
    • 25: clarify status of trailers. The first proposal for handling trailers was prepared for the Dinard f2f [14] which was discussed briefly at the f2f (see "Discussion of Issue #25 Trailers" in [15]) and consequently a new proposal was put forward [16]. The latter generated much email discussion (see threads starting at [14] and [16]).
    • 22 and 95: SOAPAction. This was discussed extensively at the Dinard f2f, and resulted in various "optional" and "deprecated" (loosely defined) proposals [15]. A new proposal has recently been put forward [17], 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 [18] 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 [23].
      • 12: http error codes. Material on this issue was created for the Dinard f2f [19]. One commentator says "Discussion of this issue tends to be polarised and has lead to threads that have become 'exausted' without conclusion eg. [20] [21]. 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. [22]".
    • 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 description.
    • 134: XMLBase support. Status of investigations, see telcon minutes
Lunch, 12.30p - 1.30p
Afternoon Session I, 1.30p - 3.00p
  • Issues /cont ....
Break, 3.00p - 3.30p
Afternoon Session II, 3.30p - 5.00p
  • Issues /cont ....
Wednesday, September 12th
Morning Session I, 8.30a - 10.15a
  • Issues /cont ....
Break, 10.15a - 10.45a
Morning Session II, 10.45a - 12.30p
  • Issues /cont ....
Lunch, 12.30p - 1.30p
Afternoon Session I, 1.30p - 3.00p
  • Issues /cont ....
Break, 3.00p - 3.30p
Afternoon Session II, 3.30p - 5.00p
  • SOAP Underlying Protocol Binding Framework (See [24])
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 [10] and references therein. Provides resolution to issues 16 and 113.
    • Relationship of Section 5 to Section 7, see Action Item 2 in [10], (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 [11] [12]
Lunch, 12.30p - 1.30p
Afternoon Session I, 1.30p - 3.00p
  • Usage Scenarios. The WG has created a number of scenarios [9] 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/ ....
  • Wrap-up

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

  CONFORMANCE

  USAGE SCENARIOS

  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 
work. 

David noted that editors need to get edits into the document in preparation 
for publication.

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
-usage scenarios
-address conformance
-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 
and 2:

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 
the namespace.

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 
issue 100.

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 
final namespace.

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:

Adjuncts
HTTP Binding, Encoding, RPC
Part 2

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.

Straw poll:

  Adjuncts: 9
  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 
section)?

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.

Chris:
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 
infoset.

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,
Choice 2

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 
instead.

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 
time).

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 
it?

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 
inconsistent.

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 
envelope.

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 
all bindings.

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 
SOAPAction.

Break.

David discussed how to make progress on this issue with various individuals 
during break.

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.

Discussion.

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 
these things?

DD: 

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.

MH: ??

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 
server then 

DD: I think that we're all in agreement that we can't ignore a mustUnderstand 
fault. 

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
[http://www.w3.org/2000/xp/Group/1/07/port80-present.html]

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 
application.

...

MN: Pro Port 80 arguments from presentation...
    Against Port 80 arguments from presentation...
    Firewall scenarios from presentation...
    Interception proxies...

HFN: offers example of hotel proxies...

MN: A much more often use of interception proxies that what to enforce caching 
policies.

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 
its use?

MN: In a spec we would inform of registration of URL scheme and default port 
and perhaps SHOULD or should wrt to their use.

Frank: ???

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 
hints etc?

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 
resolve.

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 
port.

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?

No dissent.

DF: Mark, does this proposal apply to issues 11 and 13?

MN: ...yes.

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...

10:05

Issue 12, HTTP Error Codes

Presentation from Stuart

Discussion about whether intermediaries really rewrite content based on 
status code.

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 
misleading hints.

OH: Reason this has not proved a problem is because all WS are simple at the 
moment.

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)

Reconvene:

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 
bindings.

DF: Do I take it that you 'cannot live with' a mixed solution.

Frank: ...No...

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 
internally?

WB: Seeking clarification of whether SOAP Faults should be used for 
application errors.

DF: ...so in response to the question... "who the hell does generate a SOAP 
fault..."

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 
application lyer.

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 
fault....

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, 
re-insertion.

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 
.../none thing.

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 
means.

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 
destination.

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 
bad...

MH: Use cases?

HFN: Maybe you wants some presentation component with your message...

MN: Conceivable...

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 
separate them.

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 
content...

Discussion... CDATA and base64 inclusion...

HFN: Is there wording we can leverage from elsewhere rather than having to 
explain this.

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.

Discussion....

MH: We could say that PI's are ignored. Don't think we can say that DTDs are 
ignored. 

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 
ignored.

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 
message.

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 
these things.

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.

14:15

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.

MN: Yes.

DF: Dissent?

No dissent recorded.

DF: Mark N take an action to report resolution and closure.

ACTION: Mark N report resolution and closure of Issue 73.

14:22

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 
invariance...

Discussion.

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 
need.

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 
Application.

14:33

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...

Silence.

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.

HFN: ....(missed)

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 
naturally?

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 
envelope.

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 
hops.

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 
are expressed. 

Discussion...

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 
the envelope.

HFN: I don't think we have anything to say about that...

Discussion.

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 
defined.

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 
framework.

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 
framework.

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 
the TBTF.

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 
has changed.

CF: Intervenes.... 

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 
specification.

HFN: ... creates some bricks...

DD: ....

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 
do K=1

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 
consider.

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 
started... 

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.

16:50

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 
different schedules... 

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 
earlier contact.

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 
effect...

CF: ???

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 
Marshall?

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 
individuals?

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.

17:15 Adjourn.

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
xsi:nill attribute
    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
separate issues.  

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.

(Nilo scribe)

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.

BREAK.

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 
descriptions
- need a new HTTP response header and a new response status code (427: SA 
required)

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?

Discussion.

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 
semantics.

Paul C clarifies his earlier statement with four test cases:
i) SA has a meaning to the application
-present, OK
-absent, not OK
ii) SA has no meaning to the application
-present, quietly ignore
-absent, OK

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 
invalid value.

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. 
Change made.

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 ....

Staurt objects.

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 
case?

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.

Stuart:.....

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 
testable assertions.

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 
receiving comments.

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 
license.

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 
binding etc?

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 
MUSTs etc.

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 
by multicast.

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 
state these.

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.

BREAK.

(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 
situation.

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.

S4 (request-response)

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 
to see.

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
Primer.

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 
header.

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 
encrypted?

John asked Chris to help him flesh it out.

S8 (conversational message exchange)

Chris: is there a request - multiple response example? 

Yes, S20.

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
hence.

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.

15. AOB:


PaulC: I want an action item to do the coordination on the xsi:nil, nulls etc 
issue.

PaulC: What are results for the Feb meeting survey?

DavidF: These will be provided shortly.

David F thanked Novell.

Meeting adjourned 5:10pm.

References