[OASIS Issue Tracker] (MQTT-614) Semantics and Treatment of Publish without Session

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

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

Ian Craggs edited comment on MQTT-614 at 2/29/24 3:54 PM:
----------------------------------------------------------

The MQTT 5.0 spec says this about QoS 0:Â

_The message is delivered according to the capabilities of the underlying network. No response is sent by the receiver and no retry is performed by the sender. The message arrives at the receiver either once or not at all._

PUBLISH WITHOUT SESSION has similar semantics but is not associated with a session and is sent to a network address (which can be multicast or broadcast). That is the entire normative behaviour on the sending side IMO.

On the broker side it says this:Â

_When a Server takes ownership of an incoming Application Message it MUST add it to the Session State for those Clients that have matching Subscriptions_

This is in the message receipt section 4.5. I think we need to have a similar section, but expanded to take account of transparent gateways which devolve responsibility to an associated MQTT connection.
 Â
 Something like, on message receipt the MQTT-SN server MUST either:

 # add it to the MQTT-SN session state for those clients with matching subscriptions, or
 # forward it to an associated MQTT session

But in the same way that an MQTT broker or MQTT-SN gateway can deny a connecting client for various reasons, as there is no connect involved in a PUBLISH WITHOUT SESSION, it can deny a PUBLISH WITHOUT SESSION if it does not reach the gateway's criteria - if there is no protection encapsulation for instance.


was (Author: icraggs1):
The MQTT 5.0 spec says this about QoS 0:Â

_The message is delivered according to the capabilities of the underlying network. No response is sent by the receiver and no retry is performed by the sender. The message arrives at the receiver either once or not at all._

PUBLISH WITHOUT SESSION has similar semantics but is not associated with a session and is sent to a network address (which can be multicast or broadcast). That is the entire normative behaviour on the sending side IMO.

On the broker side it says this:Â

_When a Server takes ownership of an incoming Application Message it MUST add it to the Session State for those Clients that have matching Subscriptions_

This is in the message receipt section 4.5. I think we need to have a similar section, but expanded to take account of transparent gateways which devolve responsibility to an associated MQTT connection.
Â
Something like, on message receipt the MQTT-SN server MUST either: # add it to the MQTT-SN session state for those clients with matching subscriptions, or
 # forward it to an associated MQTT session

But in the same way that an MQTT broker or MQTT-SN gateway can deny a connecting client for various reasons, as there is no connect involved in a PUBLISH WITHOUT SESSION, it can deny a PUBLISH WITHOUT SESSION if it does not reach the gateway's criteria - if there is no protection encapsulation for instance.

> Semantics and Treatment of Publish without Session 
> ---------------------------------------------------
>
>                 Key: MQTT-614
>                 URL: https://issues.oasis-open.org/browse/MQTT-614
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Task
>          Components: MQTT-SN
>            Reporter: Ian Craggs
>            Priority: Major
>
> Under what circumstances is it ok to drop a PUBLISH WITHOUT SESSION?
> How is it different to QoS 0?



--
This message was sent by Atlassian Jira
(v8.3.3#803004)