Subject: [rohc] More notation discussion issues...

From: "West, Mark (ITN)" <[email-masked]>
Date: Sun, 23 Jun 2002 10:34:55 +0100

Hi all,

Here are some more general discussion points raised as a result of my 
own deliberations on notation and from reading Hongbin's notation draft...

So, if you're interested, read on.  If not, don't say you weren't warned!

In Hongbin's ROHC-GN draft, the encoding method HUFFMAN appears.
Now, my immediate reaction was that this makes the notation specific to 
a particular set of encoding rules.  (The draft points out that other 
encodings may be added, but I'm not sure that this is the point).

I thought that the idea was for the notation to describe the behaviour 
of the protocol and then the encoding rules to interpret this and build 
compressed headers out of it.

However, I think that there is an interesting point raised here 
regarding the level of assumptions that can be made about the encoding 
rules.

Ideally, you don't want anything in the notation that is encoding-rule 
specific, but that could be very hard to achieve.  Perhaps we need to 
think about 'classes' of encoding rules, and make sure that the notation 
includes sufficient information that can be ignored, where appropriate, 
by encoding rules that can't make use.

Alternatively, we could try and keep the notation entirely free from 
assumptions about the encoding rules.  This would almost certainly 
require that when mapping from a protocol description to header formats, 
the annotation would have to be augmented by other information required 
by the encoding rules.

Another point concerns the list encodings, which we have discussed before.

Clearly at this point we are simply defining the behaviour of the 
protocol.  We ideally want to assume as little as possible about the 
encoding (as discussed above).

However, when thinking about encoding lists it is natural to think about 
inserting elements in, or deleting elements from a list (c.f. RFC 3095 
list-based encoding and EPIC-lite).  (Otherwise you send the whole list 
when it changes, and that's bad).  Given this I think that you 
inevitably have to have some concept of an 'index'; and this means in 
turn that you aren't going to have a truly unbounded list..?

Practically, I think that this means 'list' encodings should at least 
give some indication of the magnitude of the list, at least as a hint to 
the encoding rules to know how much information is required to 
manipulate the list.

Any thoughts?

Cheers,

Mark.

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)