Regrets: Dave Hollander, Katia Sycara, Ugo Corda, Zulah Eckert
Scribe: Gerald W Edgar
<Scribe> ACTION: (See also pending actions listed in the agenda) [PENDING]
- Action item to ping Mike Mehan on privacy. done
- Zula and Heather to draft management note to consider at next F2F. Pending
- Semantics work (DAML) Discovery - Pending
- Katia to mail Abbie about text. To attach the messaging and policy levels security have to be in the interaction and policy section the plan is to use the two diagrams. then fill in the text. To be worked next week. Pending
<Scribe> High level action items - needed to declare victory
Discovery needed David proposed text Paul Denning proposed ideas.
<David> - posted an updated section1.5.6 overall process for
engaging a service. the overall framework where discovery fits in a follow up
from the face to face. he took an action item with work with others, martin,
zula, Katia for a consensus. It is not committed into CVS yet. there is a
proposed replacement. It is not discovery per-se but a larger umbrella.
<Mike C> - how to discover a service
<David B> - Discovery is step one.
<Mike C> - Paul proposed text on discovery
<Paul> - discovery based on thoughts stemming from UDDI, and another view where search engines find WSDL files. Perhaps an "index" semantic web based perhaps? Search engines find things and index them. In our architecture there is no index. Perhaps to tell the index what you want to find. To harvest what is exposed on the web., Use a query language to express what you are interested in.
<Mike> - a Google like index, not a registry. related to an automated reasoning agent not a registry or index, a knowledge base. UDDI is one example of discovery mechanism Goggle is another.
<Mike M.> paul suggested a spider,
<Paul> - For web services a spider does not apply in that there are no links.
<Mike C> do we really need a network of web services separate from the rest of the web? Links in the general web might link to WSDL documents. These links would lead to other web services.
<Scribe> RDDL was mentioned - links for various pieces of information.
<Mike C >- This has more meta data for links than HTML
<Mike M >- one could imbed HTML in the WSDL file.
<Paul> observations from paul about how to discover services.
it is higher level, but there is no distinction between the UDDI or Google approach.
<Mike C> - To use various examples of discovery mechanisms. to query the discovery service and get a description of the service. in the architecture we would not distinguish between uddi, Google or reasoning agent.
<Mike M> - distinguish between manual and machine discovery. for a human, there are different needs. There is also an issue of trust involved, with a human doing the discovery, people make judgments. They trust their own judgments.
<David Booth>. do we need to distinguish between machine and human discovery?
<Mike M> - standard for machine discovery. non-standard for people to use.
<David B>. the reason to distinguish is that machines can not do all the things that people can do
<Mike M and David B - discussion about trust of mechanized interactions versus trusted human interactions.
<Paul> - this is outside of scope [of the WSAG charter]?
<Mike C >- to We need to be aligned with Semantic web.
we do not want to get too far into the details.
<Mike M > - to query a registry and receive results is in scope, to bind to those processes perhaps is not in scope. criticisms as written - it is not given enough emphasis on the autonomous discovery.
<Paul.> notion of Proxy - a discovery proxy. various UDDI servers - an issue of federated servers. an agent that knows how to find the services. This would be needed in this environment.
<Mike M> - the discovery services would be federated.
<Mike M>. people's input is wanted - what should be done differently.
<Mike C> - anyone with issues please bring it up .
<scribe> Intermediaries and the
soap/WSDL mismatch issue.
<scribe> Hugo is working this. the addressing part of the issue. SOAP does not have the final receiver. there is no description of the intermediaries. He has had no time to get this done. he asked for a back-up.
<Mike C> - he would like to be volunteer for the back-up but he would need some jump starting.
<Hugo> - he will try to get is done tomorrow.
<scribe> Mike C to Mike M - thoughts on intermediaries.
<Mike M> - thoughts on this. proxies or gateways for SOAP / WS messaging. he will revisit the intermediary text.
<Mike C> - to focus on soap intermediaries.
<Mike M> - not to emphasize web intermediaries.
<Mike C> to relate the two kinds of intermediaries [scribe: web services and the web].
<Mike M> components that are restricted devices.
<Mike C> - to give context.
<Mike M > - Draft early next week on privacy and policy.
<scribe>Security Model Abbie, Frank, Katia.
to work this.
<Frank> - This is still pending.
<Scribe> The larger issue of reliable messaging comes up in all sorts of conversations. Is there anything we can do or is it too political;? beyond the formalisms of a reliable message.
<roger> is reliability a political issue?
<Mike C> - back 2 years ago - Part of our understood duties were to tell the W3C what needs to be standardized.
<Mike c >- We should define what should go into reliable messaging.
<Roger> - we need to define the architectural requirements for reliable messaging.
Hao - owner of reliable messaging.
<Hao> yes, but after f2f he was to work with Frank - but he had not heard anything from frank.
<Mike C> - How wrote useful text with a better understanding what is needed is to harvest minutes form that meeting
<Frank> - we could do something, no problem with how to have a "first go at that" reliability needs to be addressed before we can declare victory service and message reliability needs to be addressed.
<Hao> - basically a guaranteed delivery of a message from one place to another. if we look at TCP/IP - has various aspects of reliability. that is the difference between TCP/IP and Message level reliability. TCP/IP does not address different hops.
<Frank> - how the message is acurally not part of soap.
<Roger> - there seems to be some confusion.
<Mike C> - How to draft text. if some transport even handles reliability, the message has to go from ultimate sender to ultimate receiver. we can not rely on the transport layer. In putting this in the larger context of reliability. reliability in transactions, reliability in resource or policy model. we do need to tie in the larger issues of reliability. the other thing is the concept that reliable messaging is not magically getting the message there with complete certainty, but also the state of that message. this was discussed in the face to face.
<Mike C>- any other points about reliable messaging?
<Mike C> anything else on the "mists to do to declare victory"
<Hao> - what about message exchange patterns?
Policy oriented Model
<Mike> - Hugo - the policy oriented model - is it ready as it stands?
<Hugo> - let's talk by - not just a review of the policy
policy how can the policies and requirements fit in our document. from
Martin, how to existing specs from the real world fit here? WS-Policy
requirements for services. out concept is different, Hugo examined to
find how they are related. some changes are suggested.
Who do we want to talk about capabilities and requirements in our documents - the three paragraphs would fit in our document. to support some features and not others. Service and agent requesters. to determine the use of some of the web service features. the description of the descrtiption of the requirements are imporatant
The behavior of agents capabilities and requirements will constrain
the behavior of agents. permissions and obligations.
Permissions the allowed actions of agents against a resource. there was a mix or how the current documents is uneven. permission should be renamed capability. hugo said he hopes this is what Frank had in mind. for an obligation - this could be a requirements.
<Frank> - capabilities and requirements are not the same as permissions and obligations. i.e. capability for encryption - a requirement for encryption these are separate.
<Mike C> how does this relate?
<Frank> - [there is] choreography - not obligation or requirement
<Mike C> - If a message exchange pattern is published, don't the parties agree to that pattern?
<Scribe > A discussion about obligations and requirements. for a choreographed pattern
<Frank> - capability - not a permission.
<Hugo> - a sequence of permissions. to remove the portion for choreography.
<Roger> - requirement and obligations - have a similar relation as delegation and proxy.
<Frank> - you are obliged to do something.
<Mike C> - a distinction - cap and reqquirements do not depend on an agreement - nothing is an obligation until the parties agree.
<Frank> - permissions are two sides of a coin. need to capture cap and requirements
<Hugo> - is this belongs in the policy section,
<Frank> - to capture a common threat, to constrain behavior. subject, object target. we need to sharpen the policy if we can do this - it would be useful to capture requirements and obligations.
<Mike C> - how to continue.
<Frank> - suggest to elucidate the capabilities and re and see how that fits into the rest.
<scribe> Frank will take the action to go forward and write it.
<frank> - hugo and frank to write this.
<Mike C> - workshop on WS - Policy
<Hugo> - related to the topic above. W3C has been thinking about WS-Policy - wrote to WS-Policy specs to participate in a workshop to create a wg on capabilities and requirements. Sent the e-mail yesterday. position papers will be invited, the workshop has not been announced.
<Roger> - WSPolicy - a competing set of standards?
<Mike C> - not to our knowledge.
<Mike H> - related to DAML-S to go beyond WSDL
Wraping up the Document
Mike C> issue on how to wrap up this document.
two high points. no sentiment for simply extending this group. this raised the issue of the normative form for the document we produce. we could make it a note. It will take more effort to make this a W3C recommendation.
<Frank> - use this as a clarifying moment to get this thing finished. it would be help full to know what plans other W3c groups have for our effort.
<Hugo> - do some architectural work in the spirit of the TAG. As of today we have not decided what the best thing to do next would be. By january we will have a clear view of what to do.
<Roger> - at the last AC meeting WS AWG was voted very high in importance.
<Frank> - it would be useful to encourage people to
state what should be the next steps.
Summary of Action Items
ACTION: MikeC to ping Mike Mahan on the status of the privacy work he did. [DONE]
ACTION: Zulah and Heather to have proposed Management Note draft ready by F2F[PENDING]
ACTION: dbooth to reference current semantics work (DAML-S, OWL-S) in discovery section [PENDING]
ACTION: Katia to email Abbie about pasting Abbie's whole text into the document as a starting point and to force people to comment on it [DONE]
ACTION: Chairs to put policy model update on F2F agenda [NEW]