RFC 3261 SIP: Session Initiation Protocol Junho 2002
Considerações de segurança: ver adiante
Motivação e exemplos desse uso como um mecanismo de segurança em conjunto com o S/MIME são dados em 23.4.
27.6 Novos Registros de Parâmetros para Content-Disposition
Esse documento também registra quatro novos "disposition-types" do cabeçalho Content-Disposition: alert, icon, session e render. Os autores pedem que esses valores sejam registrados no registro do IANA para Content-Dispositions.
Descrições desses "disposition-types", incluindo motivação e exemplos, são dadas na Seção 20.11.
Descrições curtas adequadas para o registro no IANA são:
alert o corpo é um tom de ring customizado para alertar o usuário
icon o corpo é exibido como um ícone ao usuário
render o corpo deve ser exibido ao usuário
session o corpo descreve uma sessão de comunicações, por exemplo, como corpo SDP conforme a RFC 2327
28 Mudanças Desde a RFC 2543
Essa RFC revisa a RFC 2543. É principalmente retro-compatível com a RFC 2543. As mudanças descritas aqui resolve muitos erros descobertos na RFC 2543 e fornece informação sobre cenários não detalhados na RFC 2543. O protocolo foi apresentado em um modelo em camada mais claro aqui.
Nós dividimos as diferenças no comportamento funcional que é uma mudança substancial desde a RFC 2543, que tem impacto sobre a interoperabilidade ou operação correta em alguns casos, e o comportamento funcional que está diferente desde a RFC 2543, mas não é uma fonte potencial de problemas de interoperabilidade. Tem havido inúmeros esclarecimentos também, que não estão documentados aqui.
28.1 Mudanças Funcionais Relevantes
o Quando um UAC deseja terminar uma chamada antes dela ter sido atendida, ele envia o CANCEL. Se o INVITE original ainda retornar uma 2xx, o UAC então envia o BYE. O BYE só pode ser enviado em uma perna da chamada existente (agora chamada de um diálogo nessa RFC), ao passo que poderia ser enviado em qualquer momento na RFC 2543.
o O BNF do SIP foi convertido para ficar em conformidade com a RFC 2234.
Rosenberg, et. al. Standards Track [Página 255]
Observações importantes a cerca dessa tradução:
A tradução de algumas terminologias do SIP:
User agent ficou como agente-usuário;
Header field como campo-cabeçalho;
Requests ficou em português como requisições no plural e no singular requisição.
Quanto às palavras/verbos usadas em documentos RFC's tramitando em trilha de
padronizações, que obedecem as regras da RFC 2119/IETF, foram traduzidas
para o português conforme a seguir:
MUST:
PRECISA, REQUERER, OBRIGAR, EXIGIR, FORÇAR, É OBRIGATÓRIO, É FORÇOSO,
NECESSITAR, É MANDATÓRIO.
MUST NOT:
NÃO PODE, É PROIBIDO, É VEDADO.
SHOULD:
DEVE, É RECOMENDADO.
SHOULD NOT:
NÃO DEVE, NÃO É RECOMENDADO.
MAY:
PODE, É OPCIONAL.
Nenhum comentário:
Postar um comentário