- From: Philippe Le Hegaret <plh@w3.org>
- Date: 06 Feb 2003 10:44:28 -0500
- To: public-ws-pnf-tf@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 UTC