[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 mailing list