Re: ForCES TLV size

Jamal Hadi Salim <[email protected]> Sat, 18 Aug 2007 06:55:48 -0400
Newsgroups gmane.ietf.forces
Organization ZNYX Networks
Message-ID <1187434549.5165.23.camel@localhost>
Hi Evangelos,

Note: This is a corner case - so optimizing for a corner case is a bad
idea.
The protocol utilizing paths etc is sufficient in delivering _any_
object/sub-object (eg you could deliver a single table cell or a row or
the whole table).
The hypothetical challenge is where you have an atomic unit example a
table cell which exceeds the 2^16 bytes. We dont know of anything today
that meets those specs - that doesnt mean we dont want to be aware of
it. One way to be aware of it is just to document it in the protocol
draft and move on.
Making the length larger is not going to resolve the problem because
if this is a problem (very skeptical it is from what i know
implementing) then sooner or later someone is going to bring a table
cell larger than whatever you defined to be the upper bound and you are
back to the drawing table.
The solution which Joel and I proposed is to be able to break down an
object exceeding the max length into fragments. This addresses the issue
of not caring whether the object grows to some large issue in the
future.
Again, we are only being pre-emptive as opposed to thinking this is an
issue given current knowledge.
The more i think about it for the sake of progress, the more i am
leaning towards us just documenting this "issue" in the draft and  
closing it.
If folks would agree to this i think Joel and I should throw out the
proposal we put forward.

cheers,
jamal

On Fri, 2007-17-08 at 20:18 +0300, Evangelos Haleplidis wrote:
> Greetings to the List,
> 
> I have a small proposition to offer in regard to the situation with the
> Length of the TLV.
> 
> It is a patch, and not a clean solution, but I'm sending it as an idea,
> nontheless.
> 
> It can be applied to all TLV's.
> 
> If someone wants to send a TLV of size larger that may fit in the 16bits
> Length, then it will set the Length field to zero, and the next 8 bytes will
> be the length. So this a special case TLV, that the length is embedded on
> the message.
> 
> What do you think?
> 
> Regards,
> Evangelos Haleplidis.