RE: [ws-rx] i021: a proposal

["Yalcinalp, Umit" <umit.yalcinalp@sap.com>]

Doug,

 

I guess I did not make my preference clear while asking the question.

 

1. I am fine as to offering this option as an option, but not a mandate. So, keeping it as a recommendation would be ok with me esp for the cases you list. We have to come up with the adequate expression.

 

2. Moving the params to the CSR should not interfere with the idea of extensibility in general.

BTW, I will not oppose moving the params to the CSR.  

 

If we decide to expose them in the CSR, it does not preclude other uses of extensibility. Those are orthogonal issues and should not be mixed with.

 

The proposal for i075 I made/you sent addresses the extensibility problem regardless of whether we move the params to the CSR and resolves the issue.

 

I am strong supporter of extensibility and lets keep it intact. It has nothing to do with this issue and all the other uses of it we may currently not anticipate right now.  

 

--umit

 

 

---

From: Doug Davis [mailto:dug@us.ibm.com]
Sent: Monday, Jan 16, 2006 2:59 PM
To: ws-rx@lists.oasis-open.org
Subject: RE: [ws-rx] i021: a proposal

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

> Two things:
>  
> -- A question about the EPR/metadata section that you are
> suggesting.  I am trying to understand how strong a requirement you
> are suggesting we make there.
>  
> In WS-A, we have discussed the fact that EPRs may be stale. This is
> also true for EPRs that may contain metadata that indicates that the
> endpoint should have WS-RM engaged or EPRs that may not have this
> data. It may be possible to use other means, for example WS-MEX, to
> determine the capabilities of the endpoint.  Therefore, "requiring"
> the metadata section may not be feasible right away, although we can
> recommend it.

I'm envisioning this being used in cases where people choose to
_not_ expose WSDL, where doing a WS-MEX Get isn't an option, or in
cases where people know the EPR will not go stale.  The choice is
up to the generator of the EPR.  The RM spec just offers up a list of
possible solutions and let's the app make the choice.  If the
wsa:Metadata section can not be used for things like this then I would
question why its even there at all.

> -- Are you suggesting to remove the extensibility of the assertion
> itself? Removing extensibility contradicts the general extensibility
> principles we have adopted in the industry for WS standards in
> general. We should not limit the vendor's capabilities in this area
> and not force them to use some other mechanism in their private environment.
>  
> I will oppose such a direction.

Given the previous discussions it just seemed easier to kill 'em. :-)
If things like AckInterval and MaxMessageNumber can't be thought of
as static enough to include in WSDL/Policy and we move them to the
CreateSequenceResponse, then I have a feeling most everything would
probably be moved there as well.  And CSR is extensible so people can
place those 'other parameters' in there.  Honestly, I don't really
have a huge preference either way because I never saw a problem with
Sequences spanning multiple endpoints and each endpoint exposing different
RM Policy - but after seeing all of the angst it cause some people
it just seemed easier to remove them.
(I keep having flashbacks to our endless DA discussions  :-)

thanks,
-Doug