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] Documents for review


The intention is something closer to 1. than to 2.  The whole point of the anon relay is that it provides a way to send to a target Foo without having to establish a link to Foo.  That's not to say that the definition is as strict a 1. would imply (for instance the container hosting the anonymous relay may impose some sort of quota on the number of links that you may attach, thus attempting to establish a new link to A would fail, while using the existing link to the anonymous target would not).  The anonymous relay is an optimisation that can be used by clients that are aware of its meaning, but those clients should still be able to perform the same messaging (albeit perhaps with some extra overhead for attaching and detaching links) without knowledge of the meaning of the anonymous relay.

-- Rob

On 13 June 2018 at 16:29, Alan Conway <aconway@redhat.com> wrote:


On Wed, Jun 13, 2018 at 7:48 AM, Rob Godfrey <rgodfrey@redhat.com> wrote:
All,

I believe that the draft specifications for the Anonymous Terminus and Enforcing Connection Uniqueness are getting to the point that they are ready for promoting to a Committee Spec Draft / Public Review Draft.

Would those interested please be so good as to review the latest working drafts for these documents:


Just one paragraph I'd like to see clarified a little:

"is possible that a message sent to a routing node has an address in the to field of properties which, if used in the address field of target of an attach, would result in an unsuccessful link establishment (for example, if the address cannot be resolved to a node).  In this case the routing node MUST communicate the error back to the sender of the message"

So given a router R and address A, which of the following is intended:

1. sending Message(to=A) over link(target-container=R, target.address=null) MUST fail if attach(target-container=R, target.address=A) would fail. In other words all addresses that can be anon-relay routed by R MUST also be available as link target nodes in R.

2. If a router can't forward Message(to=A) over anon-relay it should say so. There's no implied equivalence between addresses that are anon-routable by R and addresses that are valid link targets in  R.

I'd lean towards perferring 2, as 1 adds burden to anon-relay implementers. In the case of 1. the simplest anon-relay router has a single anonymous node and refuses all all addressed links - no variable-sized link tables, link lifecycles etc. to manage. I'm not adamant though, if there are other good reasons for choosing 1 I can live with it as long as its clear.


And either send any comments via e-mail, or come prepared to discuss them at this week's TC meeting.  Depending on the amount of feedback we get, hopefully we might be in a position to vote on promoting these to public review drafts at the TC meeting after next.

Thanks,
Rob

--
_____________________________________________________________________________

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




--
_____________________________________________________________________________

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]