RFC 2119 BCP Português

Grupo de Trabalho em Rede                                     S. Bradner
Request for Comments: 2119                            Harvard University
BCP: 14                                                       Março 1997
Categoria: Best Current Practice





Palavras-Chaves para uso em RFC's para Indicar Níveis de Exigências


Status desse Memorando

Esse documento especifica um Internet Best Current Practices (Melhores Práticas Atuais na Internet) na Comunidade Internet e requisita discussões e sugestões para melhoramentos. A distribuição desse memorando é ilimitada.


Resumo

Em muitos documentos tramitando para se tornar padrões várias palavras são usadas para indicar os requisitos na especificação. Essas palavras são freqüentemente em maiúsculo. Esse documento define essas palavras do modo como elas devem ser interpretadas em documentos do IETF. Autores que seguem essas orientações devem acrescentar essa frase ao seu documento próximo ao início:

As palavras chaves "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", e "OPTIONAL" nesse documento devem ser interpretadas como descrita na RFC 2119.

Note que a força dessas palavras-verbos é modificada pelo nível de exigência do documento no qual elas são usadas.


1. MUST
Essa palavra, ou os termos "REQUIRED" ou "SHALL", significam que a definição é uma exigência absoluta da especificação.

O verbo MUST exprime obrigatoriedade, algo mandatório, exigido, forçoso, requerido, necessário e preciso. Na tradução das RFC's do SIP para o português, aqui no blog, será traduzido como sinônimo de: PRECISAR, REQUERER, OBRIGAR, EXIGIR, FORÇAR, SER OBRIGATÓRIO, SER FORÇOSO, NECESSITAR, SER MANDATORIO.


2. MUST NOT
Essa frase, ou a frase "SHALL NOT", significam que a definição é uma proibição absoluta da especificação.
Em português equivale a: NÃO PODE, É PROIBIDO, É VEDADO.


3. SHOULD
Essa palavra, ou o adjetivo "RECOMMENDED", significam que pode haver razões válidas em circunstâncias particulares para se ignorar um item particular, mas as implicações completas precisam ser compreendidas e cuidadosamente ponderadas antes de se escolher um curso diferente.
Em português equivale a: DEVE, É RECOMENDADO.


4. SHOULD NOT
Essa frase, ou a frase "NOT RECOMMENDED" significam que pode haver razões válidas em circunstâncias particulares quando o comportamento particular é aceitável ou mesmo útil, mas as implicações completas devem ser compreendidas e o caso cuidadosamente ponderado antes de implementar qualquer comportamento descrito com esse rótulo.
Em português equivale a: NÃO DEVE, NÃO É RECOMENDADO.




Bradner                  Melhores Práticas Atuais                  [Página 1]



RFC 2119                     RFC Palavras-Chaves                    Março 1997


5. MAY
Essa palavra, ou o adjetivo "OPTIONAL", significa que um item é opcional verdadeiramente. Um fabricante pode escolher incluir o item como um mercado particular o exige ou porque o fabricante percebe que isso melhora o produto ao passo que outro fabricante pode omitir o mesmo item. Uma implementação que não inclui uma opção particular PRECISA estar preparada para interoperar com outra implementação que inclui a opção, embora, possivelmente com funcionalidades reduzidas. Nessa mesma disposição, uma implementação que inclui uma opção particular PRECISA estar preparada para interoperar com outra implementação que não inclui a opção (exceto claro, para o recurso que a opção fornece). Em português equivale a: PODE, É OPCIONAL.


6. Orientação no uso desses Imperativos

Imperativos do tipo definidos nesse memorando precisam ser usados com cuidado e parcimônia. Em particular, eles PRECISAM ser usados somente onde é realmente exigido para interoperar ou para limitar comportamento que possui potencial para causar prejuízo (por exemplo, limitar re-transmissões). Por exemplo, eles não precisam ser usados para tentar impor um método particular aos implementadores no lugar onde o método não for obrigatório para a finalidade interoperabilidade.


7. Considerações de Segurança

Esses termos são freqüentemente usados para especificar comportamento com implicações de segurança. Os efeitos sobre a segurança de não implementar um PRECISA ou um DEVE, ou fazer algo que a especificação diz NÃO PRECISA ou NÂO DEVE ser feito pode ser muito sútil. Autores de documento devem despender algum tempo para elaborar as implicações de segurança para o não seguir recomendações ou exigências porque a maioria dos implementadores não tiveram o benefício da experiência e da discussão que produziu a especificação.


8. Reconhecimentos

As definições desses termos são o amálgama de definições tomadas de inúmeras RFC's. Em adição, sugestões têm sido incorporadas a partir de inúmeras pessoas incluindo Robert Ullmann, Thomas Narten, Neal McBurnett e Robert Elz.












Bradner                  Melhores Práticas Atuais                  [Página 2]



RFC 2119                     RFC Palavras-Chaves                    Março 1997


9. Endereço do Autor

Scott Bradner
Harvard University
1350 Mass. Ave.
Cambridge, MA 02138
phone - +1 617 495 3864
email - sob@harvard.edu






































Bradner                  Melhores Práticas Atuais                  [Página 3]

Telefonia IP ainda Amarrado na Era PABX

O futuro de telefonia IP ainda amarrado na era do PABX

Zeus Kerravala

Publicado em: 02 de Maio de 2011

http://go.techtarget.com/clicktrack-r/r/13777363/5714441

De todas as discussões que tenho com decisores a respeito de Voz sobre IP (VoIP), algumas perguntas mais comuns tendem a girar em torno do futuro do IPABX – e ninguém pode ser punido por querer saber isso? O setor de telefonia teve mais inovação e transformação nos últimos 10 anos do que nos 30 anos anteriores, o que torna manter-se muito desafiador.

Eu espero plenamente que o ritmo da inovação para continuar e mesmo intensificar, tornando-se ainda mais difícil para as empresas a antecipar qual será o futuro das plataformas de voz e posicionar-se da melhor forma possível. Eu gostaria de passar algumas dicas sobre o que eu acho sobre qual será o futuro da telefonia IP e do IPABX.


A promessa do IPABX falhou

Implantar voz costumava ser fácil. Você conectava seus telefones em um PABX, e tudo funcionava magicamente. O problema com essas plataformas de PABX mais antigas era o fato deles serem muito inflexíveis, ineficientes e precivam ser fixados em cada local. Não havia uma forma de ampliar os recursos antigos no local instalado, e eles precisavam funcionar em uma rede totalmente separada.

Então surgiu o IPABX, que se imaginava a panaceia para todos os nossos problemas de telefonia. Convergindo as redes de voz e dados, o custo de fazer telefonia cairia por terra. Queríamos obter mais funcionalidade e os usuários seriam mais produtivos. Seria uma vitória da TI, dos usuários e da empresa - mas esse não era o caso para muitas organizações.

Dependendo para quem você fala, o quanto de redução de custos tende a variar. Os custos iniciais são elevados, e em muitos casos, não há todas funcionalidades de ponta. Nós fazemos chamadas, mas nós fazíamos isso antes. O que nos aprisiona então ao passado?

Eu acho que a rota principal na indústria é que nós realmente não deixamos a era PABX. Sim, todos os sistemas novos são construídos para funcionar sobre a rede IP. Temos novos telefones IP (e caros), mas conceitualmente, não mudou muita coisa. Um grande número de organizações onde eu trabalhei implantando VoIP substituiu cada PABX por um IPABX. Assim, no final do dia a arquitetura toda é a mesma, nós estamos apenas usando rede IP como o mecanismo de transporte ao invés da RCTP, mas ao nível mais básico, nós gastamos muita energia tentando fazer nossos sistemas IP parecer e agir como os sistemas TDM antigos.

A evolução do PABX

A primeira onda de evolução seguiu apartada da era PABX indo no mesmo caminho que a computação. Implantamos as novas plataformas, mas mantivemos a arquitetura semelhante. Muito disso se deveu ao ganho de conforto com os novos sistemas (fixou-se na idéia de não mexer na experiência do usuário)*, mas as plataformas IPABX em si não estavam prontas para suportar uma arquitetura diferente.

A próxima onda VoIP será semelhante ao que aconteceu no mundo da computação. Servidores de chamada se tornarão recursos baseados em datacenter que usam a WAN corporativa para fornecer serviços as filiais e aos demais funcionários. Pense em uma aplicação na organização, da mesma forma que sistemas de e-mail ou CRM - todos elas residem no datacenter e são entregues pela rede.

A evolução tecnológica também contribuiu para essa tendência. Todas as novas plataformas de voz – como o Avaya Aura, Cisco Unified Communications Manager e a Lync Microsoft – são projetados para serem implemantadas dessa forma. Elas seguem os mesmos princípios de aplicação e da Web para permitir maior escala e eficiência.

A outra coisa importante a notar sobre essas plataformas é que elas fazem mais do que apenas iniciar e encerrar chamadas. A próxima geração de IPABX deve ser pensado como um gerenciador de sessões IP, e não um servidor de chamadas. As chamadas são um dos recursos possibilitados pela sessão IP, mas a sessão traz a possibilidade de acomodar vídeo, presença e outras funções multimídia.

Como a sessão está na camada IP, torna-se altamente móveis e podem ser movidos de um telefone para um tablet para um PC com relativa facilidade. Isso trará consigo outro nível de economia de custos e começar a cumprir a visão de longo prazo do qual a mudança para o IP suposto ser: conectar qualquer ferramenta de comunicação com qualquer usuário em qualquer dispositivo. Mas para que isso aconteça, precisa haver um novo passo evolutivo, que estamos apenas começando a ver.


IPABX: Abrindo a mente às plataformas abertas

No longo prazo, eu acho que a indústria vai parar de pensar o PABX como um sistema fechado e, em vez disso, vê-lo como um conjunto de plataformas abertas que trabalhem juntas para fornecer a funcionalidade necessária.

Leia também:  Asterisk SCF - VoIP em Software Livre de Porte Enterprise e UC

Para esclarecer a minha visão, eu vou usar novamente o mundo de aplicação como exemplo. Na maioria das grandes organizações, as estratégias de aplicação são as mesmas. Uma camada de serviços subjacentes fornece todas a funções comuns, tais como serviços de autenticação e diretório. Acima dessa camada, as aplicações são construídas em algumas plataformas, como .NET ou Java. O middleware é então usado para amarrá-lo todas juntas. Embora essa seja uma simplificação grosseira de como as aplicações funcionam, e há todo tipo de exceções, essa é a rota principal que muitas empresas tomarão.

De forma similar em comunicações, o que nós vamos ter é uma camada de serviços comuns para coisas como presença e identifição de usuário, alguns dos quais serão compartilhados com outras aplicações. Um conjunto de plataformas vão residir nessa camada – talvez uma para voz, uma para vídeo, outra para mídias sociais – em um nível mais alto, e a camada de abstração para funcionalidade do middleware. De fato, o ACE da Avaya, VOSS e OpenTouch da Alcatel-Lucent são bons exemplos de alguns dos primeiros middleware de comunicação.

Embora estejamos muito longe disso, essa é a direção que a indústria está caminhando. Nós estamos saindo da era PABX? Dificilmente, mas estamos seguindo rapidamente esse caminho.

* grifo meu

Sobre o autor: Zeus Kerravala, Yankee Group senior vice president and distinguished research fellow, leads the firm's Research Council and is chartered with the responsibility of providing thought leadership to the research organization. Comprising senior research leaders, the Research Council provides outreach to clients and the broader Yankee Group community, as well as ensures that the company's research agenda addresses the needs of business leaders. Kerravala drives the strategic thinking of the research organization and helps shape the research direction. Much of Kerravala's expertise involves working with customers to solve their business issues through the deployment of infrastructure technology.