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
David Fallside gave administrative details about the IBM site and the
agenda of the meeting.
- Yves Lafon: W3C Team Contact
- Hugo Haas: W3C Team Contact (Alternate)
- Jeffrey Kay: Engenia Software
- Ed Mooney: Sun Microsystems
- Alex Milowski: Lexica
- Jim Trezzo: Oracle
- John Evdemon: XMLSolutions
- Volker Wiechers: SAP AG
- Richard Martin: Active Data Exchange
- Bill Anderson: Xerox
- Henry Lowe: OMG
- John Ibbotson: IBM
- Mark Needleman: Data Research Associates
- Waqar Sadiq: Vitria Technology
- Amr Yassin: Philips Research (Alternate)
- Henrik Frystyk Nielsen: Microsoft
- Paul Cotton: Microsoft (Alternate)
- David Orchard: Jamcracker
- Noah Mendelsohn: Lotus Development
- Murali Janakiraman: Rogue Wave
- Kevin Mitchell: XMLSolutions (Alternate)
- Randy Waldrop: WebMethods
- Glen Daniels: Allaire
- Simeon Simeonov: Allaire AC Rep
- Fransisco Cubera: IBM (Alternate)
- David Ezell: Hewlett Packard
- Stuart Williams: Hewlett Packard (Alternate)
- Kazunori Iwasa: Fujitsu
- Oisin Hurley: IONA Technologies
- Ray Denenberg: Library of Congress
- Yan Xu: DataChannel
- David Burdett: CommerceOne
- Vilhelm Rosenqvist: NCR
- Alex Ceponkus: Bowstreet
- Mark Nottingham: Akamai (AC Rep)
- Andrew Eisenberg: Progress Software
- Jean-Jacques Moreau: Canon
- Herve Ruellan: Canon
- Conleth O'Connell: Vignette
- Ray Whitmer: Netscape
- Randy Hall: Intel
- Dick Brooks: 8760 (Invited Expert)
- Bjoern Heckel: Epicentric
- David Fallside: IBM (Chair)
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:
- The Requirements Document.
- The specification, going through the following stages:
- Working Draft
- Last Call Working Draft
- Candidate Recommendation
- Proposed Recommendation
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.
W3C has decided to make the deliberation more public. Discussions should go
to the public (and archived) mailing list xml-dist-app. @@@How many
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
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
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
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.
We are an unusually large Working Group. We have considered dividing the
group into subgroups. The work is divided into 4 components:
- Message Envelope
- Content for RPC
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.
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
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
- 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
- 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
- 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
- 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
- A: envelope should provide hooks for application to address
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
- not be constrained by a req/resp approach - layering will help reuse for
other environment, like other protocols/message types
- we should decide if we setup competive initiative, collaborate with
other initiative, don't do anything and let others do the work.
ex: do you require a priori knowledge or do we have self describing
- 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
- 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
3rd Group: serialization (Stuart Williams)
Syntactic/non-syntactic, what does that means? This was the test of common
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
- 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
- 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 ->
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
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
- 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.
- 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
- 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
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
Henrik Frystyk Nielsen's
- What are you refering to when you talk about security mechanisms?
- Digest Authentication, XML DSig, etc.
Glen Daniels' group
Walk through the list of requirement
- DR 001: How do we deal session-oriented communication?
- DR 002: What about BEEP? Maybe have another requirement. The list of
protocol needs to be determined.
- DR 005: Clarification on XML idioms needed. We need to be compatible
with other W3C technologies.
- DR 007: Browsers must be able (with the current technologies) to make XP
requests and receive XP responses.
We need to figure out what this means -> add an issue in order to
clarify the use of XP (use cases).
- Q: Why browsers and not mail clients?
- A: Browsers are in a world with forms and and they could use XP
- Q: You should say more: you shouldn't do something that precludes
you from using a browser.
- A: Not preclude is not sufficient.
- DR 009:
This requirement brings the issue of the processing model (talks about how
to get a document in and then out and XP communication).
- Q: Is there a standard way to embed XML within XML?
- A: There are a variety of ways, but no standard.
- DR 010:
- Q: The word status implies that it is an application protocol. Is it
at the envelope level or the application level?
- A: There might be situations in which you might want to send back
an ack before an actual response.
- DR 013: Support intermediaries / routing information should be split.
- Q: all those things have support in front of them? Are we going to
define them or just insure that it is going to work?
- A: Should be changed by provide.
- DR 015: replace entities by things. Talking about XP version 1, XP
version 2, etc.
- Q: Is it going to be number based?
- A: Too much in detail.
- DR 016:
- Q: Is it a shall not preclude or are we going to provide a
- A: We should investigate.
- DR 018: XP processors must support XML Schema. We need to define what an
XP processor is.
- DR 019:
- Q: What is an object?
- A: an object is a SOAP end-point, i.e. a resource.
- A: It seems to me that it is related a programming model.
- C2: Everything on the Web is a resource. SOAP has the notion of
passing by a URI which has a specified lifetime.
- DR 020: Better version later on.
There should be a boundary between the core specification and the rest.
- DR 021: Needs merging.
- DR 022: Needs merging for the first part. Issue: port number.
- DR 023: We should define in which XP stands.
- DR 024: Concerns about interoperability: set of rules to check that a
message has been correctly formulated. It is related to language
interaction. About a well specified and verifiable rules for RPC.
- DR 025 - dup
- DR 026 - rewording, the intent was that more than RPC should be
- DR 027 - dominant dup
- DR 028 - dup
- DR 029 - rephrase in "we should have use cases"
- DR 030 - reword connection oriented / connection oriented. This should
be more explicit and connection with underlying support.
- DR 031 - dup
- DR 032 - do we allow small footprint implementation? (subset or
- DR 033 - do things put in XP should be human friendly or should it be
possible to use more human friendly or allow interaction with human.
- DR 034 -
- DR 035 -
- DR 036 - separation btw core of the message and context information
about the message? (proposed rewording) - sort out the use of
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.
- DR 037 -
- DR 038 - How does it relate to versionning? or just plain
- DR 039 - dup
- DR 040 - do we need to support explicit binary data (or just base64
encoding is fine). Absolute NO on one side, yes on other side. (open for
discussion) We should get requirements for binary binding.
- DR 041 - pref dup
- DR 042 - different level of abstraction may lead to conventions that put
things outside of the envelope. SHould we transfer the unit of comm or the
unit and potentially linked objects related? should be reworded in
protocol unit (and then should the envelope be that unit). (discussion
- DR 043 -
- DR 044 -
- DR 045 - entity -> external entity. SOAP disallows dtd hence
entities. (ie: SOAP uses a subset of xml) entities are slowly subsumed by
more web like entities (xlink, even PIs).
- DR 046 - popular ones are smime/ssl/digital signatures
- DR 047 - general issue from XML (read XML infoset as background)
Telcon next week, Wednesday 8am PST, 11am EST, 4pm BST, 5pm MET, (@@ check
Japan and AUstralia time) number TBA soon