W3C XML Protocol Working Group teleconference, 23 October 2002

1. Roll call

Scribe for minutes selected from attached list. Actions to be recorded on IRC. (11.00 + 5) Present 20/17 Excused Regrets Absent

2. Agenda review, and AOB (11.05 + 5)

(Time=0212 ET)

no AOB items.

3. Approval of 9 and 16 Oct telcon minutes

[http://www.w3.org/2000/xp/Group/Admin/#schedule] (11.10 + 5)

postponed.

4. Review action items, see

[http://www.w3.org/2000/xp/Group/Admin/#pending] (11.15 + 10)
(Time=0217)

Misc. notes on action items.

2002/09/04: DavidF (done)
Contact implementers regarding updates to their implementation of table 2 of the implementation table 
DavidF has posted all received, made corrections.  Some reports still expected.  BEA will provide a report by end of day Thu 10/24, but DavidO will not be at F2F to discuss.

2002/10/16: Henrik 
Send email to xmlp-comment to close issue 384, rationale is that we stick with status quo and don't want to introduce the notion of a gateway in the SOAP 1.2 spec 
Henrik posted a comment to xmlp list to discuss an editorial issue related to this. Ther are two defns of gateway. Henrik proposes to delete the defn in section 2. No opinions expressed otherwise. Pending

5. Status reports (11.25 + 15)

(Time=0224)

-- Primer
Nilo:  has all LC comments included except i218 (remove text for processing intermediaries from Part 1 to Primer.)  Nilo waiting for WG to resolve issue 394  first. See Primer change log.

-- Spec
A snapshot has been published for F2F. It is up to date, see IRC for editor todo list URL

-- Test Collection: status of update based on LC issue resolutions
Anish:  (regrets)
DF: A snapshot for the f2f was paublished late Monday.  I assume it is up to date

-- Attachment Feature
nothing to report

-- LC Issue List
Carine says it is up to date.

-- Responses to new charter, especially Call for Responses and IPR statements.
DF: we are now operating under our new charter. There has been a new (AC) call for participation. We have recived some responses ....
Yves: 6 replies. Only 2 companies did not reply, and I have sent private email to their AC reps.  I hope to have resolution by F2F.
DF: F2F agenda item on 3rd day to discuss IPR,  and CR->PR. RayW will not be at F2F, but he has same IPR concerns as before (issue 327).

-- Implementation tracking
[http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html]. We need
a volunteer to peruse the list of features in Table 2 and (a) identify any
features that are no longer valid due to LC decisions, and (b) generate new
features due to LC decisions. This work should be completed by the f2f so
that we can more accurately identify the status of our implementation
efforts.

DF: I have updated the list of features and their implementations. It is looking good, there are only a small number of features without 2 or more implementations, and we have yet to add BEA. I have updated/moved some of the features but we need a more carefull job done to assess accuracy of the feature list. Is there a volunteer to do this?
No one volunteers.
DF: The work needs to be done by the F2F so we can decide at F2F on PR vs CR, etc. We can only skip CR  if there is evidence of interop implementation of each feature. Need acurate list to make decisions.
DF randomly selects a WG member to persue the feature list: Mike Champion.

-- Media type draft, IANA application
DF: we will discuss at F2F, not now

-- Oct f2f [http://www.w3.org/2000/xp/Group/2/09/F2Fmeeting.html], questions?
Yves:  XMLPS code for bridge dial-in to F2F
JI: is the registration list up to date?
(yes)

6. LC Issues [http://www.w3.org/2000/xp/Group/xmlp-lc-issues] (11.40 + 70)

(Time=0239)

-- AF issues without proposed resolutions. WG members will be assigned to
create resolutions for each of these in time for next week's f2f meeting

o 385, add a conformance clause
From QA working group.
AI: Camilo

o 388, explicitly reference equivalence rules for URIs
From QA WG
2 choices RFC2119 or w3c namespace spec.  3rd option:  AF spec.  Cross into implementation?
AI: Marc Hadley

o 390, use of URIs for referencing secondary parts
e.g., URL in SOAP with http:... but cid:  in MIME attachment.
May be implementation issue.
AI:  Carine

o 391, how to dereference IDREFs and URIs
two parts:  1.  Hugo asks for clarification from deref from soap encoding, 2.  editorial term "attachment" if secondary part not with envelope.
AI: Nilo.

o 392, intermediairies and secondary parts
From Hugo re intermediaries and secondary parts, can intermediaries remove attachments, etc?
AI: Jean-Jacques

o 393, specify attachment implementation; this question will be discussed at the f2f meeting
Hugo/WSAWG  wants concrete AF spec.
This is on F2F agenda.  Need proposal to discuss at F2F
E.g. Add subsection to AF doc? One or multiple implementations?
AI:  Mark Jones
MJ: One proposal, or range?
DF: Up to Mark to propose.  Need to frame discussion.  Size level of effort.
MJ: Keep within charter duration, or feel free to go beyond Dec 2002?
Yves:  concrete AF does not need to go out with SOAP 1.2 specs.
DO: WSAWG feels it would be good to keep XMLP WG intact to work on this - it has the right people, and avoids overhead of new WG creation. WSAWG would probably support XMLP charter time extension to finish concrete.
NM:  Against making work on concrete AF spec if it delays progress to CR/PR.
DO:  No one wants to slow down CR/PR
MC:  WSAWG never discussed delaying SOAP 1.2.
Try to send to public list before F2F.

-- The following issues are listed as "editorial". What is their status,
and do we need proposals to resolve them?
(0252)

o 235, missing assertion
AI:  Henrik to alert Anish to do the edit

o 237, assertion 70 missing a bullet
test collection.  cut and paste problem.
AI:  Henrik to alert Anish to do the edit
AI:  Carine - mark issue list as test collection for 235, 237

o 248, use same labelling placement in spec and primer
Nilo:  we should decline doing this.
DF: Any objections to Nilo's suggestion?
 No objections.
DF: issue 248 so closed.
AI:  Nilo send to xmlp comment and originator

o 262, clarify when whitespace is ignored in primer
Nilo:  not really a primer issue.  Should be directed at main spec.
Gudge to rework proposal.
AI:  Henrik alert Gudge that re-write needs to handle 262 also.

o 309, commentator suggests SOAP uses URIs rather than QNames; the Chair
DF: I suggest closing this issue as a duplicate of 277
No objections
DF: issue closed as a dupe of 277
AI:  DF to send to xmlp comment and orig.

o 357, request to change 2 faultnames, "DataEncodingUnknown" -> "
SOAPEncodingUnknown" and "Misunderstood" -> "NotUnderstood"
DF: editors have discussed this editorial issue and closed it already.
They decided it is a generic fault and so keep DataEncodingUnknown, and
they decided to change to NotUnderstood. Anyone object to this resolution?
No objections.

-- Discussion of pushback to any issues we have closed
(Time=0301)
No such issues reported.

-- Potential new issues. For each potential new issue, we will first decide
whether or not to accept it as an issue (based on severity, "8-ball"
impact, time to resolve, etc).
(Time=0302)

o Noah has posted a potential issue
[http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0040.html] based
on the observation that it is currently not possible to ensure that a
header will travel to all downstream nodes using the obvious role='next'
and mU='false' mechanism. The rationale for posting such a potential issue
at this late date is that it appears to concern a very common scenario. The
posting contains a proposed resolution. Since last week's telcon discussion
on this subject, there has been a lot of email discussion. An artefact of
that discussion is a table that summarises the implications of each role,
see http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0096.html: the
discussants have found the table to be useful. Using this table as a
starting point, I suggest we first attempt to summarise what are the
discussants' positions so we can identify their differences and hence the
questions we need to answer.

NM: I am not a strong advocate for any of the options, and I think we have
near agreement on tech characteristics. The sender/receiver contracts
implied some proposed designs may be questionable.

Discussion with regard role=relay solution.
The WG chose a two level mechanism (1.  role, 2. mu) and this solution puts
both levels in the role.

Discussion with regard a solution involving addition of an attribute that
overrides the default.

It would work, but adds a lot of work to put it in spec.
HFN: an override attribute may not solve all use cases
JJ: proposal collapses two different concepts, targetting 
and forwarding; if forwarding required, must use generic 
role name ("relay"), can't use application defined role 
(e.g. "cacheManager")
JK:  agrees with JJ, new role also does not solve all scenarios. only a new
attrib solves all use cases
HFN: went with relay role due to 8-ball question. It possibly solves all questions.
It would be nice to have reading from 8-ball about what would be affected.
????: interaction with previous info items.  look for hidden impacts.
Yves (aka 8-ball):  adding new role is more orthogonal, less interaction
Adding new attrib would have more interaction
NM:  does not agree that one is less/more orthogonal than another.
JJ: both proposals (role, new attribute) require changes to 
spec; amount of changes roughly the same
DF: question of  clarification regarding  new role vs new attrib, are both
solutions completely fleshed out? Is there proposed text for each?
HFN:  Yes, they are both fairly close to being fleshed out.
HFN:  mail list appears to show more people liking the addition of an attribute.
We should use the table from JJ/Gudge to make it clear. I want to avoid another
Last Call.
NM:  Make default the opposite seems more natural, but not at this late date.
DF: to summarise options,
Opt 1:  new relay role
Opt 2.  new attrib, perhaps called relayIfNotProcessed or theNewAttribute (TNA)
MH:  how about another opton where we change mU to new "disposition" attribute
with values = mu | relay | ??
JK:  relay has no meaning when mu=true
NM: such a proposal woul change the crisp semantic of mu; does not ...
AI: Marc to write up proposal 
DF takes a non-binding vote (approx counts)

- replace mustUnderstand with new attrib with three values: 2
- new relay role:  2
- new attrib:  5
- status quo:  1

DF: Clearly more in favor of new attribute option.
AI:  JJ, create proposal for new attribute (TNA).
AI:  Carine, generate new issue
JK:  How will we handle implementation of this new feature?
DF:  We will need to add a new feature to the table and show it is implemented

(Time=0329)

Reject because too late in cycle
DO: reject because wsawg is taking on usage scenarios
AI:  JI to send to xmlp comment and Hal

-- Spec issues with proposals
(Time=0333)
Request from editors to re-instate text that was deleted when we changed
spec after resolving issue 220.
No objections from WG to re-instating the text.

(Time=0335)
o 389, per last week's telcon, Jacek has proposed text for the spec, see
http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0089.html. There
has been a little discussion of this, see
http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0100.html.

Regarding Herve's response to JK's proposal, JK agrees with one point, (optional
lexical value), but disagrees with Herve proposal for "1 or more" (outbound edges
when representing an array) because an empty array is still an array. JK suggests
to add "optional" to his proposal.
DF: any objection to adopting JK's proposal, with "optional"?
No objections.
DF Issue 389 so closed.
AI:  JK to send to xmlp comment ...

o 300 (and 359), How is version transition handled in the HTTP binding?
Issue originator asks whether version transitions work when a SOAP 1.2 node
sends a SOAP 1.1 version mismatch error message using HTTP but with an
application/xml+soap content-type (SOAP 1.1/HTTP used text/xml
content-type)? Email [http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0107.html]
suggests (i) keeping status quo, or (ii) adding text to clarify that a SOAP
1.1 binding may be used in sending the version mismatch error message. Glen
has proposed text, see http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0086.html.

MH: final sentence of para 1 in porposal is wrong.  SOAP 1.1 behavior.
MH, HFN: the text needs tuning up.
DF: but the gist is correct, yes?
MH: it should refer to cases of other media types
HFN: it is a  useful starting point
DF: we will not close this issue now, but we'll tune-up the text and discuss at F2F
AI:  Henrik to tune up Glen's text by deleting last sentence of 1st para, and ???

o 355, CIIs in SOAP infoset
The issue originator asks whether a SOAP infoset may contain Comment Info
Items. At the last f2f we gave Gudge a broad mandate to create a proposal,
which he has done
[http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0187.html]. This
proposal should also clarify editorial issue 262 regarding whitespace
significance as written in the Primer. Noah has described
[http://lists.w3.org/Archives/Public/xml-dist-app/2002Sep/0209.html] 3
changes to the proposal (disallow intermediaries to remove HEADERs, include
references to addt'l rules, editorial). At last week's telcon we asked
Gudge to renew his proposal in order to clarify what is novel and what is
responding directly to the issues. We are awaiting the renewed proposal.

DF: we will postpone discussionof this because we are awaiting text from Gudge

o 277, general comments
Proposal from Herve
[http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0035.html]
regarding use of QNames. Proposal from Herve
[http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0036.html]
regarding use of namespaces.

DF note that Herve is not on call.
MH:  thread on list had too many branches, we need crisp summary
HFN: do you want to  make it prettier, or is something broken? Are you
concerned about processing overhead?
DF confirmed with MH that the thread is too fragmented, and needs work to find main points
JJ: Herve will be at F2F, but on vacation now.
AI:  JJ to inform Herve to be ready to discuss at F2F

o 294, MEC motivation?
Marc proposes to add a MEC definition in Part 2, sec 5.1.2, and to modify
the HTTP binding to address MEC, see
http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0118.html.

MH:  msg exch context (MEC), there is no formal definition, vague. There is no def of
how to initialize and pass between nodes. I agree on no formal def. We should add MEC
to glossary (used only in part 2, so don't add to gloassary in Part 1). Instead, create
subsections in Part 2. 6.2.3 and 6.3.3 talk about initializing abstractly, HTTP binding
does not specify MEP ???? Need to specify how binding knows which MEP is to be used
HFN: Web method property?
MH: Orthogonal to web method (see thread with MB, NM)
NM: Thread not settled.  MH on right track.  HTTP binding needs to address it.
NM.  MEP must be dealt with by binding.  MEC okay to be adjunct.

No objection to closing with MH's proposal, using HTTP Method.
Agree with spirit, but do not closed until spec text is reviewed.

AI.  MH, send spec text. (MH will work it on Mon 28 Oct.)

o 367, 368, 369, various QA concerns
JohnI has laid out a number of discussion points
[http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0033.html and
http://lists.w3.org/Archives/Public/xml-dist-app/2002Oct/0034.html], there
is also a proposal and some discussion.
JI:  368 and 369 combined, what is meant by conformance.  circular def.
DF proposal.  NM objections.
inbound messages.  too narrow to talk about receivers.
initial sender responsibilities.
proceed cautiously
traffic light scenario.
MEPs may influence conformance
DF: did not push back on QA group
HFN  traditionally, do all MUST.  Qualify "if" you are e.g., initial sender.
AI:  DF to re-write (368, 369), also clarify which part of text addresses which issue.

Adjourn.  Time:  0409