RFC 3261 Português Página 200

RFC 3261 SIP: Session Initiation Protocol Junho 2002

não é delimitado por aspas. (O exemplo na Seção 3.5 da RFC 2617 está correto). Para o SIP, o 'uri' PRECISA ser delimitado por aspas.

3. O BNF para digest-uri-value é:

digest-uri-value = Request-URI ; conforme definido na Seção 25

4. O exemplo procedure para escolher um nonce baseado no Etag não funciona no SIP.

5. O texto na RFC 2617 [17] que considera operação de cache não se aplica ao SIP.

6. A RFC 2617 [17] exige que um servidor verifique se o URI na linha requisição e o URI incluído no campo-cabeçalho Authorization apontam para o mesmo recurso. Em um contexto SIP, esses dois URI's podem se referir a diferentes usuários, devido ao encaminhamento em algum proxy. Portanto, em SIP, um servidor PODE verificar se o Request-URI no valor do campo-cabeçalho Authorization corresponde a um usuário para o qual o servidor está disposto a aceitar requisições encaminhadas ou direcionadas, mas não é necessariamente uma falha se os dois campos não forem equivalente.

7. Como esclarecimento ao cálculo do valor A2 para garantia de integridade de mensagem no esquema de autenticação Digest, implementadores devem assumir, quando a entidade-corpo estiver vazia (isto é, quando mensagens SIP não têm corpo) que o hash da entidade-corpo resolva ao hash MD5 de uma string vazia, ou:

H(entity-body) = MD5("") =
"d41d8cd98f00b204e9800998ecf8427e"

8. A RFC 2617 observa que um valor cnonce NÃO PODE ser enviado em um campo-cabeçalho Authorization (e por extensão Proxy-Authorization) se nenhuma diretiva qop tenha sido enviada. Portanto, quaisquer algoritmos que tenham uma dependência de cnonce (incluindo "MD5-Sess") exigem que a diretiva qop seja enviada. Uso do parâmetro "qop" é opcional na RFC 2617 para os efeitos de retro-compatibilidade com a RFC 2069; porque a RFC 2543 foi baseada na RFC 2069, o parâmetro "qop" precisa infelizmente permanecer opcional para clientes e servidores a receber. Contudo, servidores PRECISAM sempre enviar um parâmetro "qop" nos valores de campos-cabeçalhos WWW-Authenticate e Proxy-Authenticate. Se um cliente receber um parâmetro "qop" em um campo-cabeçalho de desafio, ele PRECISA enviar o parâmetro "qop" em qualquer campo-cabeçalho resultante de autorização.

Rosenberg, et. al. Standards Track [Página 200]

Página Anterior

Tabela de Conteúdo

Página Seguinte



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.