W3C XML Protocol Working Group teleconference minutes: 4 February 2004

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) >
Present 14/11
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

Excused
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

Regrets
BEA Systems, Mark Nottingham
BEA Systems, David Orchard
Oracle, Anish Karmarkar

Absent
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, seehttp://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 > PENDING > > 2004/01/28: Yves > Change teleconference time (30mn earlier) > DONE > > 2004/01/28: Yves > Send email ot xmlp-comments to open an issue about extension definition for > HTTP for the representation header > PENDING Done. > 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 > DONE > > 2004/01/28: Noah > Send email to open issue on SOAP processing model and and representation > headers > 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 >
No reports.

> > > 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 > 2004, >http://www.w3.org/2000/xp/Group/3/06/Attachments/OptimizationMechanism.html> . 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: > See >http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Jan/0054.html> 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 >http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2004Feb/0000.html. > We will go through this report in the same manner as for the requirements. Use Cases by MichaelM: UC2: Met. No comments. UC6: Not met. MTOM 4.3.11 conflicts. Jacek: Met by XOP. In scope for XOP, out of scope for MTOM http binding. 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 cases. UC9: Met. No comments. UC10: Met. No comments. UC11: Met. No comments. Requirements: 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 explicit. MichaelM: Is R9 met or unmet? Silence. DavidF: We'll leave this open and come back to it. R9 question to be added to issues list. R15: Met. No comments. R32: Met. No comments. R18: Met. 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. R29: Met. Agreement. R33: Met. 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 could optimize. Gudge: Can also encrypt data which contains one or more xbinc:Include elements. DavidF: Will leave open pending 'security' section. R37: Gudge: Can do that. Will be covered by security section. Gudge to write 'Security' section by 9th February. R1: Met. No comments. 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 fragments natively. MichaelM to change to 'met'. R3: Met. No comments. R4: Met. DavidF: The binary form is space-efficient representation? Saying preserves Base64-binary is not space-efficient. Rationale will change. Requirement is still met. R35: Met. No comment. R5: Met. No comment. R13: Met. No comments. 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 include elememnts. 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. No comments. R30: Met by MIME headers. No comments. R6: Met. No comments. 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 remove attachment. 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 same name. 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. R12: Met. No comments. R34: Met. No comments. R17: Met. No comments. DavidF: Been through our evaluation of requirements and use case. Any problem with any of the met? No comments. 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 Call. 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 header description? 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 443. > 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 media type? 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 >http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0041.htmlGudge: 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 issue 450. > 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 >http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0008.htmlGudge: 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 unanswered. 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 >http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0009.htmlMultipart/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.8090300@oracle.com (Anish) > > o Issue 9,http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x9, > proposalhttp://www.w3.org/mid/0523517A-30A9-11D8-B447-0003937568DC@sun.com> (MarcH) > > o Comments on proposed resolutions to issues 10 and 11, see >http://www.w3.org/mid/3FDEFFCF.9010109@crf.canon.fr> > - Issue 10,http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x10, > proposalhttp://www.w3.org/mid/3FC35703.3040000@crf.canon.fr (Herve) > > - Issue 11,http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x11, > proposalhttp://www.w3.org/mid/CB77CE50-2208-11D8-836E-00039396E15A@bea.com> (MarkN) > > o Issue 18,http://www.w3.org/2000/xp/Group/xmlp-rec-issues.html#x18, > proposal > > > Meeting concluded at 6:14 PM. BST