W3C XML Protocol Working Group teleconference, 26 March 2003

1. Roll call

Actions recorded on IRC.

Present 15/13 Excused Regrets Absent

2. Agenda review, and AOB


3. March 19 telcon minutes are up for approval

No comments and no objections to approval of minutes.
DavidF: Approved.


4. Review action items



5. Status reports

-- Part 0
Nilo is not present, but he did send update mail:
Jean-Jacques: Primer is in sync with Parts 1 & 2.
DavidF: Primer should now follow the same rules of change as the other

-- Part 1
Editors: Nothing to report.

-- Part 2
DavidF: Strange characters (at-signs or boxes, depending on the browser
used) appear in Part 2.
Yves will help fix these problems.
Editors: Nothing else to report.

-- Test Collection
Anish: Sent status to list:
 The Test Collection doc is in sync with Parts 1 & 2. The only
 differences since F2F are the change from valueType to nodeType, and
 a bugfix for T59 (id and ref attributes were not in the SOAP
 encoding namespace).

-- Registration of "application/soap+xml" media type, see
Yves: Mark Baker & I will publish updated version and submit to IANA,
within a matter of days.

-- n11n publication
(Covered in Action Items portion of agenda; no further comments.)

-- IPR
Yves: Nothing to add.


6. CR progress and issues

-- CR implementation report, see summary table at
The table currently (25 March) shows 6 features for which we have not yet
accumulated sufficient evidence. There is an implementor's telcon tomorrow
prior to the XMLP WG telcon, and that meeting will produce a more detailed
report on the expected schedule to complete the remaining features. At this
time, we do know there will be no more implementations of nodeType in the
near future, and so we will decide how to handle evidence for it. We will
decide how to handle evidence for the other features based on the
implementor's report.

DavidF: Implementors have traces for all but 3 features. 2 of these
 are in progress and should be complete by Monday, except for 79
 (NodeType) and part of 77.2 (DuplicateID). Implementors will
 double-check that traces capture all features and are complete (by
 Monday). See email summary of today's implementors telcon:

WG must decide how to handle NodeType. The choices are:
1. remove nodetype from spec, or
2. leave in and inform W3C that it is too early for implementors to
 test interop of this feature. If we receive pushback, we could
 remove it, but this would cause the namespace to be changed.

Straw poll: 1 for removal (but no strong objection to leaving it in),
 5 for leaving it. No objections to proposal #2 (maintain status

DavidF: A similar decision may need to be made about MissingID next
 week; otherwise implementation evidence for PR is almost complete.

Glen: While testing proper use of the role attribute, there are
 differing interpretations of empty string. Some implementations
 assume it to be ultimateReceiver, others don't accept it as valid.

Needed from WG:
1. Clarification about what happens when role attribute value is empty
2. what to do about it

Text about empty-string value of role was removed per a LC issue (#233).

MarcH: role could be a relative URI (XML Base), so it becomes whatever
 the current active base is.

DavidF: What happens if there is no base?

Gudge: We reference RFC 2396, so the question is, does that allow
 empty strings? Will investigate. Believes empty string is legal.
 "rel_path" consists of any number of characters, perhaps including
 0.... Will sort it out by next week.

DavidF: Is it a problem if we don't specify this edge case? It's not
 what anyone would generally do. We could target resolution of this
 for a SOAP 1.2 Errata. Whatever, we should add it to CR issue list.

-- Issue 419 (http://www.w3.org/2000/xp/Group/xmlp-cr-issues.html#x419),
"SOAP action as property". How shall we handle this WSD WG suggestion? Two
obvious options appear to be (i) ignore, this is too late, (ii) make
change, it doesn't affect implementation status nor is a significant spec

Glen: SOAP "action" parameter, which may be used for routing or other
 informational purpose, exists in the media type. Our extensibility
 model is in terms of Features, but we don't use our own model to
 express this. (There is no WSDL property for setting action
 parameter.) Proposal: resolve by adding an "action" feature to HTTP
 binding, approximately 3 paragraphs, analogous to Web Method feature.

MarcH: Can see the point of doing that, but does it affect the text in
 a negative way at this late stage? It might be too late.

DavidF: Another approach would be to liaise with WSD to address this
 in the future as an errata.

Glen: Can see the value of that approach.

DavidF: WG members either doesn't want to change the spec, or don't
 understand the issue well enough. Suggest that we postpone this;
 hesitant to change the spec at this late stage of the process.

Jacek, Glen, Jean-Jacques: Want to see proposed text before deciding.
Action to produce rough draft of this by end-of-week.

-- pushback on any issues closed?
No pushback received.


7. Attachments

-- The promised "single-infoset" approach to attachments has been published
in a document called "Proposed Infoset Addendum to SOAP Messages with
Attachments", see
http://lists.w3.org/Archives/Public/xml-dist-app/2003Mar/0060.html. The WG
will consider the approach described in this document, and in time decide
whether or not to use the approach as the basis for creating an attachments
specification. (Recall that the WG is on record to specify an
implementation of the Attachment Feature specification.) Any eventual use
by the WG of the approach described in the document is subject to the
authors of that document providing appropriate copyright and IP statements
to the W3C. Given that the document was published only this morning, the
Chair does not expect the WG to reach an immediate decision on whether or
not to take up the approach described therein. We will spend time on
clarification and discussion of the approach with a view to making a
decision at our next telcon (2 April).

DavidF: Question to editors of the proposal, is anything in flux?

Gudge: The document only lays out a basis for a concrete
 implementation. We could not just adopt it and be finished.

DavidO: The comments received so far are helpful in seeing how
 everything fits together.

MarkJ: Request an informal poll of the authors to see what IP issues
 may exist; speaking for AT&T, there are none.

DavidO: BEA strives to make everything they can royalty-free.

Gudge: Microsoft anticipates no problems.

SAP: No problems.

TIBCO (not present).

Jean-Jacques: Canon has no issues.

JohnI: This is a good direction. My questions are process-based. How
 would it fit into the SOAP 1.2 process, specifically interop
 requirement. Would it begin a separate track?

DavidF: Attachment work was established on a separate track from SOAP
 1.2, so as not to delay SOAP. It was decided that attachment work
 would be done as resources allow.

JohnI: What is the impact on abstract feature doc? I support a
 requirement gathering process. Are there any IP links back to the
 original AF document to those authors who are no longer involved,
 that would require release (HP, for example)?

Gudge: Expects to take both abstract and concrete docs to REC.

MarkJ: Concur. AF doc is deficient and needs to be extended anyway.

Anish: It was only published yesterday; would like more time to review
 before continuing discussion.

JohnI: Let's reserve time at next week's telcon to walk through it in

Yves: W3C believes that this would be in scope for the WG.

DavidF: Request that W3C staff read proposal in more detail and
 confirm that this decision will stand.

-- Status report on XMLP WG scope vis a vis "Proposed Infoset Addendum to
SOAP Messages with Attachments"t last week's telcon, we started making
progress on the attachment requirements listed in
We accepted R19 and R1-5, and ended on a discussion of R13. We will pick up
this discussion and continue working through the remaining requirements.

DavidF: Continue discussion of R13 from last week's telcon, re arbitrarily
 large parts. Any new insight?

MarkJ: If we incorporate MIME multipart, how do SwA implementations
 currently behave, just run out of memory when a part that is too
 large is encountered?

Jacek: No limitations; a network stream is provided.

Glen: Agree. Suggest that no limitations needed.

Gudge: Our implementation also has a mode that provides a stream, so
 parts may be of any size.

DavidF: No objections to postponing discussion. We will revisit this
 issue when more concrete designs exist.

R26, support streaming of parts.
MarkJ: Suggest postponing; currently a SHOULD, not MUST.

DavidF: Options are to accept as SHOULD or postpone until use cases
 are generated. Consensus is to postpone.

R21, extending metadata associated with whole message packaging
R31, extending metadata associated with individual parts

DavidF: "Extending" implies that there is metadata to begin with.

MarkJ: Maybe change wording to "provide an extensible means of
 associating metadata with message and parts". Will rewrite these
 to clarify.

-- Any other attachment proposals/issues

DavidF: Meeting adjourned.