RFC 3261 SIP: Session Initiation Protocol Junho 2002
20.12 Content-Encoding
O campo-cabeçalho Content-Encoding é usado como um modificador para o "media-type". Quando presente, seu valor indica qual códigos de conteúdo adicional foram aplicados ao corpo entidade, e, portanto, quais mecanismos de decodificação PRECISAM ser aplicados, a fim de obter o media-type referenciado pelo campo-cabeçalho Content-Type. Content-Encoding é usado principalmente para permitir que um corpo seja compactado sem perder a identidade de seu tipo de mídia subjacente.
Se múltiplas codificações foram aplicadas a uma entidade-corpo, as codificações de conteúdo PRECISAM ser listadas na ordem na qual foram aplicadas.
Todos os valores content-coding não são case-sensitive. O IANA atua como um registro para tokens valores content-coding. Veja [H3.5] para definição da sintaxe para content-coding.
Clientes PODEM aplicar codificações de conteúdo ao corpo nas requisições. Um servidor PODE aplicar codificações de conteúdo aos corpos nas respostas. O servidor PRECISA usar apenas codificações listados no campo-cabeçalho Accept-Encoding na requisição.
A forma de compacta do campo-cabeçalho Content-Encoding é e.
Exemplos:
Content-Encoding: gzip
e: tar
20.13 Content-Language
Ver [H14.12]. Exemplo:
Content-Language: fr
20.14 Content-Length
O campo-cabeçalho Content-Length indica o tamanho do corpo da mensagem, em número decimal de octetos, enviado ao destino. Aplicações DEVEM usar esse campo para indicar o tamanho do corpo da mensagem a ser transferida, independente do tipo de mídia da entidade. Se um protocolo baseado em stream (como o TCP) for usado como transporte, o campo-cabeçalho PRECISA ser usado.
O tamanho do corpo da mensagem-não inclui o CRLF que separa campos-cabeçalhos e corpo. Qualquer Content-Length maior ou igual a zero é um valor válido. Se nenhum corpo estiver presente na mensagem, então o valor do campo-cabeçalho Content-Length PRECISA ser definido como zero.
Rosenberg, et. al. Standards Track [Página 169]
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