<div>Good morning list,<br></div><div><br></div><div>An item added discussed in the summit was the proposed "type,len,value", which is added to the end of messages and other intercommunication structures (invoices and so on).<br></div><div>This would allow some transition to future additional fields while maintaining backward compatibility.<br></div><div><br></div><div>I believe these were brought up:<br></div><div><br></div><div>1.&nbsp; For a sequence of `type,len,value`, each `type` must be unique. -- accepted.<br></div><div>2.&nbsp; For a sequence of `type,len,value`, the `type`s must be in ascending order -- not explicitly accepted or rejected.&nbsp; It would be easier to check uniqueness (the previous rule we accepted) here for a naive parser (keep track of some "minimum allowed type" that initializes at zero, check current type &gt;= this, update to current type + 1) if `type`s are in ascending order.<br></div><div><br></div><div>Now for bikeshedding:<br></div><div><br></div><div>1, `type` - one byte or two?<br></div><div>2. `type` - maybe some other name, since we already use `type` for messages?&nbsp; How about, `key` instead?<br></div><div>3. `type` - does "it's OK to be odd" apply?&nbsp; i.e. if an even `type` that is not known is found, crash and burn.&nbsp; But intent of this system is for future expansion for optional fields, so...?<br></div><div>4. `len` - measures bytes of `value`, obviously since if the receiver does not know the `type` then it cannot know what unit is used for the `value`.<br></div><div>5. `len` - one byte or two? I believe we tend to use two bytes for various lengths.<br></div><div>6.&nbsp; BOLT - I propose making a separate BOLT for `type,len,value`, which other messages and so on simply refer to.<br></div><div><br></div><div>Regards,<br></div><div>ZmnSCPxj<br></div><div><br></div>