Re: Web Services Addressing 1.0 Core comments

Dear Paul,
Thank you for taking the time to review and comment on the
specification.
 
The Web Services working group met on April 24 2006 to consider your
comments against the WS-Addressing Core specification and in this email
is responding to you with the decisions reached in that meeting.
 
We hope that these decisions are acceptable to you.  If you are
satisfied, please respond with your consent.
 
Thanks
-bob
 
1. The EPR abbrev is used without first defining it
> 
The working group agrees that this is awkward and has spelled out
endpoint reference at its first use.
 
> 1.1 It's too bad that XML Schema Component Designators
> [http://www.w3.org/TR/xmlschema-ref/] isn't farther along, because
then
> you wouldn't have had to invent your own syntax to do what they do :-(
 
Perhaps so, but it is not.
 
> 2 Is it just me, or doesn't this section seem out of place, coming
before
> section 3?  I would like the spec would read better with the current
> section 2 & 3 reversed in order.  
 
Several reviewers prefer the current order, some the other.  The working
group decided to leave the current order unchanged.
 
> 2.1 [address] is defined as an IRI but the description contains
"...this
> URI is used...".  Shouldn't that says "...this IRI is used...]?  This
> happens in a few other places.  The editors should carefully check all
> uses of URI to insure that they shouldn't actually be IRI.
 
This usage is deliberate.  If something meets the tighter constraints of
URI, we say "URI", otherwise we say "IRI".  So for example [address] is
an IRI, but the anonymous address in particular is a URI and we say so. 
It would also be correct to say " ... this IRI is used ..." but we
discussed the issue and opted for the present wording.
 
> 3 "The contract between the interacting parties may specify that
multiple
> or even a variable number of replies be delivered" should be "The
contract
> between the interacting parties MAY specify that multiple or even a
> variable number of replies be delivered."  The editors should check
all
> uses of "conformance verbs", to make sure they are capitalized
> appropriately.
 
The working group has reviewed the text and feels that the current
capitalization is consistent with our intent as well as the guidelines
specified in RFC 2119.
 
> 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.
 
> 3.1 [relationship] In the abstract definitions it is unclear whether
the
> relationship type is the 1st or 2nd member of the pair.  It is
possible
> that it doesn't really matter to define that at the abstract
level...but
> it would appear to be necessary.
 
We acknowledge that the order is not specified in the abstract, but we
have so far had no difficulty on this point in implementations.  We do
not foresee what this change may fix or break, so we prefer to leave the
current text as-is at this point.
 
> 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.  The issue will not be re-visited since the
arguments one way or the other remain the same as they were at the point
the issue was decided.  That prior decision resulted in the filing of a
formal objection
<http://lists.w3.org/Archives/Public/public-ws-addressing/2005May/0047>.
Notwithstanding this objection, the working group has decided to take no
further action.
 
> 3.2 minor nit: why do the abstract properties and infoset reps have
> different names?  Wouldn't it be less confusing for them to have the
same
> name?  E.g., destination and wsa:To, source and wsa:From.  As written,
I
> always have to perform a mental mapping between them.
 
We agree that it may have been nice if the names matched, however, it is
late in the game for this degree of change to be assimilated.
 
> 3.2  section 3.4 describes the default for wsa:FaultTo as being
> wsa:ReplyTo..and if wsa:ReplyTo is empty then it's a free-for-all. 
> Shouldn't this behavior be stated here?  since the defaults of all the
> other properties are described here.
 
The further exposition on these properties was included in underlying
binding specifications which factoring allows appropriate treatment
based on the characteristics of the underlying protocol.  When using
these bindings of MAPs to XML, they are explicitly defaulted to
anonymous.  The group decided to leave the current text unchanged.
 
> 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.