Resumo

  • O RFC 5196 acrescenta capacidades de serviço e dispositivo ao PIDF para que o watcher escolha melhor antes do contato, inclusive quando um URI sozinho não revela o tipo de serviço.
  • Essa informação é uma projeção sujeita a fonte, tempo, autorização e composição; o próprio RFC diz que ela não substitui a negociação de mídia, como SDP, nem comprova o resultado da sessão.

Um identificador não descreve o que atenderá

Um endereço de contato diz onde começar. Ele não responde necessariamente o que existe atrás daquele tuple. Foi essa lacuna que motivou o RFC 5196: representar características de agentes SIP usando o vocabulário de capacidades do RFC 3840, dentro do modelo de pessoa, serviço e dispositivo do RFC 4479.

O ganho é prático. Antes de convidar, um watcher pode preferir um serviço que anuncie vídeo, certo tipo de mensagem ou determinada linguagem. Evita tentativas evidentemente inadequadas e apresenta escolhas melhores ao usuário. Mas o endereço, a capacidade e a sessão continuam sendo três coisas.

O escopo do RFC descreve as capacidades como pistas sobre preferências, disposição e aptidão antes do contato. E afirma explicitamente que a extensão não substitui a negociação de mídia SIP, por exemplo SDP. Um documento pode orientar o início; a oferta e a resposta determinam o que foi acordado naquela chamada.

A vista pertence a um watcher

Não há um catálogo universal que todos recebem. O presentity pode deixar de publicar uma capacidade real; o texto exemplifica um serviço de voz que o usuário prefere não revelar. Regras de autorização e servidores de presença podem limitar ou modificar as informações de acordo com quem observa.

Logo, a ausência não equivale a não suportado. Ela pode significar não divulgado, desconhecido, vencido, filtrado ou pertencente a outro objeto. O formato reserva supported para uma afirmação positiva e notsupported para uma negativa. Não incentiva uma lista exaustiva de negativas sem relevância.

Quando o mesmo valor aparece dos dois lados, o watcher pode supor suporte. A regra permite continuar diante de uma inconsistência; ela não transforma a vista em inventário completo. Um sistema que apaga uma das entradas também apaga a pergunta que precisará responder depois: quem disse o quê e em qual contexto?

Serviço e dispositivo têm fronteiras

As extensões de capacidade de serviço e de dispositivo não são nomes alternativos para a mesma coisa. Um serviço pode oferecer vídeo por meio de um aparelho e apenas áudio por outro. Um dispositivo pode processar uma linguagem sem que uma pessoa capaz e disposta a falar esteja disponível. O URI pode identificar um serviço sem provar qual endpoint receberá a próxima solicitação.

Essas fronteiras evitam a propagação indevida. Copiar uma característica de um serviço para todos os dispositivos cria compatibilidade fictícia. Somar características de vários dispositivos pode produzir um terminal imaginário que tem tudo. Cruzá-las pode esconder o aparelho que realmente atenderia.

O RFC admite que a combinação de múltiplas fontes pode provocar perda ou desencontro. Portanto, o compositor toma decisões. Precisa registrar as entradas, seus sujeitos, horários, expiração e a regra usada. Sem essa proveniência, uma vista composta não é mais confiável por parecer limpa.

O relógio muda o significado

Capacidades são descritas como características dinâmicas. Entre a publicação e o contato, um aparelho pode sair, um cliente pode reiniciar, a política pode mudar e um cache pode conservar um documento anterior. O RFC não exige alinhamento perfeito entre presença e capacidade real e alerta o watcher para não esperá-lo.

Existem vários tempos, não um só: observação na fonte, publicação, recebimento pelo servidor, transformação, composição, entrega ao watcher e convite. Um único atualizado em não mostra onde ocorreu o atraso. A expiração deve acompanhar o valor e o objeto ao qual ele pertence.

Esse limite impede duas falhas simétricas mencionadas pelo RFC. Uma informação incompleta pode convencer o watcher de que uma comunicação possível não existe. Uma informação falsa ou antiga pode induzir uma tentativa impossível. Nenhuma delas autoriza chamar o mecanismo de inútil; ambas exigem tratar o resultado como previsão limitada.

Do URI ao resultado, sem atalhos

O recibo mínimo de presença deve conter presentity, watcher e assinatura; tuple, serviço ou dispositivo; agente publicador; versão da fonte; publicação e expiração; estado positivo, negativo ou não divulgado; regra de autorização; transformação do servidor; entradas e resolução da composição; hash e hora da vista recebida.

Depois começa outro recibo. Qual sinal levou à escolha do URI? Qual endpoint respondeu? Quais foram solicitação e resposta SIP, oferta e resposta SDP, mídia negociada, disposição humana e resultado observado? A ligação entre os recibos explica a decisão sem conceder à presença autoridade sobre a sessão.

Esse esquema é uma inferência operacional, não uma extensão do protocolo. Ele aplica a disciplina de realidade de Heng Lu: símbolos úteis não devem dominar o sistema vivo que resumem. O URI aponta, a presença aconselha, a política limita, a negociação acorda e o endpoint executa. Preservar esses verbos é preservar a capacidade de provar.

Sources

  1. RFC 5196 em HTML
  2. Texto do RFC 5196
  3. Página de informações do RFC 5196
  4. IETF Datatracker: RFC 5196
  5. Histórico do RFC 5196
  6. Referências do RFC 5196
  7. Errata do RFC 5196
  8. RFC 3840
  9. RFC 3863
  10. RFC 4479
  11. RFC 3859
  12. RFC 4566
  13. RFC 3261
  14. RFC 2778
  15. RFC 3856
  16. RFC 3903
  17. RFC 5025
  18. Heng Lu — camadas de realidade e poder simbólico
  19. Heng Lu — especificação inicial mínima
  20. Heng Lu — primazia do código em execução