Umit: Have not receiving all emails, but do see the missing ones in the archives.
Members are instructed to report problems of this nature to firstname.lastname@example.org; give message IDs that are missing so the problem can be tracked down.
No corrections offered. Minute accepted.
MarkN: Summer time has begun in Europe; Daylight Savings Time begins in most of US next week. Propose moving concall to 1 hour later. Those in the UK would much prefer this, otherwise they would be joining at 5:00am. Most WG members are in favor of this change. Look for more discussion and resolution on the WG admin list.
MarkN: Received an objection before last week's deadline, so we have not yet gone to Last Call. Discussion of a compromise has progressed on the mailing list.
DavidH: Much has been said on the mailing list. We have special treatment for fault and reply, tailored to MEPs. Arbitrary claims of extensibility in the core spec are made. Willing to move on with inclusion of a note in LC draft stating that we seek comments on this issue, and are still working on it.
Proposed - Should MAPs be divorced from the rest of the specification
MarkN offered a change to Anish's proposed text, to indicate that we have closed the issue, but that it is still contentious.
DavidH: OK going to LC with inclusion of this note. May raise proposed issue as an LC issue after further examination.
Umit: Is it normal procedure to link to the issues list?
MarkN: In the list, this issue is clearly marked closed.
DavidO: Agree that this is a good way forward.
MarcH: Are we leaving the door open to a forced return to LC?
MarkN: We won't know whether this, or any other part of the specs, will be subjected to issues being raised, until we proceed to LC.
DavidO: This will give the WG time to produce concrete examples of MEPs that can or cannot be supported by the chosen model.
DavidH's proposal from email this morning:
scribe: "The Working Group requests
feedback regarding the mechanism for and
... description of Message Addressing Property extensibility /beyond the
... MEPs currently described in the WSDL specifications/, along with use
... cases that illustrate how referencing specifications and other users
... of Addressing intend to extend them. Although the Working Group has
... resolved upon a particular design [link], some participants believe
... it is not adequately specified. Such feedback will help the Working
... Group determine whether it needs to re-examine this issue."
Jonathan: Wants to go on record as believing that this text is not necessary.
Paco: Agree, it is not needed, but do not object to proceeding with it in place.
MarkN: We will be unable to complete the full LC period before next F2F; propose an LC period that end in mid-May so that issues can be resolved at June F2F in Berlin.
Formal vote to take Core, SOAP Binding, Schema to LC, with note indicated above. If published this week, end in ~5 weeks, mid-May.
Jonathan: Prefer to limit LC duration to 1 month.
MarkN: Propose to have it end on May 4 then.
TomR: Due to OASIS Symposium the prior week, prefer to end a week later.
MarcH: Agree; some TCs meeting that week may have comments.
MarkN: Any objections?
None heard; Last Call is approved unanimously. Chair and staff will consider, but are not obliged to abide by, scheduling concerns expressed by the WG.
RESOLUTION: Core (with DavidH's proposed note) and SOAP Binding docs, with appropriate schema, approved for Last Call.
The above are deemed purely editorial issues from Jonathan.
Paul sent a draft form for collection of use cases this morning.
Possible classes are Conformance, Interoperability, Composibility,
Limit test/error handling.
MarkN: Want owner for issue 41 and Test Collection doc; we have other
things to concentrate on in the meantime.
Paul: Like having each case be standalone, rather than all in one
document. We might wish to have a separate mailing list for submissions.
MarkN: OK to use the public list for now.
MarcH: Examples cannot be exact (namespace prefixes are allowed to be
different, etc.); describe in the abstract what is expected.
DavidH: How are these used?
MarkN: Exit criteria for CR requires interoperable implementations.
Philippe: Purpose of CR is to test the specification itself. Not sure
whether we can write a test for a MEP that is not defined by the spec.
Owner: Hugo Haas
<scribe> ACTION: 2005-01-17: Francisco Curbera to create a concrete proposal
for a wsa:engaged marker. PENDING
Proposal 1: <http://www.w3.org/mid/20041105215731.GD20555@w3.org>
Paco introduces his proposal:
DavidH: (Discussion regarding implications of absence of the marker.)
If the marker isn't present, client should not include any wsa headers.
If it is there, continue to treat it as a synchronous transfer.
Paco: Clarify that if client sees the marker in a wsdl service, it should
not necessarily assume that a non-anonymous reply can be used. Gets into
the area of Async Task Force issues, which I don't want to touch.
DavidH: Migration is important; may not have sidestepped as much as
necessary to accommodate this.
Anish: Re migration, consider relaxing requirement that wsdl:required
is always true.
Paco: Not very hung up on this issue. Can define another binding.
Anish: How do I say a particular service conforms to core, but not
necessarily the MEPs?
Umit: Will this proposal prevent addition of ReplyTo for composition of
one-way MEPs into more complex exchanges?
Paco: No, this isn't trying to preclude that. As soon as we understand
what Async TF wants to do, we can update this.
MarcH: Have you thought about placing this extension on the port/endpoint,
rather than the binding? If so, one could include an EPR as part of the
Paco: Prefer to keep this marker separate from that usage. Will think
MarkN: Sounds like people are generally in favor of this proposal;
is the next step to see spec-like text?
Anish: Would prefer to discuss further on the list.
MarkN: Expect to have substantial discussion about this at April F2F.
Owner: Anish Karmarkar
Owner: Anish Karmarkar
Proposal 1: <http://www.w3.org/mid/41ED99B7.email@example.com>
Anish: This is constrained to WSDL document, so not actively discussing
it. Sent joint proposal with Paco, received a couple responses. Need a
<scribe> new proposal that doesn't talk about logical addresses.
MarkN: Seems like people need time to review this and discuss next week.
MarkN: Re Aync TF work, additional MEPs; some members of XMLP WG
expressed that they didn't wish to do further work along these lines,
only maintenance on existing specs. Do we want to request formally that
they take this on?
Philippe: Even if we expect it to fail, we should send the request,
so that the response is on record and we can make other plans.
DavidO: Would we be happy if XMLP WG accepted this? It may lead to
scope and scheduling issues if they do.
Anish: Sending official request would be useful.
DavidO: Have issues with adding another dependency to the process;
WG coordination issues may become complicated.
Anish: Depends what kind of list we give them; how limited it is, and what
the dependencies are. Seems like MEP part is independent of addressing.
DavidH: What is the size of work involved?
Umit: Async TF discussed this, in/optional-out, in last meeting.
Should engage XMLP WG; agree within TF what to do, and ask whether XMLP
will accept what we produce.
Paco: Lean toward doing it ourselves, but we should offer it to XMLP.
MarkN: Sound like we should ask them, but expect that they will say no.
The question is then how do we expect to get it done. Where is the TF
at on this?
DavidO: Jonathan proposed a new MEP with request/optional-response.
It would be the implicit MEP used by new binding. When you actually
use it in WSDL, you constrain it.
MarkN: Default is continue with the TF work, not to ask XMLP.
Amy: Ask Async TF to define requirements in this area?
MarkN: We may have done this in the past, but will do so formally.