Jump to content

Talk:Type–length–value

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
(Redirected from Talk:Type-length-value)

Untitled

[edit]

TLV's are also sometimes referred to as TAG Length Value.

The TAG vs. TYPE confusion stems from the fact, that for a fully generic solution, both would be needed. Some "tag" the entries with a element identifier. Others use a "type" enumeration to denote the data type of a given entry.

What is missing in this article, IMHO is a reference to GPB (Google protocol buffers), a similar approach with a few significant improvements: <WireType + ElementTag> are combined and encoded as a varint, yielding a compact wire representation. GPB - in contrast to TLV allows for nested messages. — Preceding unsigned comment added by 79.220.98.2 (talk) 09:40, 6 May 2013 (UTC)[reply]

Notable description or original research?

[edit]

I fell on this article when reading the Interchange File Format article. Although there is a relation, I found it strange that I didn't know about this TLV expression. I have used IFF in the 90s as a programmer (especially on the Amiga) as well as other formats with a "TLV"-like data pattern (which is a logical approach for efficiency and simplicity). As such, we could consider that saying that IFF uses a TLV pattern would state the obvious. And considering that this article has no references or history section, I wondered if refering here from the IFF article wasn't a form of revisionism, or original research. It seems to be a common enough data pattern that it might deserve this article, but some work appears necessary to make the article more plausible. Is TLV jargon used by a particular company, or a now established CS terminology in data patterns, etc? My jargon dictionary doesn't include it. If the latter, it deserves a CS textbook or jargon dictionary reference, a history section on who defined/named the pattern, and notable data formats which used this pattern... Thanks, 76.10.128.192 (talk) 22:34, 28 July 2015 (UTC)[reply]