Resumo

  • A revisão 08 do rascunho de extensões iCalendar cria o papel OWNER, mas afirma que ele é apenas indicativo e não pode conceder sozinho autoridade para mudar um objeto de calendário.
  • JMAP Calendars expõe os controles que faltam: o participante precisa corresponder a uma identidade da conta, e os direitos atuais do calendário e as restrições do evento ainda precisam permitir a ação.
  • Interpretar o papel, autorizar, salvar, despachar mensagens, obter processamento remoto e mostrar a mudança ao participante são comprovantes separados.

O registro perigoso não precisa estar malformado. Pode obedecer à sintaxe, passar pelo analisador e exibir um selo de proprietário convincente. A falha começa quando o software transforma essa descrição em permissão.

A revisão 08 define OWNER como papel de participação. O texto diz que um proprietário pode realizar mudanças que afetam todos, como remarcar ou adicionar e remover participantes e papéis. Em seguida fixa a fronteira decisiva: o papel é indicativo, sua semântica depende do protocolo de troca, e nenhuma implementação deve conceder capacidade de alteração apenas porque ele aparece no objeto.

Isso separa uma alegação transportada pelos dados do poder exercido pelo sistema. Em calendários, a confusão é fácil porque o papel chega ao lado de horários, locais, recorrência e participantes que a interface já trata como acionáveis.

A alegação viaja; a autoridade não viaja automaticamente

RFC 5545 oferece uma representação portátil. O mesmo objeto pode passar por arquivos, mensagens, depósitos CalDAV e serviços JMAP com contas, identidades e direitos diferentes. Por isso um papel não pode carregar uma autorização universal.

O rascunho diz expressamente que não define a semântica de OWNER no CalDAV. Um receptor pode preservar e mostrar o papel, mas não inventar uma regra de escrita ausente no protocolo. Uma futura entrada nos registros iCalendar da IANA também não autenticaria o participante nem concederia poder; o registro coordena o nome e a referência.

A Minimum Initial Specification sustenta esse desenho. A linguagem comum deve permitir interoperabilidade sem centralizar decisões futuras. OWNER pode ser vocabulário compartilhado; a concessão continua local ao protocolo e à autoridade que o opera.

JMAP torna a decisão observável

O JMAP Calendars ativo considera o usuário proprietário somente quando um Participante tem o papel owner e corresponde a uma ParticipantIdentity desse usuário na conta.

Nem essa combinação cria poder universal. mayWriteOwn permite criar, modificar ou destruir eventos apenas no calendário em que o direito vale e apenas quando o usuário possui o evento ou o evento não tem proprietário. mayWriteAll, mayRSVP, mayShare e mayDelete representam capacidades distintas.

Em CalendarEvent/set, o servidor deve impor myRights e rejeitar a mudança não permitida com forbidden. Esse veredito é o comprovante de autoridade. O papel é só uma entrada da decisão.

Origem, privacidade, recorrência e associação a calendários podem restringir novamente a ação. Quando uma cópia não é a origem do agendamento, o cliente deve limitar edições a propriedades por usuário, ainda que os direitos pareçam mais amplos, pois uma atualização autoritativa posterior pode sobrescrever a cópia.

Etapa O que prova O que continua aberto
Análise OWNER aparece em sintaxe válida Quem declarou e se ainda vale
Identidade O participante corresponde à conta Direitos sobre calendário e evento
Autorização Uma regra atual permite a ação Se a mudança foi aceita
Mutação O servidor gravou novo estado Se mensagens foram enviadas
Entrega Outro sistema recebeu mensagem Se aplicou e exibiu
Releitura Um participante vê a mudança Convergência durável de todas as cópias

Salvar não é mudar a reunião para todos

JMAP permite solicitar mensagens de agendamento junto com uma alteração. A solicitação não prova entrega. O servidor pode salvar localmente, selecionar destinatários e depois enfrentar falha de transporte, rejeição remota ou uma cópia que ninguém consulta.

RFC 6638 e RFC 4791 mostram armazenamento e agendamento como superfícies relacionadas, mas distintas. Coleção, autoridade do usuário, caixa de saída e cópia do participante não formam um único fato atômico.

Um registro forte liga hash do objeto, posição do papel, correspondência de identidade, versão de direitos, origem e privacidade, decisão de política, identificador e hashes da mutação, seleção de destinatários, transporte e releitura. Não é preciso armazenar conteúdo privado: identificadores, hashes e resultados limitados bastam.

Progresso de padrão não é prova operacional

O Datatracker mostra a revisão 08 como Internet-Draft do grupo CALENDAR EXTENSIONS destinado a Proposed Standard, com publicação solicitada. O histórico e o relatório do shepherd documentam o processo. Ainda não há RFC nem comprovação de comportamento de produtos implantados.

O documento também adiciona SHOW-WITHOUT-TIME, mas esclarece que a apresentação não muda o intervalo temporal usado para conflitos. A mesma disciplina vale aqui: aparência não reescreve estado; OWNER não reescreve autorização.

Running-Code Primacy manda examinar a identidade resolvida, os direitos carregados e o veredito real. The Policy Mirror revela poder em resolução, cache e padrões. Reality Layers mantém sintaxe, papel, autoridade e resultado separados.

A pergunta de liderança não é “o calendário diz proprietário?”, mas “qual sistema concedeu qual operação sobre qual estado, e qual evidência mostra que a mudança chegou às pessoas que dependiam dela?”

Fontes