Minutes of XML Protocol Working Group telcon, 4 February 2004.
> 1. Roll call. Scribe for minutes selected from attached list. Actions to be
> recorded on IRC. (8.30PT + 5)
Canon, Herve Ruellan
DaimlerChrysler R. & Tech, Mario Jeckle
IBM, David Fallside
IBM, John Ibbotson
IONA Technologies, Seumas Soltysik
Microsoft Corporation, Martin Gudgin
Nokia, Michael Mahan
SAP AG, Volker Wiechers
SeeBeyond, Pete Wenzel
Sun Microsystems, Marc Hadley
Sun Microsystems, Tony Graham (scribe)
Systinet, Jacek Kopecky
W3C, Yves Lafon
W3C, Carine Bournez
Canon, Jean-Jacques Moreau
DaimlerChrysler R. & Tech, Andreas Riegg
IBM, Noah Mendelsohn
IONA Technologies, Mike Greenberg
Microsoft Corporation, Jeff Schlimmer
SAP AG, Gerd Hoelzing
Systinet, Miroslav Simek
BEA Systems, Mark Nottingham
BEA Systems, David Orchard
Oracle, Anish Karmarkar
Oracle, Jeff Mischkinsky
> 2. Agenda review, and AOB (8.35 + 5)
> 3. Approval of January 28 telcon minutes,
> http://www.w3.org/2000/xp/Group/4/01/28-minutes.html (8.40 + 5)
Approved without objection.
> 4. Review action items, see http://www.w3.org/2000/xp/Group/Admin/#pending,
> the status of each action listed here taken as correct and will not be
> mentioned, unless any WG member has a question. These action items are
> taken from the XMLP member page. Some AIs may be discussed under other
> agenda items.
> 2004/01/21: Gudge&MarkN
> Find out what was agreed regarding allowable children of xop:include
> 2004/01/28: Yves
> Change teleconference time (30mn earlier)
> 2004/01/28: Yves
> Send email ot xmlp-comments to open an issue about extension definition for
> HTTP for the representation header
> 2004/01/28: Jacek
> Send closing email to xmlp-comments and originator to close issue 442
> noting we expect to handle extensions in separate issue and that media type
> is handled under issue 443
> 2004/01/28: Noah
> Send email to open issue on SOAP processing model and and representation
> DONE (http://www.w3.org/2000/xp/Group/xmlp-issues.html#x455)
> 5. Status reports and misc (8.45 + 10)
> -- Placeholder for pending items
> o March 2004, f2f planning (possible items include: co-ordination mtg w/
> WSD WG re. description of attachments)
> -- Update on XMLP collaboration with other WGs on MTOM/XOP
> 2004/01/28: DavidF
> Compile technical reasons not to use XInclude
> PENDING, have collected some material sent me after last week's call, still
> to track down more references
DavidF hopes to complete some time this week.
> -- Media types registrations ("application/soap+xml", etc)
> -- XMLP/WSD Task Force
> 6. Attachments (8.55 + 65)
> -- Placeholder for pending items
> o Update on Copyright and IP statements
> -- Document summary, 'stable'
> 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/. The WD decided at its
> December 2003 f2f to park this document (or the Ed Copy) when MTOM etc goes
> to Last Call.
> 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?] The WD decided at its December 2003 f2f to park
> this document (or the Ed Copy) when MTOM etc goes to Last Call.
> -- Document summary, 'active'
> o SOAP Optimized Serialization Use Cases and Requirements, WD, 12
> November 2003, http://www.w3.org/TR/soap12-os-ucr/
> o SOAP Message Transmission Optimization Mechanism, Ed Copy, 26 January
> . Awaiting publication of WD.
> o XML-binary Optimized Packaging, Ed Copy, 26 January 2004,
> http://www.w3.org/2000/xp/Group/3/06/Attachments/XOP.html. Awaiting
> publication of WD.
Yves: More approval is still required to be published. A few things to fix
before publishing. Hopes for reply with publication date this week.
> -- Meeting our requirements and use cases:
> with regard meeting requirements. We will go through this report to check
> "Met" entries and to resolve the "Unsure" entries.
> 2004/01/28: MichaelM
> Go through the UC and send a report by monday feb 1
> DONE, see
> We will go through this report in the same manner as for the requirements.
Use Cases by MichaelM:
UC6: Not met. MTOM 4.3.11 conflicts.
Jacek: Met by XOP. In scope for XOP, out of scope for MTOM http
MichaelM: Will look in XOP.
Agreed with objection that okay if handled by XOP but not by MTOM.
MichaelM to produce consolidated evaluation of requirements and use
R9: Met. Extensibility defined in a few places in MTOM.
DavidF: Not met.
MichealM: Issue 444 is extensibility point?
MichaelM: It's not explicit in spec, but requirements don't ask for
MichaelM: Is R9 met or unmet?
DavidF: We'll leave this open and come back to it.
R9 question to be added to issues list.
Comments in agreement.
R27: Unclear about "extent possible". Left as unsure.
DavidF: Fair, since security is TBD.
Gudge: We can secure optimized content using C14N, but would require
producing Base64 characters. Have left open option of creating
MTOM-aware C14N, but not planning on creating it.
DavidF: Will wait on met/unmet until security section is written.
Agreement without objection.
R22: Met in XOP.
Agreement without objection.
R36. Unsure about security section.
DavidF: Do we need anything written down about encryption?
Gudge: Relatively straightforward. Encrypted XML is Base64, which you
Gudge: Can also encrypt data which contains one or more xbinc:Include
DavidF: Will leave open pending 'security' section.
Gudge: Can do that.
Will be covered by security section.
Gudge to write 'Security' section by 9th February.
R2: Partially met. MTOM only does Base64.
Jacek: Since even XML fragments can be serialised as binary data, we
have met that. Requirement doesn't say we have to handle e.g. XML
MichaelM to change to 'met'.
DavidF: The binary form is space-efficient representation? Saying
preserves Base64-binary is not space-efficient.
Rationale will change. Requirement is still met.
R26: Not sure.
Jacek: Does MIME support chunked encoding?
MarcH: MIME/interleaved does.
Gudge: Could do with multiple xbinc:Include siblings. Would have to
be sure all except last were integral number of 24 bits so no
padding. No problem with canonical Base64 is no whitespace between
Gudge: There's no terminator for Base64, but get equals signs if not
integral number of 24 bits. Keeps decoding 24 bits at a time until
you hit an equals sign.
Jacek: Would have to specify xbinc:Include siblings trick in XOP.
DavidF: What were we thinking when we drafted this requirement?
MichaelM reads UC12.
DavidF: R26 is a hold-out from UC12, which is out of scope. Any
objections to removing R26?
Approved without objections.
R26 to be removed from editor's copy.
DavidF: Consolidated document about meeting requirements should
include rationales for met/unmet/unsure. Not necessary for ones
no-one asked for clarification.
R21: Met by MIME.
Gudge: And by the fact that we're using XML.
Jacek: Should also cover versions of MIME. Met because other versions
of MIME would be compatible or use a different MIME type.
R31: Met by MIME RFC 2045.
R30: Met by MIME headers.
R7: Met but need to verify.
MarcH: XOP allows multiple references to a single attachment. You can
have attachments that aren't referenced. In HTTP binding, can have
attachments without reference. If remove reference, effectively
Jacek: Requirement is more like shouldn't create URIs by counting
parts in the serialisation. By the way we create the identification
URIs, this requirement is met by the basic idea of the URI.
DavidF: How to create packaging section in XOP?
Jacek: Cid? If create URIs in own domain, no conflict, no necessity
to rename on addition or deletion.
MarcH: Can remove any given one without affecting the others.
DavidF: True as specified in HTTP binding.
Gudge: HTTP binding says must use CID?
DavidF: Don't know.
Jacek: Should think it's in XOP.
DavidF: Have we met this requirement?
Agreement without objection.
Jacek: When people are creating URIs, DNS handles conflicts. Since
CID URIs contain any other kind of URIs, would be stupid idea for an
implementor to always use one URI, e.g., if two parts are named the
DavidF: The process for creating a XOP package -- one part that has a
unique URI -- then we went to some trouble to avoid conflict.
MichaelM: XOP 4.21.
DavidF: Add issue on meeting R7.
DavidF: Been through our evaluation of requirements and use case. Any
problem with any of the met?
The working group believes that it has met the requirements as listed
by MichaelM except for the ones called out for further work.
> -- Moving forward with the Primer.
> See comments from Jacek,
> http://lists.w3.org/Archives/Public/xml-dist-app/2004Jan/0091.html. Are
> there other comments to make? Shall we tell Nilo to continue, do we need to
> make corrections, etc?
Jacek: The new parts mostly okay except for minor things. E.g. more
mentions of XOP and some editorial issues. Have not identified
anything substantial. Should ask Nilo to finish this with the current
status of MTOM and XOP. Probably needs another round before Last
MichaelM: Not as clear as it could be in some places. Will try to
raise comments on it.
DavidF: Looks like doing the right thing. Need to make sure everybody
reads it, probably before Last Call, and do review.
DavidF: Nilo left the group. His company is still W3C member. I
invited him "back" to work on the Primer. We decided to get Nilo to
continue as best way forward instead of new editor or new Attachment
primer. He will attend meetings if invited to discuss Primer.
> -- Issue discussion. We will initially make a a pass over this list to
> determine what needs to be done to resolve each issue.
> o 449, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x449, multiple
> representations of a single resource. Is this issue not now resolved?
MarcH: Not sure if resolved.
DavidF: More intended by this issue?
Jacek: Decided to include some text about the representation header
being used multiple times in SOAP message. Until have that text, not
sure covered. Keep issue until have text.
DavidF: Should be easily resolvable after finished representation
Agreement without objection.
> o 454, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x454, variability
> of encoding in Miffy
DavidF: Need more discussion?
DavidF: Still under discussion. Will mark as "further discussion".
> o 443, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x443, Media-type
> information for binary data
Gudge: Have attribute for doing that in XOP. Say should copy value
into MIME part.
Jacek: Subject of joint task force with WSD WG?
DavidF: Weren't they defining the representation of the typing names?
Jacek: Don't know.
No-one from that group on the call.
Gudge: Text under issue says Jacek copied stuff out of PASWA as
approach to fixing this. Defining do media type in XOP, can describe
in schema. What else?
Jacek: Restrict to GIF, JPEG, and PNG?
Gudge: Use a pattern.
Jacek to contact Anish to see what WSD WG will provide w.r.t. issue
> o 447, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x447, recognizing
> and processing MTOM/Miffy in the HTTP Binding
Gudge: Still TBD.
DavidF: When have media type, will have answer? Actually have to have
Gudge: Asked IETF if can use media type for transform of media type.
Waiting for them to give feedback. Shouldn't wait much longer.
DavidF: Ask MarkN to give read on likely outcome of issue 447.
Action to Yves.
> o 448, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x448,
> extensibility/versioning in mtom elements
Gudge: We have a very restricted usage and defining stuff in
completely new namespace for new stuff is reasonable approach.
MarcH: Is versioning and extensibility. Do we allow extensibility of
stuff we're creating? Do we allow attribute extensibility?
Gudge: Don't allow any extensibility in schema. Don't think yet what
to do about children of xbinc:Include.
MarcH: This issue is placeholder for that question.
Gudge: For WD, decided xbinc:Include doesn't have any children.
MarcH: For versioning, reinvent it. Extensibility unresolved.
DavidF: We need to do some work on this.
> o 450, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x450, Referenced
> parts MUST include the 'Content-Transfer-Encoding' field and should include
> the 'Content-Length' field. Discussion started at
Gudge: Decided in BEA F2F.
DavidF: So a solution/response should exist for that.
Action to Gudge to look through F2F minutes and WD text for answer to
> o 451, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x451, referencing
> mechanism via 'Content-Type' and 'http' URI
Gudge: Must use CID.
Action to Gudge to follow up on this.
> o 452, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x452, Addressing
> the 'data:' URI directly in the MIFFY specification. Discussion started at
Gudge: Pretty sure decided 'no'.
MarcH: Sent something to SVG group about this? Sent question about
them planning on moving away from this approach?
DavidF: Need to send them an email about closing issue since email
Action to DavidF.
> o 453, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x453, Packaging
> multipart payloads via use of the 'multipart/multiplexed' mechanism in RFC
> 3391 should be considered as valid MIFFY encoding mechanism. Discussion
> started at
Multipart/Interleaved Internet Draft has been deleted.
Action to MarcH to research issue 453.
> o 455, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x455. SOAP
> Processing model and representation header.
Jacek: Arising from discussion a few weeks ago. Representation header
and MAY/SHOULD/MUST do or not do?
DavidF: Needs more discussion.
> o 456, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x456. Constraints
> on node types.
Gudge: Agree with Herve's proposal. Just talk about type property of
ones we will optimise.
DavidF: Proposal to drop two sentences. On next week's agenda.
> o 444, http://www.w3.org/2000/xp/Group/xmlp-issues.html#x444, MTOM and
> Data Model Details.
DavidF: Sounds like action to give to Noah, but he's not here.
> 8. SOAP 1.2 Recommendation (postponed)
> -- Issues and proposed resolutions.
> o Issue 8, http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x8,
> proposal (http://www.w3.org/mid/40023B56.firstname.lastname@example.org (Anish)
> o Issue 9, http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x9,
> proposal http://www.w3.org/mid/0523517A-30A9-11D8-B447-0003937568DC@sun.com
> o Comments on proposed resolutions to issues 10 and 11, see
> - Issue 10, http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x10,
> proposal http://www.w3.org/mid/3FC35703.email@example.com (Herve)
> - Issue 11, http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x11,
> proposal http://www.w3.org/mid/CB77CE50-2208-11D8-836E-00039396E15A@bea.com
> o Issue 18, http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x18,
Meeting concluded at 6:14 PM. BST