Subject: [rohc] FN as humour

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Fri, 1 Oct 2004 09:36:13 +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?
> 
> =) 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 =)

That is fine, I we are all fine with and appreciate humour, as
well as rather direct and sometimes *hard* discussions.

However, I could not see and can not see anything but humour
in that example. If a method is missing, there is obviously
an error in the FN-based specification, independent what was
the intention by the writer (define it himself in FN-form or 
english, refer to the (an) FN, or refer to some other document).

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

Of course he can. If it is defined somewhere else, there will
be a reference to that place. Without a reference, it is
actually an undefined method, and it is an error in the spec.
 
> ]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.

And you need all formats specified with defined methods,
independent of where they are defined you need the reference.

/L-E

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

---

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

I'm not sure how much point there is in replying to this, I think we
probably need Kristofer's mediation skills again, but I'll give it a go
anyway... Inline

>well as rather direct and sometimes *hard* discussions.

Agreed. And of course the hardest discussions are always over the more
trivial issues. Almost always syntax in fact =)

>in that example. 
I think the only intended humour was the "being dead for two months" gag.

> If a method is missing, there is obviously
>an error in the FN-based specification,

Yes, that's right, I agree. And the whole point of this is to make errors
(which *will* happen) easier to spot and disentangle.

>... If it is defined somewhere else, there will

I think the issue we're having here is that you are thinking only "finished
product", whereas I am thinking about the development process too. A key
point here being that whilst the finished profile will be in Internet Draft
form, there is a long period where all that is passed around is the FN, and
the English text just doesn't get updated. During that period, the FN is all
you've got to go on.

Due to the way this kind of work gets done, there will be errors in the
spec. People's availability comes and goes. Sometimes key people are
unavailable for months at a time, in which case you want the notation
they've written to be as explicit as possible.

However, even *after* the whole thing is finished, it's still useful to the
reader to have the underscores in, since it tells them instantly where to
look for the definition of the method - in the FN or in the English text.

If this is understood then I don't think I've got anything to add. If any of
it is not understood then I'm happy to clarify =)

---

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

> trivial issues. Almost always syntax in fact =)

True, but often things that might look minor can be rather
significant since the actual problem might be in differences
in how one envision basic fundamentals.

> Yes, that's right, I agree. And the whole point of this is to 
> make errors (which *will* happen) easier to spot and disentangle.
> 
> I think the issue we're having here is that you are thinking 
> only "finished product", whereas I am thinking about the
> development process too.

Not really, but I rather think there is two completely different
views on how the standardisation process works. In a completed
new standard, errors are hopefully gone. However, during
development I fully agree that there might be missing pieces.
What I can not understand is what the underscores will buy you,
and I am not totally sure for which methods you will use them
either. Is the differentiation between FN-based methods versus
English-text methods? 

If you do not have the underscores, what will happen, please
give a precise and realistic example of a method that you
would like to use underscore for, and what would be the
consequences of not having the underscore.

> A key point here being that whilst the finished profile will
> be in Internet Draft form, there is a long period where all
> that is passed around is the FN, and the English text just
> doesn't get updated. During that period, the FN is all
> you've got to go on.

If this is a key point, I disagree with you even more. When
defining a new profile, you will not normally start with the
packet formats, rather the other way around. The TCP work we
are doing right now is probably the trickiest we should be
able to think of, as we are defining the whole notation
concept in parallel.

> However, even *after* the whole thing is finished, it's
> still useful to the reader to have the underscores in,
> since it tells them instantly where to look for the
> definition of the method - in the FN or in the English
> text.

I see no actual difference between the two ways of defining
a method, the only difference is that FN methods might (will)
be machine readable, while the English text ones will not.
Thus I do not buy this argument about being useful to a 
reader. It just creates an artificial differentiation 
between two kind of methods.

/L-E