I've re-read the proposal and rfc3986. I applaud your efforts to align this more clearly with thep URI spec.
Here goes...
I think the first priority is to define address syntax and what it means to the user, without reference to how a AMQP routing is implemented. Your section 2 on AMQP networking is very good, and useful for folks implementing routers but I would move it to the end. First priority is to figure out what the address means - how it works comes later.
I'm not clear what you are defining as the AMQP address that goes in message to/reply-to or terminus address - is it:
- the whole URI, scheme and all - don't like that, scheme is irrelevant after connection
- a network-path relative URI reference "//authority/path?query" - if so what does the authority part mean once detached from its DNS/IP meaning, or can it be re-attache it to its DNS-IP meaing?
- just the /path?query (absolute and/or relative) - if so clarify how to extract the AMQP address from a URL - path with or without leading '/'? Sad but true this has been a point of real confusion and bugs
Regarding scope - I don't think we're ready to mandate that, but we need a consistent escape mechanism for "special" address components:
- Clements routers need an optional leading scope
- Dispatch router has magic "_topo" address for router network introspection
- Management spec (and dispatch router) use "$management"
I'd propose that the addressing spec say you SHOULD NOT use '$' in AMQP addresses as it MAY be used for special purposes - or go further and mandate URL escaping if used for non-special purposes. Then I'd normalize Clemens routers, dispatch routers and management thusly:
Â/$scope/foo.bar/... clemen's scope foo.bar
Â/$router/router-id/... dispatch _topo introspection into router topology
Â/$managment/... manages directly connected "entity" be it router, broker or whatever.
Â/$scope/foo.bar/$management/... manages a Clemens scope (whatever that means)
Â/$router/router-id/$management/.... manages a router in a dispatch network
Â/$scope/foo.bar/x/$router/router-id/$management/... manages a router in a network that is bound to address x in a clemens scope...
The latter examples are silly but attempting to illustrate why its a Bad Idea for the addressing spec to mandate a specific routing model.Â
At this point since we have at least 2 very different models on hand - $scope and $router are nothing like each other. A $scope is the authoritative owner of addresses, a $router is a way of introspecting into the router network, it doesn't "own" any addresses.
I have some ideas about how to reconcile the models and converge "scope" and "authority" into a single thing, but need to write it all down. Am working on it.
Finally I want to introduce a new problem: every AMQP message on the wire has between zero and four addresses.
- optional message to and reply-to fields (0-2)
- optional source and destination addresses (0 for anonymous routing, usually 1 but can be 2)
Note zero is quite possible with no source, anonymous target and no to: or reply-to: Wouldn't count on the message going anywhere but there you have it.
Only 3 addresses (to, source, target) are relevant to delivering a message, but in a routed/bridged request-response scenario they could all be relevant when it comes to figuring out how you are going to route the reply,
Dispatch router does and the HTTP bridge have thrown up a lot of interesting things to consider. Again will try to write some of this up.
Cheers,
Alan.