soft states not guaranteed state change?

[marcoscaceres]

According to the spec, soft states are not guaranteed event delivery:

In some implementations these soft states can be skipped.

However, in the spec, these transitional states are handled by explicit API calls (e.g., hold() -> "holding"). So, I'm a bit confused as to when they can be skipped?

For consistency, it would be better if soft states were also guaranteed events and state changes. Otherwise, it could get confusing and there may be applications that write code for these states that never gets run.

[zolkis]

You are right, actually the soft states can be guaranteed. In fact, the hard states could be skipped (by network equipment, or protocol differences, etc). Implementations cannot possibly guarantee the state machine depicted there. This was a 40+ email thread some time ago. That is why the state machines should be informative, but the state space defined, with the rule that the app has to follow whatever state is reported by the network/modem/implementation.

[marcoscaceres]

Ok, that makes more sense. In the draft I have, I've consolidated states into their own section (based on text which was scattered throughout the spec before). I'm going to put together a first draft of the updated text, but really need your help to make sure it's right. Hopefully will be done on Monday, but will check in what I got so far in an hour or so.