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

[Tom Keiser]

On Fri, Feb 11, 2011 at 5:36 PM, Andrew Deason <adeason@sinenomine.net> wrote:
> 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.
>

Ok.  Both yours and JHutz's arguments make perfect sense.  Moving on
to the design, I've only had time to skim the conversations so far,
however I gather the proposal is to create a derivative of section
4.15 of rfc 4506, which adds a length field as follows (hence why
Andrew has been calling it a TLV encoding):


    0   1   2   3
  +---+---+---+---+---+---+---+---+---+---+---+---+
  |  discriminant |   arm length  |  implied arm  |          AFS3 UNION
  +---+---+---+---+---+---+---+---+---+---+---+---+
  |<---4 bytes--->|<---4 bytes--->|


I'll probably regret asking, but has anyone volunteered to write this I-D? ;)

-Tom