*** Note: Data provided for fields of type "text-multi" SHOULD NOT contain any newlines (the \n and \r characters). Instead, the application SHOULD split the data into multiple strings (based on the newlines inserted by the platform), then specify each string as the XML character data of a distinct <value/> element. Similarly, an application that receives multiple <value/> elements for a field of type "text-multi" SHOULD merge the XML character data of the value elements into one text block for presentation to a user, with each string separated by a newline character as appropriate for that platform.
In some contexts (e.g., the results of a search request), it may be necessary to communicate multiple items. Therefore, a data form of type "result" MAY contain two child elements not described in the basic syntax above: one <reported/> element followed by zero or more <item/> elements. The syntax is as follows:
+In some contexts (e.g., the results of a search request), it may be necessary to communicate multiple items. Therefore, a data form of type "result" MAY contain two child elements not described in the basic syntax above:
+The syntax is as follows:
@@ -303,7 +308,7 @@
For the sake of the following examples, let us suppose that there exists a bot hosting service on the Jabber network, located at <botster.shakespeare.lit>. This service enables registered users to create and configure new bots, find and interact with existing bots, and so on. We will assume that these interactions occur using the &xep0050; protocol, which is used as a "wrapper" protocol for data forms qualified by the 'jabber:x:data' namespace. The examples in the sections that follow show most of the features of the data forms protocol described above.
- Note: Additional examples can be found in the specifications for various using protocols, such as XEP-0045: Multi-User Chat and XEP-0055: Jabber Search.
+ Note: Additional examples can be found in the specifications for various "using protocols", such as XEP-0045: Multi-User Chat and XEP-0055: Jabber Search.
The first step is for a user to create a new bot on the hosting service. We will assume that this is done by sending a "create" command to the desired bot:
Features are negotiated though the exchange of &IQ; or &MESSAGE; stanzas containing <feature/> child elements qualified by the 'http://jabber.org/protocol/feature-neg' namespace. However, this <feature/> element is simply a wrapper for structured data encapsulated in the &xep0004; protocol. Earlier versions of this document defined a structured data format to handle the feature negotiation workflow; versions later than 0.4 use Data Forms, i.e., the 'jabber:x:data' namespace.
In order to begin a negotation, the initiator sends an &IQ; stanza of type "get" (or a &MESSAGE; stanza type "normal" - see Chat Session Negotiation for examples) to the recipient with a single <feature/> element containing a data form of type "form" which defines the available options for one or more features. Each feature is represented as an x-data "field".
The recipient SHOULD examine each feature and the values of the options provided. In order to indicate preferred values, the recipient then SHOULD specify one value for each feature and return a data form of type "submit" to the initiator in an &IQ; stanza of type "result" (or a &MESSAGE; stanza type "normal").
- The following examples show some likely scenarios for feature negotiation between entities. Further examples can be found in using protocols, such as File Transfer.
+ The following examples show some likely scenarios for feature negotiation between entities. Further examples can be found in "using protocols", such as File Transfer.
A typical negotiation flow is shown in the following example of two entities negotiating the time and place for a meeting.
]]>
- The using protocol (in these examples, &xep0045;) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the ®ISTRAR;. However, the initiating entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.
+ The "using protocol" (in these examples, &xep0045;) SHOULD specify which features might be negotiable, either in the relevant documentation or in the entry for that feature in the service discovery features registry maintained by the ®ISTRAR;. However, the initiating entity MAY also query the responding entity in order to determine which features are negotiable, as shown below.
- In order for Jabber entities to adequately leverage Data Forms (e.g., by using machine-readable fields), it is RECOMMENDED to register standard x-data fields with the XMPP Registrar via the mechanisms defined in &xep0068;. Whether to do so for any given features and options shall be determined by the using protocol.
+ In order for Jabber entities to adequately leverage Data Forms (e.g., by using machine-readable fields), it is RECOMMENDED to register standard x-data fields with the XMPP Registrar via the mechanisms defined in &xep0068;. Whether to do so for any given features and options shall be determined by the "using protocol".
diff --git a/xep-0030.xml b/xep-0030.xml
index 9de9e8cea..8ad0ee166 100644
--- a/xep-0030.xml
+++ b/xep-0030.xml
@@ -473,7 +473,7 @@
It is possible that an item associated with an entity will not be addressable as a JID; examples might include offline messages stored in an inbox (see &xep0013;), entries in a Jabber-enabled weblog, XML-RPC services associated with a client or component, items available in an online trading system (e.g., a catalog or auction), news postings located at an NNTP gateway, and topics hosted by a &xep0060; component. In order to handle such items, the <item/> element MAY possess an OPTIONAL 'node' attribute that supplements the REQUIRED 'jid' attribute.
- The value of the node attribute may or may not have semantic meaning; from the perspective of Service Discovery, a node is merely something that is associated with an entity. In order to discover more about the node, the requesting entity MUST query the entity's JID while specifying the node. If the value of the 'node' attribute has semantic meaning, that meaning is provided by the using protocol or application, not by the Service Discovery protocol. A node attribute SHOULD NOT be included unless it is necessary to provide or discover information about an entity that cannot be directly addressed as a JID (i.e., if the associated item can be addressed as a JID, do not include a node). The value of the 'node' attribute MUST NOT be null.
+ The value of the node attribute may or may not have semantic meaning; from the perspective of Service Discovery, a node is merely something that is associated with an entity. In order to discover more about the node, the requesting entity MUST query the entity's JID while specifying the node. If the value of the 'node' attribute has semantic meaning, that meaning is provided by the "using protocol" or application, not by the Service Discovery protocol. A node attribute SHOULD NOT be included unless it is necessary to provide or discover information about an entity that cannot be directly addressed as a JID (i.e., if the associated item can be addressed as a JID, do not include a node). The value of the 'node' attribute MUST NOT be null.
In the following example, a user requests all available items from an online catalog service:
- A using protocol may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar maintains a registry of well-known service discovery nodes at &NODES;.
+ A "using protocol" may specify one or more service discovery nodes that have a special and well-defined meaning in the context of that protocol. For the purpose of reserving these node names globally across all Jabber protocols, the XMPP Registrar maintains a registry of well-known service discovery nodes at &NODES;.
®PROCESS;
]]>
An entity SHOULD NOT include the result set management extensions defined in this document in its requests if it does not have positive knowledge that the responding entity supports the protocol defined herein. If the responding entity does not understand result set management, it MUST ignore such extensions.
- Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given using protocol is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given using protocol is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the using protocol namespace.
+ Note: Even if a responding entity understands the result set management protocol, its support for result set management in the context of any given "using protocol" is OPTIONAL (e.g., an implementation could support it in the context of the 'jabber:iq:search' namespace but not in the context of the 'http://jabber.org/protocol/disco#items' namespace). Currently the only way for a requesting entity to determine if a responding entity supports result set management in the context of a given "using protocol" is to include result set management extensions in its request. If the responding entity does not include result set management extensions in its response, then the requesting entity SHOULD NOT include such extensions in future requests wrapped by the "using protocol" namespace.
Security considerations are the responsibility of the using ("wrapper") protocol, such as XEP-0030 for the 'http://jabber.org/protocol/disco#items' namespace, XEP-0055 for the 'jabber:iq:search' namespace, and XEP-0136 for the 'http://jabber.org/protocol/archive' namespace.
diff --git a/xep-0131.xml b/xep-0131.xml
index f3c168e8d..1bc43a148 100644
--- a/xep-0131.xml
+++ b/xep-0131.xml
@@ -242,7 +242,7 @@
However, many Internet standards use a different datetime format that ultimately derives from &rfc0822; as updated by &rfc1123;; specifically, that format is used by email (RFC 2822), the World Wide Web (RFC 2616), and the Session Initiation Protocol (RFC 3261). To map dates to and from these protocols, we define the SHIM RFC2822Date header.
- In general, security considerations are the responsibility of the using protocol.
+ In general, security considerations are the responsibility of the "using protocol".
Certain SHIM headers MAY be security-sensitive (e.g., the "Classification", "Distribute", and "Store" headers specified herein). If an entity plans to use such headers, it MUST determine whether the intended recipient supports both the SHIM protocol and the particular security-sensitive headers of interst, as described under Service Discovery; furthermore, an implementation MUST warn a human user (if any) before use if the security-sensitive headers of interest are not supported.
diff --git a/xep-0147.xml b/xep-0147.xml
index c399ca596..4b2ec898c 100644
--- a/xep-0147.xml
+++ b/xep-0147.xml
@@ -226,7 +226,7 @@ xmpp:romeo@montague.net?unsubscribe
Internationalization considerations for XMPP IRIs/URIs are specified in RFC 4622; the reader is referred to that document for a complete discussion of the relevant issues.
- Localization of application-specific data presented to a human user (e.g., as encapsulated in key-value pairs) is the responsibility of the using protocol.
+ Localization of application-specific data presented to a human user (e.g., as encapsulated in key-value pairs) is the responsibility of the "using protocol".
Security considerations for XMPP IRIs/URIs are specified in RFC 4622.
diff --git a/xep-0221.xml b/xep-0221.xml
index 4b10bcae6..abecfb32a 100644
--- a/xep-0221.xml
+++ b/xep-0221.xml
@@ -31,7 +31,7 @@
- In certain protocols that make use of &xep0004;, it can be helpful to include media data such as small images. One example of such a using protocol is &xep0158;. This document defines a method for including media data in a data form.
+ In certain protocols that make use of &xep0004;, it can be helpful to include media data such as small images. One example of such a "using protocol" is &xep0158;. This document defines a method for including media data in a data form.