Resumo

  • O RFC 5367 permite que uma lista plana, enviada no SUBSCRIBE inicial, crie assinaturas agregadas; respostas ao pedido não comprovam o sucesso de cada recurso, que só se torna observável por notificações compatíveis com rlmi+xml.
  • Pedidos posteriores usam a URI fornecida pelo servidor para o diálogo e não recebem semântica de lista: um corpo recipient-list deve ser omitido e, se enviado, rejeitado com 415.
  • Uma URI purpose=list-management é uma capacidade separada. A lista manipulável é vinculada à vida da assinatura e deveria ser destruída quando ela termina; encerrar o diálogo, revogar o link e apagar todas as cópias exigem recibos diferentes.

O link sobrevivente denunciou uma fronteira perdida

O primeiro NOTIFY pode incluir um cabeçalho Call-Info com uma URI marcada como purpose=list-management. Ela oferece um meio para manipular a lista associada à assinatura.

Esse endereço não é mero texto de ajuda. Quem consegue apresentá-lo ao serviço apropriado pode tentar alterar um conjunto que determina quais recursos serão observados. É uma capacidade e deve ter sujeito, escopo, prazo e revogação.

Guardar o link num painel é conveniente. O problema surge quando a interface confunde persistência visual com validade operacional. Um favorito antigo pode continuar visível depois de o diálogo terminar, mesmo que o servidor já o tenha invalidado; também pode continuar funcional por falha de revogação.

As duas situações pedem respostas distintas. Na primeira, a UI está desatualizada. Na segunda, uma autoridade sobreviveu ao objeto que justificava sua existência. Sem uma tentativa segura ou um recibo de invalidação, a aparência do painel não decide qual delas ocorreu.

A criação tinha uma entrada própria

O UAC envia o SUBSCRIBE inicial à URI pública do recurso de lista. Pelo menos uma parte do corpo usa a disposição recipient-list, e o pedido traz recipient-list-subscribe em Require.

O cliente também precisa aceitar rlmi+xml. O desenho separa a declaração do conjunto da observação de seus membros: a lista entra no pedido inicial; os resultados constituintes chegam pelas notificações.

O formato padrão vem do RFC 4826, mas o serviço exige uma lista plana. Hierarquias e entry-ref não são necessários; o cliente deveria evitá-los, e o servidor pode descartar informação adicional.

Por isso, a cadeia de custódia deve guardar o documento original, o perfil aceito, os elementos descartados, a normalização de URI e o conjunto canônico resultante. O hash do arquivo prova quais bytes chegaram, não prova automaticamente quais recursos ganharam significado operacional.

Uma resposta não continha três resultados

O RFC 5367 afirma que o código de resposta ao SUBSCRIBE não informa se o servidor conseguiu assinar as URIs da lista. A resposta pertence ao pedido de nível superior.

Um 2xx pode estabelecer o diálogo enquanto alguns destinos ainda estão pendentes, recusam o evento, exigem autorização ou falham por rota. Transformar esse 2xx em “todas as assinaturas ativas” muda silenciosamente o sujeito da afirmação.

O RFC 4662 fornece o modelo de notificação para listas. A informação rlmi+xml permite conservar posições distintas para os recursos por trás de uma única relação agregada.

O painel deve mostrar ao menos dois números: estado do diálogo e cobertura constituinte. O denominador vem da lista canônica; o numerador não pode ser redefinido como “itens que apareceram na última notificação”. Ausência precisa continuar como ausência ou desconhecido.

A notificação era evidência temporal

Mesmo o NOTIFY correto não é uma fotografia eterna. Versão, ordem, completude e horário de observação determinam o que ele pode afirmar.

Cada posição precisa de URI canônica, instância, estado, versão, instante, motivo de término e origem. Se um evento antigo chega depois de um novo, o receptor não deve regredir o estado por ordem de entrega.

Também é preciso saber se a mensagem representa uma visão completa ou uma atualização parcial. Sem essa informação, omitir um item pode significar “inalterado”, “removido”, “não observado” ou “mensagem incompleta”.

Frescor do diálogo e frescor do recurso são relógios distintos. Uma renovação pode manter a relação agregada viva sem produzir observação recente para cada posição.

A renovação não podia reescrever a lista

Depois de estabelecido o diálogo, o UAC pode enviar novos SUBSCRIBE para estender a duração. Esses pedidos vão para a URI que o servidor forneceu como alvo remoto do diálogo.

O RFC 5367 não define semântica para um corpo de lista nessas solicitações seguintes. O cliente deve omiti-lo; o servidor que o recebe responde 415 Unsupported Media Type.

Essa recusa preserva a diferença entre manter e recriar. Se o operador pudesse anexar outra lista a uma renovação, a credencial para prolongar uma assinatura também ampliaria o universo observado.

Um produto não deve “ser útil” aceitando o corpo e mesclando entradas. Tal comportamento inventaria uma operação que o contrato não distribuiu e tornaria impossível saber qual lista fundamentou as permissões originais.

Cada URI governava uma fase

No começo há a URI pública da lista. Durante o diálogo há a URI fornecida pelo servidor. Opcionalmente há a URI de gestão anunciada no NOTIFY.

A primeira cria a relação, a segunda a mantém e a terceira modifica a lista associada. Compartilhar o mesmo ambiente ou domínio não torna seus poderes intercambiáveis.

Os registros devem ligar URI pública, principal autenticado, evento, documento e conjunto, identificadores de diálogo, alvo de continuação e URI de gestão. Também devem registrar a decisão que emitiu cada capacidade.

Uma requisição sintaticamente válida enviada à superfície errada pode ser um erro de roteamento de autoridade. Contar apenas métodos SUBSCRIBE ou códigos HTTP/SIP esconde essa diferença.

A lista tinha prazo porque concentrava relações

Uma lista de observação agrega informação sobre pessoas, serviços ou dispositivos. Mesmo quando as URIs isoladas não parecem sensíveis, a seleção revela intenção, responsabilidade e proximidade operacional.

O RFC 5367 vincula a vida de uma lista manipulável à assinatura. Ela deveria ser destruída quando a assinatura expira ou termina por outro motivo.

Essa regra impede que um artefato temporário vire diretório permanente por inércia. Também limita o período durante o qual uma URI de gestão pode expor ou alterar o conjunto.

O verbo “destruir”, porém, precisa de projeção operacional. Pode haver registro primário, cache, índice, réplica, backup e trilha de auditoria. A organização deve declarar quais superfícies somem, quais ficam sob exceção, por quanto tempo e com que controles.

Expires zero não era um recibo de apagamento

Enviar Expires: 0 ou receber uma terminação prova uma transição protocolar. Não prova que cada armazenamento eliminou os dados nem que o link de gestão deixou de autorizar.

O ciclo precisa de marcos separados: pedido de término aceito, diálogo encerrado, capacidade revogada, registro primário removido, derivados limpos e exceções seladas. Cada marco tem responsável e prazo.

Se a limpeza assíncrona falhar, o estado deve permanecer “pendente de destruição”, não “apagado”. Repetir a operação exige idempotência para evitar recriar a lista ou apagar o objeto errado.

Backups não precisam fingir exclusão instantânea. Precisam de uma política verificável de retenção, restauração e reaplicação de tombstones para que uma recuperação não ressuscite a capacidade.

O cliente autenticado ainda dependia de opt-in

O mecanismo herda as considerações de segurança dos RFCs 4662 e 5363. O servidor autentica e autoriza o cliente, e a proteção do serviço inclui o consentimento adequado dos destinatários.

Saber quem pede não responde se cada alvo aceitou aquele pacote de eventos, finalidade e duração. Credencial do chamador e permissão do recurso são relações distintas.

A decisão de política deve ligar principal, serviço, evento, URI canônica, finalidade, duração e versão da regra. Um papel amplo não deve virar passe para construir listas arbitrárias.

Recusas precisam de motivo controlado, inclusive quando detalhes não podem ser revelados ao cliente. Internamente, privacidade, ausência de opt-in, rota, erro e pendência não deveriam colapsar na mesma célula vazia.

O registro nomeava capacidades, não provava exercício

A IANA registra o option-tag recipient-list-subscribe e o propósito list-management. Esses nomes permitem reconhecimento interoperável.

Sua presença não prova que um servidor assinou todos os recursos, que o link foi usado, que a alteração foi autorizada ou que a lista foi destruída. Vocabulário de protocolo não substitui telemetria de execução.

O RFC 5367 foi publicado em outubro de 2008 como Standards Track e atualizou o RFC 3265 no uso de Call-Info em NOTIFY. O RFC 6665 mais tarde tornou o RFC 3265 obsoleto. Implementações atuais devem considerar essa evolução sem apagar os limites de fase.

As notas de Lu Heng oferecem a lente declarada. Minimum Initial Specification explica por que uma base compartilhada não deve inventar semântica de mutação para renovações. Reality Layers lembra que lista, URI, resposta, notificação e cronômetro são símbolos de realidades diferentes. Os fatos do protocolo continuam apoiados nos RFCs e no registro da IANA.