Details

    • Type: Improvement
    • Status: Applied
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: MQTT-SN-1.2
    • Fix Version/s: wd04
    • Component/s: MQTT-SN
    • Labels:
      None
    • Proposal:
      Hide

      Section 5.4.4 needs to be updated to allow a 0-length clientid.

      Section 6.2 should now read;

      6.2 Client’s Connection Setup
      As with MQTT, a MQTT-SN client needs to setup a connection to a GW before it can exchange information with that GW. The procedure for setting up a connection with a GW is illustrated in Fig. 3, in which it is assumed that the client requests the gateway to prompt for the transfer of Will topic and Will message. This request is indicated by setting the Will flag of the CONNECT message. The client then sends these two pieces of information to the GW upon receiving the corresponding request messages WILLTOPICREQ and WILLMSGREQ. The procedure is terminated with the CONNACK message sent by the GW.
      If Will flag is not set then the GW answers directly with a CONNACK message.

      • CONNECT PROCEDURE SEQUENCE DIAGRAM -
        Figure 3: Connect procedure

      In case the GW could not accept the connection request (e.g. because of congestion or it does not support a feature indicated in the CONNECT message), the GW returns a CONNACK message with the rejection reason.

      In the case where the client provides a zero length client identifier, the Server MUST respond with a CONNACK containing an Assigned Client Identifier. The Assigned Client Identifier MUST be a new Client Identifier not used by any other Session currently in the Server.

      Show
      Section 5.4.4 needs to be updated to allow a 0-length clientid. Section 6.2 should now read; 6.2 Client’s Connection Setup As with MQTT, a MQTT-SN client needs to setup a connection to a GW before it can exchange information with that GW. The procedure for setting up a connection with a GW is illustrated in Fig. 3, in which it is assumed that the client requests the gateway to prompt for the transfer of Will topic and Will message. This request is indicated by setting the Will flag of the CONNECT message. The client then sends these two pieces of information to the GW upon receiving the corresponding request messages WILLTOPICREQ and WILLMSGREQ. The procedure is terminated with the CONNACK message sent by the GW. If Will flag is not set then the GW answers directly with a CONNACK message. CONNECT PROCEDURE SEQUENCE DIAGRAM - Figure 3: Connect procedure In case the GW could not accept the connection request (e.g. because of congestion or it does not support a feature indicated in the CONNECT message), the GW returns a CONNACK message with the rejection reason. In the case where the client provides a zero length client identifier, the Server MUST respond with a CONNACK containing an Assigned Client Identifier. The Assigned Client Identifier MUST be a new Client Identifier not used by any other Session currently in the Server.

      Description

      The clientid variable length field is allowed to be 0-length in both MQTT 3.1.1 and 5.0, indicating that the server should assign a clientid itself. If we do allow this behaviour in MQTT-SN I think it’s important that that clientid is returned to the client, as it is in MQTT 5.0. This could be done by including the server assigned clientid in the MQTT-SN CONNACK packet, which currently has no variable length field.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                simon.johnson Simon Johnson [X] (Inactive)
                Reporter:
                ian.craggs Ian Craggs
              • Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: