mirror of https://github.com/moparisthebest/xeps
0.9
This commit is contained in:
stpeter
parent
57fa0c2086
commit
04f2b7087e
511
xep-0292.xml
511
xep-0292.xml
|
|
@ -31,6 +31,12 @@
|
|||
<email>samizzi@cisco.com</email>
|
||||
<jid>samizzi@cisco.com</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.9</version>
|
||||
<date>2011-10-09</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Described how to use the vCard format for storing private data about one's contacts; added XMPP Registrar considerations.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.8</version>
|
||||
<date>2011-08-31</date>
|
||||
|
|
@ -132,169 +138,337 @@
|
|||
<p>The vCard XML format defined at the IETF specifies that the root element is <vcards/>, where the only defined child element is <vcard/>. For use in XMPP, we specify that the root element shall be <vcard/>, not <vcards/>.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IQ-Based Publication and Retrieval' anchor='iq'>
|
||||
<p>As in <cite>XEP-0054</cite>, the primary method for publishing and retrieving vCards is the XMPP &IQ; stanza.</p>
|
||||
<section2 topic='Retrieval' anchor='iq-retrieval'>
|
||||
<p>An XMPP entity retrieves the vCard of another entity (or itself) by sending an IQ-get to the target entity containing a <vcard/> child element (note the lowercase "c"!) qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace.</p>
|
||||
<example caption="vCard Retrieval Request"><![CDATA[
|
||||
<iq from='samizzi@cisco.com/foo'
|
||||
id='bx81v356'
|
||||
to='stpeter@jabber.org'
|
||||
type='get'>
|
||||
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If a vCard exists for the target entity, the responsible entity (e.g., the XMPP server that hosts the account for a bare JID) MUST return the data in an IQ-result:</p>
|
||||
<example caption="Server Returns vCard"><![CDATA[
|
||||
<iq from='stpeter@jabber.org'
|
||||
id='bx81v356'
|
||||
to='samizzi@cisco.com/foo'
|
||||
type='result'>
|
||||
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
|
||||
<fn><text>Peter Saint-Andre</text></fn>
|
||||
<n><surname>Saint-Andre</surname><given>Peter</given><middle></middle></n>
|
||||
<nickname><text>stpeter</text></nickname>
|
||||
<nickname><text>psa</text></nickname>
|
||||
<photo><uri>http://me.stpeter.im/images/stpeter_oscon.jpg</uri></photo>
|
||||
<bday><date>1966-08-06</date></bday>
|
||||
<adr>
|
||||
<parameters>
|
||||
<type><text>work</text><text>voice</text></type>
|
||||
<pref><integer>1</integer></pref>
|
||||
</parameters>
|
||||
<ext>Suite 600</ext>
|
||||
<street>1899 Wynkoop Street</street>
|
||||
<locality>Denver</locality>
|
||||
<region>CO</region>
|
||||
<code>80202</code>
|
||||
<country>USA</country>
|
||||
</adr>
|
||||
<adr>
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<ext></ext>
|
||||
<street></street>
|
||||
<locality>Denver</locality>
|
||||
<region>CO</region>
|
||||
<code>80210</code>
|
||||
<country>USA</country>
|
||||
</adr>
|
||||
<tel>
|
||||
<parameters>
|
||||
<type><text>work</text><text>voice</text></type>
|
||||
<pref><integer>1</integer></pref>
|
||||
</parameters>
|
||||
<uri>tel:+1-303-308-3282</uri>
|
||||
</tel>
|
||||
<tel>
|
||||
<parameters><type><text>work</text><text>fax</text></type></parameters>
|
||||
<uri>tel:+1-303-308-3219</uri>
|
||||
</tel>
|
||||
<tel>
|
||||
<parameters><type><text>home</text><text>voice</text></type></parameters>
|
||||
<uri>tel:+1-303-555-1212</uri>
|
||||
</tel>
|
||||
<geo><uri>geo:39.59,-105.01</uri></geo>
|
||||
<title><text>Executive Director</text></title>
|
||||
<role><text>Patron Saint</text></role>
|
||||
<org>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>XMPP Standards Foundation</text>
|
||||
</org>
|
||||
<url><uri>https://stpeter.im/</uri></url>
|
||||
<note>
|
||||
<text>
|
||||
More information about me is located on my
|
||||
personal website: https://stpeter.im/
|
||||
</text>
|
||||
</note>
|
||||
<gender><sex><text>M</text></sex></gender>
|
||||
<lang>
|
||||
<parameters><pref>1</pref></parameters>
|
||||
<language-tag>en</language-tag>
|
||||
</lang>
|
||||
<email>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>psaintan@cisco.com</text>
|
||||
</email>
|
||||
<email>
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<text>stpeter@jabber.org</text>
|
||||
</email>
|
||||
<impp>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<uri>xmpp:psaintan@cisco.com</uri>
|
||||
</impp>
|
||||
<impp>
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<uri>xmpp:stpeter@jabber.org</uri>
|
||||
</impp>
|
||||
<key>
|
||||
<uri>https://stpeter.im/stpeter.asc</uri>
|
||||
</key>
|
||||
</vcard>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If no vCard exists, the server MUST return an IQ-result containing an empty <vcard/> element.</p>
|
||||
<example caption="No vCard (empty element)"><![CDATA[
|
||||
<iq from='stpeter@jabber.org'
|
||||
id='bx81v356'
|
||||
to='samizzi@cisco.com/foo'
|
||||
type='result'>
|
||||
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<section1 topic='Self vCards' anchor='public'>
|
||||
|
||||
<p>This section describes the use of the vCard format for self-publication and retrieval of publicly-accessible information about any entity on an XMPP network, thus fulfilling all the use cases of the old vcard-temp format.</p>
|
||||
|
||||
<section2 topic='IQ-Based Publication and Retrieval' anchor='self-iq'>
|
||||
<p>As in <cite>XEP-0054</cite>, the primary method for publishing and retrieving vCards is the XMPP &IQ; stanza. (Although it would have been possible to use &xep0222; for public storage and retrieval, community consensus is that storage via IQ is more backward-compatible with <cite>XEP-0054</cite>, and that publish-subscribe is more appropriate only for event notifications.)</p>
|
||||
<section3 topic='Retrieval' anchor='self-iq-retrieval'>
|
||||
<p>An XMPP entity retrieves the vCard of another entity (or itself) by sending an IQ-get to the target entity containing a <vcard/> child element (note the lowercase "c"!) qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace.</p>
|
||||
<example caption="vCard Retrieval Request"><![CDATA[
|
||||
<iq from='samizzi@cisco.com/foo'
|
||||
id='bx81v356'
|
||||
to='stpeter@jabber.org'
|
||||
type='get'>
|
||||
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If a vCard exists for the target entity, the responsible entity (e.g., the XMPP server that hosts the account for a bare JID) MUST return the data in an IQ-result:</p>
|
||||
<example caption="Server Returns vCard"><![CDATA[
|
||||
<iq from='stpeter@jabber.org'
|
||||
id='bx81v356'
|
||||
to='samizzi@cisco.com/foo'
|
||||
type='result'>
|
||||
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
|
||||
<fn><text>Peter Saint-Andre</text></fn>
|
||||
<n><surname>Saint-Andre</surname><given>Peter</given><middle></middle></n>
|
||||
<nickname><text>stpeter</text></nickname>
|
||||
<nickname><text>psa</text></nickname>
|
||||
<photo><uri>http://me.stpeter.im/images/stpeter_oscon.jpg</uri></photo>
|
||||
<bday><date>1966-08-06</date></bday>
|
||||
<adr>
|
||||
<parameters>
|
||||
<type><text>work</text><text>voice</text></type>
|
||||
<pref><integer>1</integer></pref>
|
||||
</parameters>
|
||||
<ext>Suite 600</ext>
|
||||
<street>1899 Wynkoop Street</street>
|
||||
<locality>Denver</locality>
|
||||
<region>CO</region>
|
||||
<code>80202</code>
|
||||
<country>USA</country>
|
||||
</adr>
|
||||
<adr>
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<ext></ext>
|
||||
<street></street>
|
||||
<locality>Denver</locality>
|
||||
<region>CO</region>
|
||||
<code>80210</code>
|
||||
<country>USA</country>
|
||||
</adr>
|
||||
<tel>
|
||||
<parameters>
|
||||
<type><text>work</text><text>voice</text></type>
|
||||
<pref><integer>1</integer></pref>
|
||||
</parameters>
|
||||
<uri>tel:+1-303-308-3282</uri>
|
||||
</tel>
|
||||
<tel>
|
||||
<parameters><type><text>work</text><text>fax</text></type></parameters>
|
||||
<uri>tel:+1-303-308-3219</uri>
|
||||
</tel>
|
||||
<tel>
|
||||
<parameters><type><text>home</text><text>voice</text></type></parameters>
|
||||
<uri>tel:+1-303-555-1212</uri>
|
||||
</tel>
|
||||
<geo><uri>geo:39.59,-105.01</uri></geo>
|
||||
<title><text>Executive Director</text></title>
|
||||
<role><text>Patron Saint</text></role>
|
||||
<org>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>XMPP Standards Foundation</text>
|
||||
</org>
|
||||
<url><uri>https://stpeter.im/</uri></url>
|
||||
<note>
|
||||
<text>
|
||||
More information about me is located on my
|
||||
personal website: https://stpeter.im/
|
||||
</text>
|
||||
</note>
|
||||
<gender><sex><text>M</text></sex></gender>
|
||||
<lang>
|
||||
<parameters><pref>1</pref></parameters>
|
||||
<language-tag>en</language-tag>
|
||||
</lang>
|
||||
<email>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>psaintan@cisco.com</text>
|
||||
</email>
|
||||
<email>
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<text>stpeter@jabber.org</text>
|
||||
</email>
|
||||
<impp>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<uri>xmpp:psaintan@cisco.com</uri>
|
||||
</impp>
|
||||
<impp>
|
||||
<parameters><type><text>home</text></type></parameters>
|
||||
<uri>xmpp:stpeter@jabber.org</uri>
|
||||
</impp>
|
||||
<key>
|
||||
<uri>https://stpeter.im/stpeter.asc</uri>
|
||||
</key>
|
||||
</vcard>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If no vCard exists, the server MUST return an IQ-result containing an empty <vcard/> element.</p>
|
||||
<example caption="No vCard (empty element)"><![CDATA[
|
||||
<iq from='stpeter@jabber.org'
|
||||
id='bx81v356'
|
||||
to='samizzi@cisco.com/foo'
|
||||
type='result'>
|
||||
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Publication' anchor='self-iq-publication'>
|
||||
<p>An XMPP entity publishes or updates its vCard by sending an IQ-set to itself, containing a <vcard/> child element qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any).</p>
|
||||
<example caption="vCard Publication Request"><![CDATA[
|
||||
<iq from='stpeter@jabber.org/squire
|
||||
id='h3vz319m'
|
||||
to='stpeter@jabber.org'
|
||||
type='set'>
|
||||
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'>
|
||||
[...]
|
||||
</vcard>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If no error occurs, the responsible entity returns an IQ-result.</p>
|
||||
<example caption="Server Acknowledges Publication"><![CDATA[
|
||||
<iq from='stpeter@jabber.org'
|
||||
id='bx81v356'
|
||||
to='stpeter@jabber.org/squire'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>Note: An entity MAY have authorization to update the vCard of another entity (e.g., a server administrator might have authorization to modify the server's vCard).</p>
|
||||
</section3>
|
||||
|
||||
</section2>
|
||||
<section2 topic='Publication' anchor='iq-publication'>
|
||||
<p>An XMPP entity publishes or updates its vCard by sending an IQ-set to itself, containing a <vcard/> child element qualified by the 'urn:ietf:params:xml:ns:vcard-4.0' namespace. The publication request needs to include the entire vCard, not a "diff" against the prior data (if any).</p>
|
||||
<example caption="vCard Publication Request"><![CDATA[
|
||||
<iq from='stpeter@jabber.org/squire
|
||||
id='h3vz319m'
|
||||
to='stpeter@jabber.org'
|
||||
type='set'>
|
||||
<vcard xmlns='urn:ietf:params:xml:ns:vcard-4.0'>
|
||||
[...]
|
||||
</vcard>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If no error occurs, the responsible entity returns an IQ-result.</p>
|
||||
<example caption="Server Acknowledges Publication"><![CDATA[
|
||||
<iq from='stpeter@jabber.org'
|
||||
id='bx81v356'
|
||||
to='stpeter@jabber.org/squire'
|
||||
type='result'/>
|
||||
]]></example>
|
||||
<p>Note: An entity MAY have authorization to update the vCard of another entity (e.g., a server administrator might have authorization to modify the server's vCard).</p>
|
||||
|
||||
<section2 topic='Event Notifications' anchor='self-pubsub'>
|
||||
<p>&xep0060; provides a way to subscribe to events, and &xep0163; defines a pubsub profile for events associated with instant messaging (IM) accounts. If PEP is supported by an IM server, it can be used to automatically generate event notifications when a user's vCard is modified.</p>
|
||||
<section3 topic='Location' anchor='self-pubsub-location'>
|
||||
<p>The canonical location for notifications regarding a user's vCard is a pubsub node whose name is "urn:xmpp:vcard4".</p>
|
||||
</section3>
|
||||
<section3 topic='Subscribing to vCard Notifications' anchor='self-pubsub-subscribe'>
|
||||
<p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:
|
||||
<ol>
|
||||
<li>Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with XEP-0060, section 6.1.</li>
|
||||
<li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service may send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
|
||||
</ol>
|
||||
</p>
|
||||
</section3>
|
||||
<section3 topic='Receiving a vCard Notification'>
|
||||
<p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with XMPP clients that are not pubsub-capable (see Message Body). This is in accordance with XEP-0060, second 6.1.7.</p>
|
||||
<example caption="Receiving a vCard publication/update"><![CDATA[
|
||||
<message from='romeo@montague.lit'
|
||||
to='juliet@capulet.lit'
|
||||
type='headline'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='urn:xmpp:vcard4'>
|
||||
<item id='current'/>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='Event Notifications' anchor='pep'>
|
||||
<p>&xep0060; provides a way to subscribe to events, and &xep0163; defines a pubsub profile for events associated with instant messaging (IM) accounts. If PEP is supported by an IM server, it can be used to automatically generate event notifications when a user's vCard is modified.</p>
|
||||
<section2 topic='Location' anchor='pubsub-location'>
|
||||
<p>The canonical location for notifications regarding a user's vCard is a pubsub node whose name is "urn:xmpp:vcard4".</p>
|
||||
<section1 topic='Contact vCards' anchor='contacts'>
|
||||
|
||||
<p>In addition to enabling the publication and retrieval of vCards about any entity on an XMPP network, the vCard format can also be used to store information about an entity's contacts.</p>
|
||||
|
||||
<section2 topic='Format' anchor='contacts-format'>
|
||||
<p>A contact is simply a vCard about someone else (or something else, in the case of automated entities). If the other person or entity is in the user's roster &rfc6121;, the vCard SHOULD contain the Jabber ID of the person or entity. This enables a user to store information about the contact outside of the roster, thus obviating the need for changes or extensions to the roster namespace itself (as in &xep0145;).</p>
|
||||
<example caption="Contact"><![CDATA[
|
||||
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
|
||||
<fn><text>Samantha Mizzi</text></fn>
|
||||
<n>
|
||||
<surname>Mizzi</surname>
|
||||
<given>Samantha</given>
|
||||
<middle></middle>
|
||||
</n>
|
||||
<nickname><text>Sam</text></nickname>
|
||||
<nickname><text>samizzi</text></nickname>
|
||||
<geo><uri>geo:39.59,-105.01</uri></geo>
|
||||
<org>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>Cisco</text>
|
||||
</org>
|
||||
<note>
|
||||
<text>
|
||||
My co-author on XEP-0292. She's cool!
|
||||
</text>
|
||||
</note>
|
||||
<impp>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<uri>xmpp:samizzi@cisco.com</uri>
|
||||
</impp>
|
||||
</vcard>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Subscribing to vCard Notifications' anchor='pubsub-subscribe'>
|
||||
<p>Let us imagine that Juliet wishes to receive the updates that Romeo publishes to his vCard. She has two options:
|
||||
<ol>
|
||||
<li>Implicitly subscribe by advertising support for "urn:xmpp:vcard4+notify" in her &xep0115; data. Romeo's PEP service then automatically sends vCard updates to her when it receives presence from her, until and unless she sends presence of type unavailable or stops advertising an interest in vCard updates. This is in accordance with XEP-0060, section 6.1.</li>
|
||||
<li>Explicitly subscribe by sending a formal subscription request to the "urn:xmpp:vcard4" node at Romeo's JabberID. Romeo's PEP service may send her all vCard updates even if she is offline at the time (depending on service policies regarding presence integration).</li>
|
||||
</ol>
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Receiving a vCard Notification'>
|
||||
<p>Because Juliet has sent presence to Romeo including Entity Capabilities data that includes the "urn:xmpp:vcard4+notify" feature, Romeo's XMPP server will send a PEP notification to Juliet. The notification can include an XMPP message body for backwards-compatibility with XMPP clients that are not pubsub-capable (see Message Body). This is in accordance with XEP-0060, second 6.1.7.</p>
|
||||
<example caption="Receiving a vCard publication/update"><![CDATA[
|
||||
<message from='romeo@montague.lit'
|
||||
to='juliet@capulet.lit'
|
||||
type='headline'>
|
||||
|
||||
<section2 topic='Storage' anchor='contacts-storage'>
|
||||
<p>Because contact vCards are private information, they are best stored using &xep0223;. The canonical location is a well-known pubsub node "urn:xmpp:contacts". In accordance with <cite>XEP-0223</cite>, this node MUST have an access type of "whitelist" by default. When a client stores items at this node, it SHOULD NOT include an ItemID, so that the pubsub service can assign those identifiers.</p>
|
||||
<example caption='Storing a Contact vCard'><![CDATA[
|
||||
<iq from='stpeter@stpeter.im/squire' type='set' id='h3vs7163'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='urn:xmpp:contacts'>
|
||||
<item>
|
||||
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
|
||||
<fn><text>Samantha Mizzi</text></fn>
|
||||
<n>
|
||||
<surname>Mizzi</surname>
|
||||
<given>Samantha</given>
|
||||
<middle></middle>
|
||||
</n>
|
||||
<nickname><text>Sam</text></nickname>
|
||||
<nickname><text>samizzi</text></nickname>
|
||||
<geo><uri>geo:39.59,-105.01</uri></geo>
|
||||
<org>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>Cisco</text>
|
||||
</org>
|
||||
<note>
|
||||
<text>
|
||||
My co-author on XEP-0292. She's cool!
|
||||
</text>
|
||||
</note>
|
||||
<impp>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<uri>xmpp:samizzi@cisco.com</uri>
|
||||
</impp>
|
||||
</vcard>
|
||||
</item>
|
||||
</publish>
|
||||
<publish-options>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#publish-options</value>
|
||||
</field>
|
||||
<field var='pubsub#persist_items'>
|
||||
<value>true</value>
|
||||
</field>
|
||||
<field var='pubsub#access_model'>
|
||||
<value>whitelist</value>
|
||||
</field>
|
||||
</x>
|
||||
</publish-options>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>When a contact's vCard is stored in a private node, it is pushed out to all of the user's resources that have included in their entity capabilities (XEP-0115) data a service discovery feature of "urn:xmpp:contacts+notify" (in the following example those resources are "squire" and "roundabout").</p>
|
||||
<example caption='Publisher resources receive event notification'><![CDATA[
|
||||
<message from='stpeter@stpeter.im'
|
||||
to='stpeter@stpeter.im/squire'
|
||||
type='headline'
|
||||
id='ka92g1b5'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='urn:xmpp:vcard4'>
|
||||
<item id='current'/>
|
||||
<items node='urn:xmpp:contacts'>
|
||||
<item id='9703CC4E-CF7E-4A86-9E61-2C670235F9CB'>
|
||||
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
|
||||
<fn><text>Samantha Mizzi</text></fn>
|
||||
<n>
|
||||
<surname>Mizzi</surname>
|
||||
<given>Samantha</given>
|
||||
<middle></middle>
|
||||
</n>
|
||||
<nickname><text>Sam</text></nickname>
|
||||
<nickname><text>samizzi</text></nickname>
|
||||
<geo><uri>geo:39.59,-105.01</uri></geo>
|
||||
<org>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>Cisco</text>
|
||||
</org>
|
||||
<note>
|
||||
<text>
|
||||
My co-author on XEP-0292. She's cool!
|
||||
</text>
|
||||
</note>
|
||||
<impp>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<uri>xmpp:samizzi@cisco.com</uri>
|
||||
</impp>
|
||||
</vcard>
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
|
||||
<message from='stpeter@stpeter.im'
|
||||
to='stpeter@stpeter.im/roundabout'
|
||||
type='headline'
|
||||
id='pty14x69'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node='urn:xmpp:contacts'>
|
||||
<item id='9703CC4E-CF7E-4A86-9E61-2C670235F9CB'>
|
||||
<vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
|
||||
<fn><text>Samantha Mizzi</text></fn>
|
||||
<n>
|
||||
<surname>Mizzi</surname>
|
||||
<given>Samantha</given>
|
||||
<middle></middle>
|
||||
</n>
|
||||
<nickname><text>Sam</text></nickname>
|
||||
<nickname><text>samizzi</text></nickname>
|
||||
<geo><uri>geo:39.59,-105.01</uri></geo>
|
||||
<org>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<text>Cisco</text>
|
||||
</org>
|
||||
<note>
|
||||
<text>
|
||||
My co-author on XEP-0292. She's cool!
|
||||
</text>
|
||||
</note>
|
||||
<impp>
|
||||
<parameters><type><text>work</text></type></parameters>
|
||||
<uri>xmpp:samizzi@cisco.com</uri>
|
||||
</impp>
|
||||
</vcard>
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Note: There is no payload, because this is a pure notification (the receiver needs to retrieve the vCard using an IQ-get as described earlier.</p>
|
||||
</section2>
|
||||
|
||||
</section1>
|
||||
|
||||
<section1 topic='vCards of Automated Entities' anchor='apps'>
|
||||
|
|
@ -330,6 +504,12 @@
|
|||
<p>This document does not require interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Well-Known Service Discovery Nodes' anchor='registrar-nodes'>
|
||||
<p>The ®ISTRAR; shall include 'urn:xmpp:contact' in its registry of Nodes for Service Discovery and Publish-Subscribe at &NODES;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Mapping from vcard-temp to vCard4' anchor='mapping'>
|
||||
<p>This section provides a more detailed description of mapping vcard-temp properties to vcard4 properties.</p>
|
||||
<section2 topic='Properties Defined in vcard-temp but not in vCard3 or vCard4' anchor='mapping-temponly'>
|
||||
|
|
@ -589,7 +769,11 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
|||
<photo><uri><xsl:value-of select='EXTVAL'/></uri></photo>
|
||||
</xsl:when>
|
||||
<xsl:otherwise>
|
||||
<photo><uri><xsl:text>data:</xsl:text><xsl:value-of select='TYPE'/><xsl:text>;</xsl:text><xsl:value-of select='BINVAL'/></uri></photo>
|
||||
<photo>
|
||||
<uri>
|
||||
<xsl:text>data:</xsl:text><xsl:value-of select='TYPE'/><xsl:text>;</xsl:text><xsl:value-of select='BINVAL'/>
|
||||
</uri>
|
||||
</photo>
|
||||
</xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:for-each>
|
||||
|
|
@ -658,7 +842,10 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
|||
<logo><uri><xsl:value-of select='EXTVAL'/></uri></logo>
|
||||
</xsl:when>
|
||||
<xsl:otherwise>
|
||||
<logo><uri><xsl:text>data:</xsl:text><xsl:value-of select='TYPE'/><xsl:text>;</xsl:text><xsl:value-of select='BINVAL'/></uri></logo>
|
||||
<logo>
|
||||
<uri><xsl:text>data:</xsl:text><xsl:value-of select='TYPE'/><xsl:text>;</xsl:text><xsl:value-of select='BINVAL'/>
|
||||
</uri>
|
||||
</logo>
|
||||
</xsl:otherwise>
|
||||
</xsl:choose>
|
||||
</xsl:for-each>
|
||||
|
|
@ -735,7 +922,10 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
|||
<sound><uri><xsl:value-of select='EXTVAL'/></uri></sound>
|
||||
</xsl:when>
|
||||
<xsl:when test='$SOUND.ext=1'>
|
||||
<sound><uri><xsl:text>data:audio/basic;base64,</xsl:text><xsl:value-of select='BINVAL'/></uri></sound>
|
||||
<sound>
|
||||
<uri><xsl:text>data:audio/basic;base64,</xsl:text><xsl:value-of select='BINVAL'/>
|
||||
</uri>
|
||||
</sound>
|
||||
</xsl:when>
|
||||
<xsl:otherwise>
|
||||
</xsl:otherwise>
|
||||
|
|
@ -873,7 +1063,16 @@ OR OTHER DEALINGS IN THE SOFTWARE.
|
|||
<xsl:variable name='PREF.count' select='count(PREF)'/>
|
||||
<xsl:variable name='NUMBER.count' select='count(NUMBER)'/>
|
||||
<!-- first we count the number of vCard TYPE parameters -->
|
||||
<xsl:variable name='TYPE.count' select='$HOME.count + $WORK.count + $TEXT.count + $VOICE.count + $FAX.count + $CELL.count + $VIDEO.count + $PAGER.count + $TEXTPHONE.count'/>
|
||||
<xsl:variable name='TYPE.count'
|
||||
select='$HOME.count
|
||||
+ $WORK.count
|
||||
+ $TEXT.count
|
||||
+ $VOICE.count
|
||||
+ $FAX.count
|
||||
+ $CELL.count
|
||||
+ $VIDEO.count
|
||||
+ $PAGER.count
|
||||
+ $TEXTPHONE.count'/>
|
||||
<!-- now we output all the parameters -->
|
||||
<xsl:if test='$TYPE.count > 0'>
|
||||
<parameters>
|
||||
|
|
|
|||
Loading…
Reference in New Issue