[Standards] XEP-0136: comments about auto save and preferences
Steven te Brinke
s.tebrinke at student.utwente.nl
Sun Jun 13 14:22:29 UTC 2010
When reading XEP-0136 I discovered some confusing properties. I will describe
these and propose changes that make them more intuitive to me. I am not sure
whether the things I propose are better than the official XEP, so let me know
what you think about it.
The auto save preference is quite confusing to me. If I am right, all
preferences are global, except the auto save preference, which can be set per
stream by using scope='stream'. The idea that it can be set per stream sounds
quite good, but the way it is done is quite strange to me:
1) The usage of scope is explained in the XEP, but the scope element is not
part of the given schema.
2) The auto element can be set as well inside as outside the pref element
without having different semantics.
3) Setting an auto with scope='stream' implies removing the auto with
Maybe number 3 is done for a specific reason, but I do not know in which use
case it is useful. Consider the following situation:
My server has archiving disabled by default and I want to archive all
messages, so I set <auto save='true' scope='global'/>. At home I use a client
with built in archiving, so I set <auto save='false' scope='stream'/> to
disable archiving for this session only. However, when I now login with any
other client, archiving is disabled because the server default is used.
(Setting auto with scope='stream' was overwriting the one with
Thus, IMO it is undesired that the setting for a stream overwrites the global
setting. Therefore I propose the following change: remove the scope attribute
from the auto element and define two separate elements: one inside the prefs
and one outside. The former should be global and the latter per stream. If
both are present, the server should use the latter. This way, no functionality
is lost and now both properties can be configured independently. Furthermore,
it makes all preferences in the prefs element global, which is more intuitive.
Regarding the streams, there is one more thing that is unclear to me. The spec
states: "Server implementations SHOULD remove all <session/> elements when
stream is closed."
However, a user can have multiple streams (e.g. by being online on multiple
PCs) and there is no definition to which stream a session element belongs. My
propose is to remove this sentence altogether, because I think it is not
really desired to have sessions removed at the end of a stream. The expiration
will remove the session when appropriate. Consider the following situation:
During a secret conversation with Bob we both turn off archiving for this
session only. For a reason unknown to me, Bob goes suddenly offline. Because I
was busy typing, I only notice this after I have send another message. This
message will be archived at Bobs side because his stream was closed before I
send the message. This is not what we desired. Only if the session element had
expired normally, the desired effect would have been achieved.
Another point are changes to preferences. These are pushed to every resource
which has retrieved the preferences before. I assume this is done to allow the
client to have an up to date view of the preferences. However, item removes
are not pushed to the clients, so clients cannot maintain an up to date view
from the pushed changes. Therefore, IMO this behaviour should be changed.
Because I do not know how clients will use this information, I cannot say in
which way it should be changed. There are many possibilities:
1) Also push removes. This adds additional complexity to the protocol, but
allows clients to stay updated with minimal overhead.
2) Always push the full settings on a change, not only the changes. Provides
the same functionality as 1 using less complexity, but more overhead.
3) Push no information about changes. Minimal overhead, but removes the
ability to stay up to date.
4) Use 3, but additionally store the settings in a pubsub node, so all
interested clients can stay up to date. Has many good properties: no overhead
when clients are not interested, less complexity in this protocol. Downside is
that in order to use it, pubsub support is required (but that will be required
for many features anyway).
Note that when sessions are expired, they can be removed from the configuration
by the server. IMO this should also be considered a change of configuration,
but at least the expected behaviour in this situation should be documented
More information about the Standards