[AFS3-std] Re: [OpenAFS-devel] Proposal for new ptserver RPC: pr_WhoAmI

Jeffrey Altman jaltman@secure-endpoints.com
Tue, 26 Jun 2007 15:26:10 -0400


Jeffrey Hutzelman wrote:
> 
> 
> On Tuesday, June 26, 2007 02:52:22 PM -0400 Jeffrey Altman
> <jaltman@secure-endpoints.com> 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
>> user@foo.bar.com 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?

Yes.

Jeffrey Altman
Secure Endpoints Inc.