Prelim Minutes WSRM TC Conference Call –Nov 01, 2005

The meeting of the WSRM  TC took  place by teleconference

Time Tuesday, 1 November 2005, 05:30pm to 06:30pm ET

1 Draft Agenda:

1) review agenda

2) Roll Call

3) Minutes approval

4) Action Items

5) Discussion of WSRX using WS-RM as Product name

6) Discussion of potential TC future activities

8) New Business

2 Roll Call

Attendance:

First Name	Last Name	Role	Company	Voting Level
jeff	mischkinsky	Member	Oracle Corporation*
Jacques	Durand	Secretary	Fujitsu Limited*	1
Kazunori	Iwasa	Secretary	Fujitsu Limited*	1
Tom	Rutt	TC Chair	Fujitsu Limited*	1
Robert	Freund	Voting Member	Hitachi, Ltd.*	1
Eisaku	Nishiyama	Voting Member	Hitachi, Ltd.*	1
Nobuyuki	Yamamoto	Voting Member	Hitachi, Ltd.*	1
Alan	Weissberger	Voting Member	NEC Corporation*	1
Paul	Knight	Voting Member	Nortel Networks Limited*	1
Anish	Karmarkar	Voting Member	Oracle Corporation*	1
Doug	Bunting	Secretary	Sun Microsystems*	1

Meeting is quorate.

3 Minutes Discussion

Tom Rutt volunteered to take minutes.

3.1 Approval of previous meeting minutes

The minutes of the 10/04 teleconference meeting are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/15101/MinutesWsrmTC100405.htm

Bob F Moved to approve the 10/04 minutes, Jacques seconded.

No opposition minutes 10/04 minutes approved

4 Status of Action Items

4.1 Action 012505-1 (Tom Rutt) Pending

OASIS Staff has posted the errata cd as:

http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-v1.1-errata-cd1.0.pdf

However, on the posted standard the errata index is referenced as as:

http://www.oasis-open.org/committees/wsrm/documents/errata/1.1/index.html.

The errata Index still does not yet exist.

The action item will stay open until the errata index page is posted.

4.1 Action 100405-1 (Jacques Durand) Closed

Action: Jacques to provide summary on issue of reliable request response.

Old Email already contains a paper with this summary:

http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200309/msg00053.html

5 Discussion of WS-RX TC use of WS-RM as Product name

Jamie Clark is working with WS-RX TC on proper use of document naming in OASIS.

From now on all their documents and namespaces will have “ws-rx” TC shorthand as a prefix.

On the Oct 27 call of the WS-RX TC Jamie wanted clarification as to whether their use of WS-Reliable Messaging (and WS-RM) is acceptable to the WSRM TC.

We chose ws-reliability as a spec name for our TC.

Anish: I thought the issue was about document names, as well as other namespaces.

Jeff: Explain how this is less confusing than any alternative.

Anish: The confustion is the convention of tc name followed by product name. WS-RX has decided to use the WS-Reliable messaging after the TC name. The confustion is between tc name and document name. What if their tc called their document ws-rx/ws-reliableMessaging, or ws-rx/ws-rm.

Doug B: I do not think we own that name because we have not used that product name.

Tom: there is no real cause for confusion between wsrm/ws-reliability vs. ws-rx/ws-ReliableMessaging.

Doug B: that TC decided a long time ago what their name will be. What happens if we answer the question as no?

Tom: I we did complain, OASIS staff would have a headache to resolve this.

Jeff: we could send an email to the ws-rx tc that their use of names might cause confusion.

Tom R: however the ws-rx TC has not chosen to ask our TC this question directly. Jamie mentioned something at the last WS-RX TC meeting about seeking any concerns about their use of document names in our TC.

Tom R: It feels, to me, like we have no real way to deny them the use of the product name “ws-Reliable Messaging” or “WS-RM”, but we could offer them some statement of acceptability, if we, as a committee, felt it appropriate..

Doug B: we can give a response directly to the TC admin about this, however he has not yet asked a question to this TC.

Tom: Jamie stated to me today on the phone, that he will be sending a request to the committee on this subject in the near future.

Bob F: I do not think either group has done things to violate OASIS rules. Each group has made decisions in the past as to their product names. If the OASIS admin is concerned, they should give an explicit recommendation for either or Both TCs to consider. I do not know what action our TC can take at this time. If OASIS staff has a problem with a committee’s use of names, they need to take it up with that committee.

Jeff M: If Jamie has a problem with their TC choosing a product name which is confusing to the world, he should have the WS-RX TC take care of it.

Tom R: It is a statement of fact: there is no technical problem, due to the TC shorthand name being used as a Prefix in these namespaces, it is only a perceptual problem.

Bob F: the strings are unique. I do not see why we need to say anything about it. If Jamie sees an issue, he needs to take it up with the other TC.

Paul Knight: this is a Kind of courtesy question; we could state we would not raise any formal objection.

Jeff: Given we do not have a question to respond to, I do not know what we can do.

Bob F: until we have a motion on the table, with an actual question from Jamie, there is nothing for US to do.

Tom R: I will wait for a question from Jamie before entertaining any motion regarding namespace issues.

6 Discussion of Potential Future TC activites:

The working list of potential enhancements to WS-Reliability was posted after the last f2f as:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm

6.1 Reliable Request Response

On 9/19/2003, a paper was posted to the wsrm mailing list, edited by Jacques

http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200309/msg00053.html

After review, the TC mail list can be used to comment in this paper, as to its continued relevance to TC future activities.

Wheter we have need to protocol changes are needed to allow this.

Bob F: If we find a need for new capability in the ws-reliability specification, we would have to judge whether it is within the scope of this TC to approve the extensions.

Jacques: We need to decide if reliability of synchronous response support is what we need to decide. That early study shows what is required if we want to provide reliability of response, but we need to discuss if there is a need, before we discuss how to do that.

Tom: Yes that is true, yet some of the mechanisms in that paper, do not require protocol changes, but do impact the construction of an RMP. In particular Caching of the response is something which would be impacted to support this feature, even though there are no new headers required.

Tom: caching is not necessarily required if duplicate elimination is not in use.

Tom: the key question is whether the requirement is there.

Doug B: One question is whether adding such new capabilties is necessary enough to keep the TC open.

Tom R: I agree we need to decide within the next few meetings whether providing reliability for the response of a wsdl request/response transaction is important enough to keep the TC open.

7 New Business

Bob F: What is the process to mothball a TC.

Doug B: we would have to tell the TC admin we are not working any more..

Action: Tom will find out from Jamie what a TC does when it wants to go into maintenance only mode.

Jacques: if there are a minority of members who want to continue working on an extension, is this enough to keep the TC alive?

Bob F: if we did a ballot and only 3 members want to progress on the extension work, is that enough to keep the TC open (allowing the others to go away if they want to).

Tom: I will include that question in my query with oasis staff associated with my action item.

TC Decided to select Jan 24, 2006 as our next meeting date.

BoB F moved Anish seconded to adjourn.

No opposition, meeting adjourned at 6:25: PM Eastern Standard Time.

wsrm message