OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

amqp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [amqp] Addressing Model Blog Post


My key point is that I don’t want to constrain the scope naming model to a particular notion of naming authority or model for how the legitimacy of such an authority and of assigned names might be determined. 

Names are names.

If you hit 8.8.8.8 and there’s an Internet network access paywall, that paywall completely owns that address until you put down money. You are 100% at the mercy of your next hop router for what 8.8.8.8 means. 


Von: Rob Godfrey <rgodfrey@redhat.com>
Gesendet: Montag, November 12, 2018 6:03 PM
An: Clemens Vasters
Cc: Alan Conway; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post
 


On Mon, 12 Nov 2018 at 17:53, Clemens Vasters <clemensv@microsoft.com> wrote:
I believe the authority is exactly the next party  you talk to and nobody else. If that party doesn’t know what to do with a name, it routes to some upstream  “default gateway” or simply fails out.

I disagree that there need to be central authorities at all. If the container behind the next hop feels like it can act in the role of foo.bar.example.com and it’s authorized to do so by an assumed overlaid security layer and rule set, it can go right ahead and handle the message.

You still need a *naming* authority for the scopes - you are just delegating that naming authority to the security authority ...  I'm not saying you need to connect to that authority at any point, but you need some way of being able to prove ownership of a scope. 
 

Scope names are like IP addresses. They are not like DNS A/AAAA records.

IP Addresses are still assigned by an authority.  I can't just claim to be 8.8.8.8 and expect that to be respected when connecting to the internet.  

-- Rob
 
 

Von: Alan Conway <aconway@redhat.com>
Gesendet: Montag, November 12, 2018 5:03 PM
An: Rob Godfrey
Cc: Clemens Vasters; oasis-amqp-list
Betreff: Re: [amqp] Addressing Model Blog Post
 


On Thu, Nov 8, 2018 at 4:19 PM Rob Godfrey <rgodfrey@redhat.com> wrote:


On Thu, 8 Nov 2018 at 20:20, Alan Conway <aconway@redhat.com> wrote:


On Thu, Nov 8, 2018 at 12:14 PM Clemens Vasters <clemensv@microsoft.com> wrote:

 

I want to make a car on the road addressable (that is conceptually the target container) and then use the node structure to allow for addressing different aspects of that car. The car is roaming across a wild mix of 3G/4G/5G networks including international roaming and never has a stable IP address. So I’ll give the car a rendezvous point in its general proximity that acts as a proxy and from where it can pick up messages (that is the container that actually gets routed to) as the car gets back on the network, and that rendezvous point may shift.

 

When I want to send messages to that car, I connect to the edge of the car overlay network, find a path to whatever the right target container is (how that happens is indeed out of scope) and then direct messages to the nodes in that container.   

 

I need a name for the onramp, a name for the car whereby it’s obscured whether that’s the actual car or just a container acting as an intermediary for it, and a name for the map service in the car.


+1 - you need a hierarchical name that includes all those parts. But you don't (IMO) need to syntactically differentiate what the different parts of the name refer to - let the routers do that at runtime.
That allows your proposal of //(scope)/foo/bar but doesn't mandate it. That way you don't have to decide between //(ford.car)/steering and //(car)/ford/steering up front, you can use //car/ford/steering consistently and configure the network to deliver based on how things are deployed.


So to me the issue is in the case of messaging between two different domains, where the precise details of routing within the domain should not be exposed across the domain boundary (and thus also not impact routing externally if the internal rules are changed).  

Within a single organisation or a single centrally controlled messaging network it is fine to have knowledge of the topology / routing be distributed to many routers. Where we a talking about being able to send messages across organisational boundaries this would not be appropriate.  As such I would expect that within the domain "foo" you can set up any routing scheme you like, and distribute the knowledge about that scheme amongst your routers... but for someone from bar sending a message to foo/address1 via the onramp amqps://messaging.bar then the amqp endpoint as messaging.bar can not be required to parse beyond foo/ to know the next step.

I believe we need a way to identify the "domain" (or scope) and the domains must be uniquely identifiable (thus we need to appeal to some naming authority). Ideally one should be able establish trust that a particular intermediary "speaks" for a given domain using some sort of PKI infrastructure.  I don't really care if the address syntax is //<domain>/path or /(<domain>)/path, that is a fairly uninteresting syntax decision (I think the (<domain>) variant may lead to an easier implementations within large domains (i.e. large organisations).   In a global (or multi-organisational) heterogeneous messaging network I do believe that we need a way of differentiating the "global" part (the domain) from the "internal" part.

Brings us back to "who is the authority" for AMQP domains. 

I'd like to support the case where DNS Is the authority thusly:
GIve amqp://foo.net/x/y we allow
- client connects to foo.net and uses AMQP address "//foo.net/x/y" i.e. including the authority from the URL.
- client connects to foo.net and uses relative AMQP "/x/y" - server may be able to pick up foo.net from virtual host and route elsewhere for link addresses, but message to:  addresses can't be changed so in that case the client must use an absolute address.

In the case where the on-ramp IP or authority is different from the AMQP authority, the client must in any case be aware of two addresses, so it connects to amqp://on-ramp.net but sends to //foo.net/x/y



--
_____________________________________________________________________________

Red Hat GmbH, www.de.redhat.com,
Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael O'Neill


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]