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

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Thu, 30 Sep 2004 16:36:57 +0200

Inline.

/Ghyslain

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Finking, Robert
> Sent: den 30 september 2004 15:08
> Hang on, I think we have a misunderstanding here. The generic 
> FN doesn't
> define any external encoding methods does it? It's not 
> intended to. If I've
> given that impression in my text, it needs to be corrected. 

No, I don't think there is a misunderstanding. The text gives the right impression. The point is that defining a formal language that opens the door to encoding methods possibly being defined in cyberspace seems contradictive. A profile will define packet formats using the library in the generic FN draft + using own defined methods using the FN, but in the end there will be no external definition and certainly not coding methods defined using english language or worse - pointing to a 3095 encoding method?

> The FN should
> only define what an external encoding method is and give 
> examples of the
> usage of external encoding methods. Apologies if I have communicated
> something else!

Actually, I don't think that the FN should define what an external encoding method is at all?
Question being - external to what? The FN draft provides a library and syntax for defining methods, profiles either use the methods in the library or provide own definition of encoding methods using FN syntax, no?

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

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

---

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

On Sep 30 2004, at 16:36 Uhr, Ghyslain Pelletier (LU/EAB) wrote:

> No, I don't think there is a misunderstanding. The text gives the 
> right impression. The point is that defining a formal language that 
> opens the door to encoding methods possibly being defined in 
> cyberspace

That is indeed not intended.

> seems contradictive. A profile will define packet formats using the 
> library in the generic FN draft + using own defined methods using the 
> FN, but in the end there will be no external definition and certainly 
> not coding methods defined using english language

Interesting.
How would you define ipv4_inferred_checksum except in english?
(How would you define "irregular" except in english?)

> or worse - pointing to a 3095 encoding method?

That, indeed, sounds hard unless it is accompanied by some text that 
translates the 3095 concepts to something that can connect with the 
rest of FN.

> Question being - external to what?

Maybe the term "external" is not so good.
An encoding method is
-- either defined in english (in the FN draft or in the draft giving 
the FN spec)
-- or defined in FN, i.e. by giving an FN structure that defines the 
encoding method in terms of other encoding methods, field lists, and 
let-expressions.

> The FN draft provides a library and syntax for defining methods, 
> profiles either use the methods in the library or provide own 
> definition of encoding methods using FN syntax, no?

The assumption was that not every english-language-defined method needs 
to be in the FN draft, in particular if it is highly specific to the 
specific compression scheme.  Of course, if we update the FN draft for 
every new compression scheme, we can define all 
english-language-defined methods in the FN draft, so the above becomes 
simpler:
An encoding method is
-- either defined in english (in the FN draft)
-- or defined in FN, i.e. by giving an FN structure that defines the 
encoding method in terms of other encoding methods, field lists, and 
let-expressions.

To me, this would be a bit like changing a programming language 
specification each time you add an assembly language procedure to the 
library, so it does feel unusual to me.

Gruesse, Carsten