> 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 > 2. Does the specification solve the problem stated in the introduction and > requirements? Yes. > 3. Do you plan to implement this specification in your code? If not, why not? I don’t like the overlapping with XEP-0079. As a > 4. Do you have any security concerns related to this specification? No. > 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? 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. Do clients need the <store/> hint? Isn’t that a server policy? 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 § 8.5.2.1.1.: "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. — Christian _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
