[AFS3-std] Re: rxgk CombineTokens and enctypes

[Benjamin Kaduk]

On Wed, 7 Nov 2012, Andrew Deason wrote:

> On Wed, 07 Nov 2012 11:43:15 -0500
> Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>
>> I'd rather not see the generic operation go away just because one
>> component of one application chooses for convenience to do the same
>> thing in an RPC that also does two other things.  More generally,
>> while AFS is certainly a driving force for Rx, as someone who has
>> written a number of other Rx-based applications, I think there is
>> great value in maintaining the notion that Rx is its own protocol with
>> AFS as one application, rather than just some of the common bits of
>> the various AFS protocols with no concept of layering or abstraction.
>
> Sure. What I'm saying is, any application, AFS or not, needs to define
> what this RPC means; it's not usable on its own. So, if you have this
> generic RPC that is used by different applications, I see two
> annoyances/issues:
>
> 1. You have the same RPC with the same name, code point, and arguments,
> which does potentially very different things. That could be confusing.
>
> 2. Each application needs to specify the behavior of the CombineTokens
> RPC for that application anyway. And if you need to add any input or
> output arguments, you need to make an entirely new RPC. So trying to
> define an application-agnostic one seems like it might be a waste of
> time.
>
> It just doesn't seem like reasoning about the details of the result of
> "combining tokens" is meaningful, when "combining tokens" is
> intentionally undefined and could be _anything_.
>
>
> This doesn't seem worth the time spent on it, though. I'm just trying to
> explain what I mean; if people just plain disagree, I won't push it. If
> nobody else wants to go in this direction, I'm fine enough with any of
> the suggested additional text from Ben/Simon/me on this. (The "the new
> identity is an application-specific combination [...]" stuff.)

I see valid arguments both pro- and anti- a generic CombinedTokens, and 
haven't had much time to think about it this week since I'm at the IETF 
meeting.  It does seem, though, that the app-defined behavior is 
restricted to the server, since the client treats tokens as opaque and 
just passes them from server to server.  It is probably possible to have 
an application client that knows it wants to combine identities but does 
not need to care about the details of how the identities are combined.

-Ben