My 2 cents:-

I think it depends on what someone means to achieve by doing a server restart. Some scenarios:-

• Physical Host in someone's data centre, administrator wants to try to 'fix' a broker configuration issue, so does a restart to flush configuration (eg invoke-rc.d restart x on classic init.d based systems). Probably does want to drop in-memory messages (which might be == QoS 0)

• Virtual Host in the cloud, underlying infrastructure needs patching, server stopped and restarted, end user of messaging probably shouldn't know or have to care

• Physical or Virtual Host, kernel needs patching, but there's a 5 9s SLA (uggh but true), so a quick restart is needed. So either restart doesn't cause QoS to be lost (as user shouldn't be ware) or it does (to satisfy fast restart goals, so any in-memory QoS aren't flushed to disk first).

• 9 to 5 system (a lot of trading systems run only daily), powered off at end of day, probably QoS 0 and everything else can be destroyed.

So really, it comes down to what level of g'tee a provider (ie server infrastructure + broker) (either internal datacentre, or virtuals, or cloud) interprets as QoS 0. Perhaps we should offer guidance only / use a MAY (eg, a conforming implementation MAY decide to not retain QoS 0 retained messages over server restarts).

Would an implementation be conformant if you were to ignore always RETAINED for Qos 0
i.e., pub Qos=0, Retained=1

Options:

1. Disconnect immediately
2. accept, but override to Retained=0
3. Assume it means retain for the life-cycle of the publishers connection
4. Assume it means retain for the life-cycle of the publishers session
5. Honour Retain as for Qos 1 or Qos 2 i.e., until catastrophic failure or admin intervention
6. May discard Qos 0 Retained messages at any time even where Qos 1 or Qos 2 messages survive

Take to TC all 03.10.2013

TC Approve on TC call 10.10.2013
Proposed Nick O'Leary, Seconded Rahul Gupta

fixed in WD17