Preliminary WS-RX Face to Face Minutes

Thurs September 22, AM Minutes

Minutes Style Conventions

Motion text

§ Motion Resolution text

Ų Action item text

Ų Potential new issue Text:

12 Thursday AM Issue Discussions

On suggestion of Chris F, Issue 21 was taken off the agenda, because it needs further email discussion

Issue 006 is also off the agenda, because it is related to issue 008.

12.1 Issue 29 – Security composition

Gill presented an overview of his contribution at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00201.html

Gil: This contribution examines the threats that the current security token in the create sequence exchange is intended to thwart.

Paul F: This logic could be put into an implementation, without it being in the RM spec itself.

Gil: there is a tight binding between ws and rm, in the current spec, which is not desirable. My proposal is to delete lines 494 thru 500 of the wd03 spec.

“

/wsrm:CreateSequence/wsse:SecurityTokenReference

This optional element uses the extensibility mechanism defined next to communicate an explicit reference to the security token to be used to authorize messages for the created outbound Sequence and if offered the inbound Sequence, using a <wsse:SecurityTokenReference> as documented in WS-Security [WSSecurity]. All subsequent messages in the outbound Sequence and if offered the inbound Sequence MUST demonstrate proof-of-possession of the referenced key.

“

Chris F: the threat that this is trying to be protected against is that someone can hijack sequence. Performance is an issue, we do not want to encrypt the rm header. XSL is not always end to end, so there are cases where the sequence may be hijacked. The mechanism in the spec works, and is efficient. It is an optional mechanism, however if used the other side must comply with its use.

Gill: but there are other ways to do this. The spec does not show why this mechanism is necessary.

Chris F: we want an interoperable mechanism to avoid hijacking the sequence to be in the spec. We have a need to associate a security context with an RM sequence.

Gil: different ways to protect against this threat are appropriate to different applications in various circumstances.

Lei: I do not see the spec stating the rm sequence ID constitutes a single user session. I see two users on the same sequence is a valid use case.

Chris F: I did not say user, I said Identity. You have to have evidence of this credential to use the sequence. I can give the credential to any number of users. The text in lines 494 to 500 ensures this.

Martin C:: I believe different specs should be composable. This mechanism is appropriate as a separate profile, but does not belong in the base standard.

??? - The charter calls for this TC to define elements and relations among elements for efficient preservation of integrity using WS Security.

Rex: this ought to be structured as a layer above the base ws-rm protocol. Does IBM and Microsoft product architecture allow other ways to do this.

Chris F: this is a means we know will perform well and meet a level of security which are customers are happy with. A profile will delay this capability.

Glen D: I agree with Martin. The basic spec should be composable. However we could have another spec for this one mechanism.

Jeff M: This mechanism violates the principle of composability of WS specs. There are other approaches than this one IBM and Microsoft have placed into the Spec.

Umit: the word optional suggests that it does not have to be used. However if it asserted, it is required for an RMD to support.

Chris F: this is optional to implement.

Marc G: Others want to use transport security or other ws-s mechanisms. However this mechanism is a different way to compose with ws-security specific to rm, that is why it is in this spec. I am shocked to hear that interoperability is not important to some members of this TC. This is one way of composing with ws-s for use with ws-rm. If you do not want to implement it, it is optional.

Anish: I find the heated discussion surprising. The existing extensibility points in the spec enables the token to be carried in the message.

Glen:D: put that paragraph in a different spec, and refer to that spec in your product.

Paul F: an RMD implementation that does not support ws-security will send a fault back to the RMS. The problem with coupling is that our spec relies on a particular version of the WS-security spec. If they change the security spec, we are more coupled. Glen’s idea of a different spec for this mechanism has some benefit.

Tom R: the only way an RMD can say it does not support this option, if asserted by the RMS in the create sequence exchange, is for the RMD to not accept that sequence creation (i.e, return fault code). The RMS, could if it wanted, back off from using that mechanism, or decide to not communicate with that RMD.

Gil: I move to remove lines 494 to 500, and the example on lines 450 to 452, Jeff M seconded.

Paul C: the fact that this is optional makes this motion unnecessary. Other mechanisms can be used.

Marc G:: I am against this motion, because it reduces interoperability. Why remove an optional element which at least two companies want to use and enable interoperability.

Jeff M moved to call question, Gill seconded.

8 for call

12 against call

§ RESOLUTION: Call fails.

Chris F: if we take this as an extension point, it can be ignored. It does not have a wsrm:mustUnderstand attribute. When the option is being used, there is required behaviour. We are using an extensibility point in the schema, and a receiver must behave in the standard manner, or it must not accept the sequence. It cannot be a profile, because we want required behaviour.

Martin C: I would like to amend the motion to move the text to another document with a separate conformance point. NO second

Paul C: This element is in the wsrm namespace. Do you want it to be in a different namespace.

Anish: this is already in the ws-s namespace.

Glen D: it would be better to put it into another header with a must understand attribute.

Chris F: we have an optional thing with a MUST. You do not have to implement it, but you must implement the ability to recognize it in a create sequence message, and fault if the RMD does not support the mechanism.

Glen D: the extension must be followed, if present, or fault. The extensibility mechanism is flawed, in that it does not have a “mustUnderstand” mechanism associated with it.

Gil: my concern is that this puts a tight coupling between two ws specs which is not warranted.

Jeff M moved to call question on the motion, seconded by Abbie.

14for call

3 against call

§ Motion to call question passed.

Sumit Gupta new to roll

Iwasa on roll from Wed PM.

Vote on motion to remove 450 452, and 494 – 500.

15 yes

14 no

8 abstains

§ RESOLUTION: Motion to close issue 29 with removal of lines 450-452 and 494-500 passes.

12.2 Issue 3 – epr and sequence scope

Anish proposal at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00249.html

Issue i003 was raised during the 1st f2f when there was a statement made

that the Sequence was a binary relationship between two Endpoints. This

statement raised the the question as to which two endpoints were

involved. One of course was wsrm:AcksTo, what is the other one (the RMD

does not necessarily have a wsa:EndpointReference or a WSDL description

for that matter)?

The spec itself does not have such a statement and therefore I don't

think this is an issue against the spec. I propose that we close this

issue with no action.

Doug D: the spec does have one place talking about “exactly two parties”. This is incorrect. It is related to Issue 10. However I do not disagree with closing issue 3.

Anish moved to close issue 3 with no action, Steve W seconded.

Serge: we need to precisely define the scope of an sequence.

Sanjay: Issue 10 will provide the discussion point for the scope.

No objection to adopt motion.

§ RESOLUTION: Motion to close issue 3 with no action passed.

12.3 Issues 2, Changing AcksTo during sequence

Anish mail at : http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00256.html

Two corrections below (forgot to include the Sequence id).

-Anish

Anish Karmarkar wrote:

> All,

> I had an action to send a proposal for issue i002 [1]. Here it is.

> Issue i002 was raised during the 1st F2F. The issue was raised in the

> context of long running Sequences where it was possible for the AcksTo

> EPR to change. There was also some discussion on unending sequences (I

> think Steve Winkler brought this up). In a long running Sequence it is

> possible that the AcksTo EPR may change and therefore the RMS needs the

> ability to let the RMD know of the new AcksTo.

> Subsequently, I have been talking with our mobile folks and they have

> brought up a different usecase (but which has the same issue):

> In the mobile world there are cases where the RMS is expected to have

> different EPRs throughout the life of the Sequence (the device changes

> cells/location/countries or is intermitantly offline), therefore it

> necessary to provide the capability to change the AcksTo EPR for a

> particular Sequence in progress.

> Here is the outline of a proposed solution:

> 1) The RMS is allowed to send a new message called wsrm:ChangeAcksTo

> with the following pseudo-schema --

> <wsrm:ChangeAcksTo Version="xs:unsignedInt" ...>

<wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

> <wsrm:AcksTo ...> wsa:EndpointReferenceType </wsrm:AcksTo>

> ...

> </wsrm:ChangeAcksTo>

> 2) The RMD responds with wsrm:ChangeAcksToResponse or a fault with fault

> [Subcode] wsrm:ChangeAcksToDisallowed. wsrm:ChangeAcksToResponse has the

> following pseudo-schema --

> <wsrm:ChangeAcksToResponse Version="xs:unsignedInt" ...>

<wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

> ...

> </wsrm>

> The /wsrm:ChangeAcksToResponse/@Version has to contain the same value as

> the corresponding one in wsrm:ChangeAcksTo

> Version numbers are strictly monotonically increasing numbers starting

> at 1 (the AcksTo EPR in the CS message being version 0).

> The reason to have a version number in the exchange is because

> wsrm:ChangeAcksTo message may be retransmitted/lost/delayed/received

> out-of-order and it is necessary to prevent the RMD from regressing to a

> previous AcksTo.

> On sending a wsrm:ChangeAcksToResponse message, the RMD sends subsequent

> acks to the new AcksTo EPR.

> Comments?

> -Anish

Anish presented his proposal.

Paul F: this adds complexity for a corner case. There is nothing requiring an EPR to be tied to an IP address.

Anish: a mobile device can change its replyTo, but it has no way to change the AcksTo.

Chris F: I agree with Paul F. I am not in favor with this. This is not a problem for RM to deal with exclusively. Leveraging the network capabilities does not require tying an AcksTo URI to a fixed IP address.

Paul C: This opens up a security hole, allowing hijacking the sequence easily. Since there is now no standard way to secure the rm sequence, I would not want to adopt this proposal.

Anish: I agree we should not take action today. This is not a complete proposal. However the security threats are not different than those already there. The complete proposal should include a security analysis.

Sanjay: I have security concerns as well. Changing an agreement made in initial setup phase can cause many problems. The complexity is not warranted.

Jacques: The description and justification for the issue need to be more complete (perhaps with a used case). I would avoid new signaling. If closing and starting a new sequence could meet the use case, it should be the preferred manner.

Anish: I agree to study the mobile used case further.

Stefan: Mobile EPRs is a separate issue from RM. This should be solved in a generic manner.

Abbie: I am totally opposed to adding the changeAcksTo message. There are many more complications. Nortel has solutions for mobile endpoint networking.

Steve W: I agree that closing sequence and opening new one is an appropriate way to deal with the mobile use case. Changes to accommodate mobile EPRs should be address somewhere else than WS-RM spec.

TC agreed to leave this issue open for now, and to take discussion to email list.

12.4 Issue 35 (anonymous uri)

Description

WS-Addressing Core [1], section 2.1 says the following about 'anon':

"Some endpoints cannot be located with a meaningful IRI; this URI is

used to allow such endpoints to send and receive messages. The precise

meaning of this URI is defined by the binding of Addressing to a

specific protocol."

WS-Addressing SOAP binding [2] defines what the 'anon' address means

when used with ReplyTo and FaultTo in SOAP and SOAP/HTTP binding. It

does not say anything about what it means when used in other headers

such as AcksTo.

Justification

WSRM defines AcksTo element of type EndpointReferenceType and allows

'anon' URI for the address. But the meaning of such an anon address is

not defined anywhere.

Related Issues

i012

Origin

Anish Karmarkar

Owner

Anish Karmarkar

Proposal 12005-09-08

This can be resolved by:

a) Adding a stmt similar to WS-Addressing SOAP binding. Something like:

"When "http://www.w3.org/2005/08/addressing/anonymous"; is specified as

the address of the wsrm:AcksTo EPR, the underlying SOAP protocol binding

provides a channel to the specified endpoint. Any underlying protocol

binding supporting the SOAP request-response message exchange pattern

provides such a channel. For instance, the SOAP 1.2 HTTP binding[SOAP

1.2 Part 2: Adjuncts] puts the reply message in the HTTP response."

b) we could ask the WS-Addressing WG to fix their SOAP binding to

include not just ReplyTo and FaultTo EPRs but any EPR when used in the

context of SOAP/HTTP binding.

I prefer that we do (b). If they refuse, we can do (a)

Anish: presented his email.

Several people expressed a preference for approach b).

Umit: I propose that we take this to the ws-addressing group, which is meeting next week. After their discussion we can come back to this.

Tom R: I see no problem with making statement a), even if the ws addressing group does make the same clarification.

Jonathan: it is better to have the statement in one place.

Serge: the ackTo context is defined in WS-rm. Why not define AcksTo here.

Anish: every binding must define this. If defined in ws-addressing all soap/http binding it is available for all users of that binding, not just ws-rm.

Sanjay: we could agree to text changes to our document now, and can change it later if ws-addressing makes the change.

Umit: I feel it is better to ask the WS-addressing group first.

Doug D: Does this give additional semantics to anonymous in ws-addressing, which do not apply to their current use with wsa:replyTo and wsa:FaultTo.

Paul F: I propose that we open action item to have Doug D ensure that the changes in ws-addressing will meet our needs fully.

Glen D: The text in WS-addressing will be more generic.

Sanjay: whatever ws-addresssing comes up with could serve as the basis for the text we include in ws-rm.

Anish: I do not understand Doug D concern. WS addressing says (for replyTo or FaultTo) for http binding anonymous means use http response back channel.

Jonathan: In addressing you never have both reply to and ack to going back for a request. For WS-RM there might be two things going back by piggyback.

Doug D: my concern is the use of piggyback acks and message replies on the http back channel.

Ų ACTION: Doug D will write new issue to characterize the piggybacking of acks when using an anonymous AcksTo.

ACTION: Umit will ask the WS-addressing group to discuss making anonymous URI description more generic. She will get back to us on their discussion

Paul F: if we do not get ws-adressing updated we can fall back on a specific wording for ws-rm.

Agreed to leave issue open for now.

12.5 Issue 10 – Sequence spanning ports

Description

Is there a need to allow a single sequence to span multiple ports?

Justification

"Having a single sequence span multiple ports (much like an MQ queue does)

could be needed as well."

Doug proposed. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00251.html

I took an AI to write up a formal proposal for issue 10:

Issue 10, as stated, deals with whether or not a single RM sequence can span multiple ports. Looking at this issue some more though I believe the broader issue is really whether a single RM sequence can span multiple endpoints as well. Should the RM spec limit a single RM sequence to just a single RM Source and RM Destination or should it leave it up to the implementation to decide? I believe it should leave it up to the various implementations. If an implmentation is smart enough to share RM state across multiple endpoints then there is no reason why a single sequence could not be used to deliver messages to all of them (and to be clear I do see multiple RMSs and RMDs being an option). So, with that mind I'd like to propose the following changes to the specs:

Using this version of the RM spec: http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14548/wsrm-1.1-spec-wd-03.pdf

Line 80:

remove the word "exactly" in the

sentence "...delivery of messages between exactly two parties,..."

To the end of line 439 add:

This specification makes no restriction of the plurality of the

RM Source or RM Destination. If implementations can support

a single RM Sequence spanning multiple WSDL ports or even

multiple service endpoints then they are free to do so. However,

it is out of scope for this specification to define how this

ability is communicated or achieved.

Serge: I agree we need to clarify the scope of a sequence. I do not disagagree with allowing more than two ports.

Jacques; Is the sequence addressed as several ports with same RMD, or may ithe same sequence be used for two RMDs.

Doug D: a single sequence spanning multiple RMDs is application specific. Any RMD could reject messages with an unknown sequence ID. However there may be application specify ways to make more than one RMD to be aware of a given sequence ID.

Jacques: You still must keep the notion that there is an abstract RMD to keep state knowledge, to maintain the acknowledgement semantics.

Doug D: the current spec wording “exactly two” could be construed as disallowing what I want to allow.

Chris F: Line 436 would also need to be changed.

Sanjay: by adding the text above we are placing it directly in scope of the specification.

Doug D: I really want to remove the “exactly” in line 80 and to change the text in line 436. I am open to refine my proposal if there is general agreement.

Tom: Is Sanjay just concerned about adding the extra new text in Doug D proposal.

Sanjay: yes that is my concern.

Lei: What about the definition of RMS and RMD

Doug D: the definitions refer to endpoints sending or receiving a single reliabile message. They do not refer to the sequence.

Doug D: if we just take away “exactly” we still have the problem of other text which is misleading, I could take an action to change any text which implies a restriction to two endpoints.

Umit: there needs to be scoping to require the multiple RMDs to interact to treat the sequence properly.

Doug D: of course the multiple RMDs would have to have ways to share the common state of the sequence. However the mechanisms to do this would be out of scope of ws-rm.

Serge: perhaps the create sequence message needs to be changed to accommodate this.

Doug D: it is quite possible to do this without changing the signatures of the create sequence exchange.

Anish: I agree with what Doug D is saying.

Vadim: I am against this proposal. This would need to work with any RMS implementation. If the RMS to do this must be made by the same provider as the Multiple RMDs, this breaks interoperability.

Lei: how would the source determine which of the multiple RMDs to send each message to.

Doug D: that would be out of the scope of the spec.

Sanjay: At this point I see this proposal as leaving the back door open. Making it possible with out saying how to do it leaves the back door open.

Doug D: either add the new paragraph, or tweak the text before it to remove the restriction to singleton.

Jacques: The proposal is not good enough. I can agree with the use case scenario of having a sequence spanning several destinations sharing state. I have trouble with the statement that a sequence can handle several RMDs. Perhaps change the wording that sequence can span several implementations, providing they behave as a single abstract RMD.

Doug D: what about wording to imply “virtual RMD” is allowed.

Serge: what would the RMS use for the actual destination for each message in the sequence.

Doug D: one could perhaps use a logical wsa:to address, with different http addresses for subsequent messages sent in the sequence. The sending application would have to be designed to deal with this.

Glen D: for example wsdl markers could be used for this.

Serge: You would need a specialized virtual address for all messages in the sequence for this to work.

Glen D: such mechanisms would be out of scope. Rm defines how to send message with its semantics, it does not need to restrict the topology of the nodes in the system.

Umit: A simple solution is to modify 80, to say “between a source and a destination”. There is no need to add the extra paragraph.

Doug D: my proposal was to add a paragraph, rather than removing all offending text.

Umit: I suggest removing all offending text rather than adding that paragraph.

Doug D: I could agree to tweak line 80, and to modify the line 436 paragraph rather than adding the new paragraph, if the TC would find this acceptable?

Sanjay: the charter speaks of exchanges between two web services.

Jacques: I would like to discuss alternatives to Doug’s approach. We could define rms and rmd in a more abstract way, not associating them explicitly to an endpoint.

Paul F: I would also prefer that.

Doug D: do you mean to change the glossary definition.

Jacques; eg “the Soap processing entity capable of performing RM functions on receiving/sending a message”

Doug D: I would have to think about that further.

Sanjay: straw pool on agreeing with clarification of definitions to take away single endpoint restrictions from RMD and RMS (including the definitions), and not include additional text.

Steve W: how about the straw poll about whether this is worth pursuing.

Paul F: how about Yes means do something, no means close with no change.

19 yes

2 no

Ų ACTION: Doug D to post alternative proposal, taking away the additional text in his original proposal on Issue 10.

Agreed to leave issue 10 open for now.

12.6 Issue I 25 discussion continued:

Glen presented his proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00245.html

RX'ers:

Here is the new proposal for i025 in pseudo-schema....

<wsrm:SequenceAcknowledgement ...>

<wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

[ [ <wsrm:AcknowledgementRange ...

Upper="xs:unsignedLong"

Lower="xs:unsignedLong"/> +

<wsrm:Final/> ? ]

| <wsrm:Nack> xs:unsignedLong </wsrm:Nack> +

| <wsrm:None/>]

...

</wsrm:SequenceAcknowledgement>

Essentially this just adds a new choice, <wsrm:None/>, which acts as an

explicit marker to indicate that no messages have been received.

The reason that Anish and I like this proposal so much is that it seems

to satisfy the desires of both camps:

* The people who want an EXPLICIT marker (rather than the absence of

something) to represent this case get their wish.

* The people who do NOT like the potentially confusing overloading of

sequence numbers with a 0,0 case (and all the requisite special-case

coding) get their wish of something that is clear to code.

Here is the actual proposal:

1) Amend the schema to add a third <xs:choice> element, <wsrm:None/> in

parallel with Nack and AcknowledgementRange.

2) Explain the meaning of this element in the text, i.e.

"/wsrm:SequenceAcknowledgement/wsrm:None -- no messages were received".

3) Editors to clean up the text around AcknowledgementRange (i.e. is it

really optional, etc...)

There you have it.

--Glen

Jorgen also posted a proposal at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00253.html

’d like to propose an alternate resolution for issue 25.

In the meeting yesterday, we discussed issue 25 and the group expressed its opinion that they preferred a definite statement to be made in this boundary case of no messages received yet.

The remaining proposal being considered last night was to send “Ack 0..0” for the case where no messages have been received.

<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever">

<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

<wsrm:AcknowledgementRange Upper="0" Lower="0">

</wsrm:SequenceAcknowledgement>

My intellectual concerns with this approach are that we are making an incorrect statement – we are acknowledging receipt of a message [#0] that (a) we haven’t actually received, (b) doesn’t actually exist, and (c) will never be sent

My practical concerns with this approach are that I fear this change may cause a large ripple effect on implementations.

I suspect implementations will need to change to explicitly recognize and exclude / ignore the dummy message #0 anywhere they use a sequence range (although I haven’t actually checked into the details yet).

Also changing the schema to say #0 is in the message number range makes it harder to do effective validation of message content on the wire (should you wish to do that) – specifically is Ack 0..10 valid or just Ack 0..0?

I believe we already have existing features of the RM spec that can be used to solve this problem and make a definite but correct statement to handle this boundary condition – We can assert “I’m still waiting for you to send me the first message” – eg. “Nack 1”

<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever">

<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

<wsrm:Nack>1</wsrm:Nack>

</wsrm:SequenceAcknowledgement>

The advantages of this approach are:

1. It makes a definite statement rather than relying on the absence of a statement to convey meaning

2. The statement made is accurate – “I haven’t received message #1”

3. We don’t need to change the message number range to accommodate this boundary condition – the schema can show the real 1..unbounded condition to allow better validation of on-the-wire messages

4. We don’t need to introduce and document the concept of the fictitious “Message #0” and explain where and when it is valid to use that message number

5. I _suspect_ the impact on existing implementation will be less by not introducing lots of special-case handling code

6. We are re-using existing functionality in the spec rather than introducing new functionality to handle special cases – which should ultimately lead to fewer code paths and a smaller surface area.

7. This approach is basically backward compatible with exiting spec versions (both syntactically and semantically) – it represents a clarification for this boundary case rather than introducing completely new functionality.

So I propose the following resolution for Issue 25

Recommend that an RMD be required to respond with a SequenceAcknowledgement element containing a Nack child element with content “1” to signify that the first message has not yet been received for a given Sequence. e.g.

<wsrm:SequenceAcknowledgement xmlns:wsrm="http://docs.oasis-open.org/whatever">

<wsrm:Identifier>http://example.org/mysequence/1234</wsrm:Identifier>

<wsrm:Nack>1</wsrm:Nack>

</wsrm:SequenceAcknowledgement>

Chris F: the proposal by Jorgen changes the semantics of Nack.

Glen D: a nack is a push rather than a pull. Putting the NACK in there is doing something we would not do otherwise. As I have stated many times, Nack should be placed in a separate message header.

Glen D: I still think the simplest solution is to send an empty sequence.

Paul F: straw poll: who does not like Glenn approach of adding a new exclusive “none” element.

Who does not like Jorgen approach

Many

Anish moved to accept Glen’s Proposal for resolving 25, Glen D seconded.

Discussion:

Vadim: would it be an error to send the “none” after an ack had been sent previously.

Glen D: yes.

Gil: there are secondary issues to clean up the other text. However we can raise other issues to fix this.

Lei Jin: I see no extra problems with this proposal

Vote on motion

17 yes

2 no

10 abstain

§ Motion to close Issue 25 with Glen D proposal passed.

12.7 Issue 31- Inconsistency between spec and schema for ackRequested

Chris F proposal at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200509/msg00119.html

Proposal to fix schema to meet text in spec.:

Chris F moved to close issue 31 with proposal in his email, Abbie Seconded.

No objection.

§ RESOLUTION: Motion to close issue 31 with proposal from Chris F email.

13 Next f2f

Sanjay: :there is an offer for 14 and 15 December from Fujitsu in Sunnyvale CA.

Apache conference is 10- 14 of December, in SanDiego.

Who cannot do Sunnyvale on 14 and 15^th December?

5 people

Chris F: IBM could host, with the Location tbd. We need a big facility for this group. Pallisades, Armonk or Raliegh are possibilities.

Tom Rutt: New York area can have snow problems in mid December.

Motion by Umit, seconded by Jeff M, to accept Fujitsu 14 to 15 offer.

Straw poll (who can attend 24 to 15 in Sunnyvale

27 yes

5 no

§ RESOLUTON: The group agreed to accept the Proposal from Jacques for the next F2F to be hosted by Fujitsu on Dec 14 and 15 in Sunnyvale..

Issues 25,31 (seqAck when no messages, spec/schema inconsistency)

Issue 32 (on-wire optimization)

14 Discussion on Participation obligation and CDs

Paul presented a slide on participation obligation an CDs.from Section 9.2 of IPR policy

Paul F warned the TC members that this must be observed.

Paul F proposed to produce a new CD after each F2F.

November,

February

May -> Committee Spec

Paul: proposed Issues to be addressed in CD 1, to be published sometime in November.

Issues closed, 4, 12, 14, 18

Issues in editor status: 1, 5, 11 13, 16 17, 19, 27, 28

Issues agreed in Seattle: 20, 26, 24 …

Any follow up issues from this meeting (e.g., 6, 8, and 21)

Gil what about new issues that come up before the next F2F.

Paul F: .Unless they are easy they will be in the next CD.

Paul C: why not just include decisions that are made in this meeting. That is to take away the follow up issues in his proposal.

Chris F: we need to be careful about a hard cut agreed now.

Paul C: we will not figure out that until we agree on the first batch.

Paul C: I suggest we give the editors a clear statement Today, before the closure of the F2F, an explicit list of issue resolutions to include in the first CD.

Paul C: when we see a doc from editors it has to have change bars. Any date of delivery depends on the action item to Gil on change bars.

Anish: the tools can indeed compare documents, so we just need to send a proposal to the list. I suggest the editors make a decision before the end of the F2F.

Paul F: the shorter the timeframe to CD after this meeting is better.

Paul C: is a two week window to review the text for CD adequate?

Jeff M: is the review just on whether the editors executed the proposals correctly?

Paul C: people can vote no for any reason they want.

Paul C: I expect the CD change bars to be against the initial contribution, version 1.

15 New issues since last con call

16 Thurs PM issues

Issue 33 - nack processing

Issue 34 – Faults and piggybacking

ws-rx message

12 Thursday AM Issue Discussions

12.1 Issue 29 – Security composition

12.2 Issue 3 – epr and sequence scope

12.3 Issues 2, Changing AcksTo during sequence

12.4 Issue 35 (anonymous uri)

12.5 Issue 10 – Sequence spanning ports

12.6 Issue I 25 discussion continued:

12.7 Issue 31- Inconsistency between spec and schema for ackRequested

13 Next f2f

14 Discussion on Participation obligation and CDs

15 New issues since last con call

16 Thurs PM issues