Re: [amqp] addressing summary

[Ted Ross <tross@redhat.com>]

Thanks for this summary.  Here's my first round of questions and comments:

The where-i-am and who-i-am properties:
=======================================

Does a container's who-i-am have to be a subset of its where-i-am?

It says that peers can define a subspace within a container's
where-i-am.  How is this negotiated in the protocol since the OPEN
performatives don't handshake.  Does a container that wants to create a
subspace need to hold its OPEN frame until it receives the peer's OPEN
frame?

What if both containers want to create a subspace?

Are where-i-am and who-i-am optional properties?  Even for routers?

It looks to me that we might be trying to create a routing mechanism
based on container hierarchy.  I think this specification should not
endorse any routing mechanism.


Anonymous Relay Behaviour
=========================

"Links from the anonymous relay to a container-address are not permitted"

  - Is container-address the same as who-i-am?
  - Why is this prohibition here?

Can we state explicitly that links from an AR to another AR are permitted?

Can we add something like the following?  "Links established from an AR
with the dynamic flag set are assigned a unique address by the AR"


Request/Response Examples
=========================

What is meant by "Message properties define the quality of service?"

The term "match" is used throughout the summary.  Does this word have
special meaning or does it simply mean "is equal to?"

Example (2) should be removed in my opinion.  This try-until-I-succeed
protocol is not very elegant.  Furthermore, this will not scale well in
a network of relays because the address, created by the endpoint, will
need to be propagated throughout the network before it can be used.
This will create race-conditions in request/response scenarios where the
request arrives at the server before the server's relay is ready to
forward the response.

What is missing here is dynamic-address-assigned-by-the-peer.  This has
been proven in implementation and it scales efficiently without race
conditions.  I should emphasize that a dynamic address is _not_ the same
as a temporary queue.

We've had the dynamic-address discussion a half dozen times and it keeps
dropping off the radar.  Am I the only one who thinks this is important?