W3C home > Mailing lists > Public > public-ws-pnf-tf@w3.org > February 2003

Minutes PFTF 20030218

From: Philippe Le Hegaret <plh@w3.org>
Date: 18 Feb 2003 22:05:37 -0500
To: public-ws-pnf-tf@w3.org
Message-Id: <1045623912.5017.1.camel@chacal>

[raw minutes at http://www.w3.org/2003/02/18-ws-desc-irc]





Glen: reading at don's message:
try to get that in mind. We can process all usage scenarios and go in
them one by one.

David: let's try to get one and see how it looks before getting to the
next one.

Colleen: do we have a list of scenarios? i.e. discuss the list first?
 [list is at


Glen: all the way down, ie. including the syntax?

David: not sure. concern about our schedule, f2f is too closed.

Glen: is there anything missing in the list?

Paco: optionality between features and also add the capability of
features requirements.

David: optionality and security related to authentification.

Paco: about building optionality into the feature itself.

 [[ 2.2.n abstract feature is optional. ]]

Paco: in addition, you also want optional within the feature as well.

 [[ 2.2.n+1 declarative provider policy ]]

David: policy about what kind of action you do as opposed as a policy on
what kind of features you requiring.

Glen: negotiation can be designed as a feature.

David: let's dive into that.

Glen: agreed. let's go deep into an example. re negotiation use
case. security requires negotiation. a fault sent back may contain a
mustUnderstand. this is a kind of negotiation.

David: you asserted that negotiation can be done as a feature. seems to
me like negotiation is a really obvious. we need at least to include it

Glen: the purpose of this group how properties and features fit into the
world and in particular to help the WSD to better understand what the
landscape looks like and it fits. we need to come up quickly with an


straw poll: negotiation feature?

in: David, Paco, Youenn, Colleen
out: Jean-Jacques, Glen
Abstain: Amy, Philippe, Steve

-> it's in.

ACTION: Colleen to send a proposal for negotiation feature
ACTION: Jean-Jacques to include the Colleen's proposal on negotiation

Where should we start?

 S2 and we'll see how we're doing.



 "A sender requires that a abstract particular security feature be
 used. The feature is either implemented natively by the selected
 transport protocol (S2.1) or implemented as one or more SOAP header
 blocks (S2.2)."

Glen: a security channel feature 

David: it's a property of the message exchange as opposed to
authentification feature...

Glen: you can use a secure channel, or encrypt the message.

David: there is a different between encrypting the message, and changing
the mime type, as changing the body and putting it in a soap message.

Glen: if you change the media type, you changed the binding. you have a
uri for a unsnoopable message, [...]  you can say: I'm defining an
abstract service that requires the feature.  do we want this concept at
the binding or abstract level?

Paco: if abstract, the requester needs to figure out how to bind it?

Glen: yes.

Amy: will we have syntaxt in the portType then?

Glen: do we want the abstract capability?

Paco: if abstract, you put the requirement on all bindings.

Glen: ditto in Java, you define an interface, classes need to implement
all features.

David: if a service is secure, does it change its meaning?

Glen&Paco: no

Glen: even if you describe that A & B are required, you can send back a
fault asking for feature C as well.

Paco: seems like outside the WSDL contract scope a little bit. so 2
levels: abstract and bindings. is bindings level a feature as well?  how
do we represent them at the bindings level?

Glen: a SOAP module or as part of the bindings. at the WSDL level, it is
part of the binding in any case.  you need some way to say: I have this
soap module available or you need to use this module.

Paco: you assume that at the binding level, you'll be able to match the
abstract features.  it may be nice to have a clear mapping.

Glen: a list of the features and modules that implement those features?

Paco: yes. provide links between the 2 levels.

Glen: worries about repeating information in the spec. the modules are
defined somewhere else.  if you do understand a module, you'll know if
it implements the abstract features.  is it a reasonable burden on the
software to go into the graph dependency of the features?

Paco: it looks like that at the authoring side, you'll have to be

Glen: having the dependencies in a machine readable won't prevent to
understand the module anyway.

ACTION: Glenn to write up S2

Glen: for next time: how do we connect to WSDL and thinking about S7.
Amy: and also how to present that to the WG?
Glen: S2 involves no properties, S7 will have some.

ACTION: Amy to write up some materials for S7
Received on Tuesday, 18 February 2003 22:05:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:41:57 UTC