[Standards-JIG] UPDATED: JEP-0100 (Gateway Interaction)

Richard Dobson richard at dobson-i.net
Wed Mar 10 19:41:26 UTC 2004


> > On Wed, Mar 10, 2004 at 05:45:29PM +0100, Ralph Meijer wrote:
> > > Couldn't we just go and push using %nn escaping, while also trying to
support
> > > the old use of %?
> >
> > Certainly because none of the stuff following % as it is currently
> > used (msn.example.com, icq.example.com, yahoo.example.com,
aim.example.com)
> > is in the [0-9a-f] range.
>
> My understanding is that your MSN address can be user at host where the
> host part is not limited to msn.com but could be any valid domain. So
> let's say that your domain name is 2f.com; now the old-style % escaping
> results in a JID of user%2f.com at msn.example.com -- which is potentially
> problematic because %2f maps to ' in the %hexhex escaping recommended by
> RFC 2718, no? But we don't mean user@'.com we mean user at 2f.com. And so
> it goes...

Yup thats a problem, but there is only a very remote problem of it really
causing serious problems, IMO I would agree with the rest that it is far
cleaner to use the standard URI escaping mechanism, I would have to agree
that it is far better to sort it out now than wait until some later point
down the line, the longer we leave it the worse it is going to be, since we
are now documenting gatewaying properly now its far better to make it the
best we can than having to be too tightly restricted by bad legacy hold
overs. Using standard escaping also gives us the benefit of being able to
represent reliably in clients what ID in the legacy network the JID
represents, e.g. if it is an MSN ID you could show the end user the
user at hotmail.com address along with an MSN icon which is far more user
friendly for novice/new users, and you can do it using a common code base
for all transport types in a nice clean way.

> And then of course there is the real world: who is planning to write
> code for msn-t? ;-)

It surely wouldnt be "that" hard for someone to patch MSN-T to support this
concidering.

Richard




More information about the Standards mailing list