Resumo

  • iMIP definiu como transportar objetos de calendário do iTIP por e-mail, sem atribuir ao cabeçalho comum do correio o significado do evento.
  • A versão legível para pessoas e a parte text/calendar atendiam a leitores distintos, mas deveriam representar o mesmo objeto, não duas reuniões alternativas.

O transporte não precisava virar agenda

Uma mensagem pode atravessar vários servidores sem que nenhum deles compreenda o que significa “marcar reunião”. O protocolo de agenda precisava, portanto, continuar legível fora do percurso de e-mail. RFC 2447, o iMIP, estabeleceu em 1998 uma ligação entre iTIP e o transporte por MIME: iCalendar define os dados, iTIP define as operações e o e-mail transporta o conjunto. Essa separação permitia discutir uma operação de agenda sem redefinir cada campo de mensagem ou cada agente de correio.

O ponto de ancoragem era uma parte MIME text/calendar. Ela carregava o objeto iCalendar, e o parâmetro MIME method precisava corresponder à propriedade METHOD interna. O valor externo ajuda a reconhecer o tipo da parte; o valor interno pertence ao objeto que o cliente de agenda interpreta. Não são dois votos sobre o método. São duas camadas que devem concordar. Quando a mensagem traz objetos com métodos diferentes, cada objeto fica em sua própria parte calendário, agrupada em multipart/mixed; misturá-los numa única parte apagaria uma distinção relevante.

Duas apresentações não significam dois compromissos

Uma mensagem multipart/alternative pode conter a forma estruturada e uma explicação em texto simples. Um programa sem calendário continua podendo exibir data, local e organizador. Um cliente compatível pode processar o objeto. A segunda apresentação não é outra versão do compromisso para o destinatário escolher: ambas devem se referir ao mesmo conteúdo de agenda.

Se duas partes oferecem horários diferentes, a ambiguidade não pode ser resolvida pelo fato de ambas aparecerem no mesmo pacote. Uma alternativa MIME muda a representação para adequá-la ao leitor; uma contraoferta ou alteração exige a operação apropriada no protocolo de agenda. A estrutura que acomoda texto e calendário é uma ponte de compatibilidade, não uma interface de negociação.

O pacote também precisava sobreviver aos limites do transporte. RFC 2447 especificava o uso de charset quando havia caracteres além de US-ASCII e de codificações apropriadas para partes que não pudessem seguir diretamente pela rota de e-mail. RFC 6047 substituiu RFC 2447 em 2010 e atualizou a ligação para versões posteriores dos formatos de mensagem e do S/MIME. Essas regras dizem respeito a representar e decodificar conteúdo; não demonstram que a mensagem chegou à caixa certa ou que algum cliente alterou uma agenda.

Anexos trazem uma armadilha semelhante. O objeto pode referenciar uma parte por Content-ID ou Message-ID. RFC 2447 recomenda transportar junto as partes referenciadas sempre que possível, pois o destinatário talvez não tenha acesso ao repositório externo. Um identificador não carrega o conteúdo nem concede autorização para buscá-lo.

Também não se deve ler autoridade nos campos do envelope. Depois de um encaminhamento, Sender pode apontar para quem retransmitiu, e o agente de correio não precisa copiar o papel de Organizer para Reply-To. A implementação deve examinar ORGANIZER e ATTENDEE dentro de text/calendar. RFC 2447 descreveu autenticação por multiparts de segurança MIME; a atualização RFC 6047 passou a exigir autenticação S/MIME. Mesmo uma assinatura validada cobre somente o conteúdo protegido: não prova entrega, processamento, consentimento ou comparecimento.

RFC 2447 foi publicado como Standards Track em novembro de 1998 e ficou obsoleto com RFC 6047, de 2010. A sequência documenta evolução de uma fronteira de transporte, não adoção em produtos ou estatísticas de uso. A contribuição histórica foi deixar claro que calendários podiam viajar por e-mail sem que o protocolo de agenda se confundisse com o cabeçalho, o texto de apresentação ou a entrega da mensagem.

Fontes