[AFS3-std] Re: XCB union decoding (was Re: Encoding IPvN addresses)

[Andrew Deason]

On Fri, 11 Feb 2011 22:17:40 +0000
Tom Keiser <tkeiser@sinenomine.net> wrote:

> I'm quite keen on removing the proprietary union-plus-opaque-default
> specification from my I-D in favor of this generic new union type.
> However, this leads to a question: would it be desirable to defer
> semantics (such as criticality) to the discriminator namespace
> definition in each I-D so that the base union I-D remains very simple
> and generic, or would it be better to split the discriminator
> namespace up into several regions along a few axes

I already somewhat discussed this with Tom, but to say it more
publically... I favor just letting the discriminator namespace be
handled by the relevant standard, and not specifying it for everyone
now. This is both in the interests of getting a base type available more
quickly, but also I think deferring this to the individual RPCs or data
types is more flexible. For example, I could in theory imagine some RPC
that wants to use some discriminators that are "critical", but failing
to recognize some results in a different error behavior than others.

e.g. "If you get a discriminator you don't understand in the range A-B,
stop the operation and issue an error; if you get a discriminator you
don't underand in the range C-D, continue the operation to completion
but notify the peer you didn't understand the discriminator. If you
don't understand the discriminator and it's outside of those ranges,
just ignore it."

And some users may not have a need for 'critical' tags at all; it's hard
for me to imagine VLDB address listing to need them. While the namespace
is rather huge, carving it up into sections does unnecessarily limit how
many discriminators such things can use.

-- 
Andrew Deason
adeason@sinenomine.net