First XML Protocol Face-To-Face Meeting Minutes

October 11-12, 2000, hosted by IBM in Raleigh, NC, USA. Minutes taken by Hugo Haas and Yves Lafon.


David Fallside gave administrative details about the IBM site and the agenda of the meeting.




We must first produce the requirements for the protocol, within the scope of the charter of the WG. It will be published as a Note within the coming month, and will be evolving. Editors will be (resolved on the second day) Alex Milovski and Henrik Frystyk Nielsen.

The final deliverable is the XML Protocol Specification. We will provide a description using an XML Schema. In order to garantee interoperabilty, the document will go through a Candidate Recommendation.

The Working Group is required to publish a document within every three months. The documents will be public. The first publication of a document requires W3C Director's approval (allow around 1 week). The plan of our deliverables is the following:

We will keep an issues list and write a glossary to make sure that everybody uses the same vocabulary to talk about the same things.



Mailing lists

W3C has decided to make the deliberation more public. Discussions should go to the public (and archived) mailing list xml-dist-app. @@@How many members@@@

The member-only list is there for administratrive purposes and communication with other WGs which are Member confidential.

Note from Paul Cotton: Watch out when you hit the Reply button to be sure you send your email to the right place!

Discussions about the requirements will be Member only, so that we can publish a first version rapidly, and we get feedback from the public on this first publication.

Then discussions will be public.


They will happen on a weekly basis.

The agenda will be posted 2 days in advance on the Member-only list.

Minutes will be published on the public. If you don't want to have something publicly published, please notify the chair and there will be a Member-only version and a public one.

A scribe is needed for the teleconference.

The slot proposed is on Wedesday, 8am PST/11am EST/5pm MET. That time may change.

David Orchard noted that it overlaps the XML Core teleconference, but there is no way that we can find a time with no conflicts.


We are required to have a minimum of 3 face-to-face meetings per year.

We can also go to 1 or 2 public meetings of some sort. Example: XML Schema's editors went to public conferences.

This working group is very public because a lot of other communities are already involved in XML protocols/messaging.

The next one will be hosted by Microsoft at Redmond, WA, on December 13-14.

We are planning to have two face-to-face meetings next year. The expected dates are March 2001 and June 2001.

Paul Cotton noted that there is an all-WG meeting during the February 2001 meeting. We have to consider if we want to go, and if we want to meet another Working Group there.


Large Group!

We are an unusually large Working Group. We have considered dividing the group into subgroups. The work is divided into 4 components:

We have considered dividing the Working Group in 4 smaller groups working on each of these areas.

In order to make this large group work, we need consistency: signing up in this WG is a serious commitment and W3C's notion of good standing applies.

Decision making

Decisions are achieved by consensus.

There are different ways to achieve consensus: straw polls, more formal votes, .... How to deal with disagreement? Anyone has the option of recording their dissent.

The system that we are going to use will be less formal voting: discussion of the topic, used to formulate a number of alternatives, and then use a straw poll to see with which solution we want to use. If we really can't agree, we will use a formal vote.

The role of SOAP

We are going to design requirements.

We will then consider whether SOAP 1.1 reasonnably meets the requirements. If yes, we can use this aspect of SOAP. If not, we will design something for the requirements not met.

We won't consider any new version of SOAP; we will use SOAP 1.1.

Is there a name for this protocol?
Yes, it is "XML Protocol".
Glen Daniels: Seems too generic.
Paul Cotton: There is already XML Schema, XML Query.
Yan Xu: Yes, but there are already others XML protocols.
Paul Cotton: Microsoft also has an XML schema language, and everybody knows what the W3C XML Schema language is.
David Fallside: if this is a problem, we can add this to the issue list.
Henrik Frystyk Nielsen: Already an issue list for SOAP.
Noah Mendelsohn: How do we deal with our charter? Is the charter prescriptive? If it's the case, we should try to swallow our personnal feelings because modifying the charter puts the bar high.
YL: Criticism about the name from AC comments it is not the same kind of protocols as the IETF has. It was not listed as a critical issue.
Ray Denenberg: Name of the Working Group doesn't imply the name of the specification produced (not in charter).
Paul Cotton: That has always been the case within W3C.


Schedule. See David's slides.

Something useful with the requirements is use cases.
Paul Cotton: seconded.


We divided the group into 4 subgroups to each examine one of the components in the charter (envelope, RPC, serialization, HTTP transport).

Envelope group (Henrik Frystyk Nielsen)

look at the charter and look at the things addressing envelope.
What is an envelope then look into the charter?
Simple -> nested protocol.
Security issue, how to find a good model for extensibility.
relationship with schema, no overlap with schemas.
HTTP is not the only one transfer protocol.
Simple is a relative term, fuzzy. We need some use cases and then we should have simple cases simple in practise.
Very simple negotiation to decide when to extend things.
intermediaries, can they modify the message or not?
there should be a mechanism to support links. It is possible to have two ways to use binary data, import a blob mechanism or point to an external link (in ebXML it is done within the MIME packaging).
Enveloppe should not rely on the underlying transfer.
Regarding application semantics, some spinoff WG should work on that and verify that the envelope is extensible enough.
How to figure out how to talk to another party is description of service and thus out of scope.
I18N concerns and security issues about securing an envelope in another enveloppe.

Q: can we mandate that these documents are in utf8 format or is it possible to carry message in different national encodings?
A: this should be in the requirement doc.
Q: link btw the binding and the envelope
A: if you have a msg path and they have multiple binding, how do they interact all semantic you want to express have to be in the boundaries of the envelope, otherwise it may be lost from one hop to another. protocol binding should be transparent to the envelope, but protocol used is not transparent as the model is different depeding on the transport.
Q: HTTP model is more a framing protocol that resp/req.
A: it may break intermediaries if http breaks req/resp model.
Q: evolvability only applies to encapsulation data not encapsulated one
A: envelope should provide hooks for application to address evolvability

2nd group: RPC (David Burdett)

RPC is a request-response like protocol a particular format for communicating informations such as method names parameters that are typically mapped to procedure calls into an application.

Define an egreed convention for the wire format
Q: how you see issue 2 wiht paragraph 2.5?
A: itmeans out of scope but. 1.2 bullet 2, it should be deployed automatically without central authority. Automatic service discovery lead to this.
Q: RPC doesn't define a wire format, it is the serialization job.
A: abstraction is method name and parameters defined in one way. abstraction are higher level than XML
A: you don't define a wire format there but a way of mapping proc call in RPC.
A: we're not dealing with smealess binding to a language
Q: http post fits also the RPC model.
A: some rpc have some idl bundled to them, you also have exception handling we should focus on our abstract version of how to handle rpc.

3rd Group: serialization (Stuart Williams)

Syntactic/non-syntactic, what does that means? This was the test of common understanding.
We should be capable of serializing syntactic datatypes like what is defined in XML Schemas datatypes.
We preferred to use abstract rather than non-syntactic. THe serialization should be independant of any language binding, so you don't need to have the same env on both side. There was a recognition that streamed like transfer were not adressed.

Q: What is a difference btw a large binary blob and an attachment. We opened the box of security with no time to finish.
A: diff btw blob and attachement, attachement are a typed link.
Q: I hope we are not trying to define a subsyntax of XML to express schemas
A: the natural fit to XML is tree structure, we should tranport arbitrary graph not tree, see RDF.
Q: replace non-syntactic by abstract, would that make thigs clearer?
A: this should be fine for me.
Q: are we inventing a new language?
A: I don't see that.

We should be more specific in what we mean by non-syntactic.
DF: we will fix that by putting it in the requirement doc or in the glossary. use cases may solve the pb of what we want to send.

4th group: protocol group (David Orchard)

recommandations: abstract datamodel (infoset). the wire protocol is what we see when we bind to http protocol (for ex). The datamodel can be bound differently. In soap it is roughly one to one but if you want to map to other protocol you have problems.
Then there should be mapping btw that data model and various protocols. - We need to parameterize protocols, ex in smtp you have to expliciely request a reply which is implicit with http. Http should be the first binding (pb is which kind of http?)
Protocol bindings, http:
SHould we use POST or should we have a "browser subset" Asynchronous/callback there should be conversion at intermediaries XP HTTP -> XP/SMTP -> XP/Napster
So what is low priority or not? it should be bindable to HTTP but not only. to teste the requirement, should we do other protocols?
Security and protocols. 2.4 exclude application level security. We have interaction with seciruty at transport or application. Security has to be in the datamodel.
We said that the key to evolvability and multiple intermediaries is the combination of an abstract data model with a protocol parameterization. We suggested that protocols other than the HTTP/(M)POST, such as GET, File, SMTP, etc. could/should be done as an appendix or a separate Note.

Many members were interested in this.

Q: do you want to use GET?
A: Yes so that we can bookmark it.
Q: do we need to have a subset?
A: we whould have the Get binding even if it is an appendix.
A: browsers have limited http capability, a browser application would require to move structure data and browser can't make text/xml post.
Q: does that astraction talk about kind of transaction?
A: we didn't go that far.
Q: the charter says that the WG will create a HTTP mapping, does it preclude other protocols? (then elude transport neutrality?)
A: no.
A: more on this, other external people will point out what are the limitation introduced by ex the http mapping. Unlike SOAP we need that XP is more transport neutral.

Subgroups requirements

Paul Cotton

Q: What do you think by modular?
A: I didn't wrote that so I don't know.
A: related to orthogonal and exensibility

Henrik Frystyk Nielsen

Q: what do you mean by entity expansion
A: I mean external entities
Q: WHat are the reason why you ruled the out?
A: You may have chicken and egg pb when you resolve and get entities.
A: only external ones are problematic
Q: what lightweight requirement is?
A: it should be very similar to simple, by "as simple as other things doing this"

Glen Daniels

Alex Milowski

SOAP Presentation by Henrik Frystyk Nielsen

See slides and also the ppt version.

XML Schema Presentation by Noah Mendelsohn

See slides in PDF.

Presentation of each subgroup requirements

Paul Cotton's group

Extracted righ out of the charter, plus list from people.

Glen Daniels noted that "shall be supported by the browser" is as a client.

Henrik Frystyk Nielsen's

What are you refering to when you talk about security mechanisms?
Digest Authentication, XML DSig, etc.

Glen Daniels' group

Alex Milovski's

Walk through the list of requirement

There should be a boundary between the core specification and the rest.

This document will be sent out and the DR XXX will live forever and should be used as reference for discussion. Those items belongs to the whole group not the subgroup that created them during the f2f.

Telcon next week, Wednesday 8am PST, 11am EST, 4pm BST, 5pm MET, (@@ check Japan and AUstralia time) number TBA soon