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.

Present 11/8
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

2003/07/02: MarkN
    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)

2003/10/08: WG
    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

2003/10/22: MarkN
    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.

2003/10/22: Marc
    Kick-off email discussion of issue 440

2003/10/29: JohnI
    Send "no comment" email to RDF WG re. their 2nd LC docs

2003/10/29: Jacek
    Send closing email to xmlp-comment and originator about issue 438

2003/10/29: Yves
    Send closing email to xmlp-comment and originator about issue 437
    (Jacek's proposal)

2003/10/29: Jacek
    Restart mime-typing of bin data discussion in email

2003/10/29: MarkN
    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.
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?

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.

6. Attachments
-- 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" (
http://www.w3.org/mid/66558096-0101-11D8-9934-00039396E15A@bea.com). (This
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: Yes.

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?

Gudge: Yes.

Noah: Signing it seems orthogonal to whether it's important.

Gudge: Agree.

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?

Yves: Yes.

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
MIME header?

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?

No response.

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.