Subject: [rohc] FN control fields

From: "Finking, Robert" <[email-masked]>
Date: Wed, 20 Apr 2005 14:31:03 +0100

Hi Ghyslain, Kris, All

Wow! You go to a morning meeting and while you're away the list explodes. Many thanks to you all for your contributions. OK taking into account the whole discussion, here are the main points as I see them:

 - We don't have consensus
 - The main obstacle is Kris and Ghyslain's disagreement
 - They both live in Luleå

Therefore I suggest an arm wrestling competition at sunset in the car park outside Ghyslain's apartment =) 

Seriously, this is a fairly involved issue and I'm very glad Ghyslain has joined in - thanks! The main points:

 1 Some want to be able to indicate need for context, others don't
 2 The current state of play (CSoP) in the FN draft is the latter
 3 The CSoP in the TCP-pf is the former
 4 The FN draft will have to change if it adopts the former
 5 The TCP-pf will NOT have to change if it adopts the latter, the FN in the TCP-pf will be the same either way but have a subtly different meaning
 6 It would be very good if we can fix the "non-default default let statements" bug as part of this
 7 we have endeavoured to remove formal references to context from the FN as part of the simplification we did last summer
 8 "derived" fields are currently not discussed at all in the FN draft, but since *some* mention is made of context in the draft (albeit non-formal) we need to do something to handle them
 9 The information about whether context is needed is already there in the profile, implicitly (in terms of what encoding methods are used for that field).

Here is my suggestion, which will hopefully fit all parties to an OKish degree:

- we stick with the current syntax, which keeps things simple and minimises the changes necessary
- in the TCP-pf we can use comments to indicate that context is needed for certain fields
- we clarify in the FN draft the possibility of the existence of derived fields and their use; again these can optionally be indicated by comments
- we clarify in the FN draft that "control_fields" sections are just like any other section inside a structure in that they may have a field encodings list.
- we move the non-default let statements in the FN-draft AND tcp-pf out of the default section and into either a "control_fields" field encodings list, or a "uc_format" field encodings list if that is more convenient.

Did I give a fair summary, and how does my suggestion sit with everyone? I'm guessing nobody will be over the moon about it, but hopefully all can just about swallow it?

Here's hoping!

Raffles

Robert Finking (01794 833189)
Roke Manor Research (http://www.roke.co.uk)
Romsey, Hampshire SO51 0ZN

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

---

From: Kristofer Sandlund <[email-masked]>
Date: Wed, 20 Apr 2005 16:14:39 +0200

Hi all,

<flame>
I have an even better solution, replace FN with box notation and english!
</flame>

 From what I understand of Ghyslains solution, all fields not part of the 
uc_format needs to be defined as control_fields, right?
If so, co_baseheader will have the following:
control_fields =
                          discriminator,
                          ttl_hopl_outer_flag,
                          seq_indicator,
                          ack_indicator,
                          ack_stride_indicator,
                          window_indicator,
                          ip_id_indicator,
                          urg_ptr_present,
                          tos_tc_present,
                          ttl_hopl_present,
                          list_present,
                          header_crc,
                          options_list;
(not including those already defined global fields)

What I'm trying to point out here is that co_baseheader has 21 different 
co_formats, but only one place to declare the control_fields, and of the fields 
above, almost all are for co_common, and the other 20 formats need to "see" the 
other variables in their scope just because of this new way of having control 
fields.
This is supposed to make things more clearer and simpler? (it works, sure, but 
this will clutter things to a point where I want to throw up).

This solution seems to me like we have to declare everything one scope outside 
of where it is needed. Ugly!

I hope someone with access to the CVS that isn't me makes these ugly changes to 
the tcp-pf *grumpy*

/Kristofer