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

RFC 3261            SIP: Session Initiation Protocol           Junho 2002
Informações sobre campos-cabeçalhos em relação aos métodos e processamento de proxy estão resumidas nas Tabelas 2 e 3.
A coluna "onde" descreve os tipos de requisição e resposta nos quais os campos-cabeçalhos podem ser usados. Os valores nessa coluna são:
R: O campo-cabeçalho somente pode aparecer em requisições;
r: O campo-cabeçalho somente pode aparecer em respostas;
2xx, 4xx, etc.: Um valor ou faixa numérica indica códigos de respostas com os quais o campo cabeçalho pode ser usado;
c: O campo-cabeçalho é copiado da requisição para a resposta.
Uma entrada vazia na coluna "where" indica que o campo cabeçalho pode estar presente em todas as requisições e respostas.
A coluna "proxy" descreve as operações que um Proxy pode executar sobre um campo cabeçalho:
a: Um proxy pode adicionar ou concatenar o campo-cabeçalho se não estiver presente.
m: Um Proxy pode modificar um valor de campo-cabeçalho existente.
d: Um Proxy pode deletar um valor de campo-cabeçalho.
r: Um Proxy precisa ser capaz de ler o campo-cabeçalho, e, portanto esse campo-cabeçalho não pode ser encriptado.
As próximas seis colunas relacionam a presença de um campo-cabeçalho em um método:
c: Condicional; requerimentos do campo-cabeçalho dependem do contexto da mensagem.
m: O campo-cabeçalho é obrigatório.
m*: O campo-cabeçalho DEVE ser enviado, mas os clientes/servidores necessitam estar preparados para receber mensagens sem esse campo cabeçalho.
o: O campo-cabeçalho é opcional.
t: O campo-cabeçalho DEVE ser enviado, mas os clientes/servidores necessitam estar preparados para receber mensagens sem esse campo-cabeçalho.
Se um protocolo baseado em stream (como o TCP) for usado como um meio de transporte, então o campo-cabeçalho PRECISA ser enviado.
Rosenberg, et. al.          Standards Track                   [Página 160]


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.