On Tuesday, June 26, 2007 02:52:22 PM -0400 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman wrote:
Discussion of protocol issues should go to afs3-standardization.
I have copied this message there.
Agreed. Both lists is fine for now.
Please make use of the flags to indicate whether the user is
registered and/or should try self-registration, rather than inferring
that from the returned ID. I say this for a couple of reasons...
[pruned]
In fact, I'm beginning to think the result should separately indicate:
- the viceID currently used for that client (possibly ANONYMOUSID)
- the name currently used for that client (possibly system:anyuser)
- the name the client may self-register with (possibly empty)
- whether the client is registered
- whether the client may self-register
Comments?
We can have two flags:
PR_WAI_IS_REGISTERED 0x0001
PR_WAI_MAY_REGISTER 0x0002
PR_WAI_IS_REGISTERED is set when the viceID specified is assigned to
that entity and not to a group
PR_WAI_MAY_REGISTER is set when the ptserver determines that there is a
name that could be registered but which doesn't exist in the database
AND if such a request was received it could in fact be processed. There
is no point encouraging the client to attempt to register
[EMAIL PROTECTED] if the configuration of the server would not permit it.
I think that adding the second name field is a good idea.
OK, so we return an "effective" ID and name, and a flag that indicates
these belong specificaly to the client.
And then we have a "potential" name, and a flag that indicates that
registration of that name by this client will probably succeed.
Yes?
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
