[239] in Zephyr Mailing List
Re: Interrealm support issues
daemon@ATHENA.MIT.EDU (Derrick J Brashear)
Fri Jan 3 09:46:18 1997
Date: Fri, 3 Jan 1997 09:43:00 -0500 (EST)
From: Derrick J Brashear <shadow@DEMENTIA.ORG>
Reply-To: Derrick J Brashear <shadow@DEMENTIA.ORG>
To: zephyr@MIT.EDU
In-Reply-To: <9701031431.AA03343@portnoy.MIT.EDU>
> For example, we should be able to setup a SIPB.MIT.EDU zephyr realm
> which uses the ATHENA.MIT.EDU kerberos realm for authentication
> (similar to how the sipb.mit.edu AFS cell uses ATHENA.MIT.EDU kerberos
> authentication).
Been there done that. You won't find me arguing about this.
> To do inter-realm zephyr properly, we need, most likely, to change the
> protocol. If we change the protocol, then none of the current
> application will work, so we can feel free to change how zephyr
> behaves (we can always provide backwards compatibility in the local
> server). The problem is that unless we make assumptions that probably
> aren't valid, the protocol doesn't have enough fields to support
> everything we want to do.
True, again.
> If we're going to change the protocol, we might as well fix all of the
> protocol problems, too. I've heard ideas murmured about other
> possible changes to the protocol. Perhaps those people can chime in
> with their ideas?
The current Z{Make,Read}Ascii need to die. A content type field should be
considered, at least, so that if I wanted to write what would essentially be a
MIME-capable Zephyr client I don't have to overload the body.
> If we are not going to change the protocol, then we must make the
> assumption that zephyr realm == zephyr kerberos realm == recipient
> principal realm.
In which case it again becomes an argument of network bandwidth versus trust.
The server to server model has one other advantage I forgot to mention, and
that is simplicity; I need only know a single local server.
-D
