W3C XML Protocol Working Group teleconference, 13 February 2002

Minutes of XML Protocol telcon, 13 February 2002.

1. Roll call, scribes for minutes/action items

Present 37/31 Excused Regrets Absent

2. Agenda review, and AOB

AOB
David F Status update on F2F - draft agenda linked from member page. No comments received.
 David to update soon. Suggestions to David.
 Registration closes at the end of this week.
 Remote access in Mass area. Send email with regrets and wish to attend remotely.
Glen Plan to start 6am and hookup with Cannes.
David F Will coordinate with Glen. Sync at lunchtime (Cannes time).

3. Approval of February 6 Feb telcon minutes

No additions/corrections noted
Minutes approved.

4. Review action items

 - Editors RDF/UML pending
 - Henrik/David links from external WGs. 
 RDF Pinged, no response.
 UML later in meeting - pending
 - Oisin review primer. Still to complete - by end of week .pending
 - David O and F
 Talk with W3C (Yves) team about handing some over to other groups.
 Issues raised may be dealt with by other groups.
 - David/Yves infoset encoding
 Keep the infoset descriptions considered editorial, don't have to be put into last call. 
 complete
 - Highland complete
 - Marc H etc rewrite section 2 - complete
 - Henrik - new issue - done (issue 183)
 - Henrik done.

5. Status reports

All doc owners need to report status with regard providing a stable copy by
15 February (end of week).
-- Primer
Nilo  Comments from Oisin, Chris F and JJ.
 Incorporated
 Clean version by end of Friday
 Empty section on other serialisation schemes
  Not able to do anything on this by Friday.
  Not followed up with XMI example
Oisin  Look for XMI examples

-- Spec
Marc Part 1 in good shape
 Rewrite of sec 2 
 TBTF issues - proposal to solve
 Part 2 needs further work
 Plan to cut on Friday and make available as snapshot.
David F Gudge's state of encoding infoset ?
Marc Not ready by Friday
 No infoset in encoding section
 Gudge took a copy
 Process - URLs for snapshot to member list

-- TBTF
David F Meeting this morning
 Discussion on features/bindings in context of end-to-end
 Good progress made
 Another meeting on Friday
 Expect text to be available then
 Suggests putting text in situ and flagging that it is still under discussion
 Security/ intermediary /feature binding
Henrik Editorially that would create a bottleneck
Marc Agreed
David F Editors don't seem to be in favour - withdraws the suggestion.

-- ETF
Marc Met yesterday
 Discussed all issues
 Handle on all issues
 Proposals to close all issues
David F How many ?
Marc 8
David F Will they be ready for consideration at F2F ?
Marc Yes
David F Were there any that you though should be handled by another TF?
Marc 1 was TBTF issue
David F Does the 8 include the 3 RPC ones ?
Marc Yes

-- Conformance work
Oisin Have all info needed for publication
 Not in doc form yet
 May have doc ready by Friday
David F Can Yves help ?
Yves Yes - formatting for Web site - on Monday
Paul C Prefer text for Friday
Oisin We can publish plain text on Friday
Paul C Are there any submissions of test material from outside WG ? i.e. in addition to Soapbuilders?
David F Not seen any
Yves No
David F Looks as though we didn't get anything
Anish Doc refers to tests created by Soapbuilders for SOAP 1.1 not 1.2
David F We are doing a conformance doc for SOAP 1.2 not SOAP 1.1
Oisin Text will be added to refer to 1.1 tests
David F Your words suggest we are writing code; We are not writing code
Oisin Anish and Jeff are not writing code. Just a list of assertions from the document.
David F Looking for list of assertions from 1.2 doc and descriptions of test derived from assertions.
Oisin That's what we expected to do but not code.
John I Soapbuilders is a resource to use
Oisin Soapbuilders is a starting point.
Paul C I suggest a F2F agenda item to discuss creating a real test suite.

-- Usage Scenarios
John I Nothing to report

-- XMI/UML (MarioJ) and RDF (DavidF) serialisations
Mario XMI/UML serialisation
 Take rest of week to complete item - discussions with UML reps on serialisation
David F So long as we know there will be a resolution for F2F
Mario   Yes

6. Editorial guidance sought.

-- Is there any reason to not remove the usage scenarios from the requirement document and instead refer to the scenarios WD?
David F We should keep usage scenario requirements separate.
 The scenarios doc represents solution to those requirements
John I Agree
Henrik OK with that - not change anything
Stuart  Agree
DavidF  We will maintin the separation

-- Is there any reason to not remove the terminology section from the
requirement document and instead refer to the AM and the SOAP 1.2 spec? (We
will need to check with the AM to avoid losing any information.)
David F Comments ?
Stuart AM relies on terminology section being present
 Some point we need to to return to AM doc and decide whether we need to bring it up to date
 Dependency between the two
David F No strong expression - recommend leave as is
WG Agree, no objections

7. Issue 102, clarify rules for delivering fault messages

The TBTF recommends the WG adopts the resolution to this issue described in
[5]. Does the WG have any objections to accepting this recommendation for
closing issue 102?
David F This represents a small addition to 5.3 part 1
 Any discussion?
Stuart Number of +1s
 No trimming but minor change
David F No objections heard, we will close 102 with TBTF proposal.
 Stuart to send to XMLP Comment

8. Issue 55, Examples needed for encoding/encapsulation

ETF proposal [10] that with Part 2, the Primer and the Usage Scenarios, we
have indeed provided a broader view beyond the statement that SOAP 1.1
".... provides one mechanism for encapsulation and encoding of data with
limited examples of extensibility. The XP specification must broaden these
mechanisms via use cases."
Henrik Drafted proposal
 Requirement 506 - show multiple ways of encoding data
 Fulfil requirement through documents
John I Originator happy
David F No objections heard from the WG so the issue is closed with the ETF proposal.
        Henrik send close note.

9.During last week's telcon discussion of agenda item #6, we discussed the
editors' proposed rewrite of Section 2 [3]. That discussion favoured the
option (ii) that was mentioned in the agenda item, and there is now new
text [9] based on our discussion of that option. Do we accept this new
text?
Marc New role attribute value - ult recipient
 Omitting attr is same as with ult recipient added
David F Any objection to accepting revised text ?
 None heard - we accept the new text
 Editors add it to doc
Paul D Should we use camel case for ult recipient attribute?
David F Yes, because we want consistency in our spec

10. Issue 176, canonicalization/rewrite of headers [11]

Henrik has proposed to resolve this issue by disallowing any child
information items other than those that are explicitly allowed in the
document information item, the Envelope element information item, and the
Header element information item [16]. Do we accept this proposal?
Henrik Comments and whitespace
 Need mechanism for what an intermediary can/cannot touch
 The proposal on table provided guidance on which info items are significant and which are not
David F Any discussion ?
Henrik Comments from ChrisF concerning whether whitespace should be allowed
 JJ and Noah in favour of proposal.
Chris F Troubled by intermediary affecting whitespace wrt signing
Marc Similar concern about changing attributes
Chris F Tampering with namespace on envelope
Marc Need for canonicalisation rules on envelope
David F Summary:
 Marc - Need to handle this by generating rigorous canonicalisation rules
 Henrik - Can simply discuss rules for small part
 How much do we have to provide as part of this WG ?
Rich If we are defining what an intermediary can do we are describing semantically important
John I Can we pick up some of the existing canonicalisation schemes ?
Paul D Looks like a conformant intermediary can break the signature
 Need to define some feature which gets over this "preserve whitespace"
Henrik This assumes a SOAP document is fixed whereas it can change over a message path
David F If we decided to do nothing, what would you do ?
Marc Henrik has gone part way
Rich Willing to draft set of rules
David F Henrik doncerned that expanding the algorithm is a black hole
 Rich propose a SOAP message canonicalisation ?
 Action to Rich Salz to produce by end of week.

11. Issue 137, intermediaries relaying SOAP messages without modifying them

NM has proposed text [13] and HFN has offered some small changes [14]. Does
the combination of the text and the changes represent the direction that
the WG wishes to go in order to resolve the issue?
David F Are there still dependencies between 137 and 176 ?
Henrik No, we can treat them separately
 Reviews proposal .....
Chris F Noah's proposal really just restating the SOAP processing model
 Restating the obvious (section 2)
Henrik Are you in general agreement ?
Chris Second part no problem, first part confusing
 Like to see first part reworked.
Henrik Is this right direction ?
 Primarily second part .....
Stuart Not properly grocked warning headers ...
 Seems to be making more complex with warning headers
David F Assume this is in right direction
Henrik and Noah to tighten up text.

12. Issue 133, SOAP and the web architecture

The TBTF recommends resolving this issue as outlined in [8]. Does the WG
have any objections to resolving this issue with this recommendation?
David F TBTF made proposal for resolution
 Arose due to usage of POST in HTTP binding
 This usage may not be the best wrt Web Architecture, however it is not our place to resolve this issue
 Propose to close with existing HTTP binding
Paul C Alluded to "the problem" with HTTP POST - what is it ?
Noah Point of view if you are retrieving info then should use GET rather than POST
Paul C The TAG has been discussing POST, GET etc. and are going to try to resolve this between W3C/IETF
 So, we are doing the right thing in closing this now.
Stuart Mark Baker had some problems
 But proposed a friendly amendement
David F Should we close the issue with TBTF proposal plus Mark's amendment, and only do the current POST binding now?
No objection raised
DavidF  Issue 133 is closed in this manner.
 Stuart to handle closure text.

Meeting closed ...............