-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Roland,
You may consider subscribing to the RELOAD implementers mailing-list: http://implementers.org/mailman/listinfo/reload One comment below. On 12/21/2011 09:32 AM, Roland Bless wrote: > Hi, > > a student (André Becker) at our institute discovered > some inconsistencies with the proposed fragmentation > while implementing RELOAD, which he has started to work > on recently. > > Issue: 5.3.2 and 5.7 are inconsistent and confusing > with respect to the fragment bit definition. > > Sec. 5.3.2: > fragment: This field is used to handle fragmentation. The high > order two bits are used to indicate the fragmentation status: If > the high bit (0x80000000) is set, it indicates that the message is > a fragment. If the next bit (0x40000000) is set, it indicates > that this is the last fragment. The next six bits (0x20000000 to > 0x01000000) are reserved and SHOULD be set to zero. The remainder > of the field is used to indicate the fragment offset; see > Section 5.7 > > I read this as: > - if the message is a fragment then the high bit is set. > - if the message is the last fragment, then the next bit is set. > > (BTW: It is not clear to me why there is only a "SHOULD be set to zero" > for the Reserved bits instead of a MUST.) > > And Section 5.7 states: > If the message is not fragmented, then both the > first and last fragment bits are set to 1 and the offset is 0 > resulting in a fragment value of 0xC0000000. Note that this means > that the first fragment bit is always 1, so isn't actually that > useful. > > Issues: > - there are no official names defined in 5.3.2 that are called > "first fragment" and "last fragment" bits. The high bit of > 5.3.2 indicates that the message is a fragment, not only the first > fragment. > - according to 5.3.2, it is perfectly ok to set both bits > for the last fragment, since the high bit should be set because > it's a fragment and the next bit should be set to indicate that > it is the last fragment. > - the last sentence is a somewhat weird statement For reference, here's the email exchange for this text (search for "A.20"): http://www.ietf.org/mail-archive/web/p2psip/current/msg05801.html > > Proposal: > - change 5.3.2 to a clearer definition of the bits > - fix the description in 5.7 > as follows: > > sec 5.3.2: > fragment: This field is used to handle fragmentation. The high > order two bits are used to indicate the fragmentation status: > If the message is a fragment the high bit ("fragment bit") > (0x80000000) MUST be set, as it indicates that the message is a > fragment. If the message is the last fragment the next bit ("last > fragment") (0x40000000) MUST be set in addition to the high bit, > otherwise it MUST be set to zero. The next six bits (0x20000000 to > 0x01000000) are reserved and MUST be set to zero, their contents > MUST be ignored on reception. The remaining 24 bits of the field > are used to indicate the fragment offset; see Section 5.7 > > So if the message is a fragment, the high bit will always be set, > and the last bit will be additionally set to indicate "last fragment". > The combination high bit zero and last fragment is not allowed > (protocol error). Is there a need to report an error message back in > this case? > > Proposed changed text for Section 5.7: > Old: > The first fragment therefore has > an offset of 0. The first and last bit indicators MUST be > appropriately set. If the message is not fragmented, then both the > first and last fragment bits are set to 1 and the offset is 0 > resulting in a fragment value of 0xC0000000. Note that this means > that the first fragment bit is always 1, so isn't actually that > useful. > > > New: > The first fragment therefore has an offset of zero. > The fragment and last fragment bit indicators MUST be appropriately > set. If the message is not fragmented, then both the first and last > fragment bits are set to zero and the offset MUST be set to zero. - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJO8h05AAoJECnERZXWan7EpTUQAImGv5w+TW/7eO7RMipW2k85 qDEJ8svDs/ASDjR/ITTHIW/oIjWRDZpCo66yaqaQs/5iYe/O90dN2fgmqtB3Yjrv ug3orfwuvrHrgy8W6+cCw+7X5bKyEb49qqRW1x6lkGwzc06+D/K4tkM6Jne/qU9B BqJiDJHDy2K1LPGVO+VB+Lqig83CJWejlaT+iHGiSlVBjc72zwu374ZSvJK7PHDy Rmiu0Ph0UYD3jnk/MouCqAUTdpi8orV8pNwmxynDG4TxwjkvKTDlLhJTKE42LHH6 d7y4sF5hlsdU7R8L2zLY48263lE0FMp839ynmj7oQnaTJKMnkZaM1Uo49QW3Ml25 knGUnUQ/tj9r2NgIYtme1bWoDanPT6F09bYsppF9hcIofZ4tK+9hY2H+b8pU39dm GRFMFmrFaWf5eeya/GRghpHCFcjOnflPqCv5ECquFLGCodvznNdgXv84Z2EV97WJ L9wxgOJlGCBaF3OmX/Z3RT/GRRF5+CRGIx5NwT4EsyBa1vJy8l5W9dl8nZQ63mOK bALklfNdnMwP8w1OmkENWfX0q4biF6scjxFxpB/77ngYivpyIDx1ZqvWpL+Tfw6B WHAvgXSlDrGKgJ+YDJy4jC7wZNVq9Oep58lfKhV17TWbwBg4mLsSZKmMTFWi8LMI RlDIk095nus1JyMFnlCK =qQxC -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
