Problem: We don't know the structure of the Uri-Path, so we may need to add or remove FID
Ana: I don't agree to add or remove FID's, in which case you need to add/remove a FID?
Ana: I think you need to add/remove Rules from the Context
Laurent: What if we add you d'ont know the structure of your URI path so you want to add an element
don't know, may be we can avoid it, one scenario is that you d'ont know the structure of your URI path so you want to add an element, but does it worth the cost of introducing it in the current standard.
Ana: This means that you disagree with the definition of the original
header, and so you do not follow RFC8724. Section 7
Compression/Decompression."... the Rule matches the original packet... In a
Rule, the Field Descriptors are listed in the order in which the fields
appear in the packet header...."
So since the beginning the Rule describe the non-compressed header, a new
Uri-Path is un update and perhaps belongs to another packet??
Problem: We don't know the structure of the Uri-Path, so we may need to add or remove FID
Ana: I don't agree to add or remove FID's, in which case you need to add/remove a FID? Ana: I think you need to add/remove Rules from the Context Laurent: What if we add you d'ont know the structure of your URI path so you want to add an element don't know, may be we can avoid it, one scenario is that you d'ont know the structure of your URI path so you want to add an element, but does it worth the cost of introducing it in the current standard. Ana: This means that you disagree with the definition of the original header, and so you do not follow RFC8724. Section 7 Compression/Decompression."... the Rule matches the original packet... In a Rule, the Field Descriptors are listed in the order in which the fields appear in the packet header...." So since the beginning the Rule describe the non-compressed header, a new Uri-Path is un update and perhaps belongs to another packet??