W3C XML Protocol Working Group teleconference, 17 July 2002

Includes material from IRC log.

1. Roll

Present 31/26 Excused Regrets Absent

2. Agenda Review & AOB

-- David confirmed that the URL for the Attahments draft spec provided
with the agenda addendum is the correct reference.

-- David noted that agenda item #5/option#3 received the most support
for dealing with the Attachments document. But W3C staff still needs
to confirm this.

-- David would like everyone to register for the F2F, even if sending
regrets.

	

3. Approval of previous 2 weeks telcon conferences.

Previous meeting minutes' approval postponed by a week at Marc's
request (minutes not posted to web site until today).

        

4. Review Action Items


        

5. Status reports.

-- Media type draft/IANA application: Mark B thought that there was an
AI on David on this. David will contact Mark re IANA application.

-- Attachment feature task force: David reported that the task force
felt that the document was more or less complete and needed WG review
at this point. David solicited feedback on the document, section by
section.

Comments received during the meeting on the document were: 

- David said that in the abstract both attachments and parts are used,
but couldn't document be made more formal by using parts. Stuart
prefers attachments for the title. Henrik will provide a sentence in
the intro that attachment is an informal term for part.

- Section 1: Should it be a MAY? Henrik porvided some clarification:
"If you are using feature, then refer to it using this URI". Stuart
had concerns about the word "use". Glen provided an alternative
wording. "When refering to this feature, use this URI."

- Section 5.0: In description of SOAP message property, it represents
the primary SOAP message because there may be other SOAP
messages. David had concern over "the primary SOAP part of the
message". Staurt said that he and Herve have discussed this and have a
clarification on this, which will be posted soon. He provided some
details. Ater some discussion, it was clarified that the envelope is
part of a larger structure. Agreed to judiciously replace "SOAP
message" with "compound structure".

David asked what "a priori with any MEP" means in the last
sentence. Some discussion, after which it was agreed to remove the
sentence. Mike asked what the relation was between MEPs and
attachments. They are orthogonal, and it says so somewhere in the
text.

- section 5.1: Stuart said that the Note feels ackward. He'd prefer
that it to be removed. herve gave reasons why it might be
useful. Several suggestions made for rewording. Agreed to highlight
the potential for conflict in section 5.0 and take out the note. left
to editors to rework this so that the text makes sense.

- section 5.2: same comments about the note.

- section 6: "NEED NOT" not defined in any RFC. It will be change to
lower case in the revised draft. Sub-bullet#1 has a reference to
DIME. Jacek said that Herve said that DIME will use the new
attachments feature; so it is OK to refer to it. Jacek had some email
exchange with him on a MIME representation based on SOAP w Attachments
W3C NOTE. Stuart noted that reference 10 is to an IETF draft. Is the
intent to maintain it and have it disappear after 6 months? Henrik
suggested having them as non-normative references. He noted that when
documents move to the next stage, evaluate the references.

- section 8: Henrik had some clarification on the last para.

{Additional summary gleaned from IRC log:

<DavidF> change to 16 july AF doc: introduce "attachment"/"part" in
the INtroduction
<DavidF> change to 16 july AF doc, sec 5: refer to "primary SOAP part"
<DavidF> change to 16 july AF doc, e.g. sec 5: ensure we correctly
refer to "compound soap structure" rather than "message"
<DavidF> change to 16 july AF doc, sec 5: remove sentence "This
feature MAY be used, a priori ..."
<DavidF> change to 16 july AF doc, sec 6: uncap NEED NOT
<DavidF> change to 16 july AF doc, sec 6: add example mentioning SOAP w/ Att
<DavidF> change to 16 july AF doc, sec 5.1 and 5.2: remove "Note" and
make reference in 5.0 to the warning section re. overlapping
properties in the main SOAP spec
<DavidF> change to 16 july AF doc, sec 8: ensure last para reads as examples
}

- Stuart would like to encourage use of a diagram.

-- David asked if WG was happy with the document's contents.
Yes.

-- Herve said the next version would be available by the next telcon.

-- David said some issue potentially remains on copyright. This
discussion is outstanding. He wanted feedback on the three options for
publication. He talked to Michael S-McQ of W3C and option 3 is
probably possible.

Stuart wanted to know if the bundling options for publication would
require interoperable implementations. David said that the document
states that this is an abstract feature. Paul Cotton said to pick word
from the Infoset spec, stating that this document has no conformance
implications but other specs may conform to it. Paul C also noted that
we need TimBL's approval to publish a first WD, and there shoud be a
first WD before a Last Call WD.

Some discussion on timing of LC given summer schedules. David wants
members to write to him re which groups should review this for LC.

Stuart had question on having a simulaneous WD and LC WD. David said
process document says there should be a WD before a LC WD. however, we
did not do this with the test collections.

WG agreed the draft should be reformatted as a WD.

        

6. Implementation tracking

-- Implementation features not captured in the test collection document: 

Asir will have a list by Friday. David would like to speed it
up. Would more volunteers speed it up? Lynne has some work that she'll
share with Asir.

Anish has provided a list of new features not included. Jacek has
provided comments on this.  As there were no comments, Jacek's list is
the one incorporated.

Jacek is "iffy" about #8 on SOAP header blocks. It does not seem like
an implementation feature. Another one he is iffy about is #17. Not
sure how this affects SOAP implementations. Yet another one is #20.

PaulC thinks Jacek's choice of which are iffy is good, and indicates
he probably set the basr correctly for filtering other
features. Proponents of the ones not included should provide rationale
on why they should be included.

Anish said the same argument could be applied to every one; how does
one draw the line. Jacek's email offers some arguments. Some of them
rephrased as proposed in that email can be answered in a yes/no
fashion by implementors, whereas #17, for example, cannot be so
answered.

Stuart and Lynne intervened...

Jacek will send a further email which will clarify some of these matters. 

-- Status report from implementors:

Jacek (Systinet) sent to David a list of features they have
implemented. It's a large number. After their implemntation effort is
done, he'll mail it to the list. Henrik asked about the end point - is
it running? It will be up soon, and they'll test it on soapbuilders.

H-P provided David with a list of implemented features. is there an
end point? Yin-Ling said yes. But they are still considering
interoperability timing.

As these implementation reports come in, David will provide a count on
the webpage as to how many implementations exist of each feature.

Glen (Apache) said that they do a portion but not all. They are doing
client interop testing with a MSFT endpoint and wil do server testing
next week.

MSFT is working on a list and will provide it soon, possibly next
week. Henrik said they have an available end point.

        

7. LAST CALL issues


#226 was closed but received pushback from Paul Prescod. PP said that
he was concerned that all resources should be identified by a URI, not
when to use GET. Glen said that it seems like a best practice
guideline. Henrik said that such text is there already, in section
4.1.1 in part 2. It is possible that we pointed PP to the wrong
section.

Issue #217 reported by Marc. "A SOAP node must be identified by a
URI". Must it be unambiguous? This is used in a fault , where it is
optional. Marc has sent email to dist-app proposing text - "A SOAP
node is identified by an unambiguous URI". No objections were voiced
objecting to this proposal. The issue is closed.

Issue #229. Marc has proposed text to dist-app. Some email discussion
on this. No objection were voiced to closing this with the proposed
text. The issue is closed.

Meeting adjourned.

Action item summary
<RRSAgent> ACTION: DF contact MarkB re. IANA application [1]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T19-32-01
<RRSAgent> ACTION: Henrik, Stuart, regenerate last sentence of section
2 of 16 July AF doc [2]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T19-40-34
<RRSAgent> ACTION: herve Try to reformat AFTF draft to looks like a
W3C document for next telcon [3]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T20-19-56
<RRSAgent> ACTION: DavidF & Yves, take Jacek's filtered version and
merge it to table 2 of implementation list (add numbering scheme) [4]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T20-37-30
<RRSAgent> ACTION: editors, Look at part 2 to see if it answers Paul
Prescod's pushback on issue 226; if so, contact Prescod and ask
whether part 2 text OK and for him to send new email to xmlp-comment;
if not OK w/ Prescod, come back to WG [5]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T20-50-57
<RRSAgent> ACTION: Editors Incorporate change to close issue 217 ("A
SOAP Node is identified by an unambiguous URI.") [6]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T20-56-11
<RRSAgent> ACTION: StuartW Send closure text to xmlp-comments on issue 217 [7]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T20-56-20
<RRSAgent> ACTION: Editors, Incorporate MarchH proposed change to
close issue 229 [8]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T21-00-19
<RRSAgent> ACTION: MarcH Send closure text to xmlp-comments on issue 229 [9]
<RRSAgent>   recorded in http://www.w3.org/2002/07/17-xmlprotocol-irc#T21-00-27