Subject: RE: [rohc] RE: External Encoding Methods

From: "Finking, Robert" <[email-masked]>
Date: Fri, 1 Oct 2004 09:45:17 +0100

]> > What I have thought all the time was that:
]> >
]> > 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 (in the FN
]> >    draft or in the draft giving the FN spec)
]> 
]> This is exactly my view.
]> (So far, the FN draft does not define any methods in FN, IIRC, but it 
]> certainly can.)
]
]This I do not understand, in what way would you say the FN draft
]defines methods, if not in FN-form?

Ah OK, well I think I can answer this question! The FN draft defines methods in English. The only encoding that is defined in the notation itself is list encoding. It is a good point that we *could* define all the encoding methods using the FN itself, but I don't think that would be particularly helpful in some cases, "lsb" encoding in particular would be very difficult to define in the FN and hard to read. But that's why we have methods like that as primitives in the FN!

]
]> > I have not heard anyone saying that an FN spec can not
]> > define its own methods formally.
]> 
]> Actually, the *only* thing an FN spec can do is define 
]> encoding methods formally.
]
]I meant in FN-form, while the opposite is plain English.

It's true nobody has said the FN spec "can not" define its own methods in FN-form, it's just not been done - do we want to do this? It would be useful for verification purposes.
]
]Anyway, which of these would you call "external", or whatever
]term we are now using?

OK, I think I can answer this too. There are basically three kinds of encoding methods,
  1. those defined as primitives in the FN draft ("irregular", "lsb", "static" etc.),
  2. those defined in the FN part of the profile as structures (including list structures), and
  3. those referenced in the FN part of the profile, but rigorously defined outside the FN part of the profile.

OK, so now I have a question, as I think I may have misunderstood you. Are you saying that there should be no category 3 here? I.e. that if an encoding method isn't be defined in the FN part of a profile, then it must be defined in the FN-draft? (i.e. are you advocating that we return to the pre IETF60 scheme where we had gazillions of encoding methods in the FN draft)?

Regards

Raffles

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

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 12:47:46 +0200

> > Anyway, which of these would you call "external", or whatever
> > term we are now using?
> 
> I would like to get rid of the term "external".

Good. I obviously am fine with this.
 
> It would be nice to have a word for "encoding method defined 
> in english 
> language within the text of a spec using FN", such as 
> inferred methods 
> defined based on properties of the protocol being compressed.  This 
> *may* be what some of us called "external", but I'm not even 
> sure about 
> that.

I don't think that this is what _everyone_ meant by external, since in the draft I've seen the text did imply "a pointer to something".

I like the way you express it above, it is more inline with what I'd like to see and I think that the discussion seemed to converged that way. I'll suggest some edits later.
 
> Gruesse, Carsten

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 13:03:26 +0200

I have a feeling we a converging, if not yet to completely
common opinions but at least towards common terminology and
understandings. 

/L-E

> -----Original Message-----
> From: Ghyslain Pelletier (LU/EAB) 
> Sent: den 1 oktober 2004 12:48
> To: 'Carsten Bormann'; Lars-Erik Jonsson (LU/EAB)
> Cc: 'Finking, Robert'; [email-masked]
> Subject: RE: [rohc] RE: External Encoding Methods
> 
> 
> I don't think that this is what _everyone_ meant by external, 
> since in the draft I've seen the text did imply "a pointer to 
> something".
> 
> I like the way you express it above, it is more inline with 
> what I'd like to see and I think that the discussion seemed 
> to converged that way. I'll suggest some edits later.
>  
> > Gruesse, Carsten
> > 
>

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 13:32:20 +0200

All,

I have added a suggestion for the text in the FN draft to replace the section on "External Encoding Methods" in the issue tracker. Have a look and let me know if what I wrote means anything to you.

Suggested text for 4.8.7
------------------------

4.8.7. Profile-specific Encoding Methods

   The library of encoding methods provides a basic and
   generic set of coding methods. Some additional encodings 
   specific to a particular protocol may however be needed, 
   such as for methods that infer the value of a field from 
   other values. These methods are defined based on the 
   properties of the protocol being compressed.

   Profiles may define additional encoding methods; the 
   scope of these methods is then local to the profile 
   definition itself, and they can be used as part of the 
   formal definition of the profile as any other methods 
   from the library (see section xxxx).

   Profile-specific encoding methods must be rigorously
   defined using either the ROHC-FN syntax or in plain
   text, as long as its definition provides enough
   information to unambiguously implement the encoding
   method in the compressor and the decompressor. These
   methods should be no less complete than the methods
   provided herein.

///Ghyslain

--
 Ghyslain Pelletier, Dipl. Ing.
 Wireless IP Optimizations
 Ericsson Research, Corporate Unit

 Ericsson AB, Laboratoriegränd 11
 Box 920, S-97128 Luleå, SWEDEN
 Phone : +46 (0)  8 404 29 43
 Mobile: +46 (0) 70 264 83 14
 [email-masked]
 http://www.ericsson.com

-----------------------------------
 The opinions expressed in this
 message are my personal opinions.
 These opinions are not
 necessarily those of my employer,
 unless stated otherwise.
-----------------------------------

> From: Lars-Erik Jonsson (LU/EAB) 
> Sent: den 1 oktober 2004 13:03
> To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'
> Cc: 'Finking, Robert'; [email-masked]'

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 1 Oct 2004 13:01:39 +0100

]I have added a suggestion for the text in the FN draft to replace the
]section on "External Encoding Methods" in the issue tracker. Have a 
]ook and let me know if what I wrote means anything to you.
]
]Suggested text for 4.8.7
]------------------------
]
]4.8.7. Profile-specific Encoding Methods
]
]   The library of encoding methods provides a basic and
]   generic set of coding methods. Some additional encodings 
]   specific to a particular protocol may however be needed, 
]   such as for methods that infer the value of a field from 
]   other values. These methods are defined based on the 
]   properties of the protocol being compressed.
]
]   Profiles may define additional encoding methods; the 
]   scope of these methods is then local to the profile 
]   definition itself, and they can be used as part of the 
]   formal definition of the profile as any other methods 
]   from the library (see section xxxx).
]
]   Profile-specific encoding methods must be rigorously
]   defined using either the ROHC-FN syntax or in plain
]   text, as long as its definition provides enough
]   information to unambiguously implement the encoding
]   method in the compressor and the decompressor. These
]   methods should be no less complete than the methods
]   provided herein.

This is good Ghyslain, I like this text a lot. I agree to this change,
though I would like to leave open the question of whether we need another
paragraph (something along the lines of):

Profile-specific encoding methods must have identifier which start with an
underscore in order to make them visually distinct from other encoding
methods.

Regards

Raffles

///Ghyslain

---

From: "Ghyslain Pelletier (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 14:14:47 +0200

> underscore in order to make them visually distinct from other encoding

Please motivate this?

Right now I cannot see the difference between a method being defined within the profile itself or fom the library of encoding method.

/Ghyslain

---

From: "Finking, Robert" <[email-masked]>
Date: Fri, 1 Oct 2004 14:38:07 +0100

]> 
]> Profile-specific encoding methods must have identifier which 
]> start with an
]> 
]> underscore in order to make them visually distinct from other encoding
]> 
]> methods.
]
]
]Please motivate this?
]
]Right now I cannot see the difference between a method being defined 
]ithin the profile itself or fom the library of encoding method.

Well, I thought we'd been motivating it all along, but here goes again. To give a specific example (since L-E asked for one earlier), suppose that during development, in the TCP profile you have an encoding method called "satic". I come along and read the FN bit of the profile (please be aware that the English part of the profile and the FN for the packet formats are updated independently), and have no clue as to whether this is supposed to be "static" or is supposed to be an encoding method defined in the English text. Hence I can't correct it. This wouldn't be a problem except that most of the time the majority of the people concerned with ROHC-FN aren't available, so that you feel somewhat like you're working in a vacuum.

Second example. The draft is finished and has made it to RFC stage, as has the TCP profile. Mr E. N. Gineer from Sagem is tasked with developing the compressor/decompressor for Sagem's new phone. He's reading the FN part of the spec and wants to know where to find the definition of the "satic" encoding method. He's pretty sure it's not a primitive encoding method because there are only a few of them and it doesn't ring any bells, so does he need to manually skim through the FN to find the formal definition, or does he need to look up the English text for the reference?  He can't tell! However, if an underscore prefix was used...

I hope this illustrates the rationale behind this idea.

Regards

Raffles

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 15:38:26 +0200

> This is good Ghyslain, I like this text a lot. I agree to
> this change, though I would like to leave open the question
> of whether we need another paragraph (something along the
> lines of):
>  
> Profile-specific encoding methods must have identifier which 
> start with an underscore in order to make them visually
> distinct from other encoding methods.

As you might have expected, I do not want to add this requirement.
Actually, I would argue that the FN can not mandate profile
definitions to use such an identifier, as that is totally up
to the profile writer to decide. 

If the FN makes such a statement, a profile definition can
easily override it, but a profile can also use its own way
to separate different kinds of methods.

So, making such a requirement/statement in the FN is just moot!

/L-E

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 15:48:14 +0200

> Well, I thought we'd been motivating it all along, but here 
> goes again. To give a specific example (since L-E asked for 
> one earlier), suppose that during development, in the TCP 
> profile you have an encoding method called "satic". I come 
> along and read the FN bit of the profile (please be aware 
> that the English part of the profile and the FN for the 
> packet formats are updated independently), and have no clue 
> as to whether this is supposed to be "static" or is supposed 
> to be an encoding method defined in the English text. 

   We are talkning about ONE specification, I can not understand
   why you say that text vs FN-part are updated separately, I
   would rather claim that the natural thing is to make this
   in parallell.

>  This wouldn't be a problem except that most 
> of the time the majority of the people concerned with ROHC-FN 
> aren't available, so that you feel somewhat like you're 
> working in a vacuum.

   This is an IETF WG, involved people is usually just an
   e-mail message away. And what is in WG documents is 
   developed openly on the mail list.

> Second example. The draft is finished and has made it to RFC 
> stage, as has the TCP profile. Mr E. N. Gineer from Sagem is 
> tasked with developing the compressor/decompressor for 
> Sagem's new phone. He's reading the FN part of the spec and 
> wants to know where to find the definition of the "satic" 
> encoding method. He's pretty sure it's not a primitive 
> encoding method because there are only a few of them and it 
> doesn't ring any bells, so does he need to manually skim 
> through the FN to find the formal definition, or does he need 
> to look up the English text for the reference?  He can't 
> tell! However, if an underscore prefix was used...

Why is he reading just a minor part of the spec? The spec
consists of several parts, but of course you can not
expect to understand everything by reading just one part
in the middle.

> I hope this illustrates the rationale behind this idea.

It just makes me more convinced that this artificial
separation is completely wrong.

I know you have had a hard time with the FN and ROHC-TCP
work, which has been a mess during the whole process.
However, no underscore in the world had helped us with
this.

/L-E