XMLP Working Group Telcon Minutes, 12 November 2003

1. Roll call.
Present 12/7
BEA Systems, Mark Nottingham
BEA Systems, David Orchard
Canon, Herve Ruellan
IBM, David Fallside
IBM, Noah Mendelsohn
IBM, John Ibbotson
Microsoft Corporation, Martin Gudgin
Oracle, Anish Karmarkar (scribe)
Sun Microsystems, Marc Hadley
Sun Microsystems, Tony Graham
W3C, Carine Bournez
W3C, Yves Lafon

Canon, Jean-Jacques Moreau
Microsoft Corporation, Jeff Schlimmer
Oracle, Jeff Mischkinsky

DaimlerChrysler R. & Tech, Mario Jeckle
IONA Technologies, Seumas Soltysik
SAP AG, Volker Wiechers
SeeBeyond, Pete Wenzel
Systinet (IDOOX), Jacek Kopecky

DaimlerChrysler R. & Tech, Andreas Riegg
IONA Technologies, Mike Greenberg
Nokia, Michael Mahan
SAP AG, Gerd Hoelzing
Systinet (IDOOX), Miroslav Simek

2. Agenda review, and AOB

3. Approval of November 5 telcon minutes,
Approved without objection

4. Review action items, see http://www.w3.org/2000/xp/Group/Admin/#pending

5. Status reports and misc
-- Placeholder for pending items
  o December 2003, f2f planning (registration closes 21 November). Note:
there will not be a WG telcon on the Wednesday before the f2f.

MarkN: we have found out that the IESG had determined that our reg was not 
  valid and had rejected it and had not told us about it. Discussing with IETF 
  as to why this is really bad. I did not represent the WG, but have been 
  discussion on my own behalf. They are currently not very happy with me. 
  We need to resubmit our reg. We can either resubmit and use the old system, 
  make the entire thing as a internet-draft OR wait till the new process is 
  put in place -- where we put the stuff in the Rec. I think we decided to take 
  the previous route. If we choose the shorter route then the media type stuff 
  in the Rec is no longer normative.
DavidF: what is fastest
MarkN: submit a new ID.  New process -- not sure how long it will take, we 
  could ask the liaison as to when it would happen.
DavidF: sounds like we should just resubmit
MarkN: we should work with liaison

  o March 2004, f2f planning (possible items include: co-ordination mtg w/
WSD WG re. description of attachments)

-- Registration of "application/soap+xml",
Covered above.

-- Update on XMLP/SVG WGs' collaboration on a "Generic MTOM" spec, DavidF
to report. (Proposal at
No report.

-- The WSD WG will be working on describing attachments and media types in
XML. There has been some interest in setting up a joint Task Force with WSD
WG on one or both of these topics (e.g.
http://lists.w3.org/Archives/Public/xml-dist-app/2003Sep/0046.html). Does
XMLP WG wish to work with WSD WG on one or both of these topics, and if so,
should we setup a TF?

Anish: We had asked the WSD WG to undertake two things related to MTOM:
  description of an MTOM binding in WSDL 2.0 and use of media types in XML. The
  WSD WG has decided to undertake both. For the 'use of media types in XML',
  they have decided to publish this work as a W3C Note. I had mentioned to
  Jonathan Marsh, who is the chair of the WSD WG, that there was some interest
  within XMLP WG, in forming a joint task force to do this work.
MarkN: sounds like a good idea. We should use something more light weight than a
MarcH: I don't think there is anything more light weight than a W3C Note.

WG agrees to form a joint TF 

-- W3C staff seek feedback on providing short names (URLs) for WG documents
in progress vs. for old/stable documents such as the SOAP 1.1 Note

Carine: we have a short name "soap" which points to the SOAP 1.1, the plan is 
  to point it to the W3C Rec.
Anish: would it point to part 1 or part 2?
Carine: it will point to a cover page
Noah: we have done such a thing for a while. I suggest we update our WG page 
  to point to the cover page

WG agrees to the change.

6. Attachments
-- Placeholder for pending items
    o Update on Copyright and IP statements

-- Document summary [comments]
    o Proposed Infoset Addendum to SOAP Messages with Attachments, private
doc, 1 April 2003,
http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html [starting point
doc for WG's Attachment work]
    o Attachment Feature, WD, 24 Sept 2002,
    o Attachment Feature, Ed Copy, 24 Sept 2002,
http://www.w3.org/2000/xp/Group/2/07/SOAP-AF/aftf-soap-af.html [how is this
different from the WD?]
    o SOAP Optimized Serialization Use Cases and Requirements, Editor's
Draft, 16 October 2003,
http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html. WD
    o SOAP Message Transmission Optimization Mechanism, WD, 21 July 2003,
http://www.w3.org/TR/soap12-mtom/; Ed Copy, 8 Oct, incorporates XQuery
datamodel at

-- We had originally thought to use a media type to flag MTOM usage but
further investigation by MarkN indicates this is not feasible (e.g.
RFC2048, sec 2.2.1). The next best option proposed by MarkN is a media type
parameter, such as:
            application/soap+xml; enc="http://www.w3.org/2003/11/soap-mtom"
MarkN further proposes to ask the W3C's IETF/IESG liason to verify that an
MTOM media type parameter is indeed the preferred option. The Chair will
ask the WG whether or not to accept these proposals (possibly with

DavidF: <summarises Mark's issue>. Noah read the same section that Mark read 
  and reached different conclusion
MarkN: rfc basically says that only thing that are identifiable as formats
  should have a media type. But things like gzip should not be used as a
  media-type. We will have significant difficulties trying to register this.
  SVG has a different encoding but they have not tried to register a separate
  media-type. We should go through the w3c-iesg liaison and find out if this is
  indeed possible.
DavidF: <reads the relevant section>
Noah: I think Mark is more sensitive to these issue wrt to guessing IESG's
  mind, so I will defer to him. I think this is the alternate encoding for SOAP,
  and it is the entire multipart not just the SOAP env. I would claim that if we
  gzip it, then you just have to look at it differently and you get the SOAP
  message. I think that this is slightly different. It says you don't have the 
  info you need, but you have instruction to get it -- look at the 
  xbinc:include, this is not part of the SOAP processing model, but a different 
  representation. I find it attrative to have a different media type. I think 
  the comparison with gzip is apples and oranges.
MarkN: i could be wrong and it could indeed sail thru the IESG. There are MIME
  processors such as procmail that do not deal with parameter. Same with Apache.
  So this might be a problem. But you can write a script to do this is Apache.
Noah: my problem is more fundamental. It is exactly the separation from SOAP
  that makes it clear that it is not SOAP.
MarkN: we could take that approach, but I am concerned about IESG. They are
  going to view this as an encoding. The attractive thing for me is that we 
  only have a parameter and therefore there is only one mediatype to register.
Noah: I think we should not make the decision based on what IESG would do, but
  rather what is the right thing to do.
DaveO: Seems to me that there are two different perspective on this.
MarcH: my question is - we have been talking about separating out MTOM
  functionality and applying it to SOAP.

<more discussion about this - minutia not captured in the mintues>

Noah: how do we use gzip?
MarkN: use content-encoding or content-transfer-encoding
MarkN: our encoding is specific to xml. The bar for registering conent-encoding
  is low, the bar for content-transfer-content is very high
DavidF: because of Mark's personal standing, we could have someone else's name
  on the media type draft and use liaison.
Mark: i don't think it has reached the stage where they would reject it because
  of my name. That would be unprofessional.
Yves: I had originally proposed that content-encoding carry this information. 
  It is more then a simple serilization of soap, so it might be a better idea 
  to have a diffent media type. Mark can we use application-tar or xtar?
MarkN: we could use X header. That would affect the relationship between W3C and
DavidF: we should get two media types but ask w3c liaison to ping them about a
  likely outcome.
DavidF: would anyone be unhappy with putting together a separate media type and
  asking the liaison to ping IESG? If there is feedback that it won't fly then 
  we will have to change our approach.
MarkN: we could create a quick ID, and circulate it on the ietf types list and
  see if we get any feedback.
Noah: can we do a 2pc (phase-commit) protocol? Otherwise there is a catch-22.
MarkN: there isn't a 2pc, but there is discussion on the new process. We could
  do a application.vnd.w3c or some such thing. This would be easier  but still
  could be rejected. The vnd type does not require publication in advance
DavidF: I don't think w3c would not want to be a purveyor of vnd media type.

<more discussion on the same -- minutia not captured in the minutes>

DavidF: we should go for the real media type and if they say no then we should
  consider other option. How does a liason process work?
Yves: It is a telecon every 3 months. There is also a ML. We could send it
  there. You will then hear from w3c and iesg.
DavidF: Lets do the following: prepare a proposal (doesn't have to be full ID)
  and have rationales like Noah had in his email and we can drop that on the ML
  and in parallel prepare a draft.
DavidF: hearing no objection we will go forward with this. Need someone to do
Mark: I would be happy to do this if Noah would help me with this.
Noah: ok.

-- Issue discussion
    o 440, Sharing MTOM parts for identical leaf nodes,
http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440. See thread starting

DavidF summarizes the current state --
Gudge proposed a 1-to-1 mapping.  Two alternate suggestions: why can't I have 
more than one ref to a part and why could you not have parts that are not 
referenced from anywhere.

DavidF: Gudge, can you outline your position in 2 minutes?
Gudge: my position is this -- i want 1-to-1 mapping because if there are
  multiple includes that reference a single part, it makes life harder for
  intermediaries. There is no easy way to know if a part can be dropped.
  Wrt not allowing mime part which are not referenced -- this fits in my view of
  everything sould be in the infoset. The reason for doing MTOM was to keep
  everything in the infoset
MarcH: multiple ref to same data -- I see allowing that as the an optimizing
  rather than ser. the same date twice. It is additional optimization. I talked
  with MarkN, we have a scheme which we think can work. We will talk to
  gudge about this and come to some resolution. On the other issue, we don't 
  need to say anything about it, but we should not prevent it. For example, 
  we don't prevent additional HTTP header, it has nothing to do with SOAP 
MarkN: can we say attachments that are not referenced don't have anything to do
  with SOAP.
Anish: would this attachment be described in WSDL?
Mark: no
MarcH: don't know
Noah: I am in the 1-1 mapping camp. I would not have objection in the core ser.
  to say that for the purposes of SOAP there is 1-1, but the ser. allows
  additional things, but the use is discouraged. Question for gudge - we do 
  allow inter. to manipulate a message, for example to do encryption. How rigid 
  do we want to be on the 1-1 mapping issue.
Gudge: the encryption case -- the rules apply after the decryption takes place.

<more discussion on the encryption case -- minutia not captured in the minutes>

MarcH: We are considering some kind of id for the binary data which can then be
  referenced from other places.
Noah: I think it is important to put in the reverse way.

<more discussion on Marc's proposal -- minutia not captured in the minutes>

Noah: what if two elements have the same id but different content (erroneously)
then it would violate the SOAP model.

-- WG comments on initial drafts of a split MTOM document that provide for
a "Generic MTOM" (
Draft not yet available.

-- Representation header (e.g.
whether/how to incorporate into MTOM spec. See proposal at

-- Providing media-type information for binary data (e.g.
whether/how to incorporate into MTOM spec. See email discussion starting at

7. SOAP 1.2 Recommendation (postpone)
-- Obtain proposals to resolve issues against Recommendation specs.