I agree with
Doug, that the crux of the WS-A
issue is “whether or not WSA will
allow other specs to define new
'special' non-addressable URIs.” I believe that if this point were to
be used
effectively as an extensibility point it would have to be architected
better. We
put this extensibility point in at the last minute without adequate
consideration of its consequences. Anish’s isAnon proposal attempts to
architect the point better, at least in the domain of anonymous-like
behavior.
I can imagine extending that mechanism to an “isSpecial” functionality
for
general-purpose special URIs (e.g. synonyms for ‘none’). Either of
these
solutions would naturally fall within the Core, suggesting a new
version of
WS-A which is an impractical solution. The practical solution is to
remove the
misleading suggestion in 5.2.1 that this extensibility point actually
can be
used safely.
The core of this issue
remains, of course, an WS-RM one –
namely, can the desired “polling” functionality (if desired!) be
achieved without
intruding into the WS-A layer, without bending or limiting WS-A in ways
that
might not compose well with other uses of WS-A, and whether it fully
leverages
the capabilities of WS-A to address messages to the appropriate
destinations.
I think this WG can play a role in providing such advice, though that
has been slowed
considerably IMO by the lack of clearly documented use cases and a
model for
how the current polling solution is intended to work.
Doug,
The list is
what I heard from the folks on
the call. It is intended to provoke discussion and possibly correction.
The question
of priority is if the
exposition is the correct description of the problem to be solved.
There was
also discussion of a potential
errata that would remove 5.2.1 which I did not include in my summary.
For now, I
would be content to have a well
characterized definition of the problem so that it might be bounded.
Several
folks have expressed reservations
about synonyms for anonymous. If it is intended that anonymous
identify a
specific resource (such as the backchannel). It then would make as
much
sense as defining a synonym for www.cnn.com.
More than
that, some folks have said that
this synonym overloads replyTo and defines semantics associated with a
definition of this uri that only RM will understand.
Do you
disagree with the exposition?
Does the RM redefined URI convey identifying or parametric information
or does
it not?
Thanks
-bob
Bob,
A
couple of points:
- A4 -
if I'm reading your text right, I believe you're saying that other
specs can
define their own replyTo header. And this is true. However, this
means that WSA is extensible by allowing people to avoid WSA. Funny
:-)
-
Despite all of the talk around CR33, the issue is not about
transmitting
identifying information. Nor is it about whether or not identifying
information should be placed in the URI or in some Reference
Parameter/Property. The issue around CR33 is whether or not WSA will
allow other specs to define new 'special' non-addressable URIs and
allow them
to be used in the wsa:ReplyTo/FaultTo. That's it. It doesn't matter
what the semantics of those URIs are, it doesn't matter how people are
going to
use them - its much simpler than that. Can other specs do exactly what
WSA did and define new URIs? Any discussion about whether or not a
spec
made the right choice to do that is not relevant. WSA needs to answer
the
very simple question from a more abstract point of view and once that
answer is
found then I think everything else will fall into place.
So,
does the WSA WG think that no other spec, for all time, will ever need
to
define a new special non-addressable URI that may be used in
ReplyTo/FaultTo?
(like ws-rm or ws-discovery did)
thanks,
-Doug
This is a list of the
results, as I heard them, of our discussion on
2006-10-02 related to our response to CR33
Exposition:
It
seems that the desire inferred by the issue is that an endpoint would
like to transmit
identifying information (or perhaps some other parametric information)
in a one
way message, and that one way message is intended to be used to “open
the
backchannel” upon which may be transmitted information that is
determined in
part by the identifying or parametric information transmitted in the
originating message. In the specific use case presented, the issue
originator proposes that this identifying or parametric information be
passed
in the replyTo uri as a special form of “anonymous”. CR33 states that
the
WS-Addressing WSDL binding CR document would create interoperability
issues
with their implementation since it does not permit a form of anonymous
other
than the literal “anonymous” to be represented in WSDL.
In the
WS-Addressing Teleconference of 2006-10-02, there was a brainstorming
session
intended to clarify exactly what problem the WS-Addressing working
group was
trying to solve related to its resolution of CR33 since several
proposals
related to a direct response to CR33 have failed as yet to gain
consensus.
Alternatives
mentioned: (please feel free to come up with more if you have a better
idea)
A1)
During the progress of the WS-Addressing working group, a feature known
as
Reference Properties was removed from the original submission. If this
were to be added back, then this could be used to convey such
identifying or
parametric information. This would imply changes to both rec level
specifications as well as the WSDL binding. It is not clear if these
might
be “breaking changes”.
A2)
The WS-Addressing specifications include a feature known as Reference
Parameters which are created by the epr minter which are considered to
be
“opaque” to all but the minter. Outside of the WS-Addressing “layer”
there may be no such constraint. Reference Parameters might be used to
convey this identifying or parametric information. Note that there is
not
general agreement that WS-Addressing is a “layer” or if it is a set of
kit
parts which may be used at any layer. This might imply a clarifying
change to
WS-Addressing specifications.
A3)
WS-Addressing includes a feature known as “From” which contains a uri.
There are no behavioral constraints imposed by “From” and potentially
anything that might be represented as a uri might be conveyed. This
might imply
a clarifying change to WS-Addressing specifications.
A4)
WS-Addressing defined a limited set of special URLs which mean specific
things
to WS-Addressing when used in replyTo. These are “anonymous” and
“none”.
If the behavior specified by WS-Addressing is not desired, then the
authors of other specifications might specify their own forms of
replyTo
semantics appropriate to their application without WS-Addressing
implications.
This would imply that CR33 be closed with no action.
A5) It
was suggested that there is wide latitude in what might be contained in
a SOAP
header and the authors might be able to use such a means to convey the
desired
identifying or parametric information. This would imply that CR33 be
closed
with no action.
A6)
WS-Addressing Core and SOAP binding are fine as-is, but we just need to
fix the
WSDL binding or perhaps come up with a WSDL cum policy related change.
For proposals related to this alternative, please refer to the issue
list.
For
the purposes of this thread please identify in the subject line the
alternative
A[1-n] referenced or “exposition” if you feel the problem statement
needs
improvement.
Thanks
-bob