W3C XML Protocol Working Group teleconference, 17 O ctober 2001

Minutes of XML Protocol WG telcon on October 17, 2001.
Bracketed numbers, e.g. [2], correspond to references in agenda.

1. Roll call, scribes for minutes/action items

Present 36/30 Excused Regrets Absent

2. Agenda review, and AOB (12.05 + 5)


3. Approval of minutes from 3 Oct telcon [1] (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?
  Hugo: No.
  DF  : any problems?
  <no answer>
  DF  : Minutes are approved as posted


4. Review action items, see [2] (12.15 + 10)

2001/08/29: PaulC 
      Come up with resolution text for issue 30 
      <Paul not present>

2001/09/13: PaulC 
      Report back the status inside XML Query regarding void/non-void return
      values, in time for 17 October teleconference. 
      <Paul not present>

2001/09/13: TBTF 
      Think about expressing SOAPAction as a property/feature. 

2001/10/03: ChrisF 
      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.

2001/10/10: Hugo 
      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. 

2001/10/10: Gudge 
      Send response for Issue 14 to Larry Masinter
      Done (no response from Larry)

2001/10/10: Hugo 
      Close i112 and i53. 

2001/10/10: ChrisF 
      Send resolution text for i139 to xmlp-comments. 

2001/10/10: Editors 
      Put in section 2 the wording from http://lists.w3.org/Archives/Public/xml-dist-app/2001Oct/0053.html 

2001/10/10: Hugo 
      Create new issue out of issue 140. 

2001/10/10: NoahM 
      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)

-- Primer
    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.

-- Spec
    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.

-- ETF
    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 [3]
    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
            to dist-app


6. Issue 134, xml:base support [8] (Postponed from last week)

DavidO has created a proposal [9] for how to (positively) support xml:base.
There appears to be a well-received friendly amendment to this proposal
[10]. The chair proposes the WG accept either this new proposal (as
amended), or Noah's original proposal [11].

    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
          right away?
    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 [19]

We have a longstanding issue [17] (and more recently [18]) 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?
    MN+HFN: yes.


8. Issue 70, define processing intermediaries [12]

This issue was recently closed but there appears to be continuing email
traffic on the subject [13]. 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 
          it completely.
    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
          doing it.
    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 
          procedure call?
    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 [14]

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.
    MarcH: 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 [15]

This issue is motivated by Req 700a [16] 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 
            some guidance.
    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.