On Fri, 11 Feb 2011 22:17:40 +0000 Tom Keiser <[email protected]> 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 [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
