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 15:19:28 +0200

OK, then I got it wrong, sorry!

The FN should probably benefit from clearer descriptive text around
the principles of it, i.e. in the initial parts of the document,
sorrunding the examples.

By the way, I still believe the inferred_ipv4_header_checksum
method belongs to the FN document. It is a general method!

/L-E

> -----Original Message-----
> From: Carsten Bormann [mailto:[email-masked]]
> Sent: den 30 september 2004 15:13
> To: Finking, Robert
> Cc: Carsten Bormann; Lars-Erik Jonsson (LU/EAB); [email-masked]
> Subject: Re: [rohc] RE: External Encoding Methods (was: RE: ROHC-FN
> Snapsh ot - Wednes day's update)
> 
> 
> > ]Ok, so why don't you just have that escape character 
> (underscore) when
> > ]you *use* a method? A parser that sees such a method can 
> then ignore
> > ]it.
> 
> Yes, this is what I was thinking we were doing.
> 
> > ]Listing non-defined methods in the generic FN seems very strange
> > ]to me.
> >
> > 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. 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!
> 
> Agree.
> 
> Gruesse, Carsten
> 

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

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 14:57:49 +0100

L-E,

]Thanks, then I am much more sure that I get what you are saying.
]
]What I still do not understand is why we need the "external
]encoding method" ("_") being defined by the FN. Instead of
]requiring all non-FN methods used in an FN specification to
]be indicated with an underscore escape character, meaning 
]that a potential parser could ignore it, it should be the
]parser that would just say, "I've checked the specification
]according to FN. All is fine, apart from the following 
]methods being undefined: method_a, method_b, method_c"
]
]The profile writer will know that these methods are ok, right?

Yes, the writer will, but not necessarily the reader. Supposing the writer has definitions in his head for all three methods, but that in a deadline rush, he accidentally forgets to specify the definition of method_c in the profile. Then he goes on holiday or is busy/uncontactable/dead for a couple of months.

The implementer comes along and gets back these three undefined methods, but only sees definitions for two of them. He has no clue as to whether the third method should have a definition in the FN, or whether there is a normative definition in an RFC somewhere.

It's about being open and explicit, rather than closed (i.e. relying on "head" information) and implicit.

Hope that makes sense =)  of course you may well disagree anyway ;-)

Regards

Raffles

---

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

> On Sep 30 2004, at 15:47 Uhr, Lars-Erik Jonsson (LU/EAB) wrote:
> 
> > parser that would just say, "I've checked the specification
> > according to FN. All is fine, apart from the following
> > methods being undefined: method_a, method_b, method_c"
> 
> That's how we started.
> Checking a list of half a dozen (or more) such names for typos after 
> each semantic check gets pretty long in the tooth quickly, though.
> That's pretty much why declarations in programming languages were 
> invented.

That sounds more like a problem with the way the parser log gets
presented. You want to follow up on all reported errors, right.
With a proper presentation, one should get just one error message
for each unknown method, that does not sound like a problem to me.

Anyway, of course one can insert such an underscore for potential
non-FN methods when applying the parser check during the profile
verification, but I see no point in having them in a published
standard, i.e. no point in defining it in the FN.

/L-E

---

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

> > 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".

Yes, but having methods defined in english somewhere else seems to defeat the entire idea between the FN itself, don't you think?

> 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.
> 
> Gruesse, Carsten
> 
>

---

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

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Carsten Bormann
> Cc: Carsten Bormann; [email-masked]; Lars-Erik Jonsson (LU/EAB)

This I don't get... in a complete profile specification, there should not such escaped method name, right???

---

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

> method belongs to the FN document. It is a general method!

I agree, not because it is a "general method" but because it is useful enough to have it in the library of methods availble for profiles to use.

/Ghyslain

---

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

> > So why have then in the FN???
> 
> Ah, that's indeed a quite valid question.
> The reason why I would do it this way is that you don't want to have 
> manual editing steps to change the development version of the FN spec 
> into the published version of the FN spec.
> These are error prone.

Well, the editor of the profile and the editor of the FN draft won't have to make any changes if we don't have them at all in the FN. It's up to the one that wants to make checks using a parser to identify these methods and fix its input so that these make it through...

Externally-defined methods are dangerous inmy opinion, mainly also because the latest suggestion was that their definition can live in cyberspace -- or worse, in 3095 ; )

/Ghyslain

---

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

GP,

> This I don't get... in a complete profile specification, 
> there should not such escaped method name, right???

My question was asked "long ago", I had misunderstood it a
little bit. Now we are arguing about whether it is at all
needed. Personally, I do not see the point of the "external
encoding methods" concept. External to what?

/L-E

---

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

Well, as I have said before. I can not see anything more
general than the IPv4 header, when it comes to HC.

But I also agree with your other argument.

/L-E

> From: Ghyslain Pelletier (LU/EAB) 
> Sent: den 30 september 2004 16:40
> To: Lars-Erik Jonsson (LU/EAB); 'Carsten Bormann'; Finking, Robert
> Cc: [email-masked]
> Subject: RE: [rohc] RE: External Encoding Methods (was: RE: ROHC-FN
> I agree, not because it is a "general method" but because it 
> is useful enough to have it in the library of methods 
> availble for profiles to use.
> 
> /Ghyslain
>

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 15:53:31 +0100

Surely the whole internet will be moved over to IPv6 by this time next year
;-)

-----Original Message-----
From: Lars-Erik Jonsson (LU/EAB) [mailto:[email-masked]] 
Sent: Thursday, September 30, 2004 3:50 PM
To: Ghyslain Pelletier (LU/EAB); 'Carsten Bormann'; Finking, Robert
Cc: [email-masked]
Subject: RE: [rohc] RE: External Encoding Methods (was: RE: ROHC-FN Snapsh
ot - Wednes day's update)

/L-E

---

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

Robert,

> Yes, the writer will, but not necessarily the reader. 
> Supposing the writer has definitions in his head for all 
> three methods, but that in a deadline rush, he accidentally 
> forgets to specify the definition of method_c in the profile. 
> Then he goes on holiday or is busy/uncontactable/dead for a 
> couple of months.
> 
> The implementer comes along and gets back these three 
> undefined methods, but only sees definitions for two of them. 
> He has no clue as to whether the third method should have a 
> definition in the FN, or whether there is a normative 
> definition in an RFC somewhere.

First I thought this was some kind of joke...

What about if there was an earthquake?
If we reach the end of the world, how do we make sure
our specifications gets published un an unambiguous way
even after that?

Seriously, an FN-based specification would either define
methods itself or use methods from another specification
which it refers to. That is how specifications are built.

I do not know what you mean by writer, if you mean a profile
writer, neither do I know what you mean by a reader.

We are talking about specifications, and tools to simplify
the specification work. Specifications are supposed to be
clear, you should never have to try to find a normative
answer without a clear reference.

To be honest, what you wrote above makes no sense to be,
I've probably misunderstood what you were trying to say.

/L-E

---

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

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)

I have not heard anyone saying that an FN spec can not
define its own methods formally.

/L-E

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

---

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

> encoding methods" concept. External to what?

Me neither, plus that it opens a door that the formal notation is trying to close.

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 16:16:43 +0100

L-E
]
]Robert,
]
]> L-E,
]> 
]> ]Thanks, then I am much more sure that I get what you are saying.
]> ]
]> ]What I still do not understand is why we need the "external
]> ]encoding method" ("_") being defined by the FN. Instead of
]> ]requiring all non-FN methods used in an FN specification to
]> ]be indicated with an underscore escape character, meaning 
]> ]that a potential parser could ignore it, it should be the
]> ]parser that would just say, "I've checked the specification
]> ]according to FN. All is fine, apart from the following 
]> ]methods being undefined: method_a, method_b, method_c"
]> ]
]> ]The profile writer will know that these methods are ok, right?
]> 
]> Yes, the writer will, but not necessarily the reader. 
]> Supposing the writer has definitions in his head for all 
]> three methods, but that in a deadline rush, he accidentally 
]> forgets to specify the definition of method_c in the profile. 
]> Then he goes on holiday or is busy/uncontactable/dead for a 
]> couple of months.
]> 
]> The implementer comes along and gets back these three 
]> undefined methods, but only sees definitions for two of them. 
]> He has no clue as to whether the third method should have a 
]> definition in the FN, or whether there is a normative 
]> definition in an RFC somewhere.
]
]First I thought this was some kind of joke...
]
]What about if there was an earthquake?
]If we reach the end of the world, how do we make sure
]our specifications gets published un an unambiguous way
]even after that?

=) I try to mix a bit of humour into my posts as arguing all day can put you
in a bad frame of mind =) Still the point I was trying to make was not a
joke. I hope this mix of humour and content is not a problem? Please say if
it is, and I'll try to stop =)

]
]Seriously, an FN-based specification would either define
]methods itself or use methods from another specification
]which it refers to. That is how specifications are built.
]
Right, sure so methods it defines its self or methods defined in the FN are
ordinary "internal" methods. The ones defined in another specification are
"external" methods. If you don't provide any syntactic distinction between
the two, the reader of the profile has no way of distinguishing between an
error the profile writer has made and a legitimate external reference.

]I do not know what you mean by writer, if you mean a profile
]writer, neither do I know what you mean by a reader.

OK what I mean by a writer is somebody like Mark, who produces packet
formats described in the notation, which somebody like me (the reader) will
have to use to produce an implementation.

If we could assume that no implementation effort was going to take place
until the profile was done and dusted, then I'd have to agree that there
would be much less point in the leading underscore (though I'd still argue
that it would make the published profile more readable). The whole
motivation for this in the first place, came from my own experience of
having to read FN written by other people - it's not that easy!

]
]We are talking about specifications, and tools to simplify
]the specification work. Specifications are supposed to be
]clear, you should never have to try to find a normative
]answer without a clear reference.

That's fine, but I don't think what I'm saying is affected by this. 

]
]To be honest, what you wrote above makes no sense to be,
]I've probably misunderstood what you were trying to say.
]
OK, well let me know if this has helped =)

Regards

Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 16:37:57 +0100

]> My question was asked "long ago", I had misunderstood it a
]> little bit. Now we are arguing about whether it is at all
]> needed. Personally, I do not see the point of the "external
]> encoding methods" concept. External to what?
]
]Me neither, plus that it opens a door that the formal notation is 
]trying to close.

OK I think Carsten has said this already, but... How are you going to define
the more complex encoding methods in the notation? If you can't do it, or if
you realise that the notation to do it is horribly complex and impenetrable,
what do you do then? That's what they're for...

---

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

> OK I think Carsten has said this already, but... How are you 

See my answer to Carsten. Maybe I am thinking wrong.

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 16:45:14 +0100

]>> Interesting.
]>> How would you define ipv4_inferred_checksum except in english?
]>> (How would you define "irregular" except in english?)
]>
]> I meant using the english language in an more or less informal manner, 
]> such as this possiblity was open in the latest version of the draft 
]> using the exemple (although it was flagged as not recommended to do 
]> so):
]>
]>    crc_field ::= _four_bit_crc; % see 
]> www.ciphersbyritter.com/ARTS/CRCMYST.HTM
]
]Ah, I hadn't seen this.
]This one we don't want.
]My assumption was that there was going to be a section in the 
]specification that makes use of FN that defines painstakingly (in 
]english language) what a _four_bit_crc is on both its uncompressed and 
]compressed side.

Ah OK, my bad, Mark and I may have misunderstood the intention here - or
maybe it was just me ;-) I'll add that to the issues list... (I'm adding
both things that have been decided need doing, and also things that we need
to decide whether to do or not)

Cheers

Raffles

---

From: "Finking, Robert" <[email-masked]>
Date: Thu, 30 Sep 2004 17:03:25 +0100

OK, thanks for the update, I've added it to the issues log. I'll be amazed if everybody agrees on this though ;-)

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Thursday, September 30, 2004 4:59 PM
To: Finking, Robert
Cc: 'Ghyslain Pelletier (LU/EAB)'; Carsten Bormann; 'Lars-Erik Jonsson (LU/EAB)'; [email-masked]'
Subject: Re: [rohc] RE: External Encoding Methods (was: RE: ROHC-FN Snapsh ot - Wednes day's update)

On Sep 30 2004, at 17:50 Uhr, Finking, Robert wrote:

> must be rigorously defined in the non FN part
> of the profile, rather than just by referencing a definition
> in another document.

They might be rigorously defined in the non FN part of the profile 
using language that references a definition in another document.
The point is that they must be rigorously defined, which you cannot do 
just by pointing to a document that does not rigorously define an 
encoding method.

Gruesse, Carsten