WS-TX F2F Minutes

07-09 November 2006

F2F, hosted by Hitachi.

Agenda:

To be held over 3 days.

Tues Nov 7 (starting 11:00) - Thurs Nov 9 (ending 17:00)

TUESDAY 7 Nov 11am 5pm EST

1. Roll Call - chair

Ian called roll. The meeting is quorate.

2. Confirm Paul Knight as minute taker - chair

Paul taking minutes.

3. Approve minutes of Nov 2 telecon - chair

Minutes approved.

4. Call for AOB - chair

None noted initially.

5. Action Review - Paul K

(Monica? Ram?) Propose precise text or removal of

According to the mapping rules defined in the WS-Addressing specification, all such reference properties must be copied literally as headers in any message targeting the endpoint.

from line 332 in WS-C.

Action Item Closed.

Monica: Proposal is on chat:

[11:18] Ram: Proposal for action item: Messages sent to the target protocol service endpoint

carry all reference parameters contained in the Endpoint Reference, according to rules

defined by the WS-Addressing specification [WSADDR].

[11:19] Ram: Monica's proposal 1: These Endpoint References contain (opaque)

wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Endpoint

References are defined using WS-Addressing [add link] EPRs.

[11:19] Ram: Monica's proposal 2: These Endpoint References may contain (opaque)

wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Endpoint

References are defined using WS-Addressing [add link] EPRs.

Ram: My earlier proposal is also pasted:

[11:19] Ram: Ram's proposal: These Endpoint References may contain (opaque)

wsa:ReferenceParameters to fully qualify the target protocol service endpoint. These Endpoint

References may contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol

service endpoint. Endpoint References are defined using WS-Addressing [add link] EPRs.

Ram: Only the second sentence is changed in Monica's proposals.

Ian: The difference is the middle sentence in Ram's proposal. Nobody is suggesting changing the first sentence.

Ram: The original text is also posted:

[11:21] Ram: Old text: These Endpoint References may contain (opaque) wsa:ReferenceParameters

to fully qualify the target protocol service endpoint. According to the mapping rules defined

in the WS-Addressing specification, all such reference properties must be copied literally as

headers in any message targeting the endpoint.

Ian: Ram, what specific text are you proposing?

Ram: May have posted wrong text earlier…. The correct text is:

[11:23] Ram: Ram's proposal: These Endpoint References may contain (opaque)

wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Messages sent

to the target protocol service endpoint carry all reference parameters contained in the

Endpoint Reference, according to rules defined by the WS-Addressing specification [WSADDR].

Ram: First sentence stays same. Second sentence avoids making a normative statement about WS-Addressing.

Max: what is the goal? - 1: not make normative references to WS-A. 2 - Not lose any context with the changes we make. Bob, what is the best language or verb to use here?

Bob: EPRs used according to…

Max: A specific reference?

Bob: It usually best to refer to the set of documents, not just Core or WSDL binding, unless there is a specific reference.

Ian: Text now refers to the SOAP binding. It is talking about reference parameters in general.

Bob: For a single document, this could just reference the Core spec of WS-A. For specific bindings, we would reference the Bindings specs.

Ram: It is now pointing to the namespace.

Ian: That logically means the whole set of WS-A specs.

Ram: In the normative refs, it only has one ref to WS-A.

Ian: In section 7, we have refs to WSADDR.

Bob: The reference to Core may not be the best here.

Max: I posted a suggestion in the chat:

[11:32] mfeingol: Endpoint References MUST be interpreted according to the rules defined in

WS-Addressing 1.0 Core [WSADDR].

Ian: Do we have a consensus on Max's proposal?

Monica: So it would be the first sentence, plus Max's after "… protocol service endpoint."

Ian: Any objections?

None.

The proposal is accepted for WS-C.

6. Potential new issues to accept - Ram

Brief statement of each proposed new issue. There is no need to consider the merit of any proposed resolution at this stage. In general the TC will accept issues that are not reopening resolved issues and that are in-scope. Accepted issues move from "review" state to "active" state.

None?

No new issues noted.

7. Further discussion in Agenda Item "Completion of RFC 2119 AIs"

Email discussions on this topic:

WS-AT:

Ian: There was some concern about Monica's comments around 3.3.3.

Andy: I will submit an issue concerning this.

Ram: Line 41, page 4 of AT, the word "uppercase" is flagged by MS-Word as questionable.

Tom F: It is okay. That is a MS-Word concern.

WS-BA:

http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00101.html

http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200611/msg00018.html

Ian: Tom posted the document to the TC this morning.

Tom: Some of the lowercase musts were changed to MUST. I'll go through each change.

Line 6: can - MAY

Ian: This is not a testable assertion. It places no normative constraint. Do we need an uppercase MAY?

Max: Prefer lowercase may here.

Ram: Yes.

Tom: Line 53. can - MAY. This should be lowercase too.

- agreement

Tom: Line 179 - must - MUST

Andy: This mirrors issue 106. We agreed during the AT discussion to defer this to the discussion of Issue 106. It applies to both.

Ian: Let's accept this now, but we may change it again in discussing 106.

Tom: 197 - can - MAY

- agreement

205 - may - MAY

agreed

210 - must - MUST; may - MAY

Max: Need to say "either" with the MUST.

Tom: "MUST either close or compensate all participants"

Tom: Mixed: MUST direct all participants to an outcome, but MAY direct each individual …

agreed

217 - Remove extraneous must

233 - Change should to MUST (send a close or compensate)

235 - not - NOT

241 - should - MUST

244, 246 - may - SHOULD

same for 249, 251

253, 255 - same

260-261 should - MUST

Ian: Not sure about this. It's similar to the AT spec discussion. Do we need line 261 at all? The state table shows when the message can be sent. This is from the perspective of the Coordinator.

Max: There is some normative text about the participants.

Ian: We are just trying to make the headline statements, as long as they don't contradict the state tables. It's not incorrect to place requirements on the participants.

Ian: Does this refer to the exit message? It's not clear. We should say "the exit message may be sent."

Tom: Agree.

Ian: We could swap the order of the last two sentences. - editorial discretion here.

Tom: Will change it.

Tom: line 267 should - MUST

269 must not - MUST NOT; may - MAY

Tom: May need to clarify the message we are referring to here.

Line 274 - should - MUST

278

Monica: Should use the word "either" here.

Tom: Okay. I'll look through, and insert "either" where there are "ors".

Line 283 - add "or Fail"

Tom: Lines numbers on the doc may be one less than I say, since they change as I am editing.

290 - 2 mays to SHOULD

291, 294 - same.

296, 299, same

308 - might - MAY

Max: It sounds like you can only send the message when you're in that state, on line 308. Maybe use "For example" and a lower case may?

Tom: okay

Agreement

319 - can - MAY? maybe lower case may?

- agreement with lower case may

322 - must - MUST

324 - 2 should - MUST

Tom: This is a requirement rather than an expectation.

Ian: We had a similar discussion with AT and changed it to MUST.

Max: line 320 - responsibility of coordinator - is this a MUST?

Tom, Ian: yes.

Tom: line numbers are off now.

"Current" 337

Fail - 338 - should - MUST

Could not complete - 345 should - MUST

347 - must not - MUST NOT; may - MAY

Ian: Also, ref to "this message" is not clear.

353 - should - SHOULD

Monica: We were trying to decide where the emphasis was.

Tom: We can't dictate what will happen in the implementation.

Monica: Do we need a requirement on the first participant?

Tom: Remove SHOULD?

Okay.

Line now reads:

[12:24] Ian R: Tom Freund: The participant completes application processing and MUST transmit

the Completed notification.

Monica: Okay.

Max: It could fail.

Monica: Maybe make it two sentences?

Tom: Will work on the text, will post updated text later.

Line 465 or thereabouts. - This needs to be consistent with AT.

Ian: AT didn't make these changes. We do need consistency. We didn't want to restate things which are normatively stated in other specifications.

Max: The changes seem fine.

Ian: If so, we should make the changes in AT too.

Ram: Also Coordination.

Andy: In AT, there was a distinction. In that case, the lower case was more appropriate.

Tom: Happy to use the lower case here.

Ian: All three should be consistent.

Max: It seems right to use lower case when describing internal processing of other specs.

Ian: Are these referring to something the WS-TX protocols may do?

may, MAY, or can are the choices.

Max: Comfortable with Tom's proposal here.

Ian: All three should be consistent.

Andy: Okay with that.

Ian: Then all should be uppercase.

- agreement.

Andy: Line 466 - describes WS-Trust and has a link, but others don't have the link. Do we need it everywhere?

Tom: Maybe have the ref the first time it's used in a paragraph?

Ian: Easier to hyperlink all of them, so we don't have to make a decision on each.

Andy: It depends on which referencing style we're using.

Ian: Does anyone really care on this point? Once we've produced the committee specs, we will not be able to change it.

Andy: Probably worth adding the references.

Tom: In this section, or throughout the document?

Ram: Probably not throughout the document? Use it the first time in a section? I suggest the editors focus on the security considerations, but not through the rest of the doc.

Andy: But in general, where we have a reference, we should hyperlink?

Ian: Yes.

Tom: Section 6, Line 512. - This is common text with the other specs.

Delete for example, use "in such cases"; change should to MUST.

I pasted the updated text to match what's in AT:

[12:43] Tom Freund: Protocol faults raised by a Coordinator or Participant during the

processing of a notification message are terminal notifications and MUST be composed using

the same mechanisms as other terminal notification messages.

Tom: Everyone agree with that?

No objections.

Line 552 - use "knows" -

Andy: Why do we have a glossary in BA, and not in the other specs?

Ram: Coordination has one.

Andy: Will add something in AT.

Ian: Interoperability considerations? Do we need this section? It is not in WS-C or WS-AT.

Tom: Will delete Section 7. It does not really say anything.

Ian: So that concludes the RFC2119 key word inspection for all three specifications now.

8. Review of BA proposed public review draft materials - Tom

Tom to summarize changes in latest working draft.

Each issue that is completed in the working draft will be moved from "Pending" to "Resolved" state.

Tom will produce public-review drafts from these once we agreed the issues within are resolved..

Tom: There are not a lot of changes beyond the RFC2119 key word changes we just reviewed.

Ian: Will you be able to accept all these changes by tomorrow, so we can see the deltas?

Tom: Yes, everything we just discussed, plus these changes.

Tom: My changes reflect the previous level.

Tom: Line 110 - namespace , issue 99

Issue 97 - line 114 - xml schema link "can be found".

- later, incorrect hyperlink

325 - 326 - RFC change was actually from issue 97

518-519 - changed to be consistent with AT.

Tom: Those were all the changes to the document. Most other changes were to XSD and WSDL.

Ram: Can we review those?

Tom: Okay… Will have to highlight where the changes were made… copyright changed, deleted addressing from schema; these are only two changes in the XSD schema.

Tom: WSDL: copyright changed, addressing reference changed; action attributes disappeared from messages

Ian: wsaw: isn't referenced.

Tom: We need to discuss deleting wsaw:

Tom: That's where it is now.

Ian: Good place to break for lunch. Will restart at agenda item 9.

9. Issue resolution for issues that affect WS-BA

i098 - WS-C/WS-AT: Comments on WSDL/XSD files

Ian: We've already resolved parts 1 and 2, and discussed part 3. We need to resolve it based on Tom's work.

Any objections?

No objections; Issue 98 resolved.

i102 - WS-AT: Editorial comments

Related emails:

On "tentative actions":

http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00102.html

On AT section 3.1:

http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200611/msg00021.html

Ian: There are several emails on this. First, Ram's: We dealt with the first two points on lines 2 and 19. The line 24 item concerns tentative actions by a participant.

I'll paste text into the chat room.

[14:16] Ian R: http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00102.html

[14:17] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative. Typically those actions are neither made persistent nor made visible to other

activities....Commit directs the participants to make the tentative actions final.  For

example, they could then be persisted and made visible to other transactions.  Abort directs

the participants to make the tentative actions appear as if the actions never happened."

Ian: Since the first reference to tentative actions includes "visible and persistent," the issue asks for this to be included at the later usage. However, it was pointed out that this is the job of a resource manager, not part of AT. Monica's later proposal was what I pasted into the chat. What Commit does is different from making the actions persistent.

[some wordsmithing activities]

Final accepted text:

[14:34] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative; typically they are neither made persistent nor made visible

outside the transaction....Commit directs the participants to make the

tentative actions final so they may, for example, be made persistent and made visible outside

the transaction.  Abort directs the participants to make the

tentative actions appear as if they never happened."

Ian: We have covered most of the rest of the items.

Tom: We should note for each of these if they apply to BA as well.

Ian: Everything that can apply to BA should be considered to apply. We'll let the editors handle that, not go through each item.

Monica: In Preconditions (3.1), we need a change. I'll paste the proposal:

[14:39] monica:    Change from: The correct operation of the protocols requires that a

   number of preconditions MUST be established prior...

   Change to: The correct operation of the protocols requires that a

   number of preconditions are to be established prior...

   Reason: The individual bullets specify the level of requirement.

Ian: Continuing with Issue 102, the line 216 in 3.3.1. The proposal is to change the text.

However, "Once the prepare has been issued," is imprecise.

Ram: Prefer to leave it as is.

Ian: Agree, no change to line 216.

Ian: Any other issues we have to discuss in Issue 102? How about Section 8?

Joe: Not sure. 178-179 was the last thing mentioned in the minutes I took.

Ram: Going through the changes.

Lines 209-210 - ordering of references

Section 7 - no longer a pair

Section 4.4, lines 318, 320 the numbers have changed.

Section 5, line 331 - description not right, change to a "human-readable representation of the fault."

Line 513 - fatal condition, not fatal.

Section 9

State Tables - change ReadOnlyDecision to Read Only Decision.

Ian: That is already okay, fixed in current version, no need to change it.

Ram: Section A, Acknowledgements: some names need to be adjusted.

Peter Furniss should be listed as affiliated to Choreology, same as Alastair, since he was employed by Choreology for most of the time these specs were being developed.

Monica: Line 224 - upon receiving - 3.3.2 - Line 221 - I will paste to chat.

[14:57] monica:     211 Upon both receiving a Commit notification in the completion

    protocol and successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

Ian: There is a sequence of events that occurs. This makes it sound independent.

Joe: Upon successfully completing the prepare phase - that part is enough.

Monica: So it could be:

[15:01] monica: Upon successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[15:01] Ian R: strike "After receiving a Commit notification in the completion protocol and "

Max: Capitalize Prepare?

Andy: Should be lower case.

Ian: So the final is:

Upon successfully completing the prepare phase for Volatile 2PC participants, the root

coordinator begins the prepare phase for Durable 2PC participants.

Ian: Having covered all of those items, can we have a motion to accept?

Ram: Motion to accept, with amendments as noted, plus a change in the last call on security context, and the RFC2119 action items.

Joe: Amendment to change participant to initiator or vice versa as needed.

Ian: Any opposition?

None, motion is passed. Issue 102 is resolved.

i104 - Remove wsaw:Action attribute from WSDL

Ian: This is to do with the use of wsaw:Action

In issue 99, we noted that in the WSDL we were incorrectly using the wsa: namespace instead of wsaw:. We resolved to change to wsaw: namespace. While that would be correct, there is a problem: The WSA WSDL binding spec is not stable yet, in particular the namespace.

Bob: We (WS-Addressing WG of W3C) will go back through last call.

Ian: We can either wait until the WSDL binding spec is stable, or we can take a risk when we expect it is stable, or we can define in the normative text what the action URIs need to be, and get rid of the wsaw:Action reference. The proposed resolution is to more clearly normatively define in the prose of our text to get rid of the wsaw:Action altogether, and replace it with text defining exactly the Action URI. Does that sound like a reasonable proposal? There are details about how to do it in the proposal for Issue 104.

Ian: Move the existing text into the "Use of WS-Addressing Headers" section and change the text "the element" into something more precise. Similarly in the AT and BA specs, there are notification messages instead of Request-Reply messages. So this is a concrete proposal to address the issue.

Eric: Seems pretty clear. Do we need a cross-reference?

Ian: No, the proposal is to move the text.

Joe: Will we get properties from various WS-A specs?

Ian: No, all from Core.

Ram: Editorial comment. The reference to WS-COOR is in a wrong font. It needs to be Courier New, size 9.

Tom: Use "Example" tag, in the OASIS template.

Ian: Other than getting the style tags right, and the precise location of the text in all the specs, any objections?

None, the motion is passed. Issue 104 resolved.

i105 - WS-AT: Determine standard fault requirements

Monica: There are faults listed in WS-C and section 5.1 and 5.2, but no definition. The proposal identifies this, but does not have a complete resolution.

Eric: Is it a MUST requirement?

Joe: It was not in the interop testing, so we proposed SHOULD.

Eric: Just because it was not in the interop testing, does not bear on its level of requirement.

Joe: Are these more informative, like log messages? I thought they were more like that.

Eric: An unexpected protocol message seems like something you need to know about.

Ian: The state table leads you to think it is more of a MUST. Why not change 503 to include MUST?

Monica: There was nothing at all. We wanted to allow for other fault codes as well, but were not prepared to propose them now.

Ian: If you sent a protocol to an end point that didn't exist, such that the receiving end point didn't respond properly.

Max: If the end point was not WS-A aware?

Ian: If this is changed to use MUST rather than SHOULD, it is fine.

Bob: Destination unreachable wouldn't be seen, for instance. Or end point unavailable.

Max: The main question is - what do you send?

Ian: This is applied to a participant of coordinator which is up and running.

Max: Changing from will to MUST?

Joe: Could just not list individual faults.

Ian: This is what the test says now: a standard fault code such as Invalid State….

[wordsmithing - Ian, Max, Joe, Monica]

Ian: will paste to chat:

[15:40] Ian R: Unexpected protocol messages MUST result in a fault message as defined in the

state tables. These faults use standard fault codes defined either in [WS-COOR] or in Section

5, Transaction Faults.

Ian: Does that completely cover Issue 105?

Monica: Motion to adopt with the text as proposed in the chat.

Andy: Second.

No objections, Issue 105 resolved.

Ian: propose we stop at 4:30 today.

Monica: Would like to cover 107 and 108 today if possible.

Ian: Short break now, aim to cover 106, 108, 107 today by 4:30 if possible.

i106 - Requirement for the use of SOAP and the location of a CoordinationContext in a message in unclear

Andy: This is based on the RFC 2119 discussion. Changes are proposed for the AT and BA specs. The only normative statements about SOAP are in the policy sections. There was a MUST change on line 145 of the PR…. AT context MUST flow …

This issue proposes more normative text. [see issue for specific text]

Policy assertion section changes are also proposed.

Joe: Replace "the SOAP header" with "a SOAP header" in two places.

Andy: Fine.

Max: Is there a normative requirement to flow a CoordinationContext outside a policy assertion?

Ian: You can interoperate by having an out-of-band method.

Max: Concerned about the MUST in 145-146.

Ian: WS-C defines the CoordinationContext, but WS-AT and WS-BA define specific usages.

Joe: The Coordination spec says you must use the CoordinationContext. Max's point goes beyond this.

Max: Do we agree that we don't want to prohibit alternate representations of transactions?

If another application does this over SOAP, do they have to use WS-C?

Ian: No, but if they use WS-AT, they need to conform.

Max: If a transaction starts in AT and moves to another protocol, are they constrained?

Andy: No.

Max: But the statement would appear to force it to be constrained.

Eric: Any specific suggestion?

Andy: The text I propose mostly addresses this. The MUST refers to flowing the AT CoordinationContext. If you are outside AT, it does not apply.

Tom F: It distinguishes the interoperability domain.

Andy: The text might be able to be tweaked a bit to make it more clear.

Ian: I don't see why we wouldn't want to have this statement, which defines how to follow the standard. At the same time, we don't want to prohibit other behaviors outside of AT.

Max: The policy assertion is defined in terms of headers.

Andy: It constrains you to use SOAP and the CoordinationContext format.

Ian: Perhaps that is overly restrictive? Is that a mistake?

Max: Ask a policy expert? The assertion makes no sense in other domains.

Ian: There are two parts to this proposal. We should dispose of the first part before we can address the second.

Max: Would it make sense to take the "flow" text and handle it in the Policy Assertion section?

Andy: It should be outside of the policy assertion section. Otherwise it will not be seen by implementers who are not concerned with policy implementation.

Tom: I would support the idea of splitting the text.

Ian: We need a concrete proposal. Can we get that ready for tomorrow, and now try to address issues 108 and 107.

Joe: Line 192-195 in WS-C, it is a bit overly aggressive. Consider putting it in the other specs.

Ian: Let's consider that tomorrow.

[continuing on 8 Nov., 09:45]

Andy: We make a normative statement to help interoperability without relying on Policy.

Eric: Max's suggestion from yesterday was to avoid unnecessary constraints on implementations. Was there a specific proposal?

Max: Separate the SOAP issue from the transaction issue. Do we want entire spec referring to SOAP?

Andy: No, the proposed text says "For application messages that use a SOAP binding…" The idea was to constrain it to the headers, so the implementation does not have to scan the entire SOAP message.

Max: Still concerned about the constraint.

Andy: It is only a constraint within the bounds of AT.

Eric: Not sure that the specification language acts as a constraint to non-compliant implementations. However, we want to allow flexibility.

Max: I will work on some text to express my concerns today.

Eric: We will return to this issue later today if possible.

[continuing after lunch 8 Nov.]

Max: I sent text to Ian and Andy. Will now send it to the mailing list.

Andy: pasting to chat:

[13:17] Andy: Section 2 - Atomic Transaction builds on WS-Coordination, which defines an

Activation and a Registration service and a CoordinationContext type.   Example message flows

and a complete description of creating and registering for coordinated activities is found in

the WS-Coordination specification [WSCOOR].

The Atomic Transaction coordination context is a CoordinationContext type with the

coordination type defined in this section. Application messages that propagate a transaction

using the Atomic Transaction protocol MUST use an Atomic Transaction coordination context. If

these application messages use a SOAP binding, the Atomic Transaction coordination context

MUST flow as a SOAP header in the message.

[13:18] Andy: Section 4.2 - A policy assertion that specifies that an Atomic Transaction

coordination context MUST be flowed inside a requester's message. From the perspective of the

requester, the target service that processes the transaction MUST behave as if it had

participated in the transaction. For application messages that use a SOAP binding, the Atomic

Transaction coordination context MUST flow as a SOAP header in the message.

Ian: This is the description of where the coordination context needs to be sent in the message.

Andy: Is it IN a SOAP header or AS a SOAP header?

Ian: It does not matter. In this case they are synonymous.

The other change is in section 4.2. This seems to address the issue.

Andy: Move to accept Max's proposal as the resolution to Issue 106.

Max: Second.

No objections. Motion approved. Issue 106 resolved.

[13:36] monica: The sentence in #106 is incomplete: A policy assertion that specifies that an

Atomic Transaction coordination context MUST be flowed inside a requesters message.

[13:36] monica: A policy assertion specifies that an Atomic Transaction coordination context

MUST be flowed inside a requesters message.

[13:38] Andy: Monica - the text is a follow on from the line above so I believe it makes sense.

[13:39] monica: All I did was delete 'that' - otherwise it is an incomplete sentence (grammatically).

[13:43] Andy: It should really be read as "/wsat:ATAssertion - A policy assertion that

specifies that an Atomic Transaction MUST be flowed inside a requesters message."

[13:43] Andy: The /wsat:ATAssertion being from the line above.

Monica: Okay, did not have the complete context.  That is fine.

i108 - Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097), Submission 2

Monica: WS-AT, Section 3, sub-bullet items , lines 168 and 170 - take "should" out.

Line 172: (proposed by Andy) Should a participant wish to register for more than one of these protocols, it MUST send multiple Register messages. A participant MUST register by using one of these registration protocols.

Tom F: A participant MAY register for more than one of these protocols. To register for more than one of these protocols, a participant MUST send multiple Register messages.

Max: It worries me when the spec uses MUST for an optional behavior.

Ian: The original intent was to note that a participant may register for more than one protocol.

Tom: The single case should go first, like:

A participant MUST use one of these registration protocols in order to register. A participant MAY register for more than one of these protocols. To register for more than one of these protocols, a participant MUST send multiple Register messages.

Ian: Using the RFC 2119 language, we are assuming that we are discussing implementations which are using these protocols in order to interoperate.

Max: It is being interoperable, but adding additional functionality. It would risk being declared non-conformant.

Ian: We should continue this tomorrow.

Tom: There is what you want in each document, and the issue of composability among the protocols.

Max: Not sure what we gain with normative language. Also, it may prevent other implementations.

Ian: Tomorrow, we will start with the BA Public Review question, since we expect to have people call in to vote. Then we can come back if something makes a small change in BA, which would be a post-PR draft of BA. We will start again at 9:00 tomorrow.

[continuing 8 Nov. 11:10]

Andy: I sent a message to the list with proposed text. We may need to have that assigned an issue number for tracking, or it could be taken as a proposed resolution to Issue 108.

Eric: We can consider it as an amendment to Issue 108.

Andy: It is a proposed resolution to part 2 of Issue 108.

[11:15] monica: for 108 http://lists.oasis-open.org/archives/ws-tx/200610/msg00105.html

[11:16] monica: Section 2.1 was handled by #106.

[11:17] ericn: http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200611/msg00038.html

Joe: Would like some time to review this.

Eric: If we defer discussion until after lunch, will that be sufficient?

[will return after lunch]

[after lunch]

Ian: Pasting the text proposed now:

[13:26] Ian R: Commit

Upon receipt of this notification, the coordinator knows that the

participant has completed application processing. A coordinator that is

Active SHOULD attempt to commit the transaction.

Rollback

Upon receipt of this notification, the coordinator knows that the

participant has terminated application processing. A coordinator that is

Active MUST abort the transaction.

Section 3.3:

Prepare

Upon receipt of this notification, the participant knows to enter phase 1

and vote on the outcome of the transaction. A participant that is Active

MUST respond by sending an Aborted, Committed or ReadOnly notification as

its vote.  If the participant does not know of the transaction, it MUST

send an Aborted notification. If the participant has already voted by

sending Aborted or Committed, it MUST resend the same vote.

Rollback

Upon receipt of this notification, the participant knows to abort, and

forget, the transaction. A participant that is Active or Prepared MUST

respond by sending an Aborted notification and SHOULD then forget all

knowledge of this transaction. If the participant does not know of the

transaction, it MUST send an Aborted notification to the coordinator.

Commit

Upon receipt of this notification, the participant knows to commit the

transaction. A participant that has successfully sent Prepared MUST

respond by sending a Committed notification and SHOULD then forget all

knowledge of this transaction. If the participant does not know of the

transaction, it MUST send a Committed notification to the coordinator.

Committed

Upon receipt of this notification, the coordinator knows the participant

has committed, and forgotten the transaction.

Joe: I will paste some text in the chat. This is removing a comma in the text for section 3.3.

[13:26] joef: Rollback

Upon receipt of this notification, the participant knows to abort, and

forget, the transaction.

Ian: With this change, both Joe and Monica have agreed with the text. Any other discussion related to RFC 2119 key words?

Max: Section 3.2 looks fine.

Max: 3.3 Prepare section has a problem. It indicates that a participant might vote by sending Committed. That should be Prepared, in two places.

Andy: Pasting new text for that.

[13:34] Andy: Prepare

Upon receipt of this notification, the participant knows to enter phase 1

and vote on the outcome of the transaction. A participant that is Active

MUST respond by sending an Aborted, Prepared or ReadOnly notification as

its vote.  If the participant does not know of the transaction, it MUST

send an Aborted notification. If the participant has already voted by

sending Aborted or Prepared, it MUST resend the same vote.

Max: Modified text:

[13:37] mfeingol: If the participant knows that it has already voted, it MUST resend the same vote.

Joe: Since the participant should forget after sending Aborted, how can it resend it?

Ian: There is no requirement to forget within a specific time period.

Joe: I like the new text since it doesn't specify that Aborted MUST be re-sent.

Max and Ian: wordsmithing…

[13:43] Ian R: Rollback

Upon receipt of this notification, the participant knows to abort, and

forget, the transaction. A participant that is not Committing MUST

respond by sending an Aborted notification and SHOULD then forget all

knowledge of this transaction. If the participant does not know of the

transaction, it MUST send an Aborted notification to the coordinator.

[13:46] mfeingol: Committed

Upon receipt of this notification, the coordinator knows the participant has committed and

has forgotten the transaction.

Ian: Motion to adopt?

Andy: Motion to adopt.

Max: Second.

No objection.

Issue 106 resolved.

10. Issue resolution for WS-C and WS-AT

i101 - WS-AT: Remove Invalid Protocol fault

Ram: The meaning of the fault is not clear.

Eric: Email from Max: the URL is in the chatroom:

[9:56] Ian R: http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00057.html

Ram: Move to accept the proposal from Max as posted.

Alastair: Why should it be narrowed to being a capability fault rather than a more general runtime fault, if some clash of protocol types at any time occurs?

Ram: We could not find a use case for the more general case.

[suspended discussion of 101 to allow vote on BA]

[resumed discussion 10:12]

Alastair: While the proposal adds something, it removes the capability to send a message about reception of an invalid protocol type in other situations. It's not clear that either is correct. It would be more appropriate to reword it.

Ian: This is most usefully represented as being specific to the registration exchange. It's not useful in the more general sense as Alastair suggests. The end point would not receive the message in most cases. It would be intercepted lower in the protocol stack. I also think it is useful to note that this fault can be generated in the registration exchange, so it will be implemented by most implementers.

Max: Agree with Ian, it should be specific to registration. It would be usurping the functionality of another layer to try to make it more general.

Alastair: Don't agree, I think it would not be intercepted lower in the stack. There are usually three messages: invalid state, invalid protocol, and invalid parameter which are available to express runtime problems. What happens if you did receive a message like Complete at the wrong time?

Ian: Good question. I'll try to answer: If I have an implementation which does not want to accept a Complete message at a specific time, I will not define in WSDL the ability of a participant to send the Complete message, so I should not receive it.

Alastair: There is already a fault "Cannot Register Participant." We should use it. I think we should either remove it altogether, or leave it as is stands, noting that the invalid registration can be handled by the Cannot Register Participant fault.

Max: I was trying to avoid making a breaking change such as removing the text completely. I will withdraw my proposal if needed.

Ian: The objective of stating this usage is more specialized than the "Cannot Register Participant" fault.

Alastair: What you are doing is tampering with existing functionality and adding none. I don't think it is a good idea. You end up some ambiguity, since there are two faults that could be sent in the same circumstances. This will cause changes in existing implementations. I think this issue should be dropped with no change.

Ian: My concern is that adopting this may be considered as a breaking change. It's not worth making a breaking change. Before voting, I'd like to make sure it is not considered a breaking or substantive change.

Max: The MS implementation does not implement this, so we would have no change.

Ian: This change would not break the IBM implementation, but removing the fault would.

Eric: I think the IONA implementation is the same as IBM's in this regard.

Alastair: What the text says is clear. If you leave it alone, you have a mechanism that will work well.

Max: I disagree that the original text is clear. We need some clarification to it.

Alastair: What is unclear?

Max: "…received a message from an invalid protocol."

Alastair: How about "… received a message which is invalid for the protocol supported by the endpoint."

Ian: Change protocol to protocols

[10:38] alastair: This fault is sent by either the coordinator or a participant to indicate

that the endpoint that generates the fault received a message which is invalid for the

protocol supported by the endpoint.  This is an unrecoverable condition

[10:39] ericn: This fault is sent by either the coordinator or a participant to indicate that

the endpoint that generates the fault received a message which is invalid for the protocols

supported by the endpoint.  This is an unrecoverable condition.

Max: We also need to consider what is meant by "invalid"

Alastair: A message which is not part of the protocol. This definition doesn't include invalid parameters, which are a different fault.

Alastair: Concerned about the plural "protocols." Why have two faults which could be sent in a given situation? It attempts to smuggle in a variant of "cannot register participant."

Ian: An endpoint can be registered for multiple protocols, so we need the plural.

Alastair: Agree with that point. But Ian is saying that he wants to use this in a case where a correct message is received but the registration cannot be handled. I think it is deliberately covering over a disagreement.

Eric: We have a motion on the floor. The text has been changed.

Ram: Move to accept the text as posted by Eric:

[10:45] ericn:This fault is sent by either the coordinator or a participant to indicate that

theendpoint that generates the fault received a message which is invalid for the protocols

supportedby the endpoint. This is an unrecoverable condition.

Ian: second

Eric: any objections?

Monica: abstain

Issue 101 resolved with the text posted by Eric.

i103 - WS-C: Update "reference properties" text

Eric: "Change all references from reference properties to reference parameters."

Ian: This is just an issue to formally dispose of this necessary change.

Ian: Motion to adopt the proposed change.

Ram: second

No objections.

Issue 103 resolved.

i107 - Other Editorial Issues Surrounding AI#0057 Review for RFC 2119 (I#097)

[10:50] monica: http://lists.oasis-open.org/archives/ws-tx/200610/msg00103.html

[10:50] monica: we were on second item on the issue - line 172

Joe: This deals with registering participants. I put text in the chat:

[10:50] joef: A participant MUST register

using one of the protocol identifiers defined in this section.

Max: Why do we need the additional text?

Joe: It is intended to minimize the changes. It says you can use the identifier, but does not say you MUST use the identifier.

Max: I would expect to use normative language where it clarifies something. Where only a single protocol identifier is available, it is not really needed.

Monica: Why not put it in?

Max: It does not seem to be needed. We are just saying there is a capability. The current text is fine. To be consistent with this change, we would have to change a lot of text. Would there be interop problems if this is not changed?

Joe: Not aware of any interop issues if the changes are not made. But it seems unbalanced. However, we don't feel very strongly about it.

Monica: It is better to use normative text in a normative section.

example:

[10:57] joef: An initiator registers for this protocol using the following protocol identifier:

[11:04] ericn: An initiator that registers for this protocol MUST use the following protocol identifier:

Joe: will paste next one: I don't want to spend lots of time on this.

[11:08] Ian R: A participant MAY register for more than one of these protocols by sending

multiple Register messages.

[11:08] ericn: ian's suggestion above

[11:08] ericn: A participant MAY register for more than one of these protocols.

[11:09] ericn: current suggestion

[11:09] ericn: for line 172

Line 185

[11:10] ericn: A Completion protocol coordinator MUST be the root coordinator of an atomic transaction

[11:10] ericn: suggestion for line 185

[11:12] Andy: Cases exist where a Coordinator or Participant has forgotten a transaction that

is completed and needs to respond to

a resent protocol message. In such cases, the [source endpoint] property SHOULD be used as

described in section 3.3

of WS-Addressing 1.0  Core [WSADDR].

[11:12] ericn: lines 487-488

Andy: I need to go through and capitalize as appropriate then we can review those changes.

Ian: The rest of the issue is done. We need to formally resolve 107.

Joe: Move to accept proposal and amendments made during the discussion.

Ian: Second

No objections. Issue 107 resolved.

11. WS-TX Unwinder, Sponsored by Hitachi. Starts 6:30pm

Location: 62 Peakham Road, Sudbury MA

URL: http://maps.google.com/maps?saddr=48+Monument+Sq,+Concord,+MA+01742&daddr=62+Peakham+Road,+sudbury+MA&f=li&hl=en&ie=UTF8&om=1&z=12

WEDNESDAY 8 Nov 9am 5pm EST

Re-review any further BA changes Tom

Tom: I sent an email with the latest revisions, this morning.

Changes for Issue 102:

Line 2 - defines - define

Line 85 - Issue 102, point 5 - not using URI - delete it

Line 104 - point 6 of issue 102

Line 125 - change SOAP 1.2 ref

Line 171 - Issue 102 point 8

Ian: propose upper case A for activation.

Tom: will include that editorial change.

177 - 102, point 8

205-207 - from yesterday's wordsmithing

218 - Preconditions Section added, with updates, matching AT document.

Andy: need to change the MUST in 218 to must, based on Monica's contribution. I changed the AT test.

Ram: Also update the "appropriate security credentials". No, that is correct as it is; it contains the updated text.

Tom: 227 - editorial change - part of errata changes for RFC 2119.

Tom: Note that many changes in 240+ should have been accepted as changes, and not show up on this version.

Line 272 - CannotComplete

281 - either inserted

311 - lower case may; inserted "for example"

351 - CannotComplete inserted

357-359- has all conditions, parsed into proper buckets

446 - correction to line number references

471 etc. - added hyperlinks

515- 518 - text moved from above, issue 104

519 - Issue 102 point 20

Deleted section on Interoperability considerations.

Updated change section

Ram: Maybe Jim Johnson needs to be added? No, apparently not.

Tom: 617-620 text added based on Issue 105

Tom: WSDL changes - WS-Addressing deleted from a line; messages shortened.

No changes to XSD.

Conduct approval ballot to approve BA PR draft Chairs

Ian: describes vote to move WS-BA to Public Review.

We need 50% of voting membership

Colleen - yes

Monica - abstain

Joe F. - abstain

Martin - yes

Tom Rutt - yes

Alastair - abstain

Kevin - yes

John Harby - yes

Charlton - abstain

Doug Davis - yes

In room:

Paul - yes

Eisaku - yes

Bob F.- yes

Andy - yes.

Eric - yes

Ian - yes

Tom F: yes

Max: yes

Ram: yes

Final vote:

4 abstain

15 yes

The vote has approved progressing the BA spec to PR.

Alastair: How many voting members are there?

Ian: 23

Monica: Do we need to vote for CD then PR?

Ian: I believe that is correct, procedurally.

Eric: Does anyone object to considering the vote as a combined CD approval and PR approval?

No objections.

Ian: Procedurally, we will produce a CD and then a PR draft.

Break while chairs submit BA PR material to OASIS Admin

Continue issue resolution for WS-C and WS-AT

Continuation from yesterday

Discussion:

Process for producing documentation to complete documents.

Bob: Wondering about schedule for tomorrow. I'll be in after 9:00.

Ian: We expect to finish issue resolution today, have the spec editors incorporate changes overnight, and review the docs tomorrow. I expect we will close the meeting in time for lunch.

After lunch:

Ian: When can we produce the documents?

Andy: Later this afternoon.

Ram: Almost ready now.

Ian: We will ask the Issues Editor (Ram) to develop an Issue disposition log.

Ian: We will give the editors an hour to get the documents ready.

Ian: During that hour, I'll send out the PR material to the TC Admin staff.

We'll reconvene at 3:00 and may be able to finish the complete agenda.

Working session to prepare CS material:

Prepare Issue Disposition Log for WS-C and WS-AT CS ballot

Prepare draft CS spec

THURSDAY 9 Nov 9am 5pm EST

Review WS-C and WS-AT CS material

Nov. 08 15:15

Ram: Reviewing WS-C Issues.

Ram: Using the Public Review (PR) draft as the base.

Ian: Procedurally, when we have the adoption vote, it needs to be a draft based on the PR draft. However, it's more correct to call it a Working draft..

Ram: It will be WD # 10.

Andy: Also a new doc identifier. I did that for AT.

Ian: This is the likely draft for the CD when the PR closes, if there are no more comments received during the PR time period.

Ram: Have also updated footer.

Changes in section 1.4.

1.6 - 95-96 resolutin to Issue 97

112-113 - ref to SOAP 1.2

[ covering each change ]

Ram: Some extra spaces deleted.

Andy: I got those same ones in AT.

LIne 735 - Added Choreology as affiliation for Peter Furniss.

Ian: We will accept the changes before submitting the CD. The specification has to go through PR, and must not contain any changes introducing incompatibilities.

Ram: This will be the final copy.

Ian: Once we adopt a Committee Specification, we will have to re-ballot if we make any changes. We can't make any changes after we send it for adoption as an OASIS Standard. There is the errata process, however.

Ram: After we get to the Committee Spec, how often will we meet?

Ian: We will still be focusing on BA. The chairs will cancel meetings which are not needed as we proceed, but we would like to keep the meetings on the calendar.

Ian: Is maintenance mode a consideration?

Martin: Info on the proposed maintenance mode. It is not yet approved.

Ram: XSD, WSDL review.

That completes the review of the WS-C spec.

Ram: Discussing the WS-C/WS-AT PR Issues Log document. As it notes, for all the PR issues resolved so far, the impact is that, "These issues were resolved with changes that were editorial in nature and no substantive changes were introduced."

Andy: WS-AT.

Andy: This is the most recent document. WD #12, including resolutions to Issue 108. I have sent it to the mailing list.

Andy: Made several changes to use upper case in Atomic Transaction, etc.

Andy: Intro - changed to "define."

Tom: Need to use "defines" since the subject is "set."

Andy, Ram: Okay

Andy: Line 31, changed "AT" to "this specification"

Andy: [continuing through the changes]

Andy: 141-145 are part of resolution to Issue 106.

[16:10] monica: how do we link the use of this namespace and line 67?

[16:10] Andy: 67: This MUST also be used as the CoordinationContext type for Atomic Transactions.

[16:10] monica: If that is the intent, ok.

Andy: Line 167, 169 - deleted should

[continuing through changes]

Andy: Line 439 - Security Context Token (SCT)

[16:41] Andy: Lines 519 - 520: 1.Transitions with a N/A as their action are inexpressible. A

TM should view these transitions as serious internal consistency issues that are likely fatal

conditions.

Andy: Will update text above list of participants.

Andy: That is all the changes, except the WSDL and schema.

Ian: Let's put up the latest docs on the web site, Then when the PR finishes, we will remove the appendix with change history, and accept the changes.  If there are no PR issues submitted as of the day before the next meeting (Thursday Nov. 16) I'll ask the editors to go ahead and make the Committee Spec documents ready.

[discussing process continuing on through moving to OASIS Standard for all specs]

We are on track to complete by February.

Ram: Will we have another F2F to deal with BA issues?

Ian: It makes sense to plan for it, to get it on everyone's calendar if needed.  It may not be needed.  Mark Little has offered to host a F2F.  Newcastle or Hursley are possibilities.  The BA PR should end about Jan. 14.  Jan. 15 is Monday.  We should plan for Jan 16-18 if possible.

Ian: We all wish to express our appreciation to Hitachi for hosting this meeting, and to Bob for the excellent evening yesterday.

Submit CS material for WS-C and WS-AT CS ballot

Minutes:

Text From Chat:

[10:46] Room information was updated by: John Harby

Call-in details:

US (toll free) 866-505-4412

UK (toll free) 0800 279 9193

Int'l (toll) +44-20-7019-0808

Passcode: 268450

[10:57] charlton: please ping the IRC chat if there are any votes that will be taken, as a number of us are also at WS-Policy today

[11:10] Paul Knight: Charlton, got your request, will note any votes in the chat.

[11:18] Ram: Proposal for action item: Messages sent to the target protocol service endpoint carry all reference parameters contained in the Endpoint Reference, according to rules defined by the WS-Addressing specification [WSADDR].

[11:19] Ram: Monica's proposal 1: These Endpoint References contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Endpoint References are defined using WS-Addressing [add link] EPRs.

[11:19] Ram: Monica's proposal 2: These Endpoint References may contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Endpoint References are defined using WS-Addressing [add link] EPRs.

[11:19] Ram: Ram's proposal: These Endpoint References may contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol service endpoint. These Endpoint References may contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Endpoint References are defined using WS-Addressing [add link] EPRs.

[11:21] Ram: Old text: These Endpoint References may contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol service endpoint. According to the mapping rules defined in the WS-Addressing specification, all such reference properties must be copied literally as headers in any message targeting the endpoint.

[11:22] charlton: thx

[11:23] Ram: Ram's proposal: These Endpoint References may contain (opaque) wsa:ReferenceParameters to fully qualify the target protocol service endpoint. Messages sent to the target protocol service endpoint carry all reference parameters contained in the Endpoint Reference, according to rules defined by the WS-Addressing specification [WSADDR].

[11:32] mfeingol: Endpoint References MUST be interpreted according to the rules defined in WS-Addressing 1.0 Core [WSADDR].

[12:24] Tom Freund: The participant It SHOULD completes application processing and MUST transmit the Completed notification.

[12:24] Ian R: Tom Freund: The participant completes application processing and MUST transmit the Completed notification.

[12:41] Ian R: Protocol faults raised by a Coordinator or Participant during the processing of a notification message are terminal notifications and MUST be composed using the same mechanisms as other terminal notification messages.

[12:41] Martin: I just dialled in...add me to the roll please

[12:42] Ian R: Martin- got you

[12:43] Tom Freund: Protocol faults raised by a Coordinator or Participant during the processing of a notification message are terminal notifications and MUST be composed using the same mechanisms as other terminal notification messages.

[13:00] Paul Knight: breaking for lunch, back in one hour, starting with agenda item 9.

14:15] Martin: im back on

[14:16] Ian R: http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00102.html

[14:17] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative. Typically those actions are neither made persistent nor made visible to other

activities....Commit directs the participants to make the tentative actions final.  For

example, they could then be persisted and made visible to other transactions.  Abort directs

the participants to make the tentative actions appear as if the actions never happened."

[14:22] Ian R: >Ian Robinson wrote: The text I proposed is trying to more precisely state

exactly this. Its a very minor thing but I think that if we are going to clarify ths text as

suggested in issue 102 then we should make it clear that the AT commit is simply directing

the participants to make their tentative changes final. Previously the text might have been

interpreted that "tentative" meant "not persistent" and so "commit" meant "make persistent".

For some participants that is exactly what it means but not, typically, for Volatile2PC

participants. And, even for those participants where commit does result in a tentative change

being made persistent, it is the participant (or a resource manager it delegates to) and not

the coordinator that deals with persisting the data and making it visible.

[14:23] Ian R: > >"The actions taken by a transaction participant prior to commit are only

> >tentative (and so typically are neither made persistent nor made visible

to

> >other activities)...Commit directs the participants to make the

tentative

> >actions final so they may, for example, be persisted and made visible to

> >other transactions.  Abort directs the participants to make the

tentative

> >actions appear as if the actions never happened."

[14:26] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative (and so typically are neither made persistent nor made visible

to other transactions)...Commit directs the participants to make the

tentative actions final so they may, for example, be made persistent and made visible to other transactions.  Abort directs the participants to make the

tentative actions appear as if the actions never happened."

[14:29] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative (and so typically are neither made persistent nor made visible

outside the transactions)...Commit directs the participants to make the

tentative actions final so they may, for example, be made persistent and made visible outside the transaction.  Abort directs the participants to make the

tentative actions appear as if the actions never happened."

[14:32] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative; typically they are neither made persistent nor made visible

outside the transaction...Commit directs the participants to make the

tentative actions final so they may, for example, be made persistent and made visible outside the transaction.  Abort directs the participants to make the

tentative actions appear as if the actions never happened."

[14:33] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative (and so typically are neither made persistent nor made visible

outside the transactions)...Commit directs the participants to make the

tentative actions final so they may, for example, be made persistent and made visible outside the transaction.  Abort directs the participants to make the

tentative actions appear as if they never happened."

[14:34] Ian R: "The actions taken by a transaction participant prior to commit are only

tentative; typically they are neither made persistent nor made visible

outside the transaction....Commit directs the participants to make the

tentative actions final so they may, for example, be made persistent and made visible outside the transaction.  Abort directs the participants to make the

tentative actions appear as if they never happened."

[14:39] monica:    Change from: The correct operation of the protocols requires that a

   number of preconditions MUST be established prior...

   Change to: The correct operation of the protocols requires that a

   number of preconditions are to be established prior...

   Reason: The individual bullets specify the level of requirement.

[14:55] monica:   211 Upon both receiving a Commit notification in the completion

    protocol and successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[14:56] monica: Current:

[14:56] monica:    211 After receiving a Commit notification in the completion protocol

    and upon successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[14:56] monica: Ram:

[14:56] monica:     211 Upon receiving a Commit notification in the completion protocol

    and upon successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[14:57] monica: monica slightly modified:

[14:57] monica:     211 Upon both receiving a Commit notification in the completion

    protocol and successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[15:00] monica: Assuming sequential:

[15:00] monica:     211 Upon receiving a Commit notification in the completion protocol

    and then successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[15:01] monica: Upon successfully completing the

    222 prepare phase for Volatile 2PC participants, the root

    coordinator begins the Prepare phase for Durable

    223 2PC participants.

[15:01] Ian R: strike "After receiving a Commit notification in the completion protocol and "

[15:02] Ian R: Upon successfully completing the prepare phase for Volatile 2PC participants, the root coordinator begins the Prepare phase for Durable 2PC participants.

[15:07] Paul Knight: issue 104

[15:21] Paul Knight: Issue 105

[15:39] Paul Knight: wordsmithing is often quiet work

[15:40] Ian R: Unexpected protocol messages MUST result in a fault message as defined in the state tables. These faults use standard fault codes defined either in [WS-COOR] or in Section 5, Transaction Faults.

[15:40] Martin: pardon?

[15:45] Paul Knight: 10 minute break

[16:11] Martin: long 10 minutes

[16:12] Paul Knight: We're almost ready to start

[16:14] Paul Knight: issues 106, 108, 107 will be attacked next

[16:14] Paul Knight: back on the line

[16:15] Paul Knight: Issue 106

***************************************

chat from Wednesday morning

[9:18] monica: good morning

[9:18] monica: only on irc

[9:18] monica: started yet?

[9:19] kevin: yes, Tom is going through the BA updates

[9:22] monica: ok

[9:22] monica: thanks

[9:25] charlton: i wanted to confirm whether we could hold WS-BA Public Review adoption ballot at 11.00 ET vs. 10.00 ET

[9:26] charlton: sounds like from Eric that we won't, and will hold it at 10.00....

[9:31] tomRutt: only on irc

[9:32] Paul Knight: If we don't have 2/3 positive vote at 10:00, will try again at 11:00...

[9:34] charlton: ok

[9:34] charlton: only on irc

[9:40] monica: paul can you put ticklers of info in irc until we can join?

[9:40] monica: thanks.

[9:40] ericn: yes we are giong to try for 10 am all right

[9:41] Paul Knight: Still planning to vote at 10:00.  Please call in at that time if possible.

[9:42] ericn: we can accept a vote by IRC since we can append the IRC log to the meeting minutes

[9:42] Paul Knight: We have completed the BA review and will cover other issues until 10:00

[9:43] Paul Knight: topic: Issue 106

[9:46] monica: joining

[9:46] monica: on mute however

[9:50] monica: I am here but I can't talk right now.

[9:51] monica: We didn't finish 107

[9:53] tomRutt: I just joined call on mute

[9:53] Paul Knight: topic: Issue 103

[9:55] Paul Knight: topic: Issue 101

[9:56] Ian R: http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200610/msg00057.html

[9:56] Paul Knight: will vote in a few minute on BA

[10:01] Paul Knight: Please call in now for BA vote.

[10:02] monica: Martin=abstain

[10:02] tomRutt: i vote yes, on mute

[10:03] Dug: I vote 'yes'

[10:03] Dug: can I get on the roll?

[10:04] John Harby: 14 yes 5 abstain

[10:05] ericn: 15 yes 4 abstain

[10:06] tomRutt: both are 50+ majority votes are they not?

[10:07] John Harby: can we use motion

[10:08] tomRutt: I do not object to my vote both for CD and pub review

[10:08] ericn: thanks

[10:08] John Harby: ditto

[10:10] Paul Knight: topic: Issue 101

[10:11] charlton: Can I get on the roll?

[10:11] charlton: on the call on mute ;_)

[10:12] monica: on the phone on mute too

[10:12] tomRutt: the tc process http://www.oasis-open.org/committees/process.php#3.1 and 3.2 states that both cd vote and pr vote are full marjority vote of TC

[10:12] ericn: ok charlton

[10:13] ericn: ok but i think we had that since we asked whether we could use the same vote

[10:13] tomRutt: agree

[10:13] John Harby: +1

[10:14] charlton: thanks eric

[10:36] Paul Knight: received a message which is invalid for the protocol supported by the endpoint

[10:38] alastair: This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for the protocol supported by the endpoint.  This is an unrecoverable condition

[10:39] ericn: This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for the protocols supported by the endpoint.  This is an unrecoverable condition.

[10:42] John Harby: i need to take care of a few things at the office, will be back later

[10:43] ericn: ok

[10:44] ericn: This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for the protocols supported by the endpoint.  This is an unrecoverable condition.

This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for the protocols supported by the endpoint.  This is an unrecoverable condition.

This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for one of the protocols supported by the endpoint.  This is an unrecoverable condition

[10:45] ericn: This fault is sent by either the coordinator or a participant to indicate that the endpoint that generates the fault received a message which is invalid for the protocols supported by the endpoint.  This is an unrecoverable condition.

[10:47] monica: abstai

[10:47] monica: abstain

[10:49] alastair: Sorry got to go to another meeting.

[10:49] ericn: ok

[10:50] monica: http://lists.oasis-open.org/archives/ws-tx/200610/msg00103.html

[10:50] monica: we were on second item on the issue - line 172

[10:50] joef: A participant MUST register

using one of the protocol identifiers defined in this section.

[10:51] monica: A participant MUST register

using one of the protocol identifiers defined in this section.

[10:51] monica: volatile and durable 2 pc description exists above this text if accepted.

[10:57] joef: An initiator registers for this protocol using the following protocol identifier:

[11:04] ericn: An initiator that registers for this protocol MUST use the following protocol identifier:

[11:05] monica: +1

[11:05] ericn: thx