[Standards-JIG] Refactor: Converting a One-to-One Chat into a Conference (JEP-0045)

JD Conley jconley at winfessor.com
Sat Dec 18 23:35:13 UTC 2004


The continue process needs to more clearly define limitations on room
history delivery and can also be improved in a few areas. We want to
make this as simple as possible for client users and developers alike.
My proposal below takes one step out of the process and locks down the
message history delivery a bit more.  I also included a recommended
practice for generating room names (which I'm not partial to at all, but
one should be included).

I propose the following:


The first person decides to include a third person in the discussion, so
she (or, more precisely, her client) does the following:

1. Creates a new room including a <continue /> flag.
2. Optionally sends history of the one-to-one chat to the room.
3. Sends an invitation to the second person and the third person,
including a <continue/> flag.

The RECOMMENDED process for creating the room name is as follows:
"[first person JID node]_[current local unix time]_[creation attempt]".
For example, a room created by "crone1 at shakespeare.lit/desktop" on
1/1/2005 at 00:00:00 SHOULD first attempt to create a room named
"crone1_1104537600_1". The first person's client MUST generate a new
unique room name if the name they have chosen is already in use and
continue this process until the room is created, the process is canceled
by the user, or a timeout period elapses.

Example 47. Continuing the Discussion I: User Creates Room

    from='crone1 at shakespeare.lit/desktop'
    to='crone1_1104537600_1 at macbeth.shakespeare.lit/firstwitch'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <continue />

. . .

The continue element signals to the service that the owner wishes to
continue an existing one-to-one chat.  This allows the service to
provision the room accordingly.  The service MAY have a different
default configuration for continued conversations than other newly
created rooms.  The service SHOULD immediately unlock the room, apply
the instant room defaults, and not require any configuration.  It is
RECOMMENDED that the service configure the room as non persistent, non
anonymous, private, and members only. The service MAY optionally
disallow further configuration of the room by the owner.

Example 48.  Continuing the Discussion II: Owner Sends History to Room

. . .

Note: Use of the Delayed Delivery protocol enables the room creator to
specify the datetime of each message from the one-to-one chat history
(via the 'stamp' attribute), as well as JID of the original sender of
each message (via the 'from' attribute). If discussion history is
desired, the room creator MUST send the complete one-to-one chat history
before inviting additional users to the room, and SHOULD also send as
history any messages appearing in the one-to-one chat interface after
joining the room and before the second person joins the room; if the
one-to-one history is especially large, the sending client may want to
send the history over a few seconds rather than all at once (to avoid
triggering rate limits). The service SHOULD NOT add its own delay
elements (as described in the under Discussion History) to prior chat
history messages received from the room owner.

The service MUST NOT accept messages of type groupchat containing
delayed delivery elements from any occupant other than the room owner,
or in any rooms which were not created with the <continue /> flag, or
after any users other than the initial owner have joined the room. The
service MUST respond with a bad-request stanza error to such messages
and MUST NOT broadcast the message to room occupants.

. . .


Any thoughts?


More information about the Standards mailing list