From 2bfb3ecfb399f8e8d4ec7e9d99da2be2b0dc684b Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 12 Jul 2007 20:41:15 +0000 Subject: [PATCH] copy edit git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1061 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0115.xml | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/xep-0115.xml b/xep-0115.xml index 3c64cc51..be69e548 100644 --- a/xep-0115.xml +++ b/xep-0115.xml @@ -123,19 +123,17 @@ ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/> ]]> -

The 'node' attribute represents the client Romeo is using. The 'ver' attribute is a specially-constructed string that represents the identity (see &DISCOCATEGORIES;) and supported features (see &DISCOFEATURES;) of the entity.

-

At this point, your client has no idea what the capabilities are of someone with a client string 'http://exodus.jabberstudio.org/caps' and a version string '8RovUdtOmiAjzj+xI7SK5BCw3A8='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.

+

The 'node' attribute represents the client Romeo is using (the client identifier is an "FYI" and is not used further in Entity Capabilities). The 'ver' attribute is a specially-constructed string that represents the identity (see &DISCOCATEGORIES;) and supported features (see &DISCOFEATURES;) of the entity.

+

At this point, your client has no idea what the capabilities are of someone with a version string '8RovUdtOmiAjzj+xI7SK5BCw3A8='. Your client therefore sends a service discovery query to Romeo, asking what his client can do.

- + ]]>

The response is:

- + @@ -143,7 +141,7 @@ ]]> -

At this point, your client knows that anyone advertising a version string of '8RovUdtOmiAjzj+xI7SK5BCw3A8=' has a client that can do MUC. Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same version string. For example, Benvolio may send you the following presence:

+

At this point, your client knows that anyone advertising a version string of '8RovUdtOmiAjzj+xI7SK5BCw3A8=' has a client that can do &xep0045;. Your client remembers this information, so that it does not need to explicitly query the capabilities of a contact with the same version string. For example, Benvolio may send you the following presence:

]]> -

... you have no information about what this contact's client is capable of (as he is using a different client/version), and you therefore need to query for capabilities explicitly again via service discovery.

+

... you have no information about what this contact's client is capable of unless you have cached previous entity capabilities information; therefore you need to query for capabilities explicitly again via service discovery.

@@ -217,7 +215,7 @@ node - A unique identifier for the software underlying the entity, typically a URL at the website of the project or company that produces the software; required for backward-compatibility. + A unique identifier for the software underlying the entity, typically a URL at the website of the project or company that produces the software; although this information is an "FYI" in the current version of entity capabilities, it is required for backward-compatibility with older versions. REQUIRED @@ -233,19 +231,19 @@

Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.

  1. Initialize an empty string S.
    2. -
  2. Sort the service discovery identities by category and then by type, formatted as "category" "/" "type".
    3. -
  3. For each identity, append the category/type (if it exists) to S, followed by the '<' character.
    4. +
  4. Sort the service discovery identities by category and then by type (if it exists), formatted as "category" "/" "type".
    5. +
  5. For each identity, append the category/type to S, followed by the '<' character.
  6. Sort the supported features.
  7. For each feature, append the feature to S, followed by the '<' character.
    8. -
  8. Compute ver by hashing S using the SHA-1 algorithm as specified in &rfc3174; (with binary output) and encoding the hash using Base64 as specified in Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero).
    9. +
  9. Compute ver by hashing S using the SHA-1 algorithm as specified in &rfc3174; (with binary output) and encoding the hash using Base64 as specified in Section 4 of &rfc4648; (note: the Base64 output MUST NOT include whitespace and MUST set padding bits to zero). The OpenSSL command for producing such output is "echo -n 'S' | openssl dgst -binary -sha1 | openssl enc -nopad -base64".

For example, consider an entity whose service discovery category is "client", whose service discovery type is "pc", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". The value of the 'ver' attribute would be generated as follows:

    -
  1. E = ''
    2. +
  2. S = ''
  3. Only one identity: client/pc
    4. -
  4. E = 'client/pc<'
    5. +
  5. S = 'client/pc<'
  6. Sort the features: "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".
    7. -
  7. E = 'client/pc<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'
    8. +
  8. S = 'client/pc<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'
  9. ver = 8RovUdtOmiAjzj+xI7SK5BCw3A8=
 @@ -328,7 +326,7 @@ -

If two entities exchanges messages but they do not normally exchange presence (i.e., via presence subscription), the entities MAY choose to send directed presence to each other, where the presence information SHOULD be annotated with the same capabilities information as each entity sends in broadcasted presence. If capabilities information has not been received from another entity, an application MUST assume that the other entity does not support capabilities.

+

If two entities exchange messages but they do not normally exchange presence (i.e., via presence subscription), the entities MAY choose to send directed presence to each other, where the presence information SHOULD be annotated with the same capabilities information as each entity sends in broadcasted presence. If capabilities information has not been received from another entity, an application MUST assume that the other entity does not support capabilities.

 @@ -337,7 +335,7 @@

Use of the protocol specified in this document might make some client-specific forms of attack slightly easier, since the attacker could more easily determine the type of client being used. However, since most clients respond to jabber:iq:version requests without performing access control checks, there is no new vulnerability. Entities that wish to restrict access to capabilities information SHOULD use &xep0016; to define appropriate communications blocking (e.g., an entity MAY choose to allow IQ requests only from "trusted" entities, such as those with whom it has a subscription of "both").

-

Adherence to the algorithm defined in the Generation of ver Attribute sectio of this document helps to guard against poisoning of entity capabilities information by malicious or improperly implemented entities.

+

Adherence to the algorithm defined in the Generation of ver Attribute section of this document helps to guard against poisoning of entity capabilities information by malicious or improperly implemented entities.

 @@ -391,7 +389,7 @@ -

Before Version 1.4 of this specification, the 'node' attribute was required, the 'ver' attribute was generated differently, and the 'ext' attribute was used more extensively. For historical purposes, Version 1.3 of this specification is archived at <http://www.xmpp.org/extensions/attic/xep-0115-1.3.html>. For backward-compatibility with the legacy format, the 'node' attribute is REQUIRED and the 'ext' attribute MAY be included.

+

Before Version 1.4 of this specification, the 'ver' attribute was generated differently and the 'ext' attribute was used more extensively. For historical purposes, Version 1.3 of this specification is archived at <http://www.xmpp.org/extensions/attic/xep-0115-1.3.html>. For backward-compatibility with the legacy format, the 'node' attribute is REQUIRED and the 'ext' attribute MAY be included.