Carsten,
You did indicate in a message that you thought that 4944 was fine as
it was as it does NOT say that you can compress anything that is not in
the first fragment.
My listening to the discussion seemed to be that folks didn't think that
this was sufficient. I also don't think that it is sufficient.
We could explicitly state, for clarity, that you MUST NOT compress
anything outside the first fragment, but then what happens if someone
decides to use RPL or some other source routed protocol that inserts a
routing extension header or some other extension header that "pushes" a
compressed header into the second fragment. Would the node have to
uncompress that header?
If that is not a problem, then maybe we can just state that thou MUST
NOT compress outside fragment 1.
If it is a problem, then this seems like a good fix.
geoff
On Thu, 2010-03-04 at 00:19 +0100, Carsten Bormann wrote:
> On Mar 4, 2010, at 00:00, Geoff Mulligan wrote:
>
> >> From what I can tell we appear to be closing in on the idea (from Daniel
> > plus others) that the HC draft should only:
> > - Allocate a new dispatch value for the "changed" frag offset and
> > length value
> > - Define the frag offset and length to be the values relevant for the
> > actual data in the packet (compresses or not)
> > - Strongly deprecate the old frag dispatch value
> >
> > Agree or disagree?
>
> I personally believe 4944's fragmentation is fine.
> I must have missed a lot of discussion if the above is the resolution.
>
> Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
