Re: rfc3921bis: self-presence

Hello,

I think if we have to make this change, the bahviour of the
client should be stated. For now, a client cannot expect to
gets its own presence.
What is the desired behaviour when it can expect to receive
its own presence ? What should happen if it never receive it
? Should it disconnect ? Can it wait synchronously forever
?

I also seconds Rachel point: How do we stage such a change
if we do it ? There are many servers and clients out there ?
How can we change the standard without disrupting the
production ?

I do not have definitive answer, but stability is also
important.

--
Mickael Rémond

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/