Hi, I'm not advocating to keep this XEP, but I think it should be deprecated or obsoleted for the right reasons (even if it is a non-normative, simple XEP as this one).
On 29 May 2017 at 16:49, Daniel Gultsch <dan...@gultsch.de> wrote: > Obsolete even due to the security implications the Security > Considerations fail to mention. > Missing documentation on security implications don't make a XEP obsolete in itself I think, but means the XEP needs to be updated. > Of those, 2. is the biggest problem, at least some implementations will > > happily send a plain-text version of their logs to any other resource > > requesting it. This sounds like a problem with the implementation (most likely because of missing documentation of the implications in the XEP). Other implementations just forward the stanza as it came in (with a different envelope). > (especially 3. depending on what gets exposed), The undocumented security consideration of this XEP was "Don't do anything a server can't do anyway". I think this still holds for all the cases (unless it's badly implemented), except indeed for Case 3. All the XEPs mentioned indeed solve many of these use cases in a much more elegant way. This is why the XEP was written as an ad-hoc protocol. That said, none of the XEPs mentioned are in Draft, so technically, it hasn't been superseded yet either. Remko
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
