WSAWG Telcon Minutes 2002-06-20

Agenda, Actions, Attendance
agenda+ Roll call, scribes for minutes/action items (15.30 + 5)
agenda+ Agenda review, and AOB (15.35 + 5)
agenda+ No minutes to approve (15.40 + 0)
agenda+ Review action items [none] (15.40 + 0)
agenda+ Status (15.40 + 10)
agenda+ Review of progress made at F2F (15.50 + 10)
agenda+ Review RTF proposals for Requirements doc changes related to Team goal (16.00 + 15)
agenda+ Review RTF D-AC018 [5] (16.15 + 15)
agenda+ Proposal for D-AC005.5 - 8 (16.30 + 5)
agenda+ Next steps and task assignments (16.35 + 20)
agenda+ Wrap-up (16.55 + 5)
chris: I'd like to schedule some time to discuss my various goals that I posted.
okay, we'll see if there's time, otherwise next week I'll add it to the agenda
that's ok
chris, when will the f2f minutes be available? I a bit lost in some email threads without them.
hugo and I were cleaning them up this morning. they should be posted soon.
zakim, this is arch
ok, chrisf
Jim Davenport here from MITRE
I cannot seem to dial in right now
Zakim, what is the agenda?
I see 11 items remaining on the agenda:
1. Roll call, scribes for minutes/action items (15.30 + 5) [from chrisf]
2. Agenda review, and AOB (15.35 + 5) [from chrisf]
3. No minutes to approve (15.40 + 0) [from chrisf]
4. Review action items [none] (15.40 + 0) [from chrisf]
5. Status (15.40 + 10) [from chrisf]
6. Review of progress made at F2F (15.50 + 10) [from chrisf]
7. Review RTF proposals for Requirements doc changes related to Team goal (16.00 + 15) [from chrisf]
8. Review RTF D-AC018 [5] (16.15 + 15) [from chrisf]
9. Proposal for D-AC005.5 - 8 (16.30 + 5) [from chrisf]
10. Next steps and task assignments (16.35 + 20) [from chrisf]
11. Wrap-up (16.55 + 5) [from chrisf]
well thanks Dave! I need more gold stars!
dave... how do you make it put the msg out with an * like that?
Daniel = scribe
1. Roll call, scribes for minutes/action items (15.30 + 5)
Chris goes over agenda
item 3 minutes
F2F minutes to review:
Hugo working on minutes, will post URL on IRC, will be approved next week in call
Aims & Objectives URL:
item 4 - no outstanding AIs
item 5 status: editors call report:
few attendees, working on usage scenarios document
terminology: use thingies suggested
Chris asks Hugo about posting of use cases
Hugo: modified travel use case, integrated with Roger's EDS use case
will post to list, link from homepage
David O will review
ACTION: Hugo to publish his updated version of the use thingy doc
RTF report: team lead reports, working on 7, 18, 19
will send reworked #7 to list for review
nest week will work on #18, 19
nest - next
CHris: will cover later in agenda also
agenda item 7
actually, item #6, review of f2f results
Chris: meeting was partially successful, lot of progress, could be more
many proposals were resolved
CHris has made the changes to the reqs doc, will post today
David O presented basic Arch Document, much discussion at f2f
more work needed
Chris will propose additional task forces to work on parts of this
esp. architectural aspects of existing specs need to be harvested
binding, MEP, cross-functional requirements added to list
Katia: cross reference must be consistent
CHris: glossary presentation by Allen Brown
discussion of glossary organization
Allen will continue to work on this
Chris: Use cases were also reviewed, both travel and EDI use thingies were reviewed
security aspects were discussed in detail
confidentiality, data integrity, authentication
this discussion ended when we reached the limits of the current architectural understanding
decision was made to split efforts to flesh parts out, parallel efforts to maximize resources and speed process
agenda item 7: review of RTF proposal addressing DAG002
should some of these be moved to team goals?
refactoring options discussion
CHris: hopefully everyone has looked at this
Suresh leads conversation
the first proposal is to move DAG007 over to team goals
let's talk about this first, then the rest
DAG007 says the ref architecture must be reliable and stable over time
Daniel sez: where do you want to move it?
Chris: asks group how to proceed with this proposal: serially or as a whole?
Suresh starts with 7.1 - relaible
7.2 stable over time
7.1.1 precise definition of architecture, no opaque jargon
Frank M. asks if we use plain English or UML or what?
Suresh sez the doc doesn't say, intentionally ambigous
Frank M: do we think it should be in English?
Suresh: thinks it should be ambigous
Daniel agrees, even while typing
Chris notes we shoud try not obfuscate the text too much
make sure we define terms as much as possible
7.2 - stability and evolution
7.2.1 - stable conceptual model
7.2.2 WSA defined by well-defined policy
7.2.3 new versions of WSA should be backwards compatible
7.2.4 changes are well-defined
Daniel: I was worried about 7.2.3. I've worked on a lot of software projects that required it, and I've worried about it.
Zulah: We had this discussion and the "should" came up.
LOL that is not a word
Dave thanks, I am back as scribe
much gracias
Suresh, Katia argue over compatibility
zakim, who's here?
On the phone I see Mark_A_Jones, GlenD, ??P7, +1.408.732.aaaa, Tim_Jones, ??P10, ??P9, +1.972.459.aabb, Joseph_Hui, Igor_Sedukhin, Chris_Ferris, Hugo, ??P17, +1.919.488.aacc,
... DavidB, MikeM, ??P20, Prasad_Yendluri, ??P25, PaulD, +1.415.229.aadd, ??P1, DOrchard, +1.412.268.aaee, ??P3, Henrik?, ??P28, ??P29, ??P30, ScottV?, MarkB
On IRC I see DaveO, jeffm, AllenBr, Kreger, JimD, MartinC, MikeM, Daniel, igors, TC, TimJones, joe, Zakim, RRSAgent, chrisf, frankmcca, MarkB, Mark_J, Henrik, dbooth, hugo
Daniel will accept 7.2.3 so long as it says "should"
zakim, mute me
sorry, DaveO, I do not see a party named 'DaveO'
zakim, mute dorchard
DOrchard should now be muted
I can buy that
paul Denning sez: is superflous
SUresh: that one applies specifically to changes, not the same as 7.2.1
Suresh: does the group agree?
No complaints from the ppl
Mike M. sez: 7.2.1 may be superflous also
resolved: remove: , and the
changed Web Service Architecture is reliable
Suresh: I adont agree
from d-ac007.2.3.1
Katia: makes point about
Chris clarifies
they could be merged but its worth preserving the distinction
CHris: other comments?
Joe Hui: at a higher level, "evolvable over time"?
Joe: should we add this?
Suresh: stable changes lead to evolution, not really needed
Suresh says it was removed because it is mentioned elsewhere
Joe argues that his point is different
wants to add evolvable to 7.2.2
CHris: let's get closure w/o adding things
Please send your change requests to the list
Can we be confortable with the existing text? what do we think?
Frank M asks about 7.2.2
Frank: does it refere to the arch or the documents or the components or what?
SUresh: all of the above
Suresh: do we agree?
Dbooth suggests we should clarify the text
Frank supports idea, but it needs further elaboration, describes as "minefield"
Joe'd like to see the notion of an "evolutionary roadmap" reflected in 7.2.2.
Frank: versioning is a difficult task fraught with error and controversy
Chris clrifies the versioning
Frank: how does versioning work? incrementing?
Frank we need a versioning policy
Chris: agrees we need to spend more time on this
Daniel: What i intended was the arch must be reliable, stable, but there is a path for it to grow. I did not mean easily understood.
Katya: But now we're talking about it pertaining to the document, so "reliable" is a confusing term.
Daniel talks about intent of goal 7, meaning of relaible is "predictable behaviour
Thx Dave!
zakim, unmute dorchard
DOrchard should no longer be muted
Suresh: agrees with reliable term
Katia: confusing reliable with well-defined
Katia sez well-defined is different and should be included, thinks text is confusing
David O suggests that this go to the mailing list
Chris: hmmm maybe we can get closure on at least some things, ie the intent rather than text
Chris: objections?
no objections
editors take action item to fix DAG007 as per group agreement
now on DAC008.6
ACTION: Editors to include new version of D-AC007 with modifications agreed on the call
Daniel: 007 was originally intended to refer to the arch, not the team.
Katia: doesn't agree
on to 8.6 - use of components must be consistent w/in architecture
Katia: suggests it might be moved
Daniel notes that this applies to both the arch and doc, and that this was intentional on the part of the editors
Katia suggests rewording:
The definition and use of the components is consistent
within the Web Service Architecture
and the architecture document itself
CHris: hears no objection, so moved
moving on 12.7
ACTION: Editors to include new version of D-AC008.6
12.7 sez architecture must be validated against use thingies
does the group agree?
ACTION: Editors to include new version of D-AC012.7
Chris: this si approved
ag 5.3 - unique components
Chris goes over items 5.x, asks for comments
Chris: objections?
ACTION: Editors to include new version of D-AC005.3
CHris hears no objections, editors will do it
ACTION: Editors to mark D-AC005.3 as approved AC005.3
CHris: skipping agenda item 8, RTF needs more time to cogitate on this one
CHris: tortures group with high pitched noise as he changes telephones
Chris: on to agenda item 9
rrevision for DAC 5.5-8
Frank M: what about mgmt? this is a black mgmt out of scope?
Chris: discuss on the list
Frank have we discussed this before?
CHris: not on the call
CHris ( on item 9) 5.5-8 revision suggested by Srinivas, text is recast
Chris reads proposed text
Mark B. sez: there was something on the list about this
mark: actually that was 5.6 sorry
Chris: do we adopt the revisions?
zakim, mute dorchard
CHris: no objections, editors are tasked with fixing it
DOrchard should now be muted
Chris: on to agenda item #10
ACTION: Editors to change and mark as accepted: D-AC005.[56]
Chris recaps what happened at the f2f on this issue
zakim, unmute dorchard
DOrchard should no longer be muted
CHris: I had hoped to draft what might constitute scope of security WG proposal
Chris: we worked on this but did not achieve closure, based on Joe Hui's "onion" proposal
(see f2f notes)
Chris: suggestion that we might focus on end to end security also, possibly at the message level
CHris: requires digital signing of SOAP msgs, credentialing
Chris: when we got to the point of setting pen to paper, we broke out into broader discussion
Chris: of need for more clear arch def before security WG can be proposed
CHris: futher discussion was about arch model for WS...suggestion was that we would
Chris: harvest assumptions and ideas from existing WS specs
and then set up a subteam to do the harvesting
members should be familiar with WSDL and/or SOAP
David O: is that an or or or both
Chris: and/or
CHris: need a small group
Chris: also a 2nd subgoup working on security use thingies
Chris: based on dissecting Hugo's travel use thingy
Chris: talks about short time frame 3-4 weeks
CHris: calls for volunteers, 3-4 ppl per group to progress in short time
Mark Baker: under the impression that harvesting would look at running code as source for arch principles
Mark B: better approach that harvesting other specs
Mark: what do you think?
CHris: you mean the web?
Mark: better source than specs, which are very general
Katia: what is the point?
Katia: harvest from *what* running code?
David O: Mark may be suggesting looking at a wide range of code
Mark: experience shows that running code is best soruce
Paul D: are you thinking about deployment descriptors etc?
Mark: not sure about that...more about interactions between existing components as model for architecture
David O: one of the reasons for harvesting was from Glen D., instead of proposing conceptual model,
we should start from the group up with components exchanging infosets
and then talk about how this might be extended with more features, etc.
WSDL proviedes an abstract model of these intractions might take place
David O likes this idea
iteratively adding more refinements
opposes Daniel's top-down suggestion at previous f2f
Katia: doesn't object to Dave's proposal, but notes that this leads to feature creep in the description
David O: WSDL supports 4 types of that what you mean?
Katia: there are other things too
David interrupts: the point is that the reality of these specs have lots of architecture in them
David: we should gather all of that up and then work on it
Chris: this is useful for consistency
David: what? we need consistency? Ha!
Chris: that would be nice...
CHris: one can think of features that should be defined unambigously and consistently
CHris: and we need to take these things into accoutn when we work on the arch
Chris: we can consider alternate sources of desription, but we have to deal with what is already done
regardless of the impact
mark doesn't agree
Daniel doesn't agree with Dave, agrees with Mark
David O: makes distinction about harvesting, helps to identify gaps
mark: notes basic assumption that we all know about SOAP and WSDL
David O: ppl were unconfy with features of SOAP and WSDL
Regrets - I need to drop off, see y'all next week
David O: points out that most of the arch is already done, we just need to harvest
Suresh: likes David's approach
has one question: is the part from the other specs normative?
Chris: normative?
Daniel: this means we are stuck with SOAP and WSDL
Scribe: correction: David O said "normative" not CHris F.
Katia: aska about meaning of normative
David O: SOAP must be extended to be used, so extensibility is key
Suresh: which version of SOAP 1.1?
Chris: SOAP 1.2
Chris: normative defn is diff in this group than normal W3C
David O: can you pass on the reference to SOAP attachments?
Suresh: question about infosets
Chris: we can discuss that later
Chris: wrapping up, asks for volunteers for these two subgroups
Chris: note short timelines
Chris: work will start asap
CHris: sez that previous volunteers fro the f3f should volunteer again
Joe Hui: wonders if CHris would state scope of volunteer work
Chris: after the useage thingies work is done yes
Joe: what is the overall scope?
CHris: will send in an email
i have to leave too. later all.
bye for now, I have another meeting
FrankMcC: I sent out some additional goals/requirements.
... I'd like to find a way to get the process in place to address them.
[15:45] <Daniel> item 4 - no outstanding AIs
... The background for this is that they come from our experience in doing agents.
... An agent is like a use case for people doing Web Services.
... And from doing Agent interop stds also.
Katya: And also they represent how WEb Services may evolve in the future.
... Rather than just one-shot "get the stock quote" examples.
... In reality you have multi-party interactions and more complicated services.
FrankMcC: If WS are going to be deployed by businesses, they need to address std business needs.
... These goals are enable techynologies to meet those needs.
Katya: Yes.
FrankMcC: I'd like to put a process into place for addressing these.
Chris: That is part of our process.
i must leave.
Chris: Just keep championing them on the list and try to bring them toward consensus or capture the sense of what people think.
Chris: No teleconference call on July 4th.
Chris: Re: Usage Scenarios, DaveH is not on the call, and my phone battery is dying, so could someone volunteer to chair the call?
MarkH: I'll hang out for the call.
(A few others also said they would)
zakim, please propose a chair
I don't understand 'please propose a chair', dbooth. Try /msg Zakim help
Hao: I'll chair.
[Meeting adjourned]
rrsagent, where am i?

Action Items

ACTION: Hugo to publish his updated version of the use thingy doc [1]
recorded in
ACTION: Editors to include new version of D-AC007 with modifications agreed on the call [2]
recorded in
ACTION: Editors to include new version of D-AC008.6 [3]
recorded in
ACTION: Editors to include new version of D-AC012.7 [4]
recorded in
ACTION: Editors to include new version of D-AC005.3 [5]
recorded in
ACTION: Editors to mark D-AC005.3 as approved AC005.3 [6]
recorded in
ACTION: Editors to change and mark as accepted: D-AC005.[56] [7]
recorded in
WS_ArchWG()3:30PM has ended


Chair had system crash and lost roll info