Because XML vCards (see vcard-temp (XEP-0054)
Any entity supporting this extension MUST be prepared to accept more fields than were requested, in case the target does not support this extension. A compliant target SHOULD exclude any fields listed in the filter element. In the event that the filter element does not exist or is empty, the target MUST return the entire vCard as it would without this extension.
To illustrate the functionality of this protocol, we will first request a standard vCard. As shown in XEP-0054, a user may view another user's vCard by sending an IQ of type "get" to the other user's bare JID. A compliant server MUST return the vCard to the requestor and not forward the IQ to the requestee's connected resource.
The server should then return the other user's vCard to the requestor:
A user may request that specific portions of another user's vCard be excluded by including the requested field(s) inside a filter element qualified by the 'vcard-temp-filter' namespace, inside the vCard element.
The server should then return all available fields from the other user's vCard except for those listed in the filter stanza:
This document introduces no new security concerns beyond those already involved in implementation and deployment of the 'vcard-temp' protocol.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
The XMPP Registrar
The schema for the 'vcard-temp-filter' namespace re-uses the element names from the DTD described in XEP-0054.
]]>