Updated minutes Jan19

[Guy Pardon <guy@atomikos.com>]

OASIS confcall minutes 19/1/04

-Approval of previous minutes
Update: Jamie should be contacted about update
->there is general consensus on handling this in subgroup
Motion to approve minutes, seconded by Mark
Any objections? No, so approved.

-Action items
Martin posted FAQ.
Martin: Every workgroups has an FAQ. This one was developed by the 
original authors of the CAF spec and is a live document.
Comment: there is still the mentioning whether of not to submit to a 
standards body, seems unnecessary?
Martin: we may just omit this piece of text
Guy: nobody has signed any royalty free agreements except maybe the 
original authors. Just want to point that out.
Martin: this is running ahead of things, but it is supposed to be 
independent of WS-CAF.
-Someone (?): the agreement is RAND terms.
-Someone: we should get the FAQ updated to the current TC. The TC pages 
are still outdated.
(Discussion on RF issue here)
-The only way we can enforce IPR issues is to ask people to respect RF 
upon submitting a contribution.
-Nobody can ever make that promise because you don't know of any 
undisclosed IPR.
-Conclusion of this: the original RF authors have made this statement 
in the FAQ, but not the other members.
-The CAF spec should be RF as much as possible, but it may not be 
possible entirely. BPEL is also not RF. More precisely, it was said 
that the TC will attempt to make the work RF, but because of the 
realities, it is possible that someone may not have disclosed IP; the 
TC can't force this without getting members to sign something, which we 
can't do (and it isn't covered by an OASIS rule).
-Are we going to change the FAQ to reflect the fact that only the 
original authors? OK, action item.
The FAQ is to be adopted as a document of the TC. So now would be the 
time to get it changed if required.

Martin: any other questions on the FAQ? No.

Next item: Eric: Context examples presentation:
In the F2F in December, there was some discussion about deferring long 
issues to later.
One such things was whether the CTX service is really generic outside 
TM functions.
We talked at the F2F mainly about the characteristics of CTX and about 
thinking of some examples of use case scenarios.
Some things included security, database files, clusters membership,...
None of these examples are normative but rather to be included as 
appendix in the specs.
Going over them in (reverse) order of the emails mentioning them:

-Example1: Session state from Greg: shared session across WS 
interactions to support conversations.
It appears that Gregs example would fit.

-HP pointed out that they did not define the creation of session but 
rather the need for them

-Example2: Cluster membership: Mark wrote scenario on how to use CTX 
for replicas in fail-over and load balancing. Conclusion: CTX seems 
good match for weak or even strong consistency protocols (dixit Mark). 
Weak consistency seems more appropriate for WS applications

-Example3: Database files and devices: CTX could be used to share 
resource information. A set of WSs could access common resources over 
multiple interactions. The CTX could contain and share the different 
handles to these resources.

-Example4: Security example: never received.

-Example5: Context for sharing state in business processes: Jan 
Alexander proposes an intermediare and define the state of an activity 
as the set of messages exchanged. The intermediary would make share 
state between apps in a transparant way. CTX would nicely fit.

Are any of the examples' authors present to point out any mistakes in 
the presentation? Silence.

Eric: OK, let's open for discussion

-Alistair: Choreology went over them and comments: Erics example is 
like a config service (cf property files): a service which sits on top 
of a file repository. The same seems to apply to Jan's example. Remark: 
it would be useful to have a webservices edition of that, since it 
seems basic functionality that can be isolated from the more complex 
examples. It seems like registration and outcome notification are on a 
different level.
Another comment: there is an update facility here. We don't have any 
access control to the information in the CTX. One can dynamically 
modify the information from different locations.
Answer: a signalling protocol to allow participants to detect 
conversation ending would be useful.
Also, singalling is already out of the basic CTX and put into the 
coordination framework.
CTX only provides the basics and begin/end in some way.

-What is the thing that enlists in CTX? The ALS? There seems some 
confusion about this.
As it reads: enlistment is in the CTX specification, but Greg suggests 
it is one level up.
So where does coordination start and CTX stop?
(Some discussion about whether we should limit ourselves to the 
examples or discuss the specs).

-Choreology's point: completion in Mark's facility is confusing: is the 
completion signal going through CTX or not? Is there any enlistment in 
the specs, or is this the wrong version of the specs?
Answer: there is no necessary dependency between the ALS and any 
coordinated event.

-Mark's answer: the coordination aspects in the example are back-end 
and not meant for the CTX service to do. The CTX service only has to 
signal a termination event. The replica coordination is not part of CTX 
but can be something else.

-Follow-up question by Alistair: does the signal depend on some 
registration or not?
Mark (with some reservations): CTX has very low-level type of 
co-ordination among the different ALS-es. Activity.start would add 
something to the basic context. We can continue this discussion by 
email.

-If there is nothing using the termination in the CTX then why should 
it be there? Maybe it is worth raising an issue about it. (there seems 
to be agreement on this)

Martin: let's continue the discussion via email
Next item: implementation scheme update
-Malik: WS-I proposition has had no objections. A charter was posted 
for the implementation group.
Any questions? No

Next item: issues resolution
Martin: The only way to make progress is by going over issues and 
resolve them before moving on.
Did everyone get a chance to read the issues? Silence. Any motions?
Remark: In most cases they appear typos or editorial fixes.

Motion to adopt them (issues 1-11) by Greg. Anybody seconding? Yes: 
Simeon.
Any discussions? No. Objections? No. Motion approved.

Simeon still has to do an update.

Issues 44-45:
Issue 44: was informally resolved at F2F? Are we going to use WSDL 
version 1.1 or 2.0?
1.1 seems more reasonable, since 2.0 is too far out?
Motion to use WSDL1.1, seconded by Mark. Any discussions? Yes, we could 
later map to WSDL2 if it is stable? There is nothing in the resolution 
now that precludes that, but maybe we should formalize the willingness 
to be forward-compatible.
Martin: we can still reverse this decision if appropriate.
Any objections? No. Motion approved.

Issue 45: do we want to be compliant with WS-I BP?
Any motions?
Question: what is the impact of a decision? Martin: BP was recommending 
not to do stupid things with WSDL by adhering to best practices.
Question: is there any need to reference BP from the specs? Yes, we 
should mention it.
Simeon: BP is well-established and we should not come up with our own. 
If we all agree to comply with BP then things will be easier.
Motion: Adopt BP, seconded by Simeon.
Any objections? No. Accepted, issue 45 closed with resolution that 
intent is to be BP-compliant.

Next agenda item:
End of April there are possibilities to meet in a F2F. Are we going to 
do this? Currently we have Feb and then May-June. Any comments? No. 
Anybody opposed to meeting? No. Eric: we should consider meeting since 
it will be a chance to get interaction with other TCs. This opinion 
seems to be shared by others.
No objections, so this is approved.

Next meeting: Feb 2nd.

Last Question: how do we raise a new issue? Answer: send an email, it 
will go the the bug tracking system.