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



All,

not having had any requests for changes, I'm going to open two electronic ballots asking for these working drafts to be approved as Committee Specification Drafts and opened to Public Review.  

Normally I would have held a vote at the next TC meeting, but I'll be travelling on Friday and unable to attend.  Therefore, and after having consulted the TC Admins on the correct wording of such votes, you should shortly see two ballots opening, allowing Voting Members just over 7 days to approve or reject these working drafts.

Thanks all,
Rob

On Fri, 15 Jun 2018 at 18:00, Keith Wall <kwall@redhat.com> wrote:
Rob,

Thanks.  No comments from me on either document.  Both look good.  I
think both AMQ-123 and AMQ-140 can be closed.

Kind regards, Keith.


On Fri, Jun 15, 2018 at 10:19 AM, Rob Godfrey <rgodfrey@redhat.com> wrote:
>
>
> 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
>> "target.address"?
>
>
> 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
>> earlier?
>
>
> 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.
>
> Thanks,
> Rob
>
>> -Ted
>>
>>
>> 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


--
_____________________________________________________________________________

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]