[260] in Release_7.7_team
Re: telnet -safe as default
daemon@ATHENA.MIT.EDU (John Hawkinson)
Wed Jan 18 03:19:01 1995
Date: Wed, 18 Jan 1995 03:18:50 -0500
To: cfields@MIT.EDU
Cc: release-team@MIT.EDU, krb-apps@MIT.EDU, brlewis@MIT.EDU, ghudson@MIT.EDU
In-Reply-To: "[259] in Release_7.7_team"
From: John Hawkinson <jhawk@MIT.EDU>
Preferatory comment: Remember that I'm an idealist here (!= release
engineer), and among other things, I would like all versions of telnet
to be consistant. So sue me :-)
Craig writes:
> On safe = 4:
>
> I agree with the idea that "safe" should mean what it says,
> and not "safe, well, maybe." I don't see any particular reason
> not to provide this functionality as a special option here at,
> MIT, distinct from "-ax." Since we bothered to add it in the
> first place, we ought to make it consistent with its name.
> Unless we want to call it "telnet -safer."
I think it's a was a bad idea to call the option -safe in the first place,
as it breaks the existing (i.e. getopt-based) paradigm for telnet options.
As such, I would not be surprised if the "other" telnets' maintainers would
refuse to integrate such an option. This would result in a functionality being
present only in the Athena telnet, which would be poor.
> On ax = 2:
>
> change the behaviour of existing command line options. If in
> the future -ax changes to 4, then we change change ours then
> to follow suit (with the usual documentation issues).
Fair enough. I guess this is the "we don't want to be the first implementation
to do this" problem. Hopefully I won't run into it everywhere...
> On old = 1:
>
> All I have in mind here is a way to provide the old behaviour
> in an option. I haven't actually thought much about the best
> way to do that. This is not likely to be it.
I think it's really poor to call it -old (again) because it breaks
compatibility with getopt-based telnets (i.e. all the others). Please
consider using a one-character option name or somesuch.
> I don't ever go for behaviour three because I don't want to create the
> _expectation_ of the user that if encryption isn't happening, they
> will be warned of it, because they may take it to other sites and get
> burned. This may or may not be worth being concerned with.
All I can say is: AAAAAAAAAAAAAAAAAARRRRRRRRRRRRRGHHH!
--jhawk
