The current plan is to move SHA-1 to a SHOULD NOT, SHA-256, SHA3-256 and BLAKE2b256 to MUST, and SHA-512, SHA3-512, and BLAKE2b512 to SHOULD by the end of 2016.
These recommendations ought to be reviewed yearly by the &COUNCIL;.
-http://dx.doi.org/10.6028/NIST.FIPS.202 +If an entity supports the protocol defined herein, it MUST report that by including a &xep0030; feature of "urn:xmpp:hashes:1" in response to disco#info requests, along with one service discovery feature for each algorithm it supports:
Real-time text is transmitted via an <rtt/> child element of a <message/> stanza. The <rtt/> element is transmitted at regular intervals by the sender client while a message is being composed. This allows the recipient to see the latest message text from the sender, without waiting for the full message to be sent in a <body/> element.
This is a basic example of a real-time message "Hello, my Juliet!” transmitted in real-time while it is being typed, before a final message delivery in a <body/> element (to remain Backwards Compatible):
Example 1: Introductory Example
-
+
The <rtt/> element contains one or more child elements that represent Real-Time Text Actions such as text being appended, inserted, or deleted. Example 1 illustrates only the <t/> action element, which appends text to the end of a message.
Transmission of the <rtt/> element occurs at a regular Transmission Interval whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs.
There MUST NOT be more than one <rtt/> element per <message/> stanza.
@@ -290,22 +288,24 @@Initialize a new real-time message: <rtt event="new"/> and <rtt event="reset"/>
- Sender clients MUST use an <rtt/> element containing either event="new" or event="reset" in the first transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all Action Elements (e.g., text insertions and deletions) included within the <rtt/> element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e., cleared prior to immediately processing action elements).
Both <rtt event="new"/> and <rtt event="reset"/> are logically identical to recipients, except for presentation:
- For recipients, these differ only for optional presentation purposes (e.g., highlighting newly started incoming messages). Senders SHOULD use event="new" when sending the first text of a new message (e.g., the first key presses), and only use event="reset" when doing Message Refresh or Simple Real-Time Text. See Keeping Real-Time Text Synchronized.
Sending modifications of a real-time message: Outgoing <rtt event="edit"/> or <rtt/>
Sender clients SHOULD transmit this element at a regular Transmission Interval while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See Sending Real-Time Text.
Receiving modifications of a real-time message: Incoming <rtt event="edit"/> or <rtt/>
Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received <rtt/> elements from the same sender. If 'seq' increments as expected, the Action Elements (e.g., text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if 'seq' does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via event="new" or event="reset". See Keeping Real-Time Text Synchronized.
Committing a real-time message: Delivery of a <body/> element
- A real-time message is considered complete upon receiving <body/>. See Body Element.
Starting real-time text: <rtt event="init"/>
- Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The 'seq' attribute is ignored by recipient clients. See Guidelines for Initiating Real-Time Text.
Ending real-time text: <rtt event="cancel"/>
- Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-to-one chat session (until event="init" is used again), and handle any unfinished real-time messages appropriately (e.g., clearing or saving the message). The 'seq' attribute is ignored by recipient clients. See Guidelines for Initiating Real-Time Text.
Starting value for seq attribute:
- Sender clients MAY use any new starting value for 'seq' when initializing a real-time message using event="new" or event="reset". Recipient clients receiving such elements MUST use this 'seq' value as the new starting value. A random starting value is RECOMMENDED to improve reliability of Keeping Real-Time Text Synchronized during Usage with Multi-User Chat and Simultaneous Logins.
Initialize a new real-time message: <rtt event="new"/> and <rtt event="reset"/>
+Sender clients MUST use an <rtt/> element containing either event="new" or event="reset" in the first transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all Action Elements (e.g., text insertions and deletions) included within the <rtt/> element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e., cleared prior to immediately processing action elements).
Both <rtt event="new"/> and <rtt event="reset"/> are logically identical to recipients, except for presentation:
+For recipients, these differ only for optional presentation purposes (e.g., highlighting newly started incoming messages). Senders SHOULD use event="new" when sending the first text of a new message (e.g., the first key presses), and only use event="reset" when doing Message Refresh or Simple Real-Time Text. See Keeping Real-Time Text Synchronized.
Sending modifications of a real-time message: Outgoing <rtt event="edit"/> or <rtt/>
+Sender clients SHOULD transmit this element at a regular Transmission Interval while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See Sending Real-Time Text.
Receiving modifications of a real-time message: Incoming <rtt event="edit"/> or <rtt/>
+Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received <rtt/> elements from the same sender. If 'seq' increments as expected, the Action Elements (e.g., text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if 'seq' does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via event="new" or event="reset". See Keeping Real-Time Text Synchronized.
Committing a real-time message: Delivery of a <body/> element
+A real-time message is considered complete upon receiving <body/>. See Body Element.
Starting real-time text: <rtt event="init"/>
+Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The 'seq' attribute is ignored by recipient clients. See Guidelines for Initiating Real-Time Text.
Ending real-time text: <rtt event="cancel"/>
+Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-to-one chat session (until event="init" is used again), and handle any unfinished real-time messages appropriately (e.g., clearing or saving the message). The 'seq' attribute is ignored by recipient clients. See Guidelines for Initiating Real-Time Text.
Starting value for seq attribute:
+Sender clients MAY use any new starting value for 'seq' when initializing a real-time message using event="new" or event="reset". Recipient clients receiving such elements MUST use this 'seq' value as the new starting value. A random starting value is RECOMMENDED to improve reliability of Keeping Real-Time Text Synchronized during Usage with Multi-User Chat and Simultaneous Logins.
The real-time message is considered complete upon receipt of a standard <body/> element (as qualified by the 'jabber:client' namespace in &xmppim;). The delivered text within <body/> is considered the final message text, and supersedes the real-time message. In the ideal case, the text within <body/> is redundant since it is identical to the final contents of the real-time message.
@@ -375,10 +375,10 @@Supports the transmission of text, including key presses, and text block inserts.
Note: Text can be any subset of text allowed in the <body/> element of a <message/>. If <t/> is empty or blank, no text modification takes place.
text]]>
text]]>
Append specified text at the end of message. ('p' defaults to message length).
Note: This action element is the minimum support REQUIRED for sender clients (i.e., speech transcription, chat bots, and Simple Real-Time Text are still possible without supporting additional action elements).
text]]>
text]]>
Inserts specified text at position 'p' in the message text.
@@ -387,18 +387,18 @@Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the backspace key, the delete key, and text block deletes.
Note: Excess backspaces MUST be ignored by the receiving client. Thus, text is backspaced only to the beginning of the message, in situations where n is larger than p.
]]>
]]>
Remove 1 character from end of message. ('n' defaults to “1”, and 'p' defaults to message length)
-]]>
]]>
Remove 1 character before character position 'p' in message. ('n' defaults to “1”)
-]]>
]]>
Remove 'n' characters from end of message. ('p' defaults to message length)
-]]>
]]>
Remove 'n' characters before character position 'p' in message.
Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See Preserving Key Press Intervals.
-]]>
]]>
Wait 'n' milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large 'n' values that exceed the average Transmission Interval. Recipient clients MAY selectively shorten or ignore the pauses ('n') in <w/> action elements to avoid lag in a chat session. Situations such as network congestion can result in a surge of <w/> elements where the total of pauses exceeds a transmission interval cycle. See Receiving Real-Time Text.
A message refresh is the sender's partially composed text being (re)transmitted via <rtt event="reset"/>. The recipient client(s) can seamlessly redisplay the real-time message as a result. This allows real-time text to resume quickly, without waiting for senders to start a new message:
-
+
The message refresh SHOULD be transmitted at intervals during active typing or composing. The RECOMMENDED interval is 10 seconds. This interval is frequent enough to minimize user waiting time, while being infrequent enough to not cause a significant bandwidth overhead. This interval can be varied, or be set to a longer time period, in order to reduce average bandwidth (e.g., long messages, infrequent or minor message changes). To save bandwidth, message refreshes SHOULD NOT occur continuously while the sender is idle. To allow quicker resumption of real-time text, sender clients MAY adjust the timing of the message refresh to occur right after any of the following additional events:
If a client supports this real-time text protocol, it MUST advertise that fact in its responses to &xep0030; information requests ("disco#info") by returning a feature of ‘urn:xmpp:rtt:0’.
Example 1. A disco#info query
-
Example 2. A disco#info response
-
@@ -502,7 +502,7 @@
-]]>
In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.
See Guidelines for Initiating Real-Time Text for more information, including implicit discovery.
It is possible for sender clients to use Message Refresh to simply re-transmit the whole real-time message, as a method of transmitting text changes. The advantage is very simple implementation. Disadvantages can include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used. The below illustrates transmission of the real-time message “Hello there!” at a regular Transmission Interval while the sender is typing.
-
+
Note: The 'seq' attribute can be restarted at any value with <rtt event="reset"/> and <rtt event="new"/>. See Processing Rules.
Most of these examples are deliberately kept simple. In complete software implementations supporting key press intervals, transmissions will most resemble the last example, Full Message Including Key Press Intervals. For simplicity, these examples use a bare JID, even in situations where a full JID might be more appropriate.
All three examples shown below result in the same real-time message "HELLO" created by writing "HLL", backspacing two times, and then "ELLO". The action elements are Element <t/> – Insert Text and Element <e/> – Erase Text.
-
+
The example above sends the misspelled "HLL", then <e/><e/> backspaces 2 times, then sends "HELLO".
-
+
The example above shows that <e n='2'/> does the same thing as <e/><e/>.
-
+
+
These examples illustrate real-time message editing via Action Elements.
Note: In most situations, during normal human typing speeds at a normal Transmission Interval, smaller fragments of text will be spread over multiple <rtt/> elements, than these demonstration examples below. See Sending Real-Time Text.
+
+
+
This is an example message containing multiple consecutive real-time message edits. This illustrates valid use of the <rtt/> element.
-
+
All examples shown below, result in the same real-time message “HELLO”. Only the last example follows Preserving Key Press Intervals.
-
+
The above example outputs “HELLO” in a single action element (Element <t/> – Insert Text).
-
+
The above example outputs “HELLO” in separate action elements for each key press.
-
+
The above example outputs “HELLO” in separate action elements for each key press, while also Preserving Key Press Intervals. The Element <w/> – Wait Interval specifies the number of milliseconds between key presses, to allow smooth presentation in recipient clients that support <w/> action elements.
The use Element <w/> – Wait Interval, between key presses, allows the receiving client to execute a small pause between action elements. This allows recipient clients to play back the sender's typing fluidly.
-
+
This example also illustrates the following:
+
The members of the Real-Time Text Taskforce (R3TF), www.realtimetext.org, made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint-Andre and many others.
-The technique of Preserving Key Press Intervals, otherwise called "natural typing", was created by Mark Rejhon, who is deaf. It is incorporated into this specification in compliance of the XSF's Intellectual Property Rights Policy at http://xmpp.org/extensions/ipr-policy.shtml.
- - +The members of the &R3TF; made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint-Andre and many others.
+The technique of Preserving Key Press Intervals, otherwise called "natural typing", was created by Mark Rejhon, who is deaf. It is incorporated into this specification in compliance with the &XSFIPR;.
Presence data received by a client &xmppim; are typically cached and displayed until they are replaced by an update (whereupon the new data will be cached and displayed...), for example graphically annotating availability of contacts in a roster. Where the entity from which the client has received the presence data is remote (residing upon a different server), unavailability of the server to server link will render the client unable to receive further presence updates from the entity but unaware that this is the case. Where the remote entity is a contact, it may cause the contact appear to be online (or offline, or away etc.) to the user of the client when they are not. Where the remote entity is a &xep0045; room the case is more severe, as the MUC room may have ejected the client due to the server-to-server (S2S) link being unavailable to send stanzas but the client may still consider itself present in the room.
This extension provides a simple mechanism by which the local server can resend previous presence data to the client, annotated such that the client knows it would be unable to receive future updates.
-Appropriate action - alert user, attempt to rejoin MUC, whatever. +Allow servers to annotate presence stanzas sent to clients indicating lack of availability of a client or server link necessary for receipt of updated presence.
By default all messages match a query, and filters are used to request a subset of the archived - messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field - MUST be set to this protocol's namespace, 'urn:xmpp:mam:1'. Three further fields are defined by this - XEP and MUST be supported by servers, though all of them are optional for the client. These fields are: + messages. Filters are specified in a &xep0004; data form included with the query. The hidden FORM_TYPE field + MUST be set to this protocol's namespace, 'urn:xmpp:mam:1'. Three further fields are defined by this + XEP and MUST be supported by servers, though all of them are optional for the client. These fields are: +
+ Other fields may be used, but are not defined in this document - the naming of new fields MUST be + consistent with the format defined in &xep0068;. Servers MUST NOT mark any fields in the form as + being required (i.e. with the data forms <required/> element), regardless of whether they are + defined in this document or elsewhere. +
If a 'with' field is present in the form, it contains a JID against which to match messages. The server MUST only return messages if they match the supplied JID. A message in a user's archive matches if the JID matches either the to or from of the message. An item in a pubsub or MUC archive matches if the publisher of the item matches the JID; note that this should only be available to entities that would already have been allowed to know the publisher of the events (e.g. this could not be used by a visitor to a semi-anonymous MUC).
@@ -562,10 +565,9 @@ ]]>The IDs used within an archive MUST be unique per item stored and MUST NOT be reused, even if the original item with a given ID has since been removed from the archive. If a server provides multiple archives (e.g. many user archives, or many MUC archives), the IDs do not need to be unique across all of these archives unless the server also allows a single query to be run across multiple archives (e.g. searching of all MUC rooms), discussion of which is beyond the scope of this document. These IDs are strings that servers may construct in any manner, and clients must treat as opaque strings (e.g. is no requirement for them to be numeric, sequenced or GUIDs).
The protocol defined has the intention that, as far as possible, an entity should be unaware of the existence of any nodes or items which they are not Cleared to view. Therefore server responses to a request for a node which the entity is not Cleared to view SHOULD be identical to - a response as if that node did not exist (See BR1), i.e. an + a response as if that node did not exist (See BR1), i.e. an &ITEMNOTFOUND; error is returned
Sending presence probes from the client should be based on human request, i.e. opening a chat dialog to an offline contact when messing full presence information for that contact. Clients MUST NOT send presence probes to all contacts that they think are offline after login.
This section describes two major use cases of the described protocol, client initiated presence probes.
In some situations, after login, the client has incomplete presence information for offline contacts. The user might be interested in status text of the offline presence of a contact or when a contact went offline. This information can be requested, i.e. when the user opens a chat dialog to an offline user, using a client initiated presence probe and is described in the following two examples.
Initialilly a client requests the current presence information of a contact by sending out a presence probe.
@@ -75,7 +75,7 @@ This section describes two major use cases of the described protocol, client iniWith this concept, any party could easily request the time a XMPP server or component went online, by sending a presence probe to it.
In response, the requester receives a presence stanza, which contains &xep0203; information, indicating the time the server went online.
When a user comes back and uses her device again the client informs user's contacts by sending a normal presence stanza like shown in the following example, omiting the <idle/> element.
Available quality of service flags, in order of importance:
-| QoS Flag | Description | diff --git a/xep-0325.xml b/xep-0325.xml index 1e9902ae..02e2eb69 100644 --- a/xep-0325.xml +++ b/xep-0325.xml @@ -5,132 +5,88 @@ ]>
|---|
| Obsolete Code | -Error Type | -Error Element | -Namespace | -Description | -
|---|---|---|---|---|
| InsufficientPrivileges | -cancel | -forbidden | -urn:ietf:params:xml:ns:xmpp-stanzas | -If the caller lacks privileges to perform the action. | -
| NotFound | -cancel | -item-not-found | -urn:ietf:params:xml:ns:xmpp-stanzas | -If an item, parameter or data source could not be found. | -
| OtherError, FormError | -modify | -bad-request | -urn:ietf:params:xml:ns:xmpp-stanzas | -If the request was malformed. Examples can include trying to set a parameter to a value outside the allowed range. | -
| NotImplemented | -cancel | -feature-not-implemented | -urn:ietf:params:xml:ns:xmpp-stanzas | -If an action has not been implemented in the device. | -
| Locked | -wait | -conflict | -urn:ietf:params:xml:ns:xmpp-stanzas | -If an item was locked by another user or process and could not be accessed. The operation can be retried at a later point in time. | -
Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.
-Corrected the namespace used for parameterGroup elements in the examples of the document.
-Added support for color values with alpha channel.
-Updated the schema to more strictly validate references to x-data forms.
-Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.
-Fixed links to documents with new numbers.
-Changed namespace urn:xmpp:sn to urn:xmpp:iot
-Schema was corrected: The parameter sub-element in the setResponse element was removed.
-Initial published version approved by the XMPP Council.
-First draft.
-Updated contact information.
+Updated example JIDs to example.org
+Response codes have been removed and replaced by XMPP compliant IQ error stanzas. The table below shows how old status codes map to XMPP IQ error elements.
+The getFormResponse element has been removed.
+The setResponse is now only used when configuration is successful.
+The parameter subelement to setResponse has been reintroduced. Examples are provided in XEP-0324.
+The element paramError has been introduced, and can be used to provide error information that are linked to control parameters.
+Added anchors to all second level subsections.
+The section 'Reading current control states' has been updated to include two methods: One simple method only using control forms, and a second, using Sensor Data (XEP-0323).
+Harmonization of data types between XEP-0323 and XEP-0325.
+The attribute writable used to correlate fields in XEP-0323 with control parameters is described.
+Namespace in dynamic form examples has been changed to urn:xmpp:xdata:dynamic.
+Corrected the namespace used for parameterGroup elements in the examples of the document.
+Added support for color values with alpha channel.
+Updated the schema to more strictly validate references to x-data forms.
+Schema was updated to reflect the correct relationship between the x-data subelement in a set operation.
+Fixed links to documents with new numbers.
+Changed namespace urn:xmpp:sn to urn:xmpp:iot
+Schema was corrected: The parameter sub-element in the setResponse element was removed.
+Initial published version approved by the XMPP Council.
+First draft.
+
Actuators are devices in sensor networks that can be controlled through the network and act with the outside world. In sensor networks and Internet of Things applications,
@@ -980,8 +936,10 @@
- You set a control form to multiple nodes controlled by a concentrator by adding node elements to the Rayo is a protocol to allow third-party remote control over media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike Jingle or even SIP, a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself. Rayo is a protocol to allow third-party remote control over media sessions, audio/video mixers and a variety of advanced media resources such as speech recognizers, speech synthesizers and audio/video recorders. These capabilities can be combined to create a wide variety of applications such as menu-based phone systems, in-game conferencing and anonymous dating services. Unlike &xep0166; or even SIP (&rfc3261;), a Rayo client is not concerned with being a party to either the session negotiation or the media stream itself. In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate to be the client to whom the server delegates control of the call, and so has directed an offer event to her 'balcony' resource. In this example, a call from 'tel:+13058881212' has reached the Rayo server 'shakespeare.lit' by calling 'tel:+18003211212', and been assigned an ID '9f00061'. The server has determined that 'juliet@capulet.lit' is a valid candidate to be the client to whom the server delegates control of the call, and so has directed an offer event to her 'balcony' resource. The client, 'juliet@capulet.lit', then decides that it is able to handle the incoming call, and so accepts it from the server, thus gaining exclusive control and indicating to the calling party that the call will be processed and that it should ring. In examples, the following JIDs are used: XMPP message stanzas directed to the call's JID with a type of 'normal' MAY be forwarded to the calling party by translating the message into the calling party's protocol. In the case of SIP, this SHOULD follow the conventions set out in draft-ietf-stox-im-06 with the exception of the <thread/> to Call-ID mapping, as the Call-ID will always be that of the calling party. XMPP message stanzas directed to the call's JID with a type of 'normal' MAY be forwarded to the calling party by translating the message into the calling party's protocol. In the case of SIP, this SHOULD follow the conventions set out in draft-ietf-stox-im-06 with the exception of the <thread/> to Call-ID mapping, as the Call-ID will always be that of the calling party. If a message is directed to the call's JID with a type other than 'normal' then the server MUST return a <feature-not-implemented/> error with a type of 'modify'. If no translation is possible then the server SHOULD return the same error but with a type of 'cancel'.
Prior to the development of the Rayo protocol, the most widely-used 3PCC protocols were Asterisk's AGI and AMI. Unfortunately, these protocols have many drawbacks, not least in their inconsistency and relatively poor documentation, but also in that they are poorly secured and lacking in attributes required for significant scalability. Much 3PCC activity is also done using process-internal APIs rather than a wire protocol like XMPP.
Rayo was developed to satisfy three main desires:
Initial development of the Rayo specification and its reference implementation was sponsored by Tropo (formerly Voxeo Labs) and Telefónica, with Punchblock being the first client library implementation, as part of the Adhearsion project. Since the beginning of the development process, further implementation efforts have begun on top of Asterisk's AGI/AMI protocols and FreeSWITCH EventSocket, native to FreeSWITCH (mod_rayo), as well as client library implementations in Node/CoffeeScript and Python.
The authors would like to acknowledge the input of teams at Tropo (formerly Voxeo Labs), Mojo Lingo and Telefónica in the development of the initial specification, and Grasshopper in expanding the implementation landscape.
diff --git a/xep-0329.xml b/xep-0329.xml index fec49253..becbefe8 100644 --- a/xep-0329.xml +++ b/xep-0329.xml @@ -23,13 +23,13 @@First draft.
&xep0060; nodes are commonly used by XMPP users to subscribe to news feeds. This document describe a way, for them, to share some of the nodes to which they have subscribed with other users. @@ -57,7 +58,7 @@
Information about the subscribed node is provided by the user client. The subscription container is defined as a classic
Information about the subscribed node is provided by the user client. The subscription container is defined as a classic &subscription; element with theses specific constraints :
| Name | @@ -71,21 +72,18 @@Any server's address | REQUIRED | |
| node | attribute | REQUIRED | |
| id | node | RECOMMENDED | |
| title | node | @@ -93,10 +91,8 @@OPTIONAL |
The aim of this XEP is to handle a list of subscriptions. To simplify the managment of this list the ID of the &xep0060; items MUST be generated according to the following method :
-
-
-
The title element of a
The title element of a &subscription; item SHOULD be in the same language as the contents of the node in question.
The publication of user tune information is not known to introduce any new security considerations above and beyond those defined in XEP-0060: Publish-Subscribe.
diff --git a/xep-0336.xml b/xep-0336.xml index 07f0a900..41bcf121 100644 --- a/xep-0336.xml +++ b/xep-0336.xml @@ -863,7 +863,6 @@ available in the updated form, the flag stating that user input has occurred in the field can be cleared. -@@ -889,9 +888,7 @@
-
This document requires no interaction with &IANA;.
- +This document requires no interaction with &IANA;.
diff --git a/xep-0337.xml b/xep-0337.xml
index 4450e9c9..49e7eb8b 100644
--- a/xep-0337.xml
+++ b/xep-0337.xml
@@ -5,55 +5,55 @@
]>
Updated contact information. Updated example JIDs to example.org Initial published version approved by the XMPP Council. Addressed pre-publication feedback from the XMPP Council. First draft. Updated contact information. Updated example JIDs to example.org Initial published version approved by the XMPP Council. Addressed pre-publication feedback from the XMPP Council. First draft.
This XEP provides a common framework for sending events over an XMPP network. These events can then be logged in event logs or analyzed by network monitors
@@ -222,7 +222,7 @@ Object 10
]]>
- Note: Any tag elements must come after the message element.
+ Note: Any tag elements must come after the message element.
@@ -256,7 +256,7 @@ File2, Line2, ...
]]>
- Note: Any stackTrace element must come after the message element and any tag elements.
+ Note: Any stackTrace element must come after the message element and any tag elements.
diff --git a/xep-0338.xml b/xep-0338.xml
index 90f5a650..0cb3a3f8 100644
--- a/xep-0338.xml
+++ b/xep-0338.xml
@@ -20,6 +20,7 @@
First draft. &rfc5888; defines a framework to group SDP 'm' lines for different purposes. A mapping to Jingle as an extension to &xep0166; is defined in this document. First draft. &rfc5576; provides a mechanism to describe attributes of individual media sources (identified by their synchronization source) within a media stream. A mapping to Jingle as an extension to &xep0167; is defined in this document. First draft. Although &xep0220; describes dialback as being run before any other negotiation, it is typically run over TLS where supported. This allows it to be used as a simple convenient fallback to X.509 Strong Authentication within the TLS layer, as described in &rfc6120;, and also affords greater protection to the exchange. Discovery of the template forms or completed form nodes happens using the protocol described in Use Cases.
+ Discovery of the template forms or completed form nodes happens using the protocol described in Use Cases.