Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP

RFC 3261            SIP: Session Initiation Protocol           Junho 2002


se os dois eram inicialmente idênticos. Assim, isso PODE ser desejável por razões de privacidade ao criar um campo-cabeçalho To que difira do Request-URI.


27 Considerações do IANA

Todos os nomes de métodos, nomes de campo-cabeçalho, códigos de status e tags option usada nas aplicações SIP estão registrados no IANA conforme instruções em uma seção Considerações do IANA em uma RFC.

A especificação instrui o IANA a criar quatro novos sub-registros em http://www.iana.org/assignments/sip-parameters: Tags Option, Códigos de Aviso (warn-codes), Códigos de Métodos e Respostas, adicionado ao sub-registro de campos-cabeçalhos que já está presente lá.


27.1 Tags Option

Essa especificação estabelece o sub-registro Option Tags sob http://www.iana.org/assignments/sip-parameters.

Option tags são usados em campos-cabeçalhos, como Require, Supported, Proxy-Require e Unsupported em suporte de mecanismos de compatibilidade para extensões SIP (Seção 19.2). A tag option em si é uma string que está associada com uma opção SIP particular (isto é, uma extensão). Ela identifica a opção de endpoints SIP.

Tags option estão registradas no IANA quando são publicadas em RFCs da trilha de padrões. A seção Considerações IANA da RFC precisa incluir as seguintes informações, que aparecem no registro do IANA junto com o número RFC da publicação.

o  Nome da option tag. O nome PODE ser de qualquer tamanho, mas DEVE ser não mais que vinte caracteres longo. O nome PRECISA consistir de caracteres alfanuméricos (Seção 25) somente.

o  Texto descritivo que descreve a extensão.


27.2 Warn-Codes

Essa especificação estabelece o sub-registro de Warn-codes em http://www.iana.org/assignments/sip-parameters e inicia sua população com os warn-codes listados na Seção 20.43. Warn-codes adicionais estão registrados pela publicação RFC.






Rosenberg, et. al.          Standards Track                   [Página 252]

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.