[Standards] rfc3921bis: self-presence
stpeter at stpeter.im
Wed Aug 29 21:55:01 UTC 2007
Mickael Remond wrote:
> 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
Perhaps not. But it does receive presence from its other available
> 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.
> it disconnect ?
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards