Re: Web Services Addressing 1.0 Core comments

> We hope that these decisions are acceptable to you.  If you are 
> satisfied, please respond with your consent.

yes...I am satisfied with these responses. A few comments below.

pvb
> > 3.1 (and elsewhere) References are made to the WS-A WSDL Binding spec,
> > although that hasn't even reached CR yet...is that kosher according to 
the
> > process?  I thought that a spec could only reference another spec if 
it was
> > no more than 1 step back in the process.  Has that changed?
> 
> The working group feels that references are not normative and thus 
> it is acceptable in this case.

So you are saying that the sentence "Web Services Addressing 1.0 - WSDL 
Binding" describes the mechanisms of Association" has no normative 
force...and there may be other valid ways of associating an [action] with 
a WSDL.  If so, then this is OK.

> > 3.1 [reference params] I'm sure there's a good reason but why isn't
> > [destination] and EPR?  The presence of [ref params] (and it's 
description
> > as applying to [destination] )would seem to indicate that [dest] 
really is
> > an EPR and not "just" an IRI.  Is the current model because of 
difficulty
> > binding "to" EPRs to common transports?  I realize it is VERY late in 
the
> > process to change something this fundimental but it has always seemed 
odd
> > to me...sorry for not saying anything sooner.
> 
> This issue has been heavily discussed in the past and the working 
> group was narrowly divided...That prior decision resulted in 
> the filing of a formal objection.

I'm just glad to know that I'm not the only one to find the current 
situation strange...as they say, if it walks like an EPR and quacks like 
an EPR...then it is an EPR :-)

> > 3.2.1 why isn't comparison of [source], [reply endpoint] and [fault
> > endpoint] discussed?
 
> This is deliberate.  There are thorny issues involved in defining the 
context 
> within which a particular comparison is meaningful. 
> Byte-for-byte identical EPRs may mean different things depending on 
context, 
> and completely different-looking EPRs may mean the same thing. 
> Rather than try to define what an EPR "means", we define what you can do 
with 
> it.

I understand the "thorny issues".  I think it would be helpful to many 
readers for you to provide a paragraph or so explaining why you aren't 
describing the comparison of [source], etc...but like I said, I'm 
satisfied with this response and won't push it if you choose not to add 
the explanation of why you aren't describing the other comparisons.

Received on Tuesday, 25 April 2006 17:33:02 UTC