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