Re: [mqtt-comment] How NL (No Local) work for retain and will

[Roger Light <roger@atchoo.org>]

Hi Takatoshi,

I think you've summed it up well.

My belief is that in scenario B the message is being sent as if by the
client with the will, so it should not be delivered to itself.

I also agree with you for scenario C: once the message has been set as
retained, the sender of that message in the future is the broker. Some
people disagree with this point, and believe that a retained message
should remain attached to the client that originally sent it, for the
purposes of applying access control at a later point.

Regards,

Roger

On Mon, 30 Nov 2020 at 02:51, Takatoshi Kondo <redboltz@gmail.com> wrote:
>
> 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
>
> --
> This publicly archived list offers a means to provide input to the
> OASIS Message Queuing Telemetry Transport (MQTT) TC.
>
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
>
> Subscribe: mqtt-comment-subscribe@lists.oasis-open.org
> Unsubscribe: mqtt-comment-unsubscribe@lists.oasis-open.org
> List help: mqtt-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/mqtt-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: http://www.oasis-open.org/committees/mqtt
> Join OASIS: http://www.oasis-open.org/join/
>