ATTENDEES 39/35 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 AUTOMATICALLY EXCUSED 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 REGRETS Commerce One Murray Maloney alternate Commerce One David Burdett principal Compaq Yin-Leng Husband principal DevelopMentor Don Box alternate DevelopMentor Martin Gudgin principal ABSENT WITHOUT EXPLANATION 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
- Introductions
- Local arrangements
- Assign scribes
- Review agenda; AOB?
- Approve minutes from Feb 21 telcon
- Action items
- Usage Scenarios, start ~9.15a
Depending upon the number of draft scenarios, the WG should decide how to reach closure on the list. The chair suggests a time limited exercise.
The WG should also decide how and when to apply the scenarios.
Links on DS's are into mail archive, current text should be in Ed's Copy of Requirements Document.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).
See the timeline.
Discussion of I18N - Contact David Clay if interested in discussing further
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
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.
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
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
Reworded:
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."
Discussion
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
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.
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
Proposal: Drop DS14 and Accept DS810 As S
Decision (group consensus): DS14 is removed. DS 810 becomes S810
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)
Discussion
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
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
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.
See slides.
This is an abstract processing model.
Stuart provided an overview of the abstract model characteristics:
One-way, 2-way request/response and Intermediary operation
Operations currently covered by AM include:
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:
At this point a fire alarm sounded resulting in a building evacuation. The meeting reconvened briefly for formal adjournment.
See slides.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Make it a glossary/editorial issue.
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.
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.