From 337e41f9255bff7e4effd4616dbb2038157c42e9 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Sat, 3 Dec 2016 10:18:14 -0600 Subject: [PATCH] XEP-0045: Typo and whitespace fixes --- xep-0045.xml | 87 ++++++++++++++++++++++++++++------------------------ 1 file changed, 47 insertions(+), 40 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 4a862c58..e45debbc 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -45,6 +45,14 @@ &stpeter; + + 1.27.1 + 2016-12-03 + XEP Editor: ssw + +

Editorial typo and whitespace fixes.

+ + 1.27 2016-10-29 @@ -52,7 +60,6 @@
  • Clarify behavior on MUC join.
    • -
@@ -1173,39 +1180,39 @@ http://jabber.org/protocol/muc#roominfo - The place for all good witches! - true - crone1@shakespeare.lit - Spells - true - 3 - cn=witches,dc=shakespeare,dc=lit - en - http://www.shakespeare.lit/chatlogs/coven/ @@ -1213,7 +1220,7 @@ label='Maximum Number of History Messages Returned by Room'> 50 - xmpp:pubsub.shakespeare.lit?;node=the-coven-node @@ -1449,7 +1456,7 @@ ]]> -

If the user has connected using a MUC client (as indicated on joining the room by inclusino of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.

+

If the user has connected using a MUC client (as indicated on joining the room by inclusion of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.

- + @@ -2212,7 +2219,7 @@
  1. Creates a new multi-user chatroom
  2. Sends history of the one-to-one chat to the room (this is purely discretionary; however, because it might cause information leakage, the client ought to warn the user before doing so)
    3. -
  3. Sends an invitation to the second person and the third person, including a <continue/> element (optionally including a 'thread' attribute).
    4. +
  4. Sends an invitation to the second person and the third person, including a <continue/> element (optionally including a 'thread' attribute).

Note: The new room SHOULD be non-anonymous and MAY be an instant room as specified in the Creating an Instant Room section of this document.

Note: If the one-to-one chat messages included a &THREAD; element, the person who creates the room SHOULD include the ThreadID with the history messages, specify the ThreadID in the invitations as the value of the <continue/> element's 'thread' attribute, and include the ThreadID in any new messages sent to the room. Use of ThreadIDs is RECOMMENDED because it helps to provide continuity between the one-to-one chat and the multi-user chat.

@@ -2615,7 +2622,7 @@ to='hag66@shakespeare.lit/pda' type='unavailable'> - @@ -2630,7 +2637,7 @@ to='hag66@shakespeare.lit/pda' type='unavailable'> - @@ -2641,7 +2648,7 @@ to='crone1@shakespeare.lit/desktop' type='unavailable'> - @@ -2651,7 +2658,7 @@ to='wiccarocks@shakespeare.lit/laptop' type='unavailable'> - @@ -3004,9 +3011,9 @@ Voice request - To approve this request for voice, select + To approve this request for voice, select the "Grant voice to this person?" - checkbox and click OK. To skip this request, + checkbox and click OK. To skip this request, click the cancel button. @@ -3292,7 +3299,7 @@ - Not so worthy after all! + Not so worthy after all! @@ -3482,7 +3489,7 @@ - A worthy witch indeed! + A worthy witch indeed! @@ -3532,7 +3539,7 @@ - Not so worthy after all! + Not so worthy after all! @@ -3643,7 +3650,7 @@ To approve this registration request, select the "Allow this person to register with the room?" - checkbox and click OK. To skip this request, click the + checkbox and click OK. To skip this request, click the cancel button. @@ -4472,7 +4479,7 @@ - Not so worthy after all! + Not so worthy after all! @@ -4649,7 +4656,7 @@ - Not so worthy after all! + Not so worthy after all! @@ -4871,7 +4878,7 @@

The "roominfo" data form used in extended service discovery can result in information leaks, e.g., the current discussion topic (via the "roominfo_subject" field). The same is true of service discovery items (disco#items) requests from outside the room (which could be used to discover the list of room occupants).

-

Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.

+

Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.

 @@ -5023,7 +5030,7 @@ Multi-User Chat (MUC) room or admin approval of user registration requests. - @@ -5061,7 +5068,7 @@ http://jabber.org/protocol/muc#request XEP-0045 - Forms enabling voice requests in a + Forms enabling voice requests in a Multi-User Chat (MUC) room or admin approval of such requests. @@ -5206,11 +5213,11 @@ presence Removal from room - Inform user that he or she is being removed from the room + Inform user that he or she is being removed from the room because of an affiliation change @@ -5397,7 +5404,7 @@ presence Removal from room - Inform user that he or she is being removed from the room + Inform user that he or she is being removed from the room because the room has been changed to members-only and the user is not a member @@ -5407,7 +5414,7 @@ presence Removal from room - Inform user that he or she is being removed from the room + Inform user that he or she is being removed from the room because the MUC service is being shut down @@ -5423,7 +5430,7 @@ -

The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.

+

The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.

@@ -5586,7 +5593,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld

  • A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type '/command parameter' in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.

  • A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the <show/>, <status/>, and <priority/> child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

  • A MUC service MAY choose to discard extended information attached to a &MESSAGE; stanza before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the Allowable Traffic section of this document.

    • -

  • A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked nickname as a reserved room nickname and MUST support the protocol specified in the Discovering Reserved Room Nickname section of this document.

    • +

  • A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked nickname as a reserved room nickname and MUST support the protocol specified in the Discovering Reserved Room Nickname section of this document.

    • @@ -6033,7 +6040,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld -