[OASIS Issue Tracker] (MQTT-301) Metadata: CONNACK Retained messages supported

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

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

Ken Borgendale commented on MQTT-301:
-------------------------------------

As to the publish before the CONNACK, I think we have to say generally that a client which proceeds to publish before receiving the CONNACK is assuming that it knows what the response to the CONNACK will be.  Obviously it could be wrong, and in such as case it most likely will not retry as it most likely just closed the connection without waiting for any response.

The text about CONNACK (and indeed DISCONNECT) being optional before closing the connection is a clear statement that the Client or Server are free to close the connection at any point and for any reason without informing the other side.  Indeed the network between the two may do this as well.  To avoid problems it is commonly good to inform the other side, but doing so may in some cases be impossible, and in other cases allow a security exploit.  Even if the Sever sends a CONNACK or DISCONNECT before closing the connection, it is not guaranteed that the Client can receive it before it seeing the connection close.

I would prefer to say that a Server which sent the Retain Unavailable could optionally simply not honor the retain bit.  This is especially useful for the QoS=0 or will message case.  

If the Sever supports retain in some cases but not in others, for some topics, or if a short enough message expiration is used or not for some QoS then I presume it should not send the Retain Unavailable.  Is is still allowed to use the Retain not supported return code when it rejects a PUBLISH with the retain set?

What is the reason for saying: "If the Server rejects the CONNECT for any other reason, it MUST NOT send a RETAIN UNAVAILABLE advertisement"?  I assume this means that the Retain Unavailable may only be sent for a CONNACK with a return code of less than 128.  We have not stated this for other CONNACK id/value pairs.  

Again I strong disagree with the statement that the Server MUST NOT close the session based on getting retain on QoS>0.  I again assert that the Server is allowed to close the connection for any reason at any time.  How would you test such an imperative?


> Metadata: CONNACK Retained messages supported
> ---------------------------------------------
>
>                 Key: MQTT-301
>                 URL: https://issues.oasis-open.org/browse/MQTT-301
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: core
>    Affects Versions: 5
>            Reporter: Brian Raymor
>            Assignee: Ed Briggs
>              Labels: Proposed
>
> This was discussed in MQTT-276 with notes from the F2F meetings and has been tracked in MQTT-256. 
> I'm opening a separate, specific issue per Ken's comments - https://issues.oasis-open.org/browse/MQTT-256?focusedCommentId=62192&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-62192:
> "All of these would be defined in separate JIRAs, but what we should do in this JIRA is to define the mechanism used to pass these values."



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