XML Protocol Working Group Telcon Minutes, 5 November 2003
1. Roll call. Scribe for minutes selected from attached list. Actions to be
recorded on IRC.
Canon Herve Ruellan
IBM David Fallside
IBM Noah Mendelsohn
Microsoft Corporation Martin Gudgin
Oracle Anish Karmarkar
SAP AG Gerd Hoelzing
SAP AG Volker Wiechers
SeeBeyond Pete Wenzel
Sun Microsystems Tony Graham (scribe)
W3C Yves Lafon
W3C Carine Bournez
Canon Jean-Jacques Moreau
IBM John Ibbotson
Microsoft Corporation Jeff Schlimmer
Oracle Jeff Mischkinsky
Sun Microsystems Marc Hadley
BEA Systems Mark Nottingham
BEA Systems David Orchard
DaimlerChrysler R. & Tech Mario Jeckle
Systinet (IDOOX) Jacek Kopecky
DaimlerChrysler R. & Tech Andreas Riegg
IONA Technologies Seumas Soltysik
IONA Technologies Mike Greenberg
Nokia Michael Mahan
Systinet (IDOOX) Miroslav Simek
2. Agenda review, and AOB
Chair: Meeting 26th November: No meeting. W3C staff to note on WG page.
3. Approval of October 29 telcon minutes,
Minutes approved with no objection.
4. Review action items, see http://www.w3.org/2000/xp/Group/Admin/#pending
Ask IETF to publish the SOAP Media-Type registration as a RFC (waiting for IETF confirmation)
2003/09/10: MarkN & DavidF
Confirm on the exact name of the content type (ietf vs vnd)
Monitor WSS Oasis TC response to our SOAP12-n11n comment. IF they
do add a reference, we may need to move the document along the rec
fork the MTOM spec per his Generic MTOM proposal by Nov 3
2003/10/22: UC req editors, W3C staff and DavidF
Submit the UC and Reqs doc for publication as a WD.
Kick-off email discussion of issue 440
Send "no comment" email to RDF WG re. their 2nd LC docs
Send closing email to xmlp-comment and originator about issue 438
Send closing email to xmlp-comment and originator about issue 437
Restart mime-typing of bin data discussion in email
Start representation hdr discussion in email
5. Status reports and misc
-- Placeholder for pending items
o December 2003, f2f planning (registration closes 21 November)
Chair: Submit registration whether or not attending.
o March 2004, f2f planning (possible items include: co-ordination mtg w/
WSD WG re. description of attachments)
-- Registration of "application/soap+xml",
-- Update on XMLP/SVG WGs' collaboration on a "Generic MTOM" spec, DavidF
to report. (Proposal at
Chair: Nothing further heard from SVG.
-- 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.
XMLP WG wish to work with WSD WG on one or both of these topics, and if so,
should we setup a TF?
Chair: How closely do we want to work with WSD on this?
Anish: WSD decided to ask for volunteers. Oracle rep volunteered.
Anish to also co-edit?
Chair: Anish could co-edit outside of a TF?
Anish: Could. JM/WSD thinking of WG Note. Anish could be made
invited expert to WSD group.
Noah: What is the joint document?
Chair: Table issue again next week or bring up in email.
-- Issue discussion
o 440, Sharing MTOM parts for identical leaf nodes,
http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440. This issue was sent
back for email discussion after last week's telcon
Noah: At least need MAY|MUST|SHOULD ruling on this. Brings up issues
about reference counting. Issue is there even in absence of sharing,
e.g., header with binary child goes through intermediary and header is
Gudge: PASWA states each MIME part must be referenced by exactly one
include. Would want to think hard about not doing it that way. Could
be for simplification of implementation, but could be infoset reasons.
Noah: Is there someone who want to include three copies of my smiling
Noah: If have subtree that is going to be encrypted, if use case of
someone didn't need to encrypt picture, just parent?
Noah: Everything we've discussed except the encryption sidetrack has
been discussed. We may have a rule and have a bit of an action to see
that WD is clear on this. May be an issue to think through encryption
Chair: When brought up 440, was much discussion about 1:1
Noah: No recall of discussion.
(Noah reviews his mail archive)
Noah: Note by Marc Hadley on 29th September. He links to other stuff.
Noah: Not much has been said lately.
Chair: Construct before next week a proposal for resolving issue 440.
E.g., wording "For every xbinc:include must be one body part".
Noah: Other way around. For every body part there must be one
xbinc:include. Friendly amendment: Intermediaries must preserve this
Gudge to write proposal.
-- WG comments on initial drafts of a split MTOM document that provide for
a "Generic MTOM" (
item depends on availability of drafts from MarkN).
No discussion since MarkN not on call.
-- Representation header (e.g.
whether/how to incorporate into MTOM spec. See email discussion (pending
discussion restart by MarkN).
Chair: Debate seems to be on whose responsibility to provide this
metadata (binding or ??). Where does discussion stand?
Noah: Problem was at what level should we encode that binary is
image/jpeg. I read Yves to say that's hop-by-hop in binding.
Not just doing optimisation in MTOM. Beleive decided to indicate MIME
type of represenations independently of whether MTOM used or MIME
used. If send through old SOAP 1.2 binding get same representation?
Use case is should carry information in infoset.
Forget about it? Leave in infoset? Duplicate information into places
in multipart/MIME? Be tricky and never send same information twice
(moral equivalent of xbinc:include in serialisation). Need attribute
that goes through SOAP processing model like any other attribute?
Yves: My mail was about concrete serialization. E.g., send to
sendmail. Has to be transient and not part of infoset.
Noah: Yves assuming serialisation not just in HTTP binding?
Yves: content-encoding, etc. might go to infoset, but serialisation
might have transient properties.
Gudge: Some things might be useful in infoset to be able to secure
them. E.g., this is a JPEG. If using XML DSIG, need info at infoset
level. May be other MIME Headers. May need some MIME information in
infoset for signing.
Noah: And for getting through intermediaries?
Noah: Signing it seems orthogonal to whether it's important.
Chair: Need more investigation on set of attributes for MIME headers
that might be hoisted to infoset.
Noah/Gudge: May be the other way around.
Chair: We do need a list of potential metadata items for
Noah: Question about charset in content-type header.
Noah: Need to make clear whether or not header parameters allowed.
Yves: Issue is quite complex. For XML and HTML, should put character
set in attribute if can.
Noah: When content is viewed as octet happens to be text/html with
charset, should encourage use of charset?
Noah: Is that an issue?
Gudge: Starting XML serialization of all MIME headers?
Noah: Some developers don't notice issue of charset parameters.
Noah: Need BNF, if only be referencing appropriate RFCs?
Chair: If to reflect content-type and parameter, need some mechanism
to reflect their definition in RFCs.
Gudge: Do MIME headers match productions for XML names?
Noah: 'soap+xml' has '+' sign.
Gudge: Can we state simple rule: namespace URI. For local name, use
Noah: Dug hole of structured attributes?
Gudge: Not ideal because would have to microparse value.
Noah: If child in infoset Base64Binary. If apply three headers, do
they become attributes of parent?
Gudge: They should be attributes.
Chair: Need investigation into nature of content-type, various
headers, and their parameters. Need more information to move ahead?
Chair: Anybody with any problem in going in this direction?
Gudge to make proposal and examples for the "attributes thing".
-- Providing media-type information for binary data (e.g.
whether/how to incorporate into MTOM spec. See email discussion starting at
Chair: Further discussion?
Gudge: Media typing comes in two places: want to media type base64
content of an element? Whether need to do same for representation
header. PASWA separated the content type out and made part of the
parent of the include and didn't say anything about it in
representation since parent of include. Still need specific way of
doing it for content not in represenation header.
Noah: Sort into two piles, one a superset of other? Here is a set
should be applicable to any Base64Binary stream? Possibly subset only
makes sense if warrent if a representation?
Gudge: For representation, should be open-ended for anything MIME
Noah: Decide by "would naturally apply to stream not originated on
Yves: Email MIME headers considered standard by IETF.
Gudge will attempt to dig into MIME specs as part of previous action
item and try to do two categories of headers: one for representation
and one for general parents of includes.
7. SOAP 1.2 Recommendation (postpone)
-- Obtain proposals to resolve issues against Recommendation specs.
Meeting adjourned 10:13 PM, PST.