[306] in Zephyr Mailing List
Re: undead zwgcs
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Sep 21 04:25:04 1998
From: Ken Raeburn <raeburn@MIT.EDU>
To: zephyr@MIT.EDU
Date: 21 Sep 1998 04:20:52 -0400
In-Reply-To: Greg Hudson's message of "Thu, 17 Sep 1998 11:28:15 EDT"
> You have to understand what's going on and think about it. The code
> was designed (not by me) with the assumption that each machine has a
> single IP address; that's not just an accident of the implementation.
> Most likely, the data structures in question will have to be modified
> to accomodate a list of IP addresses instead of just one.
Not just data structures, but the protocol as well. The use of the
host address (note the singular form) in the "unique id" field has (at
least in MIT usage) turned into a sort of location indicator,
resulting in hacked applications to spoof the value, and (I think)
restrictions in the server on what values can be used.
Multi-homed hosts aren't incredibly uncommon, and multiple addresses
per host may become more common with ipv6, but I think they're still
well in the minority today. Maybe this release can be shipped and
then the design issues tackled? I think you're looking at a
non-trivial amount of development work, which probably shouldn't be
thrown in last thing before a release is cut. Just call it a feature
(er, I meant to say, document the bug) and ship it.
There are a lot of other things for which the Zephyr design has little
or no allowance, or at least doesn't address. Most of them are
probably because the issues just didn't exist, or didn't seem worth
addressing, a decade ago; a lot of that has changed, and it's probably
past time for a new rev of the protocol. For example: NAT, IPv6 (or
other transport layers), Kerberos 5 (or other authentication systems,
or multiple-system schemes like GSSAPI or SASL), message privacy,
inter-realm, handling congestion or lossy or low-bandwidth or
high-latency links, highly dynamic access control, interfacing with
other chat systems, proxy interfaces, prioritization of messages. To
name a few. And the hex encoding it currently uses for some data
fields is a needless waste of space (though netascii makes sense, for
text fields). Etc.
Ken
