Minutes of XML Protocol WG telcon on October 17, 2001.
Bracketed numbers, e.g. , correspond to references in agenda.
1. Roll call, scribes for minutes/action items
- Akamai Technologies Mark Nottingham
- AT&T Mark Jones
- BEA Systems David Orchard
- Canon Jean-Jacques Moreau
- DaimlerChrysler R. & Tech Mario Jeckle
- Data Research Associates Mark Needleman
- DevelopMentor Martin Gudgin
- Fujitsu Limited Kazunori Iwasa
- Hewlett Packard Stuart Williams
- IBM John Ibbotson
- IBM David Fallside
- IBM Doug Davis
- IDOOX Jacek Kopecky
- Intel Randy Hall
- Intel Highland Mary Mountain
- Interwoven Mark Hale
- IONA Technologies Oisin Hurley
- Lotus Development Noah Mendelsohn
- Macromedia Glen Daniels
- Matsushita Electric Ryuji Inoue
- Microsoft Corporation Henrik Nielsen
- Mitre Marwan Sabbouh
- Mitre Paul Denning
- Oracle Anish Karmarkar
- Philips Research Amr Yassin
- Rogue Wave Murali Janakiraman
- SAP AG Volker Wiechers
- Software AG Michael Champion
- Sun Microsystems Marc Hadley
- Sun Microsystems Chris Ferris
- Tibco Don Mullen
- Unisys Lynne Thompson
- Unisys Nick Smilonich
- Vitria Technology Inc. Tony Lee
- W3C Hugo Haas
- Xerox Ugo Corda
- AT&T Michah Lerner
- BEA Systems Jags Ramnaryan
- Canon Herve Ruellan
- DaimlerChrysler R. & Tech Andreas Riegg
- DevelopMentor Don Box
- Fujitsu Limited Masahiko Narita
- IDOOX Miroslav Simek
- Interwoven Ron Daniel
- IONA Technologies Eric Newcomer
- Macromedia Simeon Simeonov
- Microsoft Corporation Paul Cotton
- Oracle Jeff MischKinsky
- Philips Research Yasser alSafadi
- Rogue Wave Patrick Thompson
- SAP AG Gerd Hoelzing
- Software AG Dietmar Gaertner
- Tibco Frank DeRose
- Vitria Technology Inc. Richard Koo
- W3C Yves Lafon
- Active Data Exchange Richard Martin
- Novell Winston Bumpus
- Compaq Yin-Leng Husband
- Engenia Software Jeffrey Kay
- Engenia Software Eric Jenkins
- Ericsson Research Canada Nilo Mitra
- Informix Software Charles Campbell
- Library of Congress Ray Denenberg
- Active Data Exchange Shane Sesta
- Compaq Kevin Perkins
- Informix Software Soumitro Tagore
- Library of Congress Rich Greenfield
- Martsoft Jin Yu
- Netscape Vidur Apparao
- Netscape Ray Whitmer
- Novell Scott Isaacson
- OMG Henry Lowe
- WebMethods Dave Cleary
- WebMethods Asir Vedamuthu
2. Agenda review, and AOB (12.05 + 5)
3. Approval of minutes from 3 Oct telcon  (12.10 + 5)
Hugo: committed DF's changes about wrong conclusion. Should we make public
the report from the TBTF?
DF : Any particular part that is problematic?
DF : any problems?
DF : Minutes are approved as posted
4. Review action items, see  (12.15 + 10)
Come up with resolution text for issue 30
<Paul not present>
Report back the status inside XML Query regarding void/non-void return
values, in time for 17 October teleconference.
<Paul not present>
Think about expressing SOAPAction as a property/feature.
Tweak proposal for issue 12 (accepted), send resolution text for issue 12.
DF: Chris did that. Chris and DF will figure out how to respond to Larry.
Investigate if issue 4 should be closed or not (likely to be yes).
2001/10/10: Nilo & Hugo.
Make the draft of the primer public.
2001/10/10: DavidF + W3C Staff
Make TBTF draft proposal public.
Send response for Issue 14 to Larry Masinter
Done (no response from Larry)
Close i112 and i53.
Send resolution text for i139 to xmlp-comments.
Put in section 2 the wording from http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0053.html
Create new issue out of issue 140.
Start an email thread on the nature of redirecting/postponing the "XML Document Type" issue.
Done (by Noah, unable to contact PaulC's by email for review)
5. Status reports (12.25 + 20)
DF: Nilo not on the call, but he did send an email: He has included
CF's comment. No other comments were received. He is still looking for
ideas for a more gentle intro to SOAP. WG members are encouraged to send
ideas to Nilo.
Editors have nothing to report.
Stuart: Telcon minutes are posted. We are seeking feedback. Converging.
Noah has posted a note stating possible points of consensus in TBTF
and wider community. Actio Item for HFN and Stuart to work on framework
Noah: 4 points of consensus included the points that came up on the
TBTF telcon. It is not a consensus but more of an individual view.
Jacek: The ETF started last week, it tackled 5 issues.
Text of Jacek's report, http://www.w3.org/2000/xp/Group/1/10/17-etf-report
Noah : Sent an email on the last issue. We should give guidance. We can
refer to soap+att. When should they do what? soap+att means that the
data is traveling with the message even if it is not in the
envelope But there is another case where the data is somewhere on
the web. eg: an x-ray that is available on a site somewhere.
That makes an assumption about the environment.
DF : About issue 29. WG's charter says we have to enable SOAP to carry
application data, and it calls out RDF and UML as examples of
applications' (model) data. We have started to interact with the RDF
community to ensure SOAP can carry RDF, and we need to start interaction
with UML community as well.
-- Conformance work
Hugo : Finished setting up a web page for call for test contributions.
Oisin: I still have some work to do on the assertions doc. I don't' have
anything to add, this is work in progress.
-- Usage Scenarios 
JohnI : 1st draft contains scenarios. Added further to that. Went out
yesterday. Haven't seen my email on the list. Will resent it if I do
not see it soon. Had some feedback from Nilo: concern that it may
not be appropriate for the primer. Not valid. I request comments.
DF : Where are you in terms of numbers of scenarios done, numbers TBD?
JohnI : 14 done, 6 todo.
DF : Any help needed?
JohnI : 2 in particular - appreciate comments on them. One of them relates
to incremental parsing and processing. What comments/issues should
be made/brought out. The other one is caching with expiration.
What features should be supported. Also straight caching one as
JohnI : Do you still want this to be on the private or public list?
DF : Make it public. Hugo - please add this to our web page
JohnI : Should we wait for this to be complete before making it public?
DF : No. Send it to Hugo for publication and send an informational email
6. Issue 134, xml:base support  (Postponed from last week)
DavidO has created a proposal  for how to (positively) support xml:base.
There appears to be a well-received friendly amendment to this proposal
. The chair proposes the WG accept either this new proposal (as
amended), or Noah's original proposal .
DO : Took Noah's proposal/wording and 'NOTed' it. 'disallowed' changed to
'allowed'. There was an error: use of URIs and soap elements.
Henrik can you elaborate on why nothing was submitted to the list
(referring to a revised version of his proposal)?
HN : No. I was wondering that myself.
DO : A concrete proposal was supposed to be made to the list, but did
not make it to the list. Let us postpone this. There was a
Hugo: Did I miss discussions on this proposal?
DO : They were private. There was a mixup as to who was going to submit it.
DF : WG ok on postponing?
Hugo: Can we have a deadline soon so that we can review the proposal?
DF : David when will you have a proposal?
DO : By monday or earlier.
DF : If it was a miscommunication as you describe, why cannot you send it out
DO : It was actually more than just a miscommunication ......
DF : Can we have it by end of the week?
DO : Yes.
7. Issue 138, use of text/xml 
We have a longstanding issue  (and more recently ) to address the
currently mandated use of the "text/xml" media type for SOAP messages in
the HTTP Binding (see section 6 of Part 2). More specifically, the
complaint is that "'text/xml' is appropriate only when the XML document is
readable by casual users (not programmers)". Throughout the voluminous
discussion on this topic, there seems to be little disagreement about not
using text/xml, rather, the discussion centers around what to use instead.
At the risk of oversimplifying the debate, it appears it is about finding
the right balance of information. A minimalist approach favours
"application/xml" and a less minimal approach favours
The Chair suggests we start by determining what are the viable alternatives
to consider (app/xml, app/xml+soap, others?), and briefly hear the pro's
and con's for each. The WG should strive to find a commonly acceptable
resolution, either on this telcon or in time for the next telcon.
DF : My reading is that no one disagrees with the idea that text/xml is
the wrong type, but no agreement on what type to use instead. app/xml is a
fine way to go, but there is a view that we need to further refine
this, e.g. app/xml+soap. How far does one go in refining?
Note a possible tie in with item #9, as suggested by LarryM.
What is the range of possibilities for the type?
MN : Options are: app/xml or app/soap or app/soap+xml. Personally prefer
app/soap, app/soap+xml. The reason is that there needs to be a easy
way to identify a soap message similar to SOAPAction. Content-type
is the most recognized way to detect a message type.
HN : Some historical backround - 1st request was for the Content-type
app/soap+xml. One thing that came out which RFC 3023 does not talk
about??? 2nd request came out was app/xml. One more thing about
Issue 9, I would be concerned about substituting xml with soap.
This is the least of the concerns.
CF : I agrre with MN's comments. Preference for either app/soap or
app/soap+xml. app/soap is an improvement. We should be able to
dispatch based on the type. A soap processor is more than an xml processor.
We need to clearly identify soap messages to enable dispatch.
Gudge: I was curious about item #9. Surely, we have not decided anything about it?
CF : We decided that xml declaration is allowed, because it is not a PI.
Noah : That is not correct. I think PIs are part of message model which we
ruled out. We agreed to close Larry's issue and opened another to
be decided in http binding.
MarcH: That is correct
DF : Issue 145 (item #9) - does it actually capture what Larry intended?
Noah : I am not sure
DF : Please look at it before we get to that agenda item
Noah : 145 does not capture the fact that it is binding specific.
The email thread has it in there.
Noah : On 138. 2 things: the comment that this isn't xml but it is soap -
that is true of all xml docs because they are all xml vocabularies.
Can someone give a tutorial about how mime-types should be used?
CF : That was what RFC3023 was supposed to address. There was a desire that
you could identify a specific media type.
Noah : Is this widely accepted?
MN : I looked at other w3c docs and they identify types. In general, this issue
affects things outside this group, and this may be a coordination issue
and we should defer to wider expertise.
DF : Would IETF prefer app/soap or app/soap+xml?
MN : It depends on how it is used. The feedback was that app was
HFN : I agree with MN w.r.t. coordination with other w3c WGs. No
mime-processor will recognize the "+" type.
This could raise issues with tools, consistency, and backward
CF : That is a red herring Henrik. Whether a mime-dispatcher can deal
with +xml is irrelevant. RFC3023 does suggest this approach, and
eventually the mime-dispatchers will catch up. We should be more
concerned with identifying the doc as a soap doc.
DO : My concern is I don't think we understand how people will end up
needing to use mime-types for complicated processing. I never have
just a blank soap message. app+soap+xml. How far do we go with
the "+" notation. We should take a simple approach and use
app/soap with no "+"
MN : There is a judgment call in deciding the depth of "+".
The key is not discovering every feature. If we use app/xml it is
hard to distinguish. We should decide: app/xml or app/soap and then
resolve the "+" issue.
DF : Proposal- to divide the issue into 2 sub-issues.
Clarification: what does a avg mime-handler do? Does it throw away
if it does not understand the string following /
MN : The subtype is a opaque string. If it is looking for it then it
will find it, else it does not matter.
CF : response to DO - soap msg has a specific processing model and a
spec. It does not matter what is in the message. It is a soap
message. We don't want to go there. TBTF has discussed the issue
and I don't think this should be done. What is inside the message
and the namespace issue is a red herring.
DF : straw poll: 1) app/xml 2) app/soap"ish", if (2) then we will
consider the sub-issue of whether "soap" or "soap+xml" or "soap+etc"
DF : poll results, (1) 0 (2) lots, no-one opposed to (2)
DF : 2 ways have been suggested to handle this, (i) seek coordination, and (ii)
seek wider input. And, Chris suggested putting "application/soap" in the spec
and asking for feedback.
MN : I second that.
DF : We can certainly target IETF and WGs for feedback.
Hugo : I can take an action to ping other W3C WGs, e.g. SMIL, SVG, and ask
how they arrived at a decision.
DF : So, your suggestion is to do some internal research before we put this
in the spec?
Hugo : I think CF's suggestion is fine.
HN : It's a good idea to specifically ask WGs.
DF : Proposal- we use the application/soap media type in the spec with an appropriate
request for feedback on the precise "soapish"-ness of the sub-type.
We also pro-actively seek feedback from IETF and other WGs.
WG agreed, no dissent.
DF : We need volunteers to craft the emails.
Hugo : I volunteer for the WG email.
MN : I volunteer for the IETF email.
HN : What feedback are we asking for from IETF? We need to target a specific
area/group and not be all over the map.
DF : Mark is one of our liaison with IETF.
MN : Not official.
DF : MarkN and Henrik can you target the appropriate group(s) in IETF?
8. Issue 70, define processing intermediaries 
This issue was recently closed but there appears to be continuing email
traffic on the subject . Is there new information to consider such that
this issue needs to be reopened?
DF : We closed issue 70, but there have been subsequent emails. Do we need to reopen
the issue? What does the WG think?
JJM : There were 3 points: 1) does an intermediary always forward an
incoming message?, 2) hence is an intermediary always a SOAP
sender? and 3) can an intermediary process zero block? We also
need to clarify that intermediaries.
DD : We should remove that the soap intermediary is a sender as well.
HN : Why? An intermediary is both a sender and a receiver. What is
the benefit of introducing a 'piece of magic' that forwards the msg?
Noah: I agree with Henrik. There is one aspect, however, which is unresolved. If a
node (intermed.) receives a message and chooses not to process a block
should it forward it all? This is unresolved.
I think we should leave open the possibility that messages can
be branched and combined, eg. for multicast. We don't need to specify
Noah: W.r.t. sec 2.5, my point is that the spec covers most of things about
forwarding, but does not cover things like encryption. etc.
HN : I agree. The spec is too restrictive.
Noah: Do we need to say anything? The original intent was that all things
being equal, intermediaries forward anything they do not work on. But
this intent is hard to put in the spec.
DF : JJM and Doug, does Noah's characterization capture what you said?
JJM : Noah's sentence used the passive mode ("message are being
forwarded further along the message path"), whereas the definition
for intermediairies is using the active mode instead ("an
intermediary transfers the message..."). The active mode is causing
some concern to some people.
Noah: <explained what is in 2.5>
DD : I think the spec is too passive. It does not say that the intermediary is
Noah: We talk only about soap nodes, some are senders some are receivers.
DD : An intermediary cannot be a sender.
HN : Then it is an endpoint.
DD : That means that it results in a certain implementation choice.
Noah: One node has one responsibility and how it is implemented is not
relevant. If a message does not stop there then it has to be a sender as
well as a receiver.
DD : What if instead of sending a message over a socket it makes a
Noah: This looks like implementation stuff and should not go in the spec.
A node is an abstraction. Procedure calls are not nodes. The spec
should not discuss this.
DF : We need to resolve this over email. We need to clarify if there is an
issue here. Let us take that to email. Let us not discuss this here.
JJM, Doug and Noah should start this thread in email.
DD : I can live with what is in it right now.
DF : We still have a pending issue to clarify the notion of an intermediary,
and its treatment of headers.
Noah: Someone sent an email saying this is not good enough. So the thread has
already been started.
DF : NM can you find this thread and restart the discussion.
Noah: I will do that.
9. Issue 145, XML declarations in SOAP messages 
This issue is the follow-on from issue 4 regarding PI's in SOAP messages.
It appears the originator wants us to clarify SOAP's position on the XML
declaration, e.g. <?xml version="1.0"?>, which syntactically is a PI; We
decided to say that SOAP messages SHOULD NOT contain PI's.
DF : The issue stated in the list and in this agenda may not reflect
what was being called for by the originator.
DF : Can we figure out what is the intent of issue 145?
MarcH: I had a discussion about this with Larry. We both agreed that the xml
declaration isn't a PI, so we closed #4 and opened a new issue.
Noah suggested that this new issue is should be tackled as part of the binding.
DF : Should the TBTF then be actively considering this?
Noah : Yes.
Hugo : I don't see how the declaration is different from PI.
Gudge: A PI is part of the infoset and xml declaration is not.
DF : Lets take this one off-line and to TBTF. Let us take it out of the
agenda for the moment.
10. Issue 61, external payload reference 
This issue is motivated by Req 700a  which concerns submission of
application-specific content, and suggests a number of ways the WG may
consider carrying such content inside and outside the envelope,
(i) carrying application specific payloads inside the XMLP envelope,
(ii) referring to application specific payloads outside the XMLP envelope,
(iii) carrying nested XMLP envelopes as application specific data within the XMLP envelope,
(iv) referring to XMLP envelopes as application specific data outside the XMLP envelope
Last week, the WG decided to not take on the task of creating an XML
document type, a decision which effectively removes item (iii) from
consideration. The WG has not explicitly discussed SOAP w/ Attachments
(e.g. as the "B.1" option in last week's XML document type discussion),
however the Chair advises the WG that taking on S+A would adversely affect
our schedule. S+A provides an obvious candidate mechanism for items (ii)
and (iv), and by postponing action on S+A, Req 700a need only consider item
(i). In this case, can we agree to resolve issue 61 by saying that we
provide an extensible mechanism, including SOAP encoding, for the purpose
of "carrying application specific payloads inside the XMLP envelope"?
DF : With an eye on the clock it is too late for the WG to consider soap+a.
Given this (ii), (iv) are out. (iii) is out. Leaving (i). Can we
do that within the envelope?
DF : Does the WG agree that we will not consider soap+a?
DF : Any objections?
JohnI : one of the usage scenario refers to soap+a.
Noah : It is reasonable to not take up soap+a. We need to at some point
review requirements and use cases. Do we know what things we are
obligated to do well?
HN : I agree. I think it is very soapish to go crazy and add more things.
It is consistent with what we have been doing with soap 1.2.
Noah : It all depends on the requirements and we may want to review those.
CF : I understand the thinking behind making it non-normative. But
people do need this and are using it. It is an obligation on our
part to say something about this. We could say that this is one way
and not the only way (similar to HTTP). The soap+a spec is well
written and we don't really need to do a whole lot. We should give
Hugo : I agree that lots of people need to use soap+a. But I will echo DF's
concern about meeting deadlines.
MN : Our charter explicitly says that we do not have to deal with this.
JJM : Can a subgroup look into this: what would it take?
DF : We already have 2 subgroups struggling to find time.
JohnI : soap+a spec all it says that there are things that you can do with
the env and mime-packaging. It is simple piece of useful technology.
Is there a mechanism that we can use to point to this spec as an
informative text? Eg; in the primer or scenario doc.
DF : The use of the term informative can be recast as non-normative.
JohnI : I would be happy with that.
HN : I would be happy with that.
Hugo : We need to be careful about the wording.
DF : Any objections to having non-normative reference which is carefully
DF : proposal-
"Make a non-normative, 'for instance', reference to soap+a
and possibly to other technologies. We will not take on soap+a
as a normative work item. We will also remove from any part of
the requirements document that soap+a technology is a
Hugo : I am not sure I would put that reference in the spec. rather in the usage
DF : The exact place can be TBD.
JJ : I object. We need to have an efficient way to send large amount of data.
Stuart: I would like to talk to one of the authors from HP and consult with him.
DF : I would like to postpone this proposal.
WG agrees to postpone decision on proposal.