Subject: Re: [netmod] type equivalence

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Mar 2021 19:44:36 +0100

After some iteration with Rob, here is a new version:

NEW'''

   o  A "type" statement may be replaced with another "type" statement
      as long as the underlying built-in type and the representation
      and semantics of the type do not change (other than allowed by
      other rules in this section). 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 type, since the underlying
      built-in type would change.

/js

On Wed, Feb 24, 2021 at 09:39:15PM +0100, Juergen Schoenwaelder wrote:
> 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-masked]> 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/>

-- 
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/>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 16 Mar 2021 20:57:36 +0100

On 2021-03-16, at 19:44, Juergen Schoenwaelder <[email-masked]> wrote:
> representation

There are several representations.  Which one is meant?

Grüße, Carsten