[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-439) Issues from Boris Verkhovykh
Ken Borgendale created MQTT-439: ----------------------------------- Summary: Issues from Boris Verkhovykh Key: MQTT-439 URL: https://issues.oasis-open.org/browse/MQTT-439 Project: OASIS Message Queuing Telemetry Transport (MQTT) TC Issue Type: Bug Components: edits Affects Versions: 5, wd13 Reporter: Ken Borgendale Assignee: Ken Borgendale Priority: Minor 1. 1775 If the value of Retain As Published subscription option is set to 0, the Server MUST set the RETAIN 1776 flag to 0 when forwarding an Application Message regardless of how the RETAIN flag was set in the 1777 received PUBLISH packet [MQTT-3.3.1-12]. 1778 If the value of Retain As Published subscription option is set to 1, the Server MUST set the RETAIN 1779 flag equal to the RETAIN flag in the received PUBLISH packet [MQTT-3.3.1-13]. And it appears that [MQTT-3.3.1-12] (RaP bit == 0) contradicts the last sentence from the following chapter: 2332 3.8.3.1 Subscription Options ... 2341 Bit 3 of the Subscription Options represents the Retain As Published option. If 1, Application Messages 2342 forwarded using this subscription keep the RETAIN flag they were published with. If 0, the RETAIN flag in 2343 the PUBLISH packet indicates whether it came from a retained source or is a new publication. Or, is it different functionality for bridging? Then it should be articulated more the clearly. 2. 2332 3.8.3.1 Subscription Options ... 2337 Bit 2 of the Subscription Options represents the No Local option. If the value is 1, Application Messages 2338 MUST NOT be forwarded to a connection with a ClientId equal to the ClientId of the publishing 2339 connection [MQTT-3.8.3-3]. It is a Protocol Error to set the No Local bit to 1 on a Shared [MQTT-3.8.3-4]. I guess, the word "Subscription" is missed at the end. 3. Second, what is the rationale to prohibit the "No Local" option for Shared Subscriptions? I would see a useful scenario: client asks to pass a message to one of its peers (if they exist), while accepting similar messages from others. It may help building auto-configurable systems. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]