[6132] in Kerberos
Re: K5 recvauth
daemon@ATHENA.MIT.EDU (Jonathan Kamens)
Sun Nov 5 16:59:04 1995
To: kerberos@MIT.EDU
Date: 5 Nov 1995 19:07:42 GMT
From: jik@jik.datasrv.co.il (Jonathan Kamens)
In article <47gun2$221t@troy.la.locus.com>, hyc@troy.la.locus.com (Howard Chu) writes:
|> This is a nice, reasonable argument, but still it does nothing to address the
|> problem of version updates.
Well, then, rename recvauth to recvauth_extended and modify it so that it
takes a null-terminated array of char *'s, any of which can be sent by the
client, instead of a single char * as the version string, and a char array
(at least as big as strlen(the longest version string) + 1) into which the
version string sent by the client is copied. Then, implement recvauth's
current behavior as a wrapper around recvauth_extended, and submit the
changes to MIT; I'm sure they'll be glad to accept them.
That way, an application programmer can make a new server backward-compatible
with old clients by (a) making sure the new server tells recvauth_extended to
accept the version strings sent by old clients and (b) making sure that the
server knows how to process requests from the client differently when it sends
an old version string.
In short, you've made an argument for perhaps making the interface to the
sendauth/recvauth protocol more flexible on the server side, but you haven't
made an argument for changing the protocol.
