[OASIS Issue Tracker] (AMQP-126) Sole Connection Detection Policy needs clarification

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

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

Robert Gemmell commented on AMQP-126:
-------------------------------------

I don't think it says what your table indicates, but I agree it could maybe be clearer to help ensure people can't mistakenly interpret it that way.

The intent in the '0 / strong' entry is to say that the policy of the existing connection with SCE settings will be respected during conflict, and even where connections don't themselves have any SCE settings they will still be taken into account for enforcing the policy of others that do.

> Sole Connection Detection Policy needs clarification
> ----------------------------------------------------
>
>                 Key: AMQP-126
>                 URL: https://issues.oasis-open.org/browse/AMQP-126
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Sole Connection
>    Affects Versions: soleconn-WD2
>            Reporter: Lorenz Quack
>
> I find Section 3.2.2 of the specification unclear.
> To wrap my brain around the rules and when a certain detection policy would trigger the enforement policy I consider 4 cases: an existing connection does/doesn't have sole connction enforement (SCE) permutated with the new connection having/not having SCE.
> Then my reading of the spec gives me this table:
>   | old conn |  new conn ||  "strong" | "weak"
> 1 | NO SCE   |  NO SCE   ||    no     |   no
> 2 | NO SCE   |     SCE   ||    no     |  yes
> 3 |    SCE   |  NO SCE   ||    yes    |   no
> 4 |    SCE   |     SCE   ||    yes    |  yes
> Do people agree with my reading of the spec?
> Was it intended this way?
> In the "strong" case I find the asymmetry between case 2 and 3 surprising.
> I find it surprising that the weak policy should trigger in case 2 where the "strong" policy does not.
> My guess is that the intention was that the strong policy also triggers in case 2.
> Overall, I find it hard to see a clear intention behind the two detectoin policies.



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