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

PFTF minutes 20020203

From: Philippe Le Hegaret <plh@w3.org>
Date: 06 Feb 2003 10:44:28 -0500
To: public-ws-pnf-tf@w3.org
Message-Id: <1044546268.28618.361.camel@jfouffa.w3.org>

Participants:
 Glen, Sandeep, Jonathan, SteveL, jean-jacques, Don, DavidO, Philippe,
 Sanjiva, Paco

Regrets: Amelia

Glen: Possible topics:
 - review proposals
 - Amy's agenda
 - review requirements

Jonathan: Would like to see problem statement and why
features/properties addresses. Would like summary of benefits

Possible items:
o specific use cases and examples
o list out advantages of this approach
o disadvantages of not having this facility
o comparison with feature/property approach vs. straight WSDL extension
  mechanism

DavidO: Would like to see use cases / scenarios

Don: Question of joint / WSDL
Glen/Don/DavidO: would like to see joint
Glen: refers to proposal to Arch
Glen summarizes
 http://lists.w3.org/Archives/Public/www-ws-arch/2002Nov/0085.html

DavidO : refers to WS-Policy
Glen: Sanjiva also mentioned -- possible overlap...
Glen: hope is only one way to do this stuff

DavidO: still concerned with overlap

Glen: SOAP 1.2 already here now with features/properties - expect people
to write and follow those guidelines

Paco: As one of authors of WS-Policy...  don't see overlap --
complementary. pushes forward to have machine readable declarations. did
not feel comfortable with just having ID without pointing to something
concrete.
WS Policy:
ftp://www6.software.ibm.com/software/developer/library/ws-policy.pdf

JJonathan: what is concrete form?

Paco: container for metadata and extensions + references - minimal
framework -- close to bindings

Sandeep: When defining scope of task force -- what is the boundary....

DavidO: When talk about relationship between Policy and our work -- use
use cases to drive and show differences. need to make separation
complete

Glen: agree -- would like to end up with something where there is a
single framework -- from low concrete all the way up to abstract

DavidO: we have URIs -- but need to show *reason* why there are they,
and how they are used....  Modivation is to show usefulness.  show at
use-case level

Jean-Jacques: concrete aim for the WSDL group -- requirement to support
SOAP 1.2 features/properties

Jonathan: seems somewhat abstract to me -- do we need something concrete
to support features/properties?  Or extension mechanisms?

Glen: explicit support useful - write simpler code -- without mapping
layer

Jonathan: Concrete action items?

Glen: talk specific scenarios on this call? Describing a service that is
req/resp over HTTP and some other that doesn't support. secure transport
-- either by natively or not. Reliable messaging.

DavidO: Need deliverable document -- required as output to do this and
assign editors

Glen -- may be able to have some cycles

DavidO volunteers
Paco -- would be happy to help
Amy/Don have some cycles as well

DavidO: mechanics -- separate mailing list?  

Philippe: separate mailing list - takes action item to create such list.

DavidO: need links from the two groups to mailing list and documents

Philippe: can give what the group wants. access to CVS as well

Contining USE CASE discussion

Glen: high level policy statement that does not affect anything on the
wire

Paco: Some policies are important, but not seen on the wire -- like
that.  (regarding the TF mailing list, please note that this is an early
proposal and may vary a little bit).  Use case of restricting /
defaulting properties

Glen: time extension -- wire representation gets affected, but not by
something described in WSDL -- spec says if foo, then blah...

DavidO: Where in the software stack is the knowledge whether a features
is supported / fulfilled?

Glen: i can take a wsdl that doesn't include any about security, but as
a client, I can do secure stuffs and it's to the server to fault.

Sandeep: do we also look at (in this group) the request can come secure
and the response is not secure?

glen: so do you write a different feature spec for each combinaison or
do you have optionality? if the secure spec describes one-way operation,
do we need something special to have it both ways?

sandeep: if more than one encryption can be used for different messages,
does it make sense to describe policies at different level? will be a
challenge to describe this kind of extensibility.

glen: it is possible to describe a feature that doesn't make sense in
some context. potential use case: asymmetric feature.

glen: another item: composability. 2 differents features that are being
used and they somehow (?) each other.  consistency accross feature
naming, like a user name for example.  authentification and
authorization feature which the same concept of user names.

Jonathan: next step?

Jonathan: we have a list of scenarios. teleconference next week?
Received on Thursday, 6 February 2003 10:44:35 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:17:44 GMT