diff --git a/xep-0031.xml b/xep-0031.xml index daa9ed43..5d37a905 100644 --- a/xep-0031.xml +++ b/xep-0031.xml @@ -1505,7 +1505,6 @@ The key's identifier, convId, is assembled. The payload, which consists of the confidentiality key and the integrity key, is wrapped in instances of xenc:EncryptedKey as follows:
-@@ -1537,6 +1536,7 @@ The xenc:CipherData element MUST be present, and it MUST use the CipherValue cho
The HMAC is computed using SKi of the security session over the following values: @@ -1726,7 +1726,6 @@ this specification is '1.0'. The value of convId MUST correspond to an existing,
The actual message body is encoded into a character string corresponding to a Jabber message body element. This character string is then wrapped in an instance of xenc:EncryptedData as follows:
-@@ -1757,6 +1756,7 @@ The xenc:CipherData element MUST be present, and it MUST use the CipherValue cho
Using the HMAC key indicated by the convId attribute, the HMAC is computed @@ -2101,12 +2101,12 @@ Support for Elliptic Curve Cryptography
Additional symmetric algorithms
+Additional hash algorithms
diff --git a/xep-0043.xml b/xep-0043.xml
index e4581be8..9085bfd0 100644
--- a/xep-0043.xml
+++ b/xep-0043.xml
@@ -64,36 +64,39 @@
Attributes only used in the <col> element within a
<where> element are the op (for operator) and conj for
(conjunction). The op is used for comparison operators such
- as <, >, =, <>, <=, >=
+ as <, >, =, <>, <=, >=
-
-
-
+
-
-
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
+
-
The conjuction attribute is used to combined constraints in the where clause +
The conjuction attribute is used to combined constraints in the where clause
Result
@@ -696,8 +697,9 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)Three responses are possible from the server.
It supports that version number and responds with: The type of 'result' indicates that the version request was
successful and if the client is satisfied with the version number,
may continue with schema requests or whatever. It does not support that version number and responds with: The type of 'error' indicates a failure in conforming to the
desired version number. The server may optionally send an
- alternative option.
+ alternative option.
+
<iq id="000" type="result" from="db.host">
<database
xmlns="http://openaether.org/projects/jabber_database.html">
@@ -705,20 +707,20 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
</database>
</iq>
- The type of 'result' indicates that the version request was
+
+
<iq id="000" type="error" from="db.host">
<database
xmlns="http://openaether.org/projects/jabber_database.html"/>
</iq>
- The type of 'error' indicates a failure in conforming to the
+
<iq id="000" type="error" from="db.host">
<database
@@ -726,7 +728,7 @@ insert tbl_two (a_date, a_numeric) VALUES('02/16/2002', 123456789123.123)
<version>0.2</version>
</database>
</iq>
-
The "offset" attribute defines the range offset, in bytes. This attribute MAY be present if the containing <file/> has an action value of "get", otherwise it SHOULD NOT be present. If this attribute is not present, a value of 0 is implied. The value of this attribute MUST be an integer, MUST NOT be less than 0, and MUST be less than (size - length).
- There are three main error conditions in file transfer. Following are the - conditions, error codes and descriptions: +
There are three main error conditions in file transfer. Following are the + conditions, error codes and descriptions:
Initiator and Target may begin using the bytestream.
Mediated connection is slightly more complicated. In this situation, the StreamHost is not the Initiator but a Proxy, which means that the Initiator must discover the network address of the StreamHost before sending the initial IQ-set, must negotiate a connection with the StreamHost in the same way that the Target does, and must request that the StreamHost activate the bytestream before it can be used. The process for establishing bytestreams in this case is as follows:
Optionally, Initiator discovers the network address of StreamHost in-band.
The following actions are defined by this document.
The "alert" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='alert'/>, which itself contains the <rule/> that triggered this action. In all other respects, this action behaves as "drop".
-
@@ -420,14 +420,14 @@
- ]]>
The "drop" action silently discards the message from any further delivery attempts and ensures that it is not placed into offline storage. The drop MUST NOT result in other responses.
The "error" action triggers a reply &MESSAGE; stanza of type "error" to the sending entity. The &MESSAGE; stanza's <error/> child MUST contain a <failed-rules xmlns='http://jabber.org/protocol/amp#errors'/> error condition, which itself contains the rules that triggered this action.
-
- ]]>
Note that the error SHOULD be of type "modify", and the general error condition SHOULD be <undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>.
The "notify" action triggers a reply &MESSAGE; stanza to the sending entity. This &MESSAGE; stanza MUST contain the element <amp status='notify'/>, which itself contains the <rule/> that triggered this action. Unlike the other actions, this action does not override the default behavior for a server. Instead, the server then executes its default behavior after sending the notify.
-
@@ -461,7 +461,7 @@
- ]]>
Creating a profile is fairly simple. First, a name is chosen, the - complete name is formatted like: + complete name is formatted like:
http://jabber.org/protocol/si/profile/profile-name
+ The complete name is what is presented in information discovery requests in order to show that the profile is supported. It is also used for the <si> profile attribute. Next, the information for the headers is @@ -321,7 +322,7 @@ streams must link the Stream Initiation to the stream. The id attribute of the <si> node is intended to provide this link. It is out of scope of this document to define how streams will make use of this - facility, but it does suggest some methods: + facility, but it does suggest some methods:
- The attributes and data of <si> are fairly simple: + The attributes and data of <si> are fairly simple:
The data of the node is a mixture of a feature negotiation for the stream and the profiles headers.
@@ -382,7 +382,7 @@
There are two error codes that are used. Following are the conditions,
- meanings and data:
+ meanings and data:
-
Define a full-featured set of metadata for file transfers, including the following:
The root element is <file> and has four attributes. The attributes - are used only during the offer stage of stream initiation: + are used only during the offer stage of stream initiation:
The size and name attributes MUST be present in the profile. The other attributes MAY be present.
@@ -150,7 +150,7 @@ When <range> is sent in the offer, it should have no attributes. This signifies that the sender can do ranged transfers. When a Stream Initiation result is sent - with the <range> element, it uses these attributes: + with the <range> element, it uses these attributes:
Both attributes are OPTIONAL on the <range> element. Sending no
attributes is synonymous with not sending the <range>
element. When no <range> element is sent in the
Stream Initiation result, the Sender MUST send the complete file starting at
diff --git a/xep-0100.xml b/xep-0100.xml
index f4179f0e..6579aaef 100644
--- a/xep-0100.xml
+++ b/xep-0100.xml
@@ -317,7 +317,7 @@
User information not verified:
+ User information not verified: Gateway returns ¬acceptable; error to Jabber User. (For detailed information regarding error conditions, refer to &xep0086;.) Use Case Ends unsuccessfully.
-
-
Edit unsuccessful: +
Edit unsuccessful:
Gateway returns ¬acceptable; error to Jabber User.
@@ -422,7 +422,7 @@Use Case Ends unsuccessfully.
Login fails: +
Login fails:
Gateway sends appropriate presence error to Jabber User (¬authorized; if password is bad, &timeout; if Legacy Service is down, etc.).
@@ -549,7 +549,7 @@Use Case Ends unsuccessfully.
Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User: +
Legacy Service supports directed presence and Gateway receives presence stanza of type "unavailable" directed to a Legacy User:
Gateway passes through directed unavailable presence to Legacy User.
@@ -595,7 +595,7 @@Use Case Ends.
Jabber User denies subscription request: +
Jabber User denies subscription request:
Jabber User sends presence stanza of type "unsubscribed" to Legacy User.
@@ -806,7 +806,7 @@Gateway cleans up subscription state and MUST NOT send Jabber User's presence to Legacy User.
Use Case Ends unsuccessfully.
Gateways and clients SHOULD implement at least one of these protocols; at a minimum, it is RECOMMENDED for gateways and clients to implement the 'jabber:iq:gateway' protocol.
-The 'jabber:iq:gateway' protocol performs two functions:
It enables a client to determine the text for the "prompt" to show to a Jabber User when the user wants to add a legacy contact to the user's roster (e.g., "Please enter the AOL Screen Name of the person you would like to contact"), as well as the preferred name for the prompted item (e.g., "Screen Name"). To do so, the client sends an empty <query/> element and the gateway returns a <prompt/> element (the name for the prompted item) and optionally a <desc/> element (the text of the prompt itself).
xmody means: x is divided by y and the remainder is returned
Suppose two nodes want to agree on a shared secret key to exchange information securely, they will exchange their public keys in order to encrypt that information. To this goal, the transport XMPP packet SHOULD include an extension of the form:
@@ -293,7 +293,7 @@
-]]>
+]]>
In this extension, the only negotiable parameter is the key length that is passed in the length attribute of the <KeyAgreement/> tag. The length attribute is used to retrieve the DH parameter group and the associated prime and generator values. We are using DH groups derived from the Internet Key Exchange protocol (IKE) which is used by IPSec. A summary of these groups and the associated parameters are described later in this document.
The client uses an empty <x/> element in the request to signal that it supports the XMPP security extension.
The flow between client and server will look like:
@@ -309,11 +309,11 @@
-]]>
+]]>
The server will reply to the request by sending out its own ephemeral public key inside the <x/> extension.
@@ -327,12 +327,12 @@
-]]>
+]]>
The client then generate its own public key, calcultate the shared secret according to the DH method and uses it to encrypt the password accordingly. It includes its own ephemeral public key into the reply to the server inside the <x/> extension.
username
@@ -346,15 +346,15 @@
-]]>
+]]>
The server now calculates the shared secret according to the DH method and uses its private key to decrypt the password.
-]]>
+]]>
An RSA Laboratories Technical Note
Version 1.4
-Revised November 1, 1993 Supersedes June 3, 1991 version, which was also published as NIST/OSI Implementors' Workshop document SEC-SIG-91-19. PKCS documents are available by electronic mail to <pkcs@rsa.com>.
This standard describes a method for implementing Diffie-Hellman key agreement, whereby two parties, without any prior arrangements, can agree upon a secret key that is known only to them (and, in particular, is not known to an eavesdropper listening to the dialogue by which the parties agree on the key). This secret key can then be used, for example, to encrypt further communications between the parties.
The intended application of this standard is in protocols for establishing secure connections, such as those proposed for OSI's transport and network layers [ISO90a][ISO90b].
diff --git a/xep-0117.xml b/xep-0117.xml index 36aaf0f0..23ef42e1 100644 --- a/xep-0117.xml +++ b/xep-0117.xml @@ -78,7 +78,7 @@The &xep0073; introduced the concept of a "protocol suite". This document extends the basic support specified in XEP-0073 by specifying an Intermediate IM Protocol Suite.
This document follows the same approach as XEP-0073. By design, the Basic IM Protocol Suite does not include more advanced instant messaging functionality; the present document fills the need for a protocol suite that addresses such functionality.
A protocol is deemed worthy of inclusion in this protocol suite if:
In general it is probably easiest for users to become visible/invisible either globally or based on roster group, since these models are conceptually simple. Although, naturally, a client developer cannot tell users what to do, it probably best to encourage the use of conceptually simple models for privacy lists.
Privacy lists can become complex and must be carefully managed by clients. For example, let us imagine that the user is currently applying another active list unrelated to visibility (e.g., a list that blocks communications with a stalker); if the user then clicks "Go Invisible" and the client is not smart, it could overwrite the stalker blocking. Therefore, if the user has an active list that incorporates rules other than those related to visibility/invisibility, the client SHOULD either assume that visibility/invisibility is an overlay on the list currently in use (generating an appropriate privacy list that takes both into account) or prompt the user regarding their intentions. In the absence of privacy lists unrelated to visibility/invisibility, the client may proceed in a less cautious fashion.
For security concerns related to privacy lists, refer to RFC 3921. Care must be taken regarding privacy lists, especially so that visibility/invisibility rules do not overwrite existing rules the user has set for the sake of security and privacy; for details, see the Implementation Notes section of this document.
It is important to recognize that invisibility can be defeated without more advanced privacy lists than those defined above and an awareness of context on the part of a client. For example, if a user usually logs in as the same resource (e.g., "Home"), a contact can send an IQ request to that resource's full JID using &xep0012;, &xep0030;, &xep0090;, or &xep0092; and receive a reply, thus providing information that reveals the user's availability. In addition, Last Activity requests sent by a subscribed contact to the user's bare JID will normally reveal the user's availability as well. To help ensure that the user's invisibility cannot be defeated in this way, the user's client SHOULD add IQ blocking to the relevant privacy list. Finally, the user's client SHOULD NOT return "is-composing" events as defined in &xep0022; or &xep0085;.
This document requires no interaction with &IANA;.
No namespaces or parameters need to be registered with the ®ISTRAR; as a result of this specification.
&xmppcore; and &xmppim; define methods for exchanging information about a person's network availability via the XML <presence/> stanza. In general, such presence information is generated only when a person initiates interaction with a client, although it can be generated programmatically through features such as auto-away. However, sometimes a user is present in the vicinity of a client but is not actively engaged with the client interface. In such circumstances, it would be helpful to have a mechanism that is sometimes referred to as <presence type='probe-irl'/>: the ability to invoke a real-life means of determining the physical presence of the user. This document defines just such a mechanism.
If administrator policies require that at least the <body/> elements (or the full content) of every message are logged automatically, and the client sets the value of the 'save' attribute to 'false' (or 'body').
A client may use a similar protocol to set the Modes for a particular contact or domain of contacts (bare JID, full JID or domain). Note: It is STRONGLY RECOMMENDED for the value of the 'jid' attribute to be a bare JID (&BAREJID;).
The same error cases apply as when Setting Default Modes.
The client MAY specify an absolute time for any message by providing a longer 'utc' attribute (which MUST be UTC and adhere to the DateTime format specified in Jabber Date and Time Profiles) instead of a 'secs' attribute. The absolute time MAY be before the start time of the collection:
As soon as the server has finished archiving a collection, it MUST securely destroy all copies of the symmetric key it used to encrypt the messages. Note: If the security of the server is compromised, then only the collections being recorded during the attack will be revealed (i.e. only those messages that would have been compromised even if they had not been archived).
The server MUST return a <feature-not-implemented/> error in the following cases:
If the client is trying to enable automatic archiving, but the server does not allow the saving of full message stanza content, and the user has specified the 'message' Save Mode in one of its Archiving Preferences.
There are no defined error conditions for agent invitations.
An invitation from the server on behalf of the support@example.net workgroup:
If the client subsequently obtains an avatar image (e.g., by updating or retrieving the vCard), it SHOULD then publish a new &PRESENCE; stanza with character data in the <photo/> element.
+Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).
-Note: This enables recipients to distinguish between the absence of an image (empty photo element) and mere support for the protocol (empty update child).
Longitude is a person's longitude in relation to the equator, where positive longitude is east of the meridian and negative longitude is west of the equator.
The Data Forms field that represents longitude is "lon".
This field maps to:
diff --git a/xep-0159.xml b/xep-0159.xml index 8cb5e4ab..ef9b47a3 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -107,14 +107,14 @@ ]]>This section specifies server functionality not defined in RFC 3921. This document will not reach Draft status until Server-Based Privacy Rules has been modified to permit this functionality.
-A server that supports this protocol MAY maintain a separate
Note: When it blocks a stanza, the server MUST NOT add the 'from' attribute of the stanza to the correspondents list.
Note: The lists of correspondents have a very different function from rosters. Edits are initiated by the server not the client, allowing the lists to be completely transparent to clients.
The server SHOULD perform the following procedures whenever it receives a stanza that falls through the active privacy list of the user it is addressed to without being either allowed or denied:
When a SPIM recognition procedure delays delivery of a stanza the server SHOULD store it temporarily.
While delivery is being delayed:
This informative section requires no client or server functionality beyond that defined in RFC 3921.
-The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from SPIM blocking (see the items with order 20, 30 and 40 in the example below).
At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive SPIM recognition techniques (like Robot Challenges). So, if its server uses interactive techniques, the client MAY use the 'jid' type to ensure its server does not block stanzas arriving from the transports the user has registered with (see the item with order 50 in the example below).
If a user believes SPIM will not be sent by users of a particular server (e.g. the user's own corporate server), then the client MAY use the 'jid' type to exclude all these users from SPIM blocking (see the item with order 60 in the example below).
If stanzas from a SPIM robot running on a zombie domain somehow manage to get past the server's SPIM recognition then the client MAY use the 'jid' type to block one or all JIDs from the domain. (RFC 3921 already enables this functionality.)
A client MAY disable server-side SPIM blocking by ensuring the default fall-through action is never applied. It does this simply by including an explicit fall-through item in its active privacy list.
Note: The parameter names are effectively guaranteed to be unique, since &IANA; maintains a registry of SDP parameters (see <http://www.iana.org/assignments/sdp-parameters>).
Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a receiver iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:
-If, after applying these rules, the receiver determines it does not support any of the offering encodings, the receiver MUST reject the session by sending a <unsupported-codecs/> error in response to the initiator's "initiate" action. Otherwise, it MUST provisionally accept the session by sending an empty IQ result. If the response content type differs from the one offered, the receiver MUST then propose the change in a "description-modify" action as defined in XEP-0166. If the description is identical, the receiver MUST send a "description-accept" action (either explicitly, or implicitly as part of a "session-accept" or "content-accept" action).
-Following is an example of this negotiation:
-The receiver now follows the rules provided in this section and determines it can only support PCMU. It provisionally accepts the session:
-It then offers the new content description in a 'description-modify' action:
-The initiator acknowledges the 'description-modify' with an empty IQ result, and sends a 'description-accept' to accept the new Jingle Audio content description.
-Finally, the target acknowledges the 'description-accept'.
-Upon receiving a Jingle initiate stanza containing a Jingle Audio content description as defined in this document, a target entity iterates through the list of offered payload types, composing an appropriate Jingle Audio response description according to the following rules:
A client MUST NOT generate a <rap/> element that has an 'app' attribute whose value is "messaging" or that has no 'app' attribute (since the default 'app' is "messaging").
The user's server may have special information that enables it to flag a resource as primary for a given application type. For instance, the server may include a communication policy service that enables the user to define (outside the context of any presence priorities) that she would prefer to be called at her "desktop" resource only between the hours of 9:00 AM and 5:00 PM local time, prefer to be called on her mobile at all other times, and so on.
To flag the primary resource related to a specific application type, the server shall add a <primary/> child to the relevant RAP element. Here is an example:
Updated to track ICE-12; corrected service discovery process; completed editorial review; removed mention of DTMF, which is for audio only.
Updated to track ICE-12; corrected service discovery process; completed editorial review; removed mention of DTMF, which is for audio only.
Updated to track ICE-10; added section on service discovery.
Updated to track ICE-10; added section on service discovery.
Specified that DTMF must use in-band signalling (XEP-0181).
Specified that DTMF must use in-band signalling (XEP-0181).
Recommended use of RTP-native methods for DTMF.
Recommended use of RTP-native methods for DTMF.
If the receiving entity does not understand or cannot process the payload, it MUST return an appropriate XMPP error (such as &unavailable; or &unexpected;).
Some applications may want to stream Jingle voice RTP directly to a non-XMPP entity, such as a SIP phone. In this scenario, DTMF needs to be sent in the content channel. Jingle DTMF enables Jingle entities to negotiate whether to send RTP over the XMPP signalling channel as described above, or over the content channel using &rfc4733;.
To request that the voice session switches to RFC 4733, a client sends a <dtmf-method/> element, qualified by the 'http://jabber.org/protocol/info/dmtf' namespace as the payload of a Jingle content-info message:
diff --git a/xep-0188.xml b/xep-0188.xml
index d1fafe38..7def564b 100644
--- a/xep-0188.xml
+++ b/xep-0188.xml
@@ -203,13 +203,13 @@
The solution should be compatible with existing (and future) cryptographic algorithms and identity certification schemes (including X.509 and PGP). The protocol should also be able to evolve to correct the weaknesses that are inevitably discovered once any cryptographic protocol is in widespread use.
-
+
Ideally, it would be possible for an XMPP user to exchange encrypted messages (and, potentially, presence information) with users of non-XMPP messaging systems.
Ideally, it should be possible to encrypt one-to-one communications that are stored for later delivery instead of being delivered immediately, such as so-called "offline messages". However, any vulnerabilities introduced to enable offline communications must not make online communications more vulnerable.
-
+
For cases where a session is not desired, it should be possible to encrypt, sign and send a single stanza in isolation, so-called "object encryption".
As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending +
As shown in the basic "session" example in the Simplified Stream Examples (4.8 of RFC 3920), it is a valid transaction to close the outgoing stream by sending
]]>
- then wait for the other entity to close its stream, like this:
+ then wait for the other entity to close its stream, like this:
]]>
- and shut down the underlying TCP connection.
+ and shut down the underlying TCP connection.
This will ensure that, should the other entity have transmitted any data, it will arrive and be processed before the TCP connection is terminated.
Special care MUST be taken that under no circumstance further packets may be written to the socket after the stream was closed, until the other side shuts down the socket.
On the outgoing TCP connection, an implementation MAY do a read-only shutdown of the socket, as long as the other side will safely be able to send its stream termination token.
diff --git a/xep-0198.xml b/xep-0198.xml index dcf72cb1..d8510f05 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -179,7 +179,7 @@Upon approval of this XEP, the Jabber Registrar shall add 'http://jabber.org/features/ack' to its registry of stream features.
Upon approval of this XEP, the ®ISTRAR; shall add 'http://jabber.org/protocol/ack' to its registry of protocol namespaces.
This protocol was designed in a way that makes migration from XEP-0090 straightforward. This document specifies a different format for the XML character data of the <utc> element (compliant with XEP-0082) and specifies a new <tzo> element for the numeric offset from UTC, while removing the formerly optional and effectively useless <display/> and <tz/> elements.
Implementations that support XEP-0090 should support the protocol defined herein as soon as possible, but should continue to support the protocol defined in XEP-0090 for backwards compatibility until the status of that specification is changed to Obsolete.
Revealing an entity's numeric time zone offset may leak limited information about the entity's current location. If the entity's understanding of UTC is far off from actual UTC, revealing that discrepancy may make it possible for an attacker to send XML stanzas that appear to be in the past or future even though they are not; therefore an entity should use the Network Time Protocol (&rfc0958;) or a similar technology to stay synchronized with actual UTC.
A server implementation SHOULD enable a server administrator to limit the number of connections that it will from a given IP address at any one time.
If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.
A server implementation SHOULD enable a server administrator to limit the number of connection attempts that it will from a given IP address in a given time period (e.g., one hour).
If an entity attempts to connect but the maximum number of connections has been reached, the receiving server MUST NOT allow the new connection to proceed. There are no XMPP errors associated with this behavior, since it occurs at the binding (TCP or HTTP) level before an XML stream is initiated.