XML Protocol WG Face-to-Face meeting minutes: 26 & 27 February 2001

Attendance list

Active Data Exchange	Shane Sesta	alternate
Akamai Technologies	Mark Nottingham	principal
Allaire	Glen Daniels	principal
AT&T	Mark Jones	principal
Bowstreet	Alex Ceponkus	alternate
Canon	Jean-Jacques Moreau	principal
Canon	Herve Ruellan	alternate
DataChannel	Brian Eisenberg	principal
Engenia Software	Jeffrey Kay	principal
Ericsson Research Canada	Nilo Mitra	principal
Fujitsu Software Corporation	Kazunori Iwasa	principal
Group 8760	Dick Brooks	ebXML contact
Hewlett Packard	David Ezell	principal
Hewlett Packard	Stuart Williams	alternate
IBM	David Fallside	chair
IBM	John Ibbotson	principal
IDOOX	Jacek Kopecky	principal
Intel	Randy Hall	principal
Interwoven	Mark Hale	principal
IONA Technologies	Eric Newcomer	alternate
Jamcracker	David Orchard	principal
Library of Congress	Ray Denenberg	principal
Lotus Development	Noah Mendelsohn	principal
Matsushita Electric	Ryuji Inoue	principal
Microsoft Corporation	Henrik Nielsen	principal
Mitre	Marwan Sabbouh	principal
Mitre	Paul Denning	alternate
Netscape	Ray Whitmer	alternate
Novell	Scott Isaacson	principal
Oracle	David Clay	principal
Philips Research	Yasser alSafadi	principal
Rogue Wave	Patrick Thompson	alternate
SAP AG	Volker Wiechers	principal
Sun Microsystems	Marc Hadley	principal
Tibco	Frank DeRose	principal
Unisys	Lynne Thompson	principal
Vitria Technology Inc.	Waqar Sadiq	principal
W3C	Yves Lafon	team contact
W3C	Hugo Haas	alt team contact
WebMethods	Randy Waldrop	principal

Active Data Exchange	Richard Martin	principal
Allaire	Simeon Simeonov	alternate
AT&T	Michah Lerner	alternate
Bowstreet	James Tauber	principal
Engenia Software	Eric Jenkins	alternate
Fujitsu Software Corporation	Masahiko Narita	alternate
IBM	Fransisco Cubera	alternate
IDOOX	Miroslav Simek	alternate
Interwoven	Ron Daniel	alternate
IONA Technologies	Oisin Hurley	principal
Library of Congress	Rich Greenfield	alternate
Microsoft Corporation	Paul Cotton	alternate
Netscape	Vidur Apparao	principal
Oracle	Jim Trezzo	alternate
Philips Research	Amr Yassin	alternate
Rogue Wave	Murali Janakiraman	principal
SAP AG	Gerd Hoelzing	alternate
Sun Microsystems	Mark Baker	alternate
Tradia	Erin Hoffman	alternate
Tradia	George Scott	principal
Unisys	Nick Smilonich	alternate
Vitria Technology Inc.	Richard Koo	alternate

Commerce One	Murray Maloney	alternate
Commerce One	David Burdett	principal
Compaq	Yin-Leng Husband	principal
DevelopMentor	Don Box	alternate
DevelopMentor	Martin Gudgin	principal

Cisco	Krishna Sankar	principal
Compaq	Kevin Perkins	alternate
DaimlerChrysler R. & Tech	Andreas Riegg	alternate
DaimlerChrysler R. & Tech	Mario Jeckle	principal
Data Research Associates	Mark Needleman	principal
Epicentric	Dean Moses	alternate
Epicentric	Bjoern Heckel	principal
Informix Software	Charles Campbell	principal
Informix Software	Soumitro Tagore	alternate
OMG	Henry Lowe	principal
Progress Software	Peter Lecuyer	alternate
Software AG	Dietmar Gaertner	alternate
Software AG	Michael Champion	principal
Xerox	Tom Breuel	primary
XMLSolutions	Kevin Mitchell	principal
XMLSolutions	John Evdemon	alternate


Monday, Feb 26th
Morning Session I, 8.30a - 10.15a
Break, 10.15a - 10.45a
Morning Session II, 10.45a - 12.30p
  • Usage Scenarios /cont ....
Lunch, 12.30p - 1.30p
Afternoon Session I, 1.30p - 3.00p
  • Attachments: SOAP and ebXML
    • Presentation on Attachments/Referencing Data in ebXML and SOAP by Brooks, Frystyk Nielsen, Ibbotson; followed by discussion
    • The WG should decide how to proceed on this topic. The chair proposes a 2 part strategy (i) describe in the Abstract Model the payload, message/container, etc types of information and their relations, and (ii) when such a description is completed, decide whether time permits to incorporate the appropriate technology into XML Protocol v1.
Break, 3.00p - 3.30p
Afternoon Session II, 3.30p - 5.00p
  • Abstract Model
    • Overview presentation of AM, AMG issues and plans, Stuart Williams
    • Discussion, identification of issues
    • WG decides how to proceed with Abstract Model: as-is, with modifications, other
Evening: Working Group dinner
Tuesday, Feb 27th
Morning Session I, 8.30a - 10.15a
  • BEEP, 60 minutes
    Marshall Rose has kindly agreed to give a presentation on BEEP that will describe the technology and outline some ideas on how XML Protocol might map onto BEEP for use as a transport.
  • Conformance, 45 minutes
    Several WG members have expressed an interest in the WG taking on some work that will describe various types of XML Conformance. Ideas have included requiring at least 2 interoperating implementations, creating test suites to facilitate implementation, a full compliance test suite, etc
    The WG should decide whether it is interested in any such efforts, and if so, sketch out a couple of options that differ in the amount of effort (and hence time) required.
Break, 10.15a - 10.45a
Morning Session II, 10.45a - 12.30p
  • Issue List review. Starting with the issues generated by applying our requirements against the SOAP 1.1 specification, we will clarify and resolve as many issues as possible. Issues generated from the SOAP-issues-list to be tackled last (time permitting).
Lunch, 12.30p - 1.30p
Afternoon Session I, 1.30p - 3.30p
  • Issue List review /cont ....
    At the end of this session the WG should decide on the criteria for publication of the XML Protocol specification.
Break, 3.00p - 3.30p
Afternoon Session II, 3.30p - 5.00p
  • Glossary, ~60 minutes
    There has been significant discussion recently on the definition of intermediaries, paths, and addressing. We will attempt to come up with mutually acceptable definitions for the Glossary. See recent discussions on xml-dist-app.
  • WG progress, schedule (including document publication), and future meeting times and dates.
  • AOB

See also meeting details (Member only).

Monday 26 February 2001

Face-to-Face Schedule Discussion

See the timeline.

Publication Discussion

Discussion of Items Left To Do

Pending Action Items (see Web page)

Discussion of I18N - Contact David Clay if interested in discussing further

Usage Scenarios

12 Usage Scenarios - Discussion of how we handle

Henrik - spend 3 hours, what we get thru is what we get thru

Chair proposed spending a maximum amount of time on each one, Group agrees

We have 7 groups of scenarios:

Glen suggested going thru each one, checkpoint 1 hr. Agreed

DS 9 - Message data signature and encryption

Glen: whole message signed in DS9

Henrik: suggested clarification, DS9 may be sufficient

David Clay: DS9 doesn't talk about encrypting header, in 15 there are other things: there is positive ack. Suggested talking about encrypting headers

Mark Jones: DS10 should be in here too. Has same mix of issues

Chair: 6 is accepted. If we accept 10 then we dispose of 9 (dup). The question is whether we want completeness of others.

Jeff Kay: DS15 has notion of return receipt. seems to be above/beyond DS6/10 (which cover non-repudiation).

Chair: we've covered receipt, signing, and encryption somewhere. We don't have to do usage scenarios for high-level abstract piece. We're not trying to do design work here.

Chair Proposal: Dispose of DS9 by saying it's a dup. Proposal to accept DS10 and to accept DS15.


Henrik: 9 is covered by 5 and 15

Glen: 5 is different

Jeff: ack implies successful data transfer and acceptance of higher-level agreements

Marwan: We should accept both

Henrik/Glen: we may want to rewrite scenarios to address different aspects

Frank: 15 covers other things, tpa, confidentiality

Jean-Jacques -

Dick Brooks: ebXML backs off on 15

Amended Proposal: Accept DS 10, remove DS9 (is a dup), discard DS15.

Frank: Accepting DS10 implies supporting encryption and signing are supported via different agents. Frank would like to restrict 10. Important things are signing and encryption, not ready to attack other things.

Dick: Clarification: wanted granular signature capability so you can change en-route header

Chair: Accept 10 as it is, do good faith effort to support all aspects of 10 and do mapping at end-of-day to see if we can/cannot support.

Decision (group consensus): Proposal passes to accept DS10 as S10, remove DS9 as duplicate and discard DS15.

DS 11 - Communication via multiple intermediaries

Frank/Glen asked for clarification of DS:

Dick Brooks: ebXML has backed off on intermediary issues. When you have protocol that's intermediary aware, it gets very complicated. ebXML is becoming Point-to-point protocol. Intermediaries are black-box. Dick suggested that we may want to drop this (like DS15). In ebXML's case, they believe they have provided a point-to-point protocol in which recursion could be used to support intermediaries

Henrik: thinks point-to-point and intermediaries are two separate issues

Frank: items that aren't addressed by other S's (non-repudiation)

Dick: non-repudiation that intermediary received it and sent it along

Mark J: assigning a path and proving path is different that just basic intermediary support in protocol

Jeffrey Kay: we should keep this because this scenario would cover routing scenarios between namespaces.

Proposal: Promote DS11 to S

Chair suggests we accept DS11

Request for clarification on wording in text. regarding pointer to "DS11"

Henrik: "an intermediary forwards the message to the ultimate receiver. "

Proposal: remove real-life examples (last two sentences) of S11 (the real-life examples)

Decision (group consensus): DS11 is promoted to S11 with last two sentences removed.

Action Item 1: Henrik edited text dropping last 2 sentences

DS 19 - Sending Non-XML Data

Mark Jones: described sending picture from digital camera to wireless network. Key is that data is embedded within SOAP message

Proposal by Mark N. Because it is worded more like a requirement than a usage scenario, proposal to rewrite DS19 as a usage scenario.

Proposal: Rewrite DS 19 as a usage scenario

Action Item 2: Mark Jones to Rewrite this as DS


A digital camera wishes to transmit image data over a wireless link using XML Protocol to a remote server. The binary image data (non-XML), accompanies the message. The digital camera represents a situation in which connections from the receiver to the sender may not be permitted due to device limitations or firewalls.

Proposal: Accept above text as S19

Decision (group consensus): DS19 is accepted as S19 with the following wording:

"A digital camera wishes to transmit image data over a wireless link using XML Protocol to a remote server. The binary image data (non-XML), accompanies the message. The digital camera represents a situation in which connections from the receiver to the sender may not be permitted due to device limitations or firewalls."

DS12 (actually DS17) - Asynchronous 2-way conversation. Discuss with DS20 & DS23


Proposal (Glen Danials): Collapse DS20 and DS23

Proposal: Reword DS17 as a specific scenario

Noah: Issue is correllation of multiple requests

Mark J: LDAP directory requests which are non-blocking

David Clay: separate (asynch rpc request w/polling for one or more responses, asynch rpc with notification, rpc request/response.

Proposal David Clay: Take 3 categories listed above and make one case

asynch request with notification

Glen: Use DS17, remove notion of correllation id to say that must be able to glue set of messages together. Should be able to perform correllation.

Proposal: Reword DS 17

Intent is that an application should put its own correlation mechanism

Jeff K: Issue involves s sender/receiver not necessarily communicating on the same connection

Mark J: the scenario currently speaks to apps being able to insert app defined functionality

Action Item 3: Jeff Kay to propose new wording for DS17 (in background)

This item was left pending

Glen withdraws proposal to merge DS20 & DS23

Proposal (Glen): Accept DS20 and DS23 as two scenarios

Discussion on DS20

Vidur: "reporting the state of a device sounds like subscribing to event stream (Frank's comment).

Proposal (Vidur/Frank): remove entire "or" clause of DS20, DS23 stands as is

Amended Proposal: Accept DS20, after removing the or clause in its entirety, and accept DS23 as Scenarios

Discussion of taking notification out of DS23.

Amended Proposal: Accept DS20, after removing the or clause in its entirety, and accept DS23 as Scenarios

Decision (group consensus): DS20 becomes S20 without or clause, DS23 accepted as is

DS 21 - Incremental parsing processing of XML Protocol messages

Suggestion: delete second paragraph.

Vidur: delete

David Clay: include

John I: question regarding granularity. Is this elemental granularity or block level/header level. Does this mean the receiver must inspect in the case of mustUnderstand.

This is a scenario which describes incremental transmission.

John I: this will affect reliable messaging.

Glen: this will be needed by apps

Proposal: Accept DS 21 as S

Decision (group consensus). DS21 is promoted to S21.

DS17' - Asynchronous 2-way conversation.

Reworded by Jeff Kay

A sender sends a message to a recipient. The sender does not wish to maintain a connection to the recipient after transport of the message because the message requires a significant time to process (this could be because the transport protocol timeout is shorter than the message processing time or just because the sender is impatient). The recipient acknowledges the request but does not return a response to the request. The recipient processes the message. If the sender can be or wishes to be proactively notified, the recipient proactively returns the response to teh sender. If the sender cannot be proactively notified, the response is held until the sender initiates a request for the response from the recipient, at which point it is returned. The response may return either the anticipated response or a failure notification. The sender acks the receipt of the response...

Vidur: If the sender cannot be proactively.....sender initiates a request for the result from the recipient.

Mark: Recipient acknowledges request -> recipient may acknowledge request.

Glen: remove acknowledgement

A sender sends a message to a recipient. The sender does not wish to maintain a connection to the recipient after transport of the message because the message requires a significant time to process (this could be because the transport protocol timeout is shorter than the message processing time, because the return protocol is different, or just because the sender is impatient). The recipient does not return an immediate response to the request. The recipient processes the message. If the sender can be or wishes to be proactively notified, the recipient proactively returns the response to the sender. If the sender cannot be proactively notified, the response is held until the sender initiates a request for the response from the recipient, at which point it is returned. The response may return either the anticipated response or a failure notification.

Action Item 4: Jeff K to revise text again as 17a & b based on input.

Item left pending

DS 14/810 - QoS

Proposal: Drop DS14 and Accept DS810 As S

Decision (group consensus): DS14 is removed. DS 810 becomes S810

DS 24/809 - Caching

Mark N: This is a use case for an XML Protocol module.

Frank D: We need caching scenario

David Clay: neither represents adequately. DS809 doesn't cover enough.

Chair: suggest that what 809 covers is important so it should be accepted

Proposal: Promote DS809 to S809, DS24 remains DS

Amendment: to add intermediaries to support caching header (good until x)


BizCo updates the online price catalog every morning at 8am, Therefore, when remote clients acccess their xp inventory service, clients and intermediaries may cache the results of any price queries until 8am the next day.

Decision (group consensus): DS809 is promoted to S809 with the addition of text discussing intermediary support for caching header, DS24 remains DS24. Proposal passes with above addition for intermediaries

Attachments: SOAP and ebXML

Presentation by John Ibbotson, Dick Brooks, and Henrik Frystyk Nielsen

ebXML WG to address convergence of SOAP in TRP specs

See John Ibbotson presentation on ebXML Convergence with SOAP and Attachments.

See Dick Brooks's SOAP/ebXML convergence open issues presentation.

See Henrik's presentation of SOAP with Attachements.

Technical points have not all been resolved

Open issues remain

Abstract Model Group Discussion

Proposal from Chair on how to proceed: Instruct AMG in XML Protocol WG to draft a way of describing things such as how items travel with message.Astract model includes description to come up with a vocabulary for components of a message and relationship between them. Some travel with message but don't necessarily travel with the message.

Suggestion from David Clay: XP Must consider delivering MIME binding

Henrik: Need envelope model and data representation model

Chair: First order of business is envelope model

Noah: Need to discuss links (things that travel with vs. things that just get pointed to for informational purposes only).

Chair Observation: We're in design space. This area (needs crisp definition) should be worked through AMG. Need model of attachments, of data that goes with or does not go with messages, and would like vocabulary of this within abstract model for future discussions.

Ray D: abstract model (what does this mean). Think we need to define which type of model we're talking about.

Proposal: Instruct AMG to develop a model for attachments and data that may or may not travel with messages. Also, the AMG should suggest a vocabulary for this model.

Decision (group consensus): AMG to develop a model for attachments and data that may or may not travel with messages. Also, the AMG should suggest a vocabulary for this model.

Stuart Williams Presentation on AM

See slides.

This is an abstract processing model.

Stuart provided an overview of the abstract model characteristics:

Model Outline

Top-Level Diagram

Operations Summary

Operations currently covered by AM include:

Operations Through Intermediaries

Request/Response Discussion

AMG is Trying to model operational semantics

Henrik: looks very much like an API. Need to explain to people how they can go off and write an XML Protocol module

Clay: Need more work in targeting and routing

Message Path and Targeting

There was discussion that included:

Binding and Attachments

At this point a fire alarm sounded resulting in a building evacuation. The meeting reconvened briefly for formal adjournment.

Action Items

  1. Action Item: Henrik perform edits on S11
  2. Action Item: Mark Jones to Rewrite this DS 19 as DS
  3. Action Item: Jeff Kay to propose new wording for DS17 (in background)
  4. Action Item: Jeff K to revise text again as 17a & b based on input. Broken down into proactive notification

Tuesday 27 February 2001

Marshall Rose BEEP presentation 8:40 - 9:45

See slides.

Conformance: 9:45 - 9:50

David F.: We have a 301a Conformance Requirement. We need a small group of people to go off and make a proposal.

There were no volunteers. David strongly suggested that "you have signed up for the WG, you have committed to do the work, we need volunteers." Hugo H and David C volunteered.

Action Item: Conformance subgroup to come back with a plan to present and discuss in the teleconf in 2 weeks, 3/14/01.

Abstract Model (continued): 9:50 - 10:45

We will take the next 25 minutes continuing the discussion on the abstract model.

David F presented a slide that organized the areas for discussion around the AM. The text is as follows:

Proceeding with Abstract Model (AM)

1. Clarify nature of model
   - Describe SOAP, and Requirements
   - Integrate Glossary
   - Clarify implications with respect to implementation
     e.g. request-response and one-way transports

2. Sections to complete
   - Path and targetting section
   - Arbitrary attachments section
     - Describe SOAP with Attachments

3. Organisation
   - Small(er) group, WG to solicit proposals from AMG.
   - Publish AM as WD? Schedule?

David F: Personal preferences are to keep the AMG as a smaller group so that it is focused and nimble and and get some work done.

David C.: Are there template restrictions/guidelines for this type of document? David F.: Not really. There are 5 separate WDs from XML Query. We are at liberty to publish the AM in whatever format manner we want.

Henrik: Are these to be done in the AMG or now today in this meeting? David F: In the AMG, but let's have the WG discuss and give input into the AMG and decide on how to proceed for each of the 3 areas today.

Mark J.: Seems like we are pushing the more controversial issues into AMG (1-way/2-way, attachments, etc). Is this the right approach? What is the philosophy of our WG approach?

David F: The AM is the catalyst. They put the proposal on the table for the WG to discuss and reach resolution. Notice, we discussed but did not decide yesterday. Easier for AMG to crystallize the issues and proposals.

Stuart: The mailing list has all the issues. The subgroup's role is just to capture and synthesize. For example, Ray is not formally in the AMG but the is participating and is acknowledged for his contribution.

David F: The subgroup can come back with options for solutions.

David C: What about the issues lists? Should we fold into the AMG? Answer: Let's do that in parallel. For example, the SOAP discussion yesterday about request/response.

Is the AMG a bridge between the requirements and the spec? Yes, but it is a 2-way bridge.

Noah: Something on my mind. We need to worry about feature creep. Experience in Schema has shown that it is too expensive to work on them only to drop later. Let's make sure the AMG sees the design in the whole. As critical features come along, we could have them break out a subgroup to work on those. We need to limit the scope of the AMG.

John I.: AMG and the rest of the WG can decided what is important.

Noah: AMG with the WG manages an issue list about what is in and what is questionable.

Henrik: Could use some phone conf time to set the criteria for evaluating the deliverables from the AMG. It needs a charter.

David C: Charter could address the current issues: Security, What is a module? How is one specified and how is one plugged in?

Mark J: As the AM gets fleshed out, we should take the same approach we took for the requirements spec. Do we wait to the end for all or approve major sections and decisions along the way. Ans: We need to take the iterative approach.

Lynne T: We have the spec and the AM. The parallel schedule almost shows higher priority to the spec. We have a conflict in making the AM public but slowing it down from input from the outside.

Glen: Lots of people are here to make sure we just don't rubber stamp SOAP 1.1. The AMG is a potential foundation for understanding people's issues.

Stuart: AMG is not about designing XML protocol. It is more about shape the structure for design.

Noah: 2 quick responses. AM is a great thing for the reasons discussed. But be a good watch dog for feature creep. If we are doing the AM for any other reason than making the spec a better spec, then we are doing it for the wrong reasons. It should not be done second. It captures some of the reasoning behind the spec.

Ray D: My primary goal for the AM. When we have a spec, we need a way to sell to the community. The AM will be the tool I use for that. We should not put it on the back burner.

Noah: Arguing against letting it go on the slower schedule.

Glen: Can we get back to the AM rather than have a meta-discussion about the AM

David F: We heard reasons for and against the goodness of the AM. We have heard that there seems to be some agreement about the need for the AM. It helps with rationale, scope, selling later on, etc. From here? I am not in favor of a charter, but we should have some statement about the direction. Come back with a codification.

John I: We can validate the model by using the usage scenarios.

Henrik: I was not suggesting something so formal as a charter. One major issue is to reconcile the glossary. We need a common set of terms to our discussions and specs. The purpose of the AM is to give us terms and and a framework for our design. For example, it can give structure to what a module is and how it get specified and

Dick: My personal view. Gap analysis relative to SOAP and our requirements and our scenarios to identify how much additional work.

David F: We just went through an exercise of mapping requirements against SOAP.

Mark N: My view of the AM has changed. Scope of the AM is slippery. AM should be editors not designers.

Yves: AM could be used to fill the gap between requirements and SOAP.

Henrik: AMG should not be working on protocol design issues.

Glen: Should be working on higher level issues.

Marwan: Abstract, what is it? Should be written in a way so that it is easily understandable.

David F: We are overtime. How do get closure? We still have different points of view. What are its purposes? What are its objectives.

Glen: Should we summarize and take an opinion poll?

David F: We could burn lots of time quickly at the face to face. I would like a smaller group of people to formalize the issues around the AMG. I will summarize during the break - come and discuss with me if you want. Take a 20 minute break.

Break 10:45 - 11:50

Summary of AM discussion 11:50 - 12:05

David F: Describe the AM. A Document that describes the model. The Spec will be one realization with corresponding syntax of that model. There could be other syntaxes. There is a certain amount of rigor applied to it. How to get there? From our charter, we say we map against SOAP. We will have a certain set of issues. We will answer those issues. We can use the Schema WG as an example process. A list of issues exist with the AM today, such as the Glossary work. I think that we can ask the AMG to come up with the finite list (the to do list). Now, as we go through the Issues list keep in mind that it might go back into the abstract model to work out and help come up with a solution. We are going to be adding things into it over time. If there are inconsistencies today, we will have to resolve those, but we can't just step into the space of "abstract model" and never leave - it will turn into an endless debate.

Scott: Action item is for the AMG to define a finite list of to do's with input from all from the the mailing lists.

David F: Yes. The Schema WG had smaller teams to answer certain questions and then came back to a larger body.

Action Item: AMG to create a To Do list and to solicit input from the mailing list. This will be a work list to help show where we are and and far we need to go.

Issues 12:05 - 12:43

We spent some time figuring out what to do (putting the issues up on the display, figuring out the process, etc). Are we going to answer and solve these issues or just assign owner. The current list is just open, closed, and unassigned. A Clarify. B Determine if it is an issue. C. Assign an owner to leave and audit trail. Owner will craft a response.

Issue 44

Some confusion about RPC vs correlation ID vs transaction ID. The issues is meant to be correlation ID not enterprise transaction manager ID. The requirement is 200. What does "enable support" mean in the requirement? Do it or allow it to be done. Somewhere in between? Define the header or allow it to be defined? Do we have to know what the issue-creator had in mind? Seems that SOAP is half-way there in defining this correlation ID. SOAP RPC yes. Other request/response no. SOAP says leave it up to the binding but it must be there. What is the SOAP binding role? Can look at it two ways. Requirements from SOAP envelope down to the underlying protocol and requirements from the underlying protocol up to the SOAP envelope. For example, in the HTTP binding you have request/response. In other words, SOAP does not really have r/r built in, but because of the binding to HTTP, it causes SOAP to be used in the r/r mode. We know that we will have something under XML Protocol, but then we have to accept the features of that transport. Requirement says we MUST do it. Do we still leave it to bindings? We must get in the business of correlation ID because we have even called out RPC as a common application, even in SOAP. However, it does not say you must correlate responses with requests. Everyone agrees it is a fine line and it is easy to fall to either side. Needs an owner and an issue. Sounds like the 1-way and 2-way discussion. These needs to be cleaned up and probably broken up. Henrik volunteered, but recognized that he is probably not impartial. Some agreement that we need another owner. Jeff Kay is the owner. We want some preliminary report by the next Teleconf (3/7).

Action Item: Jeff Kay to have a preliminary report by the next teleconf 3/7.

On future teleconfs we will review issues.

Lunch 12:45 - 2:05

Issues (cont.) 2:05 - 3:15

Issue 41

Don't feel like it really precludes intermediaries. What is the role of the underlying protocol. Same issue with ebXML. ebXML used SOAP action header. Is there an issues with multiple transports? For example TCP on one side and UDP on the other, or multi-cast on one side and uni-cast on the other. Writing the bridges is easier if the semantics are in the content, that is consistent access to the headers and such rather than rummage around in the transport details. One interpretation is that SOAP says that headers and bodies are the same with one difference, actors. Body says I'm the body and something else told you how to get me here. Headers are addressed, bodies are not. Issue is understanding not arguing a solution. We seem to be breaking the layering rules, but that is OK so we can more easily support multiple protocols. If someone thinks it is not an issue, please describe how it works. Example: http to smtp. Where does an intermediary get the final address from the hop address. SOAP solution is to provide a way for new headers to be invented. These headers can have all sorts of routing information. XML Protocol needs to focus on how new headers can be defined not on actually defining them. We need to make sure that we can come up with an envelope that can support many different types of semantic headers. Are intermediaries higher or lower? Depends. We need a balance between defining the minimal and then also staying ahead of what people will be defining as new headers. We could have some sort of best practice or normative guidelines document. Again, ebXML uses SOAP action as targets, but that always uses MIME. In XML Protocol we should either 1) move towards always MIME or 2) allow some sort of target URI at a layer above the binding. SOAP HTTP binding has it. SOAP SMTP does not have it. Is the issue clear? Seems to be. Is the URI really a route and a protocol binding or a destination independent of binding. Suggested clarification for the issue: The target URI is not represented in the envelope in any normative way. Some debate as to whether the clarification actually helps. Noah will deliver a response to the by email by 3/7 teleconf.

Action Item: Noah will deliver a response to the by email prior to the 3/7 teleconf for discussion.

Issue 43

SOAP does not require method name to be URI. SOAP requires a namespace qualified name. Are our requirements wrong? Is this a case where it should go to the AMG. Send back to issuer and state why this is an issue.

Action Item: Ray Whitmer will send back to the issuer.

Issue 45

The issue should be in the form of a statement rather than a question. Then the statement should state why it is an issue. Does anyone feel that this is an issue? We could treat this as a bigger issue: RPC is just a module, modules need a standard way to extend status and error message and faults. RPC might be a good module to have in the spec and it could serve as a template for other modules. What about othe modules that need the RPC module? OK, we already recognize the need for composable modules. Seems like we want to do that. Henrik argues against having RPC as a module. What is a module? Have we defined it yet? It seems like a block inside a message. RPC thing sure seems like a module. Brings up the issue that Eric P. started: What is this body thing? The header and body are really the same - why have two? We have blocks and blocks go in either Header (intermediaries) or body (final destination). One view is the symmetry of headers and bodies. Headers have actors. Body has 1andFinal as default. If I wanted to tell my cache manager, do I use a header? Are all headers RPCs? We need to be more crisp. One feeling is that the separation between headers and bodies is artificial. SOAP currently says method name and parameters in the "BODY". No need for this restriction. Would like to see RPC as a module of XP. Back to the issue: are the errors just numbers, a small set, extensions, etc. Decide if RPC is a module first and that will then inform us as how to solve this specific issue. Propose move the question to some other small group other than AMG. We do that not because AMG is overloaded, but because we want to have multi-processing going on to help us make progress. Propose we close this and open a sub group. No, we need to leave this open until we have an answer. Need volunteers.

Small group: Ray D Ray W Marwan Henrik Mark J Volker W. Ray W will own the issue. Need a response be 3/7. Name: RPC subgroup.

Action Item: RPC Subgroup to have a response by 3/7 teleconf.

Break 3:15 - 4:00

Schedule says to move to Glossary, but Martin is the editor and he is not here and we have more issues, so we need to continue with issues. We need to think about schedules. W3C requires a "heartbeat" publication at least every 3 months. Candidates are: AM, Update requirements, Spec, etc. Proposed agenda change: 4:00 - 4:40 Issues. 4:40 - 5:00 schedule and scheduling another F2f.

Issues (cont.) 4:00 - 4:40

Issue 46

Are we still looking at the IETF work? yes. Close the issue.

Action Item: David F will be owner and draft a response by 3/7 teleconf.

Issue 42

Make it a glossary/editorial issue.

Issue 47

Now, SOAP has a data model. It is a graph with simple data types, structs, multi-structs, and arrays. There should be difference between a data model and then an encoding. Better to split them out. In the current spec, the difference is subtle, but there. Yes, carefully adopt the terminology, and then move forward with the distinction. Should we move to pending or leave open with a note. Need to leave open, but there is a concern that we are leaving too many things open for future extensibility. This threatens interoperability. Implicitly we are essentially prioritizing these issues. We are leaving open, not to keep open indefinitely, but to wait until more items get resolved. Still see too much in extensibility. Note that many things are putting interoperability at risk such as RPC as a module rather than as core. Does module imply optional in peoples minds? yes and no. Some no. What does mandatory mean? If RPC then RPC module is different than all messages are RPC. Other things we don't have for RPC: language binding, interface definition, conventions, etc. Is there a difference between "THE" XMLP RPC module and "A" XMLP RPC module. Relates to conformance. There is a big difference between Language bindings (SOAP does not do) and on the wire protocol definitions (SOAP does do). Are people using SOAP with or without the SOAP encoding? SOAP only mandates the envelope. If we have different bindings on the client side and both are SOAP compliant, can I get a different result? Should we leave open, close, or introduce a new item. Can we assign an owner? Dave Ezell will own. Have something by 3/7.

Action Item: David Ezell will be owner and draft a response by 3/7 teleconf.

Schedule and Scheduling 4:40 - 5:15

David F put up the schedule slide again. Need to publish by mid March. Obvious candidates Req, AM, Spec, or Glossary if separate. The spec is technically publishable, but some don't think it would be a good idea. We could make it a better proposal, but taking the spec and rolling the issue list (a snapshot of the issues) into it to show the world that there are still many issues. AM is a potential - we all seem to agree that it will be published at some time. Propose reconcile the glossary and publish as soon as possible. Taking it out of the requirements means to put into a document that will be published at the same time. Taking it out of a WD doesn't necessarily remove it from the public view. The heartbeat publications were set up when W3C WG's were less public, but we are very public. So, publications seem to imply more agreement rather than public face. Hence, we need to be careful about what we publish. What is the suggestion with the glossary? Do we all think that it needs to move to the AM? No clear answer and no clear WG feeling emerging. Reconciliation should happen independent of how it gets published. What is the upfront time to get it published now that it is already a WD? A few days only. DF recognizes some consensus in doing the work in the Requirements Doc and republishing it for our heartbeat req. Verbal for for yes. WG had decided we will publish a new Req Doc with an updated glossary. Henrik has already update the editor's copy on the w3c web site. By 3/7 all review. By 3/14 need the final document. Henrik points out that there are currently no outstanding issues against it. Martin owns the glossary. Stuart will meet with Gudgin to resolve the conflicts.

Action Item: Report from Stuart and Martin on glossary work by 3/7.

So we are not ready to publish the AM and the Spec, but what is our criteria for knowing we are ready to publish?

Admin note: We are at time (5:00), propose 10 minutes. All OK with that.

Should we go off the issues list? Might not be the right metric. We could prioritize the issues and then say publish when all higher priorities are done? David F will break up issues into two priority groups. Do not want to publish the docs with issue lists? Some think that it is OK. Some concerned about the risk of the world thinking we are just rubber stamping SOAP, but we need to be very careful in how we couch it. We could just publish the issues list. We could organize the issues into buckets and save a very small number in the top bucket and frame with questions to the public. From the point of view of appearances, we already have SOAP as a public document. It would give the wrong impression to publish with only boiler plate changes. So, agreement that we will not publish the Spec until there are more changes. The AM we will process on ideas for publishing once we have the issues list.

When is the next F2F?

Charter scheduled one for June. We need one 3 months out in Sep, but for the US attendees, the first Week in Sep is Labor Day, Monday the 3rd. An option is the 10th or 11th. June is a 3 day. Should we make the Sep a 3 day? Probably yes, reserve the right to scale back if needed. 1st F2F east coast US. 2nd F2F west coast US. 3rd east coast US. 4th will be Europe. Seems like the likely candidates are west coast US or Asia.

Take a vote, multiple votes allowed, question "Which locations would I prefer?"

So, west coast 10, 11, 12 of Sept. Wait, what about Monday meeting cutting into weekends. We took a preference vote for Mon, Tue, Wed preference vs Tue Wed Thu preference.

Decided to schedule the meeting for the tue/wed/thu.

Several volunteers for hosting on the west coast:

Action Item: Host vounteers will have 2 weeks to investigate and come back with a firm proposal.

Adjourn 5:15