> For example, if state gets over-ridden, but preserved, then even though it is > not doing any good, the client which installed the state must still monitor for > any related dependenecies so as to not leave incorrect pending state. > Which also means that a client has to be able to remove state it has created, > even though that state has been over-ridden. And probably has to be able > to create state which won't take effect. Which in turns means that you need > to be able to read your own effects and the current state separately.
I would think this should be a client specific implementation detail... I don't see why, from a protocol level, it should be disallowed, when the changes involved would be minor (or at least it seems to me?). :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
