RFC 3261 SIP: Session Initiation Protocol Junho 2002
7.3.1 Formato de Campo-Cabeçalho
Campos-cabeçalhos seguem o mesmo formato de cabeçalho genérico que foi fornecido na Seção 2.2 da RFC 2822 [3]. Cada campo-cabeçalho consiste de um nome de campo seguido por dois pontos (":") e o valor do campo.
field-name: field-value
A gramática formal para uma cabeçalho de mensagem especificada na Seção 25 permite uma quantidade arbitrária de espaço-em-branco em ambos os lados do dois-pontos; contudo, implementações devem evitar espaços entre o nome do campo e o dois-pontos e usar um espaço simples (SP) entre o dois-pontos e o valor do campo.
Subject: lunch
Subject : lunch
Subject :lunch
Subject: lunch
Portanto, os exemplos acima são todos válidos e equivalentes, mas o último é o formato preferido.
Campos-cabeçalhos podem ser estendidos por múltiplas linhas, precedendo cada linha extra com pelo menos um SP ou tabulação horizontal (horizontal tab - HT). A quebra de linha e o espaço-em-branco no início da próxima linha são tratados como um simples caractere SP. Assim, os exemplos seguintes são equivalentes:
Subject: I know you're there, pick up the phone and talk to me!
Subject: I know you're there,
pick up the phone
and talk to me!
A ordem relativa dos campos-cabeçalhos com os nomes de campos diferentes não é significativa. No entanto, é RECOMENDADO que os campos-cabeçalhos que são necessários ao processamento de proxy (por exemplo, Via, Route, Record-Route, Proxy-Require, Max-Forwards e Proxy-Authorization) apareçam no topo da mensagem para facilitar o parsing rápido. A ordem relativa de linhas de campo-cabeçalho com o mesmo nome de campo é importante. Múltiplas linhas de campo-cabeçalho com o mesmo nome de campo PODE estar presente em uma mensagem, se e somente se, o valor do campo inteiro para esse campo-cabeçalho seja definido como uma lista separada por vírgula (isto é, se segue a gramática definida na Seção 7.3). PRECISA ser possível combinar as múltiplas linhas de campo-cabeçalho em um par "nome-do-campo: valor-do-campo", sem alterar a semântica da mensagem, anexando a cada valor-de-campo subseqüente ao primeiro, separados por uma vírgula. As exceções a essa regra são campos-cabeçalhos WWW-Authenticate, Authorization, Proxy-Authenticate e Proxy-Authorization.
Rosenberg, et. al. Standards Track [Página 30]
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