Re: [Imap-protocol] Login referrals resurrection?

On Tue, Jan 14, 2014 at 1:43 PM, Bron Gondwana <[email protected]> wrote:

> On Wed, Jan 15, 2014, at 08:32 AM, Timo Sirainen wrote:
> > I started wondering today if it would be a good idea to bring back the
> login referrals, only a little bit changed from their original behavior. I
> guess originally they didn't really get used because few clients supported
> them and proxying works for everyone. But nowadays many larger
> installations have IMAP proxies and backends in multiple data centers and
> even though everything works, doing unnecessary proxying between data
> centers increases latency and often also costs money. Using DNS to give the
> correct data center IP based on the source IP might work for some users,
> but that's somewhat difficult to set up and likely won't work very well for
> the increasing number of mobile users. So what if we got the most popular
> clients to implement support for login referrals and use them?
> >
> > Problem 1: LOGIN tagged OK [REFERRAL] reply conflicts between
> Lemonade-required OK [CAPABILITY] reply.
> >
> > So either one of them needs to be moved to an untagged OK reply. RFC
> 2221 only talks about tagged OK reply, while RFC 5550 makes it possible to
> use untagged OK reply. But I'm a bit worried about changing this now, there
> may well be clients that handle only the tagged OK [CAPABILITY] while there
> are almost no clients that handle [REFERRAL] anywhere. So my preferred
> server reply would be:
> >
> > * OK [REFERRAL imap://user;AUTH=*;us1.imap.example.com/] Use this
> server for decreased latency
> > a OK [CAPABILITY ...] Logged in.
> >
> > Problem 2: RFC 2221 specified OK [REFERRAL] to mean that user's
> mailboxes aren't on this server, but some shared mailboxes are.
> >
> > Instead now the OK [REFERRAL] should simply be a suggestion to the
> client to connect to the specified server to get better latency, but it
> would work just as well to just ignore it and keep using the current
> server. In fact the client likely shouldn't reconnect at all, but just
> create all future connections using the referral's server. If the referral
> server ever fails, the client should connect back to the original server.
> >
> > Does anyone else think this would be worth maybe writing a new updated
> RFC2221bis and trying to convince client developers to implement it?
>
> Any particular reason to reuse the same name with an altered meaning
> rather than coming up with a new name for this?  e.g.
>
> * OK [CANONICAL imaps://user;AUTH=*;us1.imap.example.com/] home server is
> us1
>
> Bron ( I can't believe you're sending the user to a non-ssl URL in this
> day and age! )
>

I'm sure he implied STARTTLS, that is, after all, the preferred way for
IETF protocols to work.  Or is that the difference between simap and imaps?

Brandon

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol