From 486b73e5712d3aa84101df090e7519e054856aa2 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 15 Nov 2006 23:54:16 +0000 Subject: [PATCH] 3066 to 4646 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@184 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0045.xml | 11 +++++++---- xep-0071.xml | 2 +- xep-0085.xml | 2 +- xep-0152.xml | 2 +- xep-0154.xml | 4 ++-- xep-0177.xml | 1 - xep-0183.xml | 16 ++++++++-------- xep.ent | 1 + 8 files changed, 21 insertions(+), 18 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 21eddac0..124cc0ef 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -385,7 +385,7 @@ -

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types. These extensions are implemented using protocol elements qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).

+

Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.

This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments outside of Jabber (e.g., Internet Relay Chat as defined in &rfc1459; and its successors).

@@ -397,6 +397,7 @@
  • Security and encryption at the level of a room or service
  • Advanced features such as attaching files to a room, integrating whiteboards, and interfacing with audio chat services
  • Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)
    • +
  • Mirroring or replication of rooms among multiple MUC deployments

    • This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by Jabber client and component developers alike. Future specifications may of course address the topics mentioned above.

     @@ -436,6 +437,7 @@
  • moderated or unmoderated
  • non-anonymous or semi-anonymous
    • +

    The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).

    @@ -1513,7 +1515,8 @@ ]]>

    Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the &ROOMJID; to which the user's client has sent directed presence.

    -

    If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.

    +

    It is possible that a user may not be able to gracefully exit the room by sending unavailable presence directly to the room. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 3921). If the user's server goes offline or connectivity is lost between the user's server and the MUC service to which the user is connected (e.g., in federated communications), the MUC service is responsible for monitoring error stanzas it receives in order to determine if the user has gone offline. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.

    +

    Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.

    A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).

    @@ -1600,7 +1603,7 @@ ]]> -

    However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the Nickname Conflict section of this document for details.

    +

    However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the Nickname Conflict section of this document for details.

    If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a ¬acceptable; error condition:

    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 SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (remote server unreachable, user not found, etc.).

  • 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 &MESSAGE; stanzas 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 discard extended information attached to &MESSAGE; stanzas 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 down nickname as a reserved room nickname and MUST support the protocol specified in the Discovering Reserved Room Nickname section of this document.

    • diff --git a/xep-0071.xml b/xep-0071.xml index 1f725392..39cc4405 100644 --- a/xep-0071.xml +++ b/xep-0071.xml @@ -216,7 +216,7 @@

    These three aspects are defined in the three document sections that follow.

     -

    The root element for including XHTML content within XMPP stanzas is <html/>. This element is qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. From the perspective of XMPP, it functions as an XMPP extension element; from the perspective of XHTML, it functions as a wrapper for XHTML 1.0 content qualified by the 'http://www.w3.org/1999/xhtml' namespace. Such XHTML content MUST be contained in one or more <body/> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace and MUST conform to the XHTML-IM Integration Set defined in the following section. If more than one <body/> element is included in the <html/> wrapper element, each <body/> element MUST possess an 'xml:lang' attribute with a distinct value, where the value of that attribute MUST adhere to the rules defined in &rfc3066;. A formal definition of the <html/> element is provided in the XHTML-IM Wrapper Schema.

    +

    The root element for including XHTML content within XMPP stanzas is <html/>. This element is qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. From the perspective of XMPP, it functions as an XMPP extension element; from the perspective of XHTML, it functions as a wrapper for XHTML 1.0 content qualified by the 'http://www.w3.org/1999/xhtml' namespace. Such XHTML content MUST be contained in one or more <body/> elements qualified by the 'http://www.w3.org/1999/xhtml' namespace and MUST conform to the XHTML-IM Integration Set defined in the following section. If more than one <body/> element is included in the <html/> wrapper element, each <body/> element MUST possess an 'xml:lang' attribute with a distinct value, where the value of that attribute MUST adhere to the rules defined in &rfc4646;. A formal definition of the <html/> element is provided in the XHTML-IM Wrapper Schema.

    Note: The XHTML <body/> element is not to be confused with the XMPP <body/> element, which is a child of a &MESSAGE; stanza and is qualified by the 'jabber:client' or 'jabber:server' namespace as described in &xmppim;. The <html/> wrapper element is intended for inclusion only as a direct child element of the XMPP &MESSAGE; stanza and only in order to specify a marked-up version of the message &BODY; element or elements, but MAY be included elsewhere in accordance with the "extended namespace" rules defined in the XMPP IM specification.

    Until and unless (1) additional integration sets are defined and (2) mechanisms are specified for discovering or negotiating which integration sets are supported, the XHTML markup contained within the <html/> wrapper element MUST NOT include elements and attributes that are not part of the XHTML-IM Integration Set defined in the following section, and any such elements and attributes MUST be ignored if received (where the meaning of "ignore" is defined by the conformance requirements of Modularization of XHTML, as summarized in the User Agent Conformance section of this document).

     diff --git a/xep-0085.xml b/xep-0085.xml index 9416fcae..1e044572 100644 --- a/xep-0085.xml +++ b/xep-0085.xml @@ -234,7 +234,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
  • If the Contact replies to the initial content message but does not include a chat state notification extension, the User MUST NOT send subsequent chat state notifications to the Contact.
  • If the Contact replies to the initial content message and includes an <active/> notification (or sends a standalone notification to the User), the User and Contact SHOULD send subsequent notifications for supported chat states (as specified in the next subsection) by including an <active/> notification in each content message and sending standalone notifications for the chat states they support (at a minimum, the <composing/> state).
    • -

    The foregoing rules imply that the sending of chat state notifications is bidirectional (i.e., both User and Contact will either send or not send chat state notifications) rather than unidirectional (i.e., one of the conversation partners will send chat state notifications but the other will not); this is intentional.

    +

    The foregoing rules imply that the sending of chat state notifications is bidirectional (i.e., both User and Contact will either send or not send chat state notifications) rather than unidirectional (i.e., one of the conversation partners will send chat state notifications but the other will not); this is by design.

    diff --git a/xep-0152.xml b/xep-0152.xml index ab3f5a80..afef76e4 100644 --- a/xep-0152.xml +++ b/xep-0152.xml @@ -67,7 +67,7 @@ ]]>

    When publishing reachability addresses, the <reach/> element MUST contain at least one <addr/> element. Each <addr/> element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.

    -

    The <addr/> element MAY contain one or more <desc/> children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc3066; (although the default language MAY be specified at the stanza level; see Section 9.1.5 of &rfc3920;). In order to preserve bandwidth, the <desc/> element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using personal eventing.

    +

    The <addr/> element MAY contain one or more <desc/> children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc4646; (although the default language MAY be specified at the stanza level; see Section 9.1.5 of &rfc3920;). In order to preserve bandwidth, the <desc/> element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using personal eventing.

    diff --git a/xep-0154.xml b/xep-0154.xml index 92f838ba..90eb3361 100644 --- a/xep-0154.xml +++ b/xep-0154.xml @@ -1521,7 +1521,7 @@

    Some people know more than one language, but less than well (e.g., the person may not be able to speak fluently). The definition of "less well" is left to the user.

    -

    The value of this field MUST be an abbreviation for a language as specified in &rfc3066;.

    +

    The value of this field MUST be an abbreviation for a language as specified in &rfc4646;.

    The Data Forms field that represents a language known less that well is "languages_lesswell".

    @@ -1533,7 +1533,7 @@

    Everyone knows at least one language well (e.g., they are able to speak or write the language with a fair degree of fluency). Determination of whether someone knows a language "well" or "fluently" is left to the user.

    -

    The value of this field MUST be an abbreviation for a language as specified in RFC 3066.

    +

    The value of this field MUST be an abbreviation for a language as specified in RFC 4646.

    The Data Forms field that represents a language known well is "languages_well".

    This field maps to:

      diff --git a/xep-0177.xml b/xep-0177.xml index f29b32cd..8a4c1f75 100644 --- a/xep-0177.xml +++ b/xep-0177.xml @@ -111,7 +111,6 @@ - ]]>

      The initiator MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).

      diff --git a/xep-0183.xml b/xep-0183.xml index 77177227..81548ec3 100644 --- a/xep-0183.xml +++ b/xep-0183.xml @@ -73,13 +73,13 @@
    • The 'time' attribute is used for diagnostics; the allowable values are "past", "present", and "future".
    - -

    As described in XEP-0166, to provisionally accept the session initiation request, the target entity returns an IQ-result:

    - +

    As described in XEP-0166, to provisionally accept the session initiation request, the receiver returns an IQ-result:

    + ]]> -

    To definitively accept the telepathy transport method, the target entity MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.

    - To definitively accept the telepathy transport method, the receiver MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.

    + ]]> -

    The initiating entity then acknowledges the target entity's acceptance:

    +

    The initiating entity then acknowledges the receiver's acceptance:

    ]]> -

    Now the initiating entity and target entity can begin sending appropriate psychical media over the negotiated ESP stream.

    -

    In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see XEP-0176 or XEP-0177 for examples).

    +

    Now the initiating entity and receiver can begin sending appropriate psychical media over the negotiated ESP stream.

    +

    In the event that the receiver cannot establish a channel, it SHOULD terminate the session (see XEP-0176 or XEP-0177 for examples).

    Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a <message/> element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.

    diff --git a/xep.ent b/xep.ent index f7c2fb8a..a2565ad4 100644 --- a/xep.ent +++ b/xep.ent @@ -395,6 +395,7 @@ RFC 4505 RFC 4505: The SASL ANONYMOUS Mechanism <http://www.ietf.org/rfc/rfc4505.txt>." > RFC 4566 RFC 4566: SDP: Session Description Protocol <http://www.ietf.org/rfc/rfc4566.txt>." > RFC 4622 RFC 4622: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) <http://www.ietf.org/rfc/rfc4622.txt>." > +RFC 4646 RFC 4646: Tags for Identifying Languages <http://www.ietf.org/rfc/rfc4646.txt>." >