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

On 14 June 2018 at 19:12, Ted Ross <tross@redhat.com> wrote:
Comments and questions about Anonymous Terminus:

In Figure 2.1, the link has a target of "ROUTER".  Is this intended to
be a literal reserved address? 

No, it is just an example
Can routing nodes be accessed using
targets that don't have null addresses? 

A container can create as many routing nodes as it likes, at any addresses it likes.  We don't define a way for the peer to identify that the node it is sending to is a routing node, I'm not sure whether doing so would add any value.
Is this a case where messages
can flow over a link in which the "to" address is different from the

Yes - in general it is always true that the to: in the message can differ from the target address of the link (this will likely be the common case where clients are consuming from an address)

It should be noted that the links with source.addresses of ADDR1 and
ADDR2 are not necessarily attached within Container B.  They may be on
a different container and there may be multiple hops of anonymous
links to routing nodes between source and target.

I'm not sure what you mean here... links are always between two containers.  The specification is purely describing the behaviour of one type of node that a container may provide.  Wider networks of containers and how messages may get routed across them is out of scope for this specification.

In section 2.3, it says "... reserved for use as a router node by
...".  Should this not use the term "routing node" as it is defined

I'll fix this

There is no mention of targeted links to a routing node.  This is
where a link is established to target.address == ADDR1 but the
terminus is actually on a routing node that will route all of the
deliveries to another link with source.address == ADDR1.  This might
be written off as simply an interpretation of the semantics of nodes
and termini.  However, it is possible that the target and source in
question are on different containers.  Still, this situation may be
described using the content of the base specification and this draft.
Sorry for the rambling, and possibly irrelevant point.

Yes - I think this is outside the scope of this document.


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:
> https://www.oasis-open.org/apps/org/workgroup/amqp/download.php/63251/latest/anonterm-v1.0-wd05.pdf
> https://www.oasis-open.org/apps/org/workgroup/amqp/download.php/62939/latest/soleconn-v1.0-wd04.pdf
> 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]