XMLP WG Telcon Minutes, 10 Dec 2003

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

Oracle  Anish   Karmarkar

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

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
[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
[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]