RE: [ws-rx] i021 proposal (updated)

[Christopher B Ferris <chrisfer@us.ibm.com>]

Umit,

Apologies if the dripping sarcasm didn't
come through... maybe I need a sarcasm alert emoticon:-)

I was making a point that it seemed
a little unfair that for some proposals, we are not allowing the
editors to change a comma and for this
rather contentious issue, we would not have a formal
line-numbered set of proposed changes
and leave it to the editor's discretion?

Please do not take offense. I was only
making a case for consistency of process.

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
phone: +1 508 377 9295

"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
wrote on 02/16/2006 04:21:12 PM:

> Chris, 
>  
> As one of the editors in this tc, I am not sure
how to interpret 
> your comment and take it with sarcasm or literally...
>  
> --umit
>  
> 
> From: Christopher B Ferris [mailto:chrisfer@us.ibm.com] 
> Sent: Thursday, Feb 16, 2006 12:52 PM
> To: Patil, Sanjay
> Cc: Marc Goodner; Paul Fremantle; wsrx
> Subject: RE: [ws-rx] i021 proposal (updated)

> 
> Given the amount of email traffic on this issue over the course of
> the last week, I am not at all convinced 
> that we are close to resolving this. 
> 
> Also, to be honest, I have not been able to catch up completely on
> my email due to travel 
> and an inability to get email connectivity for 1 1/2 days. I would
> actually prefer that we not spend 
> an entire call discussing/arguing something that I do not yet 
> believe has general consensus 
> agreement as to even the high-level concepts of according message
> policy subject. 
> 
> Also, given that the editor monkeys are not to be trusted even with
> making grammatical changes, 
> I am also not comfortable in just making hand-wavy voice changes to
> be addressed by the 
> editors, especially given that on other issues where there was even
> less contention in the 
> discourse, there has been significant pushback to get a formal, 
> line-numbered set of changes 
> expressed in email for the TC to review before-hand. 
> 
> I don't understand why this issue would be accorded special 
> treatment, especially given the 
> fact that there remains (IMO) some significant disagreement amongst
> the TC members. 
> 
> Cheers, 
> 
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295 
> 
> "Patil, Sanjay" <sanjay.patil@sap.com> wrote on 02/16/2006
03:18:34 PM:
> 
> > 
> > The proposal has been out for review for about a week now (Paul
posted
> > it on Feb 9th). The issue itself has been open for about 8 months
now :)
> > 
> > My proposed changes are something that I believe we can discuss
on the
> > call without requiring a line-numbered proposal.
> > 
> > I really suggest that we utilize today's call to discuss and
resolve
> > this issue.  Marc, we can walk through the proposal again
if that may
> > help you in understanding it better.
> > 
> > -- Sanjay
> > 
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> > > Sent: Thursday, Feb 16, 2006 11:52 AM
> > > To: Patil, Sanjay; Paul Fremantle
> > > Cc: wsrx
> > > Subject: RE: [ws-rx] i021 proposal (updated)
> > > 
> > > I'm sorry, I might be able to agree to this proposal but
I need more
> > > time to review this, particularly as you seem to suggest
yourself that
> > > there are changes you want to apply to this proposal. There
> > > was a lot of
> > > discussion on this issue this week and I expect there will
be more on
> > > today's call. 
> > > 
> > > I simply can't digest that much information to make a call
one way or
> > > the other yet. I think this is an important issue and would
> > > prefer that
> > > we take the proper amount of time to close it properly.
If forced I'm
> > > afraid I would have to vote against adopting anything on
this today
> > > rather than making the wrong call or accepting something
that is
> > > incomplete.
> > > 
> > > All of that said; I'm not opposed to what I'm seeing here.
I just need
> > > more time to review it.
> > > 
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/ 
> > > 
> > > 
> > > -----Original Message-----
> > > From: Patil, Sanjay [mailto:sanjay.patil@sap.com] 
> > > Sent: Wednesday, February 15, 2006 7:01 PM
> > > To: Marc Goodner; Paul Fremantle
> > > Cc: wsrx
> > > Subject: RE: [ws-rx] i021 proposal (updated)
> > > 
> > > 
> > > I am fine with Paul's suggested way of addressing my concerns.
I think
> > > this proposal should be on the table as a candidate for
resolving i021
> > > on tomorrow's call. I am taking the liberty (due to time
zone 
> > > difference
> > > with PaulF) to update the proposal as per his response just
to
> > > facilitate easier deliberation by the TC members ...
> > > 
> > > I would also propose to -- a> define rules for handling
the case where
> > > RM policy assertions are attached to multiple subjects in
the 
> > > same WSDL,
> > > and b> clarify (or even remove) the last paragraph related
to how EPR
> > > contained RM assertions interact with WSDL attached RM assertions.
I
> > > wouldn't ask for another round of proposal for resolving
> > > these aspects,
> > > and would rather let our able team of editors apply the
necessary
> > > changes (assuming the TC blesses the proposal and agrees
on the
> > > updates!) ...
> > > 
> > > -- Sanjay
> > > 
> > > --------------------------------------------------------------------
> > > Based on CDII
> > > 
> > > Delete 142-154 section 2.3 and replace with.
> > > 
> > > 2.3 Assertion Attachment
> > > 
> > > The RM assertion can have Service, Endpoint, Operation or
Message 
> > > Endpoint Policy Subjects [WS-PolicyAttachment].
> > > 
> > > WS-PolicyAttachment [WS-PolicyAttachment] defines both abstract
and 
> > > concrete attachment points in WSDL [WSDL1.1]. Because the
RM policy 
> > > assertion specifies a concrete behaviour, it MUST NOT be
attached to 
> > > abstract constructs:
> > > 
> > >     * wsdl:portType
> > >     * wsdl:portType/wsdl:operation
> > >     * wsdl:portType/wsdl:operation/wsdl:input
> > >       * wsdl:portType/wsdl:operation/wsdl:output
> > >       * wsdl:portType/wsdl:operation/wsdl:fault
> > >     * wsdl:message
> > > 
> > > The RM policy assertion MAY be attached to the following
constructs
> > > * wsdl:service
> > > * wsdl:port
> > > * wsdl:binding.
> > > * wsdl:binding/wsdl:operation
> > > * wsdl:binding/wsdl:operation/wsdl:input
> > > * wsdl:binding/wsdl:operation/wsdl:output
> > > * wsdl:binding/wsdl:operation/wsdl:fault
> > > 
> > > If the RM assertion is attached to the wsdl:service 
> > > construct, it MUST 
> > > be considered to apply to all the wsdl:port's referenced
in 
> > > the binding.
> > > If the RM assertion is attached to the wsdl:port construct,
> > > it MUST be 
> > > considered to apply to all the wsdl:binding's referenced
in the port.
> > > If the RM assertion is attached to the wsdl:binding 
> > > construct, it MUST 
> > > be considered to apply to all the wsdl:operation's referenced
in the 
> > > binding.
> > > If the RM assertion is attached to the wsdl:operation 
> > > construct, it MUST
> > > 
> > > be considered to apply to all the wsdl:input's, wsdl:output's
and 
> > > wsdl:fault's referenced in the operation.
> > > 
> > > Attaching the RM assertion to a specific wsdl:input, wsdl:output,
or 
> > > wsdl:fault construct indicates that the RM protocol MUST
be used when 
> > > sending that message (or MAY if the assertion is marked
optional).
> > > Attaching the RM assertion to a specific wsdl:operation
construct 
> > > indicates that the RM protocol MUST be used for all messages
(whether 
> > > input, output or fault) related to the operation(or MAY
if 
> > > the assertion
> > > 
> > > is marked optional).
> > > Attaching the RM assertion to a specific wsdl:binding  construct
> > > indicates that the RM protocol MUST be used for all messages
(whether 
> > > input, output or fault) related to the binding (or MAY if
the 
> > > assertion 
> > > is marked optional).
> > > Attaching the RM assertion to a specific wsdl:port construct
> > > indicates 
> > > that the RM protocol MUST be used for all messages (whether
input, 
> > > output or fault) related to the port (or MAY if the assertion
> > > is marked 
> > > optional).
> > > Attaching the RM assertion to a specific wsdl:service construct
> > > indicates that the RM protocol MUST be used for all messages
(whether 
> > > input, output or fault) related to the service (or MAY if
the 
> > > assertion 
> > > is marked optional).
> > > 
> > > WS-Addressing allows for policy assertions to be included
within an
> > > EndpointReference. Per section 2.2 above, the presence of
this
> > > policy assertion in an EPR specifies the level of support
for
> > > WS-ReliableMessaging offered by that endpoint.
> > > -------------------------------------------------------------------
> > > 
> > > > -----Original Message-----
> > > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > > Sent: Wednesday, Feb 15, 2006 17:16 PM
> > > > To: Paul Fremantle; Patil, Sanjay
> > > > Cc: wsrx
> > > > Subject: RE: [ws-rx] i021 proposal
> > > > 
> > > > So where are we with this proposal now? Is the below
text in, 
> > > > out? Does
> > > > it need to be revised in light of discussion to date?
What is the
> > > > expectation for this issue on the call tomorrow? Discussion
> > > to figure
> > > > out the correct direction to refine this proposal seems
> > > about right to
> > > > me.
> > > > 
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog: http://spaces.msn.com/mrgoodner/ 
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Paul Fremantle [mailto:paul@wso2.com] 
> > > > Sent: Thursday, February 09, 2006 3:04 AM
> > > > To: Patil, Sanjay
> > > > Cc: wsrx
> > > > Subject: Re: [ws-rx] i021 proposal
> > > > 
> > > > Sanjay
> > > > 
> > > > You are right. The proposal isn't yet fully clear on
the meaning of 
> > > > attaching WS-RM to a message or operation.
> > > > 
> > > > How about if the following text was added, before the
EPR text.
> > > > 
> > > > Attaching the RM assertion to a specific wsdl:input,
> > > wsdl:output, or 
> > > > wsdl:fault construct indicates that the RM protocol
MUST be 
> > > used when 
> > > > sending that message (or MAY if the assertion is marked
optional).
> > > > Attaching the RM assertion to a specific wsdl:operation
construct 
> > > > indicates that the RM protocol MUST be used for all
> > > messages (whether 
> > > > input, output or fault) related to the operation(or
MAY if 
> > > > the assertion
> > > > 
> > > > is marked optional).
> > > > Attaching the RM assertion to a specific wsdl:binding
 construct 
> > > > indicates that the RM protocol MUST be used for all
> > > messages (whether 
> > > > input, output or fault) related to the binding (or
MAY if the 
> > > > assertion 
> > > > is marked optional).
> > > > Attaching the RM assertion to a specific wsdl:port
construct 
> > > > indicates 
> > > > that the RM protocol MUST be used for all messages
(whether input, 
> > > > output or fault) related to the port (or MAY if the
assertion 
> > > > is marked 
> > > > optional).
> > > > Attaching the RM assertion to a specific wsdl:service
construct 
> > > > indicates that the RM protocol MUST be used for all
> > > messages (whether 
> > > > input, output or fault) related to the service (or
MAY if the 
> > > > assertion 
> > > > is marked optional).
> > > > 
> > > > You are also right about the EPR. I would recommend
making the EPR 
> > > > policy override the WSDL policy, but once again I think
this 
> > > > is an issue
> > > > 
> > > > with the overall WS-Policy Framework (i.e. a general
Policy 
> > > > issue not a 
> > > > specific RX issue).
> > > > 
> > > > Thanks for your comments,
> > > > 
> > > > Paul
> > > > 
> > > > Patil, Sanjay wrote:
> > > > > Comments inline ... 
> > > > >
> > > > >   
> > > > >> -----Original Message-----
> > > > >> From: Paul Fremantle [mailto:paul@wso2.com]
> > > > >> Sent: Thursday, Feb 09, 2006 1:43 AM
> > > > >> To: wsrx
> > > > >> Subject: [ws-rx] i021 proposal
> > > > >>
> > > > >> Proposal regarding issue 021. I'm not quite
sure this is 
> > > > >> right yet, so I 
> > > > >> would appreciate feedback from the Policy
experts.
> > > > >>
> > > > >> Based on CDII
> > > > >>
> > > > >> Delete 142-154 section 2.3 and replace with.
> > > > >>
> > > > >> 2.3 Assertion Attachment
> > > > >>
> > > > >> The RM assertion can have Service, Endpoint,
Operation 
> > > or Message 
> > > > >> Endpoint Policy Subjects [WS-PolicyAttachment].
> > > > >>
> > > > >> WS-PolicyAttachment [WS-PolicyAttachment]
defines both 
> > > > abstract and 
> > > > >> concrete attachment points in WSDL [WSDL1.1].
Because the 
> > > > RM policy 
> > > > >> assertion specifies a concrete behaviour,
it MUST NOT be 
> > > > attached to 
> > > > >> abstract constructs:
> > > > >>
> > > > >>     * wsdl:portType
> > > > >>     * wsdl:portType/wsdl:operation
> > > > >>     * wsdl:portType/wsdl:operation/wsdl:input
> > > > >>       * wsdl:portType/wsdl:operation/wsdl:output
> > > > >>       * wsdl:portType/wsdl:operation/wsdl:fault
> > > > >>     * wsdl:message
> > > > >>
> > > > >> The RM policy assertion MAY be attached to
the following 
> > > constructs
> > > > >> * wsdl:service
> > > > >> * wsdl:port
> > > > >> * wsdl:binding.
> > > > >> * wsdl:binding/wsdl:operation
> > > > >> * wsdl:binding/wsdl:operation/wsdl:input
> > > > >> * wsdl:binding/wsdl:operation/wsdl:output
> > > > >> * wsdl:binding/wsdl:operation/wsdl:fault
> > > > >>
> > > > >> If the RM assertion is attached to the wsdl:service
> > > > >> construct, it MUST 
> > > > >> be considered to apply to all the wsdl:port's
referenced in 
> > > > >> the binding.
> > > > >> If the RM assertion is attached to the wsdl:port
construct, 
> > > > >> it MUST be 
> > > > >> considered to apply to all the wsdl:binding's
referenced 
> > > > in the port.
> > > > >> If the RM assertion is attached to the wsdl:binding
> > > > >> construct, it MUST 
> > > > >> be considered to apply to all the wsdl:operation's
> > > > referenced in the 
> > > > >> binding.
> > > > >> If the RM assertion is attached to the wsdl:operation
> > > > >> construct, it MUST 
> > > > >> be considered to apply to all the wsdl:input's,
> > > wsdl:output's and 
> > > > >> wsdl:fault's referenced in the operation.
> > > > >>     
> > > > > It seems like your proposal allows for attachment
of RM 
> > > assertion at
> > > > the
> > > > > message level. In that case, wouldn't you also
want to specify the
> > > > > behavior when the RM assertion is directly attached
to the 
> > > > wsdl:input,
> > > > > wsdl:output or wsdl:fault constructs? Or is that
semantic somehow
> > > > > derived from the above? I think the main question
of the 
> > > > issue i021 is
> > > > > whether and how does RM assertion apply to the
outbound 
> > > (I hate this
> > > > > term) messages of an endpoint, and I don't see
a clear 
> > > > answer to that
> > > > > question in this proposal.
> > > > >
> > > > > There should also be statements for handling the
case where RM
> > > > > assertions are attached to multiple subjects within
the 
> > > same scope.
> > > > >
> > > > >   
> > > > >> WS-Addressing allows for policy assertions
to be 
> > > included within an
> > > > >> EndpointReference. Per section 2.2 above,
the presence of this
> > > > >> policy assertion in an EPR specifies the level
of support for
> > > > >> WS-ReliableMessaging offered by that endpoint.
> > > > >>     
> > > > > Since the previous text regarding the WSDL attachment
of RM 
> > > > assertion
> > > > > covers the behavior of outbound messages also,
there may 
> > > possibly be
> > > > > conflicts when both the techniques of associating
policies (WSDL
> > > > > attachment and EPR inclusion) are used.
> > > > >
> > > > > -- Sanjay
> > > > >
> > > > >   
> > > > >> Paul
> > > > >>
> > > > >> -- 
> > > > >>
> > > > >> Paul Fremantle
> > > > >> VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > >>
> > > > >> http://bloglines.com/blog/paulfremantle
> > > > >> paul@wso2.com
> > > > >>
> > > > >> "Oxygenating the Web Service Platform",
www.wso2.com
> > > > >>
> > > > >>
> > > > >>     
> > > > 
> > > > -- 
> > > > 
> > > > Paul Fremantle
> > > > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> > > > 
> > > > http://bloglines.com/blog/paulfremantle
> > > > paul@wso2.com
> > > > 
> > > > "Oxygenating the Web Service Platform", www.wso2.com
> > > > 
> > > > 
> > >