- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Wed, 5 Mar 2003 12:31:40 -0800
- To: <www-ws-desc@w3.org>
-------------------------------------------------------
Tuesday 4 March
-------------------------------------------------------
09:00 7 MEP review (cont)
[scribe: Philippe]
(slides not available yet)
(Gudge does his presentation "An Interesting MEP")
"A data item service"
MEP 2 IN, OUT
with HTTP binding, req-resp, single channel.
sync
n clients, one service.
consider multicast binding
n clients, one doing an input, the service doing n outputs.
one input, one output (for n clients)
from the client view, the http client sees a req-resp
(I have 2 bindings, one for http, one for output only)
Marc: the output is delivered through http?
Gudge: no, no http involved. I have a binding that says you
can send input and I'll broadcast it. Like IM or IRC.
From the server propspective, it's an input/output.
Gudge: both bindings refer to the same portType
Martin: I assume that one binding is used for the input/output
but in your case, they could be different?
Gudge: they are completely different bindings.
Umit: adding multicast is a different MEP
Gudge: that's more a binding issue than portType.
[sanjiva: I am temporarily on another call, but I note that
dealing with multicast responses require different
programming models - hence it must be represented at
the portType level.]
Marc: what problem are you pointing?
Gudge: How abstract are portTypes? Is it reasonnable to
describe such a portType and bind it the way I did?
Glen: The implications here that we have application semantic
on top of it. How do I express that I'm going to use one
binding on the input and an other on the output?
Jacek: Gudge's case seems an optimization, we don't have to
care about it.
Gudge: for me, it was interesting to have the abstract using
one MEP and have it completely different from the
consumer point of view.
Jonathan: wanted to make sure that this potential issue wasn't a
real one.
Glen: still thinks that they are hidden issue in it, using
two differents bindings from the same service, but
that's ok for now.
Jonathan: can we collect any issue against the MEP stuff?
Jacek: I don't see the motivation for MEP 7 as it stands, but
given the others don't have either, I'm fine.
Jonathan: ... beauty contest in the desert ... :)
jacek: our MEPs won't allow more than 2 roles? or we won't
define some? if the latter, we should demonstrate that
it is possible.
Jeff: use extensiblility
Amy: where does an additional role stand? for the moment,
you have the service and everybody else. how do you
describe alternative among eveybody else?
Glen: if you stick on each input/output a uri, you can
describe the message if you want.
Gudge: you can do that, today but nothing in the syntax. The
MEP has an uri and describes what those NCName means,
so why does you need uris?
Glen: it would be convenient. if there is ncname, it will be
harder to define scheme.
Gudge: it's a pair ... a qname :)
Jonathan: anything else? Do we want to add the MEps in part 1,
part 2, other?
Amy: numeric are somewhat opaque. We need a motivation for
each MEP. If somebody can't come up with a nickname and
a use case, it might not be a every common idiom.
[editorial discussion to have use cases]
Amy: we need a sample for the MEPs.
TomJ: what's the difference between MEP2 and MEP3? MEP3 is
req and possible resp?
[alewis: IN, OUT*, oFault?]
Jeff: req and multiple resp. I can come up with names like
"one-way", "multiple-output" ...
Gudge: what's the point?
Amy: let's collect the justifications.
Jonathan: can we deal with it at CR time?
Tom: collecting use cases is easy, but we are raising the bar
high.
Gudge: if I had to pick 2, I'll pick MEP1 and MEP4 :)
[discussion about a beauty contest for MEPs]
Tom: wants to reduce the list.
Gudge: argues it is not worth going there for the moment.
Amy: we have costumers for some of the MEPs.
[GlenD: +1 to Gudge's MEP1 + MEP4. Let's do it.]
Tom: this group may not be able to satisfy all your custumers.
[sanjiva: Yeah and what about simple request/response stuff like
getQuote()?]
Jonathan: union rather than intersection for our MEPs?
[Tom keeps arguing about satisfying his customers over others' :) ]
Tom: I'd like to reduce the scope of the spec. I'd like to
be done with it;.
Gudge: having 7 MEPs make the spec more useful for more people.
[Jonathan plays his straw poll/vote card]
[sanjiva: are all 7 meps required to be supported? ]
[sanjiva: That is, is a compliant proceessor required to handle all of them]
sanjiva: compliance for the 7 meps?
Jonathan: not all bindings need to support the meps.
jeff: do we have a mep normatively but not a normative binding
that supports them?
Amy: the soap processor does not require you to do http which
is the only binding provided there.
[TomJ: To make my position on the 7 MEPs clear, I think that we
have too many, inparticular MEP 3, 6 and 7. These MEPs
don't have common use cases and we should really set the
bar high on this and take them out of the normative spec.]
[sanjiva: +1 for reducing the # of MEPs]
[TomJ: I understand that others *have* use cases, but I haven't
heard enough demand from multiple companies to make me
believe there will be critical mass for them.]
Amy: if you support the soap binding, the soap req-resp and
the webmethod get. there are 2 meps required, if you
support the binding, you have to support those 2 meps
and not others.
Glen: the soap resp MEP is not MEP 2. the binding is different.
Amy: from WSDL point of view, I should be able to describe
messages others than XML messages.
Sanjiava: are we going to document 7 MEPs, with use cases, etc.
What are our criteria?
Jonathan: that's a political process. we'll have champion for each
MEP. if no champion, they will be less likely to go in
the spec.
Jonathan: suggestion on how to move forward?
[community feedback, champion, use cases, ...]
MChapman: there is a document (usage scenarios) in the WSA with 36
MEPs...
jonathan: we're trying to have balance with atomic ones and add a
few really common ones.
Gudge: I still like original formulation of fault from Amy: any
message can be a fault.
[MChapman: correction: the usage scenario doc i referenced is a wsd
doc, wsa has its own! http://www.w3.org/TR/ws-desc-usecases/]
[alewis: My formulation was actually that any message can *trigger*
a fault. And that if there's no available return path, then
it is discarded.]
Amy: do we want a set of requirements for MEP?
Philippe: we can throw some out at the CR phase
Jonathan: we can ask people to show examples of usage of those MEPs.
Amy: following QA recommendations, we might add performance
requirements, two working and interoperable example the use
a MEP in order to have it in the draft.
Jonathan: reasonnable requirement to set for the CR phase.
Martin: we can all parse the documents that use those MEPs.
[sanjiva: are we going to define MEPs that we won't use at all??? I
don't think we should do that.]
Joanthan: some of these MEPs won't be usuable with our bindings.
people we need to come up with some during the CR phase.
Martin: this is the wsdl group, not the soap interoperable group.
Amy: at some point, we need to find if each MEP is useful or not.
JeffM: easier to mvoe to CR with less MEPs...
Jonathan: if no one implements a MEP with a binding, we pull it out at
the end of the CR phase. 2 interoperable implementations
would be required.
Sanjiva: is the tcp binding going to be documented? I thought we will
provide one binding for each MEP...
Jonathan: I thought the group agreed the reverse actually. To make it
clear, if Amy wants to keep MEP 7, she'll need to convince
someone else to implement it as well with the same binding.
Amy: such effort are going on as we speak.
Sanjiva: are you going to recommending the binding after the CR phase?
Gudge: no, we'll just keep the MEP in the spec.
Amy: "2 independent implementations".
Philippe: how do we record that?
Jonathan: as an issue in the MEP spec seems reasonnable.
Sanjiva: we cannot prove that we have 2 implemetnations, unless we
have the bindings.
Jonathan: that's correct.
JeffS: interoperability of WSDL is not the same as interoperable
of SOAP. how did we get there? how do you think this
criteria will be met?
Amy: "we have supplied you with MEPs, go thou and bind them"
Jonathan: the failure mode is to move the MEP into the darkness of your
own namespace. :)
ACTION: editors of the MEPs to record this CR requirement in the
document
Jonathan: name issue resolved?
Gudge: I like numbers.
[sanjiva: I like names .. :)]
Gudge: lots of troubles we ran into were due to conotations with
names.
-------------------------------------------------------
10:50 Break
11:20 7 MEP review (cont)
[MEP names continued)
[7 sins? 7 dwarves?]
[related to their description]
[arbitrary name or names of some sense?]
[MEP name is pushed on the stack]
DBooth: [catching up] I'm concerned with the way we are defining
the MEPs. When is the appropriate time to raise this issue?
Jonathan: ... CR ... evidence of utility of the MEPs ...
DBooth: not concerned about the choice of MEPs but about the way
we are defining them. I believe it conflicts with WSA
understanding of MEP. Looking at the glossary definition
from Gudge's presentation, was concerned with his
definition of MEP. incomplete definition of MEPs, ignore
the parties that are involve.
Gudge: that's up to the binding. We agreed in Arizona that we
would describe them from the server point of view.
DBooth: that's orthogonal.
Jonathan: our definition of MEP is in the MEP lists. Are you
arguing against it?
DBooth: yes, the parties are ommitted.
Gudge: we established this morning to have a MEP and map to two
different bindings.
DBooth: I'm concerned about that. Doesn't seem the understanding
of MEPs.
Gudge: MEP in WSDL are not the same as SOAP MEPs and maybe
different in WSA as well. The MEP describe messages in
and out at the portType level.
JeffM: for me, portType means the transport level
DBooth: a WSDL is for use between parties, it's a shared thing.
at least two. the point is to get interoperability. Both
parties must agree. WSDL as is defined today is written,
for convenience, is written from the point of the service.
That does not change the fact that the document is
intended to be used by both parties. We could have done
the opposite way: Web Client Definition Language. The
purpose would have been the same.
JeffM: I disagree that we would be the same thing.
DBooth: it would be the exact complement.
Gudge: there is an assumption that flipping WSDL would be the
mirror. This assumption is not true.
Martin: you can setup expectations from the client point of view
anyway.
DBooth: the point of view is independent of the purpose of the
description.
Gudge: how does the service use it?
Glen: you build skeletons on the service with it. that's a
contract.
DBooth: then, if the contract has all information between the two
parties, it would be nice to have it shared by more.
Amy: the client cannot see the agreegated service.
DBooth: each interaction has a WSDL. different portTypes.
[JacekK: this image might be helpful: http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/att-0069/01-meps.png]
DBooth: different service address. WSD representts Agreement
(or contract between 2 parties)
Martin: not a contract in terms of negotiation. it's defined from
the service.
DBooth: take it or leave it contract. Definition of MEP 1 template
for the exchange of messages between nodes. it's a
message _exchange_ pattern.
Levels of Abstraction / Reusability
- No abstraction/reusability
- Variable service address
- Variable transport
[GlenD: Node Emission and Reception Description (NERD)]
[Gudge: Message Emmision and Reception Pattern - MERP ( rhymes
with burp )]
DBooth: you can reuse the abstract even with different protocols.
Glen: if Gudge's example valid, we lost that already.
DBooth: possible level of abstraction here. each level gives you
more reusability.
JeffS: we want to make standard here. I need you to be very specific
of the piece of abstraction that we lost.
DBooth: the symbolic identity of the parties must not be abstracted.
JeffS: doesn't exist in WSDL 1.1
DBooth: my understanding of WSDL 1.1 is that the operations that
are described are between two parties.
JeffS: you're arguing that was implicit in WSDL 1.1 then. you want
to make explicit?
DBooth: we shouldn't push it in the binding.
[http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/att-0069/01-meps.png]
Jacek: in David's world, WSDL is a contract. SOAP MEP can cover
any kind of complex MEP. What is a WSDL MEP? Is it the part
that concerns one node and involved two parties? You can an
MEP as me as a service and the world, or me, you, and the
interactions, or me, you and a set of nodes. We should decide
what way we go.
Glen: there should no way to confuse at the abstract level me and
you (or other nodes). Web Services is about the wire and what
goes on the wire. need to think about the connections between
things.
JeffS: I'm trying to describe the messages from a network with a service
[...]
Umit: the problem with JeffS' level of abstraction, you loose the
initial intention. multicast is not the same intention than
simple req-resp.
JeffS: a possible move is to accept both views.
Gudge: given that binding can do the way like anyway, how do we go?
Glen: it's going to be challenging for people to deal with that.
DBooth: agree that 2 levels of abstraction is ok. People will want to
reuse the same pattern of interactions.
Gudge: from the service, it is always the same pattern.
Glen: the semantic of the service is different. don't multicast my
bank information.
Gudge: how can you prevent that anyway? You stated that it is possible
to build unsecure binding, which is fine.
DBooth: if you define things at the binding level, you may not be able
to reuse them
Igor: can you 2 bindings concretizing one MEP?
[input/output, one binding for input, one binding for output.]
JeffS: you have to define constraint in the same binding. Our
construction today implies that you'll need one binding
construct to represent email input / soap output for example.
Martin: so, in Gudge's example, who describe the multicast?
Gudge: we have simple MEPs that can be bound to more sophisticated
binding.
DBooth: [trying to summarize] if you define an operation with MEP 2,
it is ambiguous if the output is supposed to go back to the
same party that sent it.
Gudge: it always goes back to the party, it may go to others as well.
[MChapman: i'll try and explain my issue: if at the abstart level one
uses a mutlicast mep and in you binding over tcp (for example)
how does that work - who defines all the extra mecanism, or
should that mapping be invalid]
Gudge: if it's going to take us too long, let's have MEP 1 (input
only) and MEP 4 (output only).
Glen: actually, no one explained how to do input/output over one
way protocol
Martin: then let's adopt CCPA. it only describes input, output
messages.
[sanjiva: CCPA?]
[Gudge: CCPA - Canadian Chemical Producers' Association,
Canadian Centre for Policy Alternatives,
Cumberland County, PA,
Canadian Concrete Pipe Association,
Connecticut Community Providers Association,
Centre for Creative and Performing Arts]
[s/CCPA/CPPA/]
[MChapman: ebxml Collaboration Profiles and Protocol Agreements]
DBooth: I don't think we should the ambiguity between the input goes
to the server and the output goes to somewhere we don't know.
Amy: it doesn't seem that you're suggesting that we need multiple
roles. you want to ensure that the output goes to the sender
of the input message.
JeffS: we can reuse properties and features to describe David's
concern. Soap identifies the parties except the current one.
tom: I believe that David want the input/output involved the same
parties for the MEP 2.
Amy: the agreement in Scottsdale was MEP 2, not request-response.
there may be a use for a request-response, but that's not
the agreement.
Tom: I don't think that's true.
DBooth: I'm okay with Amy's statement but let's distinguish it
clearly then.
[...]
Jonathan: I propose to add this issue in the spec.
DBooth: can we take a straw poll on this issue?
Jonathan: do we want to be able to express a request-response at the
portType level?
JeffS: I note that in the current spec, you can make any arbitrary
statement about an MEP. you rewrite MEP2 to include David's
need.
Glen: does our concept of MEPs can be linked to a more general
concept of MEPs that includes roles?
[dbooth: q1: Should we have an MEP at the PortType level that is
request/response (i.e., the response is known to go back
to the requester)?]
[dbooth: q2: Should we have an MEP at the PortType level that is
input/output without implying that the output goes to the
same party as the input came from?]
[jeffsch: jeffsch notes that q2 is the current MEP2]
Tom: I always had the view that MEP2 was in fact q1
[dbooth: These two questions are not mutually exclusive. We can
certainly say yes to both.]
Martin: I don't really care as long as you can annotate the MEPs
at the abstract level.
Sanjiva: why is important to annotate the difference between those 2
cases?
DBooth: it might not be important. I think it is important to know
that interaction pattern and reuse it.
Glen: WSIF have said it is important.
Mark: with a request-response, you can assume the recipient of
the output based on the sender of the input.
[straw poll
q1: 14 yes, 8 no
q2: 15 yes, 5 no]
Gudge: so we now have 14 MEPs...
[sanjiva: I vote for not distinguishing]
[sanjiva: (soon we'll be up to 140!)]
ACTION: Editors MEP to add an issue to address request-response MEP.
[JacekK: we have 8 MEPs, maybe 9 if MEP3 is also concerned]
[going back to MEP name]
[arbitrary name? meaningful name?]
Jonathan: do we want to change the current names (MEP1, MEP2, ...) to
something more meaningful? Having arbitrary names
won't mislead people. do we want to change the current
names (MEP1, MEP2, ...) to something more meaningful?
[17 yes, 1 abstain]
arbitrary names?
[2 yes]
ACTION: Editors MEP to suggest meaningful names for our MEPs
[sanjiva: integrate to part1 draft]
[do we want to include the MEP spec into part 1 or part 2?
or separate?]
[Allen: Part 1]
Glen: soap describes the concept of MEP in part 1 and defined
some in part 2
[sanjiva: specific MEPs are not binding specific .. they are not
bindings either. They are abstract. So IMO either its
in part 1 or in part 1.5.]
[part 1? part 2? part 3?]
part 3: 12 for
part 1/part 2 in some fashion: 3 for
Resolution: let's keep as separate spec for the moment.
part 2 is for MEPs
part 3 is for bindings
ACTION: Editors to come up with a part for MEPs
Jonathan: any objection to roll in the changes of part 1 into
the main branch?
[jjm-rns: no]
[postponed]
[Gudge: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.xml?rev=1.46.2.4&content-type=text/xml&only_with_tag=ComponentModelForMEPs]
[Gudge: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html?rev=1.21.2.1&content-type=text/html&only_with_tag=ComponentModelForMEPs]
-------------------------------------------------------
12:50 Lunch
14:00 issue clarify type and element
- Arthur's proposal [11]
[11] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0055.html
Agenda item (clarify type and element)
Arthur: problem is coupling between port type and binding. Caused by
incompleteness in the binding rules
[Arthur presents presentation: URL to follow......]
[dbooth: Arthur's slides are now available as PowerPoint at http://www.w3.org/2003/ws/desc/3/05/arthur/RemovingElementAttribute.ppt or as HTML at http://www.w3.org/2003/ws/desc/3/05/arthur/RemovingElementAttribute_clean.htm]
Tomj: concern that introducing more options on the binding
that effect the wire
Arthur: currently there's a diff port type per binding
Tomj: did we already look at type and element (getting rid
of one or both)?
Gudge: in VA... Main motivation to create abstract messages ??
Arthur: yes
Gudge: Agrees to get rid on one.....
Arthur: if we keep both the bindings need to be a lot more rigorous
Marsh: Is one of the reasons we've delayed this is that we can't
decide which one to remove?
Umit: Maybe we should really work on the bindings before we
remove either one.
[Now at Example SOAP Doc Binding slide]
Gudge: It isn't possible to guarantee all messages in WSDL be
bindable to SOAP/Doc, SOAP/RPC or ...... Still don't get
the "wrap" use
Glend: pitches for keeping element and removing type
[sanjiva: Glen, if you keep only element, how do you define a
string part?]
[GlenD: Sanjiva, Just as you need to wrap an element in a type
for the other direction, you can wrap a type in an
element this way.
name="foo" type="xsd:string"
I could either put <part> around that, or <element>
around it. Same fing.
[sanjiva: spse you have a function foo that takes two strings s1
and s2. You would need to define two elements right?
Beacuse the name is part of the definition]
[GlenD: there are two elements, yep.
name="s1" type="xsd:string"]
[sanjiva: Right so its not the same thing- the other way you
don't have that problem
name="s2" type="xsd:string"]
[GlenD: ?]
[sanjiva: I mean wrapping an element in a type approach (i.e.,
the drop @element case)]
[GlenD: what's the "problem" you refer to]
[sanjiva: That you have to define a new element for each use of
a simple type]
[GlenD: oic
well this gets into the next discussion... :)
it's only redundant if you have both part and element.
If "message" is just an element containing elements....
they're only defined once.....]
[sanjiva: And what about a mime:image/jpeg "part"?]
[GlenD: aye there's the rub, matey.
annotations.]
[sanjiva: yep]
[GlenD: But that's the tricky part]
[jeffm: Here is the url to the current "approval draft" for the
WS-I 1.0 Basic profile:
http://www.ws-i.org/Profiles/Basic/2003-01/BasicProfile-1.0-WGAD.html]
[sanjiva: that's utter crap ;-)]
[GlenD: we'll get there
yeah yeah. :)]
[Now on HTTP Post Binding slide]
[Gudge and Arthur discuss HTTP Post/Get bindings ]
Arthur: The net of the talk is to achieve abstractness at the
port type.... Is there agreement that a worthy goal that
port types are abstract??
[Group agrees (nobody decented)]
Arthur: This implies that the binding specification need to be
fixed (ie.not broken)
Marsh: The question is do we want to remove either type or
element.....
Umit: should look at removing message before addressing the
type/element decision...
Marsh: Should we still keep the type vs element issue open??
group: yes
-------------------------------------------------------
15:15 Break
15:20 Renaming
- Template [12]
- Phillipe's proposal [13]
portType -> interface;
port -> endpoint;
binding -> interfaceBinding
- Jacek's proposal [14]
binding/@type -> binding/@interface
- DavidO's proposal [15]
port -> Service
portType -> Interface
service -> ServiceCollection
[12] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0120.html
[13] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0103.html
[14] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0108.html
[15] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0112.html
Agenda item: Renaming
TomJ: Prefers smaller changes to the naming than DaveO's changes.
SJ: Should save this for WSDLv2.0
GlenD: doesn't see name changing any more than changing a namespace
as far as the language
Amy: Name change is also desirable for naming conflicts between
WSDL and other environements (ex defn. of service)
Dbooth: Friendly ammendment (change port to webservice) to dave's
proposal
GlenD: s/web service/endpoint
Marsh: Let's take one at a time
Straw Poll: change portType to interface
[results of straw poll (uc)]
port: endpoint? endPoint? service? webservice?
[Allen: I vote for endpoint]
Issue: Re-open One interface per service issue
[Gudge: I think we should choose some unicode code points outside
the ASCII range and use those. Then we could get down to
single character element names ;-)]
TomJ: Call for straw poll: endpoint yes or no
Yes = 16
No = 0
Marsh: Any objections to endpoint ? (none)
Amy: should re-visit the service renaming until the (one
interface per service issue) is solved....
[sanjiva: -1 for changing to interfaceBinding]
Marsh: Changing "binding" to "interfaceBinding" Yes or No?
Yes = O
[TomJ: Proposal: binding/@type -> binding/@interface]
[sanjiva: +1 to Jack's proposal to make binding use @interface]
[Allen: yes]
Marsh: All in favor of changing type attribute of binding to
interface?? Yes or No
Yes = all
Marsh: change mep attribute on operation to "pattern" Y/N
Yes = 13
No = 0
-------------------------------------------------------
16:50 issue fault name uniqueness
- Paco's proposal [10].
[10] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0045.html
New fault elements and names proposed to replace the generic fault
[sanjiva: +1 TomJ's proposal]
[Marsh: <inputFault name="...">
<message>Â....</message>?
</inputFault>]
= what Jon thought Tom wanted]
[Gudge: That works]
[Marsh: <inputFault name="..." message="..."/>*
= what Tom actually wanted.]
[Gudge: I don't think that works. Because we can't enforce the
uniqueness constraint]
[sanjiva: I don't understand - do you mean from XSD?]
[Gudge: that the groups need to have different names ( and those
names need to be unique WRT input and output too )]
[sanjiva: We can express that in English; are you saying it cannot be
expressed in XSD?]
[GlenD: good q]
Amy: given the impending change in syntax for faults/fault
groups, fault name uniqueness may be a non-issue
Marsh: fault name uniqueness now a non-issue
-------------------------------------------------------
Marsh: eliminating message agenda item deferred
Marsh: Future F2F info updated on the web site, please check.
Marsh: message (eliminate) issue will be moved back to telecon
discussions
-------------------------------------------------------
17:00 Adjourn
---------------------------------------------------------------------
Topics for future meetings:
1) issue eliminate message
- [Relevant materials from Roberto, Gudge, etc.]
2) If we have no other outstanding Part 1 issues, we will try to
tackle some properties/features dependent issues.
- BindingType proposal from Kevin [.1]. Updated proposal at [.2].
- Issue 28: transport='uri' [.3]
- Issue 2: SOAPAction has been deprecated, as of SOAP 1.2 [.4].
Jean-Jacques proposal at [.5]. Jacek's addendum at [.6].
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2002Aug/0009.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0068.html
[.3] http://www.w3.org/2002/ws/desc/2/06/issues.html#x28
[.4] http://www.w3.org/2002/ws/desc/2/06/issues.html#x2
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0050.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2002Sep/0056.html
3) HTTP Binding Issues (6a, 41, etc.)
Big question: how much do we want to work on this [.1].
Jeffrey's summary and recommendations (no change) [.2].
[.1] http://lists.w3.org/Archives/Public/www-ws-desc/2003Feb/0025.html
[.2] http://lists.w3.org/Archives/Public/www-ws-desc/2002Jun/0102.html
Received on Wednesday, 5 March 2003 15:31:52 UTC