[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of 2/23 Teleconf
Prelim minutes of 2/23 teleconf attached. Please propose changes before next monday. Tom Rutt secretary -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes WSRX TC Teleconf
Prelim Minutes OASIS TC Teleconf Thursday February 23, 2006 4:00 to 5:30 EST Textual Conventions Ř Action Item Motion § Resolution 1 Roll CallFrom Kavi. Meeting was quorate. 2 Review and approval of the agenda1) Roll Call 2) Review and approval of the
agenda 3) Approval of the Feb 09 and 16,
2006 meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16663/MinutesWSRX-020906.htm http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16877/minutes%20wsrx%2016%20feb.doc 4) Administrative Issues Editors review, WD / CD status Availability of the submission spec
on the public page 5) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 6) New issues since last conf-call http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00234.html 7) Issue Discussion: a> i021 An RM Policy applies
two-way http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021 b> i008 Policy assertions
granularity http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i008 c> i090 Use of offered sequences
unclear in current spec http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i090 d> i089 suggest the restricted
use of anonymous URI http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089 e> i061 Anonymous AcksTo http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i061 to moving
issue 61 to the top of the list. 8) Any other business Marc G asked that issue 61 be moved up to the top of the list. No objections Chris F asked that the Namespace be posted . 3
Approval of the Feb 09 and 16, 2006 meeting
minutes
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16663/MinutesWSRX-020906.htm
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16877/minutes%20wsrx%2016%20feb.doc Tom Rutt moved to accept both minutes Paul K seconded. No objections, both minutes approved. 4
Administrative Issues
4.1 Editors review, WD / CD statusGil stated that document are not posted by OASIS staff. The RIDL document is getting closer to being posted properly. Gil stated this would be fixed before the next meeting. Paul F: The aim is to have a vote on the call next week. The editors should post a candidate CD. Sanjay: perhaps a ballot could save time, if we opened a ballot today, to close before next weeks call. Martin: how long has this doc been available. Doug D: Monday or Tuesday of this week. Paul C: they were not accessible to all on wed. Anish: Did you mean a newer draft, I already sent it out as candidate CD. Martin: I think it is ok to ballot. Paul F: I suggest we have a 6 day ballot for approval of the Candididate drafts for CD 03. It will be issued to have it close before the next teleconference meeting. Anish: what about editorial comments on the candidtate? Paul C: I will continue my review, and identify anything that should go into CD, and especially if it impacts the interop. I think only deal-breakers be included. Doug D: I t is easier to have the ballot be up/down. Paul F: agree to have up/down ballot. Anish: The editor’s points should be considered during review for the Kavi ballot. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00163.html 4.2
Availability of the submission spec on the
public page
Editors shall organize this. Action: Doug will make the submissions available from public links. 4.3 Metadata from OASISChris F stated that he is reviewing the ASIS document from OASIS. The one thing that is relevant to this TC, is that the specific URI space …./ws-rx violates ASIS because token for tc short name do not allow hyphens. Since we are already using the space with hyphen, someone in this group should petition to allow continued use of the namespace with a hyphen. Jeff M moved, Marc G seconded that the committee ask Paul F to petition OASIS staff on the continued use of hypen in namespace. § No objections, motion passed unanamously. Ř Action: Paul F will petition OASIS staff to allow our continued use of hyphens in namespaces and file names. Note from WS-TX group http://www.oasis-open.org/apps/org/workgroup/oasis-member-discuss/email/archives/200602/msg00003.html Rant from Chris F: http://www.oasis-open.org/apps/org/workgroup/oasis-member-discuss/email/archives/200602/msg00001.html Paul F Members should vote on attendance to face to face. 5
AI Review
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
#0056: Ensure that the final WSA specifications include text
for handling of anonymous IRI values for non-WSA EPRs Owner: Robert Freund Status: Open Assigned: 2005-12-13 Due: --- #0080: Gill will work with OASIS staff to get the CD 2
artifacts posted properly Owner: Gilbert Pilz Status: Close Assigned: 2006-02-14 Due: --- 1
New issues since last conf-call
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00234.html 1.1
Proposed-01
Title: wsrm:acksTo
should not use wsa:AnonymousURK Description: The wsa:anonymousURI
is defiined in WS addressing for use in a single MEP
exchange. What we really need in wsrm:acksTo is a uri which has
the intended semantics: "return the wsrm:acknolwedgment soap header in the underlying response
to any soap request which contains a wsrm defined
soap header with this sequenceID." This is really quite specialized semantics, and should be
defined with a wsrm: specific URI. Proposal: Define a wsrm specific URI which
has the desired semantics for use in the wsrm:acksTo URI. Tom gave an overview of this new issue. Chris F: I have been talking to WS-addressing members will make this not be a problem. I would not like this to be raised as a new issue. Umit: I agree with Chris that this should be resolved in WS-addressing First. Tom: what is so important about using anonymous here. Doug D: why is this not part of Issue 61. Sanjay: I believe our spec depends on ws-addressing and we are trying to deal within WSA. We should try to work with wsa first. Anish: I was influenced by Glen D who pointed out that if wsa resolves anonymous to mean any back channel, causes problems. We have semantics of matching sequenceIDs before using the back channel. Gil: I remark that there is really an issue here, and we should accept the issue. Paul F: I think we need to ignore the proposal, there is an open issue that wsa meaning of anonymous uri and the meaning of anonymous.we want will be aligned. Doug D: I want to request the chairs that we raised the bar quite high last week. Paul F: the Bar is decided by the TC and not the chairs. I think the bar should be low. Bob F: speaking as ws addressing chair, we are working to get back to where we were when the clarification was originally requested. We are accepting proposals thru next Thursday morning. Hopefully we can accommodated the needs of this TC Tom R: I am just suggesting we can decouple our TC from the WSA discussions by having our own URI with its own special semantics. This is not much different than specifying special semantics to the use of anonymous in Ack To.. Chris F objected to raise as new issue. Put to a Vote: 7 Yes 10 no Many abstain Proposed 01 not accepted as New Issue. 2 Issue Discussion:2.1
e> i061 Anonymous AcksTo
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i061
New proposal from Chris F: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00245.html Doug D reviewed proposal: Doug D moved to accept email proposal to close I061 , seconded by Chris F: Gil wordsmithing is needed for one of the sentences. Doug D: the editors can break up the sentence. Marc G: have the editors propose a better solution and if there is no objection, we can accept the editor’s wording. Sanjay: I am not comfortable with a motion pass without agreement on the text. I am willing to let the editors have leeway to fix the cumbersome sentence, by breaking it into several sentences. Marc G: we should accept that the editors might not be able to break the sentence apart. Paul F: we are voting to accept the text in the proposal as is. Chris F moved to amend, Anish Seconded. A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. 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 provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier. To : A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. 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. Such a channel is provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier. § No objection of motion to amend. §
Amended motion had no objections. Issue 61 closed with amended proposal. 2.2
a> i021 An RM Policy applies two-way
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021 Sanjay posted latest proposal as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00222.html Title: i021 Proposal Here is an updated proposal for
resolving the long pending issue i021. The key difference in comparison to what
exists in the WS-RM Policy specification today is that -- the proposal allows
Message Policy Subject (in addition to the Endpoint Policy Subject) for the RM
Policy assertion. I would also like to bring to your
notice that this proposal: -- Avoids text that would repeat
the semantics already addressed in WS-PolicyAttachment,
for example, an Endpoint Policy Subject applies to behaviors associated with
all the message exchanges of the endpoint, and applies to aspects of both
communicating with as well as instantiating the endpoint. So the proposal would
seem a bit short and dry to some people! -- Does not include any recommendations
for which wsdl elements (among those that are allowed
by the proposal - wsdl:port Vs. wsdl:binding
Vs.binding level messages) are more appropriate for
policy attachment, since this may simply be a matter of best practices and
there are no strong technical reasons for the specification to promote one
approach over another, IMO. -- Does not include any text
related to whether and how EPR contained policies may interact with the WSDL
attached policies, since I couldn't arrive at any precise and useful
(normative) text in this regard. Please try to send in your comments
before the conf-call tomorrow (2/23)! -- Sanjay ------------------------------------------------------------------------ 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. Sanjay gave an overview of his proposal above. The proposal does not talk about EPRs, and it makes no suggestions as to preferred levels of policy attachment. Anish: I like this proposal, but posted a few comments. We no longer have parameters which can conflict, we just have a binary switch. Sanjay: I included this for extensibility, but perhaps the extensions can provide their own overrides. Chris F posted counterproposal as: http://lists.oasis-open.org/archives/ws-rx/200602/msg00225.html Thinking about this proposal, I am
concerned that what is not clear is what is the expected
behavior should the
policy be expressed as Message Policy Subject (MPS) for selected input and/or output|fault messages and then
either side goes a step further and sends messages that have NOT been
designated as reliable. Specifically, I am concerned that
there might be two flavors of RM implementation: one that only supports EPS and one that
supports MPS granularity. It would be a problem IMO if these two flavors
of RM implementation did not
interoperate. I am thinking that what may be
needed is two assertions: one for the endpoint (EPS)
that effectively proclaims that
"this endpoint supports WS-RM", period. A second assertion with MPS
could then be used to decorate the WSDL
to indicate which messages SHOULD be sent reliably, but would NOT preclude that
other messages be sent
reliably. Alternately, there would likely
need to be some statement made to the effect that if ONLY MPS is specified,
then there is
an implicit claim that the assertion ALSO applies to EPS to indicate "RM
supported". However, I am not clear as to whether Policy effectively supports this
notion of transitive policy subject UP the food-chain. I think that unless we have such a notion
of two-levels of policy subject as applied to RM assertions,
that there will be potential interoperability issues. For instance, what if a
message that was NOT designated as being reliable were sent reliably? If the RMD implementation were to reject
this message, then the Sequence is effectively broken
because the MessageNumber has been used but will
never be acknowledged. I'm not suggesting that this is the
behavior that one would expect, just that given what it states in the proposal below, it
isn't clear what responsibility the RMS and RMD have. Thus, I am thinking that we really
need two assertions, one with EPS and the other with MPS to get this right, and
to ensure interoperability. The semantic of the one with EPS is
"WS-RM Supported|Required" and MAY be
attached to either a wsdl:binding or wsdl:port and
MUST NOT be attached to any other WSDL component. The semantic of the one with MPS is
"SHOULD be sent reliably". It MAY be attached to any of: wsdl:binding/wsdl:operation/wsdl:input wsdl:binding/wsdl:operation/wsdl:output wsdl:binding/wsdl:operation/wsdl:fault It MUST NOT be attached to any
other WSDL component. When used in the context of an endpoint
that proclaims "WS-RM Required" (e.g. <wsrmp:RMAssertion
wsp:Optional="false"/>) then the
designated message(s) MUST be sent as part of an RM Sequence, otherwise, the
receiving endpoint
SHOULD generate a fault (TBD with semantics of "RM REQUIRED"). When
used in the
context of an endpoint that proclaims "WS-RM Supported" (e.g. <wsrmp:RMAssertion wsp:Optional="true"/>)
then the
sending endpoint MAY send the designated messages as part of an RM Sequence. The receiving endpoint MUST NOT
generate a "RM REQUIRED" fault. The receiving endpoint SHOULD (MUST?) permit messages that
have not been designated "SHOULD be sent reliably" to be included
in an RM Sequence. Finally, there is the issue of the
scope of the EPS assertion. Does it apply only to messages sent to the
service provider endpoint, or does it apply to messages sent in either
direction? One use case that needs to be
covered is that for pub/sub, where the subscriber endpoint is the one that would
want to assert that the messages be delivered reliably (or not as the case may
be), but where
the service provider (the publisher) could go either way (RM supported). Doug had a proposal that provided
for the wsa:ReplyTo EPR to
carry in its metadata, a policy assertion
that indicated whether RM was supported/required, much as the service provider
can do by
decorating its WSDL description. The question then becomes, how does
one express this if it is to deal with MPS as opposed to simply
EPS? WS-PolicyAttachments has defined a domain
expression for EPR which we could use, but
that would only give us EPS. We could invent some domain
expression for WSDL and use that for an external policy attachment using PolicyAttachment. I am not comfortable having the WS-RX TC
do a domain expression for WSDL though, and we'd have to do
more than one flavor anyway (sigh). Quite frankly, I am not at all
confident that the proposal below really addresses all of the issues. I personally think that we would be
best off for NOW going with JUST EPS scope for the assertion
and having the RM assertion mean: <wsrmp:RMAssertion wsp:Optional="true"/>
== WS-RM supported. The sending endpoint MAY choose to use a Sequence to send
any (or all) of the messages sent to the endpoint as described in the WSDL. <wsrmp:RMAssertion wsp:Optional="false"/>
== WS-RM required. The sending endpoint MUST use a Sequence for all messages sent to
that endpoint as described in the WSDL. When the policy assertion is
attached to a WSDL port/endpoint or binding, it applies to messages sent from
the service consumer to the service provider. When attached to an EPR, it means
any (or all) messages sent to the referenced endpoint be sent using RM. Cheers, Christopher Ferris Chris F: my concerns are that implementations might not support message subject level, and the interoperability problems this may cause. There is nothing about endpoints rejecting messages. This led me to propose two levels. At endpoint level you want to say rm support is here, and at message policy subject level you would have a switch which is “and”ed with the endpoint assertion. Chris F: I think there are pub sub use cases that different users support different levels of reliability. Restricted proposal involves receiving endpoint asserting its use of Reliability. Paul F suggested the discussion be taken to the list. Chris will try to write a concrete proposal Continue to discuss on email. 3 Any other businessDoug D: We need to have answers to the questions raised by Microsoft, as I posted in http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00193.html Action: Marc G will give answers to questions raised about anon reply to |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]