[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes, RSP face to face, June 20-21
WS-I RSP Face to Face meeting
Date: 2006-06-20 -
Chair: Bob Freund
Roll-call was taken
Bob reviews Bob's version of Robert's rules.
Resolution: WG decided on rotating scribe without objection
Charlie scribe for today.
Resolution: Marc Goodner volunteers and is confirmed to be issues editor without objection
Topic: Teleconference Schedule
Bob polls room,.tie between Monday 14:00-15:00 and Wed 16-17:30. Eastern Proposed that meetings will be Mondays at 14:00 EST - 15:30 EST
Resolution: Teleconferences to be Mondays at 14:30 EST to 16:00 EST
<anish> that means rsp and ws-addr are back to back
Citigroup has offered to sponsor teleconference thank you Skip
teleconferences will be every week due to our work schedule
Marc suggests we re-evaluate meeting schedule after first deliverableBob agrees
Topic: Issues management
Marc sends out template for issues processed
<Sanjay> Marc's proposal for issue management:http://members.ws-i.org/Resource.phx/lyris/newmessage.htx?id=209592&row=0issue lifecyle is described on Marc's e-mail
Marc describes issue list protocolEvery issue to come in tag as new for discussion in the subject linethen put into appropiate category
Resolution: members accept marc's template and list of state for issues.
We plan on using the CVS repository for all document management when Bob resolves problems
Based on notice from the WS-I board, Bob is no longer acting chair; he is now officially the chair of the RSP workgroup
Topic: Charter Review
Reviewed list of specs for RSP
Scope will be based in interpretation of our charter
question on line 61 and 62 regarding policy assertionsat the time RSP was submitted, policy was not yet visible as a WG in the W3so its schedule was indeterminate and thus it did not meet the schedule of our work group Policy may well be cited as a gap in this profile and may be included in the next release
need to coordinate with BSP 1.2 and BP 2.0 since we are dependant on those deliverables
We have an aggressive Required Deliverables schedule
Bob's key points for requirement doc be based on usage of the protocol, security dimension and environmental restrictionexample of an existing requirements doc would be the one generated during BP 1.0/1.1. The September doc would be based on usage scenariosThe July document is a non-material deliverable, so it is an internal document.
Skip raised using IBM requirements RAMP document submitted to Ford and Chrysler as input
marc raises the point about some of the requirements apply to BP, however, Skip agrees with marc, but could be used as a starting point. The document would be an input but not the basis for the document
We must be wary of source of input documents, copyright holders of document must agree to submit it with all that implies.
<jacques> I am quite OK accepting whatever req source RAMP had - but there are just too many issues with taking RAMP itself as req...
Action: IBM, Ford, and Chrysler to agree to submit the RAMP doc
Mark Richards http://members.ws-i.org/Resource.phx/lyris/newmessage.htx?id=179053&row=8action item for charlie to get permission to submit doc and send to mailing list
<MrGoodner> Here is a public link to the interop scenarios of the RX TC: http://www.oasis-open.org/committees/download.php/17232/InteropScenarios.doc scenarios do not necessarily require usage of all specs, but may us RM but no securityand vice versa
Action: Anish: extract requirements from the RAMP doc and present results to the working group
Critical dependencies are we can not progress until the RSP dependancy specs are at the nearly doneThe WS-I will not publish final material until the dependancy specs become standards
Topic: Status of dependency specifications
RX Committee spec hopefully in Sept. . Not a defined schedule yet for SX, target 18 month to standards which is roughly next summer for Committee Spec
issue and discussion of what test tools and sample apps should do for RSP
issue about doing something less labor intensive as a sample app
<Sanjay> WS-RX TC has produced several committee drafts (CD), the most recent one has been used for interop testing.
Our first deliverable is requirements derived from usage scenarios
Resolution: Jacques agreed to be an editor for September deliverable
Resolution: Marc volunteered to be editor for the July deliverable
We have to have some ideas how this things are really used to set boundaries which then bring requirements to mind
<Bob> would like to have a list of scenarios by COB tomorrowthen divide up scenarios for elaboration
Bob meeting is recessed until tomorrow 13:00-17-00 EST
Meeting resumes after recess
New Scribe: Darren
Topic: Summary of open issues
MrGoodner Issue 1 - what is a requirement?MrGoodner Issue 2 - what is an interop scenario?
<Bob> : First item of business is that we have an agenda modification… I received a request that a recorded vote be the standard mode of operation.
<Tom> : Waste of time as anyone can call for a full roll call vote at any time
<Bob> : This can be done any time, are there any objections to use non-recorded votes unless requested?
Resolution: The WG has resolved without objections to use non recorded votes unless any member requests a recorded vote.
Topic: July deliverable: Requirements derived from interop scenarios
<Bob> : We have to create requirements from interop scenariosPropose that we settle issue one and issue twoie, What is a requirement and what is an interop scenario?
<anish> i can give an example of interop scenario/requirement as it applies to rx:… 2-way reliable req-resp with piggyback acks on the req and response… on soap/http with the clent behind the firewall… one required coming out of this scenario is that the RMS must accept and the RMD … … must be allowed to send a piggybacked RM ack
<Frederick Hirsch> where is the list of recommended reading?
<Gil> its the list of dependencies in the charter… WS-RM 1.1… WS-SC 1.3… BP 1.1… BSP 1.0... etc.
<Frederick Hirsch> thank you, and where is the charter, I cannot find it on the group page.
<anish> one point to note about that requirement is that the Ack for seq "XYZ" is sent on a reliable payload message that belongs to seq "PQR". Seq "XYZ" is from client->server, seq "PQR" is from server->client… this is important to note cause sequences are for messages only in one direction
<Gil> but the acks flow in the other direction
<Marc> : Question about security example. Say using X509. Is that in scope or are we only addressing SC?
<Bob> : Only pulled that as an example supposing it would be supported. Not security expert though.
<Gil> : What depth do we want to go with abstracting the interop scenario?
<Bob> : Tend to agree with that.
<anish> ... also one point that needs to emphasis is that gathering scenarios is important cause it includes a bunch of specs and makes them work together. Whereas, ws-rx/ws-sx TC are focused on one spec.
<Charlie> Interop scenario is a defined by the composition of Qos dictated by WS-RM 1.1, WS-SC 1.3 specifcation, security and environment that is implementable to drive message exchanges to define an acceptable message pattern to verfiy interoperability.
<Bob> : Any discussion on Charlie's text?
<Charlie> : Trying to contrive set of message patterns to establish pattern of interop.
<Marc> : seems quite good. Like to avoid QoS term though!
<Bob> : Three axis's of interop scenario are Usage, Security and Environment
<Marc> : Think it's fair to call out the security reqts given the specs in our scope
<Gill> : Are application security reqts in or out of scope?
<Gil> : Don't have opinion. Just want to define scope of our work.
<Bob> ; neither of the specs define the application api. The do describe protocol at the
messaging layer, which are independent of the application layer.Marc: Wanted to make sure we are not narrowing the scope too much.
<Jacques> : Go with security at messaging layer. Another way to look at it is assuming BSP is already there, do we start from that?
<Charlie> Inteop scenario take 2 : Interop scenario is defined by the composition of specifications namely WS-RM 1.1, WS-SC 1.3 and other appropriate specifications based on the RSP work group charter designed to define an acceptable message exchange pattern to verify interoperability. The interop scenario is governed by specification, security constraints, and environmental constraints.
Bob: Thoughts about Charlie's proposal for an interop scenario. Is that a useful definition?Bob: Objections to accepting Charlie's defition?
Resolution: Issue 2 closed with: Interop scenario is defined by the composition of specifications namely WS-RM 1.1, WS-SC 1.3 and other appropriate specifications based on the RSP work group charter designed to define an acceptable message exchange pattern to verify interoperability. The interop scenario is governed by specification, security constraints, and environmental constraints.
No objections. Motion carried. Issue Two resolved.
Topic: Definition of a Requirement
<Bob> : OK. What is a requirement then?
<Jacques> : Seems that one Anish started from is a class reqt
<Bob> : What would the general defn of a requirement be?… Is a reqt is expectation of correct interoperation.
<Gil> : Reqts have to be sufficient to support usage scenarios
<Charlie> A requirement is the defined compostion of protocols based on a usage scenarios.
<Frederick Hirsch> A requirement is the ability to use referenced technologies in an interoperable, secure and best-practices manner to enable one aspect of interop scenarios. ?
<anish> here is an example of formal requirements for SOAP 1.2: http://www.w3.org/TR/xmlp-reqs/
<Gil> A requirement is a condition or feature of the referenced technologies necessary to support one or more of the defined usage scenarios.
<Jacques> : Would like to define terminology more precisely. Don't want things to be too vague.
<anish> i wonder if we need to separate out requirements and scenarios documents. In the context/contraints that we are talking about aren't they essentially the same thing? OTOH, the requirements (Rxxxx) as they will appear in the profile are completely different.… ie. have a scenarios document and tease out profile Rxxxx requirements from that directly… another example of formal requirements/usage scenarios (for MTOM/XOP): http://www.w3.org/TR/2004/WD-soap12-os-ucr-20040608/
<Charlie> i agree
<Frederick Hirsch> charter says requirements - are independent of reference to particular technologies or standards -
<Skip> : One problem with requirements is how to prove it has been satisfied or not. Needs boolean answer.
<faisal> should not what we are calling requirements are to the level of assertions that we have in BP; i.e. much like XPath expressions?
<anish> one thing to keep in mind is that the profile (amongst other things) should plug in ambiguities/holes in the referenced specs. For example, converting a 'SHOULD' in the referenced spec to 'MUST' (we have done that few times in BP). requirements being independent of references makes this difficult. If we were designing a new protocol/spec that would be usefule, but for a profile ...
<Marc> : This doc we have to deliver is not a material deliverable
<Skip> : Is that in the charter specifically?
<Bob> : It's not specified exactly that way but that is my interpretation.
<Frederick & Marc> : We've been through this process before both with BP and BSP. Scenarios are linked back to requirements specified in the profile(s).
<BobS> : Found we had to segregate business reqts from functional reqts. Need level of indirection.
<Frederick Hirsch> Note that testability of requirements may require replicating as profile statements, statements from underlying specs. BSP did this, will be more work.
<Gil> An example requirement: in the face of a communications failure an application should be provided with an accurate indication of the messages that were recieved by the destination.
<Jacques> : Charter sadly mentions this one month deliverable (requirements doc)
<Bob> : True to say that we all come from different backgrounds where terminology means different things to us all. Want to make sure we are all clear about our terms.… Real results are Sept usage scenario and 2007 profile document. July doc is a touch-base item for the board.
<jacques> 1 month deliverable = (non exhaustive) list of use cases we informally agree on, while the September deliv = (Usage Scenarios) is the actula solid reqs, activity-scoping for thisTC
<Gil> at this level we only have two "requirements"; reliability and security
<Bob> : There may be difference between the reqts doc and the final reqts in the profile. Things will change as we work on the profile.… proposal that reqts in first doc are the profiling areas that this WG will pursue.… Think it's worth bearing in mind that BSP started looking at some issues and ended up working on other ones that came to light seen as more important. That could happen to this WG as well as we get into the work.… Do we have a better definition of a requirement?
<Frederick Hirsch> requirement: scoping statement related to environment, SOAP intermediaries, endpoint requirement
<Gil> : Looks like we are getting too hung up on the term 'requirement' for this document. It's really more a high level use case document to help us define the scope
<Bob> : What do
folk think about
<Frederick Hirsch> and key assumptions based on usage scenarios
<MrGoodner> A requirement is a scoping statement that will guide our work on the interop scenarios and usage scenarios that we will address in the RSP.
<Frederick Hirsch> requirement is a scoping statement derived from the usage scenarios that will guide profiling and interop scenario work.
<Gil> s/guide our work/guide the work of the RSP working group/
Bob: Any objections to accepting Marc's latest text with Gil's amendments?Proposed text: A requirement is a scoping statement that will guide the work of the RSP working group on the interop scenarios and usage scenarios that we will address in the RSP.Gil A requirement is a scoping statement that will guide the efforts of the RSP working group in forming interop and usage scenarios.Bob: Objections to the text?No objections.
Resolution: Issue i001 closed without objection. Definition for a requirement is: A requirement is a scoping statement that will guide the work of the RSP working group on the interop scenarios and usage scenarios that we will address in the RSP.
Topic: Interop Scenarios
Bob: Let's come up with some interop scenarios...
<MrGoodner> RX TC iop scenarios: http://www.oasis-open.org/committees/download.php/17232/InteropScenarios.doc … The titles of the scenarios in the RX TC should be self explanatory… A scenario like the 'close incomplete sequence' will probably be applicable to us… Don't want to delve into 'offer' terminology from RM
Bob: BobS has provided another document for usBobS: This is a system we have called secure message routing service. Used to transport SOAP between departmentsBobS: Wanted to turn this service into a web service. Gil http://members.ws-i.org/Resource.phx/lyris/newmessage.htx?id=209820&row=0lei Synchronous: When a message is sent from a sender to a receiver, with the sender 275expecting and waiting for a response. 276Asynchronous When a message is sent from a sender to a receiver, with the sender not 277waiting for an immediate response.
<anish> does the doc then mean really blocking or non-blocking?… rather than sync/async… tranport/binding can by sync/async. application can be blocking/non-blocking regardless of whether the underlying transport is sync/async
<Marc> : What does our charter say about working with this. Can we only work with HTTP?
<Bob> : New Issue. Need to clarify underlying protocols.
<MrGoodner> Issue 3: Title: Clarification with regard to underlying protocols Description: Are only the underlying protocols from BP in scope of our consideration, i.e. HTTP only.
<anish> i would characterize this as 'binding' and not 'protocol'. BP requires the SOAP/HTTP binding. non-SOAP over HTTP is not allowed
<Tom> : BP 1.2 charter explicitly states that HTTP will be used
<Skip> : Could guarantee that a lot of people doing reliable exchanges will not be using HTTP
<jwm> BP 1.2
should be written to compose with many different transport protocols... within
<Bob> : Would prefer not to discuss this item now, but to think about it and raise as an item for a future agenda
<Skip> : Re the RX doc, two environmental areas not covered. Like to introduce RM-ActiveProxy and RM-PassiveProxy as two variables we need to consider
<jacques> RSP has a critical dependcy to BP1.2/2.0 per charter (not just a compose-as-you-go req as for BP1, BSP, AP) so HTTP appears as a prime target, even if alternative transports end-up being covered too.
<Skip> : Like to propose we introduce these two terms and consider them for any scenarios.
<anish> does 'active proxy' mean the same as 'active SOAP intermediary'? Active SOAP intermediary is defined here http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#activeinter
<Bob> : Are we proposing to open a new issue?
<Gil> Like to open up a glossary
<Marc> : If we do that, it will never be closed!
<Skip> : Like to introduce the terms
<Tom> : More than that, you want us to consider them for each scenario
<Bob> : Open the issue as number 4… We'll put them on the agenda for the next meeting and discuss then
<Gil> maybe we shouldn't create an issue to open a glossary… nevertheless I think a glossary that flows from one aspect to another of our work is valuable
<anish> forwarding interm.: http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#forwardinter
Bob: Lets scope out some areas that conform to our defns of requirement and interop scenarios by whiteboardinganish the two profiles: RSP and BP are meant to be "composable"Bob: Is having to deal with the union of all specs too big? Shall we take to the list?Bob: Suggest everyone reads the reference specifications (bedtime reading!)
Topic: Interop Scenarios
Bob: Asking folks to rattle off interop scenarios that they think may happen. Practical issues rather than hypothetical.
Whiteboard Item 1: Machine to machine communication over internet.Request flow in one direction. Response flow in another direction. No coordination between req and response
Whiteboard Item 2: Two-way Reliable ExchangeRequest and response are on different channelsBoth request and response are reliable with security for both
Whiteboard Item 3: Machine to machine over internet, one way.
Action: Gil. Define the scope of profiling SC wrt BSP
<Bob> : Reading the charter, if any other spec is referenced by one of the specs named (SC, RM, BP, BSP etc) in the charter then we need to consider that additional spec as it is used by its referencing spec.
Bob reviewed general process for developing a profile in WS-I. Explained profiling points and how we deal with them
<Gil> WS-RM says you can only have one Sequence header in a SOAP message, right?
<anish> to answer your question: I believe so, if not, we should.… checking the wsrm spec ...
<lei> in addressing, you can have multiple to, replyto, etc
<anish> not exactly lei
<lei> if they have different actor
<anish> only if those are targetted to different actors/roles… yes
<anish> gil: this is what the rm spec says:
… "The RM Source MUST NOT include more than one Sequence header block in any message."Bob: Running out of time today. Time for homework allocations...Marc will assign issue numbers to scenarios and keep track
Action: Charlie to take first three on "M2M over I, 1 way" chart.
Charlie will also draw a little graph of the scenarios
Action: Marc will take the two way ones.
Action: Skip: Send to Bob the teleconference meeting details
Action: Bob: Send out agenda and phone details on list.
Bob: Meeting adjourned.