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

Mridul Muralidharan mridul at sun.com
Tue May 29 19:06:17 UTC 2007


Adam Nemeth wrote:
> Hi,
> 
> On 5/29/07, Mridul Muralidharan <mridul at sun.com> wrote:
> 
>>
>> For most cases (I do agree, not all), why would a client need to
>> specifically address a resource ?
>> Communicating with the most available resource would happen
>> automatically while talking to bare jid...
>>
> 
> Here are my cases in a first thought:
>     - Capabilities (for voice, for certain XEP-support) - these can be
> taken to be granted

Use caps & rap (xep 168) ?

>     - Talking to my 'stayed-at-home' identity (my desktop computer from
> my mobile, for reading mails, messages, etc)

You mean me at domain/res1 talking to me at domain/res2 ? Like bots using jid 
? Can it not use Service discover extension (128) or caps ?
Most possibly I did not get the usecase here.

>     - Message has higher / lower priority than normal (=> send a funny
> link to my desktop, because it isn't as important, even when mobile is
> higher priority currently; send an alert to my cellphone, because it
> beeps, even it has less priority for comfort reasons)
> 

caps/rap again ?

But these are very specific and possibly contrived usecases just to 
bring out a usecase for resource.
My point is, just because I have "me at domain/mobile" does not mean I am 
on a mobile ... it will be better to query the resource to find out if 
it really is a mobile.
If the user already knows that a specific full jid corresponds to a 
session, that is a different case - and possibly the only valid one imo.

In most other cases, alternatives to using resource to convey meaning 
makes more sense since it is authoritative and declared information : 
while using resource is relying on potentially ambiguous data.


Though, as Justin mentioned, resources have been around for ages - and 
so users have unfortunately become familiar with it to the point of 
associated meaning with it.

Regards,
Mridul

> 




More information about the Standards mailing list