mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 02:02:16 -05:00
Typo: metadata is one word
Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
This commit is contained in:
Maxime “pep” Buquet
parent
d1c1a358e8
commit
660ff16274
2
ref.xsl
2
ref.xsl
@ -25,7 +25,7 @@ THE SOFTWARE.
|
||||
-->
|
||||
|
||||
<!-- Author: stpeter
|
||||
Description: transforms XEP meta-data into IETF reference
|
||||
Description: transforms XEP metadata into IETF reference
|
||||
-->
|
||||
|
||||
<xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' version='1.0'>
|
||||
|
||||
16
xep-0052.xml
16
xep-0052.xml
@ -80,7 +80,7 @@
|
||||
<p>Primary Flow:</p>
|
||||
<ol>
|
||||
<li>Determine if the receiver supports FT through disco/browse. [E1]</li>
|
||||
<li>Sender sends meta-data and available methods to receiver</li>
|
||||
<li>Sender sends metadata and available methods to receiver</li>
|
||||
<li>Receiver sends the accepted method to Sender and any range/offset
|
||||
information. [E2],[E3]</li>
|
||||
<li>Sender and Receiver establish the negotiated method[E4]</li>
|
||||
@ -214,7 +214,7 @@
|
||||
<p>
|
||||
At this point the sender will setup the stream method and begin to transfer
|
||||
data. The stream itself can use the file transfer namespace to tie the
|
||||
meta-data to the actual data sent, this is illustrated below using iq:oob.
|
||||
metadata to the actual data sent, this is illustrated below using iq:oob.
|
||||
</p>
|
||||
|
||||
<example caption='Starting an iq:oob transfer'>
|
||||
@ -252,7 +252,7 @@
|
||||
</example>
|
||||
|
||||
<p>
|
||||
If the transfer does not complete, for any reason after the meta-data
|
||||
If the transfer does not complete, for any reason after the metadata
|
||||
negotiation, the party that has the error SHOULD send an error 500 and
|
||||
the file id to the other party.
|
||||
</p>
|
||||
@ -266,9 +266,9 @@
|
||||
|
||||
</section1>
|
||||
<section1 topic='Stream Relation'>
|
||||
<p>By staying in just the realm of negotiating the meta-data to a file, we allow for multiple transport layers, or streams, to be used. Some streams will need to tie the meta-data to the actual data transfer, to help accomodate this the stream may use the <file/> with an action of start and the correct id. The <file/> could be transported in the stream negotiations, or along side it. Although this spec does not mandate any specific methods to new stream authors, it does provide the syntax for the currently existing "iq:oob" system.</p>
|
||||
<p>By staying in just the realm of negotiating the metadata to a file, we allow for multiple transport layers, or streams, to be used. Some streams will need to tie the metadata to the actual data transfer, to help accomodate this the stream may use the <file/> with an action of start and the correct id. The <file/> could be transported in the stream negotiations, or along side it. Although this spec does not mandate any specific methods to new stream authors, it does provide the syntax for the currently existing "iq:oob" system.</p>
|
||||
<section2 topic='"iq:oob" Relation'>
|
||||
<p>For an "iq:oob" transfer to be related to its meta-data, a <file/> is transported along side the <query/>. The id used on the <file/> is the id for the meta-data of the actual data that is being sent. The action on the <file/> is "start". An example of this can be found in the Basic Usage section.</p>
|
||||
<p>For an "iq:oob" transfer to be related to its metadata, a <file/> is transported along side the <query/>. The id used on the <file/> is the id for the metadata of the actual data that is being sent. The action on the <file/> is "start". An example of this can be found in the Basic Usage section.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Formal Description'>
|
||||
@ -292,7 +292,7 @@
|
||||
]]></code>
|
||||
</section2>
|
||||
<section2 topic='<file/> Element'>
|
||||
<p>The <file/> element is the "workhorse" element. This element is used to convey meta-data and report file transfer actions. This elemnt contains attributes for file meta-data and actions, and MAY contain a <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/> (&xep0020;) elements.</p>
|
||||
<p>The <file/> element is the "workhorse" element. This element is used to convey metadata and report file transfer actions. This elemnt contains attributes for file metadata and actions, and MAY contain a <desc/>, a <range/>, and zero or more <feature xmlns='jabber:iq:negotiate'/> (&xep0020;) elements.</p>
|
||||
<p>The "id" attribute specifies the identifier for this particular file transfer. This attribute MUST be present at all times. There are no value requirements other than it MUST be unique between the sender and receiver.</p>
|
||||
<p>The "action" attribute specifies the action to undertake with the given file. This attribute SHOULD be present in most cases. If not present, the value "offer" is implied. The value of "action" MUST be one of the following:</p>
|
||||
<table caption='Possible "action" values'>
|
||||
@ -310,7 +310,7 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td>offer</td>
|
||||
<td>The file transfer is offered (meta-data MUST be present)</td>
|
||||
<td>The file transfer is offered (metadata MUST be present)</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>start</td>
|
||||
@ -342,7 +342,7 @@
|
||||
conditions, error codes and descriptions:</p>
|
||||
<ul>
|
||||
<li>
|
||||
<em>Declining Transfer (403)</em>: During the meta-data negotiation
|
||||
<em>Declining Transfer (403)</em>: During the metadata negotiation
|
||||
the receiver may decline the transfer by sending the 403 error. The
|
||||
<error/> CDATA MAY contain a descriptive reason why, but is not
|
||||
necessary.
|
||||
|
||||
36
xep-0060.xml
36
xep-0060.xml
@ -171,7 +171,7 @@
|
||||
<li>Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.</li>
|
||||
<li>Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.</li>
|
||||
<li>Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the <default/> element (also added the <default/> element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).</li>
|
||||
<li>Removed informational mapping of node meta-data to Dublin Core.</li>
|
||||
<li>Removed informational mapping of node metadata to Dublin Core.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
@ -256,7 +256,7 @@
|
||||
<li>Changed retrieval of default node configuration options to use <default/> element, not <configure/> element</li>
|
||||
<li>Allowed caching of last published item</li>
|
||||
<li>Added pubsub#deliver subscription option</li>
|
||||
<li>Added meta-data fields for pubsub#owners and pubsub#contact</li>
|
||||
<li>Added metadata fields for pubsub#owners and pubsub#contact</li>
|
||||
<li>Changed element for retrieval of default node configuration options from <configure/> to <default/> to prevent ambiguity related to configuration of root collection node</li>
|
||||
<li>Specified pubsub#node_type configuration field</li>
|
||||
<li>Specified pubsub#collection SHIM header</li>
|
||||
@ -285,7 +285,7 @@
|
||||
<li>Added type attribute for the <create/> and <configure/> elements to differentiate between leaf nodes and collection nodes</li>
|
||||
<li>In Section 8.1.7, changed affiliations retrieval support to SHOULD and added pubsub#retrieve-affiliations feature</li>
|
||||
<li>In Section 8.1.10, removed two duplicate examples</li>
|
||||
<li>In Section 8.1.12, clarified relationship between normal disco#info data and node meta-data (which uses a service discovery extension)</li>
|
||||
<li>In Section 8.1.12, clarified relationship between normal disco#info data and node metadata (which uses a service discovery extension)</li>
|
||||
<li>In Section 8.2.4, specified that node purgation MUST result in one event notification, not a notification per item</li>
|
||||
<li>In Section 8.1.8, further specified handling of SubIDs</li>
|
||||
<li>Clarified nature of the pubsub#type field</li>
|
||||
@ -301,7 +301,7 @@
|
||||
<version>1.6</version>
|
||||
<date>2004-07-13</date>
|
||||
<initials>pgm/psa</initials>
|
||||
<remark><p>Added service discovery features for pubsub#meta-data, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.</p></remark>
|
||||
<remark><p>Added service discovery features for pubsub#metadata, and pubsub#retrieve-items. Added pubsub#subscription_depth configuration option. Specified pubsub-specific error condition elements qualified by pubsub#errors namespace.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.5</version>
|
||||
@ -367,7 +367,7 @@
|
||||
<version>0.12</version>
|
||||
<date>2003-08-13</date>
|
||||
<initials>pgm/psa</initials>
|
||||
<remark><p>Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added meta-data about meta-nodes; fully defined XMPP Registrar considerations.</p></remark>
|
||||
<remark><p>Defined public vs. private nodes; described how changes to existing nodes might trigger meta-node events (e.g., configuration changes); changed <x/> to <event/> for #events namespace; added metadata about meta-nodes; fully defined XMPP Registrar considerations.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.11</version>
|
||||
@ -584,7 +584,7 @@ And by opposing end them?
|
||||
<li>A node MAY be configured to persist published items to some persistent storage mechanism.</li>
|
||||
<li>A node MAY be configured to persist only a limited number of items.</li>
|
||||
<li>A service MAY support collections as described in <cite>XEP-0248</cite>.</li>
|
||||
<li>A service or node MAY support extended service discovery information (meta-data).</li>
|
||||
<li>A service or node MAY support extended service discovery information (metadata).</li>
|
||||
</ul>
|
||||
|
||||
</section1>
|
||||
@ -981,7 +981,7 @@ And by opposing end them?
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Discover Node Metadata' anchor='entity-metadata'>
|
||||
<p>The "disco#info" result MAY include detailed meta-data about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#meta-data" in accordance with &xep0068;. If meta-data is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
|
||||
<p>The "disco#info" result MAY include detailed metadata about the node, encapsulated in the &xep0004; format as described in &xep0128;, where the data form context is specified by including a FORM_TYPE of "http://jabber.org/protocol/pubsub#metadata" in accordance with &xep0068;. If metadata is provided, it SHOULD include values for all configured options as well as "automatic" information such as the node creation date, a list of publishers, and the like.</p>
|
||||
<example caption='Entity queries a node for information'><![CDATA[
|
||||
<iq type='get'
|
||||
from='francisco@denmark.lit/barracks'
|
||||
@ -991,7 +991,7 @@ And by opposing end them?
|
||||
node='princely_musings'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption='Service responds with information and meta-data'><![CDATA[
|
||||
<example caption='Service responds with information and metadata'><![CDATA[
|
||||
<iq type='result'
|
||||
from='pubsub.shakespeare.lit'
|
||||
to='francisco@denmark.lit/barracks'
|
||||
@ -1002,7 +1002,7 @@ And by opposing end them?
|
||||
<feature var='http://jabber.org/protocol/pubsub'/>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#type' label='Payload type' type='text-single'>
|
||||
<value>http://www.w3.org/2005/Atom</value>
|
||||
@ -1041,7 +1041,7 @@ And by opposing end them?
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.</p>
|
||||
<p>Note: Node metadata can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node metadata SHOULD be provided as fields in the node configuration form.</p>
|
||||
<p>Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.</p>
|
||||
</section2>
|
||||
|
||||
@ -5118,8 +5118,8 @@ And by opposing end them?
|
||||
<td><link url='#affiliations'>Affiliations</link></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>meta-data</td>
|
||||
<td>Node meta-data is supported.</td>
|
||||
<td>metadata</td>
|
||||
<td>Node metadata is supported.</td>
|
||||
<td>RECOMMENDED</td>
|
||||
<td> </td>
|
||||
</tr>
|
||||
@ -6013,8 +6013,8 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
|
||||
<doc>XEP-0060</doc>
|
||||
</var>
|
||||
<var>
|
||||
<name>http://jabber.org/protocol/pubsub#meta-data</name>
|
||||
<desc>Node meta-data is supported.</desc>
|
||||
<name>http://jabber.org/protocol/pubsub#metadata</name>
|
||||
<desc>Node metadata is supported.</desc>
|
||||
<doc>XEP-0060</doc>
|
||||
</var>
|
||||
<var>
|
||||
@ -6136,7 +6136,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
|
||||
<li>Authorization of subscriptions using the 'http://jabber.org/protocol/pubsub#subscribe_authorization' namespace.</li>
|
||||
<li>Configuration of subscription options using the 'http://jabber.org/protocol/pubsub#subscribe_options' namespace.</li>
|
||||
<li>Configuration of a node using the 'http://jabber.org/protocol/pubsub#node_config' namespace.</li>
|
||||
<li>Setting of metadata information using the 'http://jabber.org/protocol/pubsub#meta-data' namespace.</li>
|
||||
<li>Setting of metadata information using the 'http://jabber.org/protocol/pubsub#metadata' namespace.</li>
|
||||
</ol>
|
||||
<p>The registry submissions associated with these namespaces are defined below.</p>
|
||||
<p>Note: There is no requirement that configuration fields need to be registered with the XMPP Registrar. However, as specified in Section 3.4 of <cite>XEP-0068</cite>, names of custom (unregistered) fields MUST begin with the characters "x-" if the form itself is scoped by a registered FORM_TYPE.</p>
|
||||
@ -6240,10 +6240,10 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
|
||||
</form_type>
|
||||
]]></code>
|
||||
</section3>
|
||||
<section3 topic='pubsub#meta-data FORM_TYPE' anchor='registrar-formtypes-metadata'>
|
||||
<section3 topic='pubsub#metadata FORM_TYPE' anchor='registrar-formtypes-metadata'>
|
||||
<code><![CDATA[
|
||||
<form_type>
|
||||
<name>http://jabber.org/protocol/pubsub#meta-data</name>
|
||||
<name>http://jabber.org/protocol/pubsub#metadata</name>
|
||||
<doc>XEP-0060</doc>
|
||||
<desc>Forms enabling setting of metadata information about pubsub nodes</desc>
|
||||
<field var='pubsub#contact'
|
||||
@ -6863,7 +6863,7 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings
|
||||
<xs:enumeration value='leased-subscription'/>
|
||||
<xs:enumeration value='manage-subscriptions'/>
|
||||
<xs:enumeration value='member-affiliation'/>
|
||||
<xs:enumeration value='meta-data'/>
|
||||
<xs:enumeration value='metadata'/>
|
||||
<xs:enumeration value='modify-affiliations'/>
|
||||
<xs:enumeration value='multi-collection'/>
|
||||
<xs:enumeration value='multi-items'/>
|
||||
|
||||
@ -60,7 +60,7 @@
|
||||
<p>The requirements this protocol fulfills are:</p>
|
||||
<ul>
|
||||
<li>Simple usage that can be easily extended</li>
|
||||
<li>Provide any meta-data necessary for using the URL</li>
|
||||
<li>Provide any metadata necessary for using the URL</li>
|
||||
<li>Compatibility with &xep0095;</li>
|
||||
</ul>
|
||||
</section1>
|
||||
|
||||
@ -7,7 +7,7 @@
|
||||
<xep>
|
||||
<header>
|
||||
<title>Tree Transfer Stream Initiation Profile</title>
|
||||
<abstract>A profile describing meta-data for transferring trees of files using stream inititation.</abstract>
|
||||
<abstract>A profile describing metadata for transferring trees of files using stream inititation.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0105</number>
|
||||
<status>Deferred</status>
|
||||
@ -41,7 +41,7 @@
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction'>
|
||||
<p>File transfers of entire trees require a lot more meta-data and prior setup to link paths to files with unique ids so that clients can track them. This profile provides a more robust method of defining that meta-data so that directory trees can be transfered.</p>
|
||||
<p>File transfers of entire trees require a lot more metadata and prior setup to link paths to files with unique ids so that clients can track them. This profile provides a more robust method of defining that metadata so that directory trees can be transfered.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements'>
|
||||
<ul>
|
||||
|
||||
18
xep-0142.xml
18
xep-0142.xml
@ -163,7 +163,7 @@ U: <queue-notifications/>
|
||||
U: </join-queue>
|
||||
U: </iq>
|
||||
]]></example>
|
||||
<p>The request may contain application-specific meta-data to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the <join-queue> element MAY contain a standard <queue-notifications/> element, which indicates that the user would like to receive user status updates about their state in the queue.</p>
|
||||
<p>The request may contain application-specific metadata to help the service determine queuing of the user or Data Forms data when submitting form information (definition of such data is out of scope for this document). In addition, the <join-queue> element MAY contain a standard <queue-notifications/> element, which indicates that the user would like to receive user status updates about their state in the queue.</p>
|
||||
<p>A successful join results in a success response:</p>
|
||||
<example caption='Response Element'><![CDATA[
|
||||
S: <iq to='user@example.net/home' from='support@workgroup.example.com' id='id1' type='result'/>
|
||||
@ -213,7 +213,7 @@ S: from='support@workgroup.example.com'
|
||||
S: to='user@example.net/home'
|
||||
S: id='id1'/>
|
||||
]]></example>
|
||||
<p>The following XML is another example where meta-data is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the <crm/> element in this example would be defined outside the context of this specification).</p>
|
||||
<p>The following XML is another example where metadata is sent by the user to assist the workgroup server in queuing and routing (naturally, the custom namespace that qualifies the <crm/> element in this example would be defined outside the context of this specification).</p>
|
||||
<example caption='Join With Meta-Data'><![CDATA[
|
||||
U: <iq type='set'
|
||||
U: from='user@example.net/home'
|
||||
@ -498,7 +498,7 @@ S: </message>
|
||||
<section1 topic='Agent Protocol' anchor='agent'>
|
||||
<section2 topic='Agent States' anchor='proto-agent-states'>
|
||||
<p>Agents join a workgroup to indicate they are capable of handling conversations with users. Agent membership in the workgroup is expected to be a long term, persistent relationship similar to roster membership. For example, a customer support agent may join the support@workgroup.example.com workgroup when they begin working at example.com and will only depart when they leave that position. The wide variety of relationships, processes and permissions associated with joining and leaving workgroups lies outside the scope of this document.</p>
|
||||
<p>Once an agent has joined a workgroup they will receive workgroup status updates to inform them of the status of other members of the workgroup. Agents are responsible for updating the workgroup service with their presence so the service can intelligently route chat requests to the 'best' agent. Workgroup agent presence uses standard XMPP presence packets with optional meta-data to help routing of chat requests to agents. Some meta-data will be standard and defined later in this document. It is expected that other deployment specific meta-data will also be needed to make routing decisions.</p>
|
||||
<p>Once an agent has joined a workgroup they will receive workgroup status updates to inform them of the status of other members of the workgroup. Agents are responsible for updating the workgroup service with their presence so the service can intelligently route chat requests to the 'best' agent. Workgroup agent presence uses standard XMPP presence packets with optional metadata to help routing of chat requests to agents. Some metadata will be standard and defined later in this document. It is expected that other deployment specific metadata will also be needed to make routing decisions.</p>
|
||||
<p>The general agent workgroup state diagram is shown below:</p>
|
||||
<code><![CDATA[
|
||||
+-----------+
|
||||
@ -546,7 +546,7 @@ Agent Service
|
||||
|----------------------------->|
|
||||
| |
|
||||
]]></example>
|
||||
<p>The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional meta-data. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.</p>
|
||||
<p>The agent must inform the workgroup of its presence by sending it a directed (not broadcast) presence update packet. Agent presence updates use standard XMPP presence with optional metadata. However, there must always be an agent-status workgroup sub-element in the presence packet to indicate that the presence update relates to agent workgroup presence. Agent workgroup presence is designed to allow a separation between the agent's normal XMPP presence (server-managed via rosters) and their presence with the workgroup.</p>
|
||||
<example caption='Presence Update'><![CDATA[
|
||||
U: <presence from='alice@example.com/work' to='support@workgroup.example.com'>
|
||||
U: <agent-status xmlns='http://jabber.org/protocol/workgroup'>
|
||||
@ -561,7 +561,7 @@ U: </presence>
|
||||
<li>xa - The agent is physically away from their terminal and should not have a chat routed to them.</li>
|
||||
<li>dnd - The agent is busy and should not be disturbed. However, special case, or extreme urgency chats may still be offered to the agent although offer rejection or offer timeouts are highly likely.</li>
|
||||
</ul>
|
||||
<p>Agents MAY also embed meta-data to help the workgroup service route chat requests, using the <max-chats> element, which specifies the maximum number of chats the agent can handle. If a presence is sent to the workgroup that does not contain the max-chats value, the "default setting" will be assumed. The value of the default setting for an agent is up to an implementation. <note>The max-chats value sent from agent to workgroup service is a 'hint' or recommended value. The workgroup service is not obliged to accept this value. The actual max-chats value for the agent will be sent to the agent via the next Agent Status Update. This allows administrators to constrain agent behavior in order to enforce company policy, quality assurance, etc.</note></p>
|
||||
<p>Agents MAY also embed metadata to help the workgroup service route chat requests, using the <max-chats> element, which specifies the maximum number of chats the agent can handle. If a presence is sent to the workgroup that does not contain the max-chats value, the "default setting" will be assumed. The value of the default setting for an agent is up to an implementation. <note>The max-chats value sent from agent to workgroup service is a 'hint' or recommended value. The workgroup service is not obliged to accept this value. The actual max-chats value for the agent will be sent to the agent via the next Agent Status Update. This allows administrators to constrain agent behavior in order to enforce company policy, quality assurance, etc.</note></p>
|
||||
<section4 topic='Error Conditions' anchor='proto-agent-presence-errors'>
|
||||
<p>There are no defined error conditions for presence updates.</p>
|
||||
</section4>
|
||||
@ -750,7 +750,7 @@ S: <timeout>seconds</timeout>
|
||||
S: </offer>
|
||||
S: </iq>
|
||||
]]></example>
|
||||
<p>Application specific meta-data will normally be added as a sub-element of <offer> to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional <timeout> sub-element may be included indicating the amount of time the offer stands before the service will revoke it.</p>
|
||||
<p>Application specific metadata will normally be added as a sub-element of <offer> to help agents decide whether to accept or not (formats for which are out of scope for this document). An optional <timeout> sub-element may be included indicating the amount of time the offer stands before the service will revoke it.</p>
|
||||
<example caption='Offer Response'><![CDATA[
|
||||
A: <iq from='alice@example.com/work' to='support@workgroup.example.com' id='id1' type='result'/>
|
||||
]]></example>
|
||||
@ -773,7 +773,7 @@ A: from='alice@example.com/work'
|
||||
A: id='id1'
|
||||
A: type='result'/>
|
||||
]]></example>
|
||||
<p>The following is a more typical offer containing meta-data about the user. The offer will be revoked in 30 seconds.</p>
|
||||
<p>The following is a more typical offer containing metadata about the user. The offer will be revoked in 30 seconds.</p>
|
||||
<example caption='Offer Including Meta-Data'><![CDATA[
|
||||
S: <iq to='alice@example.com/work'
|
||||
S: from='support@workgroup.example.com'
|
||||
@ -893,7 +893,7 @@ Agent Service
|
||||
| |
|
||||
]]></example>
|
||||
<p>The server sends an invitation to the agent to begin their conversation with the user, structured according to the format defined in <cite>XEP-0045</cite>. The 'from' attribute of the <invite/> element MUST be set to the JID of the workgroup.</p>
|
||||
<p>In order to match invitations to offers, all invitations SHOULD include meta-data in the <offer/> element, with the JID of the user specified via the 'jid' attribute. The typical meta-data fragment would appear as:</p>
|
||||
<p>In order to match invitations to offers, all invitations SHOULD include metadata in the <offer/> element, with the JID of the user specified via the 'jid' attribute. The typical metadata fragment would appear as:</p>
|
||||
<example caption='Invitation Meta-Data'><![CDATA[
|
||||
<offer xmlns='http://jabber.org/protocol/workgroup' jid='user@example.net/home'>
|
||||
]]></example>
|
||||
@ -927,7 +927,7 @@ S: </message>
|
||||
<li>Use the <identity> type='workgroup'.</li>
|
||||
<li>Use the <feature> var='http://jabber.org/protocol/workgroup'.</li>
|
||||
</ul>
|
||||
<p>An example of discovery browsing is included. Notice how probing starts at the server (example.com) revealing the workgroup service by its JID (workgroup.example.com) and a simple, human friendly name ("Example.com Live Assistant"). It is only during the discovery probing of the service that it is identified as a workgroup using the <identity> and <feature> tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the <identity> and <feature> tags are again presented to identify them as workgroups along with (optional) associated meta-data.</p>
|
||||
<p>An example of discovery browsing is included. Notice how probing starts at the server (example.com) revealing the workgroup service by its JID (workgroup.example.com) and a simple, human friendly name ("Example.com Live Assistant"). It is only during the discovery probing of the service that it is identified as a workgroup using the <identity> and <feature> tags. Finally individual workgroups (support and sales) can be discovered on the Workgroup service. When individual workgroups are probed, the <identity> and <feature> tags are again presented to identify them as workgroups along with (optional) associated metadata.</p>
|
||||
<example caption='Workgroup Service Discovery'><![CDATA[
|
||||
U: <iq to='example.com' from='user@example.net/home' id='id1' type='get'>
|
||||
U: <query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
|
||||
10
xep-0214.xml
10
xep-0214.xml
@ -127,7 +127,7 @@
|
||||
<configure node='juliets_sonnets'/>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#title'><value>Juliet's Sonnets</value></field>
|
||||
<field var='pubsub#description'><value>Optional Description</value></field>
|
||||
@ -163,7 +163,7 @@
|
||||
<configure node='35227eec194a4f3971a5f3771e9c2271'/>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#title'><value>Sonnets About Romeo</value></field>
|
||||
<field var='pubsub#description'><value>Optional Description</value></field>
|
||||
@ -218,7 +218,7 @@
|
||||
<configure node='a6190c5d38e22452041d1c5798eff3f5'>
|
||||
<x xmlns='jabber:x:data' type='submit'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#title'><value>sonnet.txt</value></field>
|
||||
<field var='pubsub#description'><value>Sonnet 42</value></field>
|
||||
@ -234,7 +234,7 @@
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='a6190c5d38e22452041d1c5798eff3f5'>
|
||||
<item id='1'>
|
||||
<entry xmlns='http://jabber.org/protocol/fileshare#item_meta-data'>
|
||||
<entry xmlns='http://jabber.org/protocol/fileshare#item_metadata'>
|
||||
<size>5623</size>
|
||||
<modified>2006-12-13T18:30:02Z</modified>
|
||||
<checksum type="sha1">59282c5db190bdc3b152c5b38363442bfda8ebdd</checksum>
|
||||
@ -332,7 +332,7 @@
|
||||
<configuration node='a6190c5d38e22452041d1c5798eff3f5'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#description'><var>Sonnet 42</var></field>
|
||||
<field var='pubsub#title'><var>sonnet.txt</var></field>
|
||||
|
||||
@ -248,7 +248,7 @@
|
||||
]]></example>
|
||||
|
||||
<section4 topic='Including Node Meta-Data' anchor='notify-metadata'>
|
||||
<p>The notification event MAY also include the node meta-data, formatted using the &xep0004; protocol.</p>
|
||||
<p>The notification event MAY also include the node metadata, formatted using the &xep0004; protocol.</p>
|
||||
|
||||
<example caption='Notification of node association'><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit'
|
||||
@ -259,7 +259,7 @@
|
||||
<associate node='new-node-id'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
<value>http://jabber.org/protocol/pubsub#meta-data</value>
|
||||
<value>http://jabber.org/protocol/pubsub#metadata</value>
|
||||
</field>
|
||||
<field var='pubsub#creation_date'>
|
||||
<value>2003-07-29T22:56Z</value>
|
||||
|
||||
14
xep-0258.xml
14
xep-0258.xml
@ -16,8 +16,8 @@
|
||||
<header>
|
||||
<title>Security Labels in XMPP</title>
|
||||
<abstract>This document describes the use of security labels in XMPP. The document specifies
|
||||
how security label meta-data is carried in XMPP, when this meta-data should or should
|
||||
not be provided, and how the meta-data is to be processed.</abstract> &LEGALNOTICE;
|
||||
how security label metadata is carried in XMPP, when this metadata should or should
|
||||
not be provided, and how the metadata is to be processed.</abstract> &LEGALNOTICE;
|
||||
<number>0258</number>
|
||||
<status>Draft</status>
|
||||
<type>Standards Track</type>
|
||||
@ -167,7 +167,7 @@
|
||||
standardized formats for security labels, clearances, and security policy are
|
||||
generalized and do have application in non-government networks.</p>
|
||||
<p>This document describes the use of security labels in &xmpp;. The document specifies how
|
||||
security label meta-data is carried in XMPP. It standardizes a mechanism for carrying
|
||||
security label metadata is carried in XMPP. It standardizes a mechanism for carrying
|
||||
ESS Security Labels in XMPP, as well as provides for use of other label formats. ESS
|
||||
Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in
|
||||
conjunction with &X.500; clearances and either X.841 or &SDN.801c; security
|
||||
@ -195,8 +195,8 @@
|
||||
]]></example>
|
||||
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
|
||||
|
||||
<p>The document details when security label meta-data should or should not be provided, and
|
||||
how this meta-data is to be processed.</p>
|
||||
<p>The document details when security label metadata should or should not be provided, and
|
||||
how this metadata is to be processed.</p>
|
||||
|
||||
<p>This document does not provide:</p>
|
||||
<ul>
|
||||
@ -248,7 +248,7 @@
|
||||
</section1>
|
||||
|
||||
<section1 topic="Protocol" anchor="protocol">
|
||||
<p>An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data
|
||||
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
|
||||
includes a security label, zero or more equivalent security labels, and optionally
|
||||
display marking data.</p>
|
||||
<example caption="Labeled Message"><![CDATA[
|
||||
@ -267,7 +267,7 @@
|
||||
</securitylabel>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The security label meta-data is carried in an &SECURITYLABEL; element. The
|
||||
<p>The security label metadata is carried in an &SECURITYLABEL; element. The
|
||||
&SECURITYLABEL; element which contains one and only one &LABEL; element, zero or more
|
||||
&EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
|
||||
<p>The &LABEL; provides the primary security label. It is commonly issued by the sender
|
||||
|
||||
@ -430,7 +430,7 @@
|
||||
<p>Sessions may be established either at the request of the Rayo client (an outbound call) or as a result of a 3rd party request (an inbound call). Each scenario differs in the Rayo protocol only up to the point at which the session is established and media begins to flow. First we shall examine the sequence of stanzas passed between server and client in each of these scenarios.</p>
|
||||
|
||||
<section3 topic='Outbound Call' anchor='session-establishment-outbound'>
|
||||
<p>In order for a client to establish a new outbound call, it MUST first send a <link url="#def-dial">dial command</link> to the server, indicating the proposed target for the call, its apparent source, and any meta-data to send to the target as headers.</p>
|
||||
<p>In order for a client to establish a new outbound call, it MUST first send a <link url="#def-dial">dial command</link> to the server, indicating the proposed target for the call, its apparent source, and any metadata to send to the target as headers.</p>
|
||||
|
||||
<example caption="Client requests establishment of a new outbound session"><![CDATA[
|
||||
<iq from='juliet@capulet.lit/balcony'
|
||||
@ -1778,7 +1778,7 @@
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>The server MUST present the recording for consumption by the client by way of recording meta-data on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration & size data as specified on the <link url='#def-component-record-recording'>recording element</link>.</p>
|
||||
<p>The server MUST present the recording for consumption by the client by way of recording metadata on the complete reason, including a URI at which the recording may be fetched. It MUST provide uri, duration & size data as specified on the <link url='#def-component-record-recording'>recording element</link>.</p>
|
||||
<example caption="Component indicates it has completed due to being stopped, providing the recording"><![CDATA[
|
||||
<presence from='9f00061@call.shakespeare.lit/eh3u28'
|
||||
to='juliet@capulet.lit/courtyard'
|
||||
@ -3620,7 +3620,7 @@ Art thou not Romeo, and a Montague?
|
||||
<any minOccurs="0" maxOccurs="unbounded">
|
||||
<annotation>
|
||||
<documentation>
|
||||
May be any component specific meta-data elements, such as <recording>.
|
||||
May be any component specific metadata elements, such as <recording>.
|
||||
</documentation>
|
||||
</annotation>
|
||||
</any>
|
||||
|
||||
@ -87,7 +87,7 @@
|
||||
<section3 topic='Completion' anchor='session-receiving-completion'>
|
||||
<p>The receivefax completion reason MUST be one of the <link url='#def-components-complete-reason'>core Rayo reasons</link> or <link url='#def-finish'>finish</link> (indicating that the document was fully received). Receivefax component completion provides a fax element only when a document was successfully received.</p>
|
||||
|
||||
<p>The server MUST present the fax for consumption by the client by way of fax meta-data on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size & page count data as specified on the <link url='#def-fax'>fax element</link>. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.</p>
|
||||
<p>The server MUST present the fax for consumption by the client by way of fax metadata on the complete reason, including a URI at which the document may be fetched. It MUST provide url, resolution, file size & page count data as specified on the <link url='#def-fax'>fax element</link>. In cases of partial receipt of a fax, a fax element MAY be returned in addition to the error completion reason.</p>
|
||||
<example caption="Component indicates it has completed due to being finished, providing the fax"><![CDATA[
|
||||
<presence from='9f00061@call.shakespeare.lit/eh3u28'
|
||||
to='juliet@capulet.lit/courtyard'
|
||||
|
||||
@ -68,7 +68,7 @@
|
||||
<initials>pw</initials>
|
||||
<remark>
|
||||
<p>
|
||||
Added the possibility for <link url='#ownerupdate'>owners to update meta-data about its things</link>.
|
||||
Added the possibility for <link url='#ownerupdate'>owners to update metadata about its things</link>.
|
||||
This is done through the optional attribute <strong>jid</strong> on the <strong>update</strong> element.
|
||||
</p>
|
||||
<p>Added <strong>ROOM</strong> to the <link url='#tags'>list of predefined tag names</link>.</p>
|
||||
@ -1134,7 +1134,7 @@
|
||||
</section2>
|
||||
<section2 topic='Owner updating Meta Information about Thing in Registry' anchor='ownerupdate'>
|
||||
<p>
|
||||
An owner of a thing can also update the meta-data of a thing it has claimed. To do this, you simply add a <strong>jid</strong> attribute containing the JID of the thing to the
|
||||
An owner of a thing can also update the metadata of a thing it has claimed. To do this, you simply add a <strong>jid</strong> attribute containing the JID of the thing to the
|
||||
<strong>update</strong> element. (If this attribute is not present, the JID is assumed to be that of the sender of the message.)
|
||||
</p>
|
||||
<example caption='Owner requests an update of Meta Data of Thing'>
|
||||
@ -1157,7 +1157,7 @@
|
||||
</iq>]]>
|
||||
</example>
|
||||
<p>
|
||||
The owner can update meta-data of things behind concentrators also. To do this, the corresponding attributes <strong>nodeId</strong>, <strong>sourceId</strong>
|
||||
The owner can update metadata of things behind concentrators also. To do this, the corresponding attributes <strong>nodeId</strong>, <strong>sourceId</strong>
|
||||
and <strong>cacheType</strong> must be used to identify the thing, as follows:
|
||||
</p>
|
||||
<example caption='Owner requests an update of Meta Data of Thing behind concentrator'>
|
||||
@ -1895,7 +1895,7 @@
|
||||
<section2 topic='External services for creating QR-codes' anchor='externalqr'>
|
||||
<p>
|
||||
If using external services when creating QR-codes, like the Google Charts API used in this document, make sure HTTPS is used and certificates validated. If HTTP is used,
|
||||
meta-data tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices.
|
||||
metadata tags used in Thing Registry registrations can be found out by sniffing the network, making it possible to hijack the corresponding devices.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='DHCP Security Considerations' anchor='dhcpsec'>
|
||||
|
||||
@ -165,7 +165,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
|
||||
<ol>
|
||||
<li><strong>XSF:</strong> a central place would provide a common ground
|
||||
for a curated client list and ensure long-term availability. However,
|
||||
the operator would be able to collect meta-data and abuse authentication tokens.</li>
|
||||
the operator would be able to collect metadata and abuse authentication tokens.</li>
|
||||
<li><strong>Client developer:</strong> the developer of Romeo's client can
|
||||
provide a landing page for invitation requests created with this
|
||||
client. This is a feasible short-term solution and allows to recommend
|
||||
@ -175,7 +175,7 @@ xmpp:romeo@montague.net?roster;preauth=1tMFqYDdKhfe2pwp;name=Romeo+Montague
|
||||
down, invitation links created with the client will cease working.</li>
|
||||
<li><strong>User's server:</strong> this is the optimal long-term
|
||||
solution, as the user's server is already entrusted with the relevant
|
||||
meta-data and will exist at least as long as the user's account on that
|
||||
metadata and will exist at least as long as the user's account on that
|
||||
server. However, this requires an additional server component to query
|
||||
for invitation URIs and a web server hosting the landing page.
|
||||
Furthermore, the server operator needs to maintain the list of
|
||||
|
||||
Loading…
Reference in New Issue
Block a user