[Standards] LAST CALL: XEP-0334 (Message Processing Hints)
mwild1 at gmail.com
Thu Feb 23 12:52:11 UTC 2017
On 8 February 2017 at 23:47, Christian Schudt <christian.schudt at gmx.de> wrote:
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
> XEP-0079: Advanced Message Processing already solves the same problem.
> drop forward => no-copy
> drop stored => no-store
Maybe the document should go into more detail regarding differences
with AMP. Some notes:
- You can implement both specifications if desired
- Over 10 years after publication, XEP-0079 is not widely
implemented, I believe this is largely due to its complexity
- XEP-0079 requires multiple discovery steps before you can actually
send a message
- XEP-0079 is relatively difficult to re-use in other XEPs
- Lots of edge cases, e.g. interaction with MUC rooms. With hints the
server is still free to choose the most sensible option given the info
Hints are not about time restrictions, tracking, or anything like
that. It's just about giving the server some idea of the "kind" of
message it is processing, so it can make informed decisions. If you
need more than this, you still need AMP.
>> 3. Do you plan to implement this specification in your code? If not, why not?
> I don’t like the overlapping with XEP-0079.
I'm guessing you already implement XEP-0079, and I hear you. However
if implementation of XEP-0280 and XEP-0313 depended on XEP-0079
instead of a simple semantic tag, I'm sure other developers would also
Such situations are always going to happen in such a diverse protocol.
And I think this is one of the smallest examples of that. The good
thing here is that the two protocols are not mutually exclusive, and
you can implement both. What's not covered in that case is what would
happen if you did something like include <store/> with AMP's
drop-stored. In such cases I would say that AMP would always have the
final say. Maybe this is worth including in the XEP?
>> 5. Is the specification accurate and clearly written?
> Aren’t namespaces with a version? I.e. urn:xmpp:hints:0 instead of urn:xmpp:hints?
I'm neutral about this. A namespace is just an opaque string, so I
don't see the harm in starting without a version and adding a version
suffix if/when we need to. However I've been shot down by the editor
team for this before, and I'm fine with that. I probably wouldn't
agree to just updating it now though if the only reason is aesthetics.
> 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.
With most servers going to be archiving nowadays, it looks this way,
yes. The line between "temporary" and "permanent" is blurry,
> Do clients need the <store/> hint? Isn’t that a server policy?
A use for this would be for messages without a <body> element, which
contain an encrypted payload that is still useful to the recipient
outside the current session (OMEMO falls into this category). Lack of
a <body> might typically cause a server to classify a message as some
kind of ephemeral notification, and not part of an IM conversation.
> 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).
I don't quite see it this way. If you want to be *certain* than your
message will not be stored (of course if you trust the remote entity
not to lie), you need to use XEP-0079, discover support, and not send
your message unless it supports XEP-0079 with the right
conditions/actions that you need.
If you're happy to send the message anyway, but you want archiving
entities along the path to know that you consider the message
worthless if stored, you can just use a hint.
> 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:
Absolutely out of scope, use AMP.
More information about the Standards