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

JD Conley jd.conley at coversant.net
Fri Jan 14 21:11:32 UTC 2005

> -----Original Message-----
> From: standards-jig-bounces at jabber.org [mailto:standards-jig-
> bounces at jabber.org] On Behalf Of Peter Saint-Andre
> Sent: Thursday, January 13, 2005 12:49 PM
> To: standards-jig at jabber.org
> Subject: [Standards-JIG] Re: Refactor: Converting a One-to-One Chat
> aConference (JEP-0045)
> In article
> <97B71C0C860DEC40A993AB9F7F0D4335015F5B at fattire.winfessor.com>,
>  "JD Conley" <jconley at winfessor.com> wrote:
> > <presence
> >     from='crone1 at shakespeare.lit/desktop'
> >     to='crone1 1104537600 1 at macbeth.shakespeare.lit/firstwitch'>
> >   <x xmlns='http://jabber.org/protocol/muc'>
> >     <continue />
> >   </x>
> > </presence>
> >
> > . . .
> >
> > 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,
> > the instant room defaults, and not require any configuration.  It is
> > RECOMMENDED that the service configure the room as non persistent,
> > anonymous, private, and members only. The service MAY optionally
> > disallow further configuration of the room by the owner.
> Well, it seems that one could apply this reasoning to instant rooms in
> general if you want to save stanzas....
> <presence to='service'>
>   <x xmlns='http://jabber.org/protocol/muc'>
>     <instant/>
>     <nick>mynick</nick>
>     <continue/>
>   </x>
> </presence>
> The service creates a default room, sends you a presence stanza from
> randomroom at service/nick, and you're in.

Why won't the following suffice?  If instant rooms are not allowed the
service will return the status code on the presence stanza (as it does
anyway) signaling the room needs to be configured.

     from='crone1 at shakespeare.lit/desktop'
     to=room at service/nick'>
   <x xmlns='http://jabber.org/protocol/muc'>
     <instant />

> But that seems rather hackish to me and causes service components to
> grovel through more of the initial presence packet in order to know
> to proceed, rather than waiting for the room configuration form as
> currently do.

I thought the point was to make this easier for client developers.  Us
service developers are used to complications.  Besides, from the service
perspective, how is configuring a room based on the initial presence
packet any different than configuring it based on an IQ set asking for
an instant room?  We already have to inspect the join request for
message history settings, internal policy checking, etc.  Checking for
one more element to auto-configure a room is not a big deal.

> A cost-benefit analysis is required, methinks, before we move forward
> with this. I'd be curious what our MUC component developers think. All
> of this room creation stuff (at least for instant rooms in the
> "continue" use case) should be hidden from the user anyway, so it
> to me that we're talking about potentially making things easier for
> client developers and harder for the service developers. My initial
> feeling is that this is "six of one, half a dozen of the other", and
> not even convinced that what you propose would be easier for client
> developers, since now they need to special-case some incoming presence
> stanzas and such. How much are we really saving?

Again, I thought the whole point of Jabber was simple clients.  From the
service perspective this isn't a huge leap, but it does make the client
implementation less complicated.  It's one less IQ they need to track a
response for.  They're already waiting for the room to send them

Configuring a room is too complicated for most users.  Clients will, and
some already do, auto-configure rooms with an instant room request by
default anyway.  Why not just eliminate the IQ round trip?

What additional special casing for incoming presence packets will
clients need to do?  It seems to me that incoming presence processing
will be the same.


More information about the Standards mailing list