From Roger Light:-

Hi,

The point that Alan raises has been mentioned before on the mqtt wiki
pages that cover specification clarification and improvement:

http://mqtt.org/wiki/doku.php/clientid_autogeneration

http://mqtt.org/wiki/doku.php/mqtt_protocol

Cheers,

Roger

Hmmm.. I understand the rationales and argument but I remain to be convinced.

Of course, brokers are very capable of generating good ids, as they (a) are written by very capable people in the main and (b) have full knowledge of the topic space and clients, etc. But it's of very little use, as the client doesn't know it unless we change the protocol... I also have concerns about re-interpreting 'empty' as a special sentinel value.

I think some of the impact of this behaviour is mitigated in situations where:-

• A client has to use credentials to authenticate, and so a broker implementation can have a manual delete (obviously not completely ideal)
• Client libraries that do generate random ids do so before connection, and pass them via the API to the connecting code to manage.
• I do like Roger's original suggestion on the MQTT wiki.

Having long-lived client ids is extremely powerful (eg tracking, logging, audit, etc), even if it is awkward for clients (eg "What is unique?" "What should I use?" "Where do I store it?") With our extended identifier size, clients are free to use MAC addresses, one-off GUIDs, hostnames, ipV6 addresses (which when link-local and without privacy extensions are effectively MACs), hostname + processname + process instance, etc. It also maps very nicely to AMQP 1-0's container-id (or link-name) concepts for implementers that might want to bridge protocols.

There are also places where a client should know its own id, anyway, even if random and for dynamic purposes, eg dynamic topics with reply-to, etc.

So, in summary, I'd support adding a non-normative comment to the spec along the lines Roger proposes.

I'm not actually proposing we consider changes like I mentioned/Roger linked to, but now seems as good a time as any to discuss them.
Why does the client always want to know its client id? You're obviously right that in the situation of server autogenerated ids there is no way currently to communicate that back to the client but there are many situations where knowing the client id just isn't necessary.

Considering a situation where you have a client side autogenerated clientid and a server side autogenerated one, practically what difference is there between them for tracking and logging purposes? For auditing purposes I would hope/imagine you would be using other authentication mechanisms the use of which is not precluded by serverside auto generated clientids.

In any application where the client needed to know it's own id the current situation of being able to specify it is still available, and a future revision that allowed a generated client id to be flowed back in the CONNACK would allow the best of both.

I'm not sure my previous comment is particularly clear at making the point I was intending. Prior to V3.1 client id was the only protocol field available to identify a client, 3.1 introducing the username and password fields. Given that (and it's explicitly allowed to connect with a username and no password) it's perhaps more appropriate to think of client id as a session id instead.
If you don't care about the persistence of your session (cleansession true) why would you care about knowing your session id?
Equally in a future revision making it session id strongly supports the case of the server autogenerating an id and communicating it back to the client.

For MQTT v3.1.1, the following proposal addresses the original concerns raised in this item. This is a non-normative comment at the end of section 3.1.3.1 Client Identifier (wd10).

I have toned down the language from Roger's original "must refuse to do so" as it depends on how such a method is exposed. For example, the Paho Java client provides a static method to generate a valid client id, returned as a String. This can then be passed to an actual client instance for use. The client instance does not know the client id was generated via the convenience method so would have no way to reject it. It would also be valid to generate a 'random' id the first time and the application stores it for future use by the client instance.
--------------------------
Non-normative:
A client implementation may provide a convenience method to randomly generate the Client Identifier. Use of such a method should be actively discouraged when the Clean Session flag is set to 0.
--------------------------

There is then a separate discussion in this thread about possible future enhancements - specifically whether a CleanSession=0 client could be allowed to provide a 0-length Client ID (and the knock-on effects of server generating on etc, reframing ClientID as SessionID). We should not let the future discussion stop us resolving the v3.1.1 part of the discussion.

I agree with the previous comment. Within the scope of the charter, we're not permitted to introduce an incompatible change, such as a special meaning for a zero-length ClientId on the CONNECT packet. I like that idea, but I think we can only go as far as the previous comment in this version of the specification.

Approved TC Meeting 12.09.2013

Added the non normative comment in section, 3.1.3.1 Client Identifier

Fixed in WD12

WD12 line 661