> On 29 Apr 2016, at 14:41, Juergen Schoenwaelder
> <[email protected]> wrote:
>
> On Fri, Apr 29, 2016 at 02:36:55PM +0200, Ladislav Lhotka wrote:
>>
>>> On 29 Apr 2016, at 14:30, Juergen Schoenwaelder
>>> <[email protected]> wrote:
>>>
>>> On Fri, Apr 29, 2016 at 02:19:08PM +0200, Ladislav Lhotka wrote:
>>>>
>>>> The problem here is that enum statements aren't really restrictions but
>>>> rather specify the new set of values. It would be kind of discontinuos:
>>>> with
>>>>
>>>> typedef bar {
>>>> type foo {
>>>> enum one;
>>>> enum two;
>>>> }
>>>> }
>>>>
>>>> the "bar" set would be {one, two}. If I remove the "enum two;" statement,
>>>> the set would be just {one}, but then if I remove the "enum one;"
>>>> statement, the set would again become {one, two}.
>>>>
>>>
>>> So what? Apparently, being able to use foo without having to repeat
>>> all values of foo is the main reason to define foo in the first place.
>>
>> So what about this:
>>
>> typedef bar {
>> type foo {
>> enum one {
>> if-feature fancy;
>> }
>> }
>> }
>>
>> If "fancy" feature is supported then the "bar" set is {one}. But if it isn't
>> supported, then what?
>>
>
> If the "fancy" feature is not set, the value set of "bar" is {} (since
> there is a restriction reducing the value set to an empty set).
I think you have no support for this conclusion in 6020bis text, it depends on
what "conditional" means. One defensible interpretation is that
type foo {
enum one {
if-feature fancy;
}
}
is equivalent to
type foo {
}
if feature "fancy" isn't supported.
Or are you saying that "type foo {}" is not the same as "type foo;"?
Lada
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
