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
Motion
§
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
Weds
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
13:45-15:00
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.
Thursday
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
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17132/MinutesWSRX-030906.html
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/17304/MinutesWSRX-031606.html
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;
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00165.html
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
--------------------------------------------------------------------------------
Description
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.
Justification
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
Proposal:
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. ]
add:
"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.
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00169.html
Title: Remove the Partial Answer
Mode (PAM)
Description:
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.
Justification:
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
Proposal:
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
Paul
Agreed to add Paul new proposed issue as
I103.
0.1.3
Mixing of Soap and wsa
versions
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00174.html
Title: Mixing SOAP and/or WS-A
versions
Description:
You may end up with both SOAP 1.1
and SOAP 1.2 across a sequence. The same applies to WS-A versions.
Justification:
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
Proposal:
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
Paul
Agreed to accept proposed issue as a new issue
0.1.4
Sequence Acks on all
messages after close
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00179.html
Title: Sequence Acks
on all messages after close
Description:
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."
Justification:
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
Proposal:
> 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 *
*.
Paul
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:
http://wsi.alphaworks.ibm.com/interop/RXInteropStatus.jsp
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
connection.
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
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:
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200603/msg00188.html
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"
Sanjay:
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.
/paulc
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.