Resumo
- RFC 9873 define um estado explícito para ausência do email adicional e permite preferência quando há valor, sem testar a caixa postal.
- O email básico continua no contato; negociação EPP, estado armazenado, entrega SMTP, divulgação e publicação RDAP têm provas próprias.
Um elemento vazio em RFC 9873 tem semântica operacional: numa atualização, retira o email adicional; numa consulta, mostra que ele está ausente. O atributo primary é proibido nesse estado. Essa precisão evita confundir “sem valor” com uma cadeia defeituosa, mas não transforma um valor presente em prova de alcance.
O email exigido pelo mapeamento de contatos de RFC 5733 permanece. A extensão acrescenta um endereço ASCII ou SMTPUTF8 e pode priorizá-lo. Mensagens podem ser encaminhadas entre os dois, e a resposta pode chegar de outra escrita. Portanto, preferência, rota e identidade continuam sendo conceitos distintos.
Antes do campo há uma negociação. Pelo mecanismo de RFC 5730, cliente e servidor anunciam extensões no login e no greeting. Quando concordam com RFC 9873, precisam aceitar, validar, guardar e devolver o dado e suportar SMTPUTF8 para envio ou recepção. Sem acordo no início da sessão, a extensão não pode ser fornecida nem retornada. Isso comprova capacidade de processamento, não a etapa humana.
MX válido, caixa criada, encaminhamento correto, aceitação SMTP, entrega final, leitura e resposta formam uma sequência posterior. Até a aceitação por um servidor remoto pode terminar em bounce. Marcar primary=true não executa nenhuma dessas verificações.
O tratamento de Unicode exige atenção adicional. RFC 6530 descreve a arquitetura internacionalizada e RFC 6531 amplia SMTP. RFC 9873 recomenda repertórios controlados, domínio conforme IDNA2008 e testes com sequências combinantes. RFC 5895 orienta o mapeamento em interfaces; as tabelas IDNA da IANA registram a situação dos pontos de código. Armazenar e devolver bytes não encerra a análise de formas visualmente confundíveis.
A divulgação, por outro lado, precisa ser comum: a regra do email básico deve alcançar todos os emails adicionais. A apresentação pública continua separada. O endereço pode ser processado em RDAP sob STD 95, sem obrigação de expor literalmente tudo o que EPP guarda. O aviso da ICANN de 2026 contextualiza formulários e endereços pseudonimizados; não é um relatório de adoção da extensão.
Pelas camadas de realidade de Heng Lu, capacidade, valor configurado, normalização, armazenamento, divulgação, tentativa SMTP, resultado, ação do destinatário e projeção pública pertencem a registros diferentes. A especificação inicial mínima sustenta um núcleo interoperável estreito. A primazia do código em operação exige evidência reproduzível ao atravessar cada fronteira.
O mérito de RFC 9873 é descrever mais um estado sem inventar um resultado. O erro executivo começa quando sistemas posteriores chamam preferência de verificação, aceitação de entrega ou mecanismo público de exposição do valor privado.
Fontes
- Texto de RFC 9873
- Registro oficial de RFC 9873
- Registro STD 95
- RFC 5730: EPP
- RFC 5733: contato EPP
- RFC 5895: mapeamento IDNA
- RFC 6530: email internacionalizado
- RFC 6531: extensão SMTP
- Tabelas IDNA da IANA
- Aviso da ICANN sobre formulários
- Heng Lu: camadas de realidade
- Heng Lu: especificação inicial mínima
- Heng Lu: primazia do código em operação
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance

