Resumo

  • No iTIP da RFC 2446, um COUNTER completo enviado por um participante é uma proposta de evento alternativo; ele não modifica por si só a entrada-mestre controlada pelo organizador.
  • Se o organizador aceitar a proposta, a decisão e a distribuição de um novo REQUEST aos participantes afetados constituem etapas separadas, com estados e autoridades diferentes.

Imagine um caso expressamente hipotético. Uma reunião está marcada para segunda-feira. Um participante prefere terça e envia um COUNTER contendo um VEVENT completo com o horário alternativo. O fato de a mensagem descrever integralmente a terça-feira não significa que a agenda mestre tenha mudado. No modelo definido pela RFC 2446, o COUNTER comunica uma proposta; o organizador continua controlando o registro principal e precisa decidir o que fazer com ela.

Essa separação é central para compreender o iCalendar Transport-Independent Interoperability Protocol, ou iTIP. Publicada em novembro de 1998 como Standards Track, a RFC 2446 definiu transações de agendamento independentes do transporte e posteriormente foi obsoletada pela RFC 5546. A RFC 2445 fornecia o modelo de objetos iCalendar, enquanto a RFC 2447 ligava o protocolo ao email; mais tarde, a RFC 6047 atualizou esse vínculo por meio do iMIP.

O iTIP distingue papéis de protocolo. O Organizer inicia a troca, e os usuários convidados atuam como Attendees. Esses papéis não devem ser confundidos com o parâmetro descritivo ROLE da propriedade ATTENDEE. Essa diferença importa porque a autoridade não é deduzida apenas de uma propriedade textual: o organizador controla a entrada-mestre, enquanto cada participante controla sua própria resposta.

A RFC 2446 também separa o estado global do evento do estado individual. STATUS descreve o estado geral do componente; PARTSTAT descreve a situação de um participante específico. Assim, aceitar, recusar ou propor outra configuração não equivale automaticamente a alterar o evento para todos.

Os métodos reforçam essa divisão. PUBLISH distribui informação sem esperar uma resposta interativa. REQUEST pede processamento de uma solicitação de agendamento e admite resposta. REPLY comunica o estado de um participante. COUNTER propõe uma mudança. DECLINECOUNTER permite que o organizador rejeite essa contraproposta. Na RFC 2446, o COUNTER carrega um VEVENT ou VTODO alternativo completo, mas o conteúdo completo continua sendo uma proposta, não um commit no registro mestre.

Se o organizador aceitar a terça-feira do exemplo hipotético, a aceitação não acontece simplesmente porque o COUNTER chegou ou foi interpretado. O organizador reprograma o evento e envia um novo REQUEST aos participantes afetados. A RFC 5546 preserva essa lógica: proposta, decisão e redistribuição são transições distintas.

SEQUENCE também não deve ser lido como medidor de consentimento. Ele acompanha revisões controladas pelo organizador. Na RFC 2446, REPLY, REFRESH, COUNTER, DECLINECOUNTER e um REQUEST usado para delegação não incrementam o valor, enquanto ADD e CANCEL o incrementam. Uma resposta pode ainda se referir a uma versão anterior. Portanto, um número maior, isoladamente, não demonstra concordância, autorização ou convergência entre calendários.

O mesmo princípio aparece no encaminhamento. Um participante pode encaminhar um convite a alguém que não estava originalmente na lista, mas isso não acrescenta automaticamente o novo usuário à lista-mestre. A decisão permanece com o organizador, e quem encaminha não deve modificar as propriedades do objeto para fabricar essa inclusão.

O transporte introduz outra camada. Em sistemas store-and-forward, mensagens podem chegar fora de ordem. A RFC 2446 admite, por exemplo, que um CANCEL chegue antes do REQUEST original. Para um CANCEL ainda não correlacionado e com SEQUENCE diferente de zero, o texto recomenda retenção temporária enquanto se aguarda uma versão anterior e permite que essa informação expire. Ordem de recepção, portanto, não é sinônimo de ordem lógica.

Também não há autenticação embutida nos papéis iTIP. A RFC 2446 chama atenção para falsificação de mensagens atribuídas a organizadores ou participantes e deixa autenticação e confidencialidade para a vinculação de transporte. O fato de uma mensagem ser sintaticamente válida ou conter METHOD, UID, SEQUENCE e propriedades coerentes não demonstra que o remetente tinha autoridade para produzir o efeito pretendido.

Por isso, a análise operacional precisa preservar camadas distintas: bytes recebidos; identidade autenticada do remetente e sua autorização; METHOD e UID; SEQUENCE; PARTSTAT individual; conteúdo do COUNTER; decisão do organizador; novo REQUEST; recepção no transporte; commit no calendário local; lembrete produzido; e participação realmente observada. Um COUNTER parseado, um número de sequência maior, um recibo, um REPLY, uma linha aceita na interface ou até um evento visível não comprovam sozinhos autorização, convergência, presença ou realização.

A arquitetura do iTIP torna explícitos os incentivos. O participante pode propor. O organizador controla o mestre. Cada participante controla sua resposta. O transporte pode provar aspectos sobre o remetente, conforme sua própria vinculação. O protocolo funciona justamente porque essas responsabilidades não são condensadas em um único sinal.

Fontes