[AFS3-std] Re: Encoding IPvN addresses

[Andrew Deason]

On Thu, 10 Feb 2011 16:05:48 -0500
Jeffrey Hutzelman <jhutz@cmu.edu> wrote:

> Sure, we could build a complex type that encodes an address plus a
> port plus lets you build arrays or lists or heirarchies or what have
> you.  But why?  All of those things can be done with the existing
> tools.  I'd like to limit ourselves to creating a simple tool to solve
> a simple problem, which is the lack of extensibility in address types.

Doing something like this allows for space-optimization in what is the
most common case for us; it doesn't _preclude_ other uses. It's not
really any different if the encoder doesn't want to use it; the only
difference is that e.g. the opaque for an IPv4 type may include multiple
addresses instead of just one. The only downside here is the additional
complexity, which seems very small.  You can still encode several
addresses that all have different address types.

But it's just an optimization. I certainly don't think it's required,
and the benefit may be so small that it's not even worth the time
talking about. So I will readily concede given any opposition.

> How about a new type of union that always sends the length of the
> encoded data?

This would make things easier in many other situations as well, so I'm
all for it. Would that mean we're diverging from regular XDR, though?
(Does it matter?)

-- 
Andrew Deason
adeason@sinenomine.net