I'd been thinking about this problem/situation and how instead it might solved on the server side. For example a client connecting with clean session false and a 0 length clientId would be saying; "I don't care about my state I just want to connect and send/receive data", in this case the server can handle either assigning it internally a guaranteed unique clientId or managing it in some other way, but the client implementation doesn't need to know/care about the details or attempt to generate a clientId it hopes will be unique.

This is probably a change beyond the scope of the charter, but as it's related to the above I figure it's worth mentioning here.

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.

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