On Fri Apr 17 22:03:57 2009, XMPP Extensions Editor wrote:
Version 0.7 of XEP-0237 (Roster Versioning) has been released.
A couple of minor points.
1) Roster pushes sent by the server MUST be sent in order of the ver
attribute.
There's a whole horrible mess that occurs if any pushes are sent out
of order, so we'd need an alternate mechanism to signal "You have
received all pushes up to and including this sequence point".
I'm equally happy to have that distinct signal, and I'd be interested
particular by implementors of clustered servers on whether this would
be useful, as sending pushes out of sequence may reduce
synchronization between cluster nodes.
An example of a protocol doing this is ACAP, RFC 2244, which contains
an earlier form of the CONDSTORE pattern we've stolen from RFC 4551.
(See the UPDATECONTEXT command and the untagged MODTIME response).
2) There are cases where the sequence numbering can be known to have
broken, for example, if the account is destroyed and recreated, or in
the case of detectable data loss.
In these instances, a client may ask for an old sequence number which
is in fact from a previous regime, meaning it will remain out of sync.
This is not always a soluble problem - there are cases where the data
loss event is undetectable - if this is known to often be the case,
I'd advise avoiding the specification entirely.
But for those cases where it's possible to detect a data loss event,
it may be useful to signal the sequence regime change.
RFC 2244 provides no such mechanism - this isn't a tremendously good
thing, but it's hard to say how this affects real-world usage, given
there's only one ACAP server in existence, and I'm the only one who
uses it.
RFC 4551 does, obliquely, because the UIDVALIDITY of an IMAP mailbox
controls the validity of the entire mailbox, including the MODSEQ
values (as well as all content). It's my impression that many
existing mail clients ignore this value, and don't suffer much as a
result.
We can either provide some similar mechanism, or we can advise
implementors of the risk, and advise them to have an option somewhere
to "blow away the cache".
3) We borrow text from RFC 4551, which has IPR implications. To the
best of my knowledge, the text was written by Alexey Melnikov, and as
such, the copyright is owned by Isode Ltd, and Isode's default policy
WRT SDOs applies - ie, Isode will grant whatever permission, license,
disclaimer, or assignment is required.
I'll try to remember to ask Alexey for confirmation next Monday, when
he's back from holidays.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
