RFC 3261 SIP: Session Initiation Protocol Junho 2002
host destino não tem noção de usuários ou quando o host em si é o recurso sendo identificado. Se o sinal @ estiver presente em URI do SIP ou do SIPS, o campo usuário NÃO PODE estar vazio.
Se o host sendo endereçado pode processar números de telefone, por exemplo, um gateway de telefonia via Internet, um campo de assinante telefônico, definido na RFC 2806 [9] PODEM ser usados para preencher o campo usuário. Existem regras especiais de escape para codificar campos de assinante telefônico em URI's do SIP e do SIPS descrito na Seção 19.1.2.
password: Senha associada ao usuário. Enquanto a sintaxe URI do SIP e do SIPS permite esse campo estar presente, seu uso NÃO É RECOMENDADO, porque a passagem de informações de autenticação em texto claro (como URI's) tem provado ser um risco de segurança na quase todos os casos onde foi usado. Por exemplo, transportar um número PIN nesse campo expõe o PIN.
Note que o campo senha é apenas uma extensão da parte usuário. Implementações não querendo dar uma significação especial à parte senha do campo PODE simplesmente tratar "user:password" como uma única string.
host: O host que fornece o recurso SIP. A parte host contém tanto um nome de domínio totalmente qualificado como endereço numérico IPv4 ou IPv6. Usar a forma nome de domínio completamente qualificado É RECOMENDADO sempre que possível.
port: O número de porta aonde a requisição deve ser enviada.
URI-parameters: Parâmetros que afetam uma requisição construída a partir da URI.
Parâmetros URI são adicionados após o componente hostport e são separados por ponto e vírgulas.
Parâmetros URI tomam a forma:
parameter-name "=" parameter-value
Ainda que um número arbitrário de parâmetros URI possam ser incluídos em URI, qualquer nome de parâmetro dado NÃO PODE aparecer mais de uma vez.
Esse mecanismo extensível inclui os parâmetros transporte, maddr, ttl, user, method e lr.
Rosenberg, et. al. Standards Track [Página 149]
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