Minutes of XML Protocol f2f meeting held 29 October 2002 in at Sonic Software, Bedford, Mass. USA.
See also the IRC log at http://www.w3.org/2002/10/29-xmlprotocol-irc.html
Henrik: why don't we do spec issues before AF issues? Noah: agreed - if we get in time trouble, the spec is higher priority. DavidF: OK, main spec LC issues will be covered before AF issues. ===========================================
Marc has shown the text of his proposal for issue 294 [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0155.html] Jacek: has the HTTP method mapping to SOAP MEPs been agreed on by the group? Jacek: does the spec indeed fully tie HTTP GET with SOAP Response MEP and HTTP POST with SOAP Request/Response MEP? Gudge thinks this might be related to identifying the HTTP binding in use on the wire Issue adjourned, to be continued on Wednesday with Jacek's additional proposal ===========================================
Spec: the current snapshot is up-to-date with respect to all issues closed by the last telcon Test collection: up-to-date, xmlp-comments messages on issues 235 and 237 are still pending Implementation summary list: updated with one new implementation, still some features that are not implemented by at least two implementations Henrik noted that the basis for our "Appendix B: Mapping Application Defined Names to XML Names" has changed in one detail, he will investigate the impact on our spec and propose how this should be handled Anish asked about doing minor editorial changes to the Test Collection, he was directed to do all such changes, but a) they must be documented and b) the f2f snapshot version of the document must not change. ===========================================
Jean-Jacques took us through his new proposal [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0144.html] Noah explained his proposed changes [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/att-0160/01-xml-dist-app_w3_org_from_October_2002_Proposal_for_issue_394.htm], everybody agreed on the changes Some discussion about the difference in reinserting vs. relaying headers Some discussion about the semantics of "understanding" and the name of the mustUnderstand attribute. Jean-Jacques also proposed a table showing the behavior of a node with different attribute values combinations. It was discussed that the table could be added instead of some current normative text because it is more brief. Proposal by David: close 394 by incorporating the text as modified by Noah and adding the table, both being normative. No objections expressed. The issue is closed with the proposal. =========================================== [15 min break at 10:30] [10:52 we're back]
Henrik explained his proposal [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0152.html] There was discussion of the interaction of SOAP 1.2 HTTP Binding and other media types than application/soap+xml, it was found to be a non-problem. DavidF: proposal to close the issue with Henrik's proposal. No objections. Issue closed with the proposed text. ===========================================
The direction is to make the appendix normative and optional: "If one is going to do this, one MUST follow the stated rules". JohnI took an action to write text. ===========================================
Herve: issue 277 has two parts: 1) in many places we use QNames where we could use URIs 2) we define too many XML namespaces in the spec If we change the QNames into URIs we can remove a number of namespaces. Proposal for 1) at http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0035.html Discussion on the cons and pros of using URIs or QNames. The discussion then moved to the definition of versions (because of identifying a version in VersionMismatch faults). Cases 3 to 6 in the proposal are accepted as proposed. The chair assesses that making 1 through 6 QNames and 7 URIs is the least-impact option. Straw-poll results: 2 people in favor of making 1 and 7 URIs, rest QNames 6 people in favor of making 1 through 6 QNames, 7 URIs 2 people in favor of making 2 and 7 URIs, 1 and 3-6 QNames 1 person in favor of making 1 through 6 QNames, 7 URIs, renaming some VersionMismatch stuff Nobody opposes the second option (the popular one). David: The first part of 277 is closed with the second option. Proposal for 2): http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0035.html 6 people in favor of merging faults namespaces (soap-upgrade, soap-faults) into envelope namespace (and renaming soapupg:Envelope to soapupg:SupportedEnvelope). 3 people in favor of keeping them separate other points of the proposal are agreed on No objections expressed to accepting the proposal as written, plus the rename above. David: The second part of 277 is so closed. =========================================== Issues 367, 368, 369 Conformance discussion: what is conformance and what can things conform to? Noah: there are many levels of conformance - test collection, binding framework, the rest of the spec. Also it may be an imploementation that conforms, a message or a binding spec, for example. Specifying all this would be useful but could take a lot of resources. The QA activity is suggesting a conformance section in the spec. We need to better understand what the QA activity really in mind. David will contact the QA people. =========================================== Lunch break =========================================== Issue 371 Henrik explained the issue and the proposal [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0136.html]. The proposal details aspects of understanding and processing headers, but Gudge expresses concern whether introducing this does not add confusion. Updated proposal: update section 2.6 to make it clear that successful processing of one header doesn't preclude faulting on further similar header. The WG agrees - without objection - to close issue 371 by adopting the change to section 2.6 proposed in the referenced message (replacing the original sentence starting "In all cases where a SOAP header block ...") =========================================== Issues 355 and 262 Proposal by Gudge: http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0168.html Discussion about digital signatures and breakages thereof related to, or caused by, intermediaries changing the literal representation. Noah argues that XML DigSig is an important thing and that SOAP should make the default that DigSig works, at least on the individual header block level. Gudge argues that a health warning about how one can get into problems when changing lexical form is sufficient for us to be able to say that we support the broken DigSig. Mark Jones compared the issue of rewriting boolean values with the possible issues with reserializing SOAP Encoding data. Crux of the issue: how strongly do we want to concern ourselves with the lexical form? Marc and Jacek support Gudge's point of view. Mark supports Noah's view. Henrik acknowledges that we're facing a major choice here. The WG agrees - without objection - to add the health warning (to be provided by Gudge) and thus resolve issues 355 and 262. =========================================== Issue 385 Camilo: this is a request from QA for a conformance clause on the Attachment Feature. The WG was contemplating a meeting with the QA folks, maybe tomorrow over the phone. David and Camilo will synchronize this issue with the spec QA/conformance issues. =========================================== Issue 388 Marc presented his proposal [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0157.html] and the WG agrees - without objection - to close issue 388 with this proposal. =========================================== Issue 390 Carine presented her proposal [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0149.html] and the email discussion on the proposal. Noah: attachment feature is primarily aimed at adding data that lives with the envelope. Noah, Henrik and Colleen discussed whether attachments are representations of external resources or parts of the message. David: are we discussing whether references to attachments are part of some global scheme (like the Web/URI)? Noah: there's no discussion about that. The problem is that an attachment dereferencing is done in the binding. Noah: attachments are those things which are resolved by the binding. There can be other references to the "usual" resources, not carried in attachments. David: this discussion is growing in scope; maybe creating usage scenarios for the AF is more appropriate in the context of a concrete attachment specification. David: we may push back on this issue, we think the AF spec is scoped well enough as it is. David: to move this forward, we need to see a proposal, probably a rework of Carine's proposal, Carine will write it. =========================================== Issue 386 Herve presented the issue and his proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0095.html Because properties are not QNames any more, this issue goes away. The WG agrees - without objection - to close the issue with this proposal. =========================================== Issue 387 Herve presented the issue and his two proposals. [http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0097.html] Discussion on can, MAY, SHOULD and where these should be or should not be used. Henrik's proposal: let's just remove the offending sentence, maybe replacing it with some words to the effect that this is a feature name, and referencing the feature framework. Issue closed - without objection - with the following proposal: the sentence is replaced by the text saying that the URI is the name of this feature; a reference to the feature framework is added - the framework explains what a feature name is used for. Meeting adjourned.