Clarification of broker behaviour when client REGISTERs a PREDEFINED topic

Two Sections to update; 5.4.11 REGACK Length MsgType Flags TopicId MsgId ReturnCode (octet 0) (1) (2) (3-4) (5-6) (7) Table 15: REGACK Message The REGACK message is sent by a client or by a GW as an acknowledgment to the receipt and processing of a REGISTER message. Its format is illustrated in Table 15: Length and MsgType: see Section 5.2. Flags: – DUP: not used. – QoS: not used. – Retain: not used. – CleanSession: not used. – TopicIdType: indicates the type of information included at the end of the message, namely “0b00” topic name, “0b01” pre-defined topic id, “0b10” short topic name, and “0b11” reserved. TopicId: the value that shall be used as topic id in the PUBLISH messages; MsgId: same value as the one contained in the corresponding REGISTER message. ReturnCode: “accepted”, or rejection reason. See section 5.3.10. AND 6.5 Topic Name Registration Procedure Because of the limited bandwidth and the small message payload in wireless sensor networks, data is not published together with its topic name as in MQTT. A registration procedure is introduced which allows both a client and a GW to inform its peer about the short topic id and its corresponding topic name before it can start sending PUBLISH messages using a topicId. To register a topic name a client sends a REGISTER message to the GW. If the registration could be accepted, the gateway assigns a topicId to the received topic name and returns it with a REGACK message to the client. If the client initiates a REGISTER against a topic which is known by the gateway to have a predefined topicId associated with it, the gateway will specify its topicIdType to be predefined and set the topicId value to match this in the REGACK. The client can then choose to update its registry of predefined topicIds if it so wishes. If there are no predefined topicIds, the gateway will pass back a NORMAL alias topicIdType. If the registration could not be accepted, a REGACK is also returned to the client with the failure reason encoded in the ReturnCode field. After having received the REGACK message with ReturnCode=“accepted”, the client shall use the assigned topicId to publish data of the corresponding topic name. If however the REGACK contains a rejection code, the client may try to register later again. If the return code was “rejected: congestion”, the client should wait for a timeTWAIT beforerestartingtheregistrationprocedure. At any point in time a client may have only one REGISTER message outstanding, i.e. it has to wait for a REGACK message before it can register another topic name. A GW sends a REGISTER message to a client if it wants to inform that client about the topic name and the assigned topic id that it will use later on when sending PUBLISH messages of the corresponding topic name. This happens for example when the client re-connects without having set the “CleanSession” flag or the client has subscribed to topic names that contain wildcard characters such as # or +.