RFC 3261 Português Página 253 :: 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.

domingo, 10 de julho de 2011

RFC 3261 Português Página 253

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
O texto descritivo para a tabela de warn-codes é:
Warning codes fornecem informação suplementar ao código de status em mensagens resposta do SIP quando a falha da transação resulta de um problema do Session Description Protocol (SDP) (RFC 2327 [1]).
O "warn-code" consiste de três dígitos. Um primeiro digito de "3" indica avisos específicos ao SIP. Até uma futura especificação descrever usos de warn-codes diferentes de 3xx, só warn-codes 3xx podem ser registrados.
Avisos de 300 até 329 estão reservados para indicar problemas com keywords na descrição de sessão, de 330 até 339 são avisos relacionados com serviços de rede básicos requisitados na descrição de sessão, de 370 até 379 são avisos relacionados a quantitativo de parâmetros de QoS requisitados na descrição de sessão, e 390 a 399 são avisos miscelaneos que não caem em nenhuma das categorias acima.
27.3 Nomes de Campo-Cabeçalho
Essa obsoleta as instruções IANA no sub-registro de header sob http://www.iana.org/assignments/sip-parameters.
A informação seguinte precisa ser fornecida em uma publicação RFC a fim de registrar um novo nome de campo-cabeçalho:
o  O número RFC em que o cabeçalho está registrado;
o  o nome do campo-cabeçalho sendo registrado;
o  uma versão da forma compacta para esse campo-cabeçalho, se algum for
         definido;
Alguns campos-cabeçalhos comuns e amplamente usados PODEM ser atribuídos formas compactas de uma letra (Seção 7.3.3). Formas compactas só podem ser atribuídas após revisão do grupo de trabalho do SIP, seguido pela publicação da RFC.
27.4 Códigos de Métodos e Respostas
Essa especificação estabelece os sub-registros de Método e de Código-Resposta sob http://www.iana.org/assignments/sip-parameters e inicia sua população como segue. A tabela de Métodos iniciais é:
Rosenberg, et. al.          Standards Track                   [Página 253]


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.