[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes, RSP face to face, June 20-21
Minutes
WS-I RSP Face to Face meeting
Meeting
Date: 2006-06-20 - Present
Anish
Karmarkar Bob
Freund Bob
Sunday Charles
LeVay Darren
Self Dorival
Simoes Ed
McIver Eric
Wells Faisal
Waris Frederick
Hirsch Gilbert
Pilz Jaques
Durand John
Miller Lei Jin
Leonid
Felikson Marc
Goodner Mark
Richards Pete
Wenzel Sanjay
Patil Skip
Snow Tim
Fowler Tom
Rutt Vincent
Kowalski Absent Andy
Teasdale Chris
Ferris Chris
Kurt David
Orchard Denis
Pilipchuk Hal
Lockhart Janice
Carroll Joe
Pruitt Kenneth
Childers Michael
Bechauf Michael
McIntosh Mohammad
Abidi Paul
Downey Si La Chair:
Bob Freund Scribe:
Charlie Topic: Formalities 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. Topic: RAMP Skip raised using IBM requirements RAMP document
submitted to Ford and Chrysler as input <Gil> ftp://www6.software.ibm.com/software/developer/library/ws-ramp200508.pdf
<Gil> http://www-128.ibm.com/developerworks/webservices/library/specification/ws-ramp/
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. Usage Scenarios 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. <Gil> http://www.ws-i.org/docs/charters/RSP_Charter1-0.pdf
<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 <anish> exactly! <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
the <Bob> : Would
prefer not to discuss this item now, but to think about it and raise as an item
for a future agenda jwm Sure.... <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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]