Tweaked the security considerations.
Because decloaking is a presence leak (albeit intentional), an XMPP client that implements the receiving side of this specification MUST disable sharing of session presence by default and MUST enable the feature only as a result of explicit user configuration. (Gateways and other non-user entities MAY divulge their own presence and capabilities unconditionally, if that is appropriate for the service policy at the gateway.)
+Because decloaking is a presence leak (albeit intentional), an XMPP client that implements the receiving side of this specification MUST disable sharing of session presence by default and MUST enable the feature only as a result of explicit user confirmation. Such confirmation can be provided per request, at the first request per requestor, by setting some "always decloak" configuration option (e.g., globally or per domain), or through some other suitable means as long as decloaking does not occur by default. (Gateways and other non-user entities MAY divulge their own presence and capabilities unconditionally, if that is appropriate for the service policy at the gateway.)
The need for this protocol extension, and a rough proposal for solving the problem, were originally determined at XMPP Summit 5 in the summer of 2007. Thanks to Diana Cionoiu, Justin Karneges, and Justin Uberti for their input to those discussions.
+The need for this protocol extension, and a rough proposal for solving the problem, were originally determined at XMPP Summit 5 in the summer of 2007. Thanks to Diana Cionoiu, Justin Karneges, and Justin Uberti for their input to those discussions. Thanks also to Kurt Zeilenga for his feedback on the resulting specification.