RE: FW: I-D ACTION:draft-gahrns-imap-referrals-02.txt

[Steve Hole <[e-mail]>]

On Thu, 24 Apr 1997 10:53:38 -0700 "Mike Gahrns (Exchange)" 
<[e-mail]> wrote:

> 2) Distributed hierarchy where mailboxes may be scattered across several
> servers and we give a Mailbox referral

This is the really valuable thing I think.
 
> I am now thinking that maybe the draft should be split into two -  Login
> Referrals  and Mailbox Referrals
> 
> What would people think of this?

Well, I still think that mailbox distribution is valid in the presence of 
a global authentication framework (Kerberos).  I am not sure how that 
would solve the problem of distribution of mailbox space -- I would 
certainly wish to distribute in the presence of a global authentication 
namespace.   A login referral is really a service referral and I would 
suggest that Service Location (svrloc) would be a better way to handle 
that.

> > concerns. In short, I'd like to be able to _not_ support "remote" LIST
> > and LSUB, yet provide other referral mechanisms. Can this be 
> > accommodated?

Stuff deleted ...

> What I think would work, however, is to define a new Referrals List
> command called RLIST.  If a client supported mailbox referrals, and it
> was operating against a mailbox referrals enabled server, it would issue
> RLIST instead of LIST.  Everything about the two commands would be the
> same, but now remote mailboxes would be returned.
> 
> Would people be okay with this?


It would be really nice to have servers list mailbox referrals, but it 
should not be manditory (Mike's reasons are very valid).   It seems to me 
that this is a quality of service issue.  If the server can do mailbox 
list referrals, that is great. If it can't then the client will still find 
out when it tries to select the mailbox.  A good client really shouldn't 
make the referral transaction visible anyway.

The big issue from the client point of view is representing the "state" of 
the folder correctly and (perhaps) disabling or enabling functionality 
that is specific to a certain state.   For example a client would disable 
a "mailbox create" function if the mailbox is marked as \NoInferiors.   
That way a user can never attempt a create that will fail.   By having 
list referrals, it just makes the information to the client better (more 
intuitive) and avoids potential user surprise.   The client would still 
operate correctly in the end.   It will fail to open the folder and get a 
referral, which it may or may not be able to follow.

So, to summarize:

1.  I would not put in a special command.   The quality of information to 
the client is useful but not critical.   The server can either provide it 
or not. There is no special syntactic or semantic content that a client 
needs to process differently other than the referral syntax itself.   
The client simply needs to handle referrals, which it needs to handle 
anyway.

2.  I would relax the language to say MAY for listing.   If the server can 
do it, great.  I would like to use such a server.   For many sites it just 
wouldn't be necessary.   If the server can't support it, the client can 
still get the referral on select and act appropriately.

> So to recap:
> 
> 1) Propose to split the draft into a Login Referrals and a Mailbox
> Referrals Draft.

I don't think this is necessary (or even useful?).

> 2) Create a new command RLIST, that will include remote mailboxes in the
> LIST response.

I don't think this is useful.   The client can deal with a referral or 
not.   The server can issue referrals or not.   It is quality of service 
information.

Cheers.
---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [e-mail]
900 10040 - 104 St.		Phone: [phone]  
Edmonton, AB, Canada		Fax:   [phone]  
T5J 0Z6