On Thu, Aug 26, 2010 at 12:48 PM, Jeffrey Hutzelman <[email protected]> wrote: > What I offer as an alternative is that mechanism-specific knowledge about > the format of raw-krb5 be confined to the implementations of those rx > security classes which use it; namely, rxkad and rxk5. These will already > require changes to support what I hope will end up being a common, > class-independent API to allow server application code to obtain the > client's authentication name, to be used in place of rxkad_GetServerInfo. At > least rxkad will already require code changes to report a krb5 principal > name as a single string, rather than performing the lossy krb5-to-krb4 name > conversion it does today. All I propose is that instead of merely returning > a string, it return an opaque name in the same form as would be used by > gss-krb5. >
Then this begs the question: how do you support a mixed environment of old (current) and new (revised) rxkad fileservers without creating additional confusion due to names being represented differently? -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
