[AFS3-std] Re: rxgk CombineTokens and enctypes

[Andrew Deason]

On Sat, 3 Nov 2012 15:28:25 -0400 (EDT)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> On Sat, 3 Nov 2012, Simon Wilkinson wrote:
> 
> >>> 1) Whichever one the server picks from the client-provided list.
[...]
> I think this is the least bad way to get to a fully/usefully specified
> CombineTokens operation.  (That is, I think we should do it.)

I don't have much to say here, but I would like to +1 this.

On Sat, 3 Nov 2012 19:48:17 +0000
Simon Wilkinson <simon@sxw.org.uk> wrote:

> > A zero-length new_token would indicate failure, but there might be
> > some sense in reusing the RXGK_ClientInfo errorcodes here.
> 
> In AFSCombineTokens, a zero length new_token has a specific meaning -
> it means "the target endpoint doesn't support rxgk, so you can safely
> fallback to rxkad". I don't think fallback is necessarily what you
> want if there is an error in the negotiation, so I would agree that we
> should include an error code here. Of course, this reopens the can of
> worms of assigning meaning to these error codes.

Well, keep in mind we don't have to cover all possible errors at first;
we can always add more later.

It's easy enough to divide the 'errorcode' field into standard and
application-specific regions (e.g. 0-0x7FFFFFFF, 0x80000000-0xFFFFFFFF)
if we want to use 'errorcode' for both. Or just have two separate fields
(application-specific vs not); either way sounds fine.

-- 
Andrew Deason
adeason@sinenomine.net