See also: IRC log
Present: Abbie Barbir, Chris Ferris David Booth, Doug Bunting, Eric Newcomer, Frank McCabe, Geoff Arnold, Gerald Edgar, Hao He (remote), Heather Kreger, Hugo Haas, Igor Sedukhin, Jeff Mischinsky, Katia Sycara, Martin Chapman, Roger Cutler, Sinisa Zimek, Tom Carroll,
Regrets: Chris Ferris, Don Mullen, Duane Nickull, Hao He, Paul Denning, Prasad Yendluri, Srinivas Pandrangi, Suresh Dvadaran, Zulah Eckert
Chair: Mike Champion
Scribe: Abbie Barbir, Tom Carroll
<mchampion> ACTION: Hugo will create a glossary mailing list. WG members are encouraged to use it for glossary discussion and then take consensus to public list for ratification
<dbooth> Heather's slides are at
. Please ignore the broken images. They are just repeats of the
... Heather's slides in PPT format: http://www.w3.org/2003/ws/arch/3/02/mtf-030307/mtf-030307.ppt
<zulah> Is the scribe using IRC? This is an unfortunately 1 sided conversation on the phone and it would be good to know the questions
<MChapman> scribe not on irc
<hugo> Management document reviewed: http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/att-0001/W3c.Mtf.WSInstance.20030229.htm
Agenda 1. MTF 2. Liaisons Discussion Michael: Need help to get rid of rat holes. Appreciate e-mails stating this is helpless. Glossary discussions this mornings, but did not go too far. Need to nail things out. David Booth: With the number of people and view points, volume gets out of hand, frustrating to read. Form small definition task force. Come up with a proposal and come up with a definition. Roger: Need a separate list. Hugo: Like that idea David: Only a change to the process of collecting info Michael: Hugo to start the list. Heather: Needed a specific set of deliverable Did not get the Web Service Execution Environment Still have 8 items on the glossary list. We will talk about the submission, need to talk about the life cycle document, need to start a coconscious process about, we need to talk about charter. This submission is the appropriate level of detail for the document. WSA need to address the management part to be complete. Manageability of Web Services Endpoint (See slides) Not every element of the architecture need to be manageable. Main point that is addressed is the web services end point. Need to address the intermediaries. Security administration is important, but it is addressed elsewhere. Franc: The use of the word metric is not consistent with the scientific definition. Is this a management term. Heather: This is still under debate. Michael: Seems perfectly in tune with the document. Roger: What element means Heather: Element defined in the architecture, end point is used in WSDL Martin: WSDL changed terms. Definition of WSDL is read Roger: This does not sound manageable. So huge range only a subset that is manageable. Heather: We are managing the instance of the service. Cris: No, this is not true, u manage a process. Heather: What are the manageable properties of a Web Services. Roger: Elements are wide, we only looking at services: Frank: Is element a deployed resource. Heather: Problem with your diagrams is that u can not manage description of the service. A port type only is not enough; need to know what he talks. Frank: U got not manage an element until it exists. I prefer the word resource. Tom: Configuration is a big term, provisioning is it part of that. Igor: ???????? Martin: Obtaining data is different than management. Zula: Phone is only one way. Heather: Talking about events. Roger: would a resource management can be an instance. WSDL doc management? Heather: These are general definition. Need to decide in this group what is needed to be managed and then we get a term for it. Martin: In terms of arch is this required. Roger: U mean that u are only interested in web services. Heather: yes, Frank: WSDL relation to a web services, this relation need to be managed Heather: Very hard to divide these pieces of work, need to be careful. We are doing pieces of work where we are trying to manage other pieces. We are not trying not manage what is behind the web services. A lot of the stuff in the MTF doc is more detailed than the WSA arch doc. If the group agrees that the description of the WSDl is also a resource then surely that is also a managble part. Roger: Need to change the doc to state that we are only managing WSA. Martin: but we do not know what are the elements Heather: At this point Martin: Only runtime? Heather: So far we picked the well defined elements like end-points. Roger: U stated that u are managing elements, some elements we do not care about. Heather: No, not true Tom: This is a scope problem, clearly we do not have one yet. This work does not preclude other work Martin: Need to start managing the bits Franc: MTF to decide on which elements than need to be managed. What u did is that u picked one of the things that need to be managed and detailed it. Igor: This is what it needs to be manageable. Heather: we picked end point and then expanded the work. Igor: Has common concerns that belong to other elements. Doc: If I have an inventory system that offers WSA interface, what aspects of that system are managing and how to separate that from the rest. Heather: we looked at what WSDL does Igor: What we are saying that URL count the number of messages and these information. Heather: Have defined a list of questions that need answeres. Heather: Manageability Components A managed element means that somebody is really managing the element. Roger: Does this mean that need to be managed by a web service. Heather: U need to access then thru a web services. Igor: A web Service is managed in the same way like the WSA, a web service. Roger: OK. Fracnk: This should be done as a WDSL requirement Heather: WSDL can do that now. Martin: Need to be careful not to have muiltiple componenet description in wsdl. WSDL can inherit the management interface. Igor: above is one of the examples that they could be used. This is to be consistent with WSA arch. Frank: Need to separate the actually discovery from the actual service. Heather: Apply here as well. Frnack: ne need for a discovber agency Heather: no it is consistent with the wsa requirement. Booth: need to align with the wsa definition. Heather: also came up with requirements, URI for a lot of items. Configuration should be defined. One recommendation is that there may need a separate administration interface. Roger: I do not think that all elements have a URI. A manageable element is ok, others not. Cris: Say a manageable entity. ???: Is a web service agent is mageable ot not. Booth: What parts are not manageable. Chris: like security is a feature that may be or not manageable. Heather: not all instances of agents are manageable. The agent role may be declared as manageable. ???: U need to manage the code. Frank: r u really saying that the description of the interface needs a uri Booth: would not nescesssary means what the wsdl means, corresponds to the target name space in wsdl. Micheal: this is the mother of all trout lake. Igor: The descritpoion of the interface has a clear uri. Heather: Need to resolve if description has URI or not??? THIS IS AN ACTION ITEM. Roger: Need an e-mail about this stuff. Heather: Status: Based on the life cycle report. We needed to make recommendation on metric. Action item: Change Metric to means measurenment. Heather: Requirements for managing end point. Frank: document is very usefull so far. Break, Heather: Need to review arch elements that need to be maneagble. End point was well defined. Here is the glossary definition of web services end point. How this will be implemented, what r the formats are in the doc. What we have is descriptive name of the properties. Some are marked mandatory, need more work on it. We took the list of capabilities that we defined before and come up with the list. The first identifier is the uri, etc..., see document. We have place holder about semantics and information about them. Mike Meha: Would there be a decribtion of things to manage and how Heather: related to the service itself., No Igor: we can run quirires on end points Mike Meha: so we do not know specific metrics Heather u get that from the mageability part from wsdl Heather: we need a set opf requirement of interaction blob Frank: we do not talk about failure Roger: this may not be in the arch Martin: we can say that these are examples of things Heather: some things may be conflicting with the arch. We need define conformance criteriua in the arch. Martin: CAN WE GET THE same level for other. Heather: yes security etc.. Martin: not in that details jeff: are there requirements that affect MIBs Heather: NO Igor: This is that vertical jeff: Web services is a vertical? Roger: Need a process check Booth: I am very impressed with the MTF work. I also agree agree that the purposes of the arch we need to abstract a little bit higher. We need revelant metrics and use for example. We should not state the revelant metrics. Frank: I found the doc up to section 3 usefull. After that it belongs in a separate doc. Martin: agree with that, same for reliability. Michael: for the purpose of this WG we do not need this level of the details. Heather: We took a lot of time for this work. Work requires mageability. It is not good thing to avoid that. Martin: it is the level of details. Michael: how about what we did for chreoagrphy Heather: We have done nothing there, we pushed a new WG. Frank: Taking security as an example, the arch requirements for privacy of communication, the content of the mesaage can be ebcyrpted separate from the header. Message structure should allow that, that all whar we need to put in the arch. Igor: I am desiging a toaster , heat bread, if the toaster is managebele, would we say that it has a control point, this does not mean that it is mageable, what is the level of detail. The WG is saying that the statement that the toaster is magebale, basically what is the minimumj needed. Hugo: Very early I was scared that MTF will go out of scope. I was confortable with the doc. Properties may be easier set that the whole set. The WG set the requirement, ...... Michael: They done their job better that any other task force, Igor: Need to understand the level of the details. Booth: WSA should say that to do management is collect certain metrics. Heather: We have requirements, we should do that. Booth: this is valuable work if we do not put this level in the arch, where should be put. Would a Note be there Michael: Time Is up. Hugo: Border is defined where we have control or not. Tom: Toaster may lead to discussion on magement layer, and go out of hand, for example what is a failed request, etc.. Heather: we defined that in the doc. The requirement on the toaster is how to adjust the heat. FrancK: I mean up to section 3.2 in the doc. Going back to the toaster the existence of the knb is separated of what it controls. If there is a way of managing systems, do we really need it to be a web service. Tom: we need to say that there are things that mange web services. Heather : Moving fwd: See slides for going fwd. Michael: what about the document itself. The glossary etc. Heather: It is in the slides, life cycle etc.., see the submission in the document. Michael: what IS WISDOM IN OASIS, they will use the requirements from this working group in general. Two piecers of work going in there. Hugo: thank the MTF WG. Revisiting the charter, need fixces in the use of the term submission, need to use the word proposal. Heather: we will work on that. Michael: also some work can be submitted as a note by the MTF Hugo: I will submit a revised version (ACTION ITEM) Michael: I think 1. issue of level of details that is needed to manage. 2. where do u draw the line for requirements for a product and the architecture 3. different part of the doc should not have different levels of details. Do we have profound difference Roger: I object to the charter, in particular that they propose the arch of the manageability., etc.. Heather: for the mageability property Roger: This is getting out of hand Michael: What is the delta: Booth: There is a matter of scope. Heather: Need to think about the other elements that are needed. Martin: We need assimilate the info before u do more work. Hugo: If we do that we should half discussion in the teleconference calls Zula: Security and other stuff is not revelant in this work. Michael: Take a poll if management is valuable or not. Yes is the answer, level of details is the issue. Heather: Even for security also, we need to decide the level of details. Jeff: Saying that in order for something to confirm give u the prcosessing time is non reasonable. Chris: we need the architectural requirements to support management. We do not need the properties, may be they can be in WSDL the actual definition of properties can be vertical or other SDO. It is necessary to go down in level of details in order to get the details but what get in the arch will be the bits that enable that stuff. Same with security. Jeff: all this information here, in the MTF doc is .. same conclusion as chris. Igor: management vendors need that. Heather: when we look at this from a manager view, web services is just another thing, for us we need to define what is needed to be magemable.
<frankmcca> ACTION: Hugo will suggest amendments to the proposed management task force charter
<dbooth> Frank and Eric proposed incorporating the MTF work up until section 3.2 into the Arch document.
<hugo> ACTION: Editors to
incorporate MTF doc up to 3.2
... ACTION: MTF to consider section 3.2's future and to work with W3C Team contacts
... ACTION 3 = Editors to incorporate MTF docs (including the latest one up to section 3.2)
... ** BREAK FOR LUNCH **
<scribe_TC> P3P joint meeting
... MikeC going over WSA Goals
<Heather> thanks david
<dbooth> (MikeC describes the main goals of the WSA WG)
<scribe_TC> MikeC: Going over The concepts and
Relationships diagram created by FrankMc.
... MikeC: Privacy is a real world constraint of web Services hence the liasion.
... LoriC: P3P is in the process of being recharted.
<dbooth> Lorrie Cranor, AT&T: http://lorrie.cranor.org/
<scribe_TC> LoriC: p3p wg plans to address the P3P
1.0 issues and use beyond its current domain.
... LoriC: Describing how P3P works
<hugo> P3P specs: http://www.w3.org/TR/P3P/
<scribe_TC> LoriC: Issues beyond http
... MikeC: are sub parties in an information exchange bound by the main party offering the P3P terms and is there a way to communicate that
... RogerC: If a user used an agent to aquire something and data is exchanged is the service provider required to keep the agents information private or the users information or both
... LoriC: the users information is protected by the P3P policy.
... GeraldE: If you don't know who the individual is because of the web service abstraction how does P3P obligation get handled.
... loriC: Thats what we are here to discuss.
... LoriC: There might need to be a document that expains how that get done in collaboration with WSA.
... the p3p is a check prior to interaction
... there is no contractual part to P3P.
... FrankMc: What do you see the req. are for automating the service to service agreements.
... A reference to the policy could be passed
... danielA: there needs to be a set of asertions that are evaluated at each node, RDF like.
... LoriC: if we develop a general way to pass policies the privacy could use that mechanism.
... GeraldE: Multiple privacy policies could become overwhelming as the interactions go beyond point to point. What does the orchestrationg service present to the customer.
... P3P is an asertion but not a form contract, use is agreement.
... ChrisF: information is flowing in both directions and what is the impact to the provider based on the policies of the consuming service.
... P3P does not cover the scope of bidirectional exchanges and is an interesting hypothetical
... MassimoM: recaps the points
... MassimoM: bidirectional support, Service to service vs. user to service, person vs entity/ company. P3P could solve some of the issues and would need additional work. It doesn't mean that it will solve all problems
... WSDL could provide a way to apply a policy to inbound and out bound data
... The issues are revolve more non-technical issues that technical
... The issues revolve more around non-technical issues than technical
... Web services may provide an abstraction that reduces the amount of personal information being transfered.
... GeraldE: How fine grained is P3P
... LoriC: P3P is extensible, and has three levels of grainularity, the third level is whre the extension is made vis a custom schema
... LoriC: The offering serivce may include the references of the other services in the chain.
... RogerC: The does ther service consummer have to go an evaluate each included policy before accepting the policy.
... LoriC: P3P does not have a mechanism for choosing the policy, but a site might have a mechanism to do that.
... MikeM: Sounds like there is some over lap and that we need to have a joint effort on the overlap usecases. Has P3P been in contact with the identity management folks.
... LoriC: Yes, liberty
... FrankMc: Data may have attributes associated with it and the attributes may have to be persisted accross or through the transaction
... MikeC: would anyone be interested in creating the usecases
<dbooth> ACTION: MikeM to work with P3P people to write privacy use cases for Web services
<scribe_TC> MikeM: Steps forward to handle the
usecases work for WSA
... MIkeC: Kick off a thread on usecase that need to be addressed by P3P and WSA
... LoriC: Where do you see the standardization fitting in P3P, WSDL choreography ????
... MikeC: we can only make suggestions
... what about ws-policy
... MikeC: we have talked about looking at ws-policy
... MikeC: The discussion was very informative
... Hugo: there will be many incarnations of policies
... This concludes the P3P joint discussion
... MikeC: Martin what about the choreography stuff
... MartinC: We haven't met yet ther are about 40 registrations
... MartinC: first day is open forum and second day we will start going start creating use cases.
... MartinC there are some interesting things comming out of wsd like MEPs.
... Hugo is the official contact for WSI stuff
... ChrisF: will make his WSI presentation available
... ChrisF: WSI Basic profile
... ChrisF: Soap 1.1 no soap encoding, trailers are disallowedMost spec ambiguities resolved in alienment with Soap 1.2
... ChrisF: WSDL1.1
... ChrisF: limited to use of rpc/literal and document /literal
... ChrisF Skips the remaing parts of the profile
... ChrisF: going over the form of the profile
... ChrisF: the profile is publicly available
... ChrisF: WSI will have a sniffer and analizer to test profile conformance for users
... ChrisF: most of the verbage is intended for vendors
... ChrisF: the profile focuses on a instance and not the tooling
... ChrisF: and the platforms
... chrisF: there is a discussion starting about platform and tooling compliance
... MikeM: Is this what the protocol group is going to work on
... ChrisF: no there will be a BOF that will result in the board becoming convinced platform and tolling is important.
... ChrisF: there is some delay unti the 1.2 spec become available
... Hugo: are there any conflict between the decision between the basic profile and the decisions made by XMLP
... hugo: we need to talk about publication
... MikeC: maybe we should see how far we are from xmlspec we are
... Hugo: we have missed the publication heart beat.
... FrankMc: should we publish by the next F2F?
... Hugo: we need to get a draft out in 2 or 3 weeks.
... DavidB: will call for definitions of asyncronous on the list an agregatea and present them to the group for nitting.
... RogerC: Can we let people rank the definitions
... davidb: yep
... MikeC: we will focus on the editors and getting them assitance, MikeC and RogerC volenteers.
... FrankMc: we are having issues with CVS
... Hugo: will work on the CVS issues.
... ChrisF: you can send the docs to me I have a key
... MikeC: would like to progress the document to a publishable state (highest priority), then resolving the MTF issue.
... Hugo: Davids proposal for resolving the the definitions is a good approach should we do tha tfor reliability.
... Meeting Closed