Skip to main content
TLVs são declarados como tokens <name>_<tag>. O nome é cosmético. A tag é a autoridade. Assim, o gateway, uma credencial e um fornecedor podem cada um chamar a mesma tag por nomes diferentes e ainda concordar sobre ela.

​
A tag é decimal a menos que prefixada 0x

Esta é a única parte genuinamente surpreendente da sintaxe, e é assim porque implantações existentes já declaram tags decimais. Tags válidas são 0x0000–0xFFFF. Um token cuja tag não parseia é logado e pulado.
vendor_1400 e peid_0x1400 são tags diferentes. Se uma carrier te dá uma tag como 0x1400 e você escreve 1400, tudo carrega, nada avisa, e a tag errada vai para o fio.

​
Cinco níveis de declaração

​
Precedência: mensagem > credencial > fornecedor

Defaults só preenchem lacunas. Nunca sobrescrevem um valor já presente. Então um valor que o cliente enviou vence um default de credencial, que vence um default de fornecedor. A exceção é o stamp de whitelist em modo replace, onde o overwrite é a aprovação. Veja Whitelisting.

​
Valores default

Um default pode ser:
Valores não podem conter , ou =. Não há escape. Use hex: quando um fornecedor precisa deles.O formato é <name>_<tag>=<value>, separado por vírgulas. Uma entrada malformada como PEID=…, sem tag no nome, parseia para nada e loga apenas um WARN. A configuração parece aplicada e não faz nada.

​
Tags não listadas são descartadas

registered.tlvs.submit em um listener é uma allow-list: uma tag que o cliente envia e que não está declarada lá é descartada, não passada adiante. O mesmo do lado do fornecedor decide o que de fato chega à carrier.
O mandatory.tlvs.submit por fornecedor é checado depois de registered.tlvs.submit ter filtrado. Exigir uma tag que não está também registrada portanto nunca pode ser satisfeito. O gateway avisa sobre esse par no load.

​
Onde uma tag ausente aparece

Veja Códigos de status e, para a visão do operador de quais linhas aprovadas têm tags que nada vai fornecer, o relatório de cobertura descrito em Sender IDs.