Here is an attempt to come up with better wording. If people agree on
a new wording, I volunteer to submit an errata.
OLD
o A "type" statement may be replaced with another "type" statement
that does not change the syntax or semantics of the type. For
example, an inline type definition may be replaced with a typedef,
but an int8 type cannot be replaced by an int16, since the syntax
would change.
NEW
o A "type" statement may be replaced with another "type" statement
that does not change the semantics of the type or the underlying
built-in type. For example, an inline type definition may be
replaced with a semantically equivalent typedef derived from the
same built-in type, but an int8 type cannot be replaced by an
int16, since the underlying built-in type would change.
/js
On Mon, Feb 22, 2021 at 03:20:02PM +0100, Carsten Bormann wrote:
> On 2021-02-22, at 15:17, Juergen Schoenwaelder
> <[email protected]> wrote:
> >
> > I guess considering the built-in types as incompatible is the most
> > robust approach. If we agree that RFC 7950 tried to say this, we could
> > file an errata and propose clearer language.
>
> Right. And we can keep the COMI key-to-URL mapping as is, as this
> clarification is necessary for its correct functioning.
>
> Grüße, Carsten
>
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
