[Standards-JIG] Re: [Members] Re: MOTION: JEP-0106 (JID Escap ing)

Richard Dobson richard at dobson-i.net
Wed Mar 31 17:42:15 UTC 2004


> > Well you need to think about it more, when a client queries
> > their server for the list of services it provides (disco /
> > browse / agents) it will detect the available transports and
> > if one of the transports is say msn.domain.com and it can
> > detect that it is an msn transport the client then knows that
> > any contacts with a domain of msn.domain.com are msn
> > transport contacts, it can then do the transport JID decoding
> > and put in the helpful stuff I decribed above, so see it can
> > work in an easy and generic way.
>
> People use gateways on non-local servers.  Disco/agents/browse don't help.

But not many people necessarily will and certainly I very much doubt that
novice users would, there are even clients out there that dont let you
really use non-local transports. Also there is no reason we cant have a
jabber:iq:private storage profile for storing the details of what transports
a user is using which solves the problem of non-local transports.

> > Ah I see what you mean now, that can be easily solved too,
> > you just disco the MSN contacts when they come online to get
> > their current name and then update your roster if the name is
> > different. Also longer term as this is a general problem with
> > Jabber in that you have no way of notifying your contacts
> > that you have changed your nickname we might want to develop
> > a pubsub mechanism to let people subscribe to your nickname
> > and receive immediate updates when you change it.
>
> Please, no.  If you must do this sort of thing, it is what JEP-0115 was
> designed for.  We certainly don't need more c2c queries happening at every
> login, like some older versions of Psi still in the wild do.

How does JEP-0115 help us with sending nickname updates? I thought it was
for client capabilities.

Richard




More information about the Standards mailing list