On 8 February 2017 at 23:47, Christian Schudt <christian.sch...@gmx.de> wrote: > >> 1. Is this specification needed to fill gaps in the XMPP protocol stack or >> to clarify an existing protocol? > > Partly. > 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 it has. 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 dislike this. 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. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
