How NL (No Local) work for retain and will

[Takatoshi Kondo <redboltz@gmail.com>]

Hi,

MQTT v5 added "No Local" option to the subscribe options.

> 3.8.3.1 Subscription Options
> Bit 2 of the Subscription Options represents the No Local option. If the value is 1, Application Messages MUST NOT be forwarded to a connection with a ClientID equal to the ClientID of the publishing connection [MQTT-3.8.3-3]. It is a Protocol Error to set the No Local bit to 1 on a Shared Subscription [MQTT-3.8.3-4].

https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901169

I considered the following three scenarios:

Scenario A: Normal publish

1. client1 subscribes topic1 with NL:1
2. client1 publishes topic1.

The published message is NOT delivered to the client1.
It's primary effect of NL flag. It's simple.

Scenario B: Will

1. client1 connects the broker with SessionExpiryInterval:infinity,
and will message (topic1, QoS2).
2. client1 subscribes topic1 with NL:1
3. client1 closes the session without sending DISCONNECT packet.4.
client1 connects the broker again with CleanStart: false.
If NL:0 at the step2, then client1 receives the will message that is
registered by itself.What happens if NL:1 ? The will message is
registered by the client1, if the NL flag care about the  will message
registereer, the message shouldn't be delivered to the clinent1. Is
this the expected behavior ?

Scenario C: Retain

1. client1 publishes topic1 retain:true.
2. client1 subscribes topic1 with NL:1 (RH: 0)

Retained packet is registered by the client1.
If NL:0, then the retained packet is delivered to the client1.
What happens if NL:1 ?
Isn't the retained packet delivered to the client1?
I think that the retained packet should be delivered to the client1
even if NL:1.
The retained packet is not strongly connected with the sender. It is a
kind of topic's status.

The spec uses "forwarded" in the following part:

"If the value is 1, Application Messages MUST NOT be forwarded to a
connection with a ClientID equal to the ClientID of the publishing
connection [MQTT-3.8.3-3]."

I think that delivering retained packet is not "forward". The retained
packet is delivered multiple times if subscribers subscribe the topic.
So the data source is broker, not the original registerer. That's why
I don't think it is "forward".

Let me sumup.

In the case NL:1

Scenario A: Not delivered
Scenario B: Not delivered (maybe)
Scenario C: Delivered

Am I understanding the spec correctly?


--
Thanks,
Takatoshi