OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Prelim minutes of f2f for Wed 3/22

The first day prelim minutes are attached.

The second day minutes will be sent after the meeting on Thursday.

Please provide corrections to these prelim minutes before Monday, March 27.

Tom Rutt

Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: Minutes of OASIS WS-RX Teleconference

Prelim Minutes of OASIS WS-RX Face To Face

March 22, 23, 2006


Start Time:4:00 PM Eastern Time


Paul Freemantle acted as chair.


Textual Conventions


Ø  Action Item


§    Resolution


0         Meeting Host Welcome

IBM gave a review of the meeting arrangements.



1         Roll Call

From Kavi:



xx of 49 voting members, meeting quorate


Tom Rutt agreed to take minutes.

2         Agenda Approval



13:00-13:45 Kickoff

- Welcome from hosts

- Roll call

- Review of Agenda

- Admin

(previous minutes etc)

- Review of open issues and acceptance of any new issues



Detailed review of Results from Interop

Raising of any new issues from Interop

Planning for next (online-only) Interop


15:00-15:45 issue i021/i008 discussion


15:45-16:00 break


16:00-17:00 Space for discussion of any newly issues.



8:30-9:00 breakfast


9:00-11:00 Anonymous URI and Offer - review of the Interop Scenario 2.4

Paul F to present issues.


11:00-12:00 Application Notes discussion


12:00-13:00 Lunch


13:00-14:00 Review and update of State Tables


14:00-15:00 Planning

Please see note: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00151.html

- Editors next steps

- CD4

- Ballot for PR

- Public Review

- Future distributed and F2F schedule


16:00 End



3         Admin

3.1      previous minutes






Bob F moved to approve both 3/9 and 3/16 minutes.  Tom R seconded.


§    No objection, minutes of 3/9 and 3/16 approved.

4         Review of open issues and acceptance of any new issues

4.1      New Issues

Four new issues since last meeting.

0.1.1      New proposed issue from Jacques;


NEW ISSUE: consistency in controlling the binding of SequenceAcknowledgement and of seq management responses


From: Jacques Durand <JDurand@us.fujitsu.com>

To: wsrx <ws-rx@lists.oasis-open.org>

Date: Tue, 21 Mar 2006 22:21:42 -0800







The protocol makes it possible to control how SequenceAcknowledgement can be returned to the RMS, w/r to the binding-specific channel of the underlying protocol, via the use of the WS-Addressing anonymous URI in the CreateSequence message (see i061 resolution). However the protocol does not offer any similar control on how the sequence management response messages (CSR, CloseSequenceResponse, and TSR) are making use of the underlying protocol binding-specific channel.




The deployment requirements that may lead to return SequenceAcknowledgement  headers


over the back-channel of an underlying 2-way protocol such as HTTP, will also require that sequence management response messages be also returned on the back-channel of the protocol. If not, it will not be possible to satisfy these requirements.


For example, these requirements may be: an RMS may not be able to receive incoming requests due to security restrictions, or to addressing restrictions. It is not consistent - and potentially an interop issue - to address these for Seq-Acks and not for sequence management responses.



Target: core




After, or soon after the addition from i061:


[ When the wsrm:AcksTo EPR specifies  the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel. ]



"When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the CreateSequenceResponse MUST also be transmitted by the RMD on the protocol binding-specific channel provided by the context of the CreateSequence message. This MUST also be the case for any response message (CLoseSeqResponse, TerminateSeqResponse) to related sequence management messages that concern the same sequence. "




Jacques stated that discussion after he sent the issue out pointed out the need to amend the details of the proposal.


The issue is how to have close sequence and terminate sequences replies using the acksTo epr.


Doug D asked that we do not constrain the use of acks to, but clarify how to work with anonymous Acks.


Jacques clarified that some RMS may only be able to use the back channel for all three operations, createSequence, CloseSequence, and TerminateSequence.


Anish: It is the RMS which sets the Reply to, which is initiated by the RMS.  If the RMS knows anonymous is the only way to get back, it can set the replyTo for these operations to Anonymous.


It was agreed to accept Jacques new issue as Issue 102.


0.1.2      Remove Partial Answer Mode.


Title: Remove the Partial Answer Mode (PAM)




When the RMS requests an acknowledgement, the RMD may either reply with a full sequence state, or a nack. It should be recommended that the RMD responds with the full state.




While getting a nack back (unprompted) is an efficient model for the RMD to point out "gaps" in the sequence, it does not give the RMS full information.

If the RMS is asking what "messages did you get?", it is a little annoying to say "well.... you know, I *didn't* get message 3".


RECOMMEND that the RMD replies with a "full" ack.


Target: core

Type: design




From CD-3.


At end of line 539 add:


It is RECOMMENDED that the RMD return a <wsrm:AcknowledgementRange> or <wsrm:None> element instead of a <wsrm:Nack> element (see below).


Related issues: None




Agreed to add Paul new proposed issue as I103.


0.1.3      Mixing of Soap and wsa versions


Title: Mixing SOAP and/or WS-A versions



You may end up with both SOAP 1.1 and SOAP 1.2 across a sequence. The same applies to WS-A versions.




Suppose the RMS starts a sequence in SOAP 1.2. The RMD may initiate messages (e.g. SequenceAcknowledgement). Those could be in SOAP 1.1.

Should we allow mixing SOAP types? Probably not. We could recommend that the SOAP style in place for the CS should used for the rest of the sequence.



Target: core

Type: design




From CD-3.


between lines 241-2 insert new para:


The SOAP and WS-Addressing versions used for the CreateSequence message SHOULD remain in place for all future interactions between the RMS and RMD, including

messages initiated by the RMD (e.g. <wsrm:SequenceAcknowledgement> and faults).


Related issues: None




Agreed to accept proposed issue as a new issue


0.1.4      Sequence Acks on all messages after close


Title: Sequence Acks on all messages after close




The current text is not clearly written. It says:

"Upon receipt of this message, or subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST

include a final SequenceAcknowledgement (that MUST include the <wsrm:Final> element) header block on each message destined to the RM Source, including the CloseSequenceResponse message and on any Sequence Fault transmitted to the RMS."




Obviously there may be messages (for example after the sequence has been terminated and the RMD no longer knows about this) that cannot include this element. The text needs tidying up.


Target: core

Type: editorial




> From CD-3.


At lines 373-377 replace the above text with:


"Upon receipt of this message, or subsequent to the RM Destination closing the Sequence of its own volition, the RM Destination MUST

include a final SequenceAcknowledgement (that MUST include the <wsrm:Final> element) header block on any messages *associated with the Sequence* destined to the RM Source, that including the CloseSequenceResponse message *or* on any Sequence Fault transmitted to the RMS."


The added/modified text is within * *.



Agreed to add as new issue.

4.2      Review of Open issues

Four issues in the issues list.


two deferred issues


Ø  Action: Anish will provide a proposal fo deferredr Issue 42, which version of ws addressing.


Ø  Action: Paul C will initiate discussion of deferred Issue 007.


5         Interop

5.1      Detailed review of Results from Interop

Doug D presented the initial results from the Interop:


There were 5 implementations at the interop.


Three implementations have completed full interop in all directions.


5.2      Raising of any new issues from Interop

Paul F sent a note: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00178.html

Note on behaviour from Interop

One of the scenarios for interop was a one-way, with an anonymous client.
In the scenario, a message may arrive out of order. The RMD is 
implementing inOrder delivery and is therefore not delivering this. 
Because there may be a fault response, it doesn't close the incoming 
At least one implementation was holding off sending any more messages until the block ended, and we ended up with a deadlock.
We aren't claiming this is an issue for our spec, but the interop team wished to inform the TC of this behaviour.


Paul F: this could be a robust one way (allowing fault).


Paul F: if the response channel for fault is not reliable, the loss of fault can occur with timeout.  This could be handled as application notes, rather than a spec issue.


No new issue was raised on this topic.

5.3      Planning for next (online-only) Interop

Paul F stated that an internet based interop could be done during the public review period for the spec.


Paul suggested a time period of 3 weeks for interop, with designated time during one week for people to be available for on-line chat or teleconference discussions.


Paul F asked if there are more than the initial 5 companies who may participate in next interop, near the end of May.


Sonic, BEA, ,NEC, and Sun stated they might participate in the next interop.


Paul F asked if we want the public to participate in an interop.


Jeff M: assuming we can get the non-members to do the feedback license first, to obey OASIS IPR rules, it could work.  We would need to do a public invite for interop.


Paul F: that should be added to our work list for what we have to do before going into public review.  I wanted to know if anyone disagreed with such a public invite.


No opposition was expressed for the public invite for interop.


6         Action Items

Action Item 56: agreed to close, since WS addressing PR specs allow use of Anonymous for non WS-addressing EPRs.


Action item 88: Chris F to send proposal for I021.  Still Open.

7         Wed PM Issues Discussion



7.1      issue i021/i008 discussion


Tom R pointed out that since reliable response for synchronous two way is difficult, we way want to reconsider having the attachment of rmAssertion on endpoint level imply reliability of all messages.


Chris F: I did not complete my action item to get a proposal on I021.


It was agreed to put this on the agenda in time for Chris to provide his proposal.


Paul F suggested to return to I021 for 4:00 PM.


Doug B: It may be useful for a short discussion of the problem space around Issue 21.


7.2      Issue 102 -

Peter Niblett asked if the proposal is do put any restrictions on what ws-addressing allows.


Paul F: I do not understand why the replyTo epr is not the place to send the response.


Jacques: If we require WS-addressing ReplyTo for determining the sequence management operation responses then this issue may go away.  WS-RM does have a way to control acks outside of the wsa: reply to epr.  I had originally though we could extend the concept of anonymous AcksTo for working with the responses to sequence management operations.


Paul F: I believe there should be a different mechanism for acks to and the responses to the sequence management issues.


Gill: the sequence management operations seem to work fine with wsa:replyTo.


Chris F: I think Jacques initial proposal breaks ws-addressing.  The Acks to should be able to be anonymous, while the sequence management operations use the wsa:replyTo.


Jacques Moved to close Issue 102 with no action.  Matt seconded.


§    No Objection issue 102 closed with no action.


7.3      Issue 103 – Remove Partial Answer Mode


Matt asked to change “recommended” to “should” in proposal.


At end of line 539 add:


It is RECOMMENDED that the RMD return a <wsrm:AcknowledgementRange> or <wsrm:None> element instead of a <wsrm:Nack> element (see below).


Paul C: I propose we  change “RECOMMENDED that RMD return” to “RMD SHOULD return”

The RMD SHOULD return a <wsrm:AcknowledgementRange> or <wsrm:None> element instead of a <wsrm:Nack> element (see below).


Doug B: I recommend we help interop by sating “RMD MUST return” for this case.


The RMD MUST return a <wsrm:AcknowledgementRange> or <wsrm:None> element instead of a <wsrm:Nack> element (see below).


Chris F: Nack may work in some cases.


Doug D: nacks only work for a non acked messages.


Anish: I do not understand how this is an interop problem.


Chris F: the purpose of NACK was to allow optimistic usage of the protocol.  You do not have to go to trouble of acking messages all the time.  The spec should clarify you should not NACK unless you have received all the messages before the one NACKed.


Gil: I support Doug B proposal, to always use ACK range rather than NACK in this case.  I do not see the use of NACK for this use case.  If the RMS asked for the ack state, it should receive the entire ack state.


Bob F: the current text only weakly states that the NACK implies all the earlier messages were received.  We should make this very clear in the spec.  The proposal on the table for discussion, removes the effectiveness of NACK as a feature.  We could allow NACK in this case if its semantics were clarified.


Paul F: this scenario is only for when there is an explicit ack requested from RMS.  The use of NACK for other scenarios is not affected.


Anish: the reason an RMS will send ack requested may be to clean its buffers.  But there are other cases where it needs to know what to resend.  Getting a NACK may allow the rms to resend particular messages.  


Sanjay: the words MUST may be burdensome in some cases.


Tom R: If the ack contains all the messages which were received, the RMS knows which that it sent were not received.  I do not see the value in having the RMD decide which non received message should be send first by the RMS.


Anish: Power of Nack is when there are many gaps in the sequence of received message Numbers..  It allows the RMD to select which message should be send.


Marc G: the ackRanges can have gaps, all the information is there in the ack range.  Sending the ack ranges gives more elements.


Paul F: This scenario, with an explicit ackRequested being sent, is not the same as the case for NACK for bandwidth reduction.  The RMS has requested acks, which is different than the optimistic case for use of NACK.


Chris F: the purpose of NACK if for an optimistic use of messages to trigger retransmission of lost messages.  We could fix this by requiring the NACK to include all the messages which were not received.


Bob F: we need to clarify that NACK implies all prior messages were received.  After that clarification we need to separately discuss the scenario raised here by Paul F.  Some RMS may only want to send ackRequested at the time of Closing the sequence.  I think the clarification is enough, we do not need the new text proposed by this issue.


Paul C: It is frustrating that people are not pointing to the text which needs to be changed in the actual text.  It seems we could benefit by having examples in this document to help understand the use of NACK and ack Requested.


Doub B: I see this as the RMS asking a question, and getting the answer to the question which was asked.  The NACK does not seem to Provide the answer to the question asked with an AckRequested operation.


Paul F: is the proposal that NACK should indicate every gap which exists in the received sequence.  If this is so, the NACK can be more verbose in this scenario, for some cases with a lot of wide ranging gaps.  Forcing a NACK to include every message known to be missing takes away the need for the NACK.


Jacques: at some point in the past we talked about limiting the memory of the ack range.


Anish: we do not want to require NACK to indicate every gap.  It might be useful for indicating the lowest gap.


Matt: a NACK is useful in the optimistic case.  However, we could have clarification that in response to ack requested you give the complete set of ack ranges.  This is not the optimistic case.


Chris F: if you are in the optimistic case where NACKs work, then you will not have a lot of gaps, so the ACK response will not be that large.  I do not support getting rid of NACK altogether. 


Paul F: I was saying that if NACK requires all gaps, then it could be eliminated from the protocol.


Bob F moved to accept the proposal with the MUST,  The RMD MUST return a <wsrm:AcknowledgementRange> or <wsrm:None> element instead of a <wsrm:Nack> element (see below).“  and in addition to clarify in line 625 to indicate that a NACK explicitly acks all messages preceeding the lowest numbered NACK.  Seconded by Tom Rutt.


Paul C: if this change was there, how would it affect the interop scenario.


Paul F: this would have solved the problem in the interop scenario.


Chris F: I suggest the following text for line 625 clarification “When sending a Nack, there MUST NOT be any gaps with lower valued MessageNumber than the lowest message number in the NACK.”


Anish: what is the problem with the current semantics of NACK.


Bob F: I want to clarify the text.  It currenly implies this as an ability.  My suggestion is to crispen this text.


Anish: Bob’s clarification does not allow a gap analysis by RMS.


Doug D: it allows the RMD to do gap analysis.


Anish: only RMS can do gap analysis.


Gil: There are two haves to the motion.  One is the response to ack requested, the other is to clarify NACKs.  It does not seem that


Gill moved to divide the motion, seconded by Peter Niblet.


§    No objection to divide the motion.



Motion 1:  Add text at end of period on line 537:: “The RMD MUST return a <wsrm:AcknowledgementRange> or a <wsrm:None> element instead of a <wsrm:Nack> element (see below).“


Jacques moved to amend Motion 1, seconded by Paul F, to the following:  Add text at end of period on line 537:: “The RMD MUST return a complete set of <wsrm:AcknowledgementRange> elements or a <wsrm:None> element (see below).“


§    Motion to amend Motion 1 accepted unan.


§    No object to approval of amended Motion 1.


Motion 2: Add clarification text after line 625 “When sending a Nack, there MUST NOT be any gaps with lower valued MessageNumber than the lowest message number in the NACK.”


Bob F  moved to amend motion 2 to adding a new issue to clarify semantics of NACK, seconded by Tom R.


§    Agreed to amended motion 2.


§    Motion 2 resolved by adding new issue.


Ø  Action: Bob F will propose new issue to clarify that a NACK explicitly acks all messages preceeding the lowest message number in the NACK


7.4      Issue I021/ i008 resumed

Chris F proposed his consolidated proposal to close action item 88:


Replace the entire content of section 2.3 (Assertion Attachment) in the WS-RM Policy specification with the following:


The RM policy assertion is allowed to have the following Policy Subjects [WS-PolicyAttachment]:


    * Endpoint Policy Subject

    * Message Policy Subject


WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL 1.1] policy attachment points for each of the above Policy Subjects. Since an RM policy assertion specifies a concrete behavior, it MUST NOT be attached to the abstract WSDL policy attachment points.


The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion but which MUST NOT have RM policy assertions attached:


    * wsdl:message

    * wsdl:portType/wsdl:operation/wsdl:input

    * wsdl:portType/wsdl:operation/wsdl:output

    * wsdl:portType/wsdl:operation/wsdl:fault

    * wsdl:portType


The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion and which MAY have RM policy assertions attached:


    * wsdl:port

    * wsdl:binding

    * wsdl:binding/wsdl:operation/wsdl:input

    * wsdl:binding/wsdl:operation/wsdl:output

    * wsdl:binding/wsdl:operation/wsdl:fault


If the RM policy assertion appears in a policy expression attached to a wsdl:binding as well as to the individual wsdl:binding level message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:operation/wsdl:fault), the parameters in the former MUST be used and the latter ignored.


If the RM policy assertion appears in a policy expression attached to a wsdl:port as well as to the other allowed WSDL/1.1 elements, the parameters in the former MUST be used and the latter ignored.


If an RM policy assertion is attached to any of:


    * wsdl:binding/wsdl:operation/wsdl:input

    * wsdl:binding/wsdl:operation/wsdl:output

    * wsdl:binding/wsdl:operation/wsdl:fault


then an RM policy assertion, specifying wsp:Optional=true MUST be attached to the corresponding wsdl:binding or wsdl:port, indicating that the endpoint supports WS-RM. Any messages, regardless of whether they have an attached Message Policy Subject RM policy assertion, MAY be sent to that endpoint using WS-RM. Additionally, the receiving endpoint MUST NOT reject any message belonging to a Sequence, simply because there was no Message Policy Subject RM policy assertion attached to that message.


There might be certain RM implementations that are incapable of applying RM QoS semantics on a per-message basis. In order

to ensure the broadest interoperability, when an endpoint decorates its WSDL with RM policy assertions using Message Policy Subject,

it must also be prepared to accept that all messages sent to that endpoint might be sent within the context of an RM Sequence, regardless

of whether the corresponding wsdl:input, wsdl:output or wsdl:fault had an attached RM policy assertion.


Rather than turn away messages that were unnecessarily sent with RM semantics, the receiving endpoint described by the WSDL

must accept these messages.


By attaching an RM policy assertion that specifies wsp:Optional="true" to the corresponding endpoint that has attached RM policy

assertions at the Message Policy Subject level, the endpoint is describing the above constraint in policy.


Tom:  When Chris gave his overview he stated that the “server” RMS which wants to crdate a “return” sequence on the client, and the client does not have an RMD, that client can reject the reverse create sequence request.  However the text in the proposal above does not state this.


Anish: It is problematic to have the sender of the message decide to use rm for the output and fault messages.   It is ok for the input message.


Paul F: I had put something like that in an earlier proposal.  However some TC members stated that this came for free with the ws policy definition of optional.


Anish: WSP optional does not distinguish between input and output messages.  This is my biggest problem with the details of this proposal.  A Client should not be required to support an RMD.


Anish: a WS-RM implementation does not have to support wsdl.  If they do not support wsdl, none of this applies.


Anish: you can have multiple ports with same URL.  WSA Action could be used to make decisions on dispatch.


Doug B: First, in general we are taking what today is just starting this whole policy framework and postulating complicated scenarios before getting the basics correct.  Chris F proposal is more complicated than most implementations will be for a year of two.  Making things more complicated makes me nervous.


Doug B: Second: the text proposed by Chris F is ambiguous.  The text is not restricted to the unconditional assertion at higher level not having restrictions at the lower level. Look at first paragraph after the list of subjects which may have rm policy assertions attached.  You want to say “if you have one without rm optional = true”.


Chris F: the text applies to the parameters, not the assertion itself.  It says take the parameters from the higher level one.


Doug: I accept Chris F statement. My second concern is covered by the fact that the word parameter is almost equivalent to an unconditional assertion.


Paul F: one can split the service into two, one for each level of reliability.


Anish: this can work in some cases, but it will not work if you do not have an option to split previously defined service endpoint.


Paul F: I agree we need to make clear that there is a different requirement for an input messages than for an output messages.


Anish: that would resolve my biggest concern.


Umit: Regardless of granularity on message or binding level, the client and server’s capabilities together determine what is engaged. 


Anish: I agree with respect to input.  But when we talk about output message, we need to clarify what wsrm optional means.


Umit: if one of the output messages is marked optional, then that means the client must support that message it if can engage RM as a receiver.  Putting assertion on output may mean it is required on return or optional on return.  If RM is required on output message, policy semantics mean the output message should be sent reliability and the client must accept the reliable return.


Discussion ensued on the differences for input and output messages.


Paul F: I hear from this discussion that we need to have some clarification of Chris Proposed text for the output message.


Chris F: I think there is a choice to be made about whether a client chooses to implement an RMD to receive return messages reliably.  If a service does not understand policy in the wsdl it may be unsatisfied.  WSDL describes the service, and it says nothing about the client.  So I do not see how an assertion on a server endp


Tom R: I am concerned with the text “ Additionally, the receiving endpoint MUST NOT reject any message belonging to a Sequence, simply because there was no Message Policy Subject RM policy assertion attached to that message”. This text is ok for input messages, but for output messages itt does not express the ability of the client to not accept the return sequence from the server if it does not have an RMD implemented.


Chris F: The text is qualified as “messages sent on the sequence”.  If there is not accepted sequence, that message could not be sent.  I think the concern of Tom is covered by the details of this text.


Tom R: I think a clarification that in the optional=true case the client can reject a sequence being created in the reverse direction, is warranted.


Paul F: I suggest adding text: "In the case where an optional RM Assertion is attached to an output message, and the server cannot create a sequence with the client, the server SHOULD continue to send responses unreliably"


Anish: I assume this word attachment meant to imply both direct and inherited attachment.


Paul F:  Yes.


Gil: if an RMS is capable of message level decoration, it can get resource savings.  This compromise seems to take away the resource savings, if the server has to receive any message in the to the RMD side reliably.


Paul F: It removes my ability to enforce, but not to request the capabilities.


Gil: my second point is that there seems to be a fundamental asymmetry, if it optional Client can chose to do or not for the input, but if it wants it it will get it from the server.  However the requirements are different for the output messages, since the client may reject a sequence creation in the output direction.


Anish: it might be better to have different policy markers for input and output.


Paul: straw poll to accept Chris F proposal with a clarification vs a new proposal on having different inbound and outbound markers.


In favor of amended Chris F proposal (with an amendment such as proposed by Paul F).:

19 members


In favor of new proposal with separate markers for inbound and outbound.

4 members.


Paul F: it seems clear what the TC wants.


Jacques: what about taking the WSDL as an announcement of what capabilities are present.  Any behaviour is subject to a separate agreement, which may be out of scope.


Paul F: are you suggesting the policy is non normative?


Jacques: If not every RMS must be capable of understanding WSDL, there must already be a way for reaching agreement on usage or RM outside of wsdl.


Paul C: Is Jacques stating that if the endpoints are not using wsdl, there already has to be an out of band agreement.  


Jacques: I see more problems with tying the behaviour to the wsdl if the wsdl understanding is optional.


Ashok: Some of us want to use policy.  However we are assuming that we cannot ask the client for their policy.  We have no DA assertion capabilities in our protocol.


Chris F: We should try to avoid gilding a lily that we have barely just planted.  I would assert that if you are going to send it reliably, you might just send all messages with the same level of reliability.


Gil: but the main problem is asserting input only, output only, or input/output.


Chris F: I move to accept my proposal as amended by Paul F.  Marc G seconded.


Paul F: amendment:

"In the case where an optional RM Assertion is attached to an output message, and the server cannot create a sequence with the client, the server SHOULD continue to send responses unreliably"




Doug B: s/the server cannot create a sequence with the client/a corresponding (offerred) sequence does not yet exist and the server cannot create a sequence with the client/


Combined amendment:

In the case where an optional RM Assertion is attached to an output message, and a corresponding (offered) sequence does not yet exist and the server cannot create a sequence with the client, the server SHOULD continue to send responses unreliably


Anish: we need to amend further to include direct attachment or higher level attachment to the endpoint.

In the case where an optional RM Assertion applies to an output message, there is no requirement on the client to support an RMD implementation.


Anish moved to accept this amendment to Chris F email proposal, Chris F seconded. Add text: “In the case where an optional RM Assertion applies to an output message, there is no requirement on the client to support an RMD implementation.“


§    No objection to amendment proposed by Anish.


§    No objection to amended motion proposed to close Issue 21.


Tom R: on Issue 008 , since the resolution to Issue 21 has attachment at a level less than endpoint, we can close issue 008 without change to the document.


Tom R moved to close issue 8 with no action, Chris F seconded.


§    No objection, Issue 008 closed without action.

7.5      Issue 007

Paul C posted a proposal at: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00187.html

I think the following proposal is the minimum required to close this issue.


1. Change the reference only


Add the following as a second alternative after line 908:


Anthony Nadalin, Chris Kaler, Phillip Hallam-Baker, Ronald Monzillo, eds. "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", OASIS Standard 200602, February 2006.




Chris F moved to accept Paul C proposal to close issue 007, seconded by Gil.

Peter N: can the spec have hyperlinks which are active?


Paul C: if so the active link should have the same value as the visible text.


Agreed to let editors work on this.


§    No objection to close issue 007 with Paul C proposal.

Meeting recessed at 5:30.


Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]