Based on IRC log at http://www.w3.org/2003/05/28-xmlprotocol-irc.html
have a couple of corrections: Herve's name and "has NO objections"
no other corrections
no objections, minutes approved as modified
Planning next f2f meeting
DF: we will first start putting together a page about the f2f (with hotels etc.)
Creation of Q&A on SOAP 1.2 in WSDL 1.1
DF: Glen thought the WSD WG should look at the SOAPBuilders' binding
DF: Jonathan Marsh sees WSD WG as resource constrained already but will bring this up
DF: we already have one volunteer, Anish
anish: yes, I'm still willing to do this
Tony Graham volunteers as well
Registration of the media type
MarkN: no progress yet
428: Content-free header?
DF: we have a new piece of text to be added
DF: W3C staff advised that if no implementation has to be changed, we can safely add this text
DF: so we polled the implementors
DF: we heard back from 5 implementors, no changes to implementations necessary
Gudge: Glen (apache) also replied saying no changes necessary
[jeffsch] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003May/0082.html
DF: so only one implementor hasn't replied and we didn't expect him to reply anyway
DF: I recommend we accept the added text as resolution to 428
no objections to thus resolving issue 428
430: minor editorial - disagreement between examples and text
no objection to handling this issue through email
Nilo will propose text, a day or two later (if no objections) we'll proceed to fix it and close
issue
DF: IPR all co-authors responded, Canon statement evaluation pending DF: IBM, Microsoft responded OK, waiting for AT&T, SAP and TIBCO MarkJ: we're OK, will solve with DF in email DF: TIBCO hasn't participated, will probably soon leave the group JeffS volunteers to "poke them" DF: I will rather handle it myself Attachment requirements DF: we handled this in the document that's about to be posted DF: we still have requirements we haven't decided on DF: these are "larger issues" DF: we'll now talk about binding-mechanism and above-binding mechanism, then we'll come back to the requirements no objections to this course DF: last week we started talking about PASWA as a binding mechanism and what it means DF: we have two descriptions now, let the authors speak about it a bit DF: we couldn't decide last week which direction we should take Herve (on binding mechanism): attachments are added in the message as base64 data [davidF] (URL for description http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0145.html) Herve: when asked to transmit the message, the binding will decode the base64 data and put it into attachments, adding xbinc:Include elements and the DoInclude header Herve: on receiving side the process is reversed, the binding resolves the attachments making them base64 data and removes the DoInclude header Herve: the implementations can actually skip the encoding/decoding steps, but in abstract it is necessary that the steps are in the description MarkN: is this a binding or is this a binding feature? [davidF] (URL for "above-binding" description http://lists.w3.org/Archives/Public/xml-dist-app/2003May/0146.html that markN will present shortly) MarkN: if it is a binding, it's not too composable, a feature would be fine Noah: I don't think this is intended to be a binding Noah: this is only barely a binding feature, it's more like a "technique a binding may use", it is not visible from the outside Noah: it should be clarified that in practice in implementations there could be some hints on what might be attachmentized Noah: it actually doesn't matter if different bindings use different techniques Herve: the implementation can provide ways for applications to prevent the encoding/decoding step MarkN: one could easily see this done as HTTP content-encoding MarkN: I would be concerned if we created a new binding that doesn't supercede the current HTTP binding MarkN (on PASWA as a module): MarkN: we have to handle problems like order of processing MarkN: the processing of DoInclude must behave as though xbinc:Include elements were replaced with the data MarkJ: it looks like this approach is more independent, it doesn't conflate bindings, they don't have to be include-aware MarkN: for a general way, it's more appropriate to specify it as a module, yes MarkJ: there are still optimizations to be done in implementations MarkN: the approach as a module would still require some accomodation in the binding implementations Noah: the bindings must be modified in any case Noah: the first proposal from Herve has the characteristic that the sender and receiver both agree on the form of the message Noah: with the module approach, the situation is a bit more subtle Noah: we have to be careful about things like digsig and the relay rules Noah: so in multi-hop situation the relaying node would have to agree on the attachmentization (scribe's words, Noah's spirit hopefully) Jacek: yes it is more subtle but I don't see a problem in this (all the nodes must understand PASWA) DF: the binding approach seems to have more favour Jacek: I think both approaches can be taken, we don't have to decide between the two paths MarkN: I support going down the binding path but we can do it properly both ways Noah: I think I've heard two flavors of the binding proposal Noah: to summarize: Herve's approach is "something the binding can use" Noah: we actually have to say very little normatively, the bindings have the opportunity to optimize binary data and we invite bindings to do so Noah: we would present one technique available for this Jacek: would we specify the HTTP binding with this optimization? Jacek: do we still need the DoInclude header? Noah: the second thing I think is in discretion of the particular binding Noah: should we enhance the current binding or should we publish a competitor to it? MarkN: DoInclude is there as a flag to make the message self-describing MarkN: I would hope we don't have multiple bindings out there MarkN: I wonder if the current HTTP binding can expand in the future (like PASWA, SSL) MarkJ: I support extensible bindings, we don't want a new binding for any new combination of features Noah: we could not only upgrade the binding, we could indicate more generally (hopefully not too complex) how a binding could be extended [Yves] with Accept-Encoding: and Content-Encoding in HTTP, we don't need to change the binding, it is an agreement between sender and recipient Gudge: I don't want us to redefine how attachments work for every other extension of the HTTP binding DaveO: this is somewhat related to the WSD WG's work on properties and features DaveO: WSD wants to describe features independently of their actual implementations JacekK: WSD's properties and features are related to SOAP Features, so we might need to make PASWA into a Feature, therefore a Module, too Noah: once we figure out how to evolve the HTTP binding, we could say that the HTTP binding 2.0 supports these and these features, too Noah: if a feature can only represent a possible optimization, then PASWA can be a feature but it still needn't be a module JacekK: agrees, so a feature doesn't need a module and then PASWA can be a feature and WSD's P&F come into play nicely DF: one should be able to identify which mechanism is used (for interop and WSDL) DF: suggest we agree that we're taking the binding approach, then we can continue in more detail MarkN: I think this generally captures the feeling of the group MarkN: but have we decided that it needs/deserves to be a feature? MarkN: I see it as a feature, expressed in a binding DF: so summary: this is a feature and we will express (implement) it in a binding no objections to going in this direction DF: what are the next steps? DF: we could task someone to recast PASWA as a feature (implemented in a binding) MarkN: there's no reason we should actually take the xbinc:Include (XMLish) approach in the binding jeffsch: the XML Include wonders if we are interested in using XInclude 1.1 Noah: I think Include is a fine technology, I don't think it should be necessary/requisite for implementing this feature Noah: any dependency to XInclude should go from one particular binding Noah: we should actually consider XInclude when we see what we need in the particular binding jeffsch: I don't disagree with the proposal to wait-and-see jeffsch: at the abstract level, one shouldn't say it needs XInclude jeffsch: the concrete level might require XInclude Noah: I'd like us to see the alternatives and then solve the problem we'll have DaveO: I think it likely that we'll have a relationship somewhere with XInclude DaveO: there might be timing conflicts davidF: let's ping them to see if there could be a timing problem DF: back to our next steps MarkN: 1) let's explore how this is incorporated in a binding, if it requires a new binding or extends the old one MarkN: 2) research what different mechanisms are available to implement the optimization Noah: we should specify how different bindings indicate this feature and we should specify our binding that does that Noah: also, where does the Representation element go? MarkN: good question MarkN: we should describe the feature and one implementation MarkN: so there is a packaging problem Noah: the Representation thing is actually a module, orthogonal to include Noah: we could do that in the same document, but different feature and module Noah: I suggest that we make a module (without a separate formal feature) for Representation Noah: steps: 1) abstract feature for inclusion, 2) concrete implementation, 3) representation module DF: so we have three chunks of text to do, 1 and 2 should be done in lock-step, the third is more independent no objections to going this way DF: volunteers? Noah: my time is limited this week, I'm willing to help MarkN: I can help on the first two chunks Herve: I'm willing to help, but no time this week Noah: first two pieces as well Herve: as well DF: we'll wait with the third Jacek: let's close issue 429 Noah: We should be looking at the XQuery data model meeting adjourned [RRSAgent] ACTION: W3C staff to post revised attachments requirements document [1] [RRSAgent] recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T18-15-52 [RRSAgent] ACTION: Gudge to send closing email to xmlp-comments and to the originator of issue 428 [2] [RRSAgent] recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T18-28-35 [RRSAgent] ACTION: DF to contact AT&T, SAP and TIBCO about their IPR statements (for next week) [3] [RRSAgent] recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T18-34-56 [RRSAgent] ACTION: chair to ping XML Core to determine their schedule for XINclude work [4] [RRSAgent] recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T19-23-06 [RRSAgent] ACTION: MarkN, Noah, Herve to start work on the abstract feature and conrete implementation descriptions (report next week) [5] [RRSAgent] recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T19-34-04 [RRSAgent] ACTION: JacekK to write an updated proposal for closing 429 [6] [RRSAgent] recorded in http://www.w3.org/2003/05/28-xmlprotocol-irc#T19-36-36