Re: [rohc] FN: default_methods and control fields clarification/n ew usage

[Kristofer Sandlund <kristofer.sandlund at effnet.com>]

Hi!

comments inline.

Finking, Robert wrote:
> Hi Kris,
>
> I think I'll hang back on this whilst we re-thrash-out the default methods thing - the two issues are related and I don't want to presuppose the outcome of the default methods. However, it's probably worth pointing out that:
>
>
> > Therefore, this field cannot be a control_field as per how 
> > the WG discussed them 
> > in Washington (and I haven't seen any discussion that we have 
> > updated that 
> > decision). With your proposal, this would have to be defined 
> > as a control field.
> >  Btw, the minutes from the meeting is not really clear on 
> > which interpretation 
> > to use, so I can understand if you interpreted it differently.
>
>
> Although you may not have seen the discussion, we did have one! It was really aimed at clarifying what was decided I think - that is how we ended up with what is in the document. In fact the text in the control fields section has been discussed a couple of times and IIRC has been updated for clarity after review comments, so it's not like nobody's been reading it.

Ok, so you're saying that you have explicitly changed this, I thought that the 
"wrong" text had just gotten in there. My bad, I did not mean to sound like I 
was accusing you.

Then I wonder what's the point of control fields. All they do then is help with 
scoping, and I thought the important point was to separate what is persistent or 
not...

> > I think it seems quite easy to define that, if you take the 
> > current text:
> >
> >    The control fields list specifies all fields that do not 
> > appear in the
> >    uncompressed header but which have an uncompressed value
> >    (specifically those with a non-zero uncomp_length).
> >
> > and add something like:
> >    and the value of the field is persistent between packets 
> > (i.e. have context).
>
>
> Yes, it's easy to "say", but my concern is what it *means*. This is about 3095 compatibility. What does "control field" mean in 3095? Can't 3095 control fields have context? Are we about to break something? I'm no 3095 expert as you know, so help me out here =)

Well, if it is normative text in an RFC, it really *means* what it *says* :)

> Anyway, probably best to hold fire on this (except maybe to clarify the 3095 side of things) till we've sorted out the default_methods discussion.

Nope, there is no concept of control fields in 3095, that's a term we came up 
with so that we could point out what was to be in context. In 3095, the fields 
that are "context-persistent" are not very well defined in the normative parts 
themselves (for example, search for RND and see where that flag is actually 
defined), but there's a list of what the context should look like in 6.3. I'd 
like us to do a bit better than that.

/Kristofer

> Thanks for your input - much appreciated
>
> Regards
>
> Raffles

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc