Resumo

  • RFC 5134 registra epc e epcglobal; ele não autoriza uma normalização textual universal.
  • Errata verificados corrigem o texto original: a parte específica do namespace é sensível a maiúsculas e minúsculas.
  • O esquema urn e o identificador do namespace seguem as regras gerais de comparação de URN.
  • Converter toda a cadeia para minúsculas pode fundir nomes distintos; comparar tudo por bytes pode criar duplicatas falsas.
  • No exemplo SGTIN, zeros à esquerda são significativos e a conversão numérica pode trocar a identidade.
  • Sintaxe URN, validade no subnamespace e atribuição autorizada são verificações independentes.
  • Persistência impede a reutilização administrativa do nome, mas não prova posse, localização ou existência física.
  • Uma leitura RFID prova uma observação delimitada, não a autenticidade do tag ou do objeto.
  • ONS/DDDS descobre serviços apenas para certos subnamespaces epc; não autentica a realidade.
  • epcglobal não exige mecanismo de resolução e não deve falhar por não ter endpoint.
  • Metadados e eventos EPCIS têm autoridades, horários e limites próprios.
  • Uma assinatura só é útil depois de demonstrar que a chave assinada preservou a identidade correta.

A assinatura chegou tarde demais

O sistema recebia a cadeia, aplicava lowercase, consultava o cadastro e então assinava o registro normalizado. Criptograficamente, o resultado era impecável. Semanticamente, a assinatura protegia uma identidade que talvez não fosse a recebida. Integridade posterior não recupera a distinção destruída antes da assinatura.

A versão publicada de RFC 5134 continha uma frase ampla segundo a qual o URN inteiro seria sensível à caixa. Os errata verificados 1325 e 1328 corrigem o alcance: a sensibilidade pertence ao namespace-specific string. Esquema e namespace identifier seguem as regras gerais dos URNs. O detalhe não é cosmético; ele define quais transformações preservam equivalência.

Há duas falhas simétricas. A primeira é baixar a caixa da cadeia inteira e colapsar valores distintos dentro da parte específica. A segunda é comparar cada caractere literalmente e tratar variações de URN:EPC no esquema ou NID como identidades diferentes. Um normalizador correto precisa entender a fronteira, não apenas escolher um procedimento de string.

Canonicalização precisa de recibo

Cada transformação deve registrar entrada original, codificação, regra aplicada, versão da biblioteca, subnamespace reconhecido e saída. Um teste de ida e volta deve provar que a representação resultante conserva a identidade definida pelo namespace. Se duas entradas convergirem, o sistema deve demonstrar equivalência normativa, não apenas igualdade depois de uma função conveniente.

O mesmo vale para números aparentes. O exemplo não normativo de SGTIN em RFC 5134 separa prefixo de empresa, referência de item e serial. Ele diz que zeros iniciais nos componentes preenchidos são significativos. Guardar esses trechos em colunas inteiras remove informação, mesmo que o valor aritmético permaneça.

Uma assinatura sobre a saída normalizada atesta quem aprovou aquela saída. Ela não prova que a saída corresponde ao identificador recebido. O recibo de transformação precisa ser verificável antes de a camada criptográfica produzir uma aparência de certeza.

Três noções de validade

Um parser URI pode confirmar o envelope geral. Em seguida, as regras do subnamespace EPC determinam a estrutura específica. RFC 5134 deixa claro que seu ABNF de SGTIN é exemplo e remete a definição normativa ao Tag Data Standard. Por fim, a organização deve verificar se os componentes foram de fato atribuídos pela cadeia autorizada.

Uma cadeia pode passar pela gramática geral e falhar no subnamespace. Pode estar bem formada e nunca ter sido atribuída. Pode estar corretamente atribuída e aparecer num tag copiado. Em vez de um campo valid, o registro precisa indicar syntax, namespace, allocation e as provas de cada decisão.

A versão das regras também importa. O arquivo do TDS documenta mudanças ao longo do tempo. Validar com a versão usada no comissionamento e validar com a versão atual são perguntas diferentes. Registrar essa escolha permite migrar sem reescrever fatos históricos.

Dois espaços nomeiam naturezas diferentes

RFC 5134 registra epc e epcglobal separadamente. Subnamespaces sob epc podem nomear objetos físicos; sob epcglobal, construções lógicas e de software, como schemas. Compartilhar o formato URN não torna iguais as expectativas operacionais.

O registro de epcglobal não requer nem fornece resolução. Um nome de schema pode ser persistente sem página para abrir. Uma verificação que tenta resolver todos os URNs transforma comportamento previsto em indisponibilidade falsa e dá ao operador de rede poder para invalidar uma referência lógica.

Para alguns nomes epc, pode existir ONS. Ainda assim, uma resposta de serviço não traz o produto para diante do leitor. Um valor copiado gera a mesma consulta; um cache antigo pode devolver dados autênticos fora do prazo; uma delegação comprometida pode conduzir a uma ficha convincente. Descoberta e verdade são superfícies diferentes.

Persistência não acompanha a matéria

A persistência protege a referência: o nome não deve ser reaproveitado para outro recurso quando a organização, o padrão ou o serviço muda. Essa garantia é valiosa para auditoria. Ela é estreita. O objeto pode trocar de dono, mudar de local, ser destruído ou perder o tag sem que o nome deixe de ser persistente.

O erro de governança é transferir a propriedade mais forte do cadastro para o mundo. Um nome durável pode aparecer num sensor defeituoso. Uma atribuição correta pode coexistir com um evento falso. O mesmo serial pode ser reproduzido em outro suporte. O cadastro registra continuidade administrativa; continuidade física requer observações e controles próprios.

Assim, uma aplicação não deve inferir custódia só porque todas as linhas usam a mesma chave. Precisa conservar quem entregou, quem recebeu, que fronteira foi observada, qual objeto foi inspecionado e qual intervalo permaneceu sem evidência.

Leitura RFID é uma afirmação delimitada

Um leitor pode afirmar que, sob certo firmware, antena, potência, filtro e horário, recebeu uma resposta contendo uma representação EPC. Essa afirmação é útil e deve ser preservada com identidade do dispositivo, tempo de captura, tempo de ingestão e política de deduplicação.

Ela não autentica automaticamente o portador. Se o mesmo valor surgir em locais incompatíveis, as hipóteses incluem cópia, sobreposição de zonas, atraso de mensagem, erro de gravação, relógio incorreto ou movimento mal reconstruído. A unicidade do namespace não escolhe entre elas.

Autenticidade exige outro mecanismo adequado ao risco: capacidade criptográfica do tag, dados de fabricação protegidos, processo controlado de comissionamento, evidência antiviolação ou inspeção. Ler um nome persistente não concede ao rádio aquilo que ele não mediu.

ONS entrega um destino, não um veredito

Para alguns subnamespaces epc, RFC 5134 descreve o Object Naming Service, implementação do Dynamic Delegation Discovery System. Regras DDDS e registros NAPTR transformam uma entrada em candidatos de serviço. O recibo correto é: determinada entrada e determinado serviço produziram determinada seleção naquele instante.

Para reproduzi-lo, registrar cadeia exata, forma de equivalência, serviço solicitado, delegações, candidatos, destino escolhido, proteções como DNSSEC, idade do cache, autoridade da resposta e decisão do cliente. Um resultado bem-sucedido não confirma que os metadados sejam atuais ou autorizados para aquela instância.

Falhas também precisam de tipagem. Serviço não definido, delegação ausente, validação falha, timeout e consulta malformada não significam a mesma coisa. No caso de epcglobal, ausência de resolução é parte do contrato, não indício de fraude.

Metadados e eventos precisam de autoria

A seção de segurança de RFC 5134 observa que objetos valiosos criam incentivo para falsificar metadados como preço ou dimensões. Por isso, assinaturas digitais, resolução segura e relações de confiança são fundamentais. A aplicação deve registrar signatário, campos cobertos, identidade vinculada, validade temporal e política de confiança.

Uma descrição assinada de classe não autentica necessariamente uma unidade serial. Uma descrição íntegra pode estar vencida. E uma descrição perfeitamente verdadeira pode ser consultada por um tag clonado. A assinatura liga uma afirmação ao emissor; não liga sozinha silício, embalagem e conteúdo.

A arquitetura GS1 mantém outra separação importante. O EPC nomeia; o EPCIS compartilha eventos de visibilidade sobre o quê, onde, quando, por quê e como. Um evento é uma afirmação de uma parte responsável, com tempo, ponto de leitura, local de negócio, etapa, disposição e sistema de origem. Ele não é observação contínua entre eventos.

Correções, atrasos e duplicatas devem manter trilha. Um campo de localização é produzido por um dispositivo e um processo, não é o próprio lugar. Cadeia de custódia surge desses eventos somados a recibos de transferência e verificações físicas; lacunas permanecem lacunas.

A escada antes do cadeado

Uma ordem segura começa com registro do namespace, sintaxe, fidelidade lexical e atribuição. Só então vêm observação, autenticidade do suporte, descoberta de serviço, integridade dos metadados, evento de negócio e constatação física. Cada degrau responde a uma pergunta e pode falhar sem apagar os anteriores.

Essa escada muda a função da assinatura. Em vez de encerrar o debate, ela protege uma afirmação claramente situada: quem assinou, qual representação, quais campos e qual escopo. Se a normalização anterior não tiver recibo, a assinatura deve aparecer como válida sobre uma chave cuja correspondência à entrada está pendente.

O modelo comporta a realidade: nome válido sem resolver; serviço disponível com dado antigo; metadado assinado referenciado por cópia; tag autêntico com histórico incompleto; evento íntegro antes de uma entrega fracassada. O sistema não precisa escolher um único rótulo para todos esses estados.

Fontes