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
http://www.w3.org/2003/ws/arch/3/02/mtf-030307/mtf-030307_clean.htm
. Please ignore the broken images. They are just repeats of the
text.
... 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
<Roger> hi
<scribe_TC> Introductions
... 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
... LoriC: is for communicationg the privacy policy between the
entity and the end-user
... 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.
... Hugo: with web services one might agree on the privacy of the
information with the first service in a chain of web services
invocations how will the privacy policy get propigated across the
chain.
... 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.
... LoriC: P3P would be the basis from which extension will create
a mechanism to pass the privacy policy, possibly an attachment, it
is not clear what the policy will be attached to.
... 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
... DavidB: P3P allows previously human readable Privacy policy to
be machine readable. web services may be benefited by the fact that
the privacy policies are machine readable.
... ChrisF: A service offering aservice is responsible to ensure
that the privacy policy is enforced down stream.
... 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:
... 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