[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

[Mircea Bardac]

On Saturday 19 May 2007 17:03:23 Mridul Muralidharan wrote:
> Mircea Bardac wrote:
> > Random resource strings confuses users who discover this option in the
> > jabber clients. On connection, some jabber servers offer a resource
> > string (generated with the resource provided by the client) or simply use
> > the resource string provided by the client.
>
> Trying to associate meaning with resource name, imo is a bad idea.
> Especially since there is no guarantee that the resource asked for by
> client would be granted to it by the server (server can change resource
> in bind response).
> So meaning for resource names is something that was never exposed as an
> interface - it is just an opaque string which identifies an endpoint for
> a bare jid.

Indeed. That's what I was also bringing in. This needs to be clarified for the 
future. I believe we can find information/tutorials on the net saying that 
jabber resources are a way to _describe an instance_.

The user should not know anything about the resource *id*. However, the user 
might want to know about the resource *description*, but we don't have such a 
thing (yet).

On Saturday 19 May 2007 17:03:23 Mridul Muralidharan wrote:
> Like you mention below, we have other means of identifying
> availability/status/priority, location, etc - resource is not the right
> place for this information.

Yes. I was just saying what the current situation is. We should not continue 
to encourage this.


On Saturday 19 May 2007 17:03:23 Mridul Muralidharan wrote:
> Mircea Bardac wrote:
> > 2. no resource id should be shown for the users available online -
> > recommend showing geo-loc information as an alternative (for example)
>
> There are usecases where it would become necessary for a user to
> explictly chat with a particular resource for a bare jid ... so
> completely hiding it away might break these cases.

True. Maybe we should have an optional resource description field somewhere. 
(or a way to query the client for this information - most likely).


On Saturday 19 May 2007 17:03:23 Mridul Muralidharan wrote:
> Mircea Bardac wrote:
> > 3. given the use of xmpp bind lately (GTalk), recommend using the same
> > chat window for the same user, if the user quit then returned (=only one
> > resource available all the time), with a warning or something similar
> > (showing new geo-loc if available) - it is very confusing to have a new
> > chat window opened for a contact and still have a window with the offline
> > resource available.
>
> About rebind : shouldn't this not happen in normal case ?

Well, yes - but would be easier for client devs to follow up a list of 
testcases and implement expected behaviour.

> Why would a user lose a session so frequently ?

Wireless.. or.. a user switching computers.


There could also be:

4. if there's a chat dialog opened with a resource which became offline and 
there are other resources available:
a) ask the user to pick another resource to continue or
b) pick the next available (by priority) resource



Regards,
Mircea