XMLP WG Telcon Minutes, 12 Nov 2003

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

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

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

Absent
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,
http://www.w3.org/2000/xp/Group/3/11/05-minutes.html
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",
http://www.w3.org/2002/06/registering-mediatype.html.
Covered above.

-- Update on XMLP/SVG WGs' collaboration on a "Generic MTOM" spec, DavidF
to report. (Proposal at
http://www.w3.org/mid/66558096-0101-11D8-9934-00039396E15A@bea.com)
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
Note.
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,
http://www.w3.org/TR/2002/WD-soap12-af-20020924/
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
pending.
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
http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html

-- 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
modifications).

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.

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

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
this.
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
at
http://www.w3.org/mid/DD35CC66F54D8248B6E04232892B63384A266F@RED-MSG-43.redmond.corp.microsoft.com

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

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.

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" (
http://www.w3.org/mid/66558096-0101-11D8-9934-00039396E15A@bea.com).
Draft not yet available.

-- Representation header (e.g.
http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html#_Toc36994434),
whether/how to incorporate into MTOM spec. See proposal at
http://www.w3.org/mid/DD35CC66F54D8248B6E04232892B633853C81B@RED-MSG-43.redmond.corp.microsoft.com

-- Providing media-type information for binary data (e.g.
http://www.gotdotnet.com/team/jeffsch/paswa/paswa61.html#_Toc36994425),
whether/how to incorporate into MTOM spec. See email discussion starting at
http://www.w3.org/mid/1067518991.1965.66.camel@localhost.

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