From 60d578d7eea298d6dd51df61c0090397c971f588 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 17 Jan 2007 17:02:58 +0000 Subject: [PATCH] typos git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@357 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0045.xml | 8 +++----- xep-0050.xml | 2 +- xep-0106.xml | 2 +- 3 files changed, 5 insertions(+), 7 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 8a66d735..78b319fc 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1238,7 +1238,7 @@ ]]> -

However, it MAY done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":

+

However, it MAY be done by sending a message of type "groupchat" to the new occupant containing an <x/> child with a <status/> element that has the 'code' attribute set to a value of "100":

]]> -

The use SHOULD then discover its reserved nickname as specified in the Discovering Reserved Room Nickname section of this document.

+

The user SHOULD then discover its reserved nickname as specified in the Discovering Reserved Room Nickname section of this document.

In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In Jabber, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.

@@ -2133,9 +2133,7 @@

It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where data form contains only a 'muc#role' field with a value of "participant".

+ to='darkcave@macbeth.shakespeare.lit'> http://jabber.org/protocol/muc#request diff --git a/xep-0050.xml b/xep-0050.xml index 4b9807e6..67bca7e0 100644 --- a/xep-0050.xml +++ b/xep-0050.xml @@ -289,7 +289,7 @@ - + diff --git a/xep-0106.xml b/xep-0106.xml index 0033d906..51f7eebb 100644 --- a/xep-0106.xml +++ b/xep-0106.xml @@ -209,7 +209,7 @@ foob\41r is not modified (to foobAr) by encoding or decoding transformations. -

When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the jid\20escaping [sic] feature via Service Discovery as shown above. If there any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:

+

When a client attempts to communicate with another entity through a gateway, it needs to know which encoding mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the jid\20escaping [sic] feature via Service Discovery as shown above. If there are any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:

  1. If the gateway supports the 'jabber:iq:gateway' protocol (as specified in &xep0100;), use that protocol.
  2. If the gateway does not support the 'jabber:iq:gateway' protocol, use customary escaping mechanisms (such as transformation of the @ character to the % character).