[Correção] Formato do txid (cobrança)

[dmkamers]

Limitar campo txid a qualquer combinação de: . letras: a-z A-Z . dígitos decimais: 0-9 . entre 1 e 35 caracteres O padrão é 'url-friendly' e compatível com o uso de 'uuid's sem traço (32 posições). O id de devolução tem formato similar.

[rturk]

Qual motivo de forçar uuid sem traço?

[rubenskuhl]

Como são permitidas maiúsculas e minúsculas, seria interessante documentar se o txid é case sensitive ou case insensitive. Não tenho preferência por qualquer das duas, apenas por clarificar qual é o caso.

[dmkamers]

Qual motivo de forçar uuid sem traço?

@rturk o txId não tem formato obrigatório, desde que compatível com o esquema do campo (letras e dígitos decimais). Note que um uuid com os traços tem 36 posições.

[rturk]

@dmkamers bem colocado, agora que percebi que o uuid com traço ultrapassaria o limite de caracteres.

[rturk]

@rubenskuhl minha leitura é que se o txId permite a-zA-Z deveria ser case sensitive. Ou seja diferenciar minúsculas de maiúsculas, isto também aumenta significativamente a quantidade de chaves que o campo pode acomodar.

Lembrando que o Pix será usado em escala Nacional, este campo tem que poder durar vários anos.

[ninrod]

@rubenskuhl minha leitura é que se o txId permite a-zA-Z deveria ser case sensitive. Ou seja diferenciar minúsculas de maiúsculas, isto também aumenta significativamente a quantidade de chaves que o campo pode acomodar.

@rturk apenas lembrando que o txid deve ser apresentado diretamente na URl via PUT/GET /cob/{txid}. Não seria um problema a questão de case sensitivity?

Lembrando que o Pix será usado em escala Nacional, este campo tem que poder durar vários anos.

@rturk, Acredito que 35 posições A-Z + 0-9 seja um campo que conseguirá comportar a demanda por décadas, ainda mais em se tratando de um escopo específico em que o txid deve ser único apenas por CPF/CNPJ do usuário recebedor para um dado PSP. Não sei se serve como uma referência gabaritada, mas se você observar a descrição de colisão do UUIDv4 na wikipedia:

For example, the number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion.

This number is equivalent to generating 1 billion UUIDs per second for about 85 years. A file containing this many UUIDs, at 16 bytes per UUID, would be about 45 exabytes.

Parece ser um número absurdamente grande. E considere-se ainda que o UUIDv4 é hexadecimal, então seria A-F + 0-9: nesse sentido A-Z + 0-9 atenderia e com bastante folga inclusive.

O que acham?

[rubenskuhl]

A RFC relevante aqui diz que essa parte da URI é case-sensitive, mas recomendações de construção de REST sugerem case-insensitive, possivelmente por causa de alguns web servers com o mal hábito de serem case-insensitive como o IIS.

[ninrod]

@rubenskuhl , nesse caso, considerando o "padrão de fato", ou as recomendações, não seria interessante estabelecer case insensitivity, já que A-Z + 0-9 parece estar mais do que sobrando?

@rturk, pensamentos?

[rturk]

Na minha humilde opinião este campo já nasce pequeno. Claro que 32 posições é bem grande, porém 32 não é substancialmente grande ao ponto de poder ser totalmente ignorado considerando o tamanho e magnitude que o Pix pode ter.

Assumindo o sucesso do Pix, onde todas as transações do Brasil, eventualmente migram para o Pix e teremos vários décadas da plataforma, 32 é bem uma faixa de tamanho que pode ser questionado pelos nossos netos.

Explico: Mesmo nesta faixa de tamanho, 32, ainda não é uma magnitude maior a ponto de não nos preocuparmos daqui a 20 anos. Claro sempre teremos UUID, mas softwares são atualizados, as vezes não sabemos qual algoritmo gerou os id nos passados. Times de TI são substituidos.

Bom gestores de TI irão, desde o começo do Pix, zelar pelos seus Ids, porém não necessariamente isto será verdade para todos.

Sempre é bom lembrar de:

1. https://aws.amazon.com/blogs/aws/amazon-s3-two-trillion-objects-11-million-requests-second/
2. Ipv4 vs ipv6

Novamente minha recomendação segue para adotar o maior espaço possível, logo case-sensitive

[ninrod]

Senhores, vamos bem provavelmente de case insensitive txid. Aguardar versão 2.1.0.

[jocimarcan]

Case insesitive me parece uma boa ideia, dado os possíveis incovenientes e considerando que o txId deve ser único apenas por CPF/CNPJ e que ele pode ter até "32" caracteres, ou seja, o total de txId é o somatório de 36^i para i variando de 1 a 32. Parece suficiente para atender a um usuário. Vale ressaltar que o txId do QR code estático possui no máximo 25 caracteres. E que além disso, será preenchido pelo usuário recebedor já a partir de novembro. Nesse caso, se o usuário recebedor digitar no campo Identificador Churrasco Turma do Fim de Ano, o txId a ser exibido ao usuário pagador será churrascoturmadofimdeano. Acho que vale a pena analisar se essa experiência de usuário é pretendida.

[ninrod]

case insesitive me parece uma boa ideia, dado os possíveis incovenientes e considerando que o txId deve ser único apenas por CPF/CNPJ e que ele pode ter até "32" caracteres, ou seja, o total de txId é o somatório de 36^i para i variando de 1 a 32. Parece suficiente para atender a um usuário. Vale ressaltar que o txId do QR code estático possui no máximo 25 caracteres. E que além disso, será preenchido pelo usuário recebedor já a partir de novembro. Nesse caso, se o usuário recebedor digitar no campo Identificador Churrasco Turma do Fim de Ano, o txId a ser exibido ao usuário pagador será churrascoturmadofimdeano. Acho que vale a pena analisar se essa experiência de usuário é pretendida.

@jocimarcan , em relação ao uso do txid no mobile, o PSP está livre para implementar a UX conforme achar melhor.

[christianf2029]

@ninrod Vi aqui na spec da 2.1.0 que o txid segue case sensitive, fiquei perdido em relação à decisão final.

[ninrod]

@christianf2029 , decidimos seguir com [a-zA-Z0-9].