[OASIS Issue Tracker] (AMQP-134) Undefined use of "network"

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/AMQP-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66923#comment-66923 ] 

Rob Godfrey commented on AMQP-134:
----------------------------------

I'd also be happy if we can come up with wording for the introduction / elsewhere that avoids use of terms like gateway / bridge / etc.  My intent here was to try to provide some sort of motivation for the mechanism in general terms, rather than a formal definition.

Further, upon re-reading the core specification I note that the term AMQP Network has a meaning there which is not the meaning that was implied in the Response Routing document, as such I think we should remove the use of this term in the Response Routing document (I think the meaning ascribed to the term in the core spec is not terribly useful, and ideally that section would be rewritten, but that is a separate issue). 

Re section 2. "O determines that address D represents a service on a separate AMQP network", (ignoring for the moment the use of the term "AMQP Network" which, as above, should be changed) - I don't think we need a definition *here* as to *how* O figures this out.  For the purposes of this document I think it is enough that O determines this through some configuration within O.  

> Undefined use of "network"
> --------------------------
>
>                 Key: AMQP-134
>                 URL: https://issues.oasis-open.org/browse/AMQP-134
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Response Routing 
>            Reporter: Clemens Vasters
>
> This spec, just as the base AMQP 1.0 spec, uses a notion of "AMQP network" and also "sub-network" that has no formal definition in the AMQP specification set. This spec also does not refer to the "intermediary" term that is mentioned several times in the AMQP 1.0 spec, and it must be assumed that the "gateway" and "bridge" nodes that are discussed here are acting as such intermediaries.
> For readers not deeply unfamiliar with the idea that AMQP has its own idea of "network", there is also substantial confusion risk with the common concept of "network" (and "sub-network"), which usually refers to the Internet Protocol Stack notion.
> The terms "address domain" and "address" are also used without definition. The closest to a definition of "address" is in AMQP 1.0 Sec 3.5 where the term "address" is defined, with a note in parens, as to be resolved to a "node within that container". An address domain as illustrated here appears to span containers, which raises the question of how containers are being addressed on the AMQP network (vs. the underlying IP network)  
> In section 2, it is stated that "O determines that address D represents a service on a separate AMQ network", but there's no criterion defined anywhere for how O might figure that out.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)