Proposal: ChainRefTag ChainBlockRefTag

[fjtc]

This issue proposes two new tags, one called ChainRefTag and the other ChainBlockRefTag.

The ChainRefTag would use the reserved explicit tag ID 26 and have the same format of the StringTag. The payload would be the textual chain identification with a single character used to define its version.

The ChainBlockRefTag would use the reserved explicit ID 27 and will be a tag sequence with 2 tags, a ChainRefTag followed by a ILIntTag that represents the block ID.

If approved, those tags could be used to represent those two values in a more standard way.

[monoman]

We do have a ChainId tag (subtype 0 of tagId 43 InterlockId) which is more compact (the textual representation uses base64 which enlarges from the byte array stored in the InterlockId). Also we have RecordReference tag (tagId 134) which encodes a sequence of a ChainId and the record number as an ILIntTag. I prefer to use these more compact and thoroughly used forms than create the proposed pair.

[fjtc]

In the go-iltags I decided to create a package called ext that implements a few extension tags have a common format but does not have an assigned tag ID. In face of your comments, it may be a good idea to extend this concept to other libraries and keep those IL2 related tags outside of the ILTag standard.

This will allow us to keep the formats implemented but not as part of the standard. What do you think about creating the concept of extended tags that do have a standard format but does not have standard tag IDs? This way, we could create a format that holds the ChainId, RecordReference from IL2 and their lists.

If we decide to follow this rule, we can left the reserved tags reserved for basic data structure tags only.

[monoman]

They have assigned numbers but in the scope of InterlockLedger node infrastructure (reserved numbers above 31 and up to 257, still in the single byte ILInt range) and are used extensively in the core InterlockApps and the structure of records in the chain.

Also some of these tags (InterlockId, the root-type of ChainId, for example) are implemented in the OSS parts of IL2

What we can decide is if we should document more of these reusable tags and implement them across the supported languages (C#, Go, Python,...) maybe, as you say, in 'extension' libs.

We could move InterlockLedger.Abstractions C# library with some more bits from InterlockLedger.Common (this lib needs to be renamed to avoid confusion with InterlockLedger.Commons) into OSS to document more of the tags that define the basic concepts in IL2 and those needed to encode/decode the records in the chain.