W3C XML Protocol Working Group teleconference, 11 September 2002

See also the IRC log.

1. Roll call

Present Excused Regrets Absent

2. Agenda review, and AOB

Renewed charter was sent out for review by AC.  Changes include date, IPR clause in line with current W3 patent policy document
Sept 6 was the deadline to respond to these changes, 11 companies responded, this is not enough
David - WG membership should get AC reps to respond to these changes even past the deadline

Additional AOB is the next ftf - to be discussed during Status report along with  projected timetable

3. Approval of 4 Sept telcon minutes

No objection approving the minutes.

4. Review action items

Gudge - will send email regarding Infoset properties after he gets off the plane.

Yves, Carine - what else can we do under current charter?
Yves - in answer to the question "will it be possible to create an attachment feature implementation?", this is not possible because what the chrter says about packaging. This may change this when the charter is approved.

David - ensure we get comments from other WG
David - I sent summary via email this morning. Mian concern is that WSD did not responed.
Jacek - 2 WSD members were going to provide comments, but did not do so. I write Jonathan to place XMLP WSD comments on the WSD ftf agenda
David - with regard XML Schema, do we need them to comment on a particular part of the SOAP 1.2 spec?
No one indicates that we need to have comments from Schema.

5. Status reports

-- Primer
Nilo - LC comment edits are completed - some items will be addressed via agenda - XMLP-comments have been sent and issues have been removed

-- Spec
Henrik - up to date 

-- LC Issue List: status, projected timetable
Carine - it is up to date 

-- Implementation tracking
David - Nothing to report

-- Media type draft, IANA application
David - Nothing to report

-- Publication Schedule
David - given there are 36 issues listed which are not editoral, and assuming we close 5 issues per week it will take the WG about 7 weeks to close the LC issues and move to PR.
Extrapolating a rough schedule from that point:
PR and the AC review which is 4 weeks, i.e. all of November
WG will resolve the AC comments as they are created 
Then 2-3 weeks minimum for W3C Director to move spec to recommendation.
So the absolute earliest recommendation date is mid-Dec, most likely recommendation will be early January 2003.
A FtF in mid-November would give us an opportunity to address AC review comments.
Henrik - ftf is good to resolve issues, would it be better to have it sooner, say end of October?
Noah - minimum notice for a ftf is 8 weeks
David - note that the entire WG can agree for a ftf sooner than 8 weeks
David asks WG members for their opinions on holding a ftf in Nov:
JohnI is OK, Noah schedule is very full and week Nov 21 is out, notes AC meeting in Boston is Nov 8
David - also we need a host for a f2f, any member who is willing please contact me directly

6. Attachment Feature document

Per the 4 Sept telcon, we will consider issues and proposals for resolutions regarding the Attachment Feature WD [4]. In lieu of issues that are identified in the Issues List [14], here are the issues that seem to have been brought up.

From Marc [15]:
-- add ref to SOAP+Attachments; support has been expressed for this
No objection to adding this reference

-- move bib refs to WS-Security, WS-Attachments, SOAP+Attachments to a non-normative refs section; support has been expressed for this
No objection to adding the new section and moving the refs

-- require CID support; multiple statements against this, some discussion whether URIs should be assigned by the binding or application
Mark - point was that part B has raised negative comments 
Noah - adding relative URI's has been raised from John Barton
Henrik - we should "declare victory" on this doc, given the WG workload
Noah - any URI specifically even relative URI's is desired

Straw poll:
Status quo = 3
Add a brief clarification = 5
Clarification like "any URI scheme can be used, including relative URI's ....base URI schemes would need to be established ...."
Clarification text will be posted via email by Herve by end of day (French time). If there are no objections from WG members by noon (Pacific time) on Monday, the editors will incorporate the text into document.

From ChrisF [16], also see thread started by Henrik [17]:
-- concern over the term "part"; Herve [18] summarises 3 options, (i) status quo, (ii) add text to clarify that AF usage of "part" is different from MIME's and WSD's, (iii) s/part/resource/

Straw poll:
Status quo (i) = 1
Add clarification (ii) = many 
Henrik to provide clarifying text which will be posted, available for review, and incorporated into the document on the same basis as above.

-- concern over the term "compound SOAP structure"; there appears to be consensus to resolve this concern by removing "Note" from the beginning of paragraph 3 in section 6 in [4].
No objection to removing the word "Note"

-- concern over specifying relationships between primary SOAP message part and secondary parts; there appears to be consensus to resolve this concern by adding "For example," to the beginning of paragraph 2 in section 4 in [4] which currently begins "Secondary parts can be used ....".
No objection to adopting the consensus proposal.

-- request for clarification of last 2 sentences in section 4 in [4] with regard receiving SOAP nodes' responsibilities ("The compound SOAP structure
model does not require that a SOAP receiver process, dereference, or otherwise verify any secondary parts of a compound SOAP structure. It is up to the SOAP receiver to determine, based on the processing context provided by the primary SOAP message part, which operations must be performed (if any) on the secondary part(s).").
Henrik - this is an implementation issue which is addressed in the implementation section - not sure about Chris's response to that
David - does anyone think we should query ChrisF further on this? Is there any objection to retaining status quo?
No objection. Status quo retained.

David - This covers the concerns that have been expressed regarding the Attachment Feature document. Does anyone know of any others?
None mentioned by WG

David - Next step is to log these concerns as issues. Suggest the 7 sub-bullets in the agenda are turned into issues and handled accordingly. This will require modifications to the Attachment Feature issues already logged by Carine and Yves. They are also to send out aprropriate emails covering these issues to xmlp-comments and the originators.
David - is the WG satisfied with the Attachment Feature Document (with the modifications just discussed) being submitted for Last Call? Note that the final text will  be available for review before submission.
No objection expressed. Voices of agreement.
David - so we will start moving the AF document toward Last Call. Other WG chairs will be notified and asked to respond - which WG's should we notify?
No response.
David - we'll use the same list as before. Editors to prepare a LC WD per end of day Monday issues.  Then go no-go WG decision to publish as Last Call WD at next telcon.

7. LC Issues [3] (1.00 + 60)

-- Part 2, Table 17 discrepancy
See proposal from Herve [5]. Any objection to accepting this proposal?

Marc H - At which layer is there a failure or a success, this is a bit odd....
Henrik - MEP is descibed, outside of HTTP. Concern about failure response clarity - failure could be a combination of things, edge cases could make this more complex. Status quo is ok - edge cases could cause trouble
Marc H - share Henrik's concern 
David - Herve what was the motivation for the proposal?
Herve - we should clarify the discrepancy
Marc H - Herve's problem is that we don't differentiate between SOAP or HTTP faults --- Marc is concern that this will open us up to even more edge cases..

Straw Poll:
Status Quo = 1
Need to think further about this = 3
Action - Marc H - drive the edge cases investigation to drive a proposal for this - due Monday Sept 16, eod

-- Part 2, FailureReason property clarification
See proposal from Herve [6]. Any objection to accepting this proposal?
2 choices -- from this proposal
a) property being a string, and 1 person in favor
b) property being a URI, and 3 people in favor
The Chair notes there is not strong feeling one way or the other, and so on the basis of the straw poll the Chair decides - Failure reason properties are to be typed as URI's.

-- Part 2, State property clarification
See proposal from Herve [7]. Any objection to accepting this proposal?
-- Part 2, Role property clarification
See proposal from Herve [8]. Any objection to accepting this proposal?
2 choices ---- for the above 2 proposals
a) property being a string, and 1 person in favor
b) property being a fully qualied name (qname), and 1 person in favor
c) property being a URI, and 4 people in favor
As before, Chair decides: State and Role properties are to be typed as URI's

Action to editors to act on the above decisions

-- Issue 243, Requirement for complete implementation
See proposal from Noah [9]. Any objection to accepting this proposal?
No objection voiced, the issue is closed with the proposal.
Action - Noah to send email to close issue

-- Issue 269, health warning with regard content types
This issue was discussed during the f2f, and we deferred a decision pending
clarification from I18N. Clarification has now been obtained, see [10]. Do
we wish to add a health warning, and if so what should it say?
Henrik - vote for status quo
Marc H - Henrik, pls explain why current text is ok
Henrik - We reference media type we define and state how the chartered parameter works, given we have little to say about other warning because it is outside our scope - this could cause confusion.
WG agrees to close this issue and keep status quo
Action - Henrik to send email to close the issue along with a brief description of the above summary

-- Issue 320, clarification on use of multiple fault codes
There is proposed text for resolution of this issue (meant to be 1/3rd size
of original proposal, etc) in the current editor's copy, see [19]. Editor's
discussion thread in the www-archive starting at [20]. Do we accept the
text in the editor's copy?
Noah - email thread has generated some changes to the net text over the past week - placing in IRC
David - does the WG need to see the entire text to make this decision?
Jacek - I am happy with the text 
WG agrees to close this issue with the text 2002sept67 email
Action - Editors place text in the spec - Henrik to send email to close the issue

-- Issue 292, how to combine RPC and encoding faults
Based on the f2f discussion and a subsequent action item, Noah has outlined
a proposal [21]. Briefly, it specifies a scheme for handling multiple
faults without regard to adjunct, and that does not hardwire any particular
combinations of faults. We will consider this proposal. If this proposal is
not acceptable, we may consider a couple of other proposals [11]:
(MG) rpc:BadArguments takes precedence over enc:MissingID
(JK) nested fault codes env:Sender/rpc:BadArguments/enc:MissingID

Noah - Must errors mandate the entire msg to be parsed, even though the message is in an error state mid-stream, this is not valid
Henrik agrees
Jacek- he is now satisfied with Noah's proposal
Action - Noah to bring back a shortened version of this proposal

-- Primer issues
Nilo has asked for guidance from the WG on a couple of Primer issues (308 &
275). He has outlined these issues and possible resolutions in [22]. Shall
we accept Nilo's proposals? (This is the "baffling issue" list.)
Nilo - 275 is a bit more general than the primer content - no change needed to the primer but main spec, Nilo to ask for more specific concerns and proposed changes
Action - Nilo to send email to xmlp-comments and originator
WG has no objection to closing these issues with Nilo's suggestions

-- Issue 373, normalisation of text in envelope/headers/body
Do we require normalisation? It appears we previously decided not, see
[12].
David - Per Marc H previous comment, it is not necessary to point out what one should not do = our response is we don't necessarily need to change the spec to address this.....
WG voices no objection to closing issue 373 by keeping the status quo 
Action - John I - send email to xmlp-comment and originator to close the issue.