[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft teleconf minutes for 18 August 2005
Attached is the draft of the minutes. Please notify if you feel there is anything missing or incorrect and I'll fix it before I upload this document (probably on Monday). I'm sorry for the parts that simply say (back and forth) but when everyone talks at once it is very hard to catch what is being said. - g
1:02PM Roll-call starts 1:08PM Roll-call ends (results here); 32 out of 53 (6 minutes for roll, not bad. - ed.)
Tom: (provides a high-level overview of the agenda) Marc: Can we limit the debate on the use cases? Tom: To what? Marc: 15 minutes Dave Orchard: Don't raise any objections and there won't be any problems. Tom: Does anyone motion to approve the minutes from the last meeting? Rich Salz: Motions to approve the minutes from the last meeting. Anish Karmarkar: Seconds. 1:13PM Tom: Motion passes.
#0013 – remains open, no update #0016 – no progress. Marc recommends that we set a deadline for resolving this. Anish: Who is on the team. Marc: Gil and Duane Tom: Does anyone else want to join? Anish: I would like to. (general agreement to work out membership for interop team over email) #0018 – Marc; I've attempted to fix the URLs. There are still problems with the XSL when using the public links. AI remains open. #0022 – Done; close it. #0023 – Done; close it. #0024 – Andreas is not on the call. Will have to remain open.
1:16PM (Proposed Issue #0001) Jacques: Has been reworded so that it does not assume that TerminateSequence will be sent. If there are gaps in a sequence and the RMS still wants to stop using the sequence (won't send any more messages). In such cases the RMS may still want to have a precise account of what messages have been received by the RMD. This issue is very close to i0019, which is the same issue except that the RMD has decided to terminate the sequence based on a fault. No objections; issue added. (Proposed Issue #0002) Gil: So WS-RM is dependent upon WS-Security (WSS). This dependency isn't necessary and it causes problems both in the usability of the spec (in terms of negotiating the use of the STR between the RMS and RMD) as well as for people trying to implement the spec (they have to include an implementation of WSS). Marc Goodner: I have a problem with an issue that is in direct conflict with the charter. Charter calls for composition with WSS. Martin Chapman: I think the issue is how we compose WS-RM and WS-Security. Chris Ferris: What alternatives are there to WSS? In any case, where is the tight coupling? This is an optional feature. Gil: There are a number of different ways of doing security. Paul: Asks Mart Chapman what his alternatives are? Mart Chapman: Don't have one right now. Paul: (Addressing Gil's point) Point-to-point solutions won't cut it. We need an alternate way. WSS is extremely important and we can't just throw it out. Dave: This exact issue came up in the charter. We had a number of discussions about changing the charter around this exact issue. Microsoft's position at that time was that we couldn't change the charter because we didn't have a specific issue. Now we're being told we can't raise this as an issue because of the charter. While I appreciate what the charter says, there are other mechanisms for preserving the integrity of the context. To address Chris's point; its hard to see how it could be any more tightly coupled (missed some stuff) Chris: The STR is optional, which means optional to implement as well as optional to use. A service is not required to support it, that's what optional means. We could be a little bit tighter in the spec about the fault mechanisms if it isn't support it. I don't understand why we would want to remove it. If you want to protect the integrity of the sequence the only way to do it is to tie it to a set of credentials. Anish: I think the discussion is getting into a debate about the proposal. I think we need to concentrate on the issue. At the core this concerns the tension between composability and flexibility. Gil: Can we just accept this as an issue and move on? Paul: David spoke directly about some discussions that took place during (prior?) the forming of the charter. I wouldn't have permitted this (missed some of this) Tom: Is anyone opposed to adding this as an issue? (none) 1:33PM: (proposed issue #0002 added to issues list)
(some discussion about whether or not we need to read the motion - not read) Jacques: Comment on the second bullet item. Can you be more specific? I would assume that the first part of the process would be used. Gil: Use cases get added to the use case document the same way issues get added to the issue list. Once in the use case document the working group has to decide if they are “in scope” or “out of scope” for the current version of the spec. Jacques: So the first phase is to decide whether or not the issue is relevant to this group. The second phase to decide whether to decide whether. Gil: Yes. Paul: I'm going to vote against this. It will divert the TCs resources into a non-normative, non-exhaustive doc who's applicability to the work of the TC is unclear. Marc Chapman: Is there a motion on the floor? I think its silly to discuss things with out a motion on the floor. All: (murmurs of agreement) Tom: We are just discussing the wording of the motion. Anish: The process for handling use cases is very similar to the process for handling issues. Gil: Makes the motion based on the text of the email. (somebody): Seconds it. Gil: (in response to Paul) I think we're going to end up wasting way more time discussing issues w/out the context of the use cases that motivate them. Ashok: (question for Paul) We've been doing standards stuff for a while. You have always been an advocate of use cases. I'm suprised that you are asking that we do not do this. Paul: I won't disagree with you. I take it you are referring to XQuery? That effort started with a blank slate. This TC started with completed specs as well as interop scenarios. I think this effort is beyond the need for use cases. Jeff Mischkinsky: Then is this TC just supposed to be a pure rubber stamp? I'm assuming that the people that wrote the contributed specs had some use cases? What is the harm of surfacing those? Tom: Anybody opposed to accepting this motion? (some people): Yes Tom: (starts to conducts vote) Jacques: Can you restate exactly what 'yes' and 'no' mean? Duane Nickell: I just joined the call. Steve: Marc moved to limit discussion. Does that mean we've limited discussion to just this call or on the mailing list as well? Martin Chapman: A motion is on the floor. We are voting on it. Gil: (reads the motion) Add use cases to the working group's process with the following guidelines:
Lei: We decided at the F2F that we wanted to use use cases. 1:48PM Tom: (conducts vote - again) 14 - yes; 8 no Paul: How many abstained please? Tom: 9 abstained Steve Carter: I abstain. Johnathan Marsh: (after finally unmuting himself) I vote no. Tom: Do we need a majority? Jeff: No. Just count the votes. (somebody) "Abstain" means "I silently agree with the majority". Tom: 14 - yes; 9 - no; 9 abstains (1:54PM) motion passes (again)
i0007 - WSS 1.0/1.1 token support Chris: The version of WSS does not matter. I see no reason to add normative reference to specs that are needed. We are only referencing the WSS STR from 1.0, but it is not changed in WSS 1.1. Tom: Does anybody else have any dicussion? Marc Goodner: At the F2F there was some discussion as to whether WSS 1.1 tokens were OK. Although it looks like they are the same, we should clarify this for the implementers. Chris: It's premature at this time since WSS 1.1 is still underway. Marc: If that's what you think we should defer the resolution of this issue until WSS 1.1 moves to the next stage. Doug Bunting: Its whichever comes first. If it changes state before we are done we can revisit this issue. If we are done before WSS 1.1 finishes we will have to make up our minds. (general agreement) Paul: What status does i0007 go into? Marc: "deferred" (issue status changed to “deferred”) i0015 - Required Artifact Metadata Marc: (general discussion of i0015, i0016). Some parts of i0016 are determined by what we decide on i0015. Marc: (reads current proposals – follow the link) Marc: I would suggest artifact names of "WS-RM" and "WS-ReliableMessaging". (some back and forth) Tom: Proposal is to use "wsrm" and "wsrmp" as the product names. (more back and forth) Paul: Can someone tell me what an "artifactName" is supposed to be? Gil: That's just the problem. (general conclusion is that the AR guidelines are not clear on what an “artifactName” is. Marc: Let's just remove the "artifactName". (back and forth) Peter Niblett: Moves to close the issue with the proposed solution. Marc Goodner: Seconds (none opposed) 2:07PM - i00015 is closed; status is moved to pending. Final values are: WS-ReliableMessaging: tc: wsrx product: wsrm productVersion: 1.1 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Protocol Specification WS-RM Policy: tc: wsrx product: wsrmp productVersion: 1.1 artifactType: spec stage: wd descriptiveName: Web Services Reliable Messaging Policy Assertion Specification Tom: i00016 is pretty straightforward? Marc: Yes, this should just flow from the values we decided to on i0015 (posts values to chat system). Martin Chapman: What's the final 01 about? Marc: That's the editors revisions. Martin: Are we going to have a primer or something? (all): Not at present. Martin: Then why do we need to have 'spec'? Chris: Because the AR guidelines say so. (back and forth) Martin: I would like to drop the 'spec' (more back and forth) Martin: (agreeing to leave 'spec' in) We can open a new issue if we need to tweak this later. 2:11 PM - motion passes; issue i0016 is closed; status moved to pending. Final values are: wsrm-1.1-spec-wd-01.* wsrmp-1.1-spec-wd-01.* Chris: Proposal is: http://docs.oasis-open.org/wsrm/yyyymm/ http://docs.oasis-open.org/wsrmp/yyymm / Marc: We can revisit this when the AR guidelines are finalized. Paul: That would be the URI for the RDL document? (yes). The RDL document would point you at the schema file? Chris: The actual name of the schema file would be something like (missed details). Paul: That would be the dated schema? Would we have a URI for the latest version of the schema? Chris: ??? Paul: Is the choice of this URI going to have any impact on how we name the schemas? (back and forth) Paul: Would there be another, more stable URI, that didn't have the date built into it but instead just took you to the latest schema? Chris: I think this is a separate issue. Paul: You guys have been debating this, so I'll trust you on this one. It looks fine for now. The editors are going to have to figure out what the URI for the schema is. Chris: We could put a link to the latest schema in the RDL doc. Peter Nibblet: Are we going to put a schema location in the WSDL file? (Paul and Peter - back and forth) Peter: Are we going to have a policy for what goes into the YYYMM? What values will we use, etc.? Gil: The editors are working on it. Paul: Rasie that as a TC issue. Peter: I don't like the idea of voting on a date if I don't know what the date is. Marc: The editors have been working on the form, not the values. Chris: I've been making a recommendation that we go with any date (today would do) but we should only ever make a change to the URI if and when there is some incompatible change to the schema. We may want to defer this until the schema and spec solidifies. The W3C just uses placeholder values. (Chris and Marc - back and forth) Paul: We need to clearly state what our namespace evolution policy is. I have no problems with the proposed policy, but we get into problems when people don't know what the policy is. Chris: Do we want to defer this? Paul: We should to defer this until we have explicit text. Gil: We need to take down an action item and assign it to Chris: (agreed) Assign action item to Chris Ferris: Compose the "namespace change policy". Paul will help with contributed text. Paul: I think this is orthogonal actually. Tom: So you are willing to accept the proposal? Paul: Personally, yes. Tom: Are you ready to make a motion: Paul: Motions to accept the URIs. Marc: Seconds the motion. 2:25PM (no discussion, no opposition) - i0017 closed; status moved to pending; Final values are: http://docs.oasis-open.org/wsrm/yyyymm/ http://docs.oasis-open.org/wsrmp/yyymm/ i0019 - Sequence termination on Fault Tom: Jacques, you sent the latest mail. Jacques: As you can see on the email, there is agreement on what the solution should be. We need to flush out the details. Doug Davis: Can we get a sense from the TC if they agree with our general direction? (provides overview of solution – see http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200508/msg00103.html) Tom: You can come up with a very tight proposal for the next meeting? Doug Davis: Yes. Anish: Does your proposal address both i00019 and "proposed 0001"? (back and forth) Doug: I think our proposed solution covers both issues. Jacques: Essentially yes, but there needs to be some more detail: Chris Ferris: In the last emails we exchanged, there was some sense that the "Final" attribute would take care of i0019 and that "Closed" would take care of "proposed 0001". Anish: (basically agrees) Stefan: I have an issue regarding the proposal for the "Close" message. I think there are issues with how that composes with ordered delivery. I don't have time to go into it now . . .
Tom: Ok, we're out of time. Paul, you posted more info about the F2F accomodations. Paul: Yes, its in on the list. Tom: The meeting is over, and next week we'll have the normal chairs. (all): No. Paul: Do you have a secretary for the next meeting? Tom: No. Paul: I suggest you get one now. Tom: Any volunteers? (all): (deafening silence) Addendum: Roll Call and Voting
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]