Resumo

  • RESERVE tornava o nome indisponível para outra reivindicação, mas a RFC 3656 deixava claro que isso não significava que a caixa estava pronta para o cliente.
  • MAILBOX indicava um registro ativo e acessível, após a criação local e ACTIVATE. A sequência era recomendada, mas dependia da cooperação dos participantes; não era uma pré-condição imposta pelo servidor.

Primeiro o nome, depois a caixa

Um conjunto de servidores de correio precisa responder a duas perguntas diferentes: qual servidor é responsável pelo nome e a caixa pode ser usada agora? Publicada como protocolo Experimental em dezembro de 2003, a RFC 3656 manteve essas respostas separadas. O MUPDATE buscava oferecer um espaço de nomes unificado para servidores IMAP e POP3 enquanto várias máquinas compartilhavam a responsabilidade pela entrega.

A sequência típica começava com RESERVE. O cliente pedia ao servidor mestre que reservasse um nome de caixa postal em determinado local. Depois de receber OK, criava a caixa localmente e enviava ACTIVATE com nome, local e ACL. A ativação bem-sucedida tornava o registro ativo. O campo de local podia orientar o cliente ao servidor que armazenava a caixa; a ACL descrevia as permissões de acesso.

As respostas mostram a fronteira. RESERVE significa que outro participante não pode mais assumir o nome, mas a RFC afirma explicitamente que isso não significa que a caixa esteja disponível aos clientes naquele momento. MAILBOX descreve um registro pronto para acesso. Tratar os dois como sinônimos transformaria um bloqueio de espaço de nomes em um falso sinal de disponibilidade: o objeto local talvez ainda não exista ou a criação não tenha terminado.

A atomicidade era uma disciplina compartilhada

O MUPDATE descrevia um mestre com a base autoritativa e servidores escravos que a replicavam. Clientes podiam consultar qualquer um deles; mudanças na base deveriam ser enviadas ao mestre. A criação cruzava, portanto, duas superfícies: o registro distribuído do nome e o armazenamento local da caixa. O protocolo coordenava essas partes sem transformá-las em uma única transação atômica.

A linguagem normativa deixa esse limite visível. Caixas novas SHOULD ser reservadas antes de ativadas porque o projeto pressupunha que participantes autenticados cooperariam para manter as operações atômicas. Mesmo assim, ACTIVATE não exige uma reserva prévia. A especificação permite essa possibilidade para facilitar a sincronização com a localização real das caixas. Um participante que ignora o bloqueio compartilhado pode contribuir para uma base inconsistente. A base não consegue inferir uma transação local que nunca foi comunicada.

DEACTIVATE devolvia um nome ativo ao estado reservado; não era o mesmo que apagar o nome do espaço de nomes. A RFC também avisava que ACLs conhecidas poderiam ser perdidas nessa transição. Durante uma migração ou uma criação interrompida, o nome pode continuar reivindicado sem que uma caixa ativa seja anunciada. O local registrado tampouco prova que um usuário entrou ou leu mensagens.

O OK da réplica tinha um limite

Depois que um escravo emitia UPDATE, o mestre enviava uma lista inicial e, em seguida, as mudanças posteriores. A especificação exigia que uma alteração no mestre fosse transmitida ao escravo em até 30 segundos. O escravo podia enviar NOOP; depois de UPDATE, a resposta OK só poderia retornar após o envio de todas as mudanças pendentes no instante daquele NOOP. Isso criava um ponto de sincronização delimitado, não uma garantia de que a base continuaria globalmente atual depois da resposta.

É uma confirmação útil, mas estreita: mostra que o fluxo pendente chegou a uma réplica em certo instante. Não demonstra a chegada de uma alteração posterior, a saúde do armazenamento local nem o acesso do usuário final. A RFC 3656 é Experimental; documenta um contrato de coordenação proposto, não implantações atuais ou disponibilidade medida.

Fontes