[AFS3-std] Re: Encoding IPvN addresses

[Andrew Deason]

On Fri, 11 Feb 2011 08:37:52 +0000
Simon Wilkinson <simon@sxw.org.uk> wrote:

> On 11 Feb 2011, at 03:53, "Matt W. Benjamin" <matt@linuxbox.com> wrote:
> 
> > yes.  at this point, an rpc-l primitive and corresponding rxgen
> > support seem like something we would need to enable manageable and
> > consistent elaboration of different union types, if I at all
> > understand the issues.  I'm happy to make xcb conformant with this,
> > for example.  I am not interested in seeing this wheel invented
> > several times.

Is XCB appropriate for this? I wouldn't have thought we'd want a client
to be able to able to interpret the callback message if it doesn't
understand the callback type. (Probably don't want to muddle this thread
with discussion of that, though...)

> Coming at this from a slightly different angle, I think we have an
> immediate need for a new address primitive. We can create, and
> implement, one relatively easily. I don't see doing so as reinventing
> the wheel.

We have a need for both; we already have outstanding drafts that are
working around the limitation of not having a TLV structure. I'm not
sure I get the perceived notion that it takes longer that way. We
already wanted to use the exact same structure for addresses, so just
put both types in the same draft. Whereas previously you described the
whole thing as an address, just stop right before you get to the
address-specific parts, make a new section and a new type, and keep
describing it. (Unless you are actually suggesting using the
opaque-based approach?)

And I haven't yet heard anything even remotely contentious about a TLV
structure (except maybe the name?). On the wire, it's exactly the same
as a union, except you always encode the arm length, and the default arm
is an implicit opaque. That's it.

-- 
Andrew Deason
adeason@sinenomine.net