[OASIS Issue Tracker] (AMQP-114) Typos, field xref fixups, and potential clarity tweaks

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

     [ https://issues.oasis-open.org/browse/AMQP-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rob Godfrey updated AMQP-114:
-----------------------------

    Fix Version/s: failover-WD2

> Typos, field xref fixups, and potential clarity tweaks
> ------------------------------------------------------
>
>                 Key: AMQP-114
>                 URL: https://issues.oasis-open.org/browse/AMQP-114
>             Project: OASIS Advanced Message Queuing Protocol (AMQP) TC
>          Issue Type: Bug
>          Components: Connection Failover
>    Affects Versions: failover-WD1
>            Reporter: Robert Gemmell
>            Assignee: Rob Godfrey
>            Priority: Minor
>             Fix For: failover-WD2
>
>
> # Abstract
> "(i.e. ccepting incoming connection requests)
> - Typo, missing character.
> # 3.1 Connection Property
> "Note that every connection-details within this list MUST use the same authority and provide the the same mechanisms to establish authorization"
> Would it be clearer to say the servers represented by the connection-details entries? The details themselves don't use anything.
> "The list MAY contain the connection details identical to those used for the current connection."
> Rather than saying MAY, would it be better to say SHOULD NOT? I think that would better fit the intent, and with the subsequent text indicating it SHOULD NOT alter the client behaviour, I think using MAY essentially encourages inclusion rather than the preferred exclusion. I think changing it would also better align with the later Redirect Alternates text, though that is admittedly a somewhat different situation.
> # 3.1.1 Connection Details
> ## scheme
> "The type of connection to establish. If omitted then the scheme for the current connection MUST be used. For security reasons, a connection SHOULD NOT be on a less secure transport than the current connection (e.g. from a TLS secured transport to an unencrypted transport). The Server SHOULD NOT offer such schemes and, if offered, the client MUST NOT use those details for establishing the new connection."
> Is the first SHOULD NOT statement at odds with the following MUST NOT? That is, if we say the client MUST NOT use the details if offered, then aren't we in effect saying a connection MUST NOT be on a less secure transport, rather than SHOULD NOT?
> ## port
> "If omitted then the default port for the scheme is to be used."
> - Perhaps SHOULD, or MUST, rather than "is to"?
> ## hostname
> "supplied in the hostname field of open frame,"
> - Perhaps drop "frame", or override the xref text to improve readability?
> "during the SASL and TLS negotiation (if used)"
> - It seems a little odd that the previous snippet uses a field specific xref, while this one which immediately follows doesn't elaborate that it covers sasl-init.hostname and SNI.
> # 3.2 Redirect Alternates
> "In this case the the info field of error MAY contain the following"
> - Double "the" from xref XSLT expansion
> "present in the the info field of error as the primary redirect"
> - Double "the" from xref XSLT expansion



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