Resumo

  • PARTSTAT=ACCEPTED é o estado de participação comunicado para um usuário de calendário, não uma medição do comparecimento posterior.
  • Resposta, representação, versão, recorrência, entrega e observação do evento precisam permanecer em campos distintos.

Uma empresa quer saber quantas pessoas fizeram um treinamento. A lista de presença ainda não chegou, mas o calendário oferece uma resposta pronta: todos os convites marcados como aceitos. Trocar o nome da coluna de “aceitou” para “compareceu” parece um atalho administrativo. Na verdade, troca a pergunta sem trocar a fonte.

A RFC 5545 define PARTSTAT como o estado de participação do usuário de calendário. Para eventos, aparecem valores como NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE e DELEGATED. Eles organizam intenções e respostas. Não observam uma catraca, uma chamada de vídeo, o tempo de permanência nem a atenção de alguém.

O percurso de Cyrus Daboo entre as camadas

Cyrus Daboo contribuiu justamente para as especificações que transportam esse estado. Foi um dos autores do CalDAV, RFC 4791, escreveu o iTIP, RFC 5546 e dividiu a autoria do CalDAV Scheduling, RFC 6638. Seu perfil no IETF listava 26 RFCs no retrato consultado. A homenagem da CalConnect de 2013 registra sua atuação histórica em calendários interoperáveis.

A autoria da RFC 5545, porém, é de Bernard Desruisseaux. A distinção importa: a história técnica é coletiva, e a contribuição específica de Daboo está no protocolo de troca e na infraestrutura de agendamento que tornam visível a cadeia de autoridade.

O que entra na cópia do organizador

No modelo do iTIP, o organizador controla o objeto mestre do agendamento. Um novo participante costuma começar em NEEDS-ACTION. Ele altera o PARTSTAT de sua própria propriedade ATTENDEE dentro de uma mensagem REPLY; o organizador incorpora a resposta. O STATUS do evento inteiro e o PARTSTAT de cada participante não são a mesma decisão.

Assim, um ACCEPTED na cópia do organizador sustenta uma frase limitada: há uma resposta aceita associada àquele endereço nessa versão do objeto. Não determina quem operou o cliente, se as condições mudaram depois ou se alguém apareceu na hora marcada.

Quem foi convidado pode não ser quem respondeu

A RFC 5546 trata a representação de forma explícita. Um participante pode delegar a outro usuário o direito de comparecer em seu lugar. SENT-BY indica que o usuário que respondeu agiu em nome do participante ou organizador identificado. Assistente, caixa compartilhada ou automação autorizada podem participar do fluxo sem fraude alguma.

O endereço convidado, o agente que disparou a resposta e a pessoa presente são identidades potencialmente diferentes. Remover os campos de delegação e manter apenas “aceitou” impede que um auditor reconstrua essa diferença.

Toda aceitação pertence a uma revisão

O organizador pode mudar horário, local ou finalidade. O iTIP usa SEQUENCE para marcar essas revisões e determina que um REPLY não aumente o número. A sequência da resposta liga a decisão do participante à versão que ele recebeu. Uma aceitação anterior a uma mudança relevante não deve ser projetada sobre a versão final.

Eventos recorrentes acrescentam o escopo da ocorrência. A série pode estar aceita enquanto um encontro identificado por RECURRENCE-ID foi recusado, deslocado ou removido. Espalhar o valor geral por todas as datas fabrica presenças que nunca foram informadas.

A automação do CalDAV termina antes da reunião

Na RFC 6638, o agendamento implícito permite que salvar, alterar ou apagar um objeto faça o servidor enviar mensagens de agendamento. Mensagens recebidas podem ser processadas automaticamente. Um REPLY pode atualizar o PARTSTAT no recurso do organizador; SCHEDULE-STATUS pode registrar o resultado da entrega ou do processamento. O agente pode ser SERVER, CLIENT ou NONE.

Essas informações são ótimas para diagnosticar a infraestrutura. Elas não dizem que uma pessoa leu a mensagem ou participou do evento. Confundir sucesso do servidor com ação humana atribui ao convidado um trabalho executado por software.

Presença merece uma fonte própria

Controle de acesso, quórum, capacitação certificada e cobrança podem exigir comprovação. Nesse caso, é preciso declarar qual sinal será observado. Crachás podem ser emprestados; conexões podem ficar abertas; uma chamada nominal pode falhar. O registro precisa guardar o método, a janela de tempo e a possibilidade de correção.

Uma matriz defensável separa endereço convidado, resposta, agente ou representante, SEQUENCE, ocorrência, estado de entrega, sinal do evento, método, horário e exceção. PARTSTAT=ACCEPTED fica na coluna da resposta. Se nenhum sinal de presença foi coletado, a coluna de observação fica vazia.

O vazio não diminui o calendário. Apenas impede que ele seja usado como testemunha de um evento que não observou.