Subject: RE: [rohc] RE: External Encoding Methods (was: RE: ROHC-FN Snapsh ot - Wednes day's update)

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 30 Sep 2004 14:40:05 +0200

> On Sep 30 2004, at 13:06 Uhr, Finking, Robert wrote:
> 
> > leading underscore
> 
> It is one way to signal "dear reader, you have to look this up in the 
> english text of the specification making use of FN".
> It also makes the life of the parser easier.
> An alternative would be to have something like (not an actual 
> suggestion):
> 
> ipv4_inferred_length === #english#;
> 
> I don't care either way.

Why would you at all mention a method that is not defined in the FN?

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 30 Sep 2004 14:52:44 +0200

> Why would you at all mention a method that is not defined in the FN?

One of the main advantages of having an FN is that it can be 
automatically checked for completeness, inconsistencies etc.
Cf. the use of tools like "smilint" in MIB module design.

If the FN code does not provide any indication that an encoding method 
name is, in fact, something that you expect to be defined elsewhere, it 
cannot distinguish between typos and english-language defined encoding 
methods.  Hence the idea to somehow declare the encoding methods 
defined in english language.

The underscore notation essentially says "trust me, this is defined 
elsewhere" at the place where the encoding method defined in english 
language is being referenced.
The explicit declaration provides even better error checking, but 
requires another line in the FN code.

Gruesse, Carsten