Based on IRC log
1. Roll Present 14/10 BEA Systems Mark Nottingham BEA Systems David Orchard Canon Herve Ruellan IBM John Ibbotson IBM Noah Mendelsohn IBM David Fallside IONA Technologies Seumas Soltysik Microsoft Corporation Martin Gudgin Nokia Michael Mahan SAP AG Volker Wiechers Sun Microsystems Marc Hadley Systinet (IDOOX) Jacek Kopecky (scribe) W3C Yves Lafon W3C Carine Bournez Canon Jean-Jacques Moreau IONA Technologies Mike Greenberg Microsoft Corporation Jeff Schlimmer SAP AG Gerd Hoelzing Sun Microsystems Tony Graham Systinet (IDOOX) Miroslav Simek Regrets Oracle Anish Karmarkar Absent DaimlerChrysler R. & Tech Mario Jeckle DaimlerChrysler R. & Tech Andreas Riegg Oracle Jeff Mischkinsky SeeBeyond Pete Wenzel 2. Agenda Review 3. Approval of December f2f minutes -- skipped 4. Action items Re. collaboration with other WGs on a generic MTOM: [scribe] DF: if no comments come, we'll proceed by setting up a TF for January 5. Status reports [scribe] media type registration [scribe] mnot: I have regenerated the Internet Draft for the application/soap+xml registration from scratch, I hope for some reviews [scribe] mnot: I've incorporated all of the media type appendix, no external references [scribe] df: we'll expect comments by sunday, the application will be sent on monday [scribe] mnot: I may not be able to send a note to ietf-types on Tuesday, I'll be travelling 6. Attachments [scribe] action items review [scribe] mnot: content-length does not work in MIME [scribe] mnot: I can't see ways for us to constrain how to use MIME [scribe] mnot: summary - no change required [scribe] Gudge: does anything stop us from putting content-length in as a hint? [scribe] mnot: no [scribe] Gudge: we could add some text about that [scribe] mnot: yes, we could add such a thing, it could make things easier for some people [scribe] mnot: we could have discussion about other hints [scribe] mnot: we can't reinvent the rules, but we can augment them by hints [scribe] mnot: the spec allows any MIME header, it doesn't say anything about content length [scribe] Noah: I'm torn about this, it's a point of variation, may be a problem for interop [scribe] Noah: people can start requiring the "hint" [scribe] Noah: maybe we need a note about the extensibility of MIME and that we require implementations to be successful with no extension information [scribe] mnot: we may be allowing other packaging mechanisms... [scribe] Noah: have we made a decision on this yet? [scribe] DF: noah, you started formulating some language...? [scribe] Noah: maybe we should first say something about the extensibility of MIME [scribe] Jacek: maybe we should just drop all this text [scribe] Jacek: so we wouldn't change the text we have now [scribe] Noah: what if somebody then uses the extensibility [scribe] MarcH: we could want to specify the minimum requirements [scribe] Noah: I should be obligated to be able to read a package with/without a content-length [scribe] Jacek: if we don't talk about some other headers, I think implementations should be prepared not to receive them [scribe] marc: yes, maybe we do need some text to actually say so [scribe] Noah: with more people than me suggesting that, I think we should add the text [scribe] DF: we need a volunteer to draft it [scribe] topic: discussion about http://www.w3.org/mid/FF356F9D-25B9-11D8-9408-00039396E15A@bea.com (point 3) [Yves] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0008.html [scribe] mnot: point 3 is about data: URIs in attribute values [scribe] mnot: in the following thread, Chris Lilly had a good approach to solving this [scribe] DF: discussion about allowing/disallowing multiple encodings? [scribe] marc: if MIFFY is going to be general-purpose, we should allow it [scribe] DF: there is always a tradeoff [scribe] Jacek: what does "multiple encodings mean"? [scribe] mnot: different encodings of the binary data in the XMLllllllll [scribe] Noah: they not only want base64 data, but also anyURI data [scribe] Noah: basically, optimizing different data types [scribe] mnot: SVG does that a lot, it's a big usecase for them [scribe] DF: it's becoming more generic, it's not clear if this is a common usecase [scribe] mnot: data: URIs aren't widely deployed beyond SVG, we might tell them to express the data otherwise than using a data: URIs [scribe] mnot: optimizing attributes could be more interesting [scribe] Noah: maybe this is too complex for the value-add [scribe] mnot: data: URIs are a bit of a hack and they know it [scribe] mnot: we might ask them to do it right [scribe] Gudge: any solution for attributes would probably require look-ahead, making impl complicating [scribe] mnot: did you see Chris's proposal? [scribe] Gudge: I might have missed that [scribe] mnot: it used another attribute [scribe] Noah: we might want to do some design, evaluating alternatives [Gudge] +1 to just optimizing element content [scribe] jacek: I don't think we need an indication of the optimization in attributes (in my proposed approach) [scribe] jacek: but I think we don't actually really need it all, just stick to element content [scribe] Noah: we could invent miffy: URIs and that could be the indication [scribe] Noah: I don't think we should allow malicious users to invent the CID values [scribe] mnot: I agree that architecturally putting in the CID URIs is not robust; the miffy: URIs could be a good idea, but probably not passable [scribe] mnot: so I propose we say we wouldn't do this [scribe] marc: we wanted MIFFY to be general-purpose and we seem to be throwing out the first requirement the public gave us [scribe] mnot: we need to accomodate their usecase, but it may be done by their redesign, not ours [scribe] mnot: so if we come up with element-content-only MIFFY, the next version of SVG could use that [scribe] mnot: we could ask the SVG group about this approach [scribe] Noah: we may not know where the end of the generalization of MIFFY is [scribe] Noah: we may be putting too much weight to the first public's requirement possibly changing MIFFY substantially [scribe] Noah: we should explore the public's requirements, but maybe we shouldn't try to do too much [scribe] Gudge: +1 [scribe] marc: we should at least listen to other people's requirements [scribe] mnot: we wanted to generalize whatever was easy enough, we shouldn't sacrifice our schedule to it [scribe] herve: we should try to do something to cope with data: URIs [scribe] DF: we seem to have three points of view: [scribe] DF: 1) let's just move on rapidly from this [scribe] DF: 2) ask SVG about this [scribe] DF: 3) let's do a design exercise [scribe] DF: in my experience the use of data: attributes has always been a source of debate in W3 community [scribe] DF: I'd be nervous about making it a design point for us [scribe] DF: we can do MIFFY/MTOM now, fairly rapidly (favoring points 1 or 2), and then MIFFY version 2 to handle some of this stuff later [scribe] DF: we don't have any strong agreement, I suggest we contact SVG first, need a volunteer [marc] indeed [scribe] DF: nobody seems to be volunteering, I suggest we just move on [scribe] jacek: I'll draft the letter to SVG on the private list (Yves takes over as scribe) [Yves] mnot: it's request to support different packaging mechanism [Yves] mnot: multipart/plutiplex is just one of them [Yves] david: what is our opinion of it? [Yves] mnot: it is a good thing [Yves] gudge: is that at the miffy level? do you want to have that at the MTOM level? [Yves] davidf: may be related to the topic of different constrains at miffy and mtom levels [Yves] Marc: are we drawing a distinction between mtom and a binding? [Yves] different binding might use different packaging [Yves] we can say http binding use only multipart/related [Yves] same issue for multiple references, we can have a limitation for the HTTP binding, but leave it open for other bindings [Yves] Noah: before miffy, it was independent of the serialization. [Yves] Noah: you feed the data and you have a multipart related package that might be useful [Yves] in mtom we added one output format [Yves] not sure about adding multiple ones for interoperability [Yves] noah: multipart related is not part of the feature [Yves] DavidF: mtom and miffy have no constraint in the feature, only the binding have the constraints [Yves] Gudge: if HTTP binding have the constraints, why having MTOM then and just take Miffy directly to the binding [Yves] ie: not have the abstract feature [Yves] Noah: what you say is "don't use a feature as you have another binding"? [Yves] Gudge: yes [Yves] Marc: sounds opposite of the way we decided to build that [Yves] Noah: an ordinary soap will give you only the infoset, in the mtom case is that the binding must implement a subset of b64 to be considered for optimization and then pass it to a suitable binding for transmission [Yves] DavidF: on the fundamental point, seems to be a consensus that the constraints may happen in the binding [Yves] davidF: we have a stack of proposed fixes for the errata, will send a ballot email tommorrow [Yves] please comment by EOW 9 open action items: ACTION: MarkN to send the email to ietf-types [1] ACTION: JohnI and the WG to provide comments on his XQuery draft (by sunday) and to be sent off on Monday [2] ACTION: DaveO to send mediatyping attribute query email to TAG [3] ACTION: MNot to take comments until Saturday and to send the I-D to IETF on Sunday (12/15) [4] ACTION: Noah to draft a text describing the responsibilities regarding MIME extensibility (due 12/16) [5] ACTION: JacekK to draft the email to SVG about point 3 to private list by COB (12/12) [6] ACTION: DavidF to send the email to SVG on monday [7] ACTION: Marc to send an email to dist-app about the proposal for binding/miffy constraints due dec 10 [8] ACTION: DavidF to send request for feedback for the spec errata proposals [9]