IRC log of ws-arch on 2002-06-14

Timestamps are in UTC.

06:54:44 [RRSAgent]
RRSAgent has joined #ws-arch
06:54:55 [hugo]
hugo has changed the topic to: WSAWG face-to-face meeting; IRC log at: http://www.w3.org/2002/06/14-ws-arch-irc
06:57:15 [Roger]
Roger has joined #ws-arch
06:58:21 [soliton]
soliton has joined #ws-arch
07:07:11 [hugo]
I put the complete IRC log for yesterday at: http://www.w3.org/2002/06/13-ws-arch-irc-complete.html
07:09:50 [chris]
chris has joined #ws-arch
07:14:46 [Zakim]
Zakim has joined #ws-arch
07:15:18 [mikem]
mikem has joined #ws-arch
07:16:43 [zulah]
zulah has joined #ws-arch
07:16:53 [dboo-scri]
dboo-scri has joined #ws-arch
07:17:38 [DaveO]
DaveO has joined #ws-arch
07:20:26 [jeffm]
jeffm has joined #WS-Arch
07:20:48 [MartinC]
MartinC has joined #ws-arch
07:21:21 [GlenD]
GlenD has joined #ws-arch
07:21:58 [hugo]
this channel is temporarily hijacked by subgroup 1 for authentication work on <http://www.w3.org/2002/06/ws-example.html>
07:22:14 [GlenD]
Ew, authentication!
07:22:17 [GlenD]
I'm outta here...
07:22:28 [GlenD]
GlenD has left #ws-arch
07:23:24 [hugo]
Other groups in #ws-arch2 and #ws-arch3; logs: http://www.w3.org/2002/06/14-ws-arch2-irc.html & http://www.w3.org/2002/06/14-ws-arch3-irc.html
07:23:28 [omh]
omh has joined #ws-arch
07:24:03 [shishir]
shishir has joined #ws-arch
07:24:26 [GlenD]
GlenD has joined #ws-arch
07:24:39 [GlenD]
OK, I'm back, but only to ask for the URL of the use-case
07:24:45 [GlenD]
Anyone?
07:25:20 [hugo]
hugo has changed the topic to: WSAWG F2F: work in subgroups on use case at <http://www.w3.org/2002/06/ws-exampl
07:25:36 [hugo]
hugo has changed the topic to: WSAWG F2F: work in subgroups on <http://www.w3.org/2002/06/ws-example.html>
07:25:43 [JensM]
JensM has joined #ws-arch
07:27:15 [chris]
this group is auth/n, right?
07:28:08 [Jens]
Jens has joined #ws-arch
07:32:56 [chris]
http://www.w3.org/2002/ws/arch/2/06/wd-wsa-gloss-20020605.html
07:39:31 [auth-scr]
2 parties:
07:40:13 [Daniel]
Daniel has joined #ws-arch
07:40:31 [auth-scr]
2 cases - either the 2 parties know (KNOWN) each other or not (UNKNOWN)
07:47:10 [auth-scr]
3 scenarios: first time (S-FIRST), another visit same tx (S-VISIT-CONT), another visit new tx (S-VISIT-NEW)
07:47:27 [jdmunter]
jdmunter has joined #ws-arch
07:47:42 [auth-scr]
Assume: Travel Agent is known, no delegation
07:54:29 [auth-scr]
Issue: Difference between authenicated identity and trust
07:55:31 [jdmunter]
auth-participant: a customer may or may not request credentials from TA
07:55:45 [jdmunter]
auth-participant: a customer may or may not validate credentials from TA
07:57:18 [auth-scr]
Issue: Can an entity that has been "authenticated" be spoofing?
07:58:23 [jdmunter]
auth-participant: a customer may or may not have pre-established governing policies
07:59:26 [auth-scr]
Assu
08:00:06 [auth-scr]
Assumption: Every entity has a set of policies (may be empty)
08:01:13 [auth-scr]
Assume: Customer will pay with credit card
08:01:36 [auth-scr]
Assume: Travel Agent doesn't care who the customer is
08:04:31 [auth-scr]
Assume: Customer is booking for themselves
08:05:36 [jdmunter]
auth-participant: TA may validate customer ID at a different time than customer validating TA ID
08:09:31 [auth-scr]
Issue: Entities may be able to act in various "roles"
08:14:23 [auth-scr]
S-FIRSTa: Customer asks TA for credentials, Cust decides to proceed with TA
08:15:28 [auth-scr]
S-FIRSTa: Cust browses for a flight
08:20:08 [auth-scr]
Issue: point to point vs. end to end
08:24:55 [auth-scr]
S-FIRSTa: Cust supplies TA with a flight query
08:25:40 [auth-scr]
S-FIRSTa: TA queries a set of airlines for flight info
08:28:54 [auth-scr]
S-FIRSTa: TA does not need to perform mutual authentication with airlines
08:30:49 [auth-scr]
S-FIRSTa: TA queries the other providers under same conditions (no more authenticataions occur)
08:32:01 [auth-scr]
S-FIRSTa: (note: above cust query was for an entire trip, not just flights)
08:33:08 [auth-scr]
S-FIRSTa: Cust makes their selection of travel arrangements
08:35:19 [auth-scr]
S-FIRSTa: TA asks Cust for info necessary to make a booking: e.g. name, address, credit card #, etc.
08:35:53 [omh]
omh has joined #ws-arch
08:38:51 [RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch-irc#T08-35-53
08:41:56 [omh]
omh has left #ws-arch
08:42:03 [omh]
omh has joined #ws-arch
08:53:48 [jdmunter]
jdmunter has left #ws-arch
09:03:16 [chris]
chris has joined #ws-arch
09:13:33 [scribe]
Martin: Use case is not nailed down enough in terms of the business details
09:14:09 [scribe]
We started with assumptions that define different paths through the use case and then some issues that we raised
09:14:20 [scribe]
First, do each of the parties need to know each others
09:14:38 [scribe]
are there business relations?
09:15:23 [scribe]
Assumed general public with no business relationship. Then there is the issue of how many times the travel agent had seen the customer (for a single transaction or multiple).
09:15:50 [scribe]
When you are new, there is no authentication until paying. Whereas when you return for a second visit, there is information on the system and you need to be authenticated.
09:16:02 [scribe]
We only did the first time scenario.
09:16:50 [scribe]
There is still this issue of locating a trusted travel agent. Once you have discovered a travel agent, you can ask them for credentials.
09:17:16 [scribe]
The sophistication of the challenge response depends on the lelve of trust, the amount of money in a transaction, etc.
09:17:28 [soliton]
soliton has joined #ws-arch
09:17:39 [scribe]
We assumed that no one cares who makes an initial query. Only autheicate during booking.
09:18:13 [scribe]
Assumptions: We assumed that the customer is not authenticated, we assume travel agent is known, assume that there is no delegation going on.
09:19:12 [auth-scr]
nick jeffm
09:19:22 [scribe]
Issues: Identity exchange is easy, trust is not. Once you have authenticated, can mascarading still happen (sorry about the spelling).
09:19:29 [hugo]
hugo has changed the topic to: WSAWG F2F: IRC log at http://www.w3.org/2002/06/14-ws-arch-irc
09:19:45 [mitrepaul]
mitrepaul has joined #ws-arch
09:20:10 [scribe]
Issues: Role vs. personal authentication - do I need separate credentials for different roles. Point to point vs. end-to-end authentication.
09:20:31 [TC]
TC has joined #ws-arch
09:20:47 [scribe]
Glen: We discussed data integrity. This is the idea that when I send you data, you can make sure that the data is what I sent you.
09:21:24 [scribe]
Issues: When you havea multinode set of parties you have node to node integrity and end-to-end.
09:22:24 [scribe]
The two different cases are because in one case someone not known to you are transfering bits and in the other someone known to me changes data after it is sent.
09:23:08 [scribe]
There may be business issue (not technical) such as miss scheduling. What technical assistance can we provide for business.
09:23:53 [scribe]
Reuse existing technical infrastructure. How do we describe and agree on policies and technologies to be used by endpoints discovery)?
09:24:40 [scribe]
Two solutions: involve a third mutually trusted party. a referree solution. The latter is a stop gap in the process that would not let anything occur until both sides of a transaction agree.
09:25:14 [scribe]
Other solution is to rely on 2 party solutions: ssl, xml dsig hashing
09:25:38 [scribe]
There may be cases where entire data stream needs integrity but also just parts of a document.
09:25:54 [scribe]
DaveO:
09:26:29 [scribe]
DaveO: User talks to travel service talks to hotel and we talked about confidentiality in this reduced setting.
09:26:54 [scribe]
Issues: Is the fact that the two parties are even talking supposed to be confidential. Privacy issues. Both level on table.
09:28:19 [scribe]
We elaborated on the use case. When the user talks to the travel service, this is a sync message. When the travel agent talks to the hotel, this is async. Then the hotel service talks directly back to the user to confirm reservation.
09:28:33 [scribe]
There are other scenario issues but we did not consider them.
09:29:51 [scribe]
What would be the standard way to architect the synch transport - we chose HTTPs. For Asynch we chose SMPT (just for an example) and we also assumed SOAP messages were being sent back and forth.
09:30:01 [mitrepaul]
mitrepaul has left #ws-arch
09:30:42 [scribe]
So in the sync case, the HTTPs takes care of confidentiality. We use encryption for the SOAP message over SMPT. We explored the options of encrypting the entire message, the body, attachments, etc.
09:31:22 [scribe]
In the case of encrypting the body, the header contains infomration about the body encryption. How does the service discover how this is supposed to be sent (description issue).
09:32:12 [scribe]
So we did not explore how to describe the implied processing at the recipient. We talked about existing messages in a foriegn name space and message format. THis cannot be imbedded in SOAP and would be an attachment.
09:33:08 [scribe]
We finished with a discussion about the line between the web interface (connector) and the application portion of a web service.
09:33:19 [Heather]
Heather has joined #ws-arch
09:34:09 [scribe]
Summary: The scenario that we ended up doing was #62 in our useage scenario document so we made that connection. So we can now explicitly tie the usage scenario (62) to the travel use case.
09:34:30 [scribe]
Chris: We have alot of use case work to do and it would be probably wise to give assistance to DaveO in the use case area.
09:34:45 [scribe]
Roger: Should we also be figuring out ways that the use case can fail?
09:35:14 [scribe]
Chris: Think about whether or not you are willing to commit time in asisting with the editing of the use cases.
09:35:30 [scribe]
Send email to me or to the member list (okay the member list due to the email change ;).
09:36:56 [scribe]
Chris: Now that we have had a chance to think about this stuff, I would like to walk through an exercise where we try to gain some concensus around the "size" (scope) of the security WG.
09:36:59 [dbooth]
q+
09:37:51 [scribe]
Chris: reminds everyone that we have this notion about a phase approach to the WG, possibly aligning the phases along Joe's onion (starting at 1). We wanted a targeted scope.
09:38:18 [scribe]
Chris: We talked about the feedback that we got from TBL about process and flexibility with changing charter.
09:39:07 [scribe]
MikeM: Why in the charter don't we list everything and then recommend a priority as opposed to just putting a small amount of work in the initial charter.
09:39:43 [scribe]
Chris: Might leave to much flexibility. As we build this we have to sell this to the AC. They won't want to see a blank check.
09:40:10 [scribe]
David: Proposes ...
09:40:43 [scribe]
Mike: heather mentioned whether the new security was a mini arch group doing WS arch work or are we going to dictate the components and tell them to fill in the boxes with technologies.
09:41:10 [scribe]
Chris: We will recommend a framework. If they have feedback, they can channel it to us. We do not want to unleash another arch group.
09:41:20 [Heather]
i agree
09:41:33 [omh]
omh has joined #ws-arch
09:42:06 [scribe]
Mike: so we would have boxes for confidentiality, integrity, etc. and some technologies (XML Dsig, encryption) and then the WG would begin.
09:43:07 [scribe]
David: When we talk about the software that implements a WS we can break it into three parts: that which is common to all WS (connector), that which is common to web services in an industry segment (e.g., business WS), ...
09:43:27 [scribe]
Glenn: Can you point out what problem that you are trying to solve because I am resitent to this direction.
09:43:53 [scribe]
Glen: A huge point of what we are doing is that we talk about the wire, not about your end platform.
09:44:25 [scribe]
David: I am trying to help us be clear about what we are talking about. Which is lots of cases of what we should and shouldn't include. So this is for clarity and the ability to draw the line.
09:44:47 [scribe]
David: My reason is that if we don't do this then we will spend an aweful amount of time arguing about whether my favorite thing is in or out.
09:45:02 [scribe]
Glenn: I think that there are better ways to deal with thes types of issues.
09:45:50 [scribe]
David: Getting back to the break up: the part that is common to all WS (connector), the part that is specific to an industry segment (scribe paraphrases heavily), and the part that is application specific.
09:46:39 [scribe]
David: Eg, there might bbe hotel industry specific portions of the WS.
09:47:00 [scribe]
OUr job is to specify the WS connector stuff. I pose this as a characterization for clarity.
09:47:57 [scribe]
JeffM: How do you know that the WS common stuff is not the empty set.
09:48:04 [scribe]
David: If it is then we haven't defined a spec.
09:48:11 [scribe]
JeffM: Disagree
09:48:30 [scribe]
Martin: are you trying to distinguish what is and what isn't a WS?
09:48:48 [scribe]
David: No. If we decide in our specification that a WS must do X, then X is in the connector stuff.
09:50:01 [scribe]
Glen: So what you are saying (and its disturbing me) is the words that you are using smack of software layer and this is not what we are talking about here. So, let's not talk about it in terms of the software at a node. What we are really talking abou tis that there are things that are common to WS that all nodes that implement WS will share .. and then there are application relm things and these are responsibilities, *not* software layers.
09:50:14 [scribe]
Chris: I am failing to understand how this helps us scope a WG to do security?
09:51:00 [scribe]
Mass confusion and kots of people talking at once.
09:51:22 [scribe]
David: There are a number of things in the use case that pertain to the WS paortion and some that pertain to the application part.
09:51:50 [scribe]
DaveO: The SOAP 1.2 spec points this out. But it did this not as software layers.
09:52:13 [scribe]
David: When we go thourhg use cases it is clear to recognize and identify the relm of the parts of the use case.
09:52:45 [scribe]
David: Our job is to decide what bucket items go in (e.g., reconcilliation)
09:53:02 [joe]
joe has joined #WS-ARCH
09:53:04 [scribe]
David: Does reconciliation go in the WS bucket or in the app level.
09:53:21 [scribe]
Chris: We agreed that we would talk about level 1 securuty(as defined by Joe)
09:54:22 [scribe]
Martin: assuming that our services have interface (service types...), whatever that looks like we need to work that out. The contents of the parameters are in the app domain. The names of ops and things ...
09:54:29 [scribe]
q+
09:54:51 [DaveO]
Scribe, can you use the term "DavidB" for when David Booth is speaking?
09:55:11 [scribe]
Chris: Stops the discussion. Wants to return to security discussion.
09:55:51 [scribe]
Chris: If people could pull up the security requirements, this will help shape our discussion.
09:56:17 [scribe]
Chris: Lets try to determine which of the requirements apply to the WG (which we would put in a charter).
09:56:29 [scribe]
Martin: Please resummarize our agreement yesterday.
09:57:08 [scribe]
Chris: Focus on Joe's Level 1: Confidentialility, integrity, authentication
09:57:13 [scribe]
Phased approach
09:57:22 [scribe]
end-to-end
09:57:48 [scribe]
(steel thread)
09:57:54 [Heather]
what about authorization?
09:58:05 [scribe]
Authorization is level 2
09:58:09 [DaveO]
Heather, auth is listed in phase #2
09:58:25 [scribe]
Phase = level
09:58:41 [scribe]
message level end to end
09:58:50 [Heather]
what else is level 2?
09:59:03 [scribe]
pick relevent subset of reqirements
09:59:04 [DaveO]
that's it
09:59:19 [scribe]
use case driven
10:00:07 [scribe]
Chris: So this is basically where we left off. What I want to do now is given this, what is the phased approach, pick the relevant requirements, identify use cases to drill down onn (or are missing as the case may be) and make sure that we can actually write up what we want the WG to do. A roughdraft.
10:01:10 [scribe]
Roger: Are we trying to draft the structure of a WG? What are we doing.
10:01:17 [scribe]
Chris: Rough draft of scoping statement from charter.
10:01:35 [scribe]
Chris: What are the relevant requirements?
10:02:37 [scribe]
Roger: 6.2.1 Authentication user, 6.2.2 authentication for data, 6.4 confidentiality, 6.5 integrity.
10:02:58 [scribe]
martin: is there access control in any of this?
10:03:05 [scribe]
Chris: Level 2 its aiuthorization.
10:03:33 [scribe]
DaveO: Are you prposing as part of level 1 that we have to interchange policy statements?
10:03:42 [scribe]
Martin: Access control is fundamental
10:03:54 [GlenD]
q+
10:03:58 [joe]
q+
10:04:03 [scribe]
DaveO: Everyone will build acess control into their software. Its what they have to echange.
10:04:09 [dbooth]
q-
10:04:38 [scribe]
Chris: are we changing our agreed on staarting point>
10:05:11 [scribe]
Glenn: is access control and authorization differnt?
10:05:20 [DaveO]
q+
10:05:32 [scribe]
Chris: Access control is a means of applying authorization.
10:05:47 [chris]
ack scribe
10:06:19 [scribe]
Zulah: are we goin to include other requirements (other than security) eg. web freindly?
10:06:28 [chris]
ack glen
10:06:30 [scribe]
Chris: No, we are not restricting the reqs to security
10:06:34 [mikem]
mikem has joined #ws-arch
10:06:45 [scribe]
Glen: Access control in this scope is part of authorization
10:06:46 [chris]
ack joe
10:06:50 [Daniel]
there is a base set of requirements that are common to all WGs we create and then there are security specific ones. We want the union of the two
10:07:00 [chris]
ack daveo
10:07:27 [scribe]
Joe: Access control is a specific cas of authorization. the onion model, the purpose, is to allow people to do the scoping. Se we have a choice to do level 1 and level 2 at the same time.
10:07:38 [scribe]
Chris: What I understand is that we want to focus on level 1
10:08:01 [DaveO]
q+
10:08:41 [joe]
q+
10:08:51 [chris]
ack
10:09:31 [scribe]
DaveO: I dont' consider my self a security expert (even though edited SAML spec), SAML talked about authorization in two aspects. When you sign on and you get a token indicating success (auth token or bearer token), and then security policies and access control. These are separate and I don't know what Authorization means in this case. Can we defer splitting these until later.
10:10:19 [scribe]
Roger: Lunch is at noon. We should go to lunch.
10:10:36 [Heather]
are you reconvening after lunch?
10:11:24 [scribe]
No decision yet
10:11:26 [Daniel]
Heather: not sure...some ppl are leaving
10:11:42 [scribe]
Glenn: How about having a small group create an outline for a charter and then prpose it to the group.
10:12:06 [scribe]
JeffM: Authorization on or off the table. This is a fundamental question.
10:12:25 [scribe]
Chris: Straw poll, is authorization on or off the table for phase 1?
10:12:42 [Heather]
i'm ok w/ it off for now
10:12:55 [scribe]
(results: most peopl efelt that it didn't belong in phase 1)
10:13:36 [scribe]
Chris: What do people think about a group creating a proposal and then recommending it.
10:14:09 [scribe]
Chris: Are we done with the security specific requiremenst?
10:14:41 [scribe]
Hugo: waht's happening this afternnoon because if the answer is nothing then the people who return from lunch will do this work.
10:15:27 [Heather]
zulah, r u coming back to scribe?
10:15:34 [DaveO]
DaveO suggestions for encryption: Shall support HTTPS, shall support encryption of SOAP messages, shall support encryption of attachments to messages
10:16:06 [Heather]
encryption of parts of messages
10:16:27 [DaveO]
+1 to heathers
10:16:40 [zulah]
Heather, we are going to head to lunch. Then some of us will return and work firther on the security WG stuff.
10:17:03 [zulah]
Presumaly this will be at 1pm. Sorry for the spelling. tired hands.
10:17:08 [Heather]
zulah, are you coming back to scribe?
10:17:43 [zulah]
Yes I can do that for you. We may also want to go through AC 007 with Soliton. Do you have the message with the summary of comments on AAC007?
10:17:55 [zulah]
BTW. We should play that by ear. We can also do that early next week by phone con.
10:18:09 [Heather]
ok
10:18:25 [zulah]
love to scribe... love to scribe... I'll be here if you are going to return.
10:18:33 [Heather]
i will return
10:18:35 [Heather]
as well
10:18:51 [zulah]
So there is some issue on whether or not we can use the room this afternoon. If this fails, I will let you know.
10:19:02 [Heather]
thanks
10:23:45 [TC]
TC has left #ws-arch
10:24:02 [zulah]
zulah has left #ws-arch
11:55:15 [DaveO]
DaveO has joined #ws-arch
11:55:55 [mikem]
mikem has joined #ws-arch
11:56:34 [zulah]
zulah has joined #ws-arch
11:57:26 [scribe]
Chris: (Choosing requirements from the doc for the WG) We are on 003 - nothing applies
11:58:11 [scribe]
Mike: 004 is getting some re-work. programming models elaboration. And the top level goal for the second part is gone. I will propose new verbage about loose coupling of conponents
11:58:37 [MartinC]
MartinC has joined #ws-arch
11:58:39 [scribe]
Chris: Does not preclude any programming model seems like a req that we would want to impose on the WG
11:59:30 [scribe]
Chris: 005 simplicity, 006 have we pulled everything that applies?
12:00:57 [scribe]
Glen: Would like to note the fact that despite the fact that security is an important aspect, my feeling is that the architecture work is higher level. Transactions, coorolation, conversations ... the architecture should be about the structure of how those pieces work and how they fit together and not about the pieces
12:01:10 [scribe]
DavidB: I agree but we are responsible for creating WGs
12:01:45 [scribe]
Glenn: If we pull back and look at the larger scale problem then we might be able to work quicker there. Then, the is this in, is this out can be determined based on the framework.
12:01:49 [chris]
chris has joined #ws-arch
12:02:30 [scribe]
Martin: We don't even know what a ws is. We need to do this before we charter. We can't do anything until we have some fundamental criteria to determine what's in and what's out.
12:02:37 [scribe]
Martin: The charter seems premature.
12:02:50 [scribe]
Daniel: The group has a tendancy to move the cart way before the horse.
12:03:02 [shishir]
shishir has joined #ws-arch
12:03:08 [DaveO]
q+
12:03:39 [scribe]
Jeffm: So we have a description wg. They have some implicit notion of a ws. I'm not so sure that actually in some ways putting the cart efore the horse isn't a good idea. Since we may not have an agreement about the cart.. the horse..... (strange metaphor).
12:03:42 [tomCarrol]
tomCarrol has joined #ws-arch
12:03:44 [MartinC]
q+
12:03:52 [tomCarrol]
q+
12:04:01 [Daniel]
Daniel has joined #ws-arch
12:04:09 [chris]
ack joe
12:04:15 [scribe]
JeffM: There is a alot of good understanding of security and we could spend alot of time creating an edifice on whcihc to put security.... but market realities...
12:04:31 [scribe]
Joe: Important to scope what we are doing so we can focus our effort... determine what is in and what is out
12:04:34 [chris]
ack daveo
12:04:58 [Daniel]
I don't agree with Jeff; I think doing the right things in the right order is important...I understand about iterating, but we need a basic agreed-upon foundation first
12:05:00 [MarkB]
q+
12:05:33 [Daniel]
q+
12:05:43 [omh]
omh has joined #ws-arch
12:05:53 [omh]
q+ Glen
12:06:00 [chris]
ack mart
12:06:04 [scribe]
DaveO: Typical problem. How long do we spend doing the general vs. the specific work. It seems a good thing to get a charter in this fairly well understood area, and alteast get some progress while continuing the arch work. Company created arch analogy... We have groups in flight (SOAP, WSDL), we can make some concrete progress and show value to the world while working on the architecture.
12:06:22 [scribe]
Martin: I'm not saying that we do a perfect architecture but we don't really have a starting point...
12:06:55 [scribe]
Martin: There are fundamental questions going on in WSDL. How can we have new teams start without some alignment. We need to schetch some arch assumptions before starting on this.
12:07:28 [scribe]
Chris: Our objectives... end of july requirements... outline for arch doc... with cut by July...
12:07:29 [joe]
joe has joined #WS-ARCH
12:07:43 [scribe]
DaveO: We have a first cut arch doc and we have had a discussion and we are going to re-work it.
12:07:46 [chris]
ack tom
12:08:22 [chris]
ack mark
12:08:27 [scribe]
TomC: Without definin the domain to some degree it complicates our activities. Whether we get a set of use cases that we can all agree on... refining the use cases and applying our use cases would provide more direction on laying out the architecture.
12:09:11 [chris]
ack daniel
12:09:12 [scribe]
Mark: Thank martin for saying what he said (about issues in outher groups). Supportive of DaveO's efforts to get the WG going quickly. We need to resolve how web services arch relates to web arch.
12:09:49 [scribe]
Daniel: I worry about the approach that DaveO is advocating. Same method as developing software (no) standarrds last longer than software. No repeat versioning...
12:10:37 [chris]
ack glen
12:10:46 [scribe]
DaveO: we develop standards more slowly than software. (6-9 months software). If we had a charter and a wg in nov it would take 2 years before something came out. Standards take longer than software and should be started as early as possible (paraphrasing from scribe)
12:10:50 [MartinC]
q+
12:12:38 [scribe]
Glenn: I am concerned about chartering a WG and they come out with a spec while we are doing arch work. And its not compatible with the arch. This may well not happen but they may be some considerations that the arch group would come up with that an individual group might not come up with. The groups may feel strange about being pushed in directions that they weren't expecting. We need to clearly message to groups that they are taking part in an archite
12:12:55 [chris]
ack martin
12:13:09 [Daniel]
q+
12:13:13 [scribe]
Martin: Not proposing that we wait 6 months. It takes a while to get Charters going. Would like month to month+1/2 to answer some of these questions.
12:13:34 [scribe]
Chris: This realistically would put us in the oct time frame wto get something off to the AC.
12:13:51 [chris]
ack daniel
12:13:57 [scribe]
Martin: I dont' understand the big emphasis on security. The security group has nothing to start from
12:14:43 [DaveO]
q+
12:14:48 [scribe]
Chris: Group will n ot get chartered until December. We will have answered some of these questions. Exactly what glenn has said is what (I believe) TBL is saying to us. (rephrase)
12:15:19 [scribe]
Glen: What happens when (for example) wsd is doing stuff and they come up with arch issues that need to be solved and will be solved by wsd. How does this happen.
12:15:29 [scribe]
Chris: There is a process. Submit and issue.
12:15:33 [hugo]
q+
12:16:02 [scribe]
Daniel: I get some sense that we are date driven as opposed to determining how ling things will reasonably take.
12:16:06 [MarkB]
q+
12:16:22 [scribe]
Daniel: Should we go back and do some reasonable estimates. We could base our times and deliverables on this. Let's do it right.
12:16:23 [chris]
ack daveo
12:17:24 [scribe]
DaveO: The tag ran into this problem. Chartered to both resolve issues and document the web architecture. Approach tag took is to split time between findings and architecture. TBL had a discussion about this and
12:18:19 [scribe]
decided to split the time. The TAG is even more focused on solving issues that on the document. 2/3 issues, 1/3 arch doc. COunter arguement is that web already exists. However interpretations of web arch not well defined.
12:19:14 [chris]
ack hugo
12:19:19 [scribe]
The way that I would look at this is let's take some time on security, and in the mean time have work done on the arch document. We can work in parallel and partition our time between the strategic and the tactical.
12:20:02 [soliton]
q+
12:20:15 [scribe]
Hugo: There is a scale of approaches here and we have to choose some middle ground.
12:21:44 [scribe]
WSDL may not exactly be compliant with the arch but it will do for now and we will tackle arch inconsistencies in the future. This depends on the time grame for both teams. Regarding what we should do, some things are easier to do without global arch view than others. Choreography vs. some security. Choose carefully what we want to do.
12:21:46 [chris]
ack markb
12:22:37 [chris]
q+
12:22:49 [MartinC]
q+
12:23:08 [chris]
ack sol
12:23:12 [scribe]
mark: We are working on charter with no arch constraints. message based, event based, what are the fundamental restrictions on component interactions. Asking a security WG to build a solution - they will ask "for what". We could get there fairly quickly but we need to resolve how our arch works with the web arch.
12:25:15 [scribe]
Soliton: Time to market is extremely important - there are products out there. Helps comapnies choose which tech to use. Second, although security is the # issue in WS, they are very security specific (as opposed to WS specific). We should look at the existing technologies and determine what we can use that already exists. Sone guidelines so that companies don't produce monsters during the period of time that we don't have a well defined arch (paraphras
12:25:16 [chris]
ack chris
12:26:18 [scribe]
Chris: Several points. 1) with regard to knowing the architecture - I argue that we all genrally and itnernally know what we are doing (we need to write it down but this should not stop us from working). 2)
12:26:42 [DaveO]
+1 to chris point 1)
12:26:54 [scribe]
Q+ dbooth
12:26:56 [MarkB]
q+
12:27:58 [scribe]
We could also look at this as solving a specific as oppsoed to a generic problem. Clearly people have been trying to determine how to attach a dig sig to a message (for integrety). Everyone is looking for one way to do this.
12:29:30 [scribe]
The longer that we put off the WG the longer we have problems and peole are clamoring for the WG.
12:30:08 [Daniel]
q+
12:30:25 [chris]
ack martin
12:30:48 [DaveO]
q+
12:30:55 [scribe]
Martin: what you are saying is radically different than our current discussions (which are gneric rather than specific). IF we have something specific, fine.
12:31:35 [scribe]
Martin: We haven't said that a WS has a WSDL interface and SOAP.
12:31:36 [chris]
ack db
12:31:41 [scribe]
DaveO: yes, we all know this.
12:31:50 [jeffm]
q+
12:31:58 [scribe]
Martin: Independnet of that, by novermeber we must have first scketch of arch.
12:32:38 [Daniel]
Heather, you there?
12:32:47 [chris]
heather, you there?
12:34:01 [Heather]
yes...
12:34:19 [Heather]
got sidetracked for a few minutes
12:34:27 [omh]
q+ glen
12:34:29 [scribe]
Dbooth: (has put up ws slide that is back on the partitioning portions of a WS) charter include specifying what the conector is (common to all ws), second purpose is to propose WG for specific features.
12:34:36 [Daniel]
just pinging to make sure you aren't sleeping
12:34:49 [Daniel]
J/K
12:35:26 [scribe]
I believe that what we will find happening is this, each person will have a different view of the difivding line between features common to all ws and specific features for some ws.
12:35:38 [chris]
ack markb
12:35:54 [Heather]
(and of course IBM doesn't agree that web services must have soap, but I thought I'd save it for another day)
12:36:08 [Daniel]
lol
12:36:11 [HaoHe]
agree with Heather
12:36:40 [HaoHe]
but this sounds strange from IBM, since it started SOAP
12:36:56 [Daniel]
actually, it was MS
12:37:09 [scribe]
Mark: Chris' comment based on the premise that everyone nows what the ws architecture is. However, this view is not compatible with web architecture. The recent decition TAG on using SOAP with HTTP and having to use get implies that any SOAP 1.1. service out there today has to make use of get in a web arch compatible way. Most today use get in a web arch incompatible way.
12:37:10 [Heather]
i think we are going to have to divide our time between specific issues and the architecture like the tag
12:37:43 [Heather]
i too feel the need to get some broad agreed architectural brush strokes before we start chartering work groups....
12:37:52 [scribe]
Chris: How does the integrity issue make any differnce with the web architecture issue of using get or post?
12:38:08 [scribe]
Mark: Yes. it makes a difference. Your request is not digitally signed.
12:38:14 [Heather]
but, I also feel the pull of getting security solved by security gurus
12:38:26 [scribe]
Chris" I want to have a soap message that I can prove is the one that was sent to me (independent of request or response).
12:39:09 [Heather]
the actual implications on the existing runtimes remains to be seen
12:39:22 [Daniel]
q+ DavidB
12:39:25 [scribe]
DaveO: We are trying to get to the point where we have a security group and we talk about very specific requirements. But we aren't at this point.
12:39:26 [Heather]
(in response to Marks comment)
12:39:37 [scribe]
Mark: I agree that the security group is one of the most arch independent groups.
12:39:43 [HaoHe]
so, Heather, why IBM prompts non-soap ws?
12:40:00 [Heather]
IBM defines web services to be defined by wsdl.
12:40:06 [scribe]
Chris: The reason we are standardizing is that we have several solutions out in the martket today. We need a standard so that we can get to interoperability
12:40:11 [Heather]
wsdl can define bindings that are non soap.....
12:40:13 [scribe]
Mark: There are other things that need to interop.
12:40:21 [DaveO]
q?
12:40:36 [Heather]
non soap bindings will be very important for internal application integration and high performance
12:40:44 [scribe]
Chris: We are trying to scope this so that ....
12:40:53 [DaveO]
q?
12:41:08 [chris]
ack daniel
12:41:11 [HaoHe]
makes sense.
12:42:27 [scribe]
Daniel: Developers don't sit around and wait for architecture (as chris and DaveO point out). Also, as hugo points out we need to choose a middle ground. However, what I am hearing is that we haven't done the first ground work and once this is done we can parallelize and iterate.
12:42:29 [chris]
ack daveo
12:44:28 [scribe]
DaveO: Personally and professionaly commited to furthering both security and the architecture. We have been doing both the arch document and progressing, and also to getting a security WG in place. let's agree on a process of splitting our work between creating working groups and architecture.
12:44:32 [Heather]
i'm not sure we need for the ground work to be DONE
12:44:36 [chris]
ack jeffm
12:46:58 [Heather]
q+
12:47:23 [scribe]
JeffM: We have an abstract defn of a ws. there are concrete instances of WS. Regardless of what beautiful abstractions we create, people build WS with SOAP over HTTP, they use WSDL and those people who are shipping product have a real need to secure their messages. Interoperability important... let's realize that there is a two part reality (arch and time to market). Advocates chartering WG now and then working on the arch.
12:48:20 [chris]
q- glen, david
12:48:50 [Heather]
what did glen and david say?
12:49:04 [chris]
heather, you're up in a moment
12:49:10 [chris]
glen abdicated his spot
12:49:13 [DaveO]
david is speaking and glen abdicated.
12:49:19 [MartinC]
q+
12:49:19 [Heather]
k, thanks
12:49:20 [scribe]
David: Likes prposal of dividing time between arch and charter for WGs. Phrases this in term of the partitioning proposal.
12:49:23 [chris]
tag, you're it
12:49:28 [chris]
type away
12:49:54 [scribe]
heather type
12:49:54 [Heather]
what if we compromise on this... can we make a concentrated double time effort (extra ccalls)
12:50:04 [Heather]
to get broad brushes to the architecture
12:50:08 [Heather]
that we agree on
12:50:12 [jeffm]
the crowd moans......
12:50:15 [chris]
the crowd goes ooooooooh
12:50:17 [scribe]
general ooooo
12:50:17 [Heather]
and THEN define the security working group?
12:50:22 [Heather]
bad ooh?
12:50:29 [Daniel]
middling oooo
12:50:32 [scribe]
not clear that this was a bad oooo
12:50:34 [Heather]
Just 2 weeks
12:50:39 [Heather]
big time deadline
12:50:41 [chris]
no, that was a combination interesting, but... ooooooh
12:50:58 [Heather]
or else the security workgroup creation guys win and we make one w/o waiting for the arch guys
12:51:22 [scribe]
Chris: points out that DaveO and chris already do this and they are up for it.
12:51:30 [tc]
q+ DavidB
12:51:30 [Heather]
this would motivate the arch guys to NOT argue about how many angels can dance on the head of a pin
12:51:52 [DaveO]
q+
12:52:03 [Daniel]
hey, I'm working on Angels-on-pinhead ML 2.0 already
12:52:05 [chris]
ack heather, martin, davidb
12:52:06 [Heather]
and its easier to dump a lot of time into something if you know its a short duration crush
12:52:16 [scribe]
Dbooth: nothing against the idea of doing double time but not realistic. Difficulty getting people to read documents and participate
12:52:19 [Heather]
ok... flame away
12:52:36 [chris]
q-
12:52:43 [chris]
q- heather, martin, davidb
12:52:44 [HaoHe]
q+
12:52:50 [chris]
ack dave0
12:52:54 [chris]
ack daveo
12:53:16 [scribe]
DaveO: will try to interpret heathers proposal. For two weeks do double itme and whatever we get done is whatever we get done IF we haven't made good progress , too bad. this is how things work in a real company.
12:54:14 [scribe]
I agree with dbooth on the double time thing. For me double time does not really work. If there is heartburn over spl;itting time between general arch and security, I can live with speding the next 2-3 weeks on arch and then the next 3 week after that we can focus on security
12:54:20 [chris]
ack hao
12:54:42 [scribe]
soliton: Maybe we can divide into task forcces as the groups are large.
12:55:17 [scribe]
Chris: (frustrated) all for double time but is it realistic to expect people to do the work.
12:55:34 [scribe]
Chris: Architects want to work on everything.
12:55:46 [Heather]
thats why i suggested single threading it
12:55:53 [Heather]
instead of parrallel...
12:56:09 [Heather]
a concentrated effort to get something down on paper
12:56:48 [Heather]
a few people would have to 'sign up' to work very hard
12:56:57 [DaveO]
q+ dbooth
12:57:07 [Heather]
and the rest of the wg would have to agree to do short turn around reviw...
12:57:12 [chris]
ack db
12:57:15 [DaveO]
q-
12:57:17 [tc]
q+
12:57:18 [scribe]
scribe: Zulah: we have been successful in having small groups make proposals. We could have a few people work on aan architecture fundamentals and at the same time have a group do the security charter. Then bring it back so that we have something to discuss.
12:57:23 [Heather]
and chris i sympathize in that we have not been good at fast anything
12:57:32 [scribe]
Dbooth: Liked DaveO's proposal, what happened to it?
12:57:57 [scribe]
Glen: We almost got there and then the taskforce idea came up and I am infavor if the latter.
12:58:09 [scribe]
DaveO: at some point the task forces have to report back.
12:58:39 [scribe]
Dbooth: would these be taskforces for things that need charters and the architecture fundamentals?
12:59:44 [scribe]
Chris: So my problem as chair is the schedule. I am not a manager. I am not schedule driven usually but I am now. We have 5 weeks before we take a 1 month break.
13:00:20 [HaoHe]
other people can keep going during the break
13:00:27 [scribe]
So we have 5 calls. And if we have 4 task forces working on different things theen there is no time to have them all report back in time for the 18th (or so) of July (when we have to report).
13:00:39 [scribe]
q+
13:00:46 [DaveO]
q+
13:01:05 [chris]
ack tc
13:01:37 [chris]
ack scribe
13:01:38 [scribe]
Tomc: I tend to like the idea of "taskforces". Someone ususally put up a strawman. THis is the most likely way to make progress.
13:02:06 [omh]
omh has joined #ws-arch
13:02:12 [Heather]
what about bumping up the call schedules?
13:02:16 [Heather]
or making it longer?
13:02:34 [DaveO]
Heather, there's been a fair bit of pushback on extra time...
13:02:42 [scribe]
Zulah: has managed and pontificated a bit
13:02:44 [chris]
zulah: create a scheduel for 5 weeks and see what we can get done
13:04:11 [scribe]
DaveO: has put up a straw man. I would like to have two task forces. The security and the existing architecture (harvested from SOAP and WSDL).
13:04:47 [Daniel]
zulah pontificates again, +1
13:04:50 [Daniel]
ing DaveO
13:04:55 [omh]
+1 on Dave0
13:04:58 [chris]
zulah: conceptual architecture is important
13:05:06 [scribe]
Glen: do we want to volunteer people now, mailing list, plan?
13:06:35 [DaveO]
How about: 1) Architecture document; 2) Security, including usage scenarios/use cases and requirements.
13:06:47 [scribe]
Chris: DaveO has proposed one taskforce for security WG charter, and another for architecture (where architecture is working with the editors to determine first cut of arch document).
13:06:57 [DaveO]
q+
13:07:09 [tc]
q+
13:07:09 [scribe]
Joe: inside the doc there is a securith section and this needs to be filled out.
13:07:13 [scribe]
q+
13:08:12 [chris]
ack daveo
13:08:12 [HaoHe]
q+
13:09:05 [scribe]
DaveO: we formed this use case task force to try to make progress on a document. We agreed on terms but have not agreed on a single use case or scenario. So, we could agree to the "harvesting" task force (SOAP WSDL), and a second team is the security group and they are constrainted to the use case and usage scenarios that are specific to security. (So Dave has suggested that we slice things a different way as they relate to use cases).
13:09:25 [scribe]
Joe: Trying to understand more clearly how security and the arch document relate.
13:09:46 [scribe]
MikeM: How would this be more useful to the use case task force?
13:10:40 [scribe]
DaveO: The directed discussion abou tsecurity almost alowed us to articulate trequirements and to connect scenarions and use cases. So the security folks flesh out the scenarios.
13:10:53 [tc]
q-
13:11:03 [chris]
ack scribe
13:11:49 [chris]
ack hao
13:13:03 [scribe]
Soliton: When people see documents they seem like they are pregiven. need process....
13:13:28 [scribe]
Chris: What if the arch guys come back with a doc, what makes you thin kit would be received differently
13:14:12 [scribe]
Glen: There is another complementary idea that somethime when you have a concrete thing to look at it provides a framework for discussions.
13:14:25 [Heather]
can the scenarios work just focus on security issues right now?
13:14:48 [scribe]
q+
13:14:50 [DaveO]
Heather, that was my suggestion.
13:15:27 [MartinC]
MartinC has left #ws-arch
13:15:49 [Heather]
glen, +1
13:16:01 [omh]
omh has left #ws-arch
13:16:10 [scribe]
zulah: Need to continue with the use cases and we need to try to gather them from other organizations. So I agree with heather but I also think that we should not forget the importance of high level use case gathering.
13:16:17 [scribe]
Chris: Break
13:16:27 [DaveO]
zulah, I agree with you on that.
13:16:36 [Heather]
i don't want to forget to gather other use cases, there are a few I'd like to add...
13:16:58 [Heather]
can we just concentrate on some immediate issues and then look up to the bigger picture in a few weeks?
13:17:23 [omh]
omh has joined #ws-arch
13:17:27 [Heather]
if we take some brush strokes at the archicture... then we'll have something to tune as we work thru the use cases
13:18:14 [scribe]
Heather, break for 15 mins
13:18:15 [Heather]
did you guys break on me?
13:18:20 [DaveO]
I suggested that too heather.
13:18:20 [Heather]
k...
13:18:27 [omh]
omh has left #ws-arch
13:23:11 [mikem]
we just broke....
13:30:54 [Daniel]
we feel broke too
13:40:50 [Heather]
i'm here... ya'll back yet?
13:42:02 [chris]
we're baaaack
13:42:29 [Heather]
i'm concerned if we have too many task forces (even 2) we won't get the concentrated work from people to comment and agree on the architecture
13:42:53 [scribe]
chris: Who is willing to contribute their effort to one or the other task force.
13:43:08 [mikem]
mikem has joined #ws-arch
13:43:10 [scribe]
Zulah: need clear statement of what each group will do
13:43:14 [chris]
i shared the same concerns earlier
13:44:11 [DaveO]
Security: Refine usage scenarios and requirements relating to security, particularly the 6? sections.
13:44:43 [dbooth]
dbooth has joined #ws-arch
13:45:00 [DaveO]
Harvesting: Look at the WSDL conceptual model and the XMLP MEP and bindings work and harvest architectural material.
13:45:06 [DaveO]
Reliability:
13:45:07 [scribe]
Chris: Looking for people to join either task force. We have DaveO, Joe, Hao, Mike, Tom, Daniel, Hugo, markb, dbooth, glen, eric
13:45:27 [hugo]
MartinC also wanted to participate
13:45:35 [DaveO]
Use Cases: Add use cases with individual owners: Zulah, Hugo, ?
13:45:42 [Heather]
if we serialize this.... i can do both
13:45:59 [Heather]
if we go parrallel we miss come companies's views on both groups...
13:46:55 [Heather]
i tthink the havesting work is VERY important!... so if i choose, I choose that one
13:48:42 [scribe]
Reliability Task Force: Responsible for re-working AG002. Timeframe?
13:49:11 [scribe]
2 weeks.
13:49:40 [Daniel]
q+
13:50:08 [HaoHe]
Actually, I will be in the US for the next two weeks, so we can talk a bit more
13:50:32 [HaoHe]
for the reliability work
13:50:52 [HaoHe]
q?
13:50:56 [dbooth]
q+
13:50:58 [chris]
ack scribe
13:51:28 [scribe]
Daniel: DaveO pointed out that use case is ongoing. What does this mean. We have closed requirements. so what are the use cases good for after we close requirements.
13:51:47 [scribe]
Chris: We will iterate.
13:52:25 [scribe]
q+
13:52:45 [Heather]
i agree with davido that usecase is on going in parrallel with architecture
13:52:52 [DaveO]
lol
13:53:13 [scribe]
Daniel: understand iteration, trying to understand you and Hugo's view point. We will publish the requirements document as a note. Does htis imply that we won't do this for a long time (as not to make changes to the note).
13:54:15 [scribe]
Chris: The way we handled this with SOAP is that we have had a frozen requirements doc that we have gone back and updated. So we don't publish a note until we are done with the doc. The doc is a wg document for the life of the wg, when our chrter expires, then we would publish the note
13:54:45 [Heather]
ok
13:54:46 [scribe]
Hugo: requirements docs we work on early and we may modify it. It is kept open through the WG and then frozen at the end.
13:55:09 [scribe]
Dbooth:
13:55:26 [scribe]
I see 5 things that chris has doen on the board. Not clear on the proposal.
13:55:42 [scribe]
Chris: there are four and yes this is the proposal. This proposal adds two task forces.
13:56:01 [scribe]
Dbooth: There was discussion about arch fundamentals effort?
13:56:13 [scribe]
Chris: This is the harvesting.
13:56:18 [scribe]
general disagreement
13:56:22 [chris]
ack daniel
13:56:27 [chris]
ack dbooth
13:56:39 [scribe]
Joe: is this the same as what mark has been evangelizing
13:56:44 [scribe]
Dbooth: similar
13:57:02 [Heather]
i thought harvesting was arch fundamentals too....
13:57:05 [scribe]
DaveO: I was suggesting that we begin with material that already exists
13:57:56 [chris]
ack scribe
13:58:24 [Heather]
so lets rename harvest to Architectural Fundamentals and assume that they will leverage existing work (like they have a choice)
13:58:33 [dbooth]
q+
13:58:34 [scribe]
Dbooth: a task force that will try to pin down...
13:58:42 [Daniel]
naming something "architectural
13:58:57 [Daniel]
anything will probably result in social issues in the group
13:59:28 [DaveO]
q?
13:59:28 [Heather]
i'm not sure that nameing will prevent social issues :-)
13:59:31 [DaveO]
q+
13:59:31 [dbooth]
Zulah: What you have up for use cases differs from what we've been discussing. I think the UC team should gather high level use cases and put them into acceptable form. I think the security team should focus on scenarios and how they relate to use cases over time.
14:00:15 [HaoHe]
q+
14:01:28 [scribe]
Zulah: Also, My assumption was that we would take some tiny steps with the architecture. That is, that we would first determine what is already out there wrt architecture and then come back and refocus a taskforce to do some more of the fundamental work. This will alleviate the concern that a small group is going to go off and bake the core architecture.
14:02:21 [scribe]
Chris: Timing, harvesting 3 weeks, reliability 2 weeks, security 4 weeks,
14:02:28 [scribe]
Use cases on going
14:02:38 [scribe]
So we have:
14:02:55 [scribe]
Use cases: gather use cases, ongoing
14:02:58 [chris]
ack db
14:03:14 [scribe]
Reliability: focus on rewording AGoo2
14:03:18 [scribe]
4 weeks
14:03:49 [scribe]
Harvesting: harvest from SOAP and WSDL, existing - 3 weeks
14:04:19 [scribe]
Security: scope requiremenst for charter, technologies to be used, usage scenario work
14:04:53 [chris]
ack daveo
14:05:04 [mikem]
q+
14:05:10 [scribe]
Dbooth: Architectural principles are not something that we can or should ignore. Also taskforces are efficient work.
14:05:41 [scribe]
DaveO: Keep harvesting taskforce andh scope them to only look at existing stuff. As opposed to a blank check to do architectural principles.
14:06:03 [dbooth]
q+
14:06:04 [scribe]
If they agree, let's then try to extract some architectural principles out of that. A starting point.
14:06:27 [chris]
ack hao
14:06:35 [scribe]
If the harvesting taskforce becomes the arch fundamental task force then it is too broad (paraphrasing)
14:06:44 [DaveO]
thanks scribe ;-)
14:06:46 [Heather]
the other groups do not address publication and discovery of services... an important aspect
14:06:52 [Heather]
we can't just igore that!
14:07:20 [scribe]
Soliton: In the reliability group, the management stuff didn't get enough comment. I woul dlike to see emphasis on management.
14:08:12 [chris]
soliton == hao
14:08:16 [dbooth]
Zulah: I also would like to see emphasis on WS mgmt. I know Heather has a paper on mgmt, and HP is interested. It's a big hunk to chew off, and there are so few people in the room with a direct commitment to it, that we need a firm statement before we can move forward.
14:08:24 [Heather]
won't the reliability group still be doing management????
14:08:29 [chris]
ack mike
14:09:01 [scribe]
Mikem: Wanted to +1 DaveO's comment on scoping the harvesting task force. The result of that work will feed into something that will lead to what others (dbooth) are looking for.
14:09:44 [chris]
ack db
14:10:05 [scribe]
This would also lead to more of a boxes, interfaces, constriants view of architecture that I am used to. Also, we have not listed all of the functionality of the architecture (discovery registration) and these basic functions are missing. The arhitecture doc is starting to address this.
14:10:39 [scribe]
dbooth: I agree that the taskforce would be too broad. So, where do the arch principles get done? Where does a strawman proposal get baked (paraphrased).
14:11:09 [scribe]
The question is how do we arrive at the architectural principles. Do we do this by the entire group or do we assign a task force.
14:11:10 [scribe]
q+
14:11:56 [scribe]
Chris: What I hear is that you want to focus on the architectural principles and I'm not sure that I am ready for this.
14:11:59 [MarkB]
q+
14:12:05 [tc]
q+
14:12:29 [Heather]
q+
14:12:43 [scribe]
Dbooth: another way to think of it is that if we spin off several working groups that would define the requirements that would ensure ethat the results of the working group would work well together. Do we want a task force for a straw man proposal for arch fundamentals.
14:12:47 [joe]
q+
14:12:52 [chris]
ack zulah
14:12:57 [chris]
ack scribe
14:13:25 [dbooth]
Zulah: My concern is that we need to stage the work to create an arch. The harvesting is important and needs to be done first.
14:13:39 [dbooth]
... To go away and do fundamentals before that would be a mistake.
14:13:49 [chris]
ack mark
14:14:28 [scribe]
Mark: Wants to say what he thinks david booth is trying today. The fundamentals are like going to our glossary. What are the components, what do they look like, how do they interact.
14:14:30 [chris]
ack tc
14:14:52 [chris]
heather, you're up next
14:15:08 [Heather]
k
14:16:42 [scribe]
TomC: I tend to agree with Dbooth with regard to defining a minimal set of usage cases. Mark discussed the components how they relate, ... a minimal set of usage scenarios would allow you to determine what Mark is asking for. Then you can delegate off to the security task force to work from the basic use cases. That is, that they start from the use cases as a description of the minimal architecture. These would also specify the requirements (paraphrasin
14:17:00 [dbooth]
ack heather
14:17:05 [chris]
type away
14:17:06 [Heather]
i am very confused....
14:17:30 [scribe]
are you typing more detail?
14:17:30 [Heather]
i thought that we were precisely at the point where we need to start creating components and interactions...
14:17:45 [Heather]
the start of this is in dave0's draft already
14:17:53 [Heather]
i must not understand what harvesting is....
14:18:13 [Heather]
i THOUGHT it was factoring in the xmlp and desc groups work into that components and relationships layout
14:18:34 [Heather]
if we're NOT ready to do comopnents someone please tell me what we ARE ready to do...
14:18:41 [scribe]
that seems accurate heather
14:18:48 [chris]
objects?
14:18:48 [scribe]
beer!
14:18:51 [DaveO]
Heather, the issue with the arch doc as it exists is that many were confused about the conceptual model. So Glenn suggested a more explicit harvesting of wsdl and xmlp material.
14:18:52 [Heather]
and If i'm too confused to straighten out on irc... then someone please help me out next week on the phone
14:19:11 [MarkB]
components are things like "sender" "receiver", "intermediary", etc..
14:19:18 [MarkB]
chunks of software
14:19:21 [Heather]
sorry daveo... your conceptual model confused me too...
14:19:22 [scribe]
heather, I don't think that you are confused
14:19:34 [Heather]
i think it needs work .. words to go with it and explanations
14:19:35 [Heather]
thats ok
14:19:38 [tc]
q+
14:19:58 [Heather]
yes... and we need a soa diagram with service provider, requester, registry, description all laid out
14:20:03 [Heather]
we all have this picture
14:20:13 [scribe]
Joe: What DBooth said about the importance of the conceptual model then just do one without waiting for the taask force.
14:20:15 [chris]
don't think you're confused... problem is that there's a gestalt delivery problem...
14:20:19 [MarkB]
cool, where?
14:20:31 [scribe]
Joe: I want to see more specifics to determine what I want to buy into
14:21:05 [scribe]
DaveO: are we going to have a fundamentals of WS taskforce over the next few weeks?
14:21:12 [scribe]
Chris: No, this is off the table.
14:21:13 [Heather]
Dave's diagram is ONE swag, not seen or agreed on before this meeting... take it for what it is and lets work on it
14:21:39 [Heather]
gestalt????
14:22:07 [scribe]
chris: micromanagement (paraphrasing)
14:22:22 [Daniel]
chris means "all at once"
14:22:49 [scribe]
Chris: realising when we bring something back to the group it takes a good deal of time to get something approves and to get people bought in.
14:23:10 [Daniel]
6 weeks not being sufficient time to complete all the tasks....we can only boil the universe one drop at a time
14:23:19 [Heather]
yes, but thats why we have to design by strawman, not by committeee
14:23:31 [Heather]
(how many angels is that?)
14:23:49 [mikem]
q+
14:23:59 [scribe]
chris: four taskforces seems excesive but this is probably our minimum. So process wise, I just don't see how we are going to work another task force. I don't think that there will be simple agreement on "every web service has one of these", then there are philosophical problems (WSDL -> WS, SOAP -> WS, others).
14:24:20 [scribe]
I don't sense a full appreciation for the fact that there is a core set of things.
14:24:24 [Daniel]
<pin><head><angels number=50 /></head></pin>
14:24:28 [scribe]
Mark: There is a definition, all things have a URI.
14:24:50 [tc]
q-
14:24:52 [DaveO]
not-wellformedness error
14:25:33 [scribe]
Dbooth: I understand then that the fundamental principles will come out later from the working group.
14:25:40 [scribe]
Chris: Yes, I believe that they will come out later if they exist.
14:26:02 [Heather]
+10! chris!
14:26:22 [MarkB]
if they don't exist, we're in a whole lot of trouble 8-)
14:27:04 [Heather]
these philosophical problems chris mentioned need to be argued and agreed on (even if grudgingly) before we can solve other problems
14:27:20 [scribe]
Chris: Right now for this next 6 months, I do not believe that the group is prepared to deal with another task force and I still don't quite Grok "what it is" that we wouldwant from this taskforce.
14:27:28 [Heather]
the architecture and security solutions will be VERY different if there is a guaranteed SOAP layer ... or no.
14:27:38 [DaveO]
scribe: should be 6 weeks rather than months..
14:27:42 [joe]
q-
14:27:51 [Daniel]
An architectural principle is a statement of constraint that does not change due to technological change
14:28:26 [MarkB]
right on
14:28:43 [Heather]
whatever arch principles we have will fall out as we work iteratively w/ use cases and a draft arch.
14:28:50 [scribe]
Daniel: on the conceptual level, there is no way to make this happen in tis short of a timeframe.
14:28:56 [Heather]
i don't think we can state them up front
14:29:06 [dbooth]
q+
14:29:12 [Heather]
the timeframe is a problem...
14:29:14 [Daniel]
I don't disagree heather, just wanted to offer a defn.
14:29:19 [Heather]
perhaps we should be fixing that one..
14:29:33 [Heather]
(Thanks Daniel... I needed the definition, its a good one)
14:30:35 [scribe]
Chris: Its 4:30 (for some of us). Straw poll, how many people think that the four task forces (use cases, reliability, harvesting, security) are the ones that we should focus on for the next 6 weeks?
14:30:41 [scribe]
(result was a majority)
14:31:06 [scribe]
Chris: How many people think that we don't have the right set of work and that we need to work with the architectural principles?
14:31:32 [scribe]
Chris: So, these are the task forces and I will pick some participants and victims to be chairs.
14:33:05 [chris]
use case - gather use cases (edi, travel, others) ** ongoing, but with 4 week freeze for pub
14:33:06 [chris]
harvesting - outline, etc (clam digging in WSD, XMLP, elsewhere identify
14:33:06 [chris]
conceptual model aspects like the SOAP process model and WSD extensibility) ** 3 weeks
14:33:06 [chris]
reliability - focus on proposals for D-AG002 (keep on keeping on) ** 2 weeks
14:33:06 [chris]
security
14:33:08 [chris]
- scoped requirements for charter
14:33:09 [chris]
- technologies to look at
14:33:14 [chris]
- usage scenarios work focus on security (s61, s62, s63, s64, ...) ** 4 weeks
14:33:45 [chris]
use cases TF responsible for "harvesting" uc and us from other orgs (OASIS, OTA, RosettaNet, etc.)
14:34:02 [DaveO]
q?
14:34:20 [chris]
ack mikem
14:35:14 [scribe]
Mike: I think that we are going round and round on the obvious. One mandatory view is to describe the components, their interfaces, and connections between them. Message exchange patterns are something that we see over ad over again. Usage scenarios help us get to this but as a spec writer I will be more interested in seeing the more concrete ...
14:35:16 [chris]
ack db
14:35:32 [scribe]
Chris: its a wrap then...
14:35:46 [DaveO]
that trout gets around..
14:36:03 [DaveO]
something smells fishy...
14:36:20 [Daniel]
thanks, Dave0
14:36:26 [dbooth]
q+
14:36:58 [scribe]
Heather, we are done. Any confusion can be cleared up via phone calls next week. Have a great weekend!
14:37:05 [Heather]
k
14:37:11 [Heather]
yall have a good flight home
14:37:16 [tc]
tc has left #ws-arch
14:37:23 [scribe]
Hao, you and me should do an early phone call next week to deal with 007
14:37:32 [Heather]
me too
14:37:44 [Daniel]
l8r
14:37:53 [scribe]
sorry, that was to you heather ;) I'll talk to you both by email on monday.
14:38:09 [Heather]
k..
14:38:10 [Heather]
by
14:38:14 [zulah]
adios
14:38:15 [Heather]
thanks all!
14:38:27 [zulah]
zulah has left #ws-arch
14:42:20 [chris]
rrsagent, where am i
14:42:21 [chris]
I'm logging. I don't understand 'where am i', chris. Try /msg RRSAgent help
14:42:35 [chris]
rrsagent, where am i?
14:42:35 [RRSAgent]
See http://www.w3.org/2002/06/14-ws-arch-irc#T14-42-35
14:43:04 [chris]
rrsagent, please excuse us
14:43:04 [RRSAgent]
I see no action items