ANÁLISE E ESPECIFICACAO DO
AGENTE USUÁRIO (UA) NO SISTEHA
DE HAN I F'ULACÃO DE HENSAGEIS ( HHS )
,
Suzan
Ka\- ina
A1 mada Mendes
Luci
F'il-mez
NCE-18/9.
Julho/9
UniVer.':;ldad,::, !::-r:::dl;'r.al do !:::io dr=.' Jcll-IEi1-C.1
N ,-í. c I e O d e C (.3 ITII:I ,-'. t a I; \ C. E I t;' f.: 1- 6 n i c ,,\
Ca i xa F'ost cl 1 232.4
20001 -R1.o de Jani1-O -RJ
BRASIL
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO NiJCLEO DE COMPUTACAO ELETRONICA
ANÁLISE E ESPECIFICAÇO DO AGENTE USUÁRIO (UA)
NO SISTEMA DE MANIPULAÇO DE MENSAGENS(MHS)
.. ..
RESUMO
f'
Este relatório descreve uma proposta para a especificaão da Entidade de gente UsuárlO (UAE), módulo lntegrante do modelo funcional de um Sistema de Manpulaão de. Mensagens (MHS) .baseado na serie X.400. O desenvolvlmento de um MHS e parte do proJeto REDE-RIO. Este proJeto permltiri a interconxão das Uni-versidades do Rio de Janelro através da RENPAC.
AN IMPLENTATION PROPOSAL OF USER AGENT ENTITY <UAE) IN THE
MESSAGE HANDLING SYSTEMS CONTEXT
ABSTRACT
This report descrlbes a proposa1 t'or the specification ot' the User Agert Entit (UAE), a modu1e which integrates the functiona1 model of a
Messa-nd1ing Sstem. (MHS) based on X.400 serles. The deye1opment of a MHS is part of the REDE-RIO proJect .ThlS prOJect wi11 a11ow the interçonnection of Unl\'rsltles of R1O de Janeiro through RENPAC.
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
I. :NTRODUC:O
O prOpósltO de um Sistema de Mensagem (MHS) é proporcionar recursos e supcrte para que seus usuárlos possam trocar mensagens entre Sl através de um melC rápido e eficlente. A sérle X400 define um MHS de acordo com os princípios do odelo OSI e. dessa forma. este sistema pode ser construído sobre qua1quer rede físlca.
. .
Nesse relatório. será apresentada apenas a especifica,ão da MTAE, mó-dulc lntegrante do modelo funcional proposto para o MHS no relatório NCE.
f"
A especiflca,ão de um Sistema de Manipu1a,ão de Mensagem e sua lmp1e-menta,ão -fazem parte de um proj.eto denomlnado REDE..:RIO. Este projeto tem como obJetivo prlnclpal, possibilitar a lnterconexão dos computadores de grande por-te :as UnlVersldades do Rio de Janeiro
A implementa,ão dos servi,os a serem oferecldos pela REDE-RIO seguem a ten:êncla internaclonal de basear os desenvolvlmentos de softwarelhardware se-lUnco o modelo OS111S0 As sete camadas especlficadas por este modelo são: fí-SlCC, en1ace, rede, transporte, sessão, apresenta,ão e apllCa,ão.
As três camadas inferlores Já estão definidas pelo CCITT e constitui o protocolo X.25. 0 padrão X.25 é oferecldo pela RENPAC (Rede Nacional de Paco-tes: e será utllizado como melo de lnterconexão entre os várlOS centros parti-Clpantes da REDE-RIO. 0 hardware e software necessários para permltir ainter-coneão serão adqulridos diretamente dos fabrlcantes.
O projeto REDE-RIO tem como tarefas o estudo, a especifica,ão e a im-p1eenta,ão das segulntes camadas:
i I. -a camada de transporte;
-a camada de sessão;
.---a camada de aplica,ão;
-o servi,o de Terminal Virtual; -o servl'o de Correio EletrônlCO;
-O servi,o de Manipula,ão e Transferência de Job;
-o servl'o de ManlPula,ão, Acesso e Transferencia de Arquivo.
Na Unlversidade Federa1 do Rio de Janeiro. o computador que se inter-11gará a RENPAC é o VAX 8810.
i
j c c.(
,c
["Yrr-8 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
... o objetivo desse relatório é apresentar a implementa,ào da interface Homem-Máqulna desenvolvida para o MHS dentro do proJeto REDE-RIO, e está orga-nIzado da seguinte forma:
(1) A UAE no MHS; (2) O Protocolo P2; (3) A Opera,ão da UAE; (4) Tabela de Estados; (5) CONCLUSõES. I I. A UAE NO MHS -; .. 11.1. O MODELO FUNCIONAL DO MHS
O procedlmento básico do funclOnamento do MHS (X400) consiste de um CIcIo de Interroga,ões. Este ciclo analisa a comunica,ão com a camada de ses-são, analisa a comunica,ão com o usuárIo, e atlva quando necessário os proce-dlemntos de transferência de mensagem para a camada de sessão ou para o usuá-rlO Cada análise realIzada se refere a uma possível recep,ão de uma mensagem proveniente da camada de sessão ou do usuário.
O Sistema de Manipula,ão de Mensagem pode ser dividido em 3 módulos, que são.
A -O módulo UAE que contém un,ões ativádas pelo usuário que corres-pondem aos Elementos .de Servi,os necessárlos para lnteraglr com o Sistema de TranserêncIa de Mensagem;
B- O módulo MTAE que ornece os meios pelos quais os agentes usuários (UAs) podem trocar mensagens através das redes de comunica,ão de dados.;
C -O módulo RTS que é a parte da entidade de aplica,ão (AE) responsá-vel pela crIa,ão e manuten,ão de aSSOC1Q'ÕeS entre oS pares de AE-.
" USUóRIO + + I + + I I l---l I I + + I I l--!--l I I + + I I l--!---! I + + SESSO MODELO FUNCIONAL DO X.400 ;'tcc cJ i. ; -; '\ .
11.2 O MóDULO UAE
A prlnclPal função do Agente Usuário (UA) é tornar os servlços de Ma-nipulação d Mnsagens disponívels ao usuário, usando o servlço de Transferên-cla de Mensagens (MT) provldo pelo Sistema de Transferêncla de Mensagens. (MTS), o qual é formado por uma coleção de Agentes de Transferêncla de Mensagem (MTA), descrlto em (5)
O UA é um conjunto de processos de apllcação contendo, no mínimo, as
funções necessárias às lntraçõs de submlSsão ntrego d mensagens JUnto ao
MTS Tals prOCedlmentos são definldos na recomendação X411.
UAs são agrupados em classes baseando-se no tlPO de conteúdo de mensa-ens que podem manlPular UAs de uma mesma classe são chamados "UAs cooperan-tes", Já que devm cooperar a flm de fornecer servlçOS e comunlcação a seus
rSpectlvos usuárlOS Par que rl coopra,ão se estabeleça os UAs utilizam
protocolos padronizados. Pc é potenclalmente um conJunto de protocolos que de-flnem a slntaxe e a semântica do conteúdo da menagem sendo transferlda. Cada lnstâncla CO protocolo Pc esta associada com uma classe de UAs cooperantes.
Um usuarlo acessa seu UA a fim de obter servl'OS de processamento de
mensaJem. Para tal, o usuárlo interage com seu UA vla disPOSltivo de
entrada/saída (por e}(emp1o, t.eclado, lmpressora, fac-slmile) ou um processo. Um UÀ pode ser lmplementado como um conJunto de processos do .sistema operacional ou como um termlnl inteligente.
Quanto a locaI1Za,ão físlca, UA e MTA podem ser lmplementados em um mesmo sIstema (UA e MTA co-resldentes) OU em sistmas dlstintos No caso de UA e MTA co-resldentes. O UA acessa o servl'o MT interagldo diretamente com O MTA no mesma slstema Caso contrárlO, O UA deve se COmunlCar com O MTA em outro sistema utlllZando a entidde-funclOnal SOE <Entldade de SubmlSsão e Entrega), deflnida pelas Recomendações X400, com flnalldade únlca de lnteragJ.r com a En-tldade MTA de form a prover O acesso do UA ao MTA. A SOE, por sua vez, se co-munlcará com O MTA através do Protocolo de submlSsão e Entrega (P3), padroniza-do e dscrlto na Recomenda,ão X411. + + Pc + + -I UA 1( )1 UA , I I I I I SOE 1( )1 MTA 1 + + P3 + +
UA "stand alone" UA-MTA CO-Resldents
; I
",\j
,:-i , UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
II.3- O SISTEMA DE MENSAGEM INTERPESSOAL .
O Sistema de Mensagem Interpessoal (IPMS) fornece servl'os para
comu-nlca,ão entre usuárlos. Os UAs desta classe são chamados IPM-UAs
Os elementos de servl'o estão definldos em C5J. O IPMS compreende o
Slstema de Transferêncla de Mensagens (MTS), uma c1asse especifica de UAs
coa-, perantes e acesso a Telex e servl'os te1emáticas definldos pelo CCITT. Os
usuá-.c rlos do IPMS geralmente sao pessoas e constituem uma comunl d a d e No t e que
ou-tras classes de UAs podem ser definidas; entretanto estes UAs formariam uma
co-munldade dlstlnta e não Paderlam comunicar-se eflClentemente com OS IPM-UAs.
Para prover o servi,o IPM, UAs usam e1ementos de servi,o fornecldos
peo MTS. Portanto, um IPM-UA deverla:
1 Fornecer fun,ães necessárias ao preparo de mensagens;
2 Executar a lntera,ão de SubmlSsão com O MTS;
3. Executar a lntera,ão de entrega com O MTS;
4 Executar fun,ães necessárias ao receblmento de mensagens;
5 Fornecer fun,ães de coopera,ão com outro(s) UA(s) a flm de auxlliar seu
cf suário a 11dr com-as mensagens;
--CC 6 Executar fun,oes adlC1OnalS de prepara,ao e manlpu1a,ao de mensagns.
Opclonalmente, O IPM-UA pode fornecer fun,ães loca.is, não
padroniza-das, ror exemplo, para processamento de texto, armazenam.ento e recuperaão de
mensagens.
A segulr, é descrlta uma proposta de especifica,ão de IJm IPM-UA a ser
reallZada em um amblente VAX/VMS, uti11Zando-se a llnguagem C Esta proposta
será a base da lmp1ementa,ão do Agen:te Usuário do MHS no proJeto REDE-RIO,
"
..
I
i I
: UNIVERSIDADE FEDERAL DO RIO DE JAN,EIRO
;,-; \' .;;", NUCLEO DE COMPUTACAO ELETRONICA
III. PROTOCOLO P2
O servlç:o IPM "(IPM5) capacita seus usuárlos a se comunicarem por
transmlssão e recepç:ão de Mensagens Interpessoals (Mensagens-IP) Os serviç:os
disronivels ao orlglnador (ou destlnatárlo) para utillzaç:ão do Nível de Agente
Usuárlo para Mensagens Interpessoals (IPM UAL) são os servlç:os oferecidos pelo
Nível de Transferêncla de Mensagem (MTL) juntamente com os servios
proporcio-; nados pela cooperaç:ão de entidades UA (UAEs) .
UAEs cooperam entre si por melO do protocolo de Mensagens
Interpes-f'
soais (P2). Este protocolo conslste essenclalmente de:
1. Definiç:ão de um conJunto de slntaxes semânticas padronizadas que pode
ser usado para construir Unidades de Dados do Protoco1o de Agente
Usuá-rio (UAPDUs);
2. Operaç:ões que o IPM UA dve rea1izar para a troca destes e1ementos de
protocolo;
3. As regras que um IPM UA deve seguir no uso do servio MTL para propor-clonar o serviç:o IPM.
III.1- E5PECIFICACO DE UAPDUs
A segulr são °descrltas ao sJ.ntaxe e a semântlca das unldades de dados utlllZadas no protocolo P2, as Unldades de Dados de Protocolo do Agente Usuárlo
(UAPDU) A dpscrlç:ão segue a notaão utllizada nas recomendações X400.
São deflnidos dOlS tipos de:UAPDUs, UAPDU de mensagem-IP (IMUAPDU) e
UAPDU de relatório e status (5R-UAPDU) .
" Sintaxe de uma UAPDU UAPDU : := choice (
(0J IMPLICIT IM-UAPDU,
(1J IMPLICIT SR-UAPDU )
i
..
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
111.1.1- TIPOS DE DADOS COMUNS
111.1.1.2- 1P-Message-Id (1dentificador de Mensagem 1P)
Um ldentificador de mensagem-IP ldentiflCa uma mensagem-1P partlcular e é usado no ofereclmento do elemento de servl'O Identifica,ão de Mensagem-IP. Este ldentiflcador deve ser únlco, inamblguo e especiflcado de acordo com o re-comendação na defini'ão do elemento de servl'O.
Uma IP-Message-ID contém uma cadela lmprlmível e deve lncluir um O/R nam, cuJa presença denota o usuário (ou UA) que gerou o ldentificador.
A cadela lmprimível prlntável é desIgnada pelo usuárlo ('ou UA) que o ger:ou e deve ser únlco no contexto do usuário.
Portanto, quando o ldentificador contém o O/R name do usuário, ele se torna globalmente único.
Sintaxe da Componente 1P-Message-Id:
.t IPMessage1d : := CAPpL1CATIONllJ IMPLIC1T SET (
ORName Optional, Printablestring) ORName .:= P1.ORName
111.1.1.3- TIME
O componente Time ldentific-a uma data-hora a ser transportada pelo
-.
", protocolo Deve sempre lnclulr a data-hora nas coordenadas VTC (Unlversal Coor-denated Time), e pode opcionalmente conter a hora local da UAE A preclsão da dat-hora é de um segundo ou de um minuto, conformeseleclOnado pela UAE.
Sintaxe do Time: Time: := UTCTime
,
["''3 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
111.1.2- IM-UAPDU
Uma IM-UAPDU tem duas partes: O cabeçalho e o corpo da mensagem-IP:
sintaKe da IM
IM-UAPDU : := sEQUENCE (
Heading, Bod )
Uma IM-UAPDU carrega uma mensag-em-IP gerada e t-ransf'erida entre origi-nadores e destlnatárlos (veJa Nota) .O cabeçalho.de uma mensagem-IP é a lnfor-ma,ão de controle que a caracterlza. O corro de uma mensagem-IP é a informa,ão que o usuárlo deseJa transferlr.
Nota: Em geral, eKlste uma correspondência unívoca entre mpnsagens-IP e IM-UAP-DUs. Entretanto, deve-se notar que em alguns casos, mais de uma IM-UAPDU pode 5r assoclada com uma mesma mensagem-IP, isto é, contndo a mesma ldentificação de mensagem (por eKemplo, quando há IndlCa,ão de DestlnatárlO CÓPla Cga .-veja se,ão IV 2.2.1> .
111.1.2.1- CABEÇALHO
Cada componente do cabe,alho de uma IM-UAPDU é usado para proporcionar um 1?1empnto rle servJ'O de IPM.
sintaKe do campo cabeçalho de uma IM: Heading : := sET (
IPMessageld,
originator (0] IMPLICIT ORDescriptor OPTIONAL,
authorizingUsers (1] IMPLICIT sEQUENCE OF ORDescriptor OPTIONAL,
---somente se não for o orlginador
primarRecipients (2] IMPLICIT sEQUENCE OF Recipient OPTIONAL,
copRecipients (3] IMPLICIT sEQUENCE OF Recipient OPTIONAL,
blindCopReclPients (4J IMPLICIT sEQUENCE OF Recipient OPTIONAL,
inReplTo (5] IMPLICIT IPMessageld OPTIONAL,
obsoletes (6] IMPLICIT SEQUENCE OF IPMessageld OPTIONAL,
crossReference (7] IMPLICIT sEQUENCE OF IPMessageld OPTIONAL,
subject (8] CHOICE (T61string) OPTIONAL,
h. eKPirDate (9J IMPLICIT Time OPTIONAL,
I J t;:!:1
: UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
replb [10J IMPLICIT .Time OPTIONAL,
replToUsers [11J IMPLICIT SEQUENCE OF ORDescriptor OPTIONAL,
---cada O/R DescrlPtar deve canter um O/R Name
importance [12J IMPLICIT INTEGER (
low(0), normal(1),
hi9h(2) ) DEFAULT narmal,
sensitivit [13J IMPLICIT INTEGER (
personal(1), private(2),
campanCanfidential(3) )OPTIONAL,
autoforwarded [14J IMPLICIT BOOLEAN DEFAULT FALSE
---indica que parte(s) do corpo da mensagem foram au-ta-remetidas )
Tabe1a 2.1 mostra, para cada componente do cabeça1ha, o e1emento de servl'a IPM na qua1 é usado.
+ + +
I I-UAPDU I Elementa(s) de Servi,o IPM
I I Componentes do Cabeçlho I.
+ + -+
! IPM5saeld I Identificaçãa de mensagem-IP I
+ + +
IOrJ91nator , Ind1ca,ão da orlginadar I
+ + +
f aut hor lzlngUses I In d i C aç ão d e USUarlas Aut arl z.dores I
+ + +
, prlmrReclPlent5 .I Ind,caço de RpclPlent Prlmários Cópia I
I capReclPlents. .I IndlaÇaO de Pedlda de Respasta I
I I Nntifltaçio de Rcebida I
I I Natificaçao de Na Recebido I
+ + +
I bl1ndCopReclPlents I IndlCa,io rle destlnatárlo Cópia Ce9a I
I I IndlCaçaa de Pedlda de Resposta I
, I NatlflCaça de Rgceblda I
I I Notlficaçaa d Naa Recpbida I
+ + +
1 inReplTo I .IndlC'ão de Resposta a Mensagem-IP I
+ + +
IobsaIt I IndlCa,ãa de Obsolescência I
+ + +
I crossRef'prence , IndlCação de Referência Cruzada --I
+ + +
..I SllbJct I Indicaçãa de Assunto ,
+ + +
I exPlrDate I IndlCação de Dnta-Hora de Expiraãa ,
+ + +
I rep1b I Indicãa de Pedida de Resposta
I
.1 rE'pIToUsers I
+-- + +
I lmpartance I IndlCação de Importância I
+ + +
I sensltlvlt , Indlcaão de Sensltlvidade I
+ + +
I autaforwrded I IndlCa,ão de Auto-remetida .,
+ + + TABELA 2.1 j f 1 j;j
rw UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Originator
Identifica o usuárlo que submete a mensagem-IP.
AuthorizingUsers
Identifica os usuárlos que autorlZaram O envlo da mpnCl!Jm-IP UM descritor O/R, que é ut11lZado para representar estes componentes, pode lnclulr um nome O/R, um nome em forma J1Vre <free-form-name), e um número de te1efone.
O O/R name é o dado necessárlO para ldentiflCar O usuárlo dentro do IPMS. EKistem circunstâncias envolvendo a reaJizaão de certos lementos de servlo, onde o O/R name pode ser omltldo AdlC10na1mente ou aJternatlvamente, um nom em forma livre <fre-nrm-name), pode ser lncluido de modo a ldentIficar mlga-velmente o usuárlo. O O/R descrlptor pode também lnclulr oPclonalmente um númp-ro de telefone.
SintaKe do O/R DescrlPtor
ORDescriptor= SETC --) pe10 menos um dos dois prlmeiros membros devem
estar presentes ORName OPTIONAL,
freeformName C0J IMPLICIT T61String OPTIONAL,
te1ephoneNumber C1J IMPLICIT PrintableStrlng OPTIONAL
Primal-Recipients, CopRecipients e B1indCopRecipients
São os usuarlos es!'eclflCados peJo orglnador rpceberem a mensagem-IP df? acordo com sua rgrs partlculares Cada um destes destlnatárlos é especiflCd-d através do componnte Recipient
O componente'Recip.lent tranp.or uma ldentiflcação de um destinatárlo <O/R DesrrlPtor) Além dlSO, lnclue S011CJtaçães para cada destinatárlO em
particu-lar reportRequest replRequest O reportRequest pode Indicar pedidos para
Not]flCaçO rJe Receblmc.'.nto. 1"5o-Recpblmento, e para retorno da mensagem-IP em caso de no recpt1Imento (returnedIPmessage) Quando receiptNotification for se-lecJonada, a nonReceiptNotifi-cation deve sf?r tambP.m se1eclOnada. O componente replRequest corresponde a um pedido de que o destinatárlO rpspon-da a mnsa-gem-IP recebtd Se ualquer detas soJltações é seleclonada, O O/R DescrlPtor que identifica o destinatrio dv conter o seu O/R name para que a solicitaão posa ser rpcOnheclda efetuada com sucesso
SintaKe do Campo Recipient Recipient= SET <
C0J IMPLICIT ORDescriptor,
reportRequest C1J IMPLICIT BIT STRING ( receiptNotification(0),
4',
t:lt'", ",!
, '.r"c UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
I
t
;-1nonReceiptNotification(1),
returnIPMessage(2) ) DEFAULT (), returnIPMessage(2) ) DEFAULT (),
---se pedido, o O/R descrlPtor deve conter um O/R name replRequest [2] IMPLICIT BOOLEAN DEFAULT FALSE
---se true, o O/R descrlPtor deve conter um O/R name)
inReplTo
Identifica a mensagem-IP já recebida da qual esta mensagem-IP é uma res-posta
. obsoletes e crossReference
Identificam as mensagens-IP que estão sendo substituídas por sta mensa-gen:'-IP por estarem obsoletas ou que estão sendo assocladas com esta mensagem-IP, respectivamente.
subject
rransporta o assunto da mensagem-IP como especificado pelo originador.
" e)(pirDate
t Indlca a data-hora a partlr da qual o originador considera a mensagem-IP inválida.
replbTime
Tndlca a data-hQra a partir da qual o origlnador gostaria de.ter uma rps-posta envlada.
replToUsers
Indica os usuários para os quals o orlglnador deseja que seja env.iada um" resposta desta mensagem-IP sendo transmitida.
O O/R descrlPtor de cada destlnatário rotenclal da resposta deve conter o componente O/R name para que a resposta seja enviada com sucesso elo IPMS.
Importance
é uma lndicação do nível de importância da mensagem-IP como especificado pplo OrJ9lnador A lmportinclo pode ser baixa, normal ou alta.
Sensitivit
Transporta a classificação, especificada pelo originador, de sensitividade da mensagem-IP. Pode ser pessoal, privada ou confidencial da companhia
, I i.\!;,.J
! f3 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
";o: !-. II NÚCLEO DE COMPUTAÇÃO ELETRONICA
III.1.2.2 -CORPO
Consiste de uma ou malS partes lndependentes. Cada parte carrega con-SlgO um lndlCação do seu tlPo Onde for necssárla d representação de um tipo partlcular de uma parte do corpo. é espcltlcado lncluir. ao longo da informa-ção da parte do corpo, um conJunt.o de parmetros que estão assoclados com a in-te)-,-etão ou que são requerldos para a lnterpretaão da parte do corpo.
As .árld partes do corpo de uma mensagem-IP particular podem ser de dl.erentp tlPOS
e
sinta><e do Corpo:
Bod .= sEQUENCE OF BodPart
BodPart = CHOICE ( [0] IMPLICIT IA5Te><t, [1] IMPLICIT TLX. [2] IMPLICIT Voice, [3J IMPLICIT G3Fa><. [4] IMPLICIT TIFO. [5] IMPLICIT TIX. [6] IMPLICIT VideoTe><. [7] NationallDeflned. C8] IMPLICIT EncrlPted. [9] IMPLICIT orwardedIPMessage. [10] IMPLICIT sFD. [11] IMPLICIT TIF1 )
Descrlão das Partes do Corpo "
,.
IASTe><t -Contpm um strlng de caracteres com a indicaão de qual conjunto (]'A2 ou IA5) I?sl;á sendo usado Em qua1quer caso, os caracteres são represnta-do" l.lSõ'.'do-5e ClS ombln-aõE'S de bltS IA5 apropriadas.
sinta><e do IA5Te><t : IASTe><t= sEQUENCE (
sET (
repertolre [0J IMPLICIT INTEGER ( ia5(5).
f ita2(2) ) DEFAULT ia5
i
, "c, .;;í,""',
, "; UNIVERSIDADE FEDERAL DD RIO DE JANEIRO
---membros adicionais deste conjunto são para uma possí-vel extensão futura')
IA5string )
Encrpted -Representa outra parte do corro que estpja encrlPtada, O texto ci-frado é representado por uma cadeia de bits. Outras lnformações taIs como um ldentlflcador para o algoritmo de encriptação são para estudos posteriores.
Encrpted .:= sEQUENCE (
SEr, ---membros para estudo posterior BIr sTRING )
Forwarded IPMessage -Rep resen t a. uma men sagem-I P que. est á c on t ida em o.ut ra men-sagem-IP com o prOpósltO de transportá-la a um conjunto adlclonal de destinatá-rlO5 Inclue, oPclonalmente, a informação de entrpga suprlda quando a mensa-gE'm-IP fOI or]g]nalmente pntregue
Sintaxe da parte do corpo remetida: ForwardedIPMessage ..= sEQUENCE (
SEr (
de1iver C0] IMPLICIT Time OPTIONAL,
Cl] IMPLICIT De1iverInformation OPTIONAL), IM-UAPDU )
DellverInformation : ;= P3,DeliverEnvelope
---slmp]esmente reutiliza a definição do tipo de dado e não implica que a in-formação tnha sido utlllZado no protocolo P3.
IIII. 1.3 -sR-UAPDU.
A sR-UAPDU é usada para retornar notificaçõe de recebido e nã6-rece-bldo de uma mensagem-IP para o seu originador.
sR-UAPDU : := SEr (
C0] CHOICE (
nonReceipt [0] IMPLICIT NonReceiptlnformation,
-receipt [0] IMPLICIT Receiptlnformtion ),
reported IPMessageld,
actua1Recipient Cl] IMPLICIr ORDescriptor OPTIONAL,
!
,,"
, "
: UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
intendedRecipient [2J IMPLICIT ORDescriptor OPTIONAL, ---presente somente se for diferente do destinatário
---real. O O/R descriptor deve conter o O/R name
converted P1.EncodedlnformationTpes OPTIONAL )
Descrião dos Componentes da SR-UAPDU:
NonReceiptInformation
É lncluído se, e somente se, uma notificaão de não-recebido está sendo transmltida. Seus componentes lncluem:
Receiptlnfo- Indica a data-hoa na qual a IM-UAPDU foi realmente recebida.
TpeofReceipt Indicará:
-explicit No caso em que o destlnatário voluntariamente e explicitamente au-torlzado envla a notificaão de recebido;
-automatic No caso em que a UAE automaticamente gerou a notifica,ão quando a mensagem-IP fOl recebida.
-SupplementarInformation: O uso desta informação na SR-UAPDU é reservado para a comunicaão de respostas de termlnalS telex e
te-1emáticos.
reason- que lndica uaeInitiatedDiscard (quando a UAE está descartando a mensa-gem-IP por razões 1ocals) ou autoforwarded (quando a UAE está auto-rpmetendo a mensagem-IP a outro UAE) ..
nonReceiptOualifier -nos casos em que a UAE descarta uma mensagem-IP, este cmponente transporta uma indicação de:
.--expired: se a mensagem foi descartada pe1a chegada da data-hora de expiraão da mensagem.
-obsoleted: se a mensagem-IP foi substituída por outra,
-subscriptionTerminated: O destinatário já não se encontra registrado como as-sinante do servio. ., t, c 'A:' , " ,
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
colr..ents
No caso de mensagem auto-remetida, este componente opcionalmente transporta uma strIng de caracteres, supridos pela UAE que auto-remeteu a mensagem-IP.
returned
Se o orlgnador pedlU o retorno da mensagem-IP em caso de não-recebimento, est::. componente transporta Integralmente a IM-UAPDU que fOl entregue.
Sintaxe:
Noneceiptlnformation : := SET (
reason C0J IM.PLICIT INTEGER (
uaelnitiatedDiscard(0),
autoForwarded(l) ), nonReceiptQualifier C1J IMPLICIT INTEGER (
expired(0), obsoleted(1),
subscriptionTerminated(2) ) OPTIONAL,
comments C2J IMPLICIT PrintableString OPTIONAL,
returned C3J IMPLICIT IM-UAPDU OPTIONAL )
RecelPtInformation
::: incluído se, e somente se, uma notlflCa,ão de recebIdo está sendo trans-por::1da Seus componentes lncluem.
Sintaxe:
ReClPtlnformation : .= SEr (
receipt C0J IMPLICIT Time,
tpeOfRecelPt C1J IMPLICIT INTEGER (
I. e)(plicit(0),
automatic(1) ) DEFAULT e)(plici-,
C2J IMPLICIT P1.SupplementarInformation OPTIONAL ), .
Repcrted
:dentlflCa a mensagem-IP CUJO destino está sendo reportado por esta SR-UAP-DU
actloalRecipient
Identlfica a UE para a qual a IM-UAPDU foi realmente entregue e que está erdo esta SR-UAPDU.
I
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
, NUCLEO DE COMPUTAÇÃO ELETRONICA
Se IM-UAPDU foi entregue ao destinatário originalmente especificado, então este cOmpO"At.transporta exatamente o O/R descriptor do componente que iden-tificou o destinatár1o real na IM-UAPDU entregue.
Se a IM-UAPDU fO1 entregue a um destinatár1o alternat1vo, então este compo-nente é um O/R descriptor que identifica o destinatário real. De qalquer forma, este componente deve 1nclu1r o O/R name do dest1natárlO real.
IntendedRecipient
É retornado somente se a IM-UPDU fO1 realmente entregue a um destinatário alternatlvo.
Ete componente é, então o O/R descr'iptor que iden1ifica o destinatário
Or191nalmente especiflCado para a entrega de. mensagem-IP, exatamente como
tranmitldo no componente destinatário correspondente da IM-UAPDU sendo repor-tada.
ConvertedEncodedlnformationTpes
Transporta o novo tipo de informa,ão codificada, caso tenha Qcorrido con-versão na IM-UAPDU.
IV. OPERACO DAS IPM-UAEs
Cara ,'rororcionar o servio IPM, !PM UAEs devem realizar orera,ões que suportam elementos de servi,os específicos.
A opera,ão de um !PM UAE é descrita em termos de:
1 Suas lntera,ões com o seu usuário (originador ou destlnatário) de servi,o I PM;
2 Sua intera,ão com o servi,o MTL, que é usado para comunicaão entr UAEs cooperantes
IV.l -SERVICO BÁSICO IPM
O ser".,o báslCO de !PM habilita um usuário originador a enviar um mensagem-IP e a tê-la recebido pelo destinatário especificado. Como parte dest srvlço básico, são transmitidos uma identifica,ão da mensagem-IP, e seu corpo com a ldentifica,ão do tlPO do corpo; o servlçO MT é acessado e cada elemento de servi,o básico do serviço de MT está disponível para transferir a mensagem-'
i
1
L', N".
IP
IV.1.1 -ACESSO AO sERVICO DE MT
IPM UAEs ut11izam O servlO de MT como um melO de transferirem mensa-gl?ns-IP O elf'mento de servlO Gerenclamento de Acesso, que é parte do servlçO áslco de MT, é utllizado por UAEs com o propósito de acessar este servio.
Prlmltlvas de servlo do MTL assocladas com O Gerenclamento de Acesso:
-(UAL)LOGON Request -(UAL)LOGON.Confirmation -(MTL)LOGON.Indication -(MTL)LOGOJResponse -LOGOFF Request -LOGOFFConflrmation -REGISTER Request (UAL)CHANGE-PAsSWORD.Request
( UAI- ) Cf-ANGE -PASsWORD .Con f' i rma t i on -(MTL)CHANGE-PASSWORD.lndlcation
A maneira especif'lca na qual estas primitlvas de servlO são (ou não) usadas entre a UAE e.o MTL depende dos procedimentos requeridos pelo DomínlO de erenclamento que rroPOrclOna o servlO MT.sendo acessado.
IV.1.2 -TRANsMISsO E RECEPCO DE MENSAGENs-IP
O servlo básico de transmissão e recepão de mensagem-IP requer ações das UAEs ori9inadora e destinatário.
Ação do UA Or19inador: .
1 Construlr uma IM-UAPDU contendo os componentes IPMessageld e Bod de acordo com a slntaxe do protocolo.P2.
2. Transmitir uma rrimitlva SUBMIT.REQUEsT para o MTL tpndo seus parâmetros de-vldamente preenchldos (Tabela 3.2- Coluna A), e como conteúdo (parâmetro con-tent) a IM-UAPDU construída.
J
: fB UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
3 Se a primitiva SUBMIT.CONFIRMATION retornada pelo MTL indica falha na sub-missão d IM-UAPDU, o UAE deve tornar o origlnador ciente da falha e da razão da falha (parâmetro failure-reason da prImitiva SUBMITConfirmation).
4 Se a primltiva SUBMIT.Conflrmation IndlCa sucesso na submlssão, a prlmitiva proporciona os parãmetros submission-time e submit-event-id que poderá ser pos-terlOrmente usado para correlaclOnar notlficaões com esta IM-UAPDU submetida
(veJa Nota 1) "
5 Após uma submissão bem sucedida, é possível que a UAE receba uma primitiva NOTIFY.lndlcatlon slnalizando-a que a IM-UAPDU não fOI entregue ao UA destina-tário. Neste caso, a UAE deve tornar o usuário ori9inador ciente da não entrega desta mensagem-IP Além dlSSO, a prlmltlva NOTIFY.lndicatlon transporta infor-maões nos parãmetros recipient-O/R-names e non-deliver-reason que devem estar a dlsPosião do orlglnador (veJa Nota 1)
Nota 1:
neVf:' ser possível correlacionar uma IM-UAPDU submetida previamente-com uma notificaão que a ela se refere
Podem ser usados diferentes mecanismos para estabelecer esta correlaãoo
Por exemp 1 o, o parâmet ro submit -event -id suprlO pe 1 as primi.t ivas SUBMIT.Conflrmatlon e NOTIF"Y.lndloca.tion podem ser usados para associar os dois eventos. Alternativamente, o valor da componente IPMessageld da IM-UAPDU pode-rl ser adotado como valor do parâmetro ua-content-id da SUBMIT.Request .Neste caso, o parâmetro ua-content-id retornado pela NOTIFYIndication pode ser usado para correlação. (Deve-se notar que D parâmetro ua-content-id é limitado a 16 caracteres)
r
Aão da UAE destinatário:
1 Quando a IM-UAPDU é entregue ao UAE destinatário, a prImitiva DELIVERolndi-catlon é recebida do MTL com os parâmetros do servlO básico de MT (ori-ginator-O/R-name, recipient-O/R-name. content-tpe,
original-encoded-inTorma-tion-tpes, submission-time e deliver-time)o
,,"'" ,'"
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO NUCLEO DE COMPUTACAO ELETRONICA
A IH-UAPDU está contida no parâmetro content e contém os componentes
IPHes-sageId e Bod Todas estas informações. transportadas como parâmetros da
primi-tlva DELIVER.Indication devem ser acessívels ao destlnatário na recepão da
mensngem-IP (veja Nota 2) .
Nota 2:
Há multas maneiras diferentes na qual o destlnatário pode acessar e
rece-ber a mensagem-IP.
Por exemplo. a UAE rode proporcionar ao destinatárlO a facilidade de
rece-ber seletlvamente (por exemplo. em alguma data-hora e em alguma ordem)
mensa-gens-IP que tenham sido entregues a sua UAE.
+ + + + +
I. PARÂHETRO I A.IM-UAPDU I B:SR-UAPDU I CIM-UAPDU I
, I (SERVIÇO BÁSICO) I I (AUTO-REMESSA) I
1 ' 1 I I
, I Nomes O/R das t ome O/R do I Nome O/R da UAE I
t ReclPlent- IUAEs para as qual si Orlglnador da I para a qual I
IO/R-names I a M-UAPU I IM-UAPDU I IM-UAPU sera I
f I sera envlada I sendo reportada I auto-remetlda I
1 1 ' I I
I I Nome O/R da UAE , Nome O/R 1 Nome O/R da UAE I
IOrlglnator- I que envla Ideste destlnatáriol que auto-remete I
: O/R-name 1 a IM-UAPDU Iv:n-Ayaf2101 a IM-UAPDU I
1 1 1 1 1
1- I----!: I §:
I'
!:
1 Content-tpe I Indica "Pc'. I IndlCa .'Pc" Indica "P2"
1 1 1
I I Preenchido I Não especiflcõdo I No epeclflCado I
, Encoded- I de acordo com os I (de t'orma a iID- 1 (de forma a iID- r'
IInformatlon-tpesl llPOS depõrte I pedlr converao) I pedlr conversao tl
I I de corro da I I
I I IM-UAPDU I I ,
1 1 1 1 1
, NDN-suppress I Ver Nota a I Sim I Sim I
1 1 1 I I
I' 1 O mesmo da' O mesmo da I
I I f IM-UAPDU sendo I IM-UAPDU sendo ,
I Priorit I I reportada I reportada I
I I I(conforme DELIVER-(conforme nELIVER-'
f II IndlcatlOn) 1 Indicatlon) I
1 1 1 I I
I Defprred- I Ver Nota a 1 I I
!;f;;;:;-i v;-Nt- ! N I N---1
! -tã: ! v;-Nt- I si; I s.i; --.
I
:-Di;I;;: I Ni I Ni I N---,
:-==!= 1 1 I i
, Alternate- , Ver Nota a I Não' Não
I
Irpclple"t-allowedl ,
1 1 1 I I
, Content-return I Ver Nota a I Não I Não I
, 1 ' 1 1
, UA-content-id I Ver Nota b I -I -I
1 1 ' I I
I Explicit- I Ver Nota a I I ,
I conversion I I I I
+ + + + +
, .
, Tabela 3.2
Nota.
a) Estes parãmetros não são mandatários na (MTL) sUBMIT.Request, e não estão relaclOnados com O servío báslCO de MT. Desta forma, eles não são especifica-dos na sUBMIT Request quando o servio básico de IPM é fornecido. (E1es podem, entretanto, ser especlflCados na realizaão dos elementos de servlo (MT) de SubmlSsão e Entrega e Conversão, conforme descrito na seão IV.2.1);
b) VeJa Nota 1 na seão IV.
IV.2- REALIZACO DOS sERVICOs OPCIONAIs DE TRANsMIssO E RECEPCO DE
MENsA-GENs-IP
xlstem vrirlos e1ementos de servio de IPM que podem ser se1ecionados plo usuárlo Opc]ondlmente na transmlssão e/ou recepão de uma mensagem-IP. A [)rer;)ão ds UC.Es no ofp;recimento de cada destes servios é descrlto em termos de al;õ (IU (I!-. UAE", re-ollzam adiciona1mente a aue1es sendo rea11zados para o ,",prv II;C bá.lCO de t: I-nsmlssão e recepão .
IV.2.1 -ACõEs DA UAE NO FORNECIMENTO DOS sERVICOs DE MT PARA sUBMIssO, ENTRE-GA E CONVERsO
IV.2.1.1 -GRAU DE ENTREGA, ENTREGA MULTI-DEsTINACO,
..
CONVERsO EXPLÍCITA:
Os p;lmntos de servlO de MT acima são POstos a disposlão dos usuá-rlOS do ser\.}c po)- cooperaão dos UAs origlnador e dest inatário como segue :
Aão da UAE origlnadora:
-tsreclf1.car 0(:') parâITletros(s) correspondente(s) da primltiva sUBMIT.Request uando IM-UAPDU p envlada.
Aão da UAE destinatário:
l.ornar o(s) rar5metro(s) da prlmltiva DELIVER.Indication acessíveis ao desti-natr;o undo a mensõgem-IP é recebida
A Tabela 33 lista a correspondência entre estes e1ementQs de serviço I p o parâmetros da prlmltlvas de servio.
, I } i ,
I
UNIVERSIDADE FEDERAL DO RIO DE JANEIRONota: No caso em que for solicitada Entrega Multidestinaão, podem ser gerados pelo MTL vários eventos NOTIFY.Indication relatlvos a uma IM-UAPDU Tais
noti-flcaões podem referir-se a entrega ou não-entrega a um ou mals destinatários especficados orignalmente, e devem ser correlacionados com a IM-UAPDU origi-na1 como descrito na Nota 1 da seão IV.l.
+ + + +
I ELEMENTO' PARAMETRO I PARaMETRO(s) DE I
I DE SERVIÇO' SUBMITRequest I DELIVERIndicatlon I
1 1 1 I
I Seleão de Grau de I Priorit , Priorit I
I Entrega' I ,
' 1 1 I
I Multl-destinaão I ReclPient-O/R names I Other-recipient-O/R-names I
1 1 1 ,
I Conversão Explícta I Expliclt-ConverslOn 1 Origlnal-encoded-info-tpes I
I II Converted-encoded-info-tpesl
+ +--- + +
TABELA 3.3- ELEMENTOS .DE SERVIÇO E PARaMETRos CORRESPONDENTES
IV 2.1.2- ENTREGA PRÉ-DATADA,
SUPRESSO DE NOTIFICAÇO DE NO-ENTREGA, PROIBIÇO DE CONVERSO
Os elementos de servlo de MT acima são postos a disposião dos usuá-rlO do servlço IPM por melO de aão da UAE originadora
Aão da UAE originadora:
:::specl+'lCar O parmetro' correspondente ao servio na primitiva SUBMIT.Request quando a IM-UAPDU é envada.
Os paramtros ssociados estão listados na Tabela 3.4.
+ +
I ELEMENTO I PARMETRO SUBMIT.Request I
.I. I DE SERVIÇO I CORRESPONDENTE ,
, , I
I t:ntrega Pré-datada , Deferred-deliver-time .-,
: -sN ;;-d;-Ntifi;-d;-I-NDN:;-(;j;-Nt-;b;i) I
" I ao-Entrega II
:-pibi-d;-c; I-c;i:hibit;d I
+ + +
Nota Se a IM-UAPDU está sendo transferlda a mais que um destinatário, pode ser especlflcado, para cada destlnatáro, um valor dlstinto para este parâmetro.
TABELA 3.4- ELEMENTOS DE SERVIÇO E PARHETROS CORRESPONDENTES
, , i .. ;:
:. f fllifE UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
".:.j " -;...'.'--'-', .;. =, " ;. " .NCLEO DE COMPUTAÇAo ELETRONICA
IV21.3- CONVERSQO IMPLÍCITA
Este elemento de servlo de MT é colocado a disposição de usuários do
ser.lo IPM através de ação da UAE destinatário.
Açã: da UAE destinatário:
-U-a rrlmitiva DELIVER Indication contendo uma IM-UAPDU na qual Conversão
I-plíclta fOl reallzada conterá também o parâmetro
original-encoded-informa-t:on-tpes Esta lnf'ormaão deve estar disponível ao destlnatário quando a
msaem-IP e sua demalS lnformaçães foram recebldas.
IV ..2 1.4 -PERMISSQO PARA DESTINATÁRIO AL TERNATIVO
cara que pste elemento de serviço seJa of'erecldo aos usuàrios do
Ser-vl: IPM, as seulntes aões devem ser reallzadas pelas UAEs origlnadora e
des-ti""..árlO.
Açãc da UAE originadora:
-E=eclf'lcar o Pdrâetros alternate-recipient-allowed na primitiva
SUBMIT.Re-qest uando IM-UAPDU é envlada
A,ãc da UAE destinatário alternativo:
Quando uma IM-UAPDU realmente entregue a um UAE
destintárloalter-nat:.'Jo, a prlmltlva DELIVER.Indlcatlon lndicará O O/R name do destlnatárlO
es-pec:&ic.\ção orl91nlmente no rarâmetro intended-recipient-O/R-name
1 S:! tentatlva de entrega de uma IM-UAPDU a um destinatárlO alternatlvo falha,
pnt;, . transmitlda a UAE do originador, uma primitlva NOTIFYIndication
sig-n.lf'::ando não-entrega (a meno's que tenha sido solicitado Supressão de
Notifica-,ão ,je Jão-Entrega -veJa seção IV2.1.2).
sta prlmltlva tem parâmetros que identificam o destinatárlO orlgialmente
esr:if'icado bem como o destlnatário alternativo intended-recipient-O/R-name e
reclpient-O/R-names), estas lnforma,ões devem estar disponíveIs ao
origina-dor
2. Se tntativa de entrega de uma IM-UAPDU a um destinatárlo alternativo é bem
SUCdldõ e é reulsltada a Notificaão de Entrega (veJa seão IV.2.1.6), então,
uma rimltlva NOTIFYIndlcation significando entrega é transmitida a UAE do
, ,
I..;""! ';',
, UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
or191nador.
a parâmetro recipient-O/R-names refJetirá o destinatário real (alternati-vo), enquanto o parâmetro intended-recipient-O/R-name terá o mesmo valor
daque-le suprldo or19inalmente pela SUBMIT.Request .
3. Outras ações devem ser realizadas peJo UA do destinatário alternativo se for requerldo Notlficação de Recebido ou Notificação de Não-Recebido para a IM-UAP-DU (veja eções IV.2.2.2 a IV.2.2.3).
IV.2.1.5- NOTIFICACO DE ENTREGA
Ete elemento de serviço de MT é colocado a disposição dos usuários do servlçO IPM por melO de ações da UAE ori9inadora.
Ações da UAE originadora:
1 A UAE pede a notiflcação especificando o parâmetro deliver-notice da primi-tlva SUBMIT.Reuest quando a IM-UAPDU é envlada.
2 Se a UAE or191nadora slnalizada através, de uma primltiva NOTIFY.lndica-tlon, da entrega da IM-UAPDU, então a UAE dev.e tornar o orlginador ciente desta notificação A lnfol-mação de notificação que é transportada pela NOTIFY.lndica-tlon (parmetro recipient-O/R-names, deliver-tie, tpe-of-UA e, se aplicável os parâmtro= converted-encoded-information-tpes, intended-recipient-O/R-name,
e supplementar-lnformation) devem estar adisposlção do or191nador.
Nota: Deve ser rossível correlacionar a notificação com a Im-UAPDU a qual se refere Exemplos de dlferentes mecanismos para o estabelecimento desta correla-ão são descritos na Nota 1 da seção IV.1.
IV.2.1.6- RETORNO DE CONTEúDO
Este elemento de serviço de MT é colocado a disposição dos usuários do servlçO IPM por melO de ações da UAE originadora.
Ações da UAE originadora:
1 Especlficar O pedido para o servio no parâmetro content-return da primitiva l' SUBMITReC'luest quando IM-UAPDU é enviada.
i, 1 . ,
J
. c , . c,fi ;,'". UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
2 Se a F:'ntl-ega de uma lM-UAPDU falha, o paràmetro returned-content da primiti.;. va NOTIry Indlcatlon transportará a IM-UAPDU retornada. A UAE deve colocar esta. lnormação a disposlção do orlglnador. <O servlço de Supressão de Notificação deNão-Entrega ni.o deve ter sldo solicitado quando a IM-UAPDU foi submetida)
IV2.c -PROPORCIONANDO OS ELEMENTOS DE SERVIÇO COM AÇO DE UAs COOPERANTES
E5te5 elemntos de servlço são descritos na recomendação X400 São
eles
IV.2.c.1- INDICAÇO DE DESTINATÁRIO CóPIA CEGA
Ações da UAE do usuárlo originador:
1 ['onstl-ull- duas (ou mals, rosslvelmente) IM-UAPDUs de acordo com a sintaxe do protocolo Pc. Estas IM-UAPDUs são idêntlcas exceto pela lnclusão e conteúdo do comroncnte blindCopRecipients
c A IM-UAPDU ue não contém o componente blindCopRecipients é enviada trans-mitlndo-5 uma prlmlllVa SUBMIT Request somente para aqueles destlntários es-peciicados como destin"táríos primário ou có,pia da mensagem-IP <isto é, somen-te o O/R names dos dstlnatárlos prlmárlo cóPla são suprldos no parâmetro rcipient-O/R/-names da SUBMIT.nequest)
3. Aos destinatárlo cóPla cega é envlada uma IM-UAPOU diferente O grau de re-velação dos destinalárlO cópia cega uns aos outros é uma questão local.
Por exemplo, o UAE pode envlar a mesma IM-UAPOU para todos os destinatários córla cega, pode envlar uma IM-UAPDU para cada destinatárlo cópia cega. indivi-dualmente, ou pode escolher algum outro a!Jrupamento. Além dlsso, o UAE pode in-serlr no component blindCopRecipients da IM-UAPOU sendo enviada para os des-tlnatárlos CÓP1 cega de um mesmo arupamento, somente OS nomes dos destinatá-rios córla cega que receberão aquela córla particular da IM-UAPOU, ou alguma "
outra comblnação de nomes de destinatários cópia cega.
Quando as IM-UAPDUs são entregues por intermédlo da primitiva .OELIVER. Indicatlon, as IM-UAPOUs enviadas as UAEs dos destinatárlos primários e secun-dários não contém o componente blindCopRecipients e desta forma estes destina-t.irlos não flCam Clentes dos destlnatários cópia cega.
,,1 ,.: ,
r UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
A UAE de cada destinatário cópia cega é informado de algum conjunto de destInatárIOs cóPIa cega incluindo ele próprio através do componente b1indCop-Recipients que a UAE do originador supriu a ele nesta cópia da IM-UAPDU.
IV2.2.2 -NOTIFICACO DE NO-RECEBIDO
A reallza,ão deste elemento de serviço requer ação das UAEs dos usuá-rlOS originador e destinatário.
A,ão da UAE do usuário originador:
1 ESrpClficar o redldo do servl'O (adlClonalmente ou independentemente do pe-dldo de Notificação de Recebido) na componente reportRequest da IM-UAPDU que é enviada para o destInatário através da prImitiva SUBMI.T.Request, para cada des-tlnatárlO.
2 Quando d UAE do usuárlO or191nador recebe a UELIVER.lndication vinda do MTL, ue trõnsporta a SR-UAPDU notIflcando o não-recebimento por parte do usuário destlnRtárlO da !M-UAPDU envlada, esta deve tornar O originador ciente da noti-fIca,ão d. não-recebido
Nota: Q componente ORDescriptor que acompanha o pedldo de notIfica,ão de rece-bldo (Ive Inclulr O Q/R name do destInatárlO (veJa Nota 2 na seção III.1.2.1> .
A,ão da UAE do usuário destInatário:
A IM--UAPDU será entregue a UAE de cada destlnatário atrvés da primi-tlva DELIVER.Indlcation.
-Para cada destInatário ao qual a Notifica,ão de Não-Recebldo foi solicitada, a UAE gerdrá not!flCa,ão sob as spguInte condi,ões:
I.
) No ca5o em quc IM-UAPDU no é receblda pelo origlnador, mas fo auto-remeti-da pela UAE do usuJrIo destlnatário a outra UAE;
b) No caso em que antes que o destlnatãrlO receba a mensagem-IP, a UAE descarta a IM-UAPDU, de forma que não há segurança de que a mensagem-IP será sempre re-CE'blda.
-Geração da Notificação:
A UAE con.stról uma SR-UAPDU tendo como componente a IPMessageId, que é idêntlca a aquela da IM-UAPDU sendo reportada, e a informação relatlva a razão I
c
' ."'
..
pra o não-receblmento (veJa Colun A da Tabela 3.5).
O componenteintendedRecipient é também incluído se e somente se o
des:lnatárlO real difere daquele especiflCado pelo orlginador Este componente contém o O/R name que fOl transrortado no parâmetro intended-reciplent-O/R-name
da ELIVER Indlcatlon
Se fOl olicltado retornb da mensagem-IP (Retorno de Conteúdo) então a ,,, IM-UAPDU é transportada no componente returned da sR-UAPDU.
t
Para envlar a notlflCaão, a UAE dlSpara a primltlva sUBMIT.Request tedo esta sR-UAPDU no rariimetro content Os demais parâmetros desta prlmitiva #
são espec.!.flCados como mostra a Coluna B da Tabela 3.2
IV,2.2.3- NOTIFICACO DE RECEBIDO
f4 realização deste: elemento de servlo requer a,ão das UAEs dos usuá-rlos orlglnador e destinatário (e posslvelmente do próprlo destlnatárlO).
A,ão da UAE do usuário originador:
1. Especlficar O pedldo do servlO na compOnente reportRequest da IM-UAPDU que é evlad par O destlnatJrlo através da prlmltlva sUBMITRequest
Notar que este pedldo pode ser feito individualmente para cada destinatário e que um pedldo de NotlflCa,ão de RE'cebldo implica também em um pedido de Noti-ficd,ão No-Recebldo.
2 Quando a UAE do usuárlO or191nador recebe a DELIVERlndication vlnda do MTL, 'lue transporta a sR-UAPDU notlflCando O receblmento da IM-UAPDU enviada, esta deve tornar o Orllnador Clente da notiflcação de recebido, e informações
in-clulndo os componentes receiptTime e supplementarInformation devem estar a
dlSPOS1'ão do usuárlO orlginador ,.
Nota: O componente ORDescriptor que acompanha o redido de notificação de rece-hldo deve lnclulr O O/R name do destinatário (veja Nota 2 na se,ão III.12..1) .
Ação da UAE do usuário destinatário:
A IM-UAPDU será entregue a UAE de cada destinatário através da primi-tlva DELIVER.Indlcatlon
-Para cada dtinatárlO para O qual a notlficação de recebido foi .pedlda, uma das duas eguintes. situações poderá ocorrer:
.
1 ,1;, .,,
!-'B UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
a) Quando a IM-UAPDU é recebida pelo destinatário, a UAE gerará automaticamente a sR-UAPDU que transmltirá a notificaão de recebido ao origlnador.
b). A UAE informará ao destinatário, quando receber a mensagem-IP, do pedido de notIficaão de recebido. A UAE esperará que o destlnatárlo realize alguma aão explícita autorizando o retorno da notificaão, e então a sR-UAPDU que transmi-te a notifIcaão será realmente gerada e enviada.
-Geraão de Notificaão:
A UAE constrói uma sR-UAp.DU incluindo os componentes ReportedIPMessa-geID da IM-UAPDU para a qual a notificao se aplica, tpeOfReceipt (por exem-plo, automátlca ou explícita, como descrlto acIma) receiptTime (veJa a coluna B da tabela 3.5) .
O componente intendedRecipient é também incluído se e somente se o destInatárlO real difere daquele especIfICado pelo origInador. Este carrega o ORDescriptor contIdo no componente Recipient da IM-UAPDU entregue, que corres-ponde ao parãmetro intended-recipient-O/R-name da DELIVER.lndication.
Para envIar a notificaão, a UAE dispara a primItIva sUBMIT.Request com a sR-UAPDU no parmetro content .Os outros parâmetros desta primitiva são especificados como mostra a Coluna B da Tabela 3.2.
IV.2.2.4- INDICAÇO.DE AUTO-REMETIDA
A ralIZaão deste lmento de servio rquer as seguintes aões dos
UAs cooperantes:
1. Quando uma UAE destinatária recbe uma IM-UAPDU através da primitiva DELI-VERlndlcation, O seu componénte auto-forwarded indica se o seu corpo contém uma mensagem-IP (IM-UAPDU) auto-remetida.
Se a m.nsagemIP auto-remetida contém um pedido de notiflcaão de re-cebido e/ou não-recebldo, estes pedidos são ignorados e a notificaão não é ge-rada
2. É possível que a própria UAE destinatária tenha sido instruída a realizar auto-remessa. Entretanto, para garantir que não ocorrerá oolooping'O de mensa-gem-IP C\uto-rE:'metidas, a UAE não deve auto-remeter IM-UAPDU contendo uma parte :t do corpo auto-remetlda
J ,c \!,, .
"".f',
. UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
3. Se a UAE recebe uma IM-UAPDU que contém uma mensagem-IP auto-remetida e não rea11za sua auto-remessa.então ela deve indlcar ao destinatário. quando ele recebe a mensagem-IP. que a IM-UAPDU contém uma mensagem-IP no seu corpo.
+ +
I COMPONENTES I A.Não-recebido I B,Recebido ICA\.1to-remeidol
I I I I Nao-recebldo I
+ + +
IreportedIPMessageId I Ver Nota a I Ver Nota a I Ver Nota a I
+ + + + +
lactualReclPlent I Ver Nota b I Ver t"ota b I Ver Nota b I
.+ + + +
IlntendedRecipient I Ver Nota c I Ver Nota c I Ver Nota a I
+ + +
IConverted I Ver ota d I Ver Nota d , Ver Nota d I
+ + +
IrecelPtTlme I I UAE fornece I I
I' I dat a-hora de I I I I I receblmento I I + + ftpeOfRecept I f lncjica I I t I 1"expl1ito"oul I I r "'automatico" I I + +
I reason I Indica "des!;:artada I I IndlCa ,.
I I pela UAE" , 1"auto-remetida"1
+ + + + +
1IJplmentar1 I ---I Informação I ---I
Ilnformation , I suplementar J I
I I I forneclda I I
I I I pela UAE I I
+ + + +
InonRecelPtQualifler IIndlca .'expirada", I I I
I "'obsoleta" ou subs-1 I I , I crlaO termlnada" I I I + + + + + IComments , , IComntrlO do I I , I I destinatario , I I I I dest 1 nado I I , I I (se suprldo) I + +
Ireturned I IM-UAPDU sendo I IIM-UAPDU sendo I
I I reortada. se I J reportado. se I
I' solicltado pelo I I solicltado I
I I orlglnador 1, Ipelo or191nadorl
+ ---+ + +
Nota a) Éo mesmo ldentiflCador transportado na IM-UAPDU a ual o relatório se refere
Nota b) O/R Descrlptor do usuário CUJO UAE realmente recebeu a IM-UAPDU que está gerando este relatório.
Nota c) O/R Descriptor do destinatário orilalmente destinado. obtldo do com-ponente Recipient correspondente da IM-UAPDU sendo reportada.
Nota d) Se ocorreu conversão no UAL. este parâmetro é idêntlco ao novo. compo-nente newEncodedlnformatlonTpes Se ocorreu conversão no MTL e não nc UAL. este parâmeto é ldêntlco ao parâmetro conyerted-encoded-informa
tlon-tpes da DELIVER,Indication que transportou a IM-UAPDU sendo re-portada
TABELA 3.5. COMPONENTES DA SR-UAPDU J
"" .J .
UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
.100 NÚCLEO DE COMPUTAÇÃO ELETRONICA
-IV.2.3 -REALIZACO DOS ELEMENTOS DE SERVICO PARA TRANSFERÊNCIA DE INFORMACO
ENTRE UAs COOPERANTES
1.2.3.1 -ELEMENTOS DE SERVICO DE TRANSFERÊNCIA DE INFORMACO APLICADOS
POR-MENSAGEM-IP
Várlos elementos de servi,o para transferêncla de informação entre UAs
cooperantes são apllcávelS por-mensagem-IP. Isto é, quando o elemento de
servi-'o é especlficado, ele se aplica a mensagem-IP e a todos os seus destlnatários.
Este tlPO de elemento de servi,o é dlstlnto do tlPO de elemento de servlO que
pode ser especlficado por destinatário, ou seja, individualmente para cada um
dos várlos destlnatárlOS de uma mesma mensagem-IP.
Os elementos de servi'o para transferência de informa,ão que estão na
categorlõi ..por-men!;Õagem-IP" são os segulntes :
-Indlca,ão do Orlglnador
-l"dlCa,ão de UsuárIOS AutorlZados
-Indlca,ão Ij destlnatrl0S PrlmárlO e Cópia
-Indlcação de Data de ExPlra,ão
-rndlcaão e Rerêncla Cruzada
-IndlCa,ão de Importáncla
-IndlCa,ão de Obsolescêncla
IndlCa,ão r.'e Sensit lvldade
Indlcar;ão de SuJeito
-IndIcar;ão de Rspota a Mensagem-IP
-Indica,ão de Mnsagem-IP emetlda
-!ndlCa,ão de Parte do Corpo Encriptado
I.
REALIZACO DESTES ELEMENTOS DE SERVICO:
Indlcaão de Mensagem-IP Remetlda e Indica,ão de Parte do Corpo Encriptada:
Para proPOrclOnar estes elementos de servlO a UAE do usuárlo
orlgina-dor lnc1ul OS tlPOS de corpo aproprlados (ForwardedIPMessage e Encripted) na
I-UAPDU ue é construída para ser envlada a UAE do destlnatário
! .
I
I
.yf
,
! ;:r UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Para os demais elementos de servio deste tipo:
O UAE do orlglnador inclui na IM-UAPDU o componente do cabe,alho cor-respondente ao element de servio (veja Tabela 2.1) A IM-UAPDU é enviada a UAE do destlnatárlO através da primltiva SUBMIT.Request .
A,ão da UAE do usuário destinatário:
A IM-UAPOU chega a UAE de cada destinatárlo através da primitiva OELI-VER.lndlcatlon A UAE então transfere a informaão correspondente da IM-UAPDU par o destlnatárlO
IV.2.32- INDICACO OE PEDIDO DE RESPOSTA
Est elemento dE ser.io podE apllcar-se a cada destinatário indiví-duàlmer)t; em IJm mensagem-IP multi-destinatárío
Aão da UAE do usuárlo or191nador:
Jr1clu,-1- O componentE' replRequest na IM-UAPOU para cada destinatário para o GI.Jai o pe'::lr.:o O -esç"osta esta sendo solícltado
e Se o orllndrjor especlflCa data a partlr da qua1 a resposta deve ser en-vlada e/ou uma :l:;t;. de usuárlO(S) para OS quais a resposta deve ser envIada, a
'.JA do or!.lndor lnclul OS componentes apropriados na IM-UAPOU (reblb e
replToUsers) C' com!,onpnte replToUsers. quando presente, lnclui os O/R r\ames de t ovos o:' I)'"u-dr:. os para os '1ualS a respost a deve ser enviada .
A,ão da UAE do usuárlo dest inatário":
t Dat-a cada d.=tlnatárlO ao qual a IM-UAPOU é entregue, a UAE destlnatárlO de-ve eHtra,-r 0 componr,t: replRequest relativo a Sl (se presente) e transferir estô lnorma,ão ao destlnatárlo
"
2 Sf-! a IM-UAPDU contem os componentes replb e replToUsers. estas informa-,ões devem er ext1-aidas e transferidas ao destlnatário.
.,
Nota'
O omponente replRequest faz parte do componente Recipient, o qual também contém o ORDescriptor
;-. c '!:}'
, UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
Quando o componente replRequest é lncluído, O componente ORDescriptor dev
, '
incluir o O/R name do destlnatarlO. O O/R name e requerldo pO1S na sua ausencla
o UAE destinatárlO não deverla estar apto a reconhecer e extralr o componente
Recipient da IH-UAPDU que se refere a ele. Portanto a UAE não estarla apta a
completar a reallZaão deste elemento de servl'O.
IV.2.3,3- CORPO MULTI-PARTE
Este elemento de servlO .fornece capacidade para que o corpo da
mensa-gem-IP conslsta de várias partes diferentes, contendo tlPOS de codifica,ão
di-ferentes.
Aão da UAE do usuário originador:
1 .COnstrulr a IM-UAPDU lnclulndo as várias partes do corpo juntamente com a
lndlCaão de seus tipos no componente Bod.
2 Quando a UAE envla a IH-UAPDU dlsparando a primitiva SUBMITRequest, devem
ser esrl?clficados os tlros das várias rartes do corpo no rarâmetro
encoded-in-fOrmatlon-tpes lnclulndo os parâmetros não-básicos para as partes do corpo com
tal característlcas (por exemplo, telefex e G3Tacslmile). Por eHemplo, se o
corpo conslste de várlas partes de corpo tipo teletex e G3facsimile, os
parâme-tros não-báslCOS referentes cada parte será' lncluída em cada parte de corpo
A UAE OI-I!Jlnadora deve executar um .'OR" dos parãmetros não-básicos tanto para
as partede (.L'rpo E'lete><, como para as partes G3facslmlle, de forma obter d
decrlão do '.í'lOr càso" Hm relaão a compatibilldade do tipo de corpo. Estes
valores, resultantes da operação "OR" para estes tlPoS de corpo, são fornecidos
no parametro encoded-information-tpes da SUBMIT.Request .
3 Quando uma IH-UAPDU com um corpo multl-parte é entregue a uma UAE
d.estlnatá-rlO, e não foram reallZadas conversões no MTS, então o parâmetro
encoded-inTor-matlon-tpes ,,;erá idêntico aó suprido pela UAE orlginadora. Se alguma conversão
fOl feltõ, parametr(1 encoded-inTormation-tpes lndicará os novos tipos
resul-tantes das conversões, e o parãmetro original-encoded-information-tpes
indica-rá os t1POS das partes do corpo originalmente enviado.
Nota: Se não é felto um mapeamento dos tipos de lnformão codificada originais
para as correspondente põrtes convertldas do corpo, não será possível ao
des-tlnatál-lo determlnar que partes do corpo foram realmente convertidas.
i r i I '" ," .
t .ff3 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
4 Quando uma mensagem-IP consiste de uma única parte de corpo do tlPO G3 fac sim11e ou teletex, os parâmetros não-básicos não precisam ser dup1icados no componente BodPart da IM-UAPDU, mas podem ser transferidos no parâmetro
origi-nal-encoded-information-tpes da prlmitiva SUBMIT.Request quando a IM-UAPDU é
envlada Na entrega da IM-UAPDU, os parâmetros não-báslCOS são fornecidos a UAE destlnátária através do paràmetro encoded-information-tpes da prlmltlva DELI-VER.lndlcatlon. A ausêncla dos parâmetro= não-báslCOS tanto do compor,ente
Bod-.Part da IM-UAPDU como do parâmetro original-encoded-information-tpes (quando o
prãmetro orlglnal-encoded-lnformatlon-tpes indlCa uma prte de corpo do tlPO
G3 facslm11e ou te1etex) lndica que a parte do corpo do tipo báslCO G3
facsl-mlle ou teletex :
IV.3 -REALIZAÇO DOS ELEMENTOS DE SERVIÇO OPCIONAIS INDEPENDENTES DA TRANSMIS-SO OU RECEPÇO DE MENSAGEM-IP
Este conJunto de e1ementos de servlO não sao seleclonados m assOCla-ão com os servlO báslCOS de transmlssão e recepção de mensagens-IP, mas
pro-rorclOnam outras caracldades e são SOllcltados lndependentemente Consiste de
("Iuatro elementos de servlço de MT.
-Cancelamento de Entrega Pre-datada Probe
-Retldo rara Entreg
-DeSl!)nção de DestlnatárlO A1ternatlvo
IV.3.1 -CANCELAMENTO DE ENTREGA PRÉ-DATADA
Este: elemento de servlço é proporcionado atl-avés de ações realizadas pe10 UAE do originador.
Aões do UAE do usuário originador:
1 Se não fOl l-eClulsltado Indicação de destinatário Cópia Cega quando a IM-UAP-DU fOl orllnalmente envlada pra entrega pré-datada, e:ntão a UAE dlpara uma prlmlllVa CANCELReque:st slmples. O parãmetro submit-event-id ldentlfic.a a IM-UAPDU ue transfr a mensagem-IP =endo cance1ada (veja nota abaixo)
2 No caso em que foi requisitado Indicação de destinatário CóPla Cega quando a IM-UAPDU fOl envlada, a UAE dispara uma CANCELRequest correspondente a cada umil das duas (ou possive1mente m.alS) IM-UAPDUs que foram submetidas ao MTL e
I I ! . "" 'v , ,.
t UN1VERSIDADE FEDERAL DO RIO DE JANEIRO
que transportam uma cóPla da mensagem-1P (veJa seção 111.2.2.1); cada CANCEL.Request transporta um parâmetro submit-event-id que identifica a 1M-UAP-DU sendo cancelada (veJa nota abalxo) .
3. D MTL indicará os resultados do cancelamento pedido através da primitiva CANCEL.Conflrmatlon (ou várias prlmltlvas CANCEL.Conflrmation quando Indicação de destlnatárlO Cópia Cega for especificada) .A UAE deve utilizar o paràmetro submit-event-id retornado pela prlmltivd CANCEL.Confirmation para determinar a ..
que CANCEL.Request se refere a prlmitlva CANCEL.Conflrmation receblda
No caso de mensagens-1P envladas a destlnatárlOS Cópia Cega. OS resul-tados do pedldo de cancelamento podem não ser os mesmos para todos os destina-tárlOs esreclficados. Portanto. a UAE deve estar apta a correlacionar (via sub-mlt-event-ld) a prlmltlva CANCEL cQm o O/R name do destinatário de cada IM-UAP-OU.
4 O orlglnador deve ser lnformado dos resultados do pedido de cancelamento pa-ra cada destlnatárlO. No caso de falha. a razão da falha (especlflCada pelo
pa-râmetrn failure-reason da rrimltlva CANCEL Confirmatlon deve também estar a
dlSPOS1Ção do orllnador
Nota: Com o uso do submlt-event-id é apenas um mecanlSmO disponível para: lden-tiflcação de I!"1-UAPDIJ sendo c.a'1celadas. a UAE dE've manter estes identiflcadores
correspondentes qua1quer mensagem-IP para a qua1 se pretende proporcionar es-te servlço
rv.3.2 -SONDAGEM
Este lemento de servlço é .proporclonado através da UAE do usuárlO IPMS que lnlClllZa o pedldo de Sond.agem
Ação da UAE:
1. A UAE transmite uma primltiva PROBE.Request ao MTL tendo os va1ores dos pa-rãmetros como lndlCado na Tabe1a 3.6
2 Se a prlmltlva poOBEConfirmcction retorr)ada re10 MTL indica que o redido não fOl acelto. a UAE deve tornar o orlglnador da Sondagem ciente da falha O parâ-metro failure-reason lndicado ppla primitiva deve estar disponíve1 ao usuário orlglnador
I
,
,",'"tf'3 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
3 Se a rrlmltiva POBE.Confirmation indica que a PROBE.Request foi aceita,
en-tão a COnflrmatlon proPOrclOna OS parâmetros probe-time e probe-event-id que
pode ser usado para correlaclonar notificaões posterlOres com esta Probe (veJa
Nota abl><O)
4 Pr;J PROBE que foi aceita, a UAE receberá a primitiva NOTIFV.Indication
slnallZõndo "entregd" ou "não-entrega" Se é lndlCado "entrega", a UAE deve
in-t'nrm;.tr .10 orl!Jindor- d Probe que uma mensagem-IP submetida com estes mesmos
parãmet ros POderlct ser ent regue com sucesso. Se é ind icado "não-ent rega" , a UAE rjevf-' J"'(Jrmar ao Qr191nador que uma mensagem-IP submetida com estes mesmos pa-rametros terla .'no-entrega'. como resultado.
Nota: !Je'/P ser possíve1 correlaclOnar uma notificação com PROBE a qual se
refe-re Emplos d mcalSmOS para estabelecer esta correlação estão descritos na
ola i da seo IV 1
-1 + +
PARf.ME O VALOR ESPECIFICADO PELA UAE
+ +
RclPlent-O/R-names Nomes O/R dos destlnatárlOS
especlfcados peJo or191nador
+ + +
Orl'Jlntor-O./R-rltlms Nome O/R do usuário envlando a
sondagem
i o... 0- + I
Cont!'1-tpe Indlc "P2"
+ : +
Encodl.1l.:-.' I:"(m,,1tlC1n-tpesl Corno especlflCado pelo usuárlo
+ +
C o n ver '.' 1 O n -p r O h 1 b 1 t e d C O m O e s p e c i f 1 c a d O p e 1 o u s u a r 1 O
" 1 + +
Alternat-eC1Plent-llowed Como especificado reJo usuário
+ + +
Contn!:--lenht Como especlf'icado relo usuárlo
+
A-Contnt-Id Como especlÇicdo reJo usuário
+
TABELA 3.6: Parâmetros utilizados na primitiva PROBE.Request
! l:!.i;;'j
,1
r UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
