[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] FN: default_methods and control fields clarification/new usage
> >>this separation. If the FN provides this separation, it still
> >> does NOT mean that it messes with "context updating" or other
> >> concepts, it is just a separation of fields to provide
> >> readability and consistency.
> >
> >I don't really get you here. I am not talking about context updating, I am
> >talking about properties related to their persistency in the context, what you
> >previously referred to as "fields" with requirements on the context.
>
> Ok, so let's try to explain this another way.
> I guess you agree that in the _text_ in rohc-tcp, the fields "with context"
> needs to be explained explicitly and separate from other type of field (as
> section 6.3 does). Then, if the text calls them "control fields", "persistent
> control fields" or "monkeys from outer space" does not matter the least to me. I
> know we have had requests for those textual descriptions before we added it and
> I hope you agree that in the text, that separation is necessary.
Relax, I did not come up with confusing names to refer to two things that shold be treated as the same ; )
So, I agree that this is not to be part of the FN, if necessary to have it is of the scope of the profile.
But no, I don't think that I actually agree that this separation is necessary in the text either, at least not explicitly - I don't think that it _needs_ to be formalized anywhere. However, I do agree that the informational mention of the role of each control fields and how it is to be used within the profile in the profile document is certainly useful (but again not mandatory). I don't think that that has any implication on the interoperability of the specification, only to the implementer's ability to understand how to actually compress things so that compressed formats can be chosen efficiently. But I could be convinced otherwise, I just don't see this right now.
> So assuming that, my point is: Why shouln't the FN give me provisions to have
> this separation reflected in the FN code? The "user" will first read the draft's
> text and see that "ooooh, these fields have a different meaning, and where do I
> find them in the FN code?". If we have the same definition for these and other
> not-in-the-uncompressed-header-fields, we make it harder on the user and that's
> what I specifically do not want to do. Yes, the FN becomes slightly more complex
> if it contains one more "class" of field, but I'd rather have the complexity
> logded there than having harder-to-read FN code.
So, you actually don't have technical arguments to motivate this formal separation within the FN?
Furthermore, you did not either provide any technical arguments against my proposal. It still think that it is simpler, clearer, easier to read and understand and easier to use for both notator and implementer. _AND_ coherent with what we've been trying to achieve for a while now with the FN.
So yes, I feel that it will become more confusing for the notator when writing new packet formats, since the artificial separation in the notation will likely IMHO lead to exceptions and exclusions on how to use each type (refer to my previous mail for the example). In short, I think it will be more of a mess with this artificial separation within the FN than if we treat all as the same and instead do better what we currently do - that is specify better within profile text the role and properties of the control fields that are most important (if not all).
> Hope that makes my motivations more clear to you even if you don't agree with them.
Actually, now that I've read this I think I had guessed right, and I can still not see the advantage of this. But yes it's clear.
/Ghyslain
_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc