See also: IRC log
Present: Abbie Barbir, Chris Ferris (remote) Colleen Evans, David Booth, David Orchard, Doug Bunting, Eric Newcomer, Frank McCabe, Geoff Arnold, Gerald Edgar, Hao He (remote), Heather Kreger, Hugo Haas, Igor Sedukhin, Jeff Mischinsky, Katia Sycara, Mark Jones, Martin Chapman, Paul Denning, Roger Cutler, Sinisa Zimek, Tom Carroll,
Regrets: Chris Ferris, Don Mullen, Duane Nickull, Hao He, Prasad Yendluri, Srinivas Pandrangi, Suresh Dvadaran, Zulah Eckert
Chair: Mike Champion
Scribe: Colleen Evans, Gerald Edgar
-No objection to publishing minutes Mike recently posted. -July F2F logistics posted [1] Refactored document review [2]
<scribe_TC> MikeC: we should keep in mind the
comments about the web arch. document in the meeting on Wed.
... MikeC: We need to make the doc. rigorous.
... MikeC: We also need to consider the reader. what can we say
that will move us toword people seeing this document as a benefit
to the industry
... MikeC: what else do we need?
... EricN: Common terms and definitions
... MartinChapman: Diagrams
... MikeC: tease out the architecture by example
... Katia: what are the trade-offs.
<hao> could you guys speak close to the phone
... zekim, +??P3 is hao
<scribe_TC> Abbie: What is compliance and
consistency.
... EricN: examples that are close to the terms.
... MarkJ: We need to describe the relationship between the terms.
Trying to show how the parts fit together.
... EricN: We need to layotut the principles and then apply the
tecnology to be consistent with the principles.
... MarkJ: We need to ensure the multiple specs fit together
(Choreography SOAP WSDL ...)
... MikeC: Who is the target reader, what is conformance, it must
bring together what we have out there today.
Discussion of document goals, etc. We need to: -Keep in mind comments on the Web architecture document made in the Tech Plenary on Wednesday. They apply to our doc as well. -Make the document rigorous -Consider the reader. What can we include that will result in people seeing this document as a benefit to the industry? -Ensure there are common terms and definitions -Describe the relationship between terms - illustrate how the parts fit together -Add diagrams -Define what is compliance and consistency -Include examples that are closer to ther terms -Layout the principles and then apply the technologies to be consistent with the principles -Ensure the multiple specs fit together (SOAP, WSDL, Choregoraphy...)
-definition of service is in the glossary Service block diagram -Agent is a piece of software -Definition of service is in the glossary -Without technology how can we measure conformance? -WSDL 1.2 terminology changes this week, how do we align? -How does ebXML fit in this model? : If our architecture is so abstract that it equates WS and ebXML, it is useless because they don't interoperate -Point about our conformance with WSD and how we track with what they do -Not intended as a complete diagram (nor are any of the others proposed at this point) -Question of context, still under discussion -We're not building abstractions - reality is we have to coordinate with other efforts (e.g. WSDL) -Difference between concrete technology and the abstract architectural representation in WSA. We want an architecture that lasts longer than a specific technology or technology set. Concepts and relationships diagram -A different take on the architecture than the service block diagram -Difference between agent and service, why do things go to each? -This is a def of a service - defining a service in its relationship to other concepts represented in the diagram -Some concepts that aren't covered in WSA itself are represented in the diagram. They are required to properly embed the WSA in the outside world (e.g., goal). -Focus is on service - there may be many links that aren't represented -Does the notion of service coincide with WSDL notion of service? Not entirely - WSDL is very endpoint centric - from description point of view -How do we reconcile concepts that are different, e.g., MEP in WSDL vs. MEP in SOAP -ACTION: Group: Make sure concepts are in sync across three specs (WSD, WSA and SOAP) -ACTION: Editors: Reconcile this with new terminology WSDL uses. -WSD is no longer using MEP - just 'pattern', so it will be possible to represent both. -Agent, deployment and service - can they be combined? -Difference between agent and manageable elements - more things deployed than systems, e.g., descriptions, etc. Managing active and non-active entities. Difference between thing that provides a service and other things you're managing. - Difference between agent and service - service something that has all these attributes associated with it, but the engine that is requesting and performing the service. Notion of reqesting service - engine behind thing requesting and thing offering, there's a relationship there. We may not need this distinction in the long run. -Is an agent a program - yes a runninig program. Agent can provide more than one service. Service includes interface, that is not part of the agent. -RATHOLE - difference between agent, deployment and service -REVISIT - management -Conformance - text representation relating to diagrams. Would be nice for diagram to indicate MUST and MAY relationships in final diagram Concepts -Difference between concepts and glossary? Glossary less formally defined and doesn't define relationships. -RATHOLE - MUSTs and SHOULDs aren't really in this section - focusing on the framework right now, will revisit this later. -This is a text representation of UML or a diagram? Might it be better represented that way? Or a table? Difficult to read through this. -ACTION: Martin to recast sample parts of this section in UML - (coffee break) -Martin's UML diagram: http://lists.w3.org/Archives/Public/www-archive/2003Mar/0015.html -David Booth explanation - service is an abstraction of agent [agent - the actual software - soap processor, app, etc.] - service has a description -One suggestion - main text have MUSTs only where universally true (across technologies) - have profiles where MUSTs are more detailed based on technology set. -Currently if the doc doesn't say MAY, then MUST is implied - should be explicit -ACTION: editors: Make MUSTs explicit and MAYs implicit (reverse current representation) -Alternate to profiles concept - use examples - map particular technologies Stakeholders' viewpoints -Working title, captures intention of this section. Demonstrating how the WSA meets the requirements. Entry points for a variety of audience perspectives or viewpoints. -Maps goals / requirements to how met in WSA Issues with the document and outstanding items / work to be done -Need to go through again - make prose real, coherency, check defs throughout, how to interrelate things throughout doc (e.g., management), identifiers (what has one and what doesn't), flesh out features such as security, reliability, etc. -Still talking about organization / presentation - need to work out details of content, but need group agreement that this is the way to go forward first. -Relationship between concepts and glossary - problem with defining the same thing in two places. Could say for things that are defined by concepts - those are defs and refer to them in glossary. Or have a link in the concepts section to the glossary. The latter would allow other groups to use the glossary more easily. -What do you get from relationship section that isn't in diagram? Could the diagram be made more explicit to cover it and not have the text? Would clutter the diagram. -Need a process for capturing details on concepts, etc. without raising formal issues -What happens with respect to glossary and diagrams? Implementation detail, but currently no diagrams in glossary - refactoring of main document -W3c tools to extract glossary, etc. are forthcoming that we can use so we can work out the mechanics of cross referencing out later and avoid duplication of definitions. -Add simple diagram up front, expand as doc develops, rather than starting with comprehensive diagram as currently in doc. Ease the reader in. -More details, examples, devil in the details, etc. -We will have to drive this style through the other groups -Process for how we declare a set of text ideas as complete - nail it down and close comment. -Make sure there's isomorphism between WSA and existing specs (SOAP, WSDL), and developing specs (WS-Choreography). Dialogue with groups to make sure this is what they have in mind -Question to group - straw poll - approve this organization. Group agrees this is a good organization and template to use going forward. -Strong consensus this is generally a good direction, considerable sentiment that the devil in the details we need to nail down. Editors have the go ahead from the group. Stakeholder's section discussion: -Mix of mapping to requirements doc and stating other non-defined requirements - should we map to requirements - reference them, etc. -Should linking go the other way - from requirement into this doc -Do an audit on requirements / consistency check, but don't link. -Why should someone just interested in this doc be distracted by the requirements linking -Give editors discretion to make it readable, useful, etc. -Put link in square brackets as a placeholder for now - could be eliminated later. Concept of stakeholders in doc discussion -Generic vs. specific content -Who is the primary audience for this spec? Audiences have different timescales and levels of urgency. Most urgent are other groups working on specs. Therefore, we can't afford to be too abstract. More rapid grounding in SOAP, WSDL, etc. going forward. -Our doc should give equal treatment to w3c and relevant OASIS specifications. -Do a general architecture - issue of chaos of profiling in combination with different versioning, etc. (e.g., SOAP 1.1 vs. SOAP 1.2, as used by different groups such as WS-I, etc.). -If we take this to logical conclusion - we'll end up describing everything. Rather have a more reduced set of actual technologies rather than a larger set. -Summary - most important audience spec writers, should focus on providing value to them. But not confine to spec writers from w3c. Explanation of agent and service discussion -Message has a recipient and a sender. Actual sender and recipient are agents (particular piece of running software, written in Java, C++, etc.) Service is an abstraction above that running software or agent. Service has description, has semantics. That's constant even if a particular agent is changed (e.g., change a Java agent to a C++ agent). -Exchanges coming off wrong box (should be agent rather than service). Mixing type and instance. -Question of term agent to represent the running software because of other uses of the term agent (e.g., in management, web community, etc.) Nowhere is it generally understood to be a blob of code. -Difference between agent and deployed element. There are other deployed elements that aren't agents such as descriptions, documents, etc. -ACTION: editors - rethink this and propose something in light of this conversation. -Service interface and service implementation? -Part of the reasoning behind using agent is that it resonates with other communities. Use it in approximately the same sense it was used in the Web Architecture. Use of UML discussion -Martin's UML diagram [4] -Have both diagram and write up? -Discussion about labels more clearly defining relationships -Need capability to represent different levels, e.g., service has an identifier, Web service has a URI as identifier. -Issue of tools - proprietary considerations, capabilities, etc. -Not an either / or using the other diagram (concepts and relationships?) vs. UML. Both are good. Suggested we keep the text as well (three representations?). -Are we going to use a formalism for architectural modeling, what, tools, selection, issues, etc. We've been waiting to have this argument for some time, and we should now. We should be practical in tools, trade-offs, etc. UML is widely accepted in industry. -MTF group used UML and it worked out well. From simple to more complex -Need to start layering these pictures, start out simple and build. Zooming concept. Like precision of UML. -Conclusion: ask editors to explore use of UML tools where appropriate - may be overkill for high level diagrams. Want to keep at least one diagram that has everything on it. (lunch) [1] http://www.w3.org/2003/ws/desc/3/05/f2fJulyLogistics.htm [2] http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/0038.html [3] http://lists.w3.org/Archives/Public/www-ws-arch/2003Mar/att-0061/wsaRefactor.pdf [4] http://lists.w3.org/Archives/Public/www-archive/2003Mar/0015.html
Agenda review- For the first half we will have break-out sessions to address issues people are interested in.
the topics:
WSDL Properties and features model what do the part do and how they relate.
Relations of WSA and ebXML (Sengupta)
Mike C. has an interest in what parts of ebXML intersect with WSA.
Web Architecture relationship (well traveled ground)
There was a question about security, but this is not a break-out, Abbie will lead that presentation to the group
Call for other topics.
Policy and expressions of policy (proposed by Hugo) - how it relates to everything else.
Proposal for holding the sessions in sequence – about 45 minutes each.
Discussion on the break.
Arijit Sengupta will start- from the chair we want to align the W3C efforts - where we can we want to incorporate ebXML. To address things like the OASIS effort on reliable messaging. Some of the lower levels of this architecture are aware of the business level features. Rodger Cutler brought up about wanting to understand CPP and CPA, in order to get the picture of what is going on.
First a disclamer. Sengupta came as an observer - not to present. (laughter all around) There was a comment we can share our mutual misunderstandings. He starts with a single slide. Sengupta said he can not go into too much detail. He states that he has to keep things simple since he only has 45 minutes. There was discussion of the convergence of standards. Rosettanet was mentioned. They have adopted a small part of ebXML, ebXML has no desire to develop the base level technologies, rather than develop competing technologies. In the case of WSDL - some of the ebXML wanted was more complex - business oriented. in 2002 Barcelona, how can they get where they want to go. They want to use W3C. There was a comment that end-to-end non repudiation, and reliable messaging are needed.
For technology infrastructure --ebXML has no desire to develop the base level technologies, rather than develop competing technologies.
Business protocol messaging --In the case of WSDL - some of the ebXML wanted was more complex - business oriented. At the 2002 Barcelona meeting, they stated they want to use W3C.
Collaboration profile and agreement -- CPP/CPA, ebXML, WSDL,
CPP - "what can I do?" this is more than WSDL. WSDL describes one point.CPA - Security, transaction, connectivity, other requirements. Describes the two sides of the connection.Both include available elements of SLAs for ebXML messaging a framework of extensions to describeWSDL is a framework; CPA is a more detailed instance
Registry Repository
ebXML, RegRep, UDDI (difference between registry and repository)
Business documents, messages
RosettaNet, OASIS BODS, core components to be leveraged.
Business process definition
ebXML, BPSS, WSDL business process stgandards - 5 or 6 in the last year.Choreography will fit here.BPSS lets you write down the process - such as purchase order. send a PO, get a response and then to fulfill it.What is the process and SLAs that run across the whole process.Can a CPP and CPS for say adding two numbers - yes.. a simple request reply. but this is not a BPSS. The important thing was to describe the process and define it clearly. This resulted in the BPSS.
At this time people were asking how can the describe the relationship between W3C and EBXML.
There were questions at this time about business process content.
Question of design time and run time.
Can you do the Hello World with ebXML? Yes, the stack builds value but you can use only what you need. What is the minimal stuff you need to do? Why use ebXML?
When you need further services. Once you need all these business requirements, then you need ebXML. You may not need this for the simple things.
Are the agreements [CPP/CPA] , machine level agreements or are they human? CPP/A are not legal documents. Two CPPS could be used for finding common agreements. The legal part is people. [Rodger] There is a question of performance - not for simple applications - automated applications through CPP/CPAs to enforce SLAs for example. The issue is not the message, but the size of the infrastructure. [Sengupta] \ This may not apply - not for high performance. [Mike ?]
A question of ebXML governance – Mike C - is there a coordinating committee. [Sengupta] yes, there are several committees.- JCC and Architecture committee. The technical group has advisors. The subgroups have their own chairs.
Is CPA always bilateral - noting to prevent multilateral - but Gupta is not sure if it is written into the spec. their scope is the business problem. One way may be to break it down into sets of transactions between two.
Chorography problems in general. Chorography may be able to use the concepts from BPSS, but not the words. to make sure we are aligned with what is going on in the world. we do not want to create another ebXML standard to have to explain it to the world. There is a discussion of the IPR differences between W3C and OASIS. We do not want to have multiple standards.
[Rodger Cutler] How much is this being used? – There is a steel network- but not through all the layers of the stack. Is money flowing? Various VANS are using CPP/A internal hand-offs. where it is used more? Europe and Asia. not seen as a US standard. Not a vendor driven think. EbXML is seen as less of a threat. There is a single European thrust. The US Biohazard effort will use this...
Is WSA using ebXML? Not at this time, but it is being referenced. In the last year, there will be a lot more use of ebXML.
ebXML standards work together, but they are not all required, they are not mandatory , The ebXML group wants to work with WAG.
Mike C.- wearing chair hat –we want to overlay our work with what ebXML is providing. We do not address business issues in this group.
ebXML is a web services using the general definition. this is a services stack. at the abstract level ebXML is compliant. in the details there are differences. Rodger articulated the to have an architecture which is a services architecture to encompass ebXML and an other one that encompasses the W3C architecture. we need to say how this conforms (or does not) to our architecture. there may be multiple architectures that may not be interoperable, but if there is a base architecture that can be use to map provide a gateway from one architecture to another. with multiple existing technology bases a common architecture may provide the gateway. We need to have both architectural interoperability and specification interoperability.
At some point we will go to final draft, and we need to articulate that we do not contradict this (but this was questioned by others.) Doug- how many architectures do we have to be congruent with? Answer: we may need to be compatible. We have already looked a fair number of architectures -
Two main things - ebXML worked with OAG and STAR have committed to use ebXML. ebXML does have a significant install base. They want to collaborate with us. How we can use this for heavy-duty stuff. Common questions - how does this relate to web services and how does this relate to ebXML.
Ultimately is it the task to WSD to describe features in WSDL – the idea came from SOAP – features could be in the header or in the binding .
Who is on the task force? Colleen.
[David Booth] The definition of feature is in the concepts and relationships. The abstract idea from the SOAP group. A feature is a collection of related ideas that has a realization. This was discussed at the WSD meeting. It is something that has a dual purpose for message exchange patterns –and WS policy the basic idea is to identify an abstract property – such as security – Some service needs to say that to interact you need some level of security to be identified by a URI. That service requiring security can be indicated somehow – for binding – that you are using HTTPS – that binding could say I give you that amount of security indicated by that URI – when you use that URL with HTTPS you have the security. Otherwise, you need to provide that security in some other manner. The feature is identified by that URI. If the feature is identified as using 3DES how would HTTPS URI feature provider indicate that it provides that feature. Requirements and providing are matched. These are matched by URI – a mini dependency and contract. This is a way to factor out what is needed. The idea is it would be available for everyone who chooses to use it.
Who defines this? – When do you describe the service. [Katia] The ebXML may have already done this. [Mike C] Where would this go? This is not always a late binding. To matching the need and providing this. The abstract part and the binding. Sengupta – ebXML May have this. This is not a negotiation. The WSDL may describe the need for security. The binding may enable satisfying this requirement.
If you want to put together a package for a particular service, there are different aspects to describe. [Sengupta] this describes a situation on the board. It is about how the WSDL description is factored. Describe the service – with several ways to get to the service. Advertise the capabilities, then the requestor satisfies the requirements.
Are we at a high enough level here? If pointing to a feature or a URI that is the description. Are we at implementation level?
What is the gap between features and properties? These may be competing mechanism for describing features. WS Policy – which some people saw as proprietary, from IBM, Microsoft, and BEA. There are specifications on the IBM web site. Policy attachments, security policy, and other policy – it can be used for any policy description. If Glen’s proposal {WS- Policy} gets through this there is no other need for other policy work. All of these are working with existing standards. Not all description is being put into WSDL.
Action item – to describing the relationship of WS policy and our effort.
To work within the framework from this morning, but to find how this relates to that.
This does not reflect the core of features and policy. [Frank] There is a need for features and policy., but security is only one of the properties we are discussing. They are trying to extract the idea of relating things together. This came from SOAP headers, there is more there than meets the eye. Requirements and implementations. An abstract property. To relate the realization of needs and implementations.
We need Colleen and David to resolve these issues.
Action to the chair to resolve this WS-policy interaction.
To describe the relation of features and properties, as well as policy.
In the morning – we agreed on the framework
This afternoon to get work with ebXML – we need to harvest the most important work. It is not that we need to do all the work, but so that we can use it.
Security
Make sure we know what are the concepts and relationships, and who is doing what.
Abbie
Requirements
What is needed? Authentication, authorizations, confidentiality, integrity, non-repudiation, controlled access integrate with Enterprise security policy, end-to end, and other aspects of security. {Auditing was mentioned}
OMA web services stack
The stack includes SOAP and security is on top of SOAP.
TLS/SSL protocol
He described what SSL/TLS provides but point to point, not application specific. Only the server is authenticated.
SAML
XML based token based protocol. SAML is one algorithm available.
XKMS
This integrates PKI with web services. To distribute and verify keys.
XACML
Communicating policy information
XML Signature and XML Encryption
Message itegrety and confidentiality
Some thoughts about SOAP
WS Security ResourcesAdd extra headers. To encrypt and sign the SOAP.It was stated that there is an inability to apply XML schema validation to a soap envelope and contents.Complex specification, inherits HTTP and It’s security holes. People have assumptions that are not true (HTTPS is not particularly secure)You really need a layer for more and better security
Discussion
WSA and WSS need to see how other requirements affect security.
There was a discussion on http security holes. [Hugo] HTTP is not bad or good; it is just what we are using. Soap has the same vulnerabilities as the HTTP server it is implemented on.
[David] Is SOAP more vulnerably then other “normal” targets of DOS.
Does the WSA need to address security –
There wqas agreement - yes - to help the reader understand that is going on.
We need the framework of risk analysis of threats and vulnerability. There are properties and trade-offs. We need to describe the tools to have a secure web services deployment. To reduce risk and not remove it.
The document should have a pointer to other topics on security. TO enable people to create secure web services. We need to indicate security on the architecture diagram.
Katia- to have the security related concepts in the diagram. How they get achieved. The interrelationships need to be explicitly stated.
Security may be any of a service, a property, or a quality.
How do we move forward on this? Appoint an editor to reformat this to fit in the framework. Martin said these things are tradeoffs. This is a framework to address various “ilities”. If we look at the way management is being looked at – there is a lot of core concepts for management, the same thing can be done for security.
Abbie – action item nail down security for the framework. Mailing list should be archived and public. Task-force-list.
Hugo – action-item create the mailing list.
Security discussion complete
General issues – Mark Baker. Closed
Sent to comment list, but not the issues list.
We could resolve then by sending a response of “we do not consider this an issue.”
We need to clarify the ISO and the web services stack – we should clarify that we do not consider this an issue. We will say that the ISO stack informative or normative because everything we are doing is in layer 7. Martin – when we talk about protocols – there are things below the SOAP level, but it does not affect our work. There is no benefit in articulating this because it does not impact our requirements or architecture.
David Booth – we should put this on the issues list and then close it.
For the issue of misusing the transport term – to be closed the same way.
Hugo – Reading Jeff’s clarification – in the XMLP group – it was called the “underlying protocol” for SOAP it was determined to use this.
What is A priori? This is considered closed. It was used by accident – the term should be prior. This was in the Charter… but it was incorrect and certainly confusing. (musings about definitions of a priori )
6 and 7 and 8 and 9 and ten and eleven are taken care of
12 is resolved
13 will be closed when Daniel Austin can send e-mail.
14
15
16 this is still open.
17 from Mark Baker assigned to Martin. This is a transport issue.
This point concerns the re-use of ports and he is pointing out a valid point. XML gives us the means to define protocols. We think we have addressed this. WSDL can be used to define an application protocol. We need inheritance and a security model. We do more than get and post. This is no different from what we have with the web now. [Rodger] can we close this issue? – He has a point we tried to cover it and we hope you agree. His statement is incorrect for the current document.
[Geoff] This is a future topic that the W3C has to think about – but not here and now as we expand the richness of web services we will have to address this.
Martin] This capability to define new application level protocols is a good thing.
18
19 Closed
20 Action to Mike C
21 Uniform Interface- Eric
22 Not appropriate for this working group.
23 closed when Daniel get to his e-mail
24 unassigned. No action item. P3P to talk to us tomorrow.
25 Hugo –- link to properties and features – this is one way that this can be used for reliability in an unreliable envireonment
26 Use case document valid nits
Synchronous. Not addressed.
Visibility. Architecture and properties. Architecture and tradeoffs. One property is multiple underlying protocols. Visibility is one of the “ilities” the way that SOA definition was in the context of Roy’s thesis, what methodology do we want to discuss architecture in. we need to take a look at properties and architecture. Services oriented architectures manipulate representations not the object directly. It would be better to have these in a SOAP message to do the right thing. Using SOA means having less visibility. For REST you can look at the URL and know what to cache.
You can get simpler deployment. Multiple protocols may be a good or a bad thing.
You always have visibility, but it is a question of how much. If your objective is to limit visibility then you can do that in SOAP. There is widely developed software that responds in particular ways to specific methods. The server can ignore SOAP actions. If what you are trying to get, then make sure that the methods as far to the front of your stream as far as possible. If you want to meet the need to high performance, then use specific methods in front. For web services, we are willing to live without caching. If we are doing GETS then you can cache. if you want to tunnel through HTTP, then you may could use caching. [Rodger] this should be in the document. [Mark] how should we recover some of the performance? There was a discussion of caching. [Geoff] what do we think of the elaboration of what we are doing? what will that look like? Until then, he hesitates to look at caching [Mark] what is a concrete problem that we can work on not in the public domain. Discussion of to cache or not to cache- and which will put more cash in our pockets. Can there be a WS cache that is smart enough to know what to cache.
A question for the group – is this an implementation question for the group? Can you use those headers? RFC2616 says POST is not cacheable. The architecture may be able to support non-restful caching.
[Rodger] collecting definitions for the Glossary – there are some big issues, but so many have so many nuances. Can we delegate people small groups for these? And to have people to accept the definitions. Discussion of the consensus process, that everyone is entitled to their opinion. Can we short-circuit this? We need to get the definitions done, Hugo – we need something clear to vote on.
[People are bailing out]
[end of notes]
<mchampion> ACTION: Chairs to
assign action item on WS-Policy / Features-Properties before end of
F2F
... ACTION: Chairs to raise properties-features coordination
between WSD and WSA on WSCG
<mchampion> ACTION: Security TF to draft concepts/relationships harvested from Abbie's presentation. Frank, Abbie, and Gerald volunteered; Katia expressed interest in helping.
<hugo> ACTION: Hugo to create a security task force mailing list
<mchampion> ACTION: Hugo will create mailing list for security TF with Katia, Eric, Tom Carroll, Abbie, Frank, and Gerald
<hugo> ACTION- 7
... ACTION 8 = Hugo will create mailing list for security TF with
Katia, Eric, Tom Carroll, Abbie, Frank, and Gerald & ChrisF
<mitrepaul> add paul denning to security tf list also
<TomCarrol> Marks OSI comment
http://lists.w3.org/Archives/Public/www-wsa-comments/2003Feb/0010.html
... Marks transport comment
http://lists.w3.org/Archives/Public/www-wsa-comments/2003Mar/0002.html
<mchampion> proposed wording: We all have different
views on the relationship between the W
... WS stack and the OSI stack; we do not see any value in spending
the time to reach a consensus.
... It doesn't matter what we call the layer below SOAP. We usually
call it "transport" but it doesn't matter whether that's the same
meaning as OSI has.
... ACTION: Mike C will draft a response to Mark's last two
comments.
<geoff_a> SOAP 1.2 binds to a variety of protocols, including HTTP. We normally refer to these as "transport protocols". However these protocols may be implemented at various architectural levels, which may or may not correspond to the term "transport" as used by the OSI or IETF reference models.
<hugo> discussing: http://lists.w3.org/Archives/Public/www-ws-arch/2002Aug/0306
<mitrepaul> related to Visibility
<mchampion> ACTION: Mike
... C will make sure that 17 is no longer an issue; Mark has a
point, and we've clarified the implications for both the WSA and
the Web as actually used.
<dbooth> ACTION: MikeC will make sure that 17 is no longer an issue; Mark has a point, and we've clarified the implications for both the WSA and the Web as actually used.
<mchampion> Mike C will look at Dave O's response
on Sep 27, 2002 1:06 pm
... This is not a bug in the WSA, the WSA is clarifiying how XML
makes Web practice clear
... ACTION: Mike C will research issue 20 as he promised at the
last F2F,
... ACTION: Eric will close issue 21
... ACTION: Heather will research/close issue #22
... ACTION: Group will discuss issue #24 will P3P tomorrow
<hugo> ACTION: DavidB to answer to issue 26's submitter
<mitrepaul> DO: visibility important for
intermediaries to act on a message
... DO: visibility enables caching, which improves response time;
so WS that are not visible may have worse response time.
<mchampion> ACTION: MikeC will work with Eric to make sure that Dave O's visibility resolution text is in the document
<mitrepaul> role-based caching?
... role-based cache-controls?
<TomCarrol> Role based solutions seem to me to be more scalable and easier to manage
<mitrepaul> what needs to be in WSA to enable
caching of complex XML queries that can't fit in a URI; visibility
mechanisms
... BOF - Fidelity person won't use GET because can't fit complex
queries in URI
<TomCarrol> at the BOF most people saw GET being adopted slowly if at all
<mitrepaul> RFC 2616 - post not cacheable.
<zulah> are you currently scribing into IRC?
<TomCarrol> no
... line
<zulah> Bummer
<TomCarrol> http://www.aosalaska.com/cyberkingnv.jpg
