RFC 3261 Português Página 153 :: Admirável Mundo Novo




Muito Bem Vindo

Prezado Leitor, a proposta desse Blog é compartilhar conhecimento com as pessoas que trabalham com Linux, Asterisk, OpenSER, e com tecnologia de voz sobre a rede IP em geral, através de tutoriais, dicas, howto, notícias entre outros assuntos.

Atente para termo de uso do conteúdo do blog no rodapé da página.

segunda-feira, 11 de julho de 2011

RFC 3261 Português Página 153

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
Expansão dos tokens hname e hvalue da Seção 25 mostra que todos os caracteres reservados de URI nos nomes de campo-cabeçalho e valores PRECISAM ser escapados.
O subconjunto de assinantes telefônico do componente usuário tem considerações especiais para escapar. O conjunto de caracteres não reservado na descrição da RFC 2806 [9] de assinante telefônico contém inúmeros caracteres em vários elementos de sintaxe que precisam ser escapados quando usados em URI's do SIP. Quaisquer caracteres que ocorrem em um assinante telefônico que não aparecem em expansão do BNF pela regra de usuário PRECISAM ser escapados.
Nota que escapar caractere não é permitido no componente host de um URI do SIP ou do SIPS (o caractere % não é válido em sua expansão). É provável que isso mude no futuro quando as exigências para nomes de domínio internacionalizados sejam finalizados. Implementações atuais NÃO PODE tentar melhorar a robustez ao tratar caracteres escapados recebidos no componente host, como, literalmente, equivalente a suas contrapartes escapadas. O comportamento exigido para atender as exigências do IDN podem ser significativamente diferentes.
19.1.3 Exemplo de URI's do SIP e do SIPS
   sip:alice@atlanta.com
   sip:alice:secretword@atlanta.com;transport=tcp
   sips:alice@atlanta.com?subject=project%20x&priority=urgent
   sip:+1-212-555-1212:1234@gateway.com;user=phone
   sips:1212@gateway.com
   sip:alice@192.0.2.4
   sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com
   sip:alice;day=tuesday@atlanta.com
A última amostra de URI acima tem um valor de campo user "alice;dia=tuesday". As regras de escape definidas acima permitem ao ponto e vírgula aparecer não escapado nesse campo. Para o propósito desse protocolo, o campo é opaco. A estrutura desse valor só é útil ao elemento SIP responsável pelo recurso.
19.1.4 Comparação de URI
Algumas operações nessa especificação requerem determinar se dois URI's do SIP ou do SIPS são equivalentes. Nessa especificação, registradores precisa comparar ligações em URI's de Contact em requisições REGISTER (veja Seção 10.3.). URI's do SIP e do SIPS são comparados por igualdade de acordo com as seguintes regras:
o Um URI do SIP e do SIPS nunca são equivalentes.
Rosenberg, et. al.          Standards Track                   [Página 153]


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:




Creative Commons License
Admirável Mundo Novo: Tudo Sobre Asterisk, OpenSER, Linux e Tecnologias de Voz sobre IP
by Cléviton Mendes de Araújo is licensed under a Creative Commons Atribuição 2.5 Brasil License.