[Standards] LAST CALL: XEP-0334 (Message Processing Hints)

Sam Whited sam at samwhited.com
Thu Feb 9 00:35:13 UTC 2017

On Wed, Feb 8, 2017 at 5:47 PM, Christian Schudt
<christian.schudt at gmx.de> wrote:
> Aren’t namespaces with a version? I.e. urn:xmpp:hints:0 instead of urn:xmpp:hints?

Just by convention (but I agree, it might be nice to have one just in
case a hint ever has to change; although I also think that's
unlikely). That being said, it's not strictly necessary since we don't
ever need to know if a server or the client supports these hints (if
they've added them, they support it, if not, they haven't indicated
any desired behavior and we don't care if they support it or not).

> Do servers really have a distinction between a permanent and a temporar store? Aren’t offline messages usually stored permanently, too?
> If I’d develop a server message store/archive, I wouldn’t develop one for temporar messages and another one for permanent ones, but just put all messages into one database.

In at least one implementation I've worked on the permanent and
temporary stores were deliberately kept separate for scalability
reasons. All MUC history was written to a database, but recent history
(the last 75 messages or so that you'd get back when you joined a MUC)
was written both to the long term history database (although it wasn't
generally queried right away) and to a LIFO style queue in Redis
(which both never grew above the size of the MUC store, and was much
quicker to access). This way you'd get the last 75 messages or so when
you joined from the "quick" temporary store, and only if you scrolled
up or searched would it hit the larger (slower access time) database.

> Do clients need the <store/> hint? Isn’t that a server policy?

It is just that, a hint; so it's still a matter of server policy (an
the server policy may or may not take into account client preference).

> In general, I am not fully convinced by this specification.
> Clients have the burden to implement two specifications for one use case (e.g. „no store“), if they want to do it right. (0334 and 0079).
> What about other use cases that might popup in the future like „store only for 30 days“ or „drop if resource is offline“ (i.e. override RFC 6120 § 10.5.4.) or some hint to specify how to really process the message:
> RFC 6121 §
> "If there is more than one resource with a non-negative presence priority then the server MUST either (a) deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available") or (b) deliver the message to all of the non-negative resources."
> e.g. <deliver-to-highest-presence/> or <deliver-to-last-active-resource/> in case of bare JID delivery.

I generally also agree that I'm not sure how I feel about this spec. I
know theoretically multiple stores could respect the no-store hint
(eg. message-archiving and MAM), but generally I think it migh be
better if this sort of thing were defined where it lives (in the MAM
spec, or in the carbons spec, or whatever the case may be).

That being said, this is also working in production very well right
now, so I could go either way. Maybe a registry makes more sense? Or
maybe this is fine? I'm undecided.


More information about the Standards mailing list