i W3C XML Protocol Working Group f2f minutes

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

1. Roll Call

Present Excused Regrets Absent

2. Agenda review

 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.

3. Action items

 Marc has shown the text of his proposal for issue 294 
 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 

4. Status reports

 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.

5. Issue 394

 Jean-Jacques took us through his new proposal
 Noah explained his proposed changes
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]

6. Issue 300

 Henrik explained his proposal
 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.

7. Issue 359

 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.

8. Issue 277

 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
 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):
 6 people in favor of merging faults namespaces (soap-upgrade, soap-faults)
into envelope namespace (and renaming soapupg:Envelope to
 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
 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:
 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
 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:
 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.
 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.