RE: [ws-rx] i021: a proposal

[Doug Davis <dug@us.ibm.com>]

"Yalcinalp, Umit" <umit.yalcinalp@sap.com>
wrote on 01/16/2006 06:33:22 PM:

> 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.


I'll see if I can find the time to come up with the
exact textual changes
for the specs (gotta keep the "just monkey"
status) and I would let it 
remain as just one of many options available.

> 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.  

It does seem a bit odd to think people will want to
add extensions
to this one assertion while the TC itself appears
to be headed down
the path of removing all of the ones it thinks would
be of interest
to the RM community at large.  So, I think it
would be interesting
to hear of some use-cases that would warrant keeping
this extension
point over people simply defining their own RM Policy
assertion that
isn't under this one.

thanks,
-Doug



> --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