Mickael Remond wrote: > Hello, > > I think if we have to make this change,
As far as I understand it, this is not a change, merely a clarification of something that was ambiguous in RFC 3921. > the bahviour of the client > should be stated. What does a client do with the presence it receives from its other resources? Many clients probably ignore such presence because it does not refer to items in the user's roster. > For now, a client cannot expect to gets its own > presence. Perhaps not. But it does receive presence from its other available resources. > What is the desired behaviour when it can expect to receive > its own presence ? Probably ignore it, or potentially check some box that says "yep, I'm really online now!" > What should happen if it never receive it ? First of all, don't panic. It's just an FYI. You never received this before and you shouldn't depend on receiving it now. > Should > it disconnect ? Certainly not. > Can it wait synchronously forever ? Why in the world would a client block processing while waiting for its self-presence? No clients do that now, and there is no reason for them to do so in the future. > I also seconds Rachel point: How do we stage such a change if we do > it ? Roll it out in your next release. No one is depending on it. > There are many servers and clients out there ? More every day. :) > How can we change > the standard without disrupting the production ? How you deploy a new release is up to you. Version 1.9 of your software may implement RFC 3920/3921, and version 2.0 may implement RFC 5920/5921 or whatever these I-Ds end up being. When someone upgrades to version 2.0, they magically get updated functionality (look, there's a new SASL error condition I've never seen before, etc.). As far as I can see, this self-presence "change" (clarification) is not a show-stopper in any fashion, so it's not as if you need to make special preparations, deploy new clients, or do anything else to make sure that things don't break. But feedback from client developers would be helpful. > I do not have definitive answer, but stability is also important. Indeed it is. That's why we are striving to make rfc3920bis and rfc3921bis backward-compatible with RFC 3920 and RFC 3921. I think we did a good job of that when we wrote the original RFCs, and we're not about to modify that approach now. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
