RFC 3261 SIP: Session Initiation Protocol Junho 2002
Embora um número arbitrário de pares de parâmetro possam ser anexados a um valor de campo-cabeçalho, é MANDATÓRIO que um dado nome de parâmetro NÃO apareça mais do que uma vez.
Ao comparar campos-cabeçalhos, nomes de campo sempre são insensíveis a maiúsculo-minúsculo. Salvo disposição em contrário na definição de um campo-cabeçalho particular, valores de campo, os nomes de parâmetros e valores de parâmetros são insensíveis a maiúsculo-minúsculo. Tokens são sempre insensíveis a maiúsculo-minúsculo. Salvo disposição em contrário, os valores expressos como strings entre aspas são sensíveis a maiúsculo-minúsculo. Por exemplo,
Contact: <sip:alice@atlanta.com>;expires=3600
é equivalente a
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
e
Content-Disposition: session;handling=optional
é equivalente a
content-disposition: Session;HANDLING=OPTIONAL
Os dois campos-cabeçalhos seguintes não são equivalentes:
Warning: 370 devnull "Choose a bigger pipe"
Warning: 370 devnull "CHOOSE A BIGGER PIPE"
7.3.2 Classificação de Campo-Cabeçalho
Alguns campos cabeçalhos fazem sentido apenas em requisições ou em respostas. Esses são chamados de campos-cabeçalhos de requisição e campos-cabeçalhos de resposta, respectivamente. Se um campo-cabeçalho aparece em uma mensagem que não confere com sua categoria (como um campo-cabeçalho de requisição em uma resposta), ele PRECISA ser ignorado. A Seção 20 define a classificação de cada campo-cabeçalho.
7.3.3 Forma Compacta
O SIP fornece um mecanismo para representar nomes comuns de campo-cabeçalho em uma forma abreviada. Isso pode ser útil quando mensagens, do contrário, tornam-se demasiada grande para ser carregadas no transporte disponível para ela (superior a unidade de transmissão máxima (MTU) quando usando o UDP, por exemplo). Essas formas compactas são definidas na Seção 20. Uma forma compacta PODE ser substituída pela forma maior de um nome de campo-cabeçalho a qualquer momento sem alterar a semântica da mensagem. Um nome de campo-cabeçalho
Rosenberg, et. al. Standards Track [Página 32]
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