(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.101.S)
(SANS FORMULE) Tableaux: 12 Tabulateurs: 0 Formules: 0
FOLIOS: 301 - 323 (DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 25.08.89 PR/UT
ID + LASER + diskette MAJ 03.10.89 JG
Corr. LASER (1re épreuve) = 3eme 23.10.89 UT
Espaces réservés 31.10.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 2.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 3.11.89 PC
BAT du 19/XI/89 21.11.89 PV
MAJ s/disquettes 7.12.89 CD
8.3
Puerto de entrega
En este punto se definen las operaciones-abstractas y los errores-abstractos que ocurren en un puerto-entrega.
8.3.1
Operaciones-abstractas
En este punto se definen las siguientes operaciones-abstractas de puerto-entrega:
a)entrega-mensaje
b)entrega-informe
c)control-entrega.
8.3.1.1
Entrega-mensaje
La operación-abstracta entrega-mensaje permite que el STRM entregue un mensaje a un usuario-STRM.
El usuario-STRM no debe rehusar la entrega de un mensaje a menos que la entrega viole las limitaciones de control-entrega entonces en vigor.
8.3.1.1.1
Argumentos
El cuadro 15/X.411 enumera los argumentos de la operación-abstracta entrega-mensaje y para cada argumento califica la presencia e identifica el punto donde se define el argumento.
8.3.1.1.1.1
Identificador-entrega-mensaje
Este argumento contiene un
identificador-STRM
que
distingue el mensaje de todos los demás mensajes en el puerto de entrega. Debe
ser generado por el STRM y debe tener el mismo valor que el
identificador-remisión-mensaje
suministrado por el
originador del mensaje al remitirse el mensaje.
8.3.1.1.1.2
Tiempo-entrega-mensaje
Este argumento contiene el
tiempo
en que se produce la
entrega y en que el STRM renuncia a su responsabilidad sobre el mensaje. Debe
ser generado por el STRM.
En el caso de entrega física, este argumento indica el
tiempo
en que la UAEF ha tomado la responsabilidad de
imprimir y entregar posteriormente el mensaje.
El valor de este argumento debe ser el mismo que el valor del
tiempo-entrega-mensaje
indicado al originador del mensaje
(véase el
8.3.1.2.1.8
) en el informe-entrega.
8.3.1.1.1.3
Nombre-este-destinatario
Este argumento contiene el
nombre-O/D
del destinatario
al que se entrega el mensaje. Debe ser generado por el STRM.
El valor de este argumento debe ser el mismo que el valor del argumento
nombre-destinatario-real
indicado al originador del mensaje
(véase el
8.3.1.2.1.2
) en un informe-entrega.
El
nombre-este-destinatario
contiene el
nombre-O/D
del destinatario individual, es decir no debe
contener el
nombre-O/D
de una LD.
El
nombre-O/D
del destinatario-deseado (si es diferente,
y el mensaje ha sido redirigido) está contenido en el argumento
nombre destinatario deseado
.
8.3.1.1.1.4
Nombre-destinatario-deseado
Este argumento contiene el
nombre-O/D
del
destinatario-deseado del mensaje, si éste ha sido redirigido, y el momento en
que se efectuó el redireccionamiento. Puede generarse por el STRM. Puede
existir un valor diferente de este argumento para cada ocasión en que se
redirige el mensaje.
Este argumento consta de un
nombre-destinatario-deseado-originalmente
y un
nombre-destinatario-deseado
. En la primera ocasión en que se
redirige un mensaje tanto el
nombre-destinatario-deseado-originalmente
como el
nombre-destinatario-deseado
contienen el
nombre-destinatario
especificado-originalmente por el
originador del mensaje. Las redirecciones subsiguientes causan ulteriores
nombres-destinatarios
que se añadirán a su vez como apéndice
a la lista de
nombres-destinatarios-deseados
.
El
nombre-destinatario-deseado
contiene el
nombre-O/D
de un destinatario individual o de un
destinatario deseado de una LD, y el momento en que se redirigió el mensaje a
un destinatario alternativo.
Cuadro 15/X.411 [T15.411], p.
8.3.1.1.1.5
Motivo-redireccionamiento
Este argumento indica el motivo de que se haya redirigido el mensaje a un destinatario-alternativo. Debe ser generado por el STRM en cada ocasión en que se produce un redireccionamiento. Puede existir un valor diferente de este argumento para cada ocasión en que se redirige el mensaje.
Este argumento puede tener uno de los siguientes valores:
-
destinatario-alternativo-asignado-destinatario
: el
destinatario-deseado del mensaje solicitó que se redirigiera el mensaje a un
destinatario-alternativo-asignado-destinatario
; el
originador del mensaje no prohibió una reasignación-destinatario (véase el
8.2.1.1.1.4
); el STRM redirige el mensaje al
destinatario-alternativo-asignado-destinatario
;
-
destinatario-alternativo-solicitado-originador
: el
mensaje no pudo entregarse al destinatario-deseado o al
destinatario-alternativo-asignado-destinatario
(si está
inscrito); el argumento
destinatario-alternativo-solicitado-originador
identificó un
destinatario-alternativo solicitado por el originador del mensaje; el STRM
redirigió el mensaje al
destinatario-alternativo-solicitado-originador
;
-
destinatario-alternativo-asignado-destinatario-DG
: el
argumento
nombre-destinatario
no identificó un usuario-STRM
destinatario; el argumento
destinatario-alternativo-autorizado
generado por el
originador del mensaje autorizó la entrega a un destinatario-alternativo; el
STRM redirigió el mensaje a un destinatario-alternativo asignado por el
destinatario-DG para recibir dichos mensajes.
8.3.1.1.1.6
Otros-nombres-destinatarios
Este argumento contiene los
nombres-O/D
especificados-originalmente de todos los destinatarios que no sean los
identificados por el argumento
nombre-destinatario-deseado-originalmente
, si éste está
presente, y el argumento
nombre-este-destinatario
, si el
originador del mensaje solicitó la revelación de los otros destinatarios (con
el argumento
revelación-de-destinatarios
de la
operación-abstracta de remisión-mensaje). Puede generarse por el STRM. Puede
existir un valor diferente de este argumento para cada destinatario
especificado-originalmente distinto del
nombre-este-destinatario
al cual se entrega el mensaje.
Cada
nombre-otro-destinatario
contiene el
nombre-O/D
de un destinatario individual o de una LD.
8.3.1.1.1.7
Historia-ampliación-LD
Este argumento contiene la secuencia de
nombres-O/D
de
cualesquiera LD que hayan sido ampliadas para añadir destinatarios a la copia
del mensaje entregado al destinatario, y el momento de cada ampliación. Debe
ser generado por el STRM si se produjo cualquier ampliación-LD.
8.3.1.1.1.8
Tipos-información-codificada-convertida
Este argumento identifica los
tipos-información-codificada
del
contenido
del mensaje después de la conversión, si ésta tuvo
lugar. Puede generarse por el STRM.
8.3.1.1.2
Resultados
El cuadro 16/X.411 enumera los resultados de la operación-abstracta entrega-mensaje, y para cada resultado, califica su presencia e identifica el punto donde se define el resultado.
Cuadro 16/X.411 [T16.411], p.
8.3.1.1.2.1
Certificado-destinatario
Este argumento contiene el
certificado
del destinatario
del mensaje. Debe ser generado por una fuente de confianza (por ejemplo, una
autoridad-certificación), y puede ser suministrado por el destinatario del
mensaje, si el originador del mensaje solicitó una
prueba-de-entrega
(véase el
8.2.1.1.1.32
) y se
utiliza un algoritmo-cifrado-asimétrico para calcular la
prueba-de-entrega
.
Puede utilizarse el
certificado-destinatario
para
transportar una copia verificada de la clave-cifrado-pública-asimétrica
(
clave-pública-sujeto
) del destinatario del mensaje.
El originador del mensaje puede utilizar la
clave-cifrado-pública-asimétrica del destinatario para validar la
prueba-de-entrega
.
8.3.1.1.2.2
Prueba-de-entrega
Este argumento proporciona al originador del mensaje una prueba de que se
ha entregado el mensaje al destinatario (para proporcionar el
elemento-de-servicio prueba de entrega definido en la Recomendación X.400) en
función del algoritmo-cifrado utilizado y de la política-seguridad en vigor.
Este argumento puede proporcionar igualmente el elemento-de-servicio no repudio
de entrega (definido en la Recomendación X.400). Debe ser generado por el
destinatario del mensaje, si el originador del mensaje solicitó una
prueba-de-entrega
(véase el
8.2.1.1.1.32
).
La
prueba-de-entrega
se calcula utilizando el algoritmo
identificado por el
identificador-algoritmo-prueba-de-entrega
(un
identificador-algoritmo
).
La
prueba-de-entrega
contiene el
identificador-algoritmo-prueba-de-entrega
y una función cifrada (por
ejemplo, una versión comprimida o desmenuzada) del
identificador-algoritmo-prueba-de-entrega
, el
tiempo-entrega
y el
nombre-este-destinatario
, el
nombre-destinatario-deseado-originalmente
el
contenido
del mensaje, el
identificador-contenido
, y la
etiqueta-seguridad-mensaje
del mensaje entregado. Se
incluyen componentes facultativos en la
prueba-de-entrega
si
están presentes en el mensaje entregado. Obsérvese que la
prueba-de-entrega
se calcula utilizando el contenido claro
(es decir, sin cifrar) del
contenido
del mensaje.
Obsérvese que la recepción de este argumento proporciona al originador del mensaje una prueba de entrega del mensaje al destinatario. La no-recepción de este argumento no proporciona ni la prueba de entrega ni la prueba de no entrega (a menos que se utilice una ruta segura y una funcionalidad de confianza).
Si se utiliza un algoritmo-cifrado-asimétrico, el destinatario del mensaje
puede calcular la
prueba-de-entrega
mediante la
clave-cifrado-secreta-asimétrica del destinatario. El originador del mensaje
puede validar la
prueba-de-entrega
utilizando la
clave-cifrado-pública-asimétrica (
clave-pública-sujeto
)
deducida del
certificado-destinatario
. Una
prueba-de-entrega
asimétrica puede igualmente proporcionar
un no repudio de entrega.
Si se utiliza un algoritmo-simétrico, el destinatario utiliza una
clave-cifrado-simétrica para calcular la
prueba-de-entrega
,
y el originador para validar la
prueba-de-entrega
. Obsérvese
que si se utiliza un algoritmo-cifrado-simétrico entonces la
prueba-de-entrega
puede proporcionar únicamente un no
repudio de entrega si la política-seguridad en vigor proporciona la
intervención de una tercera parte que actúe como notario. Los procedimientos
mediante los cuales se distribuye la clave-cifrado-simétrica no se definen en
esta Recomendación.
8.3.1.1.3
Errores-abstractos
El cuadro 17/X.411 enumera los errores-abstractos que pueden interrumpir la operación-abstracta entrega-mensaje, y para cada error-abstracto identifica el punto donde se define el error-abstracto.
Cuadro 17/X.411 [T17.411], p.
8.3.1.2
Entrega-informe
La operación-abstracta
entrega-informe
permite que el
STRM proporcione el acuse de recibo al usuario-STRM de uno o más resultados de
una invocación previa de las operaciones-abstractas remisión-mensaje o
remisión-sonda.
Para la operación-abstracta remisión-mensaje, la operación-abstracta entrega-informe indica la entrega o no-entrega del mensaje remitido a uno o más destinatarios.
Para la operación-abstracta remisión-sonda, la operación-abstracta entrega-informe indica si podría entregarse un mensaje o producirse una ampliación-LD, si se remitiera el mensaje.
Una invocación sencilla de la operación-abstracta remisión-mensaje o remisión-sonda puede provocar varias apariciones de la operación abstracta entrega-informe, cubriendo cada una de ellas uno o más destinatarios deseados. Una aparición sencilla de la operación-abstracta entrega-informe puede informar tanto sobre la entrega como la no-entrega a diferentes destinatarios.
Una invocación de la operación-abstracta remisión-mensaje o remisión-sonda por un usuario-STRM puede provocar apariciones de la operación-abstracta entrega-informe a otro usuario-STRM, por ejemplo, informes entregados al propietario de una LD.
El usuario-STRM no debe rehusar aceptar la entrega de un informe a menos que la entrega del informe viole las restricciones del control-entrega entonces en vigor.
8.3.1.2.1
Argumentos
El cuadro 18/X.411 enumera los argumentos de la operación-abstracta entrega-informe y para cada argumento califica la presencia e identifica el punto donde se define el argumento.
8.3.1.2.1.1
Identificador-remisión-sujeto
Este argumento contiene el
identificador-remisión-mensaje
o el
identificador-remisión-sonda
del sujeto del informe. Debe
ser suministrado por el STRM.
8.3.1.2.1.2
Nombre-destinatario-real
Este argumento contiene el
nombre-O/D
de un destinatario
del mensaje. Debe ser generado por el originador del mensaje, o por el STRM si
el mensaje ha sido redirigido. Debe especificarse un valor diferente de este
argumento para cada destinatario del sujeto al que se refiere el informe.
En el caso de un informe de entrega, el
nombre-destinatario-real
es el nombre del destinatario real
del mensaje y tiene el mismo valor que el argumento de
nombre-este-destinatario
del mensaje entregado. En el caso
de un informe-no-entrega, el
nombre-destinatario-real
es el
nombre-O/D
del destinatario al que iba dirigido el mensaje
cuando se encontró la razón para no-entrega.
El
nombre-destinatario-real
puede ser un
nombre-destinatario
especificado-originalmente, o el
nombre-O/D
de un destinatario alternativo si se ha
redirigido el mensaje. Si se ha redirigido el mensaje, el
nombre-O/D
del destinatario-pretendido está contenido en el
argumento de
nombre-destinatario-deseado
.
El
nombre-destinatario-real
contiene el
nombre-O/D
de un destinatario individual o de una LD.
8.3.1.2.1.3
Originador-e-historia-ampliación-LD
Este argumento contiene una secuencia de
nombres-O/D
e
instantes asociados que documentan la historia del origen del mensaje-sujeto.
El primer
nombre-O/D
de la secuencia es el
nombre-O/D
del originador del sujeto, y el resto de la
secuencia es una secuencia de
nombres-O/D
de las LD que han
sido ampliadas al dirigir el sujeto hacia el destinatario (la última es la
misma que la
historia-ampliación-LD
). Debe ser generado por
el ATM-que-origina del informe si se ha producido cualquier ampliación-LD en el
sujeto.
El
originador-e-historia-ampliación-LD
contiene el
nombre-O/D
del originador del sujeto y de cada una de las
LD, y el instante en que se ha producido el suceso asociado.
8.3.1.2.1.4
Nombre-LD-informador
Este argumento contiene el
nombre-O/D
de la LD que envió
el informe al propietario de la LD. Debe ser generado por un
punto-ampliación-LD (un ATM) al enviar un informe al propietario de la LD, en
línea con la política-informadora de la LD.
El
nombre-LD-informador
contiene el
nombre-O/D
de la LD que envía el informe.
Cuadro 18/X.411 [T18.411], p.
8.3.1.2.1.5
Tipos-información-codificada-convertidos
Este argumento identifica los
tipos-información-codificada
del
contenido
del mensaje-sujeto después de la conversión, si
ésta tuvo lugar. Para un informe sobre un mensaje, este argumento indica los
tipos-información-codificada
reales del
contenido
del mensaje convertido. Para un informe sobre una
sonda, este argumento indica los
tipos-información-codificada
que el
contenido
del mensaje-sujeto habría contenido después de la
conversión, si se hubiera remitido el mensaje-sujeto. Puede generarse por el
STRM. Puede especificarse un valor diferente de este parámetro para cada
destinatario del sujeto al que se refiere el informe.
8.3.1.2.1.6
Información-suplementaria
Este argumento puede contener información suministrada por el originador del informe, como una cadena imprimible. Puede generarse por el ATM-que-origina del informe o una unidad-acceso asociada. Puede especificarse un valor diferente para cada destinatario deseado del sujeto al que se refiere el informe.
Una unidad-acceso-teletex o una facilidad de conversión teletex-télex
pueden utilizar la
información-suplementaria
. ésta puede
contener un acuse de recibo recibido, una duración de transmisión télex, o una
nota y mensaje registrado recibido como una cadena imprimible.
Otras unidades-acceso o el ATM-que-origina del propio informe pueden
utilizar igualmente la
información-suplementaria
, para
transportar información imprimible al originador del mensaje.
8.3.1.2.1.7
Dirección-envío-físico
Este argumento contiene la nueva
dirección-O/D-postal
del destinatario-físico del mensaje. Puede generarse por la UAEF asociada al
ATM-que-origina del informe, si el originador del mensaje solicitó la
dirección-envío-físico del destinatario (véase el
8.2.1.1.1.16
).
Puede especificarse un valor diferente de este argumento para cada destinatario
deseado del mensaje-sujeto a que se refiere el informe.
8.3.1.2.1.8
Tiempo-entrega-mensaje
Este argumento contiene el
tiempo
en que se entregó (o
se podría haber entregado) el mensaje-sujeto al usuario-STRM destinatario. Debe
ser generado por el STRM si el mensaje fue (o se podría haber) entregado
satisfactoriamente. Puede especificarse un valor diferente de este argumento
para cada destinatario deseado del sujeto a que se refiere el informe.
En el caso de una entrega física, este argumento indica el
tiempo
en que la UAEF ha asumido la responsabilidad de
imprimir y posteriormente entregar el mensaje.
Si se entregó el mensaje-sujeto, el valor de este argumento debe ser el
mismo que el valor del argumento del
tiempo-entrega-mensaje
del mensaje entregado (véase el
8.3.1.1.1.2
).
8.3.1.2.1.9
Tipo-de-usuario-STRM
Este argumento indica el tipo del usuario-STRM destinatario a quien se entregó (o se podría haber entregado) el mensaje satisfactoriamente. Debe ser generado por el STRM si el mensaje se entregó (o se podría haber entregado) satisfactoriamente. Puede especificarse un valor diferente para cada destinatario-deseado del sujeto a que se refiere el informe.
Este argumento puede tener uno de los siguientes valores:
-
público
: UA que pertenece a una Administración;
-
privado
: UA que pertenece a alguien distinto de una
Administración;
-
mm
: memoria de mensaje;
-
LD
: lista-distribución;
-
UAEF
: unidad-acceso-entrega-física (UAEF);
-
destinatario-físico
: destinatario físico de un SEF;
-
otra
: unidad-acceso de otra categoría.
8.3.1.2.1.10
Código-motivo-no-entrega
Este argumento contiene un código que indica el motivo de la entrega fallida de un mensaje-sujeto (o, que en el caso de una sonda, habría fallado). Debe ser generado por el STRM, si el mensaje se entregó (o se hubiera entregado) sin éxito. Puede especificarse un valor diferente de este argumento para cada destinatario-deseado del sujeto a que se refiere el informe.
Este argumento puede tener uno de los siguientes valores:
-
fallo-transferencia
: indica que, mientras que el STRM
intentaba entregar o sondear la entrega del mensaje-sujeto, algún fallo de
comunicación le impidió hacerlo;
-
incapaz-de-transferir
: indica que, debido a algún
problema con el propio sujeto, el STRM no pudo entregar o sondear la entrega
del mensaje-sujeto;
-
conversión-no-realizada
: indica que una conversión
necesaria para la entrega del mensaje-sujeto no pudo (o no podría) realizarse;
-
reproducción-física-no-realizada
: indica que el UAEF no
pudo reproducir físicamente el mensaje-sujeto;
-
entrega-física-no-realizada
: indica que el SEF no pudo
entregar físicamente el mensaje-sujeto;
-
entrega-limitada
: indica que el destinatario está
abonado al elemento-de-servicio de entrega-limitada (definido en la
Recomendación X.400) que impidió (o impediría) la entrega del mensaje sujeto;
-
operación-guía-infructuosa
: indica que el resultado de
una operación de guía solicitada no tuvo éxito.
Pueden especificarse otros
códigos-motivo-no-entrega
en
futuras versiones de esta Recomendación.
En el argumento
código-diagnóstico-no-entrega
está
contenida otra información adicional sobre la naturaleza del problema que
impide la entrega.
8.3.1.2.1.11
Código-diagnóstico-no-entrega
Este argumento contiene un código que indica la naturaleza del problema que
hizo fracasar la entrega o la sonda de entrega del mensaje-sujeto. El motivo
del fallo se indica en el argumento del
código-motivo-no-entrega
. Puede generarse por el STRM si se
entregó (o se hubiera entregado) el mensaje sin éxito. Puede especificarse un
valor diferente de este argumento para cada destinatario-deseado del sujeto a
que se refiere el informe.
Este argumento puede tomar uno de los siguientes valores:
-
nombre-O/D-no-reconocido
: el argumento del
nombre-destinatario
del sujeto no contiene un
nombre-O/D
reconocido por el STRM;
-
nombre-O/D-ambiguo
: el argumento del
nombre-destinatario
del sujeto identifica más de un posible
destinatario (es decir, es ambiguo);
-
congestión-STRM
: el sujeto no pudo progresar, debido a
una congestión en el STRM;
-
bucle-detectado
: se detectó que el sujeto estaba
haciendo un bucle dentro del STRM;
-
destinatario-indisponible
: el usuario-STRM destinatario
estaba (o estaría) indisponible para recibir la entrega del mensaje-sujeto;
-
tiempo-máximo-expirado
: el tiempo máximo para entregar
el mensaje-sujeto, o para realizar la sonda-sujeto, ha expirado;
-
tipos-información-codificada-no-admitidos
: el
usuario-STRM destinatario no admite los
tipos-información-codificada
del mensaje-sujeto;
-
contenido-demasiado-largo
: la
longitud-contenido
del mensaje-sujeto es demasiado larga
para que el usuario-STRM acepte la entrega (excede la
longitud-contenido-máxima-entregable
);
-
conversión-no-práctica
: la conversión requerida para
entregar el mensaje-sujeto no resulta práctica;
-
conversión-implícita-prohibida
: la conversión requerida
para entregar el mensaje-sujeto ha sido prohibida por el originador del sujeto
(véase el
8.2.1.1.1.9
);
-
conversión-implícita-no-abonada
: el destinatario no se
ha abonado a la conversión requerida para entregar el mensaje-sujeto;
-
argumentos-inválidos
: se ha detectado que uno o más
argumentos del sujeto son inválidos;
-
error-sintaxis-contenido
: se ha detectado un error de
sintaxis en el
contenido
del mensaje-sujeto (no aplicable a
las sondas-sujeto);
-
violación-limitación-tamaño
: indica que el valor de uno
o más parámetros del sujeto violaron las limitaciones de tamaño definidas en
esta Recomendación, y que el STRM no estaba preparado para manejar el valor o
valores especificados;
-
violación-protocolo
: indica que faltan uno o más
argumentos obligatorios en el sujeto;
-
tipo-contenido-no-admitido
: indica que era (o sería)
necesario el procesamiento de un
tipo-contenido
no admitido
por el STRM para entregar el mensaje-sujeto;
-
demasiados-destinatarios
: indica que el STRM fue (o
sería) incapaz de entregar el mensaje-sujeto debido al número de destinatarios
especificados del mensaje-sujeto (véase el
8.2.1.1.1.2
);
-
no-acuerdo-bilateral
: indica que la entrega del
mensaje-sujeto exigía (o exigiría) un acuerdo bilateral inexistente;
-
función-crítica-no-admitida
: indica que una función
crítica requerida para la transferencia o entrega del mensaje-sujeto no estaba
admitida por el ATM-que-origina del informe;
-
conversión-con-pérdida-prohibida
: la conversión
necesaria para la entrega del mensaje-sujeto provocaría una pérdida de
información; la conversión con pérdida de información fue prohibida por el
originador del sujeto (véase el
8.2.1.1.1.10
);
-
línea-demasiado-larga
: la conversión requerida para la
entrega del mensaje-sujeto provocaría una pérdida de información porque la
longitud de la línea era demasiado larga;
-
página-partida
: la conversión necesaria para la entrega
del mensaje-sujeto provocaría una pérdida de información porque se partiría una
página original;
-
pérdida-símbolo-pictórico
: la conversión necesaria para
la entrega del mensaje-sujeto provocaría una pérdida de información debido a la
pérdida de uno o más símbolos pictóricos;
-
pérdida-símbolo-puntuación
: la conversión necesaria para
la entrega del mensaje-sujeto provocaría una pérdida de información debido a la
pérdida de uno o más símbolos de puntuación;
-
pérdida-carácter-alfabético
: la conversión necesaria
para la entrega del mensaje-sujeto provocaría una pérdida de información debido
a la pérdida de uno o más caracteres alfabéticos;
-
pérdida-información-múltiple
: la conversión necesaria
para la entrega del mensaje-sujeto provocaría una pérdida múltiple de
información;
-
reasignación-destinatario-prohibida
: indica que el STRM
no pudo (o no podría) entregar el mensaje-sujeto porque el originador del
sujeto prohibió el redireccionamiento a un
destinatario-alternativo-asignado-destinatario
(véase el
8.2.1.1.1.4
);
-
bucle-redireccionamiento-detectado
: no pudo redirigirse
el mensaje-sujeto a un destinatario-alternativo porque el destinatario había
redirigido previamente el mensaje (bucle-redireccionamiento);
-
ampliación-LD-prohibida
: indica que el STRM no pudo (o
no podría) entregar el mensaje-sujeto porque el originador del sujeto prohibió
la ampliación de las LD (véase el
8.2.1.1.1.6
);
-
no-autorización-depósito-LD
: el originador del sujeto (o
de la LD de la que esta LD es miembro, en el caso de LD anidadas) no tiene
autorización para depositar mensajes en esta LD;
-
fallo-ampliación-LD
: indica que el STRM no pudo
completar la ampliación de esta LD;
-
atributos-reproducción-física-no-admitidos
: el UAEF no
admite los atributos-reproducción-física requeridos (véase el
8.2.1.1.1.20
);
-
entrega-física-correo-imposible-dirección-incorrecta
:
fue imposible entregar el mensaje-sujeto porque la
dirección-O/D-postal
especificada del destinatario era
incorrecta;
-
entrega-física-correo-imposible-oficina-incorrecta-o-inválida
: fue imposible entregar el mensaje-sujeto porque la oficina-entrega física identificada por la
dirección-O/D-postal
especificada del destinatario era incorrecta o inválida (no existe);
-
entrega-física-correo-imposible-dirección-incompleta
:
fue imposible entregar el mensaje-sujeto porque la
dirección-O/D-postal
especificada del destinatario estaba
incompletamente especificada;
-
correo-imposible-entregar-destinatario-desconocido
: fue
imposible entregar el mensaje-sujeto porque el destinatario especificado en la
dirección-O/D-postal
no era conocido en esa dirección;
-
correo-imposible-entregar-destinatario-fallecido
: fue
imposible entregar el mensaje-sujeto porque el destinatario especificado en la
dirección-O/D-postal
había fallecido;
-
correo-imposible-entregar-organización-desaparecida
: fue
imposible entregar el mensaje-sujeto porque el destinarario especificado en la
dirección-O/D-postal
había desaparecido;
-
correo-imposible-entregar-destinatario-rehusó-aceptar
:
fue imposible entregar el mensaje-sujeto porque el destinatario especificado en
la
dirección-O/D-postal
rehusó aceptarlo;
-
correo-imposible-entregar-destinatario-no-recogió
: fue
imposible entregar el mensaje-sujeto porque el destinatario especificado en la
dirección-O/D-postal
no recogió el correo;
-
correo-imposible-entregar-destinatario-cambió-dirección-permanente
: fue imposible entregar el mensaje-sujeto porque el destinatario especificado en la
dirección-O/D-postal
ha cambiado la dirección permanente (se trasladó), y el reenvío no resultó procedente;
-
correo-imposible-entregar-destinatario-cambió-dirección-transitoriamente
: fue imposible entregar el mensaje-sujeto porque el destinatario especificado en la
dirección-O/D-postal
ha cambiado la dirección transitoriamente (está de viaje), y el reenvío no resultó procedente;
-
correo-imposible-entregar-destinatario-cambió-dirección-transitoria
: fue imposible entregar el mensaje-sujeto porque el destinatario especificado en la
dirección-O/D-postal
había cambiado la dirección temporal (
`partido'
), y el renvío no resultó procedente;
-
correo-imposible-entregar-nueva-dirección-desconocida
:
fue imposible entregar el mensaje-sujeto porque el destinatario se había
trasladado y la nueva dirección del destinatario era desconocida;
-
correo-imposible-entregar-destinatario-no-deseó-envío
:
fue imposible entregar el mensaje-sujeto porque la entrega requeriría un
envío-físico que el destinatario no deseó;
-
correo-imposible-entregar-originador-prohibió-envío
: el
envío-físico necesario para la entrega del mensaje ha sido prohibido por el
originador del mensaje-sujeto (véase el
8.2.1.1.1.15
);
-
error-mensajería-segura
: el sujeto no pudo progresar
porque violaría la política-seguridad en vigor;
-
incapaz-de-subgradar
: el sujeto no puede ser transferido
porque no puede ser degradado (véase el anexo B a la Recomendación X.419).
Pueden especificarse otros
códigos-diagnóstico-no-entrega
en futuras versiones de esta
Recomendación.
8.3.1.2.1.12
Certificado-ATM-informador
Este argumento contiene el
certificado
del ATM que ha
generado el informe. Debe ser generado por una fuente de confianza (por
ejemplo, autoridad de certificación), y puede ser suministrado por el
ATM-informador si se suministra una
comprobación-autenticación-origen-informe
.
Puede utilizarse un
certificado-ATM-informador
para
transportar una copia verificada de la clave-cifrado-pública-asimétrica
(
clave-pública-sujeto
) del ATM-informador.
El originador del mensaje y cualquier ATM a través del cual se transfiere
el informe pueden utilizar la clave-cifrado-pública-asimétrica del
ATM-informador, para validar la
verificación-autenticación-origen-informe
.
8.3.1.2.1.13
Verificación-autenticación-origen-informe
Este argumento proporciona al originador del mensaje-sujeto (o sonda-), y a
cualquier otro ATM a través del cual se transfiere el informe, los medios para
autenticar el origen del informe (para proporcionar el elemento-de-servicio
autenticación del origen del informe definido en la Recomendación X.400). Puede
ser generado por el ATM-informador si existe una
verificación-autenticación-origen-mensaje (o -sonda)
.
La
verificación-autenticación-origen-informe
proporciona
la prueba del origen del informe (autenticación del origen del informe), y la
prueba de la asociación entre la
etiqueta-seguridad-mensaje
y el informe.
La
verificación-autenticación-origen-informe
se calcula
utilizando el algoritmo identificado por el
identificador-algoritmo-autenticación-origen-informe
(un
identificador-algoritmo
).
La
verificación-autenticación-origen-informe
contiene el
identificador-algoritmo-autenticación-origen-informe
, y una
versión cifrada asimétricamente, desmenuzada del
identificador-algoritmo-autenticación-origen-informe
, el
identificador-contenido
y la
etiqueta-seguridad-mensaje
del sujeto, y todos los valores
de los argumentos siguientes (por-destinatario): el
nombre-destinatario-real
, el
nombre-destinatario-deseado-originalmente
, y:
-para un informe-entrega: el
tiempo-entrega-mensaje
, el
tipo-de-usuario-STRM
, y si el originador del mensaje lo
solicita para los destinatarios a los que se refiere el informe, el
certificado-destinatario
, y la
prueba-de-entrega
(no presente en un informe o sonda); o
-para un informe-no-entrega: el
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
.
Si están presentes en el informe, se incluyen componentes facultativos en
la
verificación-autenticación-origen-informe
.
El ATM-informador puede calcular la
verificación-autenticación-origen-informe
utilizando la
clave-cifrado-asimétrica del ATM-informador. El originador del sujeto y
cualquier ATM a través del cual se transfiera el informe puede validar la
verificación-autenticación-origen-informe
utilizando la
clave-cifrado-pública-asimétrica (
clave-pública-sujeto
)
deducida a partir del
certificado-ATM-informador
.
Futuras versiones de esta Recomendación pueden definir otras formas de
verificación-autenticación-origen-informe
(por ejemplo,
basadas en técnicas-cifrado-simétricas) que pueden utilizar los ATM a través de
los cuales se transfieren informes para autenticar el origen del informe.
8.3.1.2.1.14
Contenido-devuelto
Este argumento contiene el
contenido
del mensaje-sujeto
si el originador del mensaje-sujeto indicó que debe devolverse el
contenido
(véase el
8.2.1.1.1.23
). Debe ser
generado por el originador del mensaje, y el STRM puede devolverlo (si el
ATM-informador o el ATM-que-origina admite el elemento-de-servicio devolución
de contenido).
Este argumento puede estar presente únicamente si existe al menos un informe de no-entrega en la entrega-informe, y si el destinatario del informe es el originador del mensaje-sujeto [y no, por ejemplo, el propietario de una LD (véase el 8.3.1.2.1.4 )].
Este argumento no estará presente si se ha realizado cualquier conversión
de
tipo-información-codificada
sobre el
contenido
del mensaje-sujeto.
8.3.1.2.2
Resultados
La operación abstracta de entrega-informe devuelve un resultado vacío como indicación de éxito.
8.3.1.2.3
Errores-abstractos
El cuadro 19/X.411 enumera los errores-abstractos que pueden interrumpir la operación-abstracta entrega-informe, y para cada error-abstracto identifica el punto donde se define el error-abstracto.
Cuadro 19/X.411 [T19.411], p.
8.3.1.3
Control-entrega
La operación-abstracta control-entrega permite al usuario-STRM limitar de forma transitoria las operaciones abstractas de puerto-entrega que puede invocar el STRM, y los mensajes que puede entregar el usuario-STRM a través de la operación-abstracta entrega-mensaje.
El STRM debe retener hasta un tiempo posterior, en vez de abandonar, las operaciones-abstractas y los mensajes prohibidos.
La ejecución satisfactoria de la operación-abstracta significa que los controles especificados están actualmente en vigor. Estos controles sobreseen cualquier otro previamente en vigor, y permanecen vigentes hasta que se libera la asociación, el usuario-STRM invoca la operación-abstracta de registro en el puerto-administración para imponer limitaciones más rigurosas que los controles especificados.
La operación-abstracta devuelve una indicación de cualquier operación-abstracta que invocara el STRM, o cualquier tipo de mensaje que entregaría o sobre el que informaría el STRM, a no ser por los controles que prevalecen.
8.3.1.3.1
Argumentos
El cuadro 20/X.411 enumera los argumentos de la operación-abstracta control-entrega y para cada argumento califica la presencia e identifica el punto donde se define el argumento.
8.3.1.3.1.1
Limitación
Este argumento indica si los controles sobre las operaciones de puerta-entrega deben actualizarse o suprimirse. Puede generarse por el usuario-STRM.
Este argumento puede tener uno de los siguientes valores:
-
actualización
: los demás argumentos actualizan los
controles que prevalecen;
-
supresión
: todos los controles deben suprimirse (se
aplicarán los controles por defecto registrados con el STRM mediante la
operación-abstracta de registro del puerto-administración); los demás
argumentos deben ignorarse.
En ausencia de este argumento, se supondrá por defecto el valor
actualización
.
Cuadro 20/X.411 [T20.411], p.
8.3.1.3.1.2
Operaciones-admisibles
Este argumento indica las operaciones-abstractas que el STRM puede invocar sobre el usuario-STRM. Puede generarse por el usuario-STRM.
Este argumento puede tener el valor
autorizado
o
prohibido
para cada uno de los siguientes:
-
entrega-mensaje
: el STRM puede»no puede invocar la
operación-abstracta de entrega-mensaje; y
-
entrega-informe
: el STRM puede/no puede invocar la
operación-abstracta de entrega-informe.
Otras operaciones-abstractas de puerta-entrega no están sujetas a controles, y pueden invocarse en cualquier momento.
En ausencia de este argumento, las operaciones-abstractas que puede invocar el STRM permanecen sin modificaciones. Si no ha existido ninguna invocación previa de la operación-abstracta control-entrega en la asociación, se aplicará el control por defecto registrado con el STRM mediante la operación-abstracta de registro en el puerto-administración.
8.3.1.3.1.3
Prioridad-inferior-admisible
Este argumento contiene la
prioridad
del mensaje de
prioridad más baja que el STRM debe remitir al usuario-STRM a través de la
operación-abstracta entrega-mensaje. Puede generarse por el usuario-STRM.
Este argumento puede tener uno de los siguientes valores del argumento de
prioridad
de la operación-abstracta de entrega-mensaje:
normal
,
no-urgente
o
urgente
.
En ausencia de este argumento, la
prioridad
del mensaje
de inferior prioridad que debe entregar el STRM al usuario-STRM permanece sin
modificar. Si no ha existido ninguna invocación previa de la
operación-abstracta control-entrega en la asociación, se debe aplicar el
control por defecto registrado con el STRM mediante la operación-abstracta
registro del puerto-administración.
8.3.1.3.1.4
Tipos-información-codificada-admisibles
Este argumento indica los
tipos-información-codificada
,
que deben aparecer en los mensajes que el STRM entregará al usuario-STRM a
través de la operación-abstracta entrega-mensaje. Puede generarse por el
usuario-STRM.
Los
tipos-información-codificada-admisibles
especificados deben estar entre los autorizados a largo plazo debido a la
invocación previa de la operación-abstracta de registro en el
puerto-administración
(
tipos-información-codificada-entregables
).
En ausencia de este argumento, los
tipos-información-codificada-admisibles
de un mensaje que el
STRM puede entregar al usuario-STRM permanecen sin modificar. Si no ha existido
ninguna invocación previa de la operación-abstracta control-entrega en la
asociación, se debe aplicar el control por defecto registrado con el STRM
mediante la operación-abstracta de registro del puerto-administración.
8.3.1.3.1.5
Tipos-contenido-admisibles
Este argumento contiene los
tipos-contenido
, que deben
aparecer en el mensaje que el STRM debe entregar al usuario-STRM a través de la
operación-abstracta entrega-mensaje. Puede generarse por el usuario-STRM.
Los
tipos-contenido-admisibles
especificados deben estar
entre los autorizados a largo plazo debido a la invocación previa de la
operación-abstracta de registro en el puerto-administración
(
tipos-contenido-entregables
).
En ausencia de este argumento, los
tipos-contenido-admisibles
de un mensaje que el STRM puede
entregar al usuario-STRM permanecen sin modificar. Si no ha existido ninguna
invocación previa de la operación-abstracta control-entrega en la asociación,
se aplicará por defecto el control registrado con el STRM mediante la
operación-abstracta de registro del puerto-administración.
8.3.1.3.1.6
Longitud-contenido-máxima-admisible
Este argumento contiene la
longitud-contenido
, en
octetos, del mensaje de contenido más largo que el STRM debe remitir al
usuario-STRM a través de la operación-abstracta entrega-mensaje. Puede
generarse por el usuario-STRM.
La
longitud-contenido-máxima-admisible
no debe exceder
la autorizada a largo plazo debido a la invocación previa de la
operación-abstracta de registro en el puerto-administración
(
longitud-contenido-máxima-entregable
).
En ausencia de este argumento, la
longitud-contenido-máxima-admisible
de un mensaje que el
STRM puede entregar al usuario-STRM permanece sin modificar. Si no ha existido
ninguna invocación previa de la operación-abstracta control-entrega en la
asociación, se aplicará por defecto el control registrado con el STRM mediante
la operación-abstracta de registro del puerto-administración.
8.3.1.3.1.7
Contexto-seguridad-admisible
Este argumento limita de forma transitoria la sensibilidad de las
operaciones-abstractas de puerto-entrega (contexto-seguridad-entrega) que el
STRM puede invocar en el usuario-STRM. Es una limitación temporal del
contexto-seguridad
establecido al iniciarse la asociación
(véase el
8.1.1.1.1.4
). Puede generarse por el usuario-STRM.
El
contexto-seguridad-admisible
consta de una o más
etiquetas-seguridad
del conjunto de
etiquetas-seguridad
establecidas como
contexto-seguridad
al establecerse la asociación.
En ausencia de este argumento, el
contexto-seguridad
de
las operaciones-abstractas de puerto-entrega permanece sin modificar.
8.3.1.3.2
Resultados
El cuadro 21/X.411 enumera los resultados de la operación-abstracta control-entrega, y para cada resultado califica su presencia e identifica el punto donde se define el resultado.
Cuadro 21/X.411 [T21.411], p.
8.3.1.3.2.1
Operaciones-esperando
Este resultado indica las operaciones-abstractas que retiene el STRM y que el STRM invocaría en el usuario-STRM si no fuera por los controles que prevalecen. Puede generarse por el STRM.
Este resultado puede tener el valor
reteniendo
o
no-reteniendo
para cada uno de los siguientes:
-
entrega-mensaje
: el STRM está/no está reteniendo
mensajes, e invocaría la operación abstracta de entrega-mensaje en el
usuario-STRM si no fuera por los controles que prevalecen; y
-
entrega-informe
: el STRM está/no está reteniendo
informes, e invocaría la operación-abstracta de entrega-informe en el
usuario-STRM si no fuera por los controles que prevalecen.
En ausencia de este resultado, puede suponerse que el STRM no está reteniendo ningún mensaje ni ninguna sonda para su entrega al usuario-STRM debido a los controles que prevalecen.
8.3.1.3.2.2
Mensajes-esperando
Este resultado indica la categoría de los mensajes que el STRM está reteniendo para su remisión al usuario-STRM, y que remitiría a través de la operación-abstracta entrega-mensaje, si no fuera por los controles que prevalecen.
Este resultado puede adoptar uno de los siguientes valores:
-
contenido-largo
: el STRM ha retenido mensajes para su
entrega al usuario-STRM que exceden el control
longitud-contenido-máxima-admisible
actualmente en vigor;
-
baja-prioridad
: el STRM ha retenido mensajes para su
entrega al usuario-STRM de una prioridad inferior al control de
prioridad-inferior-admisible
actualmente en vigor;
-
otras-etiquetas-seguridad
: el STRM ha retenido mensajes
para su entrega al usuario-STRM que transportan
etiquetas-seguridad-mensaje
diferentes de las permitidas por
el contexto-seguridad actual.
En ausencia de este resultado, puede suponerse que el STRM no está
reteniendo ningún mensaje ni ninguna sonda para su entrega al usuario-STRM
debido a los controles de
longitud-contenido-máxima-admisible
,
prioridad-inferior-admisible
o
contexto-seguridad-admisible
actualmente en vigor.
8.3.1.3.2.3
Tipos-información-codificada-esperando
Este resultado indica los
tipos-información-codificada
del
contenido
de cualquier mensaje retenido por el STRM para
su entrega al usuario-STRM debido a los controles que prevalecen. Puede
generarse por el STRM.
En ausencia de este resultado, los
tipos-información-codificada
de cualquier mensaje retenido
por el STRM para su entrega al usuario-STRM estarán
sin-especificar
.
8.3.1.3.2.4
Tipos-contenido-esperando
Este resultado indica los
tipos-contenido
de cualquier
mensaje retenido por el STRM para su entrega al usuario-STRM debido a los
controles que prevalecen. Puede generarse por el STRM.
En ausencia de este resultado, los
tipos-contenido
de
cualquier mensaje retenido por el STRM para su entrega al usuario-STRM estarán
sin-especificar
.
8.3.1.3.3
Errores-abstractos
El cuadro 22/X.411 enumera los errores-abstractos que pueden interrumpir la operación-abstracta control-entrega, y para cada error-abstracto identifica el punto donde se define el error-abstracto.
Cuadro 22/X.411 [T22.411], p.
8.3.2
Errores-abstractos
En este punto se definen los siguientes errores-abstractos de puerto-entrega:
a)control-entrega-violado
b)control-viola-registro
c)error-seguridad
d)función-crítica-no-admitida.
8.3.2.1
Control-entrega-violado
El error-abstracto de control-entrega-violado informa de la violación por el STRM de un control sobre las operaciones-abstractas de puerto-entrega impuestas por el usuario-STRM a través de la operación-abstracta de control-entrega.
El error-abstracto de control-entrega-violado no tiene parámetros.
8.3.2.2
Control-viola-registro
El error-abstracto control-viola-registro informa que el STRM no puede aceptar el control que el usuario-STRM intenta imponer sobre las operaciones-abstractas porque violan los parámetros de registro existentes.
El error-abstracto control-viola-registro no tiene parámetros.
8.3.2.3
Error-seguridad
El error-abstracto error-seguridad informa que la operación-abstracta pedida no puede ser proporcionada por el usuario-STRM porque se violaría la política-seguridad en vigor.
El error-abstracto error-seguridad tiene los siguientes parámetros, generados por el usuario-STRM:
-
problema-seguridad
: identificador relativo a la causa de
violación de la política-seguridad.
8.3.2.4
Función-crítica-no-admitida
El error-abstracto función-crítica-no-admitida informa que un argumento de
la operación-abstracta ha sido marcado como
crítico-para-entrega
(véase el
9.1
) pero que no
está admitido por el usuario-STRM.
El error-abstracto función-crítica-no-admitida no tiene parámetros.
8.4
Puerto de administración
En este punto se definen las operaciones-abstractas y los errores-abstractos que ocurren en un puerto-admiración.
8.4.1
Operaciones-abstractas
En este punto se definen las siguientes operaciones-abstractas de puerto-administración:
a)registro
b)cambio-credenciales.
8.4.1.1
Registro
La operación-abstracta registro permite a un usuario-STRM realizar cambios a largo-plazo en varios parámetros del usuario-STRM retenido por el STRM afectado por la entrega de mensajes al usuario-STRM.
Dichos cambios permanecen vigentes hasta ser superados por la nueva invocación de la operación-abstracta de registro. Sin embargo, algunos parámetros pueden ser transitoriamente reemplazados mediante la invocación de la operación-abstracta control-entrega.
Nota 1
- Esta operación-abstracta debe ser invocada
antes de que pueda utilizarse cualquier otro puerto-remisión, puerto-entrega u
operación-abstracta de puerto-administración o habrá tenido lugar un registro
equivalente localmente.
Nota 2
- Esta operación-abstracta no incluye los
parámetros existentes involucrados por el elemento-de-servicio destinatario
alternativo autorizado y el elemento-de-servicio entrega-restringida definido
en la Recomendación X.400. La forma en que se suministran y modifican dichos
parámetros es asunto local.
8.4.1.1.1
Argumentos
El cuadro 23/X.411 enumera los argumentos de la operación-abstracta registro y para cada argumento califica la presencia e identifica el punto donde se define el argumento.
Tableau 23/X.411 [T23.411], p
8.4.1.1.1.1
Nombre-usuario
Este argumento contiene el
nombre-O/D
del usuario-STRM,
si ha de cambiarse el
nombre-usuario
. Puede ser generado por
el usuario-STRM.
En ausencia de este argumento, el
nombre-usuario
del
usuario-STRM permanece sin modificar.
Un DG no está obligado a proporcionar a los usuarios-STRM la posibilidad de
modificar sus
nombres--O/D
. Si así lo hace, el DG puede
limitar esa posibilidad. Puede prohibir a ciertos usuarios-STRM cambiar sus
nombres-O/D
, o puede limitar el ámbito del cambio a un
subconjunto definido localmente de los componentes de sus
nombres-O/D
. Un nuevo
nombre-O/D
propuesto será rechazado si ya está asignado a otro usuario-STRM.
8.4.1.1.1.2
Dirección-usuario
Este argumento contiene la
dirección-usuario
del
usuario-STRM, si éste la solicita o si se ha de modificar. Puede ser generado
por el usuario-STRM.
La
dirección-usuario
puede contener una de las
siguientes formas de dirección del usuario-STRM:
-la
dirección-X.121
y/o el
ID-PAST
(identificador del punto de acceso del servicio de transporte); o
-la
dirección-DASP
(dirección del punto de acceso del
servicio de presentación).
En las futuras versiones de esta Recomendación pueden definirse otras
formas de
dirección-usuario
.
En ausencia de este argumento, la
dirección-usuario
del
usuario-STRM (si existe) permanece sin modificar.
8.4.1.1.1.3
Tipos-información-codificada-entregables
Este argumento indica los
tipos-información-codificada
que el STRM permitirá que aparezcan en los mensajes entregados al usuario-STRM,
si éstos deben modificarse. Pueden ser generados por el usuario-STRM.
El STRM debe rechazar como inentegrable cualquier mensaje para un
usuario-STRM que no esté registrado para aceptar la entrega de todos los
tipos-información-codificada
del mensaje. Obsérvese que el
usuario-STRM puede registrarse para recibir el
tipo-información-codificada indefinido
. Los tipos
información-codificada-entregables indican también los posibles
tipos-información-codificada hacia los que puede realizarse conversión
implícita.
En ausencia de este argumento, los
tipos-información-codificada-entregable
permanecerán sin
modificar.
8.4.1.1.1.4
Tipos-contenido-entregables
Este argumento indica los
tipos-contenido
que el STRM
debe permitir que aparezcan en los mensajes entregados al usuario-STRM, si han
de modificarse. Puede ser generado por el usuario-STRM.
El STRM debe rechazar como inentregable cualquier mensaje para un
usuario-STRM que no esté registrado para aceptar la entrega de los
tipos-contenido
del mensaje. Obsérvese que el usuario-STRM
puede registrarse para recibir el
tipo-contenido indefinido
.
En ausencia de este argumento, los
tipos-contenido-entregables
deben permanecer sin modificar.
8.4.1.1.1.5
Longitud-máxima-contenido-entregable
Este argumento contiene la
longitud-contenido
, en
octetos, del mensaje de contenido más largo que el STRM debe permitir que
aparezca en los mensajes entregados al usuario-STRM, si han de modificarse.
Puede ser generado por el usuario-STRM.
El STRM deberá rechazar como imposible de entregar, cualquier mensaje para un usuario-STRM que no esté registrado para aceptar la entrega de mensajes de este tamaño.
En ausencia de este argumento, la longitud
máxima-contenido-entregable
del mensaje debe permanecer sin
modificar.
8.4.1.1.1.6
Destinatario-alternativo-asignado-destinatario
Este argumento contiene el
nombre-O/D
de un
destinatario-alternativo, especificado por el usuario-STRM al que deben
redirigirse los mensajes, si debe modificarse el destinatario-alternativo.
Puede ser generado por el usuario-STRM. Puede especificarse un valor diferente
de este argumento para cada valor de las
etiquetas-seguridad-usuario
.
Si se registra un
destinatario-alternativo-asignado-destinatario
y se asocia
con un valor de las
etiquetas-seguridad-usuario
, los
mensajes que transporten una
etiqueta-seguridad-mensaje
acorde se deben redirigir al destinatario. Los mensajes que transportan una
etiqueta-seguridad-mensaje
para la cual no se ha registrado
ningún
destinatario-alternativo-asignado-destinatario
, no se
deben redirigir a un
destinatario-alternativo-asignado-destinatario
.
Si se registra un
destinatario-alternativo-asignado-destinatario
único, y no
se le asocia un valor de
etiquetas-seguridad-usuario
, se
deben redirigir todos los mensajes al destinatario-alternativo.
El
destinatario-alternativo-asignado-destinatario
deberá
contener el
nombre-O/D
del destinatario-alternativo. Si el
destinatario-alternativo-asignado-destinatario
contiene el
nombre-O/D
del usuario-STRM (véase el
8.4.1.1.1.1
) no se registra ningún
destinatario-alternativo-asignado-destinatario
.
En ausencia de este argumento el
destinatario-alternativo-asignado-destinatario
, si lo
hubiere, permanece sin modificar.
8.4.1.1.1.7
Eiquetas-seguridad-usuario
Este argumento contiene las
etiquetas-seguridad
del
usuario-STRM, si han de modificarse. Puede ser generado por el usuario-STRM.
Puede registrarse un
destinatario-alternativo-asignado-destinatario
para
cualquier valor de las
etiquetas-seguridad-usuario
.
En ausencia de este argumento, las
etiquetas-seguridad-usuario
permanecen sin modificar.
Obsérvese que algunas políticas-seguridad puede que permitan únicamente
modificar las
etiquetas-seguridad-usuario
de esta forma sí
se utiliza un enlace seguro. Pueden proporcionarse otros medios locales de
modificar las
etiquetas-seguridad-usuario
de forma segura.
8.4.1.1.1.8
Argumentos de control de entrega por
defecto
Los argumentos de control por defecto son los mismos que los argumentos de
la operación-abstracta control-entrega, definidos en el
8.3.1.3.1
.
Excepto para
contexto-seguridad-admisible
, pueden ser
generados por el usuario-STRM.
Se registran los controles por defecto como argumentos de la operación-abstracta abstracta de registro. Estas actuaciones por defecto entran en vigor al comienzo de una asociación, y permanecen vigentes hasta que son suspendidas por una invocación de la operación-abstracta de control-entrega.
Los argumentos de control por defecto no deben admitir mensajes cuya
entrega esté prohibida por los valores registrados prevalecientes del argumento
tipos-información-codificada-entregables
, del argumento
tipos-contenido-entregables
o del argumento
longitud-máxima-contenido-entregable
.
8.4.1.1.2
Resultados
La operación-abstracta registro devuelve un resultado vacío como indicación del éxito.
8.4.1.1.3
Errores-abstractos
El cuadro 24/X.411 enumera los errores-abstractos que pueden interrumpir la operación-abstracta de registro y para cada error-abstracto identifica el punto donde se define el error abstracto.
Tableau 24/X.411 [T25.411], p.
8.4.1.2
Cambio-credenciales
La operación-abstracta cambio-credenciales permite al usuario-STRM
modificar las
credenciales
del usuario-STRM en poder del
STRM, o permite al STRM modificar las
credenciales
del STRM
en poder del usuario-STRM.
Durante el establecimiento de una asociación se intercambian las
credenciales
para la autenticación mutua de la identidad del
usuario-STRM y del STRM.
La finalización con éxito de la operación-abstracta significa que se han
cambiado las
credenciales
.
La interrupción de la operación-abstracta por un error-abstracto indica que
no se han cambiado las
credenciales
, bien porque las
antiguas
credenciales
estaban incorrectamente especificadas
o porque las nuevas
credenciales
resultan inaceptables.
8.4.1.2.1
Argumentos
El cuadro 25/X.411 enumera los argumentos de la operación-abstracta-credenciales y para cada argumento califica la presencia e identifica el punto donde se define el argumento.
Tableau 25/X.411 [T25.411], p.
8.4.1.2.1.1
Credenciales-antiguas
Este argumento contiene las
credenciales
vigentes
(antiguas) del invocador de la operación-abstracta en poder del ejecutor de la
operación-abstracta. Debe ser generado por el invocador de la
operación-abstracta.
Si se utiliza únicamente una autenticación-simple, las
credenciales
incluyen una
contraseña
simple asociada al
nombre-usuario
, o al
nombre-ATM
del invocador.
Si se utiliza una autenticación-fuerte, las
credenciales
incluyen el
certificado
del invocador, generado por una
fuente de confianza (por ejemplo, autoridad-certificación), y proporcionado por
el invocador.
8.4.1.2.1.2
Credenciales-nuevas
Este argumento contiene las
credenciales-nuevas
propuestas del invocador de la operación-abstracta que debe poseer el ejecutor
de la operación-abstracta. Debe ser generado por el invocador de la
operación-abstracta.
Las
credenciales-nuevas
deben ser del mismo tipo (simple
o fuerte) que las
credenciales-antiguas
, definidas en el
8.4.1.2.1.1
.
8.4.1.2.2
Resultados
La operación-abstracta cambio-credenciales devuelve un resultado vacío como indicación del éxito.
8.4.1.2.3
Errores-abstractos
El cuadro 26/X.411 enumera los errores-abstractos que pueden interrumpir la operación-abstracta de cambio credenciales y para cada error-abstracto identifica el punto donde se define el error abstracto.
Tableau 26/X.411 [T26.411], p.
8.4.2
Errores-abstractos
En este punto, se definen los siguientes errores-abstractos del puerto-administración:
a)registro-rechazado
b)credenciales-nuevas-inaceptables
c)credenciales-antiguas-incorrectamente-especificadas.
8.4.2.1
Registro-rechazado
El error-abstracto registro-rechazado notifica que no pueden registrarse los parámetros pedidos porque uno o más están indebidamente especificados.
El error-abstracto registro-rechazado no tiene parámetros.
8.4.2.2
Credenciales-nuevas-inaceptables
El error-abstracto credenciales-nuevas-inaceptables notifica que no pueden
cambiarse las
credenciales
porque las
credenciales-nuevas
son inaceptables.
El error-abstracto credenciales-nuevas-inaceptables no tiene parámetros.
8.4.2.3
Credenciales-nuevas-incorrectamente-especificadas
El error-abstracto credenciales-antiguas-incorrectamente-especificadas
notifica que no pueden cambiarse las
credenciales
porque las
credenciales
(
antiguas
) vigentes están
incorrentamente especificadas.
El error-abstracto-credenciales-antiguas-incorrectamente-especificadas no tiene parámetros.
8.5
Tipos comunes de parámetros
En este punto se define un cierto número de tipos comunes de parámetros del servicio abstracto STRM.
8.5.1
Identificador-STRM
El STRM asigna
identificadores-STRM
para distinguir
entre los mensajes y sondas del servicio abstracto STRM y entre los mensajes,
sondas e informes dentro del STRM.
El
identificador-STRM
asignado a un mensaje en un
puerto-remisión (
identificador-remisión-mensaje
) es idéntico
al
identificador-mensaje
correspondiente en un
puerto-transferencia y al correspondiente
identificador-entrega-mensaje
en un puerto de entrega. De
forma similar, el
identificador-STRM
asignado a una sonda en
un puerto-remisión (
identificador-remisión-sonda
) es
idéntico al
identificador-sonda
correspondiente en un
puerto-transferencia. Se asignan igualmente
identificadores-STRM
a los informes en los
puertos-transferencias (
identificador-informe
).
Un
identificador-STRM
consta de:
-un
identificador-local
asignado por el ATM, que
identifica sin ambigüedad el suceso en cuestión dentro del DG:
-el
identificador-dominio-global
del DG, que garantiza
que el
identificador-STRM
es inequívoco a lo largo del STRM.
8.5.2
Identificador-dominio-global
Un
identificador-dominio-global
identifica
inequívocamente un DG en el interior del STM.
Se utiliza un
identificador-dominio-global
para
garantizar que un
identificador-STRM
no resulta ambiguo a lo
largo del STRM y para identificar la fuente de un
elemento-información-rastreo
.
En el caso de un DGAD, un
identificador-dominio-global
consta del
nombre-país
y del
nombre-dominio-administración
del DG. Para un DGPR, consta
del
nombre-país
y del
nombre-dominio-administración
del DGAD asociado, más un
identificador-dominio-privado
. El
identificador-dominio-privado
es una identificación única
del DGPR y puede ser idéntico al
nombre-dominio-privado
del
DGPR. Como un asunto nacional, esta identificación puede ser relativa al país
designado por el
nombre-país
o relativa al DGAD asociado.
Nota 1
- La distinción entre el
identificador-dominio-privado
y el
nombre-dominio-privado
se ha conservado para asegurar la
compatibilidad con la Recomendación X.411 (1984). A menudo serán idénticos.
Nota 2
- En la publicación ISO/CEI 10021-4, en el
identificador-dominio-global
de un DGPR, el
nombre-dominio-administración
del DGAD asociado es optativo.
8.5.3
Nombre-ATM
Un
nombre-ATM
es un identificador para un ATM que
identifica unívocamente al ATM dentro del DG al que pertenece.
8.5.4
Tiempo
Se especifica un parámetro
tiempo
en términos del TUC
(tiempo universal coordinado) y puede contener igualmente de forma opcional una
desviación respecto del TUC para incorporar el tiempo local. La precisión de la
hora del día es de un segundo o de un minuto según determine el generador del
parámetro.
8.5.5
Nombre-O/D
Un
nombre-O/D
identifica al originador o destinatario de
un mensaje según los principios de denominación y direccionamiento descritos en
la Recomendación X.402.
En un puerto-remisión, un
nombre-O/D
consta de una
dirección-O/D
, o un
nombre-guía
o ambos
(
dirección-O/D-y-o-nombre-guía
). En todos los tipos de
puerto restantes, un
nombre-O/D
consta de una
dirección-O/D
y, opcionalmente, un
nombre-guía
(
dirección-O/D-y-nombre-guía-facultativo
). Un
nombre-guía
y una
dirección-O/D
pueden
denominar cada uno un originador o un destinatario individual o una LD.
En la Recomendación X.501 se define un
nombre-guía
. El
STRM utiliza el
nombre-guía
únicamente cuando está ausente o
es inválida la
dirección-O/D
.
Una
dirección-O/D
consta de un cierto número de
atributos-normales
, opcionalmente de un cierto número de
atributos-ampliación
, y opcionalmente de un cierto número de
atributos definidos por el DG al cual está suscrito el originador»destinatario
(
atributos-definidos-dominio
).
Los
atributos-normales
y -
ampliación
utilizados en una
dirección-O/D
se seleccionan a partir de
los definidos en la Recomendación X.402. Unicamente pueden utilizarse estas
combinaciones de atributos explícitamente definidos en la Recomendación X.402
para formar una
dirección-O/D
válida.
8.5.6
Tipos-información-codificada
Los
tipos-información-codificada
de un mensaje
representan el tipo o tipos de información que aparecen en su
contenido
. Pueden especificarse tanto los
tipos-información-codificada
básicos como los
tipos-información-codificada
definidos externamente, en caso
contrario los
tipos-información-codificada
de un mensaje
están
sin-especificar
.
Los
tipos-información-codificada
definidos externamente
son aquellos a los que una autoridad competente atribuye
identificadores-objetos. Estos incluyen los
tipos-información-codificada
tanto normalizados como
definidos-privadamente.
Los
tipos-información-codificada
básicos son aquellos
especificados originalmente en la Recomendación X.411 (1984). El tipo
indefinido
es cualquier tipo distinto de los
tipos-información-codificada
definidos-externamente
especificados y diferentes de los tipos siguientes. El tipo
télex
se define en la Recomendación F.1. El tipo
texto-ai5
(teleimpresor) se define en la Recomendación T.50.
El tipo
facsímil-g3
se define en las Recomendaciones T.4 y
T.30. El tipo
clase-1-g4
se define en las Recomendaciones
T.5, T.6, T.400 y T.503. El tipo
teletex
se define en las
Recomendaciones F.200, T.61 y T.60. El tipo
videotex
se
define en las Recomendaciones T.100 y T.101. El tipo
documento-formatizable-simple (dfs)
se define en la
Recomendación X.420 (1984) (obsérvese que los DFS ya no se definen en ninguna
Recomendación de 1988). El tipo
modo mixto
se define en las
Recomendaciones T.400 y T.501.
Se definen
parámetros-no-básicos
para el
facsímil-g3
,
teletex
,
g4-clase-1
, y
modo mixto
, los
tipos-información-codificada
para compatibilidad regresiva
con la Recomendación X.411 únicamente. Se recomienda que para cada combinación
requerida de un
tipo-información-codificada
básica y un
conjunto específico de
parámetros-no-básicos
, se defina y
utilice de preferencia un
tipo-información-codificada
definida-externamente.
Obsérvese que es probable que se supriman los
parámetros-no-básicos
en una futura versión de esta
Recomendación.
Los
parámetros-no-básicos
para
facsímil-g3
corresponden a los campos de información
facsímil (CIF) de tres -o cuatro- octetos transportados por la señal de
instrucción digital (SID) definidos en T.30. Los parámetros son
bi-dimensional
,
resolución-fina
,
longitud-ilimitada
,
longitud-b4
,
anchura-a3
,
anchura-b4
y
sin-comprensión
.
Los
parámetros-no-básicos
para
teletex
corresponden a la capacidad terminal no-básica
transportada por la instrucción de comienzo de documento (ICD) definida en la
Recomendación T.62. Los parámetros son:
conjuntos-caracteres-gráficos
,
conjuntos-caracteres-control
,
formatos-páginas
opcionales,
capacidades-terminal-misceláneas
facultativas, y un
parámetro de
uso-privado
.
Los
parámetros-no-básicos
para los tipos de
clase-1-g4
y
modo-mixto
especifican la
resolución opcional, los conjuntos de caracteres gráficos opcionales, los
conjuntos de caracteres de control opcionales, y así sucesivamente, que
corresponden a los parámetros de las
capacidades-presentación
definidos en las Recomendaciones
T.400, y T.503 y T.501.
Cuando se indican
parámetros-no-básicos
, estos
parámetros representan el
`O'
lógico de los
parámetros-no-básicos
de cada ejemplo de
tipo-información-codificada
en un
contenido
de mensaje. Así, este parámetro sirve únicamente
para indicar si existe compatibilidad de
tipo-información-codificada
, o si se requiere conversión. Si
se requiere conversión, se inspeccionará el
contenido
del
mensaje para determinar que
parámetros-no-básicos
se aplican
a cualquier ejemplo de
tipo-información-codificada
.
8.5.7
Certificado
Puede utilizarse un
certificado
para transportar una
copia verificada de la clave-cifrado-pública-asimétrica del sujeto del
certificado
.
Un
certificado
consta de los siguientes parámetros:
-
identificador-algoritmo-firma
:
algoritmo-identificador
para el algoritmo utilizado por la
autoridad-certificación que expidió el
certificado
para
calcular la firma;
-
expedidor
:
nombre-guía
de la
autoridad-certificación que expidió el
certificado
;
-
validez
: fecha y hora del día antes de las cuales no
debería utilizarse el
certificado
, y fecha y hora del día
después de las cuales no debería confiarse en el
certificado
;
-
sujeto
:
nombre-guía
del sujeto del
certificado
;
-
claves-públicas-sujeto
: una o más
claves-cifrado-públicas-asimétricas del sujeto (cada una utilizada junto con un
algoritmo
y una clave-cifrado-secreta-asimétrica del
sujeto);
-
algoritmos
: uno o más
identificadores-algoritmo
, cada uno asociado con una
clave-pública-sujeto
;
-
firma
: versión asimétricamente cifrada, desmenuzada de
los anteriores parámetros calculada por la autoridad-certificación que expidió
el
certificado
utilizando el algoritmo identificado por el
identificador-algoritmo-firma
y la
clave-cifrado-secreta-asimétrica de la autoridad-certificación.
Si el originador y un destinatario de un
certificado
se
sirven de la misma autoridad-certificación, el destinatario puede utilizar la
clave-cifrado-pública-asimétrica de la autoridad-certificación para validar el
certificado
y deducir la clave-cifrado-pública-asimétrica
del originador (
clave-pública-sujeto
).
Si el originador y un destinatario de un
certificado
se
sirven de autoridades-certificación diferentes, el destinatario puede necesitar
un trayecto-retorno-certificación para autenticar el
certificado
del originador. Por lo tanto, el
certificado
puede incluir un
trayecto-certificación
asociado.
El
trayecto-certificación
puede incluir un
trayecto-certificación-hacia-adelante
que incorpora el
certificado de la autoridad-certificación que expidió el
certificado
junto con los certificados de todas sus
autoridades-certificación superiores. El
trayecto-certificación-hacia-adelante
puede incluir
igualmente los certificados de otras autoridades-certificación, con
certificación recíproca por la autoridad-certificación que expidió el
certificado
o por cualquier otra de sus
autoridades-certificación superiores.
Un destinatario del
certificado
puede completar el
trayecto-retorno-certificación requerido entre el destinatario y el originador
del
certificado
añadiendo un trayecto-certificación-inverso
propio del destinatario al
trayecto-certificación-hacia-adelante
suministrado por el
originador en un punto-común-de-confianza. El trayecto-certificación-inverso
incluye el certificado-inverso de la autoridad-certificación del destinatario
del
certificado
, junto con los certificados-inversos de
todas sus autoridades de certificación superiores. El
trayecto-certificación-inverso puede incluir igualmente los
certificados-inversos de otras autoridades-certificación con certificación
recíproca por la autoridad-certificación del destinatario del
certificado
, o cualquiera de sus autoridades de
certificación superiores.
El trayecto-retorno-certificación así formado permite al destinatario del
certificado validar cada
certificado
en el
trayecto-retorno-certificación, para deducir la
clave-cifrado-pública-asimétrica de la autoridad-certificación que expidió el
certificado
. El destinatario puede entonces utilizar la
clave-cifrado-pública-asimétrica de la autoridad de certificación que expidió
el
certificado
para validar el
certificado
y deducir la clave-cifrado-pública-asimétrica
del originador (
clave-pública-sujeto
).
La forma de un
certificado
y de un
trayecto-certificación
se definen posteriormente en la
Recomendación X.509.
Futuras versiones de esta Recomendación pueden definir otras técnicas de distribución de claves (por ejemplo, basadas en técnicas-cifrado-simétricas).
8.5.8
Testigo
Puede utilizarse un
testigo
para transportar al
destinatario del
testigo
, información relativa-seguridad
protegida. El
testigo
proporciona la autenticación de la
información relativa-seguridad pública, y la confidencialidad y autenticación
de la información relativa-seguridad secreta.
El tipo de
testigo
se identifica mediante un
identificador-tipo-distintivo
. Esta Recomendación define un
tipo de
testigo
: el
testigo-asimétrico
.
Futuras versiones de esta Recomendación pueden definir otros tipos de
testigo
; por ejemplo,
testigo
basados en
las técnicas de cifrado-simétrica.
Un
testigo-asimétrico
contiene los siguientes
parámetros:
-
identificador-algoritmo-firma
:
algoritmo-identificador
para el algoritmo utilizado por el
originador del
testigo
para calcular la
firma
;
-
nombre-destinatario
: el
nombre-dirección-O/D-y/o-nombre-guía
del
destinatario-deseado del
testigo
;
-
tiempo
: fecha y hora del día en que se generó el
testigo
;
-
datos-firmados
: información relativa-seguridad pública;
-
identificador-algoritmo-cifrado
:
identificador-algoritmo
para el algoritmo utilizado por el
originador del
testigo
para calcular los
datos-cifrados
;
-
datos-cifrados
: información relativa-seguridad secreta
cifrada por el originador del
testigo
utilizando el
algoritmo identificado por el
identificador-algoritmo-cifrada
y la
clave-cifrada-pública-asimétrica del destinatario-pretendido del
testigo
;
-
firma
: versión
cifrada
asimétricamente desmenuzada de los parámetros anteriores calculada por el
originador del
testigo
utilizando el algoritmo identificado
por el
identificador-algoritmo-firma
y la
clave-cifrada-asimétrica-secreta del originador.
La forma de un
testigo
se define posteriormente en la
Recomendación X.509.
8.5.9
Etiqueta-seguridad
Pueden utilizarse las
etiquetas-seguridad
para asociar
la información relativa-seguridad con los objetos dentro del STRM.
Pueden asignarse
etiquetas-seguridad
a un objeto en
línea con la política-seguridad en vigor para dicho objeto. La
política-seguridad puede definir igualmente como deben utilizarse las
etiquetas-seguridad
para reforzar la política-seguridad.
Dentro del campo de aplicación de esta Recomendación, pueden asociarse
etiquetas-seguridad
a los mensajes, las sondas, y los
informes (véase el
8.2.1.1.1.30
), los usuarios-STRM (véase el
8.4.1.1.1.7
), los DG, los ATM y asociaciones entre un usuario-STRM y
un DG (o ATM) (véase el
8.1.1.1.1.4
) o entre DG (o ATM) (véase el
12.1.1.1.1.4
). Más allá del campo de aplicación de esta
Recomendación, una política-seguridad puede, como asunto local o mediante un
acuerdo bilateral, asignar adicionalmente
etiquetas-seguridad
a otros objetos dentro del STRM (por
ejemplo, rutas seguras).
Una
etiqueta-seguridad
comprende un conjunto de
atributos-seguridad
. Los
atributos-seguridad
pueden incluir un
identificador-política-seguridad
, una
clasificación-seguridad
, una
marca de
privacidad
, y un conjunto de
categorías-seguridad
.
Puede utilizarse un
identificador-política-seguridad
para identificar la política-seguridad en vigor a que se refiere la
etiqueta-seguridad
.
Si está presente, una
clasificación-seguridad
puede
tener una lista jerárquica de valores. La jerarquía básica de
clasificación-seguridad
se define en esta Recomendación pero
la utilización de estos valores se define mediante la política-seguridad en
vigor. Una política-seguridad puede definir igualmente valores adicionales de
clasificación-seguridad
y su posición en la jerarquía como
asunto local o mediante un acuerdo bilateral. La jerarquía básica de
clasificación-seguridad
es, por orden ascendente:
sin-marcar
,
sin-clasificar
,
restringido
,
confidencial
,
secreto
,
alto secreto
.
Si existe, una
marca-privacidad
es una cadena
imprimible. El contenido de la cadena imprimible puede definirse mediante una
política-seguridad, que puede definir una lista de valores a utilizar o
permitir la determinación por el originador de la
etiqueta-seguridad
de dicho valor. Ejemplos de
marcas-privacidad son
`
y
CONFIDENCIAL
'
`
.
MUY ESTRICTAMENTE CONFIDENCIAL
'
Si existe, el conjunto de
categorías-seguridad
proporciona otras restricciones dentro del contexto de una
clasificación-seguridad
y»o
marca-privacidad
típicamente sobre la base de un
`necesita-saber'
. Las
categorías-seguridad
y sus
valores pueden definirse por una política-seguridad como asunto local o
mediante un acuerdo bilateral. Los ejemplos de posibles
categorías-seguridad
incluyen escritos sobre la
clasificación-seguridad
y»o la
marca-privacidad
(por ejemplo,
`
,
PERSONAL-
'
`
,
PLANTILLA-
'
`
, etc.), grupos-cerrados-usuarios,
palabras de código, etc.
COMERCIAL-
'
8.5.10
Identificador-algoritmo
Un
identificador-algoritmo
identifica un
algoritmo
y cualesquiera
parámetros-algoritmo
requeridos por el
algoritmo
.
Un
identificador-algoritmo
puede extraerse del registro
internacional de algoritmos o definirse mediante un acuerdo bilateral.
(H.T.=NON)
TAB.???
FICHIER: H.T. =
(SANS
H.T.)
(SANS FORMULES) Tableaux: 0
(BT..) Disk ... NF../... (OPM = ..)
(87.TE.10.S)
(A1.23s) / [26s]
FOLIOS: 324 - 362 (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie disk. 586 31.08.89 PR
ID + Vérif. + diskette MAJ + laser 03.10.89 PV
Corr. LASER (1re épreuve) = 3eme 25.10.89 UT
Espaces réservés + Transfert + Impr. 30.10.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 8.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs .) ........ ..
BAT du 21/XI/89 21.11.89 PV
MAJ s/disquettes 7.12.89 CD
9
Definición de la sintaxis abstracta
del sistema de transferencia de mensajes
La sintaxis-abstracta del servicio abstracto del STRM se define en la figura 2/X.411.
La sintaxis-abstracta del servicio abstracto del STRM se define utilizando la notación de sintaxis abstracta (NSA.1) definida en la Recomendación X.208, y los convenios de definiciones del servicio abstracto definidos en la Recomendación X.407.
La definición de la sintaxis-abstracta del servicio abstracto STRM tiene las siguientes partes principales:
-
Prólogo:
^ declaraciones de las exportaciones desde el
módulo de servicio abstracto del STRM, y de las importaciones a éste (figura
2/X.411, parte 1).
-
Objetos y puertos:
^ definiciones de los objetos del
STRM y del usuario-STRM, y de sus puertos-remisión, -entrega, -administración,
(figura 2/X.411, parte 2).
-
Vinculación-STRM, y desvinculación-STRM:
^ definiciones
de las operaciones vinculación-STRM y desvinculación-STRM utilizadas para
establecer y liberar asociaciones entre un usuario-STRM y el STRM (figura
2/X.411, partes 3 y 4).
-
Puerto de remisión:
^ definiciones de las
operaciones-abstractas de puerto-remisión: remisión-mensaje, remisión-sonda,
cancelación-entrega-diferida y control-remisión; y sus errores-abstractos
(figura 2/X.411 partes 5 a 7).
-
Puerto de entrega:
^ definiciones de las
operaciones-abstractas de puerto-entrega: entrega-mensaje, entrega-informe y
control-entrega; y sus errores-abstractos (figura 2/X.411, partes 8 a 9).
-
Puerto de administración:
^ definiciones de las
operaciones-abstractas de puerto-administración: registro y
cambio-credenciales; y sus errores abstractos (figura 2/X.411, partes 10 a 11).
-
Sobre de remisión de mensaje:
^ definición del
sobre-remisión-mensaje (figura 2/X.411, parte 12).
-
Sobre de remisión de sonda:
^ definición del
sobre-remisión-sonda (figura 2/X.411, parte 13).
-
Sobre de entrega de mensaje:
^ definición del
sobre-entrega-mensaje (figura 2/X.411, parte 14).
-
Sobre de entrega de informe:
^ definición del
sobre-entrega-informe (figura 2/X.411, parte 15).
-
Campos de sobre:
^ definiciones de los campos de sobre
(figura 2/X.411, partes 16 a 19).
-
Campos de ampliación:
^ definiciones de los
campos-ampliación (figura 2/X.411, partes 20 a 28).
-
Tipos de parámetros comunes:
^ definiciones de los
tipos de parámetros comunes (figura 2/X.411, partes 29 a 41).
Nota 1
- El módulo implica ciertos cambios en el
protocolo P3 definido en la Recomendación X.411 (1984). Estos cambios se
señalan mediante
subrayado
.
Nota 2
- El módulo aplica limitaciones de tamaño a los
tipos de datos de longitud-variable utilizando la ampliación de subtipificación
SIZE de NSA.1. La violación de una restricción de tamaño constituye una
violación de protocolo.
9.1
Mecanismo de criticidad
Cada
campo-ampliación
definido en la figura 2/X.411
(partes 20 a 27) transporta consigo una indicación de su
criticidad
para remisión, transferencia y entrega. Se
concibe el mecanismo de criticidad para permitir la transparencia controlada de
funciones ampliadas. Una función no-crítica puede ignorarse o descartarse en la
entrega, pero no será descartada por un ATM retransmisor salvo cuando degrade a
un mensaje (véase el anexo B a la Recomendación X.419), mientras que una
función crítica debe conocerse y realizarse correctamente para que prosigan los
procedimientos normales.
En general, un argumento de una operación-abstracta marcado como crítico para el tipo de puerto en cuestión debe tratarse correctamente por quién ejecuta la operación-abstracta o se debe informar del error en la forma adecuada. El invocador de la operación-abstracta debe tratar correctamente todas las funciones marcadas como críticas para este tipo de puerto.
Si la operación-abstracta es de las que informan de un resultado
infructuoso, se notifica un fallo en la correcta ejecución de una función
crítica mediante la devolución de un error-abstracto de función-crítica-no-
admitida. Si la operación-abstracta no es de las que notifican un resultado
infructuoso, debe invocarse una operación-abstracta (por ejemplo, un informe)
para transportar el resultado infructuoso de la operación anterior (por
ejemplo, utilizando el
código-diagnóstico-no-entrega de
función-crítica-no-admitida
de un informe).
La ampliación que aparece en el resultado de una operación-abstracta no debe marcarse como crítica para el tipo de puerto en cuestión.
En el caso de
crítica-para-remisión
, el STRM deberá
ejecutar correctamente los procedimientos definidos para una función marcada
como
crítica-para-remisión
en una operación-abstracta de
remisión-mensaje o remisión-sonda o devolverá un error-abstracto de
función-crítica-no-admitida.
En el caso de
crítica-para-transferencia
, un ATM
receptor deberá ejecutar correctamente los procedimientos definidos para una
función en un mensaje o sonda marcado como
crítica-para-transferencia
, o deberá devolver un
informe-no-entrega con el
código-diagnóstico-no-entrega
puesto en
función-crítica-no-admitida
. Un ATM incapaz de
proporcionar una función marcada como
crítica-para-transferencia
en un informe debe descartar el
informe (obsérvese que una política o acuerdo local puede exigir que esta
acción sea auditada). Una ampliación marcada como
crítica-para-transferencia
que aparece como un argumento de
una operación de remisión-mensaje o remisión-sonda deberá aparecer sin
modificación en una operación resultante de transferencia-mensaje o
transferencia-sonda en un puerto-transferencia.
En el caso de
crítica-para-entrega
, un ATM-que-entrega
ejecutará correctamente los procedimientos definidos para una función marcada
como
crítica-para-entrega
, o no entregará el mensaje o sonda
y devolverá un informe-no-entrega con el
código-diagnóstico-no-entrega
puesto en
función-crítica-no-admitida
. Un usuario-STRM receptor
ejecutará correctamente los procedimientos definidos para una función marcada
como
crítica-para-entrega
o devolverá un error-abstracto de
función-crítica-no-admitida. Una ampliación marcada como
crítica-para-entrega
que aparece como argumento de una
operación de remisión-mensaje o remisión-sonda debe aparecer sin modificación
en una operación de transferencia-mensaje o transferencia-sonda en un
puerto-transferencia. Una ampliación marcada como
crítica-para-entrega
que aparece como argumento de una
operación de transferencia-mensaje o transferencia-sonda debe aparecer sin
modificación en cualquier operación de transferencia-mensaje o
transferencia-sonda en un puerto-transferencia.
Un ATM que genera un informe no deberá copiar las funciones críticas no
admitidas procedentes del sujeto en el informe. Al generar el informe un ATM
deberá indicar la
criticidad
(para transferencia y/o
entrega) de cualquier función admitida copiada del sujeto en el informe; la
criticidad
de una función en un informe puede ser diferente
de su
criticidad
en el sujeto.
Si el ATM o usuario-STRM no puede realizar correctamente los procedimientos
definidos para una función marcada como
`crítica-para-entrega'
, el
informe es descartado.
Los procedimientos relativos a los
campos-ampliación
y a
sus indicaciones sobre la
criticidad
se definen
posteriormente en el
14
.
Esta Recomendación define mediante la macronotación de NSA.1 el
establecimiento por defecto de la indicación de
criticidad
de los
campos-ampliación
que debe suministrar el originador
de un mensaje. El originador de un mensaje o sonda puede escoger, mensaje por
mensaje, o de acuerdo con una política local (por ejemplo, una
política-seguridad) fijar una indicación de
criticidad
de un
campo-ampliación diferente de la definida en esta Recomendación, relajar o
restringir aún más dicha
criticidad
.
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Macros del servicio abstracto
OBJECT, PORT, ABSTRACT-BIND, ABSTRACT-UNBIND, ABSTRACT-OPERATION,
ABSTRACT-ERROR
FROM AbstractServiceNotation {^joint-iso-ccitt mhs-motis(6) asdc(2) modules(0)
notation(1)^}
--
Ampliación del servicio abstracto de MM
forwarding-request
FROM MSAbstractService {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0)
abstract-service(1)^}
--
Identificadores de objetos
id-ot-mts, id-ot-mts-user,
id-pt-submission, id-pt-delivery, id-pt-administration,
id-att-physicalRendition-basic,
id-tok-asymmetricToken
FROM MTSObjectifiers {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0)
object-identifiers(0)^}
--
Definiciones de guía
Name
FROM InformationFramework {^joint-iso-ccitt ds(5) modules(1)
information-framework(1)^}
PresentationAddress
FROM SelectedAttributeTypes {^joint-iso-ccitt ds(5) modules(1)
selectedAttributeTypes(5)^}
Certificates, AlgorithmIdentifier, ALGORITHM, SIGNED, SIGNATURE, ENCRYPTED
FROM AuthenticationFramework {^joint-iso-ccitt ds(5) modules(1)
authentication-framework(7)^}
FIGURA 2/X.411 (parte 1 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Cotas superiores
ub-bit-options, ub-built-in-content-type, ub-built-in-encoded-information-types, ub-common-name-length, ub-content-id-length, ub-content-length, ub-content-types, ub-country-name-alpha-length, ub-country-name-numeric-length, ub-dl-expansions, ub-domain-defined-attribute-value-length, ub-domain-defined-attributes, ub-domain-defined-attribute-type-length, ub-domain-name-length, ub-e163-4-number-length, ub-e163-4-subaddress-length, ub-encoded-information-types, ub-extension-attributes, ub-extension-types, ub-generation-qualifier-length, ub-given-name-length, ub-initials-length, ub-integer-options, ub-labels-and-redirections, ub-local-id-length, ub-mta-name-length, ub-mts-user-types, ub-numeric-user-id-length, ub-organization-name-length, ub-organizational-unit-name-length, ub-organizational-units, ub-password-length, ub-pds-name-length, ub-pds-parameter-length, ub-pds-physical-address-lines, ub-postal-code-length, ub-privacy-mark-length, ub-queue-size, ub-reason-codes, ub-recipients, ub-recipient-number-for-advice-length, ub-redirections, ub-security-categories ub-security-labels, ub-security-problems, ub-supplementary-info-length, ub-surname-length, ub-terminal-id-length, ub-tsap-id-length, ub-informated-address-length, ub-x121-address-length
FROM MTSUpperBounds {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0) upper-bounds(3)^};
FIGURA 2/X.411 (parte 1^
bis
de 41)
Definición de sintaxis abstracta del servicio abstracto del
STRM
--
Objetos
mTS OBJECT PORTS {^submission [S], delivery [S], administration [S]^} ::= id-ot-mts
mTSUser OBJECT PORTS {^submission [C], delivery [C], administration [C]^} ::= id-ot-mts-user
--
Puertos
submission PORT CONSUMER INVOKES {^MessageSubmission, ProbeSubmission, CancelDeferredDelivery^} SUPPLIER INVOKES {^SubmissionControl^} ::= id-pt-submission
delivery PORT CONSUMER INVOKES {^DeliveryControl^} SUPPLIER INVOKES {^MessageDelivery, ReportDelivery^} ::= id-pt-delivery
administration PORT CONSUMER INVOKES {^ChangeCredentials, Register^} SUPPLIER INVOKES {^ChangeCredentials^} ::= id-pt-administration
FIGURA 2/X.411 (parte 2 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Vinculación - STRM y Desvinculación - STRM
MTSBind ::= ABSTRACT-BIND
TO {^submission, delivery, administration^}
BIND
ARGUMENT SET^{
initiator-name ObjectName,
messages-waiting [1] EXPLICIT MessagesWaiting OPTIONAL,
initiator-credentials [2] InitiatorCredentials,
security-context [3] SecurityContext OPTIONAL^}
RESULT SET^{
responder-name ObjectName,
messages-waiting [1] EXPLICIT MessagesWaiting OPTIONAL,
responder-credentials [2] ResponderCredentials^}
BIND-ERROR INTEGER^{
busy (0)
authentication-error (2),
unacceptable-dialogue-mode (3),
unacceptable-security-context (4)
^}
(0.^.ub-integer-options)
MTSUnbind ::=ABSTRACT-UNBIND FROM {^submission, delivery, administration^}
--
Parámetros de control de asociación
ObjectName ::= CHOICE^{ mTS-userORAddressAndOptionalDirectoryName, mTA [0] MTAName, message-store [4] ORAddressAndOptionalDirectoryName^}
MessagesWaiting ::= SET^{ urgent [0] DeliveryQueue, normal [1] DeliveryQueue, non-urgent [2] DeliveryQueue^}
DeliveryQueue ::= SET^{
messages [0] INTEGER
(0.^.ub-queue-size)
,
octets [1] INTEGER
(0.^.ub-content-length
) OPTIONAL^}
InitiatorCredentials ::= CHOICE^{ simple Password, strong [0] StrongCredentials (WITH COMPONENTS^{ .^.^., bind-token PRESENT^})^}
FIGURA 2/X.411 (parte 3 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
ResponderCredentials ::= CHOICE^{
simple Password,
strong [0] StrongCredentials (WITH COMPONENTS^{
bind-token^})^}
Password ::= CHOICE^{ IA5String (SIZE (0.^.ub-password-length)) OCTET STRING (SIZE (0.^.ub-password-length))^}
StrongCredentials ::= SET^{ bind-token [0] Token OPTIONAL, certificate [1] Certificates OPTIONAL^}
Security Context ::= SET SIZE (1.^.ub-security-labels) OF SecurityLabel
FIGURA 2/X.411 (parte 4 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Puerto de remisión
MessageSubmission ::= ABSTRACT-OPERATION
ARGUMENT SEQUENCE^{
envelope MessageSubmissionEnvelope,
content Content^}
RESULT SET^{
message-submission-identifier MessageSubmissionIdentifier,
message-submission-time [0] MessageSubmissionTime,
content-identifier ContentIdentifier OPTIONAL,
extensions [1] EXTENSIONS CHOSEN FROM^{
originating-MTA-certificate,
proof-of-submission^} DEFAULT {^}^}
ERRORS^{
SubmissionControlViolated,
ElementOfServiceNotSubscribed,
OriginatorInvalid,
RecipientImproperlySpecified,
InconsistentRequest,
SecurityError
,
UnsupportedCriticalFunction,
RemoteBindError
^}
ProbeSubmission ::= ABSTRACT-OPERATION
ARGUMENT
envelope ProbeSubmissionEnvelope
RESULT SET^{
probe-submission-identifier ProbeSubmissionIdentifier,
probe-submission-time [0] ProbeSubmissionTime,
content-identifier ContentIdentifier OPTIONAL^}
ERRORS^{
SubmissionControlViolated,
ElementOfServiceNotSubscribed,
OriginatorInvalid,
RecipientImproperlySpecified,
InconsistentRequest,
SecurityError,
UnsupportedCriticalFunction,
RemoteBindError
^}
CancelDeferredDelivery :: ABSTRACT-OPERATION
ARGUMENT
message-submission-identifier MessageSubmissionIdentifier
RESULT
ERRORS^{
DeferredDeliveryCancellationRejected,
MessageSubmissionIdentifierInvalid,
RemoteBindError^}
FIGURA 2/X.411 (parte 5 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
SubmissionControl ::= ABSTRACT-OPERATION
ARGUMENT
controls SubmissionControls
RESULT
waiting Waiting
ERRORS^{
SecurityError,
RemoteBindError
^}
SubmissionControlViolated ::= ABSTRACT-ERROR PARAMETER NULL
ElementOfServiceNotSubscribed ::= ABSTRACT-ERROR PARAMETER NULL
DeferredDeliveryCancellationRejected ::= ABSTRACT-ERROR PARAMETER NULL
OriginatorInvalid ::= ABSTRACT-ERROR PARAMETER NULL
RecipientImproperlySpecified ::= ABSTRACT-ERROR
PARAMETER
improperly-specified-recipients SEQUENCE
SIZE
(1.^.ub-recipients
OF
ORAddressAndOptionalDirectoryName
MessageSubmissionIdentifierInvalid ::= ABSTRACT-ERROR PARAMETER NULL
InconsistentRequest ::= ABSTRACT-ERROR PARAMETER NULL
SecurityError ::= ABSTRACT-ERROR PARAMETER security-problem SecurityProblem
SecurityProblem ::= INTEGER (0.^.ub-security-problems)
UnsupportedCriticalFunction ::= ABSTRACT-ERROR PARAMETER NULL
RemoteBindError ::= ABSTRACT-ERROR PARAMETER NULL
FIGURA 2/X.411 (parte 6 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Parámetros del puerto de remisión
MessageSubmissionIdentifier ::= MTSIdentifier
MessageSubmissionTime ::= Time
ProbeSubmissionIdentifier ::= MTSIdentifier
ProbeSubmissionTime ::= Time
SubmissionControls ::= Controls (WITH COMPONENTS^{ permissible-content-types ABSENT, permissible-encoded-information-types ABSENT^})
Waiting ::= SET^{
waiting-operations [0] Operations DEFAULT {^},
waiting-messages [1] WaitingMessages DEFAULT {^},
waiting-content-types [2] SET SIZE (0.^.ub-content-types) OF
ContentType DEFAULT {^},
waiting-encoded-information-types EncodedInformationTypes OPTIONAL^}
Operations ::= BIT STRING^{
probe-submission-or-report-delivery (0),
message-submission-or-message-delivery (1)^}
(SIZE
(0.^.ub-bit-options))
--
con retención 'UNO', sin retención 'CERO'
WaitingMessages ::= BIT STRING^{
long-content (0),
low-priority (1),
other-security-labels (2)^} (SIZE (0.^.ub-bit-options))
FIGURA 2/X.411 (parte 7 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Puerto de entrega
MessageDelivery ::= ABSTRACT-OPERATION
ARGUMENT SEQUENCE^{
COMPONENTS OF MessageDeliveryEnvelope,
content Content^}
RESULT SET^{
recipient-certificate [0] RecipientCertificate
OPTIONAL,
proof-of-delivery [1] ProofOfDelivery OPTIONAL^}
DEFAULT{^}
ERRORS^{
DeliveryControlViolated,
SecurityError,
UnsupportedCriticalFunction
^}
ReportDelivery ::= ABSTRACT-OPERATION
ARGUMENT SET^{
COMPONENTS OF ReportDeliveryEnvelope,
returned-content [0] Content OPTIONAL^}
RESULT
ERRORS^{
DeliveryControlViolated,
SecurityError,
UnsupportedCriticalFunction
^}
DeliveryControl ::= ABSTRACT-OPERATION
ARGUMENT
controls DeliveryControls
RESULT
waiting Waiting
ERRORS^{
ControlViolatesRegistration
,
SecurityError
^}
DeliveryControlViolated ::= ABSTRACT-ERROR PARAMETER NULL
ControlViolatesRegistration ::= ABSTRACT-ERROR PARAMETER NULL
--
Error de seguridad - definido en la figura 2/X.411,
parte 6 de 41
--
Función crítica no soportada - definida en la figura
2/X.411, parte 6 de 41
FIGURA 2/X.411 (parte 8 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Parámetros del puerto de entrega
RecipientCertificate ::= Certificates
ProofOfDelivery ::= SIGNATURE SEQUENCE^{ algorithm-identifier ProofOfDeliveryAlgorithmIdentifier, delivery-time MessageDeliveryTime, this-recipient-name ThisRecipientName, originally-intended-recipient-name OriginallyIntendedRecipientName OPTIONAL, content Content, content-identifier ContentIdentifier OPTIONAL, message-security-label MessageSecurityLabel OPTIONAL^}
ProofOfDeliveryAlgorithmIdentifier ::= AlgorithmIdentifier
DeliveryControls ::= Controls
Controls ::= SET^{
restrict
[0]
BOOLEAN DEFAULT TRUE,
-- update 'TRUE', remove 'FALSE'
permissible-operations
[1]
Operations OPTIONAL,
permissible-maximum-content-length
[2]
ContentLength
OPTIONAL,
permissible-lowest-priority Priority OPTIONAL,
permissible-content-types [4] SET SIZE
(1.^.ub-content-types) OF ContentType OPTIONAL,
permissible-encoded-information-types EncodedInformationTypes OPTIONAL,
permissible-security-context [5] SecurityContext
OPTIONAL
^}
--
Nota
-
Los rótulos [0], [1] y [2]
sólo se alteran para la operación de registro
.
FIGURA 2/X.411 (parte 9 de 41)
Definición de
sintaxis abstracta del servicio abstracto del STRM
--
Puerto de administración
Register ::= ABSTRACT-OPERATION
ARGUMENT SET^{
user-name UserName OPTIONAL,
user-address [0] UserAddress OPTIONAL,
deliverable-encoded-information-types EncodedInformationTypes OPTIONAL,
deliverable-maximum-content-length [1] EXPLICIT ContentLength OPTIONAL,
default-delivery-controls [2] EXPLICIT DefaultDeliveryControls OPTIONAL,
deliverable-content-types [3] SET SIZE (1
.^.ub-content-types) OF ContentType OPTIONAL
,
labels-and-redirections [4] SET SIZE
(1.^.ub-labels-and-redirections) OF
LabelAndRedirection OPTIONAL
^}
RESULT
ERRORS^{
RegisterRejected^}
ChangeCredentials ::= ABSTRACT-OPERATION ARGUMENT SET^{ old-credentials [0] Credentials, new-credentials [1] Credentials -- same CHOICE as for old-credentials --^} RESULT ERRORS^{ NewCredentialsUnacceptable, OldCredentialsIncorrectlySpecified^}
RegisterRejected ::= ABSTRACT-ERROR PARAMETER NULL
NewCredentialsUnacceptable ::= ABSTRACT-ERROR PARAMETER NULL
OldCredentialsIncorrectlySpecified ::= ABSTRACT-ERROR PARAMETER NULL
FIGURA 2/X.411 (parte 10 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Parámetros del puerto de administración
UserName ::= ORAddressAndOptionalDirectoryName
UserAddress ::= CHOICE^{
x121 [0] SEQUENCE^{
x121-address NumericString
(Size
(1.^.ub-x121-address-length))
OPTIONAL,
tsap-id PrintableString
(SIZE (1.^.ub-tsap-id-length))
OPTIONAL^},
presentation [1] PSAPAddress
^}
PSAPAddress ::= PresentationAddress
DefaultDeliveryControls ::= Controls (WITH COMPONENTS^{ .^.^., permissible-security-context ABSENT^})
Credentials ::= CHOICE^{
simple Password,
strong [0] StrongCredentials (WITH COMPONENTS^{
certificate^})
^}
LabelAndRedirection ::= SET^{ user-security-label [0] UserSecurityLabel OPTIONAL, recipient-assigned-alternate-recipient [1] RecipientAssignedAlternateRecipient OPTIONAL^}
UserSecurityLabel ::= SecurityLabel
RecipientAssignedAlternateRecipient ::= ORAddressAndOptionalDirectoryName
FIGURA 2/X.411 (parte 11 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Sobre de remisión del mensaje
MessageSubmissionEnvelope ::= SET^{
COMPONENTS OF PerMessageSubmissionFields,
per-recipient-fields [1] SEQUENCE
SIZE
(1.^.ub-recipients)
OF
PerRecipientMessageSubmissionFields^}
PerMessageSubmissionFields ::= SET^{
originator-name OriginatorName,
original-encoded-information-types OriginalEncodedInformationTypes
OPTIONAL
,
content-type ContentType,
content-identifier ContentIdentifier OPTIONAL,
priority Priority DEFAULT normal,
per-message-indicators PerMessageIndicators DEFAULT {^},
deferred-delivery-time [0] DeferredDeliveryTime OPTIONAL,
extensions [2] PerMessageSubmissionExtensions DEFAULT
{^}
^}
PerMessageSubmissionExtensions ::= EXTENSIONS CHOSEN FROM^{ recipient-reassignment-prohibited, dl-expansion-prohibited, conversion-with-loss-prohibited, latest-delivery-time originator-return-address, originator-certificate, content-confidentiality-algorithm-identifier, message-origin-authentication-check, message-security-label, proof-of-submission-request, content-correlator, forwarding-request -- for MS Abstract Service only --^}
PerRecipientMessageSubmissionFields ::= SET^{
recipient-name RecipientName,
originator-report-request [0] OriginatorReportRequest,
explicit-conversion [1] ExplicitConversion
OPTIONAL
,
extensions [2] PerRecipientMessageSubmissionExtensions
DEFAULT {^}
^}
PerRecipientMessageSubmissionExtensions ::= EXTENSIONS CHOSEN FROM^{ originator-requested-alternate-recipient, requested-delivery-method, physical-forwarding-prohibited, physical-forwarding-address-request, physical-delivery-modes, registered-mail-type, recipient-number-for-advice, physical-rendition-attributes, physical-delivery-report-request, message-token, content-integrity-check, proof-of-delivery-request^}
FIGURA 2/X.411 (parte 12 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Sobre de remisión de sonda
ProbeSubmissionEnvelope ::= SET^{
COMPONENTS OF PerProbeSubmissionFields,
per-recipient-fields [3] SEQUENCE
SIZE
(1.^.ub-recipients)
OF
PerRecipientProbeSubmissionFields^}
PerProbeSubmissionFields ::= SET^{
originator-name OriginatorName,
original-encoded-information-types OriginalEncodedInformationTypes
OPTIONAL
content-type ContentType,
content-identifier ContentIdentifier OPTIONAL,
content-length [0] ContentLength OPTIONAL,
per-message-indicators PerMessageIndicators DEFAULT {^},
extensions [2] EXTENSIONS CHOSEN FROM^{
recipient-reassignment-prohibited,
dl-expansion-prohibited,
conversion-with-loss-prohibited,
originator-certificate,
message-security-label,
content-correlator,
probe-origin-authentication-check^} DEFAULT {^}
^}
PerRecipientProbeSubmissionFields ::= SET^{
recipient-name RecipientName,
originator-report-request [0] OriginatorReportRequest,
explicit-conversion [1] ExplicitConversion
OPTIONAL
,
extensions [2] EXTENSIONS CHOSEN FROM^{
originator-requested-alternate-recipient,
requested-delivery-method
physical-rendition-attributes^} DEFAULT {^}
^}
FIGURA 2/X.411 (parte 13 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Sobre de entrega de mensajes
MessageDeliveryEnvelope ::= SEQUENCE^{ message-delivery-identifier MessageDeliveryIdentifier, message-delivery-time MessageDeliveryTime, other-fields OtherMessageDeliveryFields^}
OtherMessageDeliveryFields ::= SET^{
content-type DeliveredContentType,
originator-name OriginatorName,
original-encoded-information-types [1] OriginalEncodedInformationTypes
OPTIONAL
,
priority Priority DEFAULT normal,
delivery-flags [2] DeliveryFlags
OPTIONAL
,
other-recipient-names [3] OtherRecipientNames OPTIONAL,
this-recipient-name [4] ThisRecipientName,
originally-intended-recipient-name [5] OriginallyIntendedRecipientName
OPTIONAL,
converted-encoded-information-types [6] ConvertedEncodedInformationTypes
OPTIONAL,
message-submission-time [7] MessageSubmissionTime,
content-identifier [8] ContentIdentifier OPTIONAL
,
extensions [9] EXTENSIONS CHOSEN FROM^{
conversion-with-loss-prohibited,
requested-delivery-method,
physical-forwarding-prohibited,
physical-forwarding-address-request,
physical-delivery-modes,
registered-mail-type,
recipient-number-for-advice,
physical-rendition-attributes,
originator-return-address,
physical-delivery-report-request,
originator-certificate,
message-token,
content-confidentiality-algorithm-identifier,
content-integrity-check,
message-origin-authentication-check,
message-security-label,
proof-of-delivery-request,
redirection-history,
dl-expansion-history^} DEFAULT {^}
^}
FIGURA 2/X.411 (parte 14 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Sobre de entrega de informe
ReportDeliveryEnvelope ::= SET^{
COMPONENTS OF PerReportDeliveryFields,
per-recipient-fields SEQUENCE
SIZE (1.^.ub-recipients)
OF PerRecipientReportDeliveryFields^}
PerReportDeliveryFields ::= SET^{
subject-submission-identifier SubjectSubmissionIdentifier,
content-identifier ContentIdentifer OPTIONAL,
content-type ContentType OPTIONAL
,
original-encoded-information-types
OriginalEncodedInformationTypes OPTIONAL
,
extension [1] EXTENSIONS CHOSEN FROM^{
message-security-label,
content-correlator,
originator-and-DL-expansion-history,
reporting-DL-name,
reporting-MTA-certificate,
report-origin-authentication-check^} DEFAULT {^}
^}
PerRecipientReportDeliveryFields ::= SET^{
actual-recipient-name [0] ActualRecipientName,
report-type [1] ReportType,
converted-encoded-information-types ConvertedEncodedInformationTypes OPTIONAL,
originally-intended-recipient-name [2] OriginallyIntendedRecipientName
OPTIONAL,
supplementary-information [3] SupplementaryInformation OPTIONAL,
extensions [4] EXTENSIONS CHOSEN FROM {^
redirection-history,
physical-forwarding-address,
recipient-certificate,
proof-of-delivery^} DEFAULT {^}
^}
ReportType ::= CHOICE^{ delivery [0] DeliveryReport, non-delivery [1] NonDeliveryReport^}
DeliveryReport ::= SET^{ message-delivery-time [0] MessageDeliveryTime, type-of-MTS-user [1] TypeOfMTSUser DEFAULT public^}
NonDeliveryReport ::= SET^{ non-delivery-reason-code [0] NonDeliveryReasonCode, non-delivery-diagnostic-code [1] NonDeliveryDiagnosticCode OPTIONAL^}
FIGURA 2/X.411 (parte 15 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Campos de sobre
OriginatorName :: = ORAddressAndOrDirectoryName
OriginalEncodedInformationTypes ::= EncodedInformationTypes
ContentType ::= CHOICE^{
built-in BuiltInContentType,
external ExternalContentType
^}
BuiltInContentType ::= [APPLICATION 6] INTEGER^{
unidentified (0),
external (1),
-- identified by the object-identifier of
the EXTERNAL content
interpersonal-messaging-1984 (2),
interpersonal-messaging-1988 (22)^}
(0.^.ub-built-in-content-type)
ExternalContentType ::= OBJECT IDENTIFIER
DeliveredContentType ::= CHOICE^{
built-in [0] BuiltInContentType,
external ExternalContentType
^}
ContentIdentifier ::= [APPLICATION 10] PrintableString
(SIZE (1.^.ub-content-id-length))
PerMessageIndicators ::= [APPLICATION 8] BIT STRING^{
disclosure-of-recipients (0),-- disclosure-of-recipients-allowed 'one',
-- disclosure-of-recipient-prohibited 'zero',
-- ignored for Probe-submission
implicit-conversion-prohibited (1),-- implicit-conversion-prohibited 'one';
-- implicit-conversion-allowed 'zero'
alternate-recipient-allowed (2),-- alternate-recipient-allowed 'one',
-- alternate-recipient-prohibited 'zero'
content-return-request (3)-- content-return-requested 'one',
-- content-return-not-requested 'zero';
-- ignored for Probe-submission --^}
(SIZE (0.^.ub-bit-options))
RecipientName ::= ORAddressAndOrDirectoryName
OriginatorReportRequest ::= BIT STRING^{
report (3),
non-delivery-report (4)
-- at most one bit shall be 'one':
-- report bit 'one' requests a 'report';
-- non-delivery-report bit 'one' requests a 'non-delivery-report';
-- both bits 'zero' requests 'no-report' --^}
(SIZE
(0.^.ub-bit-options))
FIGURA 2/X.411 (parte 16 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
ExplicitConversion ::= INTEGER^{
ia5-text-to-teletex (0),
teletex-to-telex (1),
telex-to-ia5-text (2),
telex-to-teletex (3),
telex-to-g4-class-1 (4),
telex-to-videotex (5),
ia5-text-to-telex (6),
telex-to-g3-facsimile (7),
ia5-text-to-g3-facsimile (8),
ia5-text-to-g4-class-1 (9),
ia5-text-to-videotex (10),
teletex-to-ia5-text (11),
teletex-to-g3-facsimile (12),
teletex-to-g4-class-1 (13),
teletex-to-videotex (14),
videotex-to-telex (15),
videotex-to-ia5-text (16),
videotex-to-teletex (17)
^}
(0.^.ub-integer-options)
DeferredDeliveryTime ::= Time
Priority ::= [APPLICATION 7] ENUMERATED^{ normal (0), non-urgent (1), urgent (2)^}
ContentLength ::= INTEGER
(0.^.ub-content-length)
MessageDeliveryIdentifier ::= MTSIdentifier
MessageDeliveryTime ::= Time
DeliveryFlags ::= BIT STRING^{
implicit-conversion-prohibited (1)-- implicit-conversion-prohibited 'one',
-- implicit-conversion-allowed 'zero' --^}
(SIZE (0.^.ub-bit-options))
OtherRecipientNames ::= SEQUENCE
SIZE
(1.^.ub-recipients)
OF Other RecipientName
OtherRecipientName ::= OrAddressAndOrDirectoryName
ThisRecipientName ::= OrAddressAndOrDirectoryName
OriginallyIntendedRecipientName ::= OrAddressAndOrDirectoryName
FIGURA 2/X.411 (parte 17 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
ConvertedEncodedInformationTypes ::= EncodedInformationTypes
SubjectSubmissionIdentifier ::= MTSIdentifier
ActualRecipientName ::= ORAddressAndOrDirectoryName
TypeOfMTSUser ::= INTEGER^{
public (0),
private (1),
ms (2),
dl (3),
pdau (4),
physical-recipient (5),
other (6)
^}
(0.^.ub-mts-user-types)
NonDeliveryReasonCode ::= INTEGER^{
transfer-failure (0),
unable-to-transfer (1),
conversion-not-performed (2),
physical-rendition-not-performed (3),
physical-delivery-not-performed (4),
restricted-delivery (5),
directory-operation-unsuccessful (6)
^}
(0.^.ub-reason-codes)
NonDeliveryDiagnosticCode ::= INTEGER^{
unrecognised-OR-name (0),
ambiguous-OR-name (1),
mts-congestion (2),
loop-detected (3),
recipient-unavailable (4),
maximum-time-expired (5),
encoded-information-types-unsupported (6),
content-too-long (7),
conversion-impractical (8),
implicit-conversion-prohibited (9),
implicit-conversion-not-subscribed (10),
invalid-arguments (11),
content-syntax-error (12),
size-constraint-violation (13),
protocol-violation (14),
content-type-not-supported (15),
too-many-recipients (16),
no-bilateral-agreement (17),
unsupported-critical-function (18),
--
continuación
FIGURA 2/X.411 (parte 18 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
continuación
conversion-with-loss-prohibited (19),
line-too-long (20),
page-split (21),
pictorial-symbol-loss (22),
punctuation-symbol-loss (23),
alphabetic-character-loss (24),
multiple-information-loss (25),
recipient-reassignment-prohibited (26),
redirection-loop-detected (27),
dL-expansion-prohibited (28),
no-DL-submit-permission (29),
dl-expansion-failure (30),
physical-rendition-attributes-not-supported (31),
undeliverable-mail-physical-delivery-address-incorrect
(32),
undeliverable-mail-physical-delivery-office-incorrect-or-invalid (33),
undeliverable-mail-physical-delivery-address-incomplete
(34),
undeliverable-mail-recipient-unknown (35),
undeliverable-mail-recipient-deceased (36),
undeliverable-mail-organization-expired (37),
undeliverable-mail-recipient-refused-to-accept (38),
undeliverable-mail-recipient-did-not-claim (39),
undeliverable-mail-recipient-changed-address-permanently
(40),
undeliverable-mail-recipient-changed-address-temporarily
(41),
undeliverable-mail-recipient-changed-temporary-address
(42),
undeliverable-mail-new-address-unknown (43),
undeliverable-mail-recipient-did-not-want-forwarding
(44),
undeliverable-mail-originator-prohibited-forwarding
(45),
secure-messaging-error (46),
unable-to-downgrade (47)
^}
(0.^.ub-diagnostic-codes)
SupplementaryInformation ::= PrintableString
(SIZE
(1.^.ub-supplementary-info-length))
FIGURA 2/X.411 (parte 19 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Campos de ampliación
ExtensionField ::= SEQUENCE^{ type [0] EXTENSION, criticality [1] Criticality DEFAULT {^}, value [2] AND DEFINED BY type DEFAULT NULL NULL^}
Criticality ::= BIT STRING^{ for-submission (0), for-transfer (1), for-delivery (2)^} (SIZE (0.^.ub-bit-options))-- critical 'one', non-critical 'zero'
EXTENSIONS MACRO ::= BEGIN
TYPE NOTATION ::= "CHOSEN FROM" "{^"ExtensionList"^}" VALUE NOTATION ::= Value (VALUE SET OF ExtensionField-- each of a different type --)
ExtensionList ::= Extension"," ExtensionList^|^Extension^|^empty Extension ::= value (EXTENSION)
END -- of EXTENSIONS
EXTENSION MACRO ::= BEGIN
TYPE NOTATION ::= DataType Critical^|^empty VALUE NOTATION ::= value (VALUE ExtensionType)
DataType ::= type (X) Default^|^empty Default ::= "DEFAULT" value (X)^|^empty Critical ::= "CRITICAL FOR" CriticalityList^|^empty CriticalityList ::= Criticality^|^CriticalityList "," Criticality Criticality ::= "SUBMISSION"^|^"TRANSFER"^|^"DELIVERY"
END -- of EXTENSION
ExtensionType ::= INTEGER (0.^.ub-extension-types)
recipient-reassignment-prohibited EXTENSION RecipientReassignmentProhibited DEFAULT recipient-reassignment-allowed CRITICAL FOR DELIVERY ::= 1
FIGURA 2/X.411 (parte 20 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
RecipientReassignmentProhibited ::= ENUMERATED^{ recipient-reassignment-allowed (0), recipient-reassignment-prohibited (1)^}
originator-requested-alternate-recipient EXTENSION OriginatorRequestedAlternateRecipient CRITICAL FOR SUBMISSION ::= 2
OriginatorRequestedAlternateRecipient ::= ORAddressAndOrDirectoryName
--
OriginatorRequestedAlternateRecipient, tal como aquí se
define, difiere
--
del campo del mismo nombre de la figura 4/X.411, ya que no
es necesario
--
que esté presente al remitir la dirección-OD, pero si debe
estar
--
presente al transferir la dirección-OD
dl-expansion-prohibited EXTENSION DLExpansionProhibited DEFAULT dl-expansion-allowed CRITICAL FOR DELIVERY ::= 3
DLExpansionProhibited ::= ENUMERATED^{ dl-expansion-allowed (0), dl-expansion-prohibited (1)^}
conversion-with-loss-prohibited EXTENSION ConversionWithLossProhibited DEFAULT conversion-with-loss-allowed CRITICAL FOR DELIVERY ::= 4
ConversionWithLossProhibited ::= ENUMERATED^{ conversion-with-loss-allowed (0), conversion-with-loss-prohibited (1)^}
latest-delivery-time EXTENSION LatestDeliveryTime CRITICAL FOR DELIVERY ::= 5
LatestDeliveryTime ::= Time
requested-delivery-method EXTENSION RequestedDeliveryMethod DEFAULT any-delivery-method CRITICAL FOR DELIVERY ::= 6
FIGURA 2/X.411 (parte 21 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
RequestedDeliveryMethod ::= SEQUENCE OF INTEGER {^--
cada uno
distinto en orden de preferencia siendo
RequestedDeliveryMethod ::= SEQUENCE OF INTEGER {^--
el primero
el más preferido
any-delivery-method (0), mhs-delivery (1), physical-delivery (2), telex-delivery (3), teletex-delivery (4), g3-facsimile-delivery (5), g4-facsimile-delivery (6), ia5-terminal-delivery (7), videotex-delivery (8), telephone-delivery (9)^Å (0.^.ub-integer-options)
physical-forwarding-prohibited EXTENSION PhysicalForwardingProhibited DEFAULT physical-forwarding-allowed CRITICAL FOR DELIVERY ::= 7
PhysicalForwardingProhibited ::= ENUMERATED^{ physical-forwarding-allowed (0), physical-forwarding-prohibited (1)^}
physical-forwarding-address-request EXTENSION PhysicalForwardingAddressRequest DEFAULT physical-forwarding-address-not-requested CRITICAL FOR DELIVERY ::= 8
PhysicalForwardingAddressRequest ::= ENUMERATED^{ physical-forwarding-address-not-requested (0), physical-forwarding-address-requested (1)^}
physical-delivery-modes EXTENSION PhysicalDeliveryModes DEFAULT ordinary-mail CRITICAL FOR DELIVERY ::= 9
PhysicalDeliveryModes ::= BIT STRING^{
ordinary-mail (0),
special-delivery (1),
express-mail (2),
counter-collection (3),
counter-collection-with-telephone-advice (4),
counter-collection-with-telex-advice (5),
counter-collection-with-teletex-advice (6),
bureau-fax-delivery (7)
--
los bits 0 a 6 se excluyen mutuamente
--
el bit 7 puede ser fijado con cualquiera de los bits 0 a
6
--^} (
SIZE
(
0.^.ub-bit-options
))
FIGURA 2/X.411 (parte 22 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
registered-mail-type EXTENSION RegisteredMailType DEFAULT non-registered-mail CRITICAL FOR DELIVERY ::= 10
RegisteredMailType ::= INTEGER non-registered-mail (0), registered-mail (1), registered-mail-to-addresse-in-person (2)^} (0.^.ub-integer-options)
recipient-number-for-advice EXTENSION RecipientNumberForAdvice CRITICAL FOR DELIVERY ::= 11
RecipientNumberForAdvice ::= TeletexString (SIZE (1.^.ub-recipient-number-for-advice-length))
physical-rendition-attributes EXTENSION PhysicalRenditionAttributes DEFAULT id-att-physicalRendition-basic CRITICAL FOR DELIVERY :: = 12
PhysicalRenditionAttributes ::= OBJECT IDENTIFIER
originator-return-address EXTENSION OriginatorReturnAddress CRITICAL FOR DELIVERY ::= 12
OriginatorReturnAddress ::= ORAddress
physical-delivery-report-request EXTENSION PhysicalDeliveryReportRequest DEFAULT return-of-undeliverable-mail-by-PDS CRITICAL FOR DELIVERY ::= 14
PhysicalDeliveryReportRequest::= INTEGER^{ return-of-undeliverable-mail-by-PDS (0), return-of-notification-by-PDS (1), return-of-notification-by-MHS (2), return-of-notification-by-MHS-and-PDS (3)^} (0.^.ub-integer-options)
FIGURA 2/X.411 (parte 23 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
originator-certificate EXTENSION OriginatorCertificate CRITICAL FOR DELIVERY ::= 15
OriginatorCertificate ::= Certificates
message-token EXTENSION MessageToken ::= 16
MessageToken ::= Token
content-confidentiality-algorithm-identifier EXTENSION ContentConfidentialityAlgorithmIdentifier ::= 17
ContentConfidentialityAlgorithmIdentifier ::= AlgorithmIdentifier
content-integrity-check EXTENSION ContentIntegrityCheck ::= 18
ContentIntegrityCheck ::= SIGNATURE SEQUENCE^{ algorithm-identifier ContentIntegrityAlgorithmIdentifier, content Content^}
ContentIntegrityAlgorithmIdentifier ::= AlgorithmIdentifier
message-origin-authentication-check EXTENSION MessageOriginAuthenticationCheck CRITICAL FOR DELIVERY ::= 19
MessageOriginAuthenticationCheck ::= SIGNATURE SEQUENCE^{ algorithm-identifier MessageOriginAuthenticationAlgorithmIdentifier, content Content content-identifier ContentIdentifier OPTIONAL, message-security-label MessageSecurityLabel OPTIONAL^}
MessageOriginAuthenticationAlgorithmIdentifier ::= AlgorithmIdentifier
FIGURA 2/X.411 (parte 24 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
message-security-label EXTENSION MessageSecurityLabel CRITICAL FOR DELIVERY ::= 20
MessageSecurityLabel ::= SecurityLabel
proof-of-submission-request EXTENSION ProofOfSubmissionRequest DEFAULT proof-of-submission-not-requested CRITICAL FOR SUBMISSION ::= 21
ProofOfSubmissionRequest ::= ENUMERATED^{ proof-of-submission-not-requested (0), proof-of-submission-requested (1)^Å
proof-of-delivery-request EXTENSION ProofOfDeliveryRequest DEFAULT proof-of-delivery-not-requested CRITICAL FOR DELIVERY ::= 22
ProofOfDeliveryRequest ::= ENUMERATED^{ proof-of-delivery-not-requested (0), proof-of-delivery-requested (1)^}
content-correlator EXTENSION ContentCorrelator ::= 23
ContentCorrelator ::= ANY -- maximum ub-content-correlator-length octets including all encoding
probe-origin-authentication-check EXTENSION ProbeOriginAuthenticationCheck CRITICAL FOR DELIVERY ::= 24
ProbeOriginAuthenticationCheck ::= SIGNATURE SEQUENCE^{ algorithm-identifier ProbeOriginAuthenticationAlgorithmIdentifier, content-identifier ContentIdentifier OPTIONAL, message-security-label MessageSecurityLabel OPTIONAL^}
ProbeOriginAuthenticationAlgorithmIdentifier ::= AlgorithmIdentifier
FIGURA 2/X.411 (parte 25 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
redirection-history EXTENSION RedirectionHistory ::= 25
RedirectionHistory ::= SEQUENCE SIZE (1.^.ub-redirections) OF Redirection
Redirection ::= SEQUENCE^{ intended-recipient-name IntendedRecipientName, redirection-reason RedirectionReason^}
IntendedRecipientName ::= SEQUENCE^{ OrAddressAndOptionalDirectoryName, redirection-time Time^}
RedirectionReason ::= ENUMERATED^{ recipient-assigned-alternate-recipient (0), originator-requested-alternate-recipient (1), recipient-MD-assigned-alternate-recipient (2)^}
dl-expansion-history EXTENSION DLExpansionHistory ::= 26
DLExpansionHistory ::= SEQUENCE SIZE (1.^.ub-dl-expansions) OF DLExpansion
DLExpansion ::= SEQUENCE^{ ORAddressAndOptionalDirectoryName, dl-expansion-time Time^}
physical-forwarding-address EXTENSION PhysicalForwardAddress ::= 27
PhysicalForwardingAddress ::= ORAddressAndOptionalDirectoryName
recipient-certificate EXTENSION RecipientCertificate ::= 28
proof-of-delivery EXTENSION ProofOfDelivery ::= 29
originator-and-DL-expansion-history EXTENSION OriginatorAndDLExpansionHistory ::= 30
OriginatorAndDLExpansionHistory ::= SEQUENCE SIZE (0.^.ub-dl-expansions) OF OriginatorAndDLExpansion
OriginatorAndDLExpansion ::= SEQUENCE^Â originator-or-dl-name ORAddressOptionalDirectoryName, origination-or-expansion-time TIME^Å
FIGURA 2/X.411 (parte 26 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
reporting-DL-name EXTENSION ReportingDLName ::= 31
ReportingDLName ::= ORAddressAndOptionalDirectoryName
reporting-MTA-certificate EXTENSION ReportingMTACertificate CRITICAL FOR DELIVERY ::= 32
ReportingMTACertificate ::= Certificates
report-origin-authentication-check EXTENSION ReportOriginAuthenticationCheck CRITICAL FOR DELIVERY ::= 33
ReportOriginAuthenticationCheck ::= SIGNATURE SEQUENCE^{ algorithm-identifier ReportOriginAuthenticationAlgorithmIdentifier, content-identifier ContentIdentifier OPTIONAL, message-security-label MessageSecurityLabel OPTIONAL, per-recipient SEQUENCE SIZE (1.^.ub-recipients) OF PerRecipientReportFields^}
ReportOriginAuthenticationAlgorithmIdentifier ::= AlgorithmIdentifier
PerRecipientReportFields ::= SEQUENCE^{ actual-recipient-name ActualRecipientName, originally-intended-recipient-name OriginallyIntendedRecipientName OPTIONAL, CHOICE^{ delivery [0] PerRecipientDeliveryReportFields, non-delivery [1] PerRecipientNonDeliveryReportFields^}^}
PerRecipientDeliveryReportFields ::= SEQUENCE^{
message-delivery-time MessageDeliveryTime,
type-of-MTS-user TypeOfMTSUser,
recipient-certificate [0] RecipientCertificate
OPTIONAL,
proof-of-delivery [1] ProofOfDelivery OPTIONAL^}
PerRecipientNonDeliveryReportFields ::= SEQUENCE^{ non-delivery-reason-code NonDeliveryReasonCode, non-delivery-diagnostic-code NonDeliveryDiagnosticCode OPTIONAL^}
FIGURA 2/X.411 (parte 27 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
originating-MTA-certificate EXTENSION OriginatingMTACertificate ::= 34
OriginatingMTACertificate ::= Certificates
proof-of-submission EXTENSION ProofOfSubmission ::= 35
ProofOfSubmission ::= SIGNATURE SEQUENCE^{ algorithm-identifier ProofOfSubmissionAlgorithmIdentifier, message-submission-envelope MessageSubmissionEnvelope, content Content, message-submission-identifier MessageSubmissionIdentifier, message-submission-time MessageSubmissionTime^}
ProofOfSubmissionAlgorithmIdentifier ::= AlgorithmIdentifier
FIGURA 2/X.411 (parte 28 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Tipos de parámetros comunes
Content ::= OCTET STRING --
cuando el tipo-contenido
tiene el valor entero
Content ::= OCTET STRING --
externo, el valor de la cadena
de octetos de
Content ::= OCTET STRING --
contenido es la codificación
NSA.1 del contenido-externo
Content ::= OCTET STRING --
un contenido-externo es un tipo
de datos EXTERNO
MTSIdentifier ::= [APPLICATION 4] SEQUENCE^{ global-domain-identifier GlobalDomainIdentifier, local-identifier LocalIdentifier^}
LocalIdentifier ::= IA5String
(SIZE
(1.^.ub-local-id-length))
GlobalDomainIdentifier ::= [APPLICATION 3] SEQUENCE^{ country-name CountryName, administration-domain-name AdministrationDomainName, private-domain-identifier PrivateDomainIdentifier OPTIONAL^}
PrivateDomainIdentifier ::= CHOICE^{
numeric NumericString
(SIZE
(1.^.ub-domain-name-length)),
printable PrintableString
(SIZE
(1.^.ub-domain-name-length))
^}
MTAName ::= IA5String
(SIZE
(1.^.ub-mta-name-length))
Time ::= UTCTime
FIGURA 2/X.411 (parte 29 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Nombres O/D
ORAddressAndOrDirectoryName ::= ORName
ORAddressAndOptionalDirectoryName ::= ORName
ORName ::= [APPLICATION 0] SEQUENCE^{
address COMPONENTS OF ORAddress,
directory-name [0] Name OPTIONAL
^}
ORAddress ::= SEQUENCE^{
standard-attributes StandardAttributes,
domain-defined-attributes DomainDefinedAttributes OPTIONAL,
--
véase también atributos-definidos-dominio-téletex
extension-attributes ExtensionAttributes OPTIONAL
^}
--
Nota - La dirección-OD está semánticamente ausente del
nombre-OD si la secuencia de atributo-normal está
vacía
--
y se omiten los atributos-definidos-dominio y los
atributos-ampliación
.
--
Atributos normales
StandardAttributes ::= SEQUENCE
country-name CountryName OPTIONAL,
administration-domain-name AdministrationDomainName OPTIONAL,
network-address [0] NetworkAddress OPTIONAL, --
véase también
la dirección-red-ampliada
terminal-identifier [1] TerminalIdentifier OPTIONAL,
private-domain-name [2] PrivateDomainName OPTIONAL,
organization-name [3] OrganizationName OPTIONAL, --
véase
también el nombre-organización-teletex
numeric-user-identifier [4] NumericUserIdentifier OPTIONAL,
personal-name [5] PersonalName OPTIONAL, --
véase también el
nombre personal teletex
organizational-unit-names [6] OrganizationalUnitNames OPTIONAL
--
véase también los nombres-unidad-organización-teletex
--^}
CountryName ::= [APPLICATION 1] CHOICE^{
x121-dcc-code NumericString
(SIZE
(ub-country-name-numeric-length)),
iso-3166-alpha2-code PrintableString
(SIZE
(ub-country-name-alpha-length))
^}
AdministrationDomainName ::= [APPLICATION 2] CHOICE^{
numeric NumericString
(SIZE
(0.^.ub-domain-name-length)),
printable PrintableString
(SIZE
(0.^.ub-domain-name-length))
^}
NetworkAddress ::= x121Address
X121Address ::= NumericString
(SIZE
(1.^.ub-x121-address-length))
TerminalIdentifier ::= PrintableString
(SIZE
(1.^.ub-terminal-id-length))
FIGURA 2/X.411 (parte 30 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
PrivateDomainName ::= CHOICE^{
numeric NumericString
(SIZE
(1.^.ub-domain-name-length)),
printable PrintableString
(SIZE
(1.^.ub-domain-name-length)),
^}
OrganizationName ::= Printable String
(SIZE
(1.^.ub-organization-name-length))
NumericUserIdentifier ::= NumericString
(SIZE
(1.^.ub-numeric-user-id-length))
Personal Name ::= SET^{
surname [0] PrintableString
(SIZE
(1.^.ub-surname-length)),
given-name [1] PrintableString
(SIZE
(1.^.ub-given-name-length)),
OPTIONAL,
initials [2] PrintableString
(SIZE
(1.^.ub-initials-length))
OPTIONAL^}
generation-qualifier [3] PrintableString
(SIZE
(1.^.ub-generation-qualifier-length))
OPTIONAL^}
OrganizationUnitNames ::= SEQUENCE
SIZE
(1.^.ub-organizational-units)
OF OrganizationUnitName
OrganizationUnitName ::= PrintableString
(SIZE
(1.^.ub-organizational-unit-name-length))
--
Atributos definidos-dominio
DomainDefinedAttributes ::= SEQUENCE
SIZE
(1.^.ub-domain-defined-attributes)
OF DomainDefinedAttribute
DomainDefinedAttribute ::= SEQUENCE^{
type PrintableString
(SIZE
(1.^.ub-domain-attribute-type-length))
,
value PrintableString
(SIZE
(1.^.ub-domain-defined-attribute-value-length))
^}
--
Atributos de prolongación
ExtensionAttributes ::= SET SIZE (1.^.ub-extension-attributes) OF ExtensionAttribute
ExtensionAttribute ::= SEQUENCE^{ extension-attribute-type [0] EXTENSION-ATTRIBUTE, extension-attribute-value [1] ANY DEFINED BY extension-attribute-type^}
EXTENSION-ATTRIBUTE MACRO ::= BEGIN
TYPE NOTATION::= TYPE^|^empty VALUE NOTATION ::= value (VALUE INTEGER (0.^.ub-extension-attributes))
END --
de ATRIBUTO-PROLONGACIóN
FIGURA 2/X.411 (parte 31 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
common-name EXTENSION-ATTRIBUTE CommonName ::= 1
CommonName ::= PrintableString (SIZE (1.^.^.ub-common-name-length))
teletex-common-name EXTENSION-ATTRIBUTE TeletexCommonName ::= 2
TeletexCommonName ::= TeletexString (SIZE (1.^.^.ub-common-name-length))
teletex-organization-name EXTENSION-ATTRIBUTE TeletexOrganizationName ::= 3
TeletexOrganizationName ::= TeletexString (SIZE (1.^.^.ub-organization-name-length))
teletex-personal-name EXTENSION-ATTRIBUTE TeletexPersonalName ::= 4
TeletexPersonalName ::= SET^{ surname [0] TeletexString (SIZE (1.^.^.ub-surname-length)), given-name [1] TeletexString (SIZE (1.^.^.ub-given-name-length)) OPTIONAL, initials [2] TeletexString (SIZE (1.^.^.ub-initials-length)) OPTIONAL, generation-qualifier [3] TeletexString (SIZE (1.^.^.ub-generation-qualifier-length)) OPTIONAL^}
teletex-organizational-unit-names EXTENSION-ATTRIBUTE TeletexOrganizationalUnitNames ::= 5
TeletexOrganizationUnitNames ::= SEQUENCE (SIZE (1.^.^.ub-organizational-units) OF TeletexOrganizationalUnitName
TeletexOrganizationalUnitName ::= TeletexString (SIZE (1.^.^.ub-organizational-unit-name-length))
teletex-domain-defined-attributes EXTENSION-ATTRIBUTE TeletexDomainDefinedAttributes ::= 6
TeletexDomainDefinedAttributes ::= SEQUENCE SIZE (1.^.^.ub-domain-defined-attributes) OF TeletexDomainDefinedAttribute
FIGURA 2/X.411 (parte 32 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
TeletexDomainDefinedAttribute ::= SEQUENCE^{ typeTeletexString (SIZE (1.^.^.ub-domain-defined-attribute-type-length)), value TeletexString (SIZE (1.^.^.ub-domain-defined-attribute-value-length))^}
pds-name EXTENSION-ATTRIBUTE PDSName ::= 7
PDSName ::= PrintableString (SIZE (1.^.^.ub-pds-name-length))
physical-delivery-country-name EXTENSION-ATTRIBUTE PhysicalDeliveryCountryName ::= 8
PhysicalDeliveryCountryName ::= CHOICE^{ x121-dcc-code NumericString (SIZE (ub-country-name-numeric-length)), iso-3166-alpha2-code PrintableString (SIZE (ub-country-name-alpha-length))^}
postal-code EXTENSION-ATTRIBUTE PostalCode ::= 9
PostalCode ::= CHOICE^{ numeric-code NumericString (SIZE (1.^.^.ub-postal-code-length)), printable-code PrintableString (SIZE (1.^.^.ub-postal-code-length))^}
physical-delivery-office-name EXTENSION-ATTRIBUTE PhysicalDeliveryOfficeName ::= 10
PhysicalDeliveryOfficeName ::= PDS Parameter
physical-delivery-office-number EXTENSION-ATTRIBUTE PhysicalDeliveryOfficeNumber ::= 11
PhysicalDeliveryOfficeNumber ::= PDS Parameter
extension-OR-address-components EXTENSION-ATTRIBUTE ExtensionORAddressComponents ::= 12
FIGURA 2/X.411 (parte 33 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
ExtensionORAddressComponents ::= PDS Parameter
physical-delivery-personal-name EXTENSION-ATTRIBUTE PhysicalDeliveryPersonalName ::= 13
PhysicalDeliveryPersonalName ::= PDS Parameter
physical-delivery-organization-name EXTENSION-ATTRIBUTE PhysicalDeliveryOrganizationName ::= 14
PhysicalDeliveryOrganizationName ::= PDS Parameter
extension-physical-delivery-address-components EXTENSION-ATTRIBUTE ExtensionPhysicalDeliveryAddressComponents ::= 15
ExtensionPhysicalDeliveryAddressComponents ::= PDS Parameter
unformatted-postal-address EXTENSION-ATTRIBUTE UnformattedPostalAddress ::= 16
UnformattedPostalAddress ::= SET^{ printable-address SEQUENCE SIZE (1.^.^.ub-pds-physical-address-lines) OF PrintableString (SIZE (1.^.^.ub-pds-parameter-length)) OPTIONAL, teletex-string TeletexString (SIZE (1.^.^.ub-unformatted-address-length)) OPTIONAL^}
street-address EXTENSION-ATTRIBUTE StreetAddress ::= 17
StreetAddress ::= PDS Parameter
FIGURA 2/X.411 (parte 34 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
post-office-box-address EXTENSION-ATTRIBUTE PostOfficeBoxAddress ::= 18
PostOfficeBoxAddress ::= PDS Parameter
poste-restante-address EXTENSION-ATTRIBUTE PosteRestanteAddress ::= 19
PosteRestanteAddress ::= PDS Parameter
unique-postal-name EXTENSION-ATTRIBUTE UniquePostalName ::= 20
UniquePostalName ::= PDS Parameter
local-postal-attributes EXTENSION-ATTRIBUTE LocalPostalAttributes ::= 21
LocalPostalAttributes ::= PDS Parameter
PDS Parameter ::= SET printable-string PrintableString (SIZE (1.^.^.ub-pds-parameter-length)) OPTIONAL, teletex-string TeletexString (SIZE (1.^.^.ub-pds-parameter-length)) OPTIONAL^}
extended-network-address EXTENSION-ATTRIBUTE ExtendedNetworkAddress ::= 22
ExtendedNetworkAddress ::= CHOICE^{ e163-4-address SEQUENCE^{ number [0] NumericString (SIZE (1.^.^.ub-e163-4-number-length)), sub-address [1] NumericString (SIZE (1.^.^.ub-e163-4-sub-address-length)) OPTIONAL^} psap-address [0] PresentationAddress^}
terminal-type EXTENSION-ATTRIBUTE TerminalType ::= 23
FIGURA 2/X.411 (parte 35 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
TerminalType ::= INTEGER^{
telex (3),
teletex (4),
g3-facsimile (5),
g4-facsimile (6),
ia5-terminal (7),
videotex (8)^}^(0.^.^.ub-integer-options)
FIGURA 2/X.411 (parte 36 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Tipos de información codificada
EncodedInformationTypes ::= [APPLICATION 5] SET^{
built-in-encoded-information-types [0] BuiltInEncodedInformationTypes,
non-basic-parameters COMPONENTS OF NonBasicParameters,
external-encoded-information-types [4]
ExternalEncodedInformationTypes OPTIONAL
^}
--
Tipos de información codificada incorporados
Built-inEncodedInformationTypes ::= BIT STRING^{
undefined (0),
telex (1),
ia5-text (2),
g3-facsimile (3),
g4-class-1 (4),
teletex (5),
videotex (6),
voice (7),
sfd (8),
mixed-mode (9)^}
(SIZE
(0.^.^.ub-built-in-encoded-information-types))
--
Parámetros no-básicos
NonBasicParameters ::= SET^{ g3-facsimile [1]G3FacsimileNonBasicParameters DEFAULT^{^}, teletex [2] TeletexNonBasicParameters DEFAULT^{^}, g4-class-1-and-mixed-mode [3] G4Class1AndMixedModeNonBasicParameters OPTIONAL^}
G3FacsimileNonBasicParameters ::= BIT STRING^{
two-dimensional (8),
fine-resolution (9),
unlimited-length (20),
b4-length (21),
a3-width (22),
b4-width (23),
uncompressed (30)^}--
según se define en la
Recomendación T.30
TeletexNonBasicParameters ::= SET^{
graphic-character-sets [0] TeletexString OPTIONAL,
control-character-sets [1] TeletexString OPTIONAL,
page-formats [2] OCTET STRING OPTIONAL,
miscellaneous-terminal-capabilities [3] TeletexString OPTIONAL,
private-use [4] OCTET STRING OPTIONAL-- maximum ub-teletex-private-use-length
octets --^}
--
según se define en la Recomendación T.62
FIGURA 2/X.411 (parte 37 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
G4Class1AndMixedModeNonBasicParameters ::= PresentationCapabilities
PresentationCapabilities ::= ANY --
según se define en
las Recomendaciones T.400 T.503 y T.501
--
Tipos de información codificada externos
ExternalEncodedInformationTypes ::= SET SIZE (1.^.^.ub-encoded-information-types) OF ExternalEncodedInformationType
ExternalEncodedInformationTypes ::= OBJECT IDENTIFIER
FIGURA 2/X.411 (parte 38 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
--
Testigo
Token ::= SEQUENCE^{ token-type-identifier [0] TOKEN, token [1] ANY DEFINED BY token-type-identifier^}
TOKEN MACRO ::= BEGIN
TYPE NOTATION ::= type^|^empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
END -- of TOKEN
asymmetric-token TOKEN AsymmetricToken ::= id-tok-asymmetricToken
AsymmetricToken ::= SIGNED SEQUENCE^{ signature-algorithm-identifier AlgorithmIdentifier, recipient-name RecipientName, time Time, signed-data [0] TokenData OPTIONAL, encryption-algorithm-identifier [1] AlgorithmIdentifier OPTIONAL, encrypted-data [2] ENCRYPTED TokenData OPTIONAL^}
TokenData ::= SEQUENCE^{ type [0] TOKEN-DATA, value [1] ANY DEFINED BY type^}
TOKEN-DATA MACRO ::= BEGIN
TYPE NOTATION ::= type^|^empty VALUE NOTATION ::= value (VALUE INTEGER)
END -- TOKEN-DATA
bind-token-signed-data TOKEN-DATA BindTokenSignedData ::=
BindTokenSignedData ::= RandomNumber
FIGURA 2/X.411 (parte 39 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
RandomNumber ::= BIT STRING
message-token-signed-data TOKEN-DATA MessageTokenSignedData ::= 2
MessageTokenSignedData ::= SEQUENCE^{ content-confidentiality-alogorithm-identifier [0] ContentConfidentialityAlgorithmIdentifier OPTIONAL, content-integrity-check [1] ContentIntegrityCheck OPTIONAL, message-security-label [2] MessageSecurityLabel OPTIONAL, proof-of-delivery-request [3] ProofOfDeliveryRequest OPTIONAL, message-sequence-number [4] INTEGER OPTIONAL^}
message-token-encrypted-data TOKEN-DATA MessageTokenEncryptedData ::= 3
MessageTokenEncryptedData ::= SEQUENCE^{ content-confidentiality-key [0] EncryptionKey OPTIONAL, content-integrity-check [1] ContentIntegrityCheck OPTIONAL, message-security-label [2] MessageSecurityLabel OPTIONAL, content-integrity-key [3] EncryptionKey OPTIONAL, message-sequence-number [4] INTEGER OPTIONAL^}
EncryptionKey ::= BIT STRING
--
Etiqueta de seguridad
Security label ::= SET^{ security-policy-identifier SecurityPolicyIdentifier OPTIONAL, security-classification SecurityClassification OPTIONAL, privacy-mark PrivacyMark OPTIONAL, security-categories SecurityCategories OPTIONAL^}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER^{ unmarked (0), unclassified (1), restricted (2), confidential (3), secret (4), top-secret (5)^}^ (0.^.^.ub-integer-options)
FIGURA 2/X.411 (parte 40 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
PrivacyMark ::= PrintableString (SIZE (1.^.^.ub-privacy-mark-length))
SecurityCategories ::= SET (SIZE (1.^.^.ub-security-categories) OF SecurityCategory
SecurityCategory ::= SEQUENCE^{ type [0] SECURITY-CATEGORY, value [1] ANY DEFINED BY type^}
SECURITY-CATEGORY MACRO ::= BEGIN
TYPE NOTATION ::= type^|^empty VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
END --
de CATEGORíA-SEGURIDAD
END --
del servicio abstracto STRM
FIGURA 2/X.411 (parte 41 de 41)
Definición de sintaxis
abstracta del servicio abstracto del STRM
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.103.S)
(SANS FORMULE)
Tableaux: 5 - Tabulateurs: 0
Formules: 0
(1BT) (BT..)
(87.TE.11.S)
(A1.23s) / [26s]
FOLIOS: 363 - 382
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 04.09.89 SJ
ID + LASER + diskette MAJ 04.10.89 JG
Corr. LASER (1re épreuve) = 3eme 25.10.89 UT
Espaces réservés + Transfert + Impr. 31.10.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 9.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 9.11.89 PC
BAT du 21/XI/89 21.11.89 PV
MAJ s/disquettes 7.12.89 CD
SECCIóN 3 - SERVICIO ABSTRACTO DE AGENTE DE TRANSFERENCIA DE MENSAJES
10 Modelo perfeccionado del sistema de
transferencia de mensajes
En el 6 se describe el STRM como un objeto, sin referencia a su estructura interna. El presente punto perfecciona el modelo del STRM, y expone sus objetos constituyentes y los puertos compartidos entre ellos.
La figura 3»X.411 proporciona un modelo del STRM y revela su estructura interna.
El STRM consta de una colección de objetos agente-transferencia-mensaje (ATM), que cooperan entre si para formar el STRM y ofrecer a sus usuarios el servicio abstracto de STRM. Los ATM realizan las funciones activas del STRM, es decir la transferencia de mensajes, sondas e informes, generación de informes, y conversión de contenidos.
Los objetos del ATM tienen igualmente puertos, algunos de los cuales son concretamente los que resultan igualmente visibles en la frontera del objeto del STRM, es decir, puertos-remisión, puertos-entrega y puertos-administración. Sin embargo, los ATM tienen igualmente otro tipo de puerto, el puerto-transferencia, que se ocupa de la distribución del servicio abstracto del STRM entre los ATM y que no resulta visible en la frontera del objeto STRM.
El puerto-transferencia permite a un ATM transferir mensajes, sondas e informes a otro ATM. En general, puede que haya que transferir un mensaje, una sonda o un informe, un cierto número de veces entre diferentes ATM hasta alcanzar el destino deseado.
Si se dirige un mensaje a múltiples destinatarios servidos por varios ATM diferentes, debe transferirse el mensaje a través del STRM a lo largo de varios trayectos diferentes. Desde la perspectiva del ATM que transfiere dicho mensaje, se pueden alcanzar algunos destinatarios a través de un trayecto mientras que a otros se llega a través de otro distinto. En dicho ATM, se crean dos copias del mensaje, transfiriéndose cada una de ellas al próximo ATM a lo largo de su trayecto respectivo. La copia y ramificación del mensaje se repiten hasta que cada copia haya alcanzado un ATM de destino final, donde pueda entregarse el mensaje a uno o más usuarios-STRM destinatarios.
Cada ATM a lo largo de un trayecto tomado por un mensaje, es responsable de la entrega o transferencia del mensaje a un subconjunto determinado de destinatarios-especificados-originalmente. Otros ATM se encargan de la entrega o transferencia a los restantes destinatarios, utilizando copias de los mensajes creados a lo largo del camino.
Los ATM generan informes sobre la entrega o no-entrega de un mensaje dirigido a uno o más usuarios STRM destinatarios, de conformidad con la petición del originador del mensaje y del ATM-que-origina. Un ATM puede generar un informe-entrega al entregar con éxito una copia de un mensaje a un usuario-STRM destinatario. Puede generar un informe-no-entrega al determinar que una copia de un mensaje resulta imposible de entregar a uno o más destinatarios, es decir, el ATM no ha podido entregar el mensaje a los usuarios-STRM destinatarios, o no puede transferir el mensaje a un ATM adyacente que tomaría la responsabilidad de entregar o transferir el mensaje ulteriormente.
Para una mayor eficacia, un ATM puede generar un informe único, combinado, que sirva para varias copias de un único mensaje con múltiples destinatarios, del cual es responsable. Pueden combinarse conjuntamente tanto los informes-entrega como los informes-no-entrega. Sin embargo, para combinar los informes de esta manera, debe realizarse la misma conversión de contenido, si ha lugar, en los mensajes de todos los destinatarios a que se refiere el informe.
Los informes que se refieren a copias del mismo mensaje con múltiples destinatarios pero que fueron generados por ATM diferentes no se combinan en ningún ATM intermedio, sino que permanecen separados.
Cuando se necesite, un ATM puede realizar una conversión de contenido. Cuando ni la petición del usuario-STRM originador, ni la del usuario-STRM destinatario prohíben la conversión, un ATM puede realizar la conversión implícita de los tipos-información-codificada de un mensaje para adaptarse a los tipos-información-codificada a los que puede recibir el usuario-STRM destinatario. El usuario STRM originador puede solicitar explícitamente la conversión de los tipos-información-codificada específicos para un determinado usuario-STRM destinatario.
Las puertas-remisión, -entrega y -administración de un ATM que resultan igualmente visibles en la frontera del STRM se definen en la sección 2 de esta Recomendación. Los restantes puntos de esta sección definen el puerto-transferencia de un ATM, y los procedimientos realizados por los ATM para garantizar una correcta operación distribuida del STRM.
Figura 3/X.411, p.
11 Visión de conjunto del servicio abstracto
del agente de transferencia de mensajes
En la sección 2 se define el servicio abstracto STRM proporcionado por los puertos-remisión, -entrega y -administración de un ATM. En este punto, se definen las operaciones-abstractas siguientes que proporcionan los puertos-transferencia de los ATM:
Vinculación-ATM y desvinculación-ATM
a)vinculación-ATM
b)desvinculación-ATM.
Operaciones-abstractas de puerto de transferencia
c)transferencia-mensaje
d)transferencia-sonda
e)transferencia-informe.
11.1
Vinculación-ATM y
desvinculación-ATM
Vinculación-ATM
permite a un ATM establecer una
asociación con otro ATM. En el contexto de una asociación establecida pueden
invocarse únicamente operaciones-abstractas distintas de vinculación-ATM.
Desvinculación-ATM
permite liberar una asociación
establecida por el iniciador de la asociación.
11.2
Operaciones-abstractas de puerto de
transferencia
La operación-abstracta
transferencia-mensaje
permite a
un ATM transferir un mensaje a otro ATM.
La operación-abstracta
transferencia-sonda
permite a un
ATM transferir una sonda a otro ATM.
La operación abstracta
transferencia-informe
permite a
un ATM transferir un informe a otro ATM.
12
Definición del servicio abstracto
de agente de transferencia de mensajes
En el 8 se define el servicio abstracto de STRM. En este punto, se define la semántica de los parámetros del servicio abstracto proporcionados por los puertos-transferencia de los ATM.
En el 12.1 se define vinculación-ATM y desvinculación-ATM. El 12.2 define el puerto-transferencia. En el 12.3 se definen algunos tipos de parámetros comunes.
La sintaxis-abstracta del servicio abstracto de ATM se define en el 13 .
12.1
Vinculación-ATM y
desvinculación-ATM
Este punto define los servicios-abstractos utilizados para establecer y liberar asociaciones entre ATM.
12.1.1
Vinculación-abstracta y
desvinculación-abstracta
Este punto define las siguientes vinculación-abstracta y desvinculación-abstracta:
a)vinculación-ATM
b)desvinculación-ATM.
12.1.1.1
Vinculación-ATM
Vinculación-ATM permite a un ATM establecer una asociación con otro ATM.
Vinculación-ATM establece las
credenciales
de los ATM
para interaccionar, y el
contexto-aplicación
y el
contexto-seguridad
de la asociación. únicamente el iniciador
de una asociación puede liberarla (utilizando desvinculación-ATM).
Las operaciones-abstractas diferentes de vinculación-ATM pueden invocarse únicamente en el contexto de una asociación establecida.
La finalización con éxito de vinculación-ATM significa el establecimiento de una asociación.
La interrupción de vinculación-ATM por un error-vinculación indica que la asociación no se ha establecido.
12.1.1.1.1
Argumentos
El cuadro 27»X.411 enumera los argumentos de vinculación-ATM y para cada argumento califica su presencia e indica el punto donde se define el argumento.
Cuadro 27/X.411 [T27.411], p.
12.1.1.1.1.1
Nombre-iniciador
Este argumento contiene un nombre para el iniciador de la asociación. Puede ser generado por el iniciador de la asociación.
El nombre es un
nombre-ATM
.
12.1.1.1.1.2
Credenciales-iniciador
Este argumento contiene las
credenciales
del iniciador
de la asociación. Puede ser generado por el iniciador de la asociación.
Las
credenciales-iniciador
pueden utilizarse por el
respondedor para autenticar la identidad del iniciador (véase Recomendación
X.509).
Si se propone únicamente una autenticación-simple, las
credenciales-iniciador
constan de una contraseña simple
asociada al
nombre-iniciador
.
Si se utiliza una autenticación-fuerte, las
credenciales-iniciador
constan de un
distintivo-vinculación-iniciador
y, opcionalmente un
certificado-iniciador
.
El
testigo-vinculación-iniciador
es un
testigo
generado por el iniciador de la asociación. Si el
testigo-vinculación-iniciador
es un
testigo-asimétrico
, los
datos firmados
incluyen un
número-aleatorio
. Los
datos
cifrados
de un
testigo-asimétrico
pueden utilizarse
para transportar información secreta relativa-seguridad (por ejemplo, una o más
claves-cifrados-simétricas) utilizadas para asegurar la asociación, o pueden
estar ausentes de
testigo-vinculación-iniciador
.
El
certificado-iniciador
es un
certificado
del iniciador de la asociación, generado por una
fuente de confianza (por ejemplo una autoridad-certificación). Puede ser
suministrado por el iniciador de la asociación, si el
testigo-vinculación-iniciador
es un
testigo-asimétrico
. El
certificado-iniciador
puede utilizarse para transportar una
copia verificada de la clave-cifrados-asimétrica-pública
(
clave-pública-sujeto
) del iniciador de la asociación. La
clave-cifrado-pública-asimétrica del iniciador puede ser utilizada por el
respondedor para calcular el
testigo-vinculación-respondedor
. Si se sabe que el
respondedor posee, o tiene acceso al
certificado
del
iniciador (por ejemplo a través de la guía), puede omitirse el
certificado-iniciador
.
12.1.1.1.1.3
Contexto-seguridad
Este argumento indica el
contexto-seguridad
que propone
para funcionar el iniciador de la asociación. Puede ser generado por el
iniciador de la asociación.
El
contexto-seguridad
consta de una o más
etiquetas-seguridad
que definen la sensibilidad de las
interacciones que pueden producirse entre los ATM durante la duración de la
asociación, en línea con la política-seguridad en vigor. El
contexto-seguridad
debe ser uno de los autorizados por las
etiquetas-seguridad
asociadas a los DG (ATM).
Si no se establecen los
contextos-seguridad
entre los
ATM, la sensibilidad de las interacciones que pueden producirse entre los ATM
puede quedar a la discreción del invocador de una operación abstracta.
12.1.1.1.2
Resultados
El cuadro 28»X.411 enumera los resultados de vinculación-ATM, y para cada resultado califica su presencia e indica el punto donde se define el resultado.
Cuadro 28/X.411 [T28.411], p.
12.1.1.1.2.1
Nombre-respondedor
Este argumento contiene un nombre para el respondedor de la asociación. Puede ser generado por el respondedor de la asociación.
El nombre es un
nombre-ATM
.
12.1.1.1.2.2
Credenciales-respondedor
Este argumento contiene las
credenciales
del respondedor
de la asociación. Puede ser generado por el respondedor de la asociación.
Las
credenciales-respondedor
pueden utilizarse por el
iniciador para autenticar la identidad del respondedor (véase Recomendación
X.509).
Si se propone únicamente una autenticación-simple, las
credenciales-respondedor
constan de una
contraseña
simple asociada al
nombre-respondedor.
Si se utiliza una autenticación-fuerte, las
credenciales-respondedor
constan de un
testigo-vinculación-respondedor
. El
testigo-vinculación-respondedor
es un
testigo
generado por el respondedor de la asociación. El
testigo-vinculación-respondedor
debe ser del mismo tipo de
testigo
que el
testigo-vinculación-iniciador
. Si el
testigo-vinculación-respondedor
es un
testigo-asimétrico
, los
datos-firmados
incluyen un
número-aleatorio
, (que puede estar relacionado
con el
número-aleatorio
proporcionado en el
distintivo-vinculación-iniciador
). Los
datos-cifrados
de un
testigo-asimétrico
pueden utilizarse para transportar información relativa-seguridad (por ejemplo,
una o más claves-cifrado-simétricas) utilizadas para proporcionar seguridad a
la asociación, o pueden estar ausentes del
testigo-vinculación-respondedor
.
12.1.1.1.3
Errores-vinculación
Los errores-vinculación que pueden interrumpir la operación vinculación-ATM se definen en el 12.1.2 .
12.1.1.2
Desvinculación-ATM
Desvinculación-ATM permite liberar una asociación establecida por el iniciador de la asociación.
12.1.1.2.1
Argumentos
El servicio desvinculación-ATM no tiene argumentos.
12.1.1.2.2
Resultados
El servicio desvinculación-ATM devuelve un resultado vacío como indicación de la liberación de la asociación.
12.1.1.2.3
Errores-desvinculación
No existen errores-desvinculación que puedan interrumpir la operación desvinculación-ATM.
12.1.2
Errores-vinculación
Esta cláusula define los siguientes errores-vinculación:
a)error-autenticación
b)ocupado
c)modo-diálogo-inaceptable
d)contexto-seguridad-inaceptable.
12.1.2.1
Error-autenticación
El error-vinculación de error-autenticación notifica que no puede
establecerse una asociación debido a un error de autenticación; las
credenciales
del iniciador no son aceptables o están
indebidamente especificadas.
El error-vinculación de error-autenticación no tiene parámetros.
12.1.2.2
Ocupado
El error-vinculación ocupado informa que una asociación no puede establecerse porque el respondedor está ocupado.
El error-vinculación ocupado no tiene parámetros.
12.1.2.3
Modo-diálogo-inaceptable
El error-vinculación modo-diálogo-inaceptable informa que el modo-diálogo propuesto por el iniciador de la asociación resulta inaceptable para el respondedor (véase el 12 de la Recomendación X.419).
El error-vinculación de modo-diálogo-inaceptable no tiene parámetros.
12.1.2.4
Contexto-seguridad-inaceptable
El error-vinculación contexto-seguridad-inaceptable informa que el
contexto-seguridad
propuesto por el iniciador de la
asociación resulta inaceptable para el respondedor.
El error-vinculación contexto-seguridad inaceptable no tiene parámetros.
12.2
Puerto de transferencia
Este punto define las operaciones-abstractas y los errores-abstractos que se producen en un puerto-transferencia.
12.2.1
Operaciones-abstractas
Este punto define las siguientes operaciones-abstractas de puerto-transferencia:
a)transferencia-mensaje
b)transferencia-sonda
c)transferencia-informe.
12.2.1.1
Transferencia-mensaje
La operación-abstracta transferencia-mensaje permite a un ATM transferir un mensaje a otro ATM.
12.2.1.1.1
Argumentos
El cuadro 29»X.411 enumera los argumentos de la operación-abstracta transferencia-mensaje y para cada argumento califica su presencia e identifica el punto donde se define el argumento.
12.2.1.1.1.1
Identificador-mensaje
Este argumento consta de un
identificador-STRM
que
distingue el mensaje de los restantes mensajes, sondas e informes en el
interior del STRM. Deberá ser generado por el ATM-que-origina del mensaje, y
tendrá el mismo valor que el
identificador-remisión-mensaje
suministrado al originador del mensaje cuando se remitió éste, y que el
identificador-entrega-mensaje
suministrado a los
destinatarios del mensaje cuando se entrega el mensaje.
Al hacer copias de un mensaje para encaminarlo a múltiples destinatarios a
través de diferentes ATM, cada copia del mensaje lleva el
identificador-mensaje
del original. Pueden distinguirse las
copias entre sí mediante el
número-destinatario-especificado-originalmente
y los
correspondientes argumentos de
responsabilidad
, que
especifican a qué destinatario o destinatarios ha de entregarse cada copia.
12.2.1.1.1.2
Información-bilateral-por-dominio
Este argumento contiene la información destinada a los DG que encontrará el mensaje al ser transferido a través del STRM. Puede ser generado por el DG-originador del mensaje.
Este argumento puede contener cero o más elementos, cada uno de los cuales incluye:
-la
información-bilateral
destinada a un DG;
-el
nombre-país
, el
nombre-dominio-administración
y, opcionalmente, el
identificador-dominio-privado
del DG al que va destinado la
información-bilateral
.
12.2.1.1.1.3
Información-rastreo
Este argumento documenta las acciones realizadas sobre el mensaje (o sonda o informe) por cada DG a través del cual pasa el mensaje al ser transferido a través del STRM (véase el 12.3.1 ). Debe ser generado por cada DG a través del cual pasa el mensaje (o sonda o informe).
12.2.1.1.1.4
Información-rastreo-interna
Este argumento documenta las acciones realizadas sobre el mensaje (o sonda o informe) por cada ATM a través del cual pasa el mensaje (o sonda o informe) al ser transferido en el interior de un DG (véase el 12.3.1 ). Debe ser generado por cada ATM a través del cual pasa el mensaje (o sonda o informe) en el interior de un DG.
Este argumento no será suministrado por el invocador de la operación-abstracta transferencia-mensaje al transferir un mensaje a otro DG a menos que se deba a un acuerdo bilateral entre DG.
12.2.1.1.1.5
Número-destinatario-especificado-originalmente
Este argumento, combinado con el
identificador-mensaje
,
identifica sin ambigüedad la copia del mensaje entregada a cada destinatario.
Debe ser generado por el ATM-que-origina del mensaje. Se especifica un valor
diferente de este argumento para cada destinatario de este mensaje.
El
número-destinatario-especificado-originalmente
es un
valor entero en el intervalo comprendido entre uno y el número de
destinatarios-especificados-originalmente.
Tableau 29/X.411 [T29.411], p. 4
Existe una relación biunívoca entre un determinado valor del
número-destinatario-especificado-originalmente
y un
determinado
nombre-destinatario
en el momento de la
remisión-mensaje; no debería suponerse que esta es una relación singular en el
momento de la entrega-mensaje. Es decir, puede utilizarse un valor del
número-destinatario-especificado-originalmente
para
distinguir un
nombre-destinatario
especificado
originalmente, pero no un destinatario real que recibirá el mensaje.
12.2.1.1.1.6
Responsabilidad
Este argumento indica si el ATM-receptor debe tener la responsabilidad de entregar el mensaje a un destinatario o de transferirlo a otro ATM para su entrega subsiguiente al destinatario. Debe ser generado por el ATM-emisor. Puede especificarse un valor diferente de este argumento para cada destinatario del mensaje.
Este argumento puede tener uno de los siguientes valores:
responsable
o
no responsable
.
12.2.1.1.1.7
Tiempo-entrega-diferida
Este argumento se define en el 8.2.1.1.1.12 . Puede aparecer en un mensaje en el puerto-transferencia si existe un acuerdo bilateral de que un ATM distinto del ATM-que-origina del mensaje diferirá la entrega del mensaje.
12.2.1.1.1.8
Petición-informe-ATM-que-origina
Este argumento indica el tipo de informe solicitado por el ATM-que-origina. Debe ser generado por el ATM-que-origina del mensaje. Puede especificarse un valor diferente de este argumento para cada destinatario del mensaje.
Este argumento puede tomar uno de los siguientes valores:
-
informe-no-entrega
: se devuelve un informe únicamente en
el caso de no-entrega, y contiene únicamente la
última-información-rastreo
;
-
informe
: se devuelve un informe tanto en el caso de
entrega como de no-entrega y contiene únicamente la
última-información-rastreo;
-
informe-auditado
: se devuelve un informe tanto en el
caso de entrega como de no-entrega, y contiene toda la
información-rastreo
.
El argumento de
petición-informe-ATM-que-origina
deberá
especificar al menos el nivel del informe especificado en el argumento de
petición-informe-originador
, siendo el orden creciente de
los niveles de informe:
no-informe
,
informe-no-entrega
,
informe
,
informe-auditado
.
12.2.1.1.2
Resultados
La operación-abstracta transferencia-mensaje no devuelve resultado.
12.2.1.1.3
Errores-abstractos
No existen errores-abstractos que puedan interrumpir la operación- abstracta transferencia-mensaje.
12.2.1.2
Transferencia-sonda
La operación-abstracta transferencia-sonda permite a un ATM transferir una sonda a otro ATM.
12.2.1.2.1
Argumentos
El cuadro 30»X.411 enumera los argumentos de la operación-abstracta transferencia-sonda y para cada argumento califica su presencia e identifica el punto donde se define el argumento.
12.2.1.2.1.1
Identificador-sonda
Este argumento contiene un
identificador-STRM
que
distingue la sonda de otros mensajes, sondas e informes en el interior del
STRM. Debe ser generado por el ATM-que-origina de la sonda, y debe tener el
mismo valor que el
identificador-remisión-sonda
suministrado
al originador de la sonda cuando se remitió ésta.
12.2.1.2.2
Resultados
La operación-abstracta transferencia-sonda no devuelve resultados.
12.2.1.2.3
Errores-abstractos
No existen errores-abstractos que puedan interrumpir la operación-abstracta transferencia-sonda.
Cuadro 30/X.411 [T30.411], p.
12.2.1.3
Transferencia-informe
La operación-abstracta transferencia-informe permite a un ATM transferir un informe a otro ATM.
12.2.1.3.1
Argumentos
El cuadro 31»X.411 enumera los argumentos de la operación-abstracta transferencia-informe, y para cada argumento califica su presencia e identifica el punto donde se define el argumento.
12.2.1.3.1.1
Identificador-informe
Este argumento contiene un
identificador-STRM
que
distingue el informe de otros mensajes, sondas e informes en el interior del
STRM. Debe ser generado por el ATM-que-origina del informe.
12.2.1.3.1.2
Nombre-destino-informe
Este argumento contiene el
nombre-O»D
del destino
inmediato del informe. Debe ser generado por el ATM-que-origina del informe, y
modificado subsiguientemente por los puntos-ampliación de LD si se ha ampliado
alguna LD para añadir destinatarios al sujeto.
El ATM-que-origina del informe debe fijar este argumento en el
nombre-originador
del sujeto si éste no tiene una
historia-ampliación-LD
, o en el último
nombre-O»D
de la
historia-ampliación-LD
si está presente en el sujeto.
Un punto-ampliación de LD puede sustituir su propio
nombre-O»D
en este argumento, por el
nombre-O»D
que precede inmediatamente a su propio
nombre-O»D
en el
originador-e-historia-ampliación-LD
del informe o por algún
otro
nombre-O»D
según la política-informadora de la LD.
12.2.1.3.1.3
Identificador-sujeto
Este argumento contiene el
identificador-mensaje
(o el
identificador- sonda
) del sujeto
(
identificador-STRM
). Debe ser generado por el
ATM-que-origina del sujeto.
12.2.1.3.1.4
Información-rastreo-intermedia-sujeto
Este argumento contiene la
información-rastreo
presente
en el sujeto cuando se transfirió al DG-informador. Debe estar presente si, y
únicamente si se solicitó un informe auditado y confirmado por el
ATM-que-origina del sujeto. Puede ser generado por el ATM-informador.
Nota
- La inclusión en la
información-rastreo-intermedia sujeto
de la
información-rastreo-interna
presente en el sujeto cuando se
transfirió al ATM-informador queda para ulterior estudio.
12.2.1.3.1.5
Tiempo-llegada
Este argumento contiene el
tiempo
en que el sujeto
indicó al DG que hiciera el informe. Debe ser generado por el DG-originador del
informe. Puede especificarse un valor diferente de este argumento para cada
destinatario del sujeto a que se refiere el informe.
12.2.1.3.1.6
Información adicional
La especificación del contenido de este argumento se realiza mediante acuerdo bilateral entre DG.
12.2.1.3.2
Resultados
La operación-abstracta transferencia-informe no devuelve resultados.
12.2.1.3.3
Errores abstractos
No existen errores-abstractos que pueden interrumpir la operación-abstracta transferencia-informe.
12.2.2
Errores abstractos
El puerto-transferencia no tiene errores abstractos.
Cuadro 31/X.411 [T31.411], p.
12.3
Tipos de parámetros comunes
Este punto define cierto número de tipos de parámetros comunes del servicio abstracto de ATM.
12.3.1
Información-rastreo e
información-rastreo-interna
La
información-rastreo
documenta las acciones efectuadas
sobre un mensaje, sonda o informe por cada DG, a través del cual pasa al ser
transferido a través del STRM.
La
información-rastreo-interna
documenta las acciones
efectuadas sobre un mensaje, sonda o informe por cada ATM, a través del cual
pasa al ser transferido a través de un DG. La
información-rastreo-interna
deberá ser eliminada del
mensaje, sonda o informe antes de ser transferido fuera de un DG, a menos que
exista un acuerdo bilateral entre las DG.
La
información-rastreo
(o
información-rastreo-interna
) consta de una secuencia de
elementos-información-rastreo
(o
elementos-información-rastreo-interna
). El primer
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) es el suministrado por
el DG-(o ATM-) que-origina del mensaje, sonda o informe. El segundo
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) es el suministrado por
el siguiente DG (o ATM) encontrado por el mensaje, sonda o informe, y así
sucesivamente. Cada DG (o ATM) añade su elemento
información-rastreo
(o
elemento-información-rastreo-interna
) al final de la
secuencia existente. La
información-rastreo
la añade el
primer ATM que encuentren el mensaje, la sonda o el informe en cada DG por el
que atraviesen.
Cada
elemento-información-rastreo
incluye el
identificador-dominio-global
del DG que suministra el
elemento-información-rastreo
.
Cada
elemento-información-rastreo-interna
incluye el
nombre-ATM
del ATM que suministra el
elemento-información-rastreo-interna
y el
identificador-dominio-global
del DG al que pertenece el ATM.
Cada
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) incluye el
tiempo-llegada
en el cual el mensaje, sonda o informe entró
en el DG (o ATM). En el caso del DG-(o ATM-) que-origina del mensaje, sonda o
informe, el
tiempo-llegada
es el tiempo de la
remisión-mensaje, remisión-sonda o generación del informe, respectivamente.
Cada
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) especifica la
acción-encaminamiento
que el DG (o ATM) que suministra el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) adoptó respecto del
mensaje, sonda o informe.
Retransmitido
constituye la
acción-encaminamiento
normal de transferencia de mensaje,
sonda o informe a otro DG o ATM.
Reencaminado
indica que se
había realizado previamente un intento de reencaminar el mensaje, sonda o
informe hacia un
dominio-deseado
(o
ATM-deseado
); se incluye el
identificador-dominio-global
del
dominio-deseado
en el
elemento-información-rastreo
; si el intento de
reencaminamiento iba dirigido hacia otro ATM dentro del mismo DG, se incluye
entonces el
nombre-ATM
del
ATM-deseado
en
el
elemento-información-rastreo-interna
; si el intento de
reencaminamiento iba dirigido hacia otro DG se incluye en el
elemento-información-rastreo-interna
el
identificador-dominio-global
en vez de un
nombre-ATM
.
Cada
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) especifica igualmente
cualquier
acción-adicional
que el DG (o ATM) que suministra
el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) efectuó con respecto
al mensaje, sonda o informe. Las indicaciones de cualquiera de estas
acciones-adicionales
que aparecen en los
elementos-información-rastreo-interna
durante la travesía de
un DG deberán reflejarse igualmente en los
elementos-información-rastreo
correspondientes a la travesía
del DG.
Si la entrega diferida provocó que el DG (o ATM) que suministra el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) retuviera el mensaje
durante un periodo de tiempo, el
tiempo-diferido
en que
inició el tratamiento del mensaje para su entrega o transferencia se incluye
igualmente en el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
). Este parámetro no
está presente en los
elementos-información-rastreo
(o
elementos-información-rastreo-interna
) de las sondas e
informes.
Si el DG (o ATM) que suministra el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) somete un mensaje a
conversión, los
tipos-información-codificada-convertidos
resultantes de la conversión se incluyen igualmente en
elemento-información-rastreo
(o
elemento-información-rastreo-interna
). Para una sonda, un DG
que hubiera convertido el mensaje-sujeto indica en su
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) los
tipos-información-codificada
que el mensaje-sujeto
contendría después de la conversión. Este parámetro no está presente en la
información-rastreo
(o
elemento-información-rastreo-interna
) de los informes.
Si el DG (o ATM) redirige un mensaje o una sonda (a cualquiera, pero no
necesariamente a todos los destinatarios de un mensaje o una sonda), se indica
redirigido
en el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
). Este parámetro no
está presente en la
información-rastreo
(o
información-rastreo-interna
) de los informes.
Si el DG (o ATM) amplía la LD de un mensaje o de una sonda, se indica
ampliada
en el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
). Si el DG (o ATM) es
un punto-ampliación de LD y sustituye su propio
nombre-O»D
en el
nombre-destino-informe
de un informe por otro
nombre-O»D
(véase el
12.2.1.3.1.2
), se indica
ampliada
en el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) del informe.
Un DG (o ATM) realiza la detección y supresión de un bucle cuando se recibe
un mensaje, sonda o informe procedente de otro DG (o ATM). Los mensajes, sondas
e informes pueden volver a entrar legítimamente en un DG (o ATM) debido a
varias razones (
reencaminado
, etc.) y en consecuencia, un
mensaje, sonda o informe puede tener
elementos-información-rastreo
(o
elementos-información-rastreo-interna
) disjuntos procedentes
del mismo DG (o ATM). Cada vez que un mensaje, sonda o informe se transfiere a
través de un DG (o ATM), la generación de los
elementos-información-rastreo
(o
elementos-información-rastreo-interna
) se ejecuta de la
forma siguiente:
i)se agrega un
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) marcado como
retransmitido
;
ii)si se ha de producir una tentativa de reencaminamiento, el
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) añadido en i) se
cambia por
reencaminado
[y el
número de
elemento-información-rastreo
(o
elementos-información-rastreo-interna
) añadidos por el DG (o
ATM) para esta travesía del DG (o ATM) permanece en uno];
iii)si se producen tentativas subsiguientes de reencaminamiento, se añade un
nuevo
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) (marcado como
reencaminado
) para reflejar cada nueva tentativa de
reencaminamiento.
Pueden producirse varias tentativas de reencaminamiento hacia el mismo DG (o ATM).
Cada
elemento-información-rastreo
(o
elemento-información-rastreo-interna
) añadido por un DG (o
ATM) puede contener indicaciones de
acciones-adicionales
realizadas por el DG (o ATM) sobre el mensaje o sonda [es decir
tiempo-diferido
(no presentes en
información-rastreo
(
información-rastreo-interna
) en las sondas),
tipos-información-codificada-convertidos
,
redirigidos
o
ampliados
].
13
Definición de la sintaxis
abstracta de agente de transferencia de mensajes
La sintaxis-abstracta del servicio abstracto del ATM se define en la figura 4»X.411.
La sintaxis-abstracta del servicio abstracto de ATM se define utilizando la notación de sintaxis-abstracta (NSA.1) definida en la Recomendación X.208, y los convenios de definición del servicio-abstracto definidos en la Recomendación X.407.
La definición de sintaxis-abstracta del servicio abstracto ATM tiene las siguientes partes principales:
-
Prólogo
: declaraciones de las exportaciones desde el
módulo de servicio abstracto ATM, y las importaciones a éste (figura 4»X.411,
parte 1).
-
Perfeccionamiento del STRM, objetos y puertos
:
perfeccionamiento del objeto del STRM, definiciones del objeto del ATM, y su
puerto-transferencia (figura 4»X.411, parte 2).
-
Vinculación-ATM y desvinculación-ATM
: definiciones de
vinculación-ATM y desvinculación-ATM utilizadas para establecer y liberar
asociaciones entre ATM (figura 4»X.411, parte 3).
-
Puerto de transferencia
: definiciones de las
operaciones-abstractas de puerto-transferencia: transferencia-mensaje,
transferencia-sonda, transferencia-informe (figura 4»X.411, parte 4).
-
Sobre de transferencia de mensaje
: definición del
sobre-transferencia-mensaje (figura 4»X.411, partes 5 y 6).
-
Sobre de transferencia de sonda
: definición del
sobre-transferencia-sonda (figura 4»X.411, parte 7).
-
Sobre y contenido de transferencia de informe
:
definición del sobre-transferencia-informe y del
contenido-transferencia-informe (figura 4»X.411, parte 8).
-
Campos de sobre y contenido del informe
: definiciones
de campos de sobre y de contenido del informe (figura 4»X.411, partes 9 y 10).
-
Campos de ampliación
: definiciones de los
campos-ampliación (figura 4»X.411, partes 11 a 12).
-
Tipos de parámetros comunes
: definiciones de los tipos
de parámetros comunes (figura 4»X.411, parte 13).
Nota
- El módulo implica ciertos cambios en el
protocolo P1 definido en la Recomendación X.411 (1984). Estos cambios se
señalan mediante
subrayado
.
Cada
campo-ampliación
definido en la figura 4»X.411
(partes 12 y 13) transporta consigo una indicación sobre su criticidad para la
remisión, transferencia y entrega. El mecanismo de
criticidad
se describe en el
9.1
y los
procedimientos relativos a los
campos-ampliación
y a las
indicaciones de su
criticidad
se definen ulteriormente en el
14
.
MTAAbstractService { joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mta-abstract-service(2) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
--
Exportar todo
IMPORTS
--
Macros del servicio abstracto
REFINE, OBJECT, PORT, ABSTRACT-BIND, ABSTRACT-UNBIND, ABSTRACT-OPERATION
FROM AbstractServiceNotation { joint-iso-ccitt mhs-motis(6) asdc(2) modules(0)
notation(1) }
--
Parámetros del servicio abstracto del STRM
mTS, submission, delivery, administration, InitiatorCredentials,
SecurityContext,
ResponderCredentials, OriginalEncodedInformationTypes, ContentTypes,
ContentIdentifier,
Priority, PerMessageIndicators, DeferredDeliveryTime, CountryName,
AdministrationDomainName,
PrivateDomainIdentifier, ExplicitConversion, ContentLength,
ConvertedEncodedInformationTypes,
ReportType, SupplementaryInformation, EXTENSION, EXTENSIONS,
recipient-reassignment-prohibited,
dl-expansion-prohibited, conversion-with-loss-prohibited, latest-delivery-time,
requested-delivery-method, physical-forwarding-prohibited,
physical-forwarding-address-request,
physical-delivery-modes, registered-mail-type, recipient-number-for-advice,
physical-rendition-attributes,
originator-return-address, physical-delivery-report-request,
originator-certificate, message-token,
content-confidentiality-algorithm-identifier, content-integrity-check,
message-origin-authentication-check,
message-security-label, proof-of-delivery-request, content-correlator,
probe-origin-authentication-check,
redirection-history, dl-expansion-history, originator-and-dl-expansion-history,
reporting-dl-name,
physical-forwarding-address, recipient-certificate, proof-of-delivery,
reporting-MTA-certificate,
report-origin-authentication-check, Content, MTSIdentifier,
GlobalDomainIdentifier, MTAName, Time,
ORAddressAndOptionalDirectoryName
FROM MTSAbstractService { joint-iso-ccitt mhs-motis(6) mts(3) modules(0)
mts-abstract-service(1) }
--^
Identificadores de objetos
id-ot-mta, id-pt-transfer
FROM MTSObjectIdentifiers { joint-iso-ccitt mhs-motis(6) mts(3) modules(0)
object-identifiers(0) }
--
Límites superiores
ub-bit-options, ub-dl-expansions, ub-integer-options, ub-recipients,
ub-redirections, ub-transfers
FROM MTSUpperBounds { joint-iso-ccitt mhs-motis(6) mts(3) modules(0)
upper-bounds(3) };
FIGURA 4/X.411 (Parte 1 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Perfeccionamiento del STRM
MTSRefinement ::= REFINE mTS AS mTA RECURRING submission[S]VISIBLE delivery[S]VISIBLE administration[S]VISIBLE transferPAIRED WITH mTA
--
Objetos
mTA OBJECT PORTS { submission [S], delivery [S], administration [S], transfer } ::= id-ot-mta
--
Puertos
transfer PORT ABSTRACT OPERATIONS { MessageTransfer, ProbeTransfer, ReportTransfer } ::= id-pt-transfer
FIGURA 4/X.411 (Parte 2 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--^
Vinculación-ATM y desvinculación-ATM
MTABind ::= ABSTRACT-BIND
TO { transfer }
BIND
ARGUMENT CHOICE {
NULL,--^if no authentication is required
[1] SET {--^if authentication is required
initiator-name [0] MTAName,
initiator-credentials [1] InitiatorCredentials,
security-context [2] SecurityContext OPTIONAL
} }
RESULT CHOICE {
NULL,--^if no authentication is required
[1] SET {--^if authentication is required
responder-name [0] MTAName,
responder-credentials [1] ResponderCredentials
} }
BIND-ERROR INTEGER {
busy (0),
authentication-error (2),
unacceptable-dialogue-mode (3)
unacceptable-security-context (4)
}
(0^.^.^ub-integer-options)
MTAUnbind ::= ABSTRACT-UNBIND FROM { transfer }
FIGURA 4/X.411 (Parte 3 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Puerto de transferencia
MessageTransfer ::= ABSTRACT-OPERATION ARGUMENT Message
ProbeTransfer ::= ABSTRACT-OPERATION ARGUMENT Probe
ReportTransfer ::= ABSTRACT-OPERATION ARGUMENT Report
Message ::= SEQUENCE { envelope MessageTransferEnvelope, content Content }
Probe ::= ProbeTransferEnvelope
Report ::= SEQUENCE { envelope ReportTransferEnvelope, content ReportTransferContent }
FIGURA 4/X.411 (Parte 4 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Sobre de transferencia de mensaje
MessageTransferEnvelope ::= SET {
COMPONENTS OF PerMessageTransferFields,
per-recipient-fields [2] SEQUENCE
SIZE
(1^.^.^ub-recipients)
OF
PerRecipientMessageTransferFields }
PerMessageTransferFields ::= SET {
message-identifier MessageIdentifier,
originator-name OriginatorName,
original-encoded-information-types OriginalEncodedInformationTypes OPTIONAL,
content-type ContentType,
content-identifier ContentIdentifier OPTIONAL,
priority Priority DEFAULT normal,
per-message-indicators PerMessageIndicators DEFAULT {^},
deferred-delivery-time [0] DeferredDeliveryTime OPTIONAL,
per-domain-bilateral-information [1] SEQUENCE OF PerDomainBilateralInformation
OPTIONAL,
trace-information TraceInformation,
extension [3] EXTENSIONS CHOSEN FROM {
recipient-reassignment-prohibited,
dl-expansion-prohibited,
conversion-with-loss-prohibited,
latest-delivery-time,
originator-return-address,
originator-certificate,
content-confidentiality-algorithm-identifier,
message-origin-authentication-check,
message-security-label,
content-correlator,
dl-expansion-history,
internal-trace-information} DEFAULT {^}
}
FIGURA 4/X.411 (Parte 5 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
PerRecipientMessageTransferFields ::= SET {
recipient-name RecipientName,
originally-specified-recipient-number [0] OriginallySpecifiedRecipientNumber,
per-recipient-indicators [1] PerRecipientIndicators,
explicit-conversion [2] ExplicitConversion OPTIONAL,
extension [3] EXTENSIONS CHOSEN FROM {
originator-requested-alternate-recipient,
requested-delivery-method,
physical-forwarding-prohibited,
physical-forwarding-address-request,
physical-delivery-modes,
registered-mail-type,
recipient-number-for-advice,
physical-rendition-attributes,
physical-delivery-report-request,
message-token,
content-integrity-check,
proof-of-delivery-request,
redirection-history } DEFAULT {^}
}
FIGURA 4/X.411 (Parte 6 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Sobre de transferencia de la sonda
ProbeTransferEnvelope ::= SET {
COMPONENTS OF PerProbeTransferFields,
per-recipient-field [2] SEQUENCE
SIZE
(1^.^.^ub-recipients)
OF PerRecipientProbeTransferFields }
PerProbeTransferFields ::= SET {
probe-identifier ProbeIdentifier,
originator-name OriginatorName,
original-encoded-information-types OriginalEncodedInformationTypes OPTIONAL,
content-type-ContentType,
content-identifier ContentIdentifier OPTIONAL,
content-length [0] ContentLength OPTIONAL,
per-message-indicators PerMessageIndicators DEFAULT {^},
per-domain-bilateral-information [1] SEQUENCE
SIZE
(1^.^.^ub-transfers)
OF
PerDomainBilateralInformation OPTIONAL,
trace-information TraceInformation,
extensions [3] EXTENSIONS CHOSEN FROM {
recipient-reassignment-prohibited,
dl-expansion-prohibited,
conversion-with-loss-prohibited,
originator-certificate,
message-security-label,
content-correlator,
probe-origin-authentication-check,
dl-expansion-history,
internal-trace-information} DEFAULT {^}
}
PerRecipientProbeTransferFields ::= SET {
recipient-name RecipientName,
originally-specified-recipient-number [0] OriginallySpecifiedRecipientNumber,
per-recipient-indicators [1] PerRecipientIndicators,
explicit-conversion [2] ExplicitConversion OPTIONAL,
extensions [3] EXTENSIONS CHOSEN FROM {
originator-requested-alternate-recipient,
requested-delivery-method,
physical-rendition-attributes,
redirection-history } DEFAULT {^}
}
FIGURA 4/X.411 (Parte 7 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Sobre de transferencia del informe
ReportTransferEnvelope ::= SET {
report-identifier ReportIdentifier,
report-destination-name ReportDestinationName,
trace-information TraceInformation,
extensions [1] EXTENSIONS CHOSEN FROM {
message-security-label,
originator-and-DL-expansion-history,
reporting-DL-name,
reporting-MTA-certificate,
report-origin-authentication-check,
internal-trace-information} DEFAULT {^}
}
--
Contenido de transferencia del informe
ReportTransferContent ::= SET {
COMPONENTS OF PerReportTransferFields,
per-recipient-fields [0] SEQUENCE
SIZE
(1^.^.^ub-recipients)
OF
PerRecipientReportTransferFields }
PerReportTransferFields ::= SET {
subject-identifier SubjectIdentifier,
subject-intermediate-trace-information SubjectIntermediateTraceInformation
OPTIONAL,
original-encoded-information-types
OriginalEncodedInformationTypes OPTIONAL,
content-type ContentType OPTIONAL,
content-identifier ContentIdentifier OPTIONAL,
returned-content [1] Content OPTIONAL,
additional-information [2] AdditionalInformation OPTIONAL,
extensions [3] EXTENSIONS CHOSEN FROM {
content-correlator } DEFAULT {^}
}
PerRecipientReportTransferFields ::= SET {
actual-recipient-name [0] ActualRecipientName,
originally-specified-recipient-number [1] OriginallySpecifiedRecipientNumber,
per-recipient-indicator [2] PerRecipientIndicators,
last-trace-information [3] LastTraceInformation,
originally-intended-recipient-name [4] OriginallyIntendedRecipientName
OPTIONAL,
supplementary-information [5] SupplementaryInformation OPTIONAL,
extensions [6] EXTENSIONS CHOSEN FROM {
redirection-history,
physical-forwarding-address,
recipient-certificate,
proof-of-delivery } DEFAULT {^}
}
FIGURA 4/X.411 (Parte 8 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Campos de sobre y contenido del informe
MessageIdentifier ::= MTSIdentifier
OriginatorName ::= ORAddressAndOptionalDirectoryName
PerDomainBilateralInformation ::= SEQUENCE {
country-name CountryName,
CHOICE {
administration-domain-name AdministrationDomainName,
SEQUENCE {
administration-domain-name [0] AdministrationDomainName,
private-domain-identifier [1] PrivateDomainIdentifier
OPTIONAL
} },
bilateral-information BilateralInformation }
BilateralInformation ::= ANY --maximum ub-bilateral-info octets including all encoding
RecipientName ::= ORAddressAndOptionalDirectoryName
OriginallySpecifiedRecipientNumber ::= INTEGER
(SIZE
(1^.^.^ub-recipients))
PerRecipientIndicators ::= BIT STRING {
responsibility (0),
-- reponsible 'one', not-responsible 'zero'
originating-MTA-report (1),
originating-MTA-non-delivery-report (2),
-- either originating-MTA-report, or originating-MTA-non-delivery-report, or
both, shall be 'one':
-- originating-MTA-report bit 'one' requests a 'report';
-- originating-MTA-non-delivery-report bit 'one' requests a
'non-delivery-report';
-- both bits 'one' requests and 'audited-report';
-- bits 0-2 'don't care' for Report Transfer Content
originator-report (3),
originator-non-delivery-report (4),
-- at most one bit shall be 'one':
-- originator-report bit 'one' requests a 'report';
-- originator-non-delivery-report bit 'one' requests a 'non-delivery-report';
-- both bits 'zero' requests 'no-report'
reserved-5 (5),
reserved-6 (6),
reserved-7 (7),
-- reserved-bits 5-7 shall be 'zero' --^}
(SIZE
(8^.^.^ub-bit-options))
ProbeIdentifier ::= MTSIdentifier
FIGURA 4/X.411 (Parte 9 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
ReportIdentifier ::= MTSIdentifier
ReportDestinationName ::= ORAddressAndOptionalDirectoryName
SubjectIdentifier ::= MessageOrProbeIdentifier
MessageOrProbeIdentifier ::= MTSIdentifier
SubjectIntermediateTraceInformation ::= TraceInformation
AdditionalInformation ::= ANY --^maximum ub-additional-info octets including all encoding
ActualRecipientName ::= ORAddressAndOptionalDirectoryName
LastTraceInformation ::= SET { arrival-time [0] ArrivalTime, converted-encoded-information-types ConvertedEncodedInformationTypes OPTIONAL, report-type [1] ReporType }
OriginallyIntendedRecipientName ::= ORAddressAndOptionalDirectoryName
FIGURA 4/X.411 (Parte 10 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Campos de ampliación
originator-requested-alternate-recipient EXTENSION OriginatorRequestedAlternateRecipient ::= 2
OriginatorRequestedAlternateRecipient ::= ORAddressAndOptionalDirectoryName
internal-trace-information EXTENSION InternalTraceInformation ::= 38
FIGURA 4/X.411 (Parte 11 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
InternalTraceInformation ::= SEQUENCE SIZE (1^.^.^ub-transfers) OF
InternalTraceInformationElement
InternalTraceInformationElement ::= SEQUENCE { global-domain-identifier GlobalDomainIdentifier, mta-name MTAName, mta-supplied-information MTASuppliedInformation }
MTASuppliedInformation ::= SET {
arrival-time [0] ArrivalTime,
routing-action [2] RoutingAction,
attempted CHOICE {
mta MTAName,
domain GlobalDomainIdentifier } OPTIONAL,
--^
additional-actions
--^COMPONENTS OF
InternalAdditionalActions }
InternalAdditionalActions ::= AdditionalActions
FIGURA 4/X.411 (Parte 12 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
--
Tipos de parámetros comunes
TraceInformation ::= [APPLICATION 9] SEQUENCE
(SIZE
(1^.^.^ub-transfers)
OF TraceInformationElement
TraceInformationElement ::= SEQUENCE { global-domain-identifier GlobalDomainIdentifier, domain-supplied-information DomainSuppliedInformation }
DomainSuppliedInformation ::= SET {
arrival-time [0] ArrivalTime,
routing-action [2] RoutingAction,
attempted-domain GlobalDomainIdentifier OPTIONAL,
--
additional-actions
-- COMPONENT OF AdditionalActions }
AdditionalActions ::= SET {
deferred-time [1] DeferredTime OPTIONAL,
converted-encoded-information-types ConvertedEncodedInformationTypes OPTIONAL,
other-actions [3] OtherActions DEFAULT {^}
}
RoutingAction ::= ENUMERATED { relayed (0), rerouted (1) }
DeferredTime ::= Time
ArrivalTime ::= Time
OtherActions ::= BIT STRING { redirected (0), dl-operation (1) } (SIZE (0^.^.^ub-bit-options))
END --
de servicio abstracto STRM
FIGURA 4/X.411 (Parte 13 de 13)
Definición de la sintaxis
abstracta del servicio abstracto de ATM
(H.T.=NON)
TAB.???
FICHIER: H.T. =
(SANS
H.T.)
(SANS FORMULES) Tableaux: 0
(BT..) Disk ... NF../... (OPM = ..)
(87.TE.12.S)
(A1.23s) / [26s]
FOLIOS: 383 - 425 (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 588-590 01.09.89 RM/SJ/RM
ID + Vérif. + diskette MAJ + laser 10.10.89 PV
Corr. LASER (1re épreuve) = 3eme 30.10.89 UT
Espaces réservés + Transfert + Impr. 02.11.89 JC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 13.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs .) ........ ..
BAT du 22/XI/89 22.11.89 PV
MAJ s/disquettes ........ ..
SECCIóN 4 - PROCEDIMIENTOS DE FUNCIONAMIENTO DISTRIBUIDO DEL STRM
14
Procedimientos de funcionamiento
distribuido del STRM
En este punto, se especifican los procedimientos para el funcionamiento distribuido del STRM, que ejecutan los ATM. Cada ATM aplica individualmente los procedimientos descritos a continuación; la acción colectiva de todos los ATM presta el servicio abstracto de STRM a los usuarios del STRM.
Aunque los procedimientos incluyen la mayoría de las acciones importantes requeridas de un ATM, se ha omitido gran cantidad de detalles para una mayor claridad de exposición y para evitar cualquier redundancia innecesaria. Para un tratamiento definitivo de las acciones del ATM deberían consultarse las definiciones del servicio-abstracto.
14.1
Visión de conjunto del modelo del ATM
14.1.1
Organización y técnica de realización de los
modelos
La descripción de los procedimientos para un ATM único se basa en el modelo mostrado en las figuras 5/X.411 a 11»X.411 que se describe a continuación. Debe observarse que se incluye el modelo con fines expositivos únicamente y no se pretende limitar en modo alguno la realización de un ATM.
Ni los procedimientos mostrados ni el orden de los pasos de procesamiento en ellos, implican necesariamente características específicas de un ATM real.
El modelo distingue entre
módulos
^ y
procedimientos
. Los
módulos
, en el
sentido en que se utilizan aquí, son entidades de proceso autónomas que pueden
ser invocadas por otros módulos u otros sucesos externos al ATM, los cuales
pueden a su vez invocar otros módulos o generar otros sucesos externos. Los
módulos no están unidos entre sí mediante una estructura de control descrita
explícitamente; sino que la estructura de control entre los módulos surge de su
esquema de invocaciones recíprocas. Los módulos corresponden a
objetos
en el sentido de la programación orientada-objeto.
Se utilizan aquí los
procedimientos
^ en el sentido
convencional de programación. Los procedimientos están orientados a tareas o
funciones. Los procedimientos pueden llamar a otros procedimientos, en forma de
subrutinas, con devolución de control al procedimiento llamante cuando ha
finalizado el procedimiento llamado. Tales llamadas pueden anidarse hasta una
profundidad arbitraria, pudiendo, asimismo, autollamarse el procedimiento de
forma recurrente. Los procedimientos están unidos entre sí mediante estructuras
de control definidas explícitamente, construidas a partir de llamadas a
procedimientos y de dispositivos de programación convencional como iteracciones
y ejecuciones condicionales.
En el modelo, existen procedimientos dentro de los módulos. Cada módulo contiene al menos un procedimiento y puede contener varios. En el último caso, los procedimientos y la estructura de control de gobierno se describen explícitamente. En el primer caso, la existencia de un procedimiento único de módulos se trata generalmente como implícita.
Utilizando estas técnicas para la realización de modelos, puede
perfeccionarse un proceso de aplicación del ATM de la forma siguiente: para
cada operación-abstracta (tanto usuaria como suministradora) que puede existir
entre un ATM y los usuarios-STRM que sirve, o entre un ATM y los otros ATM con
los que coopera, hay un módulo único denominado
módulo
externo
. El conjunto de módulos externos es responsable de la entrada y
salida de mensajes, sondas e informes al ATM y del soporte de operaciones tales
como vinculación-STRM, desvinculación-STRM, registro, control-remisión y
control-entrega. Los módulos externos se muestran en la figura 5»X.411 y se
describen en los
14.5
a 14.10, agrupados por puertos.
Para realizar las diferentes operaciones-abstractas de las cuales es
responsable, un ATM debe ejecutar ciertas operaciones de proceso sobre cada
mensaje, sonda o informe que entra o se origina en él. En el modelo, esto es
competencia de los
módulos internos
, mostrados en figura
6»X.411 y descritos en los
14.2
a 14.4.
Los módulos externos e internos se relacionan entre sí de la forma siguiente: un módulo externo se comunica únicamente con un módulo interno, y no con otro módulo externo o directamente con un procedimiento dentro de un módulo interno. Así, los módulos internos no sólo soportan el volúmen de proceso dentro de un ATM, sino que sirven igualmente como enlaces entre sus módulos externos. Además de los módulos internos, la figura 6»X.411 muestra igualmente los módulos con los que se comunican.
El ATM está dirigido por sucesos en el sentido que permanece en reposo hasta que se detecta un suceso en una de sus puertas. Muchos de los sucesos, tales como la invocación de una operación-abstracta vinculación-STRM, control-remisión, control-entrega o registro por parte de un usuario-STRM u otro ATM se tratan directa y completamente por el módulo asignado a esta operación-abstracta. Sin embargo, otros sucesos arrancan un proceso que puede reverberar a través del ATM, perdurar durante un cierto tiempo y finalmente provocar uno o más sucesos de salida. Estos sucesos hacen intervenir los módulos de proceso internos y son:
a)un mensaje o sonda originado por un usuario-STRM soportado localmente entra a través del puerto-remisión;
b)un mensaje, sonda o informe retransmitido desde otro ATM entra a través del puerto-transferencia.
Puesto que el proceso en el interior de un ATM puede resultar bastante complejo, especialmente para mensajes con múltiples destinatarios, el módulo supone, como dispositivo interno de contabilidad, que cada mensaje transporta consigo un conjunto de instrucciones, una para el mensaje en su conjunto y una para cada destinatario. Estas instrucciones ayudan a guiar un mensaje a través de los pasos de proceso y transportan la información entre los módulos y procedimientos internos al ATM.
Nota 1
- Los procedimientos descritos aquí están
dirigidos al proceso de un mensaje único. Esto resulta adecuado para todos los
efectos menos para uno: la disposición en cola de mensajes y la prioridad
relativa de invocación de los procedimientos están gobernados explícitamente
por el argumento
prioridad
en el caso de un mensaje que
entra a través del puerto-remisión o puerto-transferencia, o implícitamente (de
prioridad urgente) en el caso de un informe o una prueba que se genera
internamente o que entra a través del puerto-transferencia.
Nota 2
- Un ATM puede especificar por defecto varias
ventanas de tiempo de entrega para cada prioridad de mensaje (por ejemplo,
aquellos valores definidos en las Recomendaciones de la serie F.400). El STRM y
por tanto, cada ATM afectado debería tener en cuenta dichos valores durante el
proceso del mensaje. Por ejemplo, el ATM puede aplicar un plazo máximo de
entrega. Si este periodo de tiempo expira antes de la entrega, el ATM genera un
informe-no-entrega y descarta el mensaje. Las acciones requeridas en este caso
son idénticas a las acciones requeridas cuando se alcanza el
último-tiempo-entrega.
Nota 3
- El examen de la información-rastreo es
incompleto debido a su naturaleza compleja. Se señalan algunos detalles
importantes pero el tratamiento completo y definitivo del informe-rastreo
aparece en el
12.3.1
.
14.2
Módulo de entrega diferida
Este módulo proporciona el elemento-de-servicio de entrega diferida. Es invocado por los módulos de remisión-mensaje y entrada-mensaje que pasan un mensaje para comprobar la petición de entrega diferida y retenerla, si es necesario. Invoca el módulo principal, pasando sucesivamente el mensaje hasta la finalización de su procedimiento interno único.
14.2.1
Procedimiento de entrega-diferida
14.2.1.1
Argumentos
Un mensaje para comprobación de la petición de entrega diferida y retención, si es necesario.
14.2.1.2
Resultados
Se devuelve el mensaje después de expirar el
tiempo-entrega-diferida
. Si se ha producido ésta, el mensaje
va acompañado de un estampillado de fecha.
14.2.1.3
Errores
Ninguno.
14.2.1.4
Descripción del procedimiento
Se comprueba en el mensaje la presencia del campo de
tiempo-entrega-diferida
. Si está ausente, el procedimiento
devuelve el mensaje y finaliza. Si está presente, se compara el
tiempo-entrega-diferida
con el tiempo presente. Si el
tiempo-entrega-diferida
ha expirado, el procedimiento
devuelve el mensaje y finaliza.
Por el contrario, en el caso de un mensaje retransmitido, el ATM comprueba la existencia de un acuerdo bilateral que le obligue a proporcionar la entrega diferida de este mensaje. Si está ausente, el procedimiento devuelve el mensaje y finaliza.
En caso contrario, según los acuerdos bilaterales o políticas en ese
respecto, se anota el instante actual como instante de llegada del mensaje, y
se retiene éste hasta la expiración del
tiempo-entrega-diferida
. Seguidamente, y como resultado, se
devuelven el mensaje y el estampillado de fecha. Finaliza entonces el
procedimiento.
Figure 5/X.411, (N), p. 1
Figure 6/X.411, (N), p. 2
14.3
Módulo principal
El módulo principal ejecuta el grueso de tratamiento de los mensajes y sondas que entran en el ATM. La figura 6»X.411 muestra las relaciones entre el módulo principal y los módulos que puede invocar o por los que puede ser invocado. El módulo principal está sujeto a la invocación por:
1)el módulo entrada-sonda, que transfiere una sonda;
2)el módulo entrega-diferida, que transfiere un mensaje;
3)el módulo sonda, que transfiere una sonda.
En el caso de una condición de error o de la necesidad de un informe positivo de entrega, el módulo principal puede ser invocado igualmente por:
4)el módulo de salida-mensaje, que cursa un mensaje con una instrucción por-mensaje que indica el problema encontrado;
5)el módulo salida-sonda, que cursa una sonda con una instrucción por-mensaje que indica el problema encontrado;
6)el módulo entrega-mensaje, que cursa un mensaje con instrucciones por-destinatario que indica el problema o problemas o el suceso o sucesos encontrados;
7)el módulo prueba-entrega-sonda, que cursa una sonda con instrucciones por-destinatario que indica el problema o problemas o el suceso o sucesos encontrados.
El módulo principal contiene procedimientos que, colectivamente, proporcionan las siguientes funciones:
-Procesamiento de rastreo
-Detección de bucle
-Encaminamiento y reencaminamiento
-Redireccionamiento del destinatario
-Conversión de contenido
-Ampliación de lista de distribución
-Réplica del mensaje
-Autenticación del origen de los mensajes y de las sondas
-Resolución del nombre.
Los procedimientos que ejecutan estas funciones se llaman mediante el procedimiento de control único que guía el tratamiento de cada mensaje o sonda recibido por el módulo principal. La figura 7»X.411 muestra la organización de los procedimientos de control y subsidiarios dentro del módulo principal; la figura 8»X.411 muestra el flujo de información a través de estos procedimientos.
Figure 7/X.411, (N), p.
Figure 8/X.411, (N), p.
Para cada mensaje o sonda recibido, el módulo principal llama al procedimiento
de control con dicho mensaje o sonda como argumento. Como resultado, el
procedimiento de control devuelve una o más réplicas del mensaje o sonda con
las instrucciones apropiadas adjuntas. Dependiendo de la naturaleza de esas
instrucciones el módulo principal invoca entonces:
1)el módulo de salida-mensaje, al cual cursa cada mensaje con una instrucción de transferencia por-mensaje;
2)el módulo de salida-sonda, al cual cursa cada sonda con una instrucción de transferencia por-mensaje;
3)el módulo de entrega-mensaje, al cual cursa cada mensaje con una o más instrucciones de entrega por-destinatario;
4)el módulo de prueba-entrega-sonda, al cual cursa cada sonda con una o más instrucciones de entrega por-destinatario;
5)el módulo de informe, al cual cursa cada mensaje o sonda con una instrucción por-mensaje y»o una o más instrucciones por-destinatario que indican la generación de un informe.
14.3.1
Procedimiento de control
Este procedimiento dirige cada mensaje o sonda entrantes a través de los procedimientos restantes del módulo principal. El flujo global de información se muestra en la figura 8/X.411.
14.3.1.1
Argumentos
Uno de los siguientes (estos argumentos corresponden a los mensajes y sondas que pueden cursarse al módulo principal, después de invocación):
1)un mensaje o sonda sin instrucciones (procedentes del módulo de entrada-sonda o sonda);
2)un mensaje sin instrucciones, pero con estampillado opcional de instante de llegada (procedente del módulo de entrega diferida);
3)un mensaje o sonda con una instrucción por-mensaje que describe un problema de transferencia (procedente del módulo de salida-mensaje o salida-sonda);
4)un mensaje o sonda con instrucciones por-destinatario que describen los problemas de entrega o los éxitos (procedente del módulo de entrega-mensaje o prueba-entrega-sonda).
14.3.1.2
Resultados
1)Una o más réplicas del argumento del mensaje o de la sonda, cada una acompañada por una instrucción por-mensaje que indica la transferencia, y»o
2)una o más réplicas del argumento del mensaje o sonda, cada una de ellas acompañada por una o más instrucciones por-destinatario que indican la entrega o la prueba de entrega, y»o
3)una o más réplicas del argumento del mensaje o sonda, cada una acompañada por una o más instrucciones por-destinatario que indican la generación de un informe.
14.3.1.3
Errores
Ninguno. Las condiciones de error se tienen en cuenta en los resultados descritos anteriormente.
14.3.1.4
Descripción del procedimiento
1)Mensaje o sonda sin instrucciones:
Se llama primero al procedimiento de cabecera para efectuar la inicialización del rastreo y varias comprobaciones mensaje por mensaje, como la de expiración de mensaje y la detección de bucle de encaminamiento.
Al recibir una devolución con instrucción de informe que indique un problema en relación con el mensaje, el proceso continúa en el paso 9.
En todas las otras devoluciones el procedimiento continúa como sigue:
2)Se llama al procedimiento de decisión-conversión-y-encaminamiento para calcular las instrucciones de encaminamiento y conversión por-destinatario. (Son instrucciones completas que dirigirán el mensaje o sonda a través del resto de los procedimientos.)
Si se indica una instrucción de redireccionamiento (por ejemplo, destinatario-alternativo-solicitado-destinatario), el proceso continúa en el paso 3.
En los demás casos restantes, el proceso continúa en el paso 4 (despachador.)
3)Se llama al redireccionamiento. Al recibir una devolución con éxito, el proceso continúa en el paso 2.
En el caso de una devolución infructuosa, el proceso continúa en el paso 8 (manipulador-error.)
4)Despachador. El despachador actúa sobre las instrucciones generadas y transfiere el control al primero de los siguientes procedimientos que resulte aplicable:
-división (paso 5); -conversión (paso 6); -ampliación-lista-distribución (paso 7); -tratamiento-error (paso 8) en el caso en que el proceso de decisión encontró un problema, por ejemplo, error de encaminamiento; -salida (paso 10).
5)Se llama al divisor para la realización de réplicas, cuando se solicita en las instrucciones por-destinatario generadas en el procedimiento de decisión-conversión-y-encaminamiento. Para cada réplica el proceso continúa por separado en el paso 4 (despachador.)
6)Se llama a la conversión para cada mensaje o sonda que necesite conversión.
Al devolver con éxito el mensaje o sonda, el proceso continúa en el paso 4 (despachador.)
Después de una devolución con instrucción de informe que indica un error de conversión, el proceso continúa en el paso 8 (manipulador-error.)
7)Se llama al procedimiento de ampliación-LD.
Después de la devolución con éxito de un mensaje, el proceso continúa en el paso 2 de forma que los destinatarios resultantes de la ampliación de la LD puedan tratarse convenientemente.
Si se devuelve una copia del mensaje con instrucciones de informe de entrega, en lugar de, o además de, la devolución anterior, el proceso continúa en el paso 9.
Una sonda que retorna con éxito llevará instrucciones de informe; el proceso continúa en el paso 9 (generación-informe.)
Después de la devolución de un mensaje o sonda con una instrucción de informe que indique una ampliación de LD, el proceso-error continúa en el paso 8.
8)Este es el punto de recogida que alcanza el proceso al detectar que un mensaje o sonda no puede ser tratado por los procedimientos de línea principales. Se llama al procedimiento de proceso-error para buscar otro método de entrega o un destinatario-alternativo. Después de una devolución con éxito, el procedimiento de proceso-error indica el nuevo destinatario en una instrucción al procedimiento de decisión-conversión-y-encaminamiento (paso 2), donde continúa el proceso.
Si no es posible el redireccionamiento, el mensaje o sonda se pasa al generador del informe (paso 9).
9)El procedimiento de control finaliza en este punto y devuelve un mensaje o sonda con las instrucciones de generación de informe.
10)Cuando un mensaje o sonda alcanza este punto, finaliza el procedimiento de control.
14.3.2
Procedimiento de cabecera
Este procedimiento efectúa la iniciación del rastreo, la detección de la expiración del mensaje, la comprobación inicial de seguridad, la detección de bucles y la comprobación de la criticidad.
14.3.2.1
Argumentos
Un mensaje o sonda y un estampillado opcional de instante de llegada.
14.3.2.2
Resultados
El mensaje o sonda con información inicializada de rastreo para este ATM.
14.3.2.3
Errores
El mensaje o sonda con instrucciones de generación del informe que detalla el problema encontrado.
14.3.2.4
Descripción del procedimiento
1)Si el mensaje ha cruzado una frontera entre dominios, se añade un
elemento-información-rastreo
de este dominio a la
retransmisión
como acción. Si el mensaje va acompañado de un
tiempo-llegada, es que ha habido dilación de entrega; se fija entonces
tiempo-diferido
en el instante actual, y
tiempo-llegada
en el valor del estampillado de fecha
acompañante. En caso contrario, no ha habido dilación, y se fija
tiempo-llegada
al valor del instante actual. Se añade
igualmente un
elemento-información-rastreo-interno
tanto si
el mensaje ha cruzado la frontera entre dominios como si no lo ha hecho.
2)Si lo requiere la política de seguridad en vigor y»o si la
verificación-autenticación-origen-mensaje
es incorrecta, el
procedimiento devuelve una instrucción de generación de informe. Los valores de
código-motivo-no-entrega
y de
código-diagnóstico-no-entrega
se fijan en
incapaz-de-transferir
y
error-mensajería-segura
, respectivamente.
3)Si alguno de los campos de extensión está marcado como crítico para la
retransmisión pero el ATM no lo entiende semánticamente, el procedimiento
devuelve una instrucción de generación de informe. El
código-motivo-no-entrega
se pone en
fallo-transferencia
y el
código-diagnóstico-no-entrega
en
función-
crítica-no-soportada
. Finaliza entonces el procedimiento.
4)Si se ha sobrepasado el
último-tiempo-entrega
, o si ha
transcurrido el máximo tiempo de tránsito del sistema para la
prioridad
del mensaje, el procedimiento devuelve una
instrucción de generación de informe. El
código-motivo-no-entrega
se pone en
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
se pone a
tiempo-máximo-expirado
. Finaliza entonces el procedimiento.
5)Se realiza la detección de bucles. El algoritmo de detección de bucles se
encuentra fuera del alcance de esta Recomendación. Sin embargo, en el
14.3.11
se facilita un ejemplo de algoritmo combinado de
encaminamiento y de detección de bucles. Si se detecta un bucle, el
procedimiento devuelve una instrucción de generación de informe. El
código-motivo-no-entrega
se pone en
fallo-transferencia
y el
código-diagnóstico-no-entrega
se pone en
bucle-detectado
. Finaliza entonces el procedimiento.
14.3.3
Procedimiento de
decisión-conversión-encaminamiento
Para cada destinatario de un mensaje o sonda cuyo responsable es el ATM, este procedimiento determina las acciones de encaminamiento y conversión, si ha lugar, que ha de tomar este ATM. Las acciones se registran como instrucciones por-destinatario asociadas al mensaje. Las acciones se llevan a cabo subsiguientemente mediante otros sub-procedimientos dentro del procedimiento interno o en cualquier otro lugar del ATM.
Nota
- Para cada mensaje particular, es posible
invocar más de una vez este procedimiento. En ese caso, el procedimiento ignora
las instrucciones por destinatario generadas por anteriores invocaciones que
aún no se han hecho actuar sobre ningún otro ente.
14.3.3.1
Argumentos
1)Un mensaje o sonda con
responsabilidad
verdadera para
aquellos destinatarios bajo la tutela de este ATM.
14.3.3.2
Resultados
El mensaje o sonda que formaron el argumento del procedimiento más las instrucciones por-destinatario nuevas o revisadas que indican el encaminamiento y la posible acción de conversión que debería emprender este ATM.
14.3.3.3
Errores
Ninguno. Las condiciones de error, si las hay, se señalan en las instrucciones por-destinatario.
14.3.3.4
Descripción del procedimiento
Se considera cada vez un destinatario. Si la
responsabilidad
es falsa, se ignora el destinatario. En caso
contrario, se llama a los procedimientos de decisión-conversión y
decisión-encaminamiento para cada destinatario. Cuando se han considerado todos
los destinatarios se finaliza el procedimiento. Véase la figura 9/X.411.
Figure 9/X.411, (N), p.
14.3.4
Procedimiento de
decisión-encaminamiento
Este procedimiento genera una instrucción de encaminamiento para un destinatario único del mensaje.
14.3.4.1
Argumentos
1)Un destinatario de mensaje más la instrucción por-destinatario, si la hay, aplicable a este destinatario.
2)La instrucción por-mensaje, si la hay, aplicable a este mensaje. Otros campos de mensaje resultan igualmente accesibles al procedimiento si se necesitan.
14.3.4.2
Resultados
Una instrucción de encaminamiento nueva o posiblemente revisada aplicable a este destinatario. Las posibles instrucciones son:
a)retransmisión a otro ATM;
b)entrega a un destinatario local;
c)ampliar la lista de distribución representada por este destinatario;
d)generar un informe que indique el fallo de la entrega. El
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
se incluyen en la instrucción;
e)redirigir a un destinatario alternativo especificado por un destinatario.
14.3.4.3
Errores
Ninguno. Las condiciones de error se registran en la instrucción de encaminamiento.
14.3.4.4
Descripción del procedimiento
El procedimiento se describe según los siguientes pasos.
Nota
- Para garantizar que no se viole la
política-seguridad durante el encaminamiento se debería comprobar que la
etiqueta-seguridad-entrega
resulta apropiada respecto del
contexto-seguridad
.
1)Si existe una instrucción por-mensaje que indica un fallo previo de
retransmisión, el procedimiento calcula entonces un destino alternativo del
próximo salto para este destinatario. La elección del algoritmo de
encaminamiento está fuera del alcance de esta Recomendación. Sin embargo, en el
14.3.11
se incluye un ejemplo de algoritmo aplicable. Si tuvo éxito,
la
información-rastreo-interna
del mensaje se actualiza con
una acción reencaminamiento
reencaminado
para reflejar el
hecho de que se ha reencaminado el mensaje (véase el
12.3.1
). Si el
menaje tuviera que haber cruzado una frontera de dominio se actualizaría, la
información-rastreo
en consecuencia. El procedimiento
devuelve una instrucción de retransmisión al destino alternativo y finaliza.
Si no existe un siguiente salto alternativo disponible o todos los saltos
siguientes disponibles han sido ensayados infructuosamente o están prohibidos,
el procedimiento devuelve una instrucción de generación de informe para este
destinatario. El
código-motivo-no-entrega
se pone a
fallo-transferencia
y el
código-diagnóstico-no-entrega
se pone en consonancia con el
fallo de retransmisión encontrado. El procedimiento finaliza entonces.
2)Si la instrucción por-destinatario indica un fallo de entrega, el
procedimiento devuelve una instrucción de generación de informe para este
destinatario. El
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
son los suministrados por el
procedimiento de entrega-mensaje o entrega-informe. El procedimiento finaliza
entonces.
3)Si el destinatario es una lista de distribución para la cual este ATM
sirve como punto de ampliación, se examina entonces el argumento de
ampliación-LD-prohibida
del mensaje. Si el valor es
ampliación-LD-autorizada
el procedimiento devuelve una
instrucción de encaminamiento (sujeta a la política-seguridad en vigor) para
ampliar la lista de distribución y finaliza.
Si el valor es
ampliación-LD-prohibida
o la
política-seguridad prohibe la utilización de una LD, el procedimiento devuelve
entonces una instrucción de generación de informe para este destinatario. El
código-motivo-no-entrega
se pone a
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
a
ampliación-LD-prohibida
. El procedimiento finaliza entonces.
En todos los demás casos, se siguen los siguientes pasos.
4)Si el destinatario resulta ser local, es decir, un usuario-STRM directamente soportado por este ATM, se siguen los siguientes pasos:
a)Se comprueba la
dirección O»D
para garantizar que
especifica sin ambigüedad un destinatario real local. En caso contrario, el
procedimiento devuelve una instrucción de generación de informe para este
destinatario. El
código-motivo-no-entrega
se pone a
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
se pone a
nombre-O»D-no-reconocido
o
nombre
O»D-ambiguo
según convenga. El procedimiento finaliza entonces.
b)Si la
dirección O»D
especifica un destinatario local
real, se comprueban los parámetros de registro del destinatario en relación con
el destinatario-alternativo-solicitado-destinatario. En la determinación de un
destinatario-alternativo, debería comprobarse la
etiqueta-seguridad-usuario
respecto de la
etiqueta-seguridad-mensaje
para garantizar que no se produce
ninguna violación de la política-seguridad.
Si el
destinatario-alternativo-asignado-destinatario
está
de hecho autorizado por el campo de
reasignación-destinatario-prohibida
y permitido por la
política-seguridad, se genera entonces una instrucción de redireccionamiento y
finaliza el procedimiento.
En caso contrario, el procedimiento devuelve una instrucción de informe para
este destinatario y finaliza. El
código-motivo-no-entrega
se
pone a
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
se pone según convenga.
c)Si el
destinatario-alternativo-asignado-destinatario
no
está vigente, se comprueba entonces el mensaje respecto de los parámetros
restantes del registro del destinatario. Por ejemplo, se compara la longitud
del contenido del mensaje con la
longitud-máxima-contenido-entregable
, el
tipo-contenido
del mensaje con los
tipos-contenido-entregables
del destinatario, etc. Si no se
encuentra ningún problema, el procedimiento de decisión-encaminamiento devuelve
una instrucción de entrega para este destinatario y finaliza.
Si existe un problema entre el mensaje de los parámetros del registro, el
procedimiento devuelve una instrucción de generación de informe a este
destinatario. El
código-motivo-no-entrega
se pone en
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
se pone en consonancia con el
problema del mensaje encontrado. Finaliza entonces el procedimiento.
5)Si el destinatario no es local para éste ATM, el procedimiento de decisión-encaminamiento intenta determinar una siguiente instrucción de salto (sujeta a la política-seguridad en vigor) para este destinatario. Si tiene éxito, se devuelve una instrucción de retransmisión al siguiente salto y finaliza el procedimiento.
Si no puede determinarse el salto siguiente, el procedimiento devuelve una
instrucción de generación de informe a este destinatario. El
código-motivo-no-entrega
se pone en
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
se pone en consonancia con el
problema encontrado. Finaliza entonces el procedimiento.
14.3.5
Procedimiento de decisión-conversión
Este procedimiento genera una instrucción de conversión para un destinatario único del mensaje.
14.3.5.1
Argumentos
1)Un destinatario de un mensaje o sonda más la instrucción por destinatario, si existe, aplicable a este destinatario.
2)Otros campos de mensaje son considerados igualmente por el procedimiento:
a)
tipos-información-codificada-original
,
b)
conversión-implícita-prohibida
,
c)
conversión-con-pérdida-prohibida
,
d)
conversión-explícita
.
14.3.5.2
Resultados
1)Una instrucción de conversión de contenido aplicable a este destinatario y, posiblemente,
2)una instrucción revisada de encaminamiento que indica la salida-retransmisión o salida-sonda hacia un ATM capaz de realizar la conversión-requerida o, en lugar de los 1 y 2 anteriores,
3)una instrucción para generar un informe que indica un fallo de entrega. El
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
se incluyen en esta
instrucción.
14.3.5.3
Errores
Ninguno. Las condiciones de error se registran en la instrucción de encaminamiento.
14.3.5.4
Descripción del procedimiento
Nota
- Como las circunstancias bajo las cuales ATM
realiza la conversión se dejan para un estudio ulterior, no resulta práctico
describir un procedimiento para decidir qué EIT se requieren para la salida de
la conversión. Por ejemplo, si un ATM intermedio desarrolla la conversión, no
existe ningún camino normalizado para conocer los EIT que puede manejar un
usuario-STRM. En consecuencia, las siguientes cláusulas suponen que el ATM
conoce los EIT para la conversión.
1)Si se requiere una conversión explícita para este destinatario, el procedimiento comienza en el paso 6.
2)Si se requiere una conversión implícita pero el destinatario no está
abonado a la facilidad de conversión implícita, el procedimiento devuelve una
instrucción de informe negativo en el
código-motivo-no-entrega
de
conversión-no-realizada
y el
código-diagnóstico-no-entrega
de
conversión-implícita-no-abonada
. Finaliza entonces el
procedimiento.
3)Si la conversión requerida no resulta práctica, el procedimiento genera
una instrucción de informe negativo con el
código-motivo-no-entrega
de
conversión-no-realizada
y el
código-diagnóstico-no-entrega
de
conversión-no-práctica
. Finaliza entonces el procedimiento.
4)Si se requiriese, la conversión del mensaje pero estuviese prohibida, el
procedimiento genera una instrucción de informe negativo con el
código-motivo-no-entrega
de
conversión-no-realizada
, y el
código-diagnóstico-no- entrega
de
conversión-prohibida
. Finaliza entonces el procedimiento.
5)Si la conversión requerida causara una pérdida de información y el campo
de
conversión-con-pérdida-prohibida
adopta el valor de
con-pérdida-prohibido
; el procedimiento genera una
instrucción de informe negativo con el
código-motivo-no-entrega
de
conversión-no-realizada
y uno de los siguientes
código-motivo-no-entrega
, según proceda:
-
línea-demasiado-larga
,
-
página-partida
,
-
pérdida-símbolo-pictórico
,
-
pérdida-símbolo-puntuación
,
-
pérdida-carácter-alfabético
, o
-
pérdida-información-múltiple
.
Seguidamente, termina el procedimiento.
6)Si la conversión requerida resulta admisible, y no puede ser realizada por este ATM, pero puede ser realizada por un ATM conocido de este ATM, se genera entonces una instrucción de no conversión. La instrucción de encaminamiento previamente generada se cambia por salida-transferencia o salida- sonda, con un destino del próximo salto apropiado para el ATM en cuestión. Seguidamente, termina el procedimiento.
7)Si la conversión requerida puede ser efectuada por ese ATM, el procedimiento devuelve una instrucción de efectuar la conversión, y finaliza.
14.3.6
Procedimiento de proceso-error
Cuando otro procedimiento encuentra un error de capacidad de entrega o encaminamiento, se llama a este procedimiento para determinar si pueden lograrse la entrega o el encaminamiento mediante la reasignación del destinatario o eligiendo una dirección-O»D diferente para el mismo destinatario. En caso contrario, debe señalarse la no-entrega al módulo de informe. Los errores que provocan una llamada a este procedimiento son:
-
nombre-destinatario
que no identifica un usuario-STRM;
-fallo de entrega;
-un ATM que es incapaz de realizar la conversión necesaria;
-problemas del trayecto de transferencia;
-problemas de ampliación-LD;
-violaciones de seguridad;
-conflicto con parámetros de registro.
Nota
- La acción emprendida en relación con el
proceso-error deberá estar sujeta a la política-seguridad en vigor.
14.3.6.1
Argumentos
1)Un mensaje o sonda con los campos por-destinatario que provocaron el problema.
2)Instrucciones de informe que indican el error.
14.3.6.2
Resultados
El mensaje o sonda en cuestión con un campo de
nombre-destinatario
, actualizado, o
1)el mensaje o sonda en cuestión;
2)instrucciones de informe.
14.3.6.3
Errores
Ninguno.
14.3.6.4
Descripción del procedimiento
Nota
- Un determinado destinatario puede llamar a este
procedimiento múltiples veces. Ocasionalmente agotará todas las alternativas y
ejecutará el paso 5 para informar del fallo.
1)Los argumentos se comprueban respecto de un
nombre-guía
. Si está presente, el procedimiento realiza una
consulta a la guía para determinar una nueva
dirección-O»D
.
La
dirección-O»D
, si la hay, así extraída de la guía se
comprueba para ver si satisface el argumento del
método-entrega-solicitado
, si existe. Si la comprobación
tiene éxito, se sustituye la nueva
dirección-O»D
por la
antigua y finaliza el procedimiento.
Nota
- Tras la sustitución de la nueva
dirección-O/D
por la original, el mensaje puede
legítimamente ser encaminado hacia una DG/ATM que ya haya visitado. Queda para
ulterior estudio la técnica para evitar la detección prematura de un bucle de
reencaminamiento.
2)En caso contrario, el procedimiento determina si se especificó un
destinatario-alternativo-solicitado-destinatario
para el
destinatario en cuestión. Si es así, se llama al procedimiento de
redireccionamiento junto con el mensaje, indicados los campos pertinentes como
argumento. Al volver satisfactoriamente del redireccionamiento, el
procedimiento finaliza devolviendo como resultado el mensaje ahora redirigido.
3)En caso contrario, el procedimiento efectúa una comprobación para el error
de entrega y si está presente comprueba la causa del error examinando el
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
. Si la
dirección-O»D
del destinatario no identifica un
usuario-STRM, se comprueban los
indicadores-por-mensaje
en
relación con el
destinatario-alternativo-autorizado
. Si el
valor encontrado resulta ser
destinatario-alternativo-autorizado
y se ha configurado el
ATM con la dirección de un destinatario alternativo para esta clase de
destinatario, se llama entonces al redireccionamiento para dirigir el mensaje
al destinatario-alternativo. Al volver satisfactoriamente del
redireccionamiento, finaliza el procedimiento devolviendo entonces como
resultado el mensaje redirigido.
4)La manipulación de los errores que pueden resolverse, pero que son debidos a problemas del direccionamiento constituye un asunto local, por ejemplo, el encaminamiento a otro ATM dentro del dominio debido a problemas de conversión.
5)Si el error de entrega es de otro tipo diferente de los citados
anteriormente, o si el valor del
destinatario-alternativo-autorizado
es un
destinatario-alternativo-prohibido
, o si no existe ningún
destinatario-alternativo-especificado-DG que resulte adecuado, el procedimiento
devuelve una instrucción de informe y finaliza.
14.3.7
Procedimiento de
redireccionamiento
Este procedimiento redirecciona un mensaje a un destinatario-alternativo.
Nota
- La utilización de las facilidades de
redireccionamiento deberá ajustarse a la política-seguridad en vigor.
14.3.7.1
Argumentos
1)El
nombre-OD
del destinatario-alternativo a quien se ha
de redirigir el mensaje.
2)Los campos del mensaje por-destinatario para el destinatario que va a ser sustituido por uno alternativo.
3)El mensaje o sonda que ha de redirigirse.
4)Motivo del redireccionamiento.
14.3.7.2
Resultados
El mensaje o sonda suministrado en el tercer argumento con el destinatario identificado en el segundo argumento sustituido por el destinatario-alternativo especificado en el primer argumento.
14.3.7.3
Errores
Indicación de que se ha detectado un bucle de redireccionamiento.
14.3.7.4
Descripción del procedimiento
1)El procedimiento garantiza primero que el redireccionamiento al
destinatario alternativo especificado no provocará un bucle de
redireccionamiento. El
nombre-O»D
del
destinatario-alternativo suministrado en el argumento 1 se compara con cada
nombre-destinatario-deseado
de la secuencia de la
historia-redireccionamiento
procedente de los campos
por-destinatario identificados en el argumento 2. Después de una concordancia,
el procedimiento finaliza indicando que se ha detectado un bucle de
redireccionamiento.
2)Se añade un elemento a la
historia-redireccionamiento
(que se crea si no está presente), utilizando el
nombre-destinatario
del argumento 2 para formar el
nombre-destinatario-deseado
, obtiendo el
motivo-redireccionamiento
a partir del argumento 4 e
incluyendo el instante en que se efectúa ese redireccionamiento. El
nombre-O»D
suministrado por el primer argumento se sustituye
entonces por ese
nombre-destinatario
.
3)En el campo de
otras-acciones
de la
información-rastreo
vigente, el valor
redirigido
se fija en verdadero.
4)El sobre de transferencia del mensaje se actualiza de la forma siguiente:
nombre-destinatario:
sustituido
información-rastreo:
indica
redirigido
historia-redireccionamiento:
añadir
nombre-destinatario
previo y
motivo-redireccionamiento
destinatario-alternativo-solicitado-originador:
suprimido si y sólo si el
motivo-redireccionamiento
indica
el
destinatario-alternativo-solicitado-originador
14.3.8
Procedimiento de división
El divisor produce réplicas de los mensajes y de las sondas según se necesiten para un proceso ulterior. Se modifican estas réplicas según proceda, para indicar la distribución de la responsabilidad para los diferentes destinatarios procedentes del original. Cada réplica se acompaña de una instrucción por-mensaje que indica su disposición ulterior dentro del ATM.
Nota
- La utilización de las facilidades del divisor
deberá ajustarse a la política-seguridad en vigor.
14.3.8.1
Argumentos
Un mensaje o sonda. Para cada destinatario con
responsabilidad
verdadera, acompaña al mensaje una
instrucción de encaminamiento»conversión.
14.3.8.2
Resultados
Una o más réplicas del mensaje original o de la sonda con la responsabilidad convenientemente indicada, y una instrucción por mensaje que indique la ulterior disposición de la réplica dentro del ATM.
14.3.8.3
Errores
Ninguno.
14.3.8.4
Descripción del procedimiento
El separador examina las instrucciones generadas por el procedimiento de
decisión-encaminamiento-y-conversión para segregar (conceptualmente) los
destinatarios con
responsabilidad
verdadera en grupos. Se
crea una réplica para cada grupo. El proceso posterior para dichas réplicas (en
otros procedimientos) depende de las instrucciones de conversión y
encaminamiento aplicables al grupo que representa.
Nota 1
- En un ATM se necesita una réplica del módulo
debido al tratamiento posiblemente diferenciador que necesitan los diferentes
destinatarios de un mensaje. Estas diferencias surgen de la necesidad de más de
un trayecto de retransmisión para salir de un ATM, de la necesidad de llevar a
cabo más de una conversión sobre el contenido del mensaje y de la necesidad de
ampliar las listas de distribución. Por ejemplo, cuando existe más de un
trayecto de retransmisión, debe crearse una copia separada del mensaje para
cada uno de dichos trayectos, con los valores de
responsabilidad
adecuados para los destinatarios que se
encuentran a lo largo del trayecto.
Nota 2
- La determinación de cuáles son las réplicas
que se necesitan es un asunto local, que se realiza de forma que se reduzca al
mínimo el número total de las réplicas creadas. Los párrafos siguientes
sugieren un enfoque pero no pretenden en forma alguna imponer limitaciones al
método seguido en una aplicación real.
Nota 3
- Para mayor sencillez de exposición, se
describe el divisor como un algoritmo de un solo-paso. Es decir, se crean todas
las réplicas necesarias antes de cualquier proceso posterior. Una optimización
importante consistiría en dividir de forma mínima el mensaje para conversión, y
completar entonces la separación de las copias convertidas.
1)El procedimiento considera primero aquellos destinatarios para los cuales
existen instrucciones de conversión de contenido. Estos destinatarios se
agrupan de forma que los miembros de cada grupo estén sujetos a instrucciones
de conversión idénticas. Se crea una réplica para cada grupo con
responsabilidad
verdadera para los destinatarios de este
grupo y falsa para todos los demás.
2)Se examinan entonces los destinatarios para los cuales existen
instrucciones de ampliación-LD. Se crea una réplica para cada destinatario de
dicha LD con
responsabilidad
para todos los destinatarios
excepto para la única LD que produjo la réplica.
3)Se subdividen posteriormente los grupos en base a las llamadas de
instrucciones de encaminamiento por-destinatario para salida-transferencia o
salida-sonda. Estos destinatarios se agrupan de forma que cada grupo comparta
un destino común para el próximo salto. Se crea una réplica para cada uno de
estos grupos con
responsabilidad
verdadera para los
destinatarios del grupo, falsa para todos los restantes. Para todos los
destinatarios de cada uno de estos grupos, éste será el primer intento de
retransmisión o un intento de reencaminamiento. En el último caso, se modifica
la información-rastreo para el mensaje o sonda con el fin de indicar que éste
es el primer reencaminamiento o uno subsiguiente.
4)Finalmente, las instrucciones de encaminamiento para algunos destinatarios
llamarán a entrega-mensaje o a generación-informe. Se crea una réplica para
cada uno de estos subgrupos con
responsabilidad
verdadera
para los destinatarios del grupo y falsa para todos los demás.
5)Finaliza entonces el procedimiento.
14.3.9
Procedimiento-conversión
Este procedimiento realiza conversiones sobre mensajes e indica aquellas conversiones que habrían sido realizadas sobre las sondas.
14.3.9.1
Argumentos
Un mensaje o sonda con indicación de la conversión o conversiones requeridas.
14.3.9.2
Resultados
El mensaje o sonda con conversiones realizadas e indicadas (sólo indicadas en el caso de una sonda).
14.3.9.3
Errores
El mensaje o sonda con instrucciones de informe que detallan los problemas de conversión encontrados.
14.3.9.4
Descripción del procedimiento
1)Para un mensaje, se realizan los procedimientos de conversión para EIT incorporados según se define en la Recomendación X.408. Los procedimientos de conversión entre los EIT definidos externamente y entre los EIT incorporados y los definidos externamente están fuera del alcance de esta Recomendación.
2)Después de la conversión, se actualiza la
información-rastreo
del mensaje o de la sonda para este
dominio para mostrar los EIT convertidos. Finaliza entonces el procedimiento.
14.3.10
Procedimiento de ampliación-lista-distribución
Este procedimiento toma un mensaje con un único destinatario de la LD y devuelve un mensaje cuya lista de destinatarios incluye los miembros de la LD. Para una sonda, verifica si se produciría una ampliación-LD, si ésta se solicita.
Nota
- La utilización de la ampliación-LD deberá estar
sujeta a la política-seguridad en vigor.
14.3.10.1
Argumentos
1)Un mensaje con información que indique la LD de destinatarios que debe ampliarse, o
2)una sonda con información que indique la LD de destinatarios cuya ampliación ha de verificarse.
14.3.10.2
Resultados
1)El mensaje con cero o más destinatarios que representan los miembros de la LD. Pueden actualizarse otros campos según se indica a continuación en la descripción del procedimiento;
2)opcionalmente, el mensaje con instrucciones para generación de informe que indica una entrega con éxito, o
3)la sonda con instrucciones para generación de informe.
14.3.10.3
Errores
1)Una instrucción de informe que indica un fallo de entrega. Los valores
para el
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
son los indicados en la
descripción del siguiente procedimiento.
2)En el caso de una LD recurrente, el procedimiento finaliza sin devolver ni errores ni resultados.
14.3.10.4
Descripción del procedimiento
1)Para un mensaje (no para una sonda), hacer la detección de recurrencia: se
examinan los componentes del campo de la
historia-ampliación-LD
para detectar la aparición del nombre
de un destinatario de la LD. Obsérvese que se utiliza un
nombre-O»D
distinguido de la LD para la detección de
recurrencia, y que cada punto de ampliación es responsable de garantizar que
sólo se coloca este
nombre O»D
en la
historia-ampliación-LD
.
Si el nombre de los destinatarios de la LD se encuentra presente en la
historia-ampliación-LD
, se define la LD de forma recurrente
y no deberá ser ampliada ulteriormente. Se descarta el mensaje y no se
devuelven ni informes ni otros resultados. Finaliza el procedimiento de
ampliación.
2)Adquisición de la LD: el procedimiento de ampliación intenta adquirir los atributos de la LD.
Si no tiene éxito, el procedimiento devuelve una instrucción de informe con
el
código-motivo-no-entrega
y el
código-diagnóstico-no-entrega
que procedan. Finaliza entonces el
procedimiento.
3)Verificación del permiso de remisión: si se trata de un mensaje (no de una
sonda), el último elemento del campo de la
historia-ampliación-LD
(si ha lugar) diferente del
nombre-originador
se considera como el emisor del mensaje.
Para una sonda, el originador es el emisor del mensaje.
El nombre del emisor se compara con los componentes del permiso-remisión-LD.
Si no existe coincidencia, se devuelve una instrucción de informe con el
código-motivo-no-entrega
de
incapaz-de-transferir
y el
código-diagnóstico-no-entrega
de
no-permiso-remisión-LD
. Finaliza entonces el procedimiento.
4)Para una sonda: si ninguna otra política local impidiera una entrega deseada, se devolvería entonces una instrucción de informe para indicar la entrega con éxito. Finaliza entonces el procedimiento.
5)Para un mensaje: la bandera de
responsabilidad
de los
destinatarios de la LD se pone en falso y se añaden los miembros de la LD como
nuevos destinatarios del mensaje. Los campos por-destinatario para cada nuevo
destinatario se copian de los del destinatario de la LD, excepto en los casos
siguientes:
-
Nombre destinatario
: miembro de la LD.
Los siguientes campos por-destinarario se copian o cambian según la política de LD local:
-
Ampliación-LD-prohibida
-
Petición-informe-ATM-que-origina
(véase la nota 1)
-
Petición-informe-originador
(véase la nota 1)
-
Destinatario-alternativo-solicitado-originador
(véase la
nota 2)
-
Conversión-explícita
.
Nota 1
- Se copia sólo si la política-LD lo requiere y
el originador no reciba informes no solicitados.
Nota 2
- El
destinatario-alternativo-solicitado-originador
puede
eliminarse o sustituirse, según la política de la LD local, o copiarse, pero
sólo si la política de LD local lo exige explícitamente.
Nota 3
- Cualquiera de los miembros-LD que identifican
las LD que aparecen en la
historía-ampliación-LD
puede ser
excluido de la ampliación de la LD y no ser incluido entre los nuevos
destinatarios del mensaje.
6)En el campo de
otras-acciones
de la
información-rastreo
vigente, el valor de la
operación-LD
se pone en verdadero.
7)El valor distinguido del
nombre-O»D
de la LD
(incluyendo su
dirección-O»D)
y el instante en que se ha
producido la expansión se añaden al campo de
historia-ampliación-LD
del mensaje.
Nota
- La utilización de un valor distinguido del
nombre-O»D
de la LD no se refiere aquí a los
nombres-guía
distinguidos sino a un
nombre-O»D
específico de la LD que el punto de ampliación
eligió para fines de comparación.
8)Si los valores de la nueva petición de informe (determinados en el paso 5) o la política local de LD impiden que el originador reciba de los miembros de la LD un informe de entrega solicitado, se construye una copia del mensaje, con instrucciones de petición del informe de entrega para la LD ampliada, y se devuelve junto con el mensaje.
9)El procedimiento devuelve el mensaje revisado y la petición de informe facultativa, tras lo cual finaliza.
14.3.11
Algoritmos de
detección de
bucle
y de
encaminamiento
Los algoritmos de encaminamiento y de detección de bucle para su utilización entre dominios y dentro de un dominio se encuentran fuera del alcance de esta Recomendación. Para exponer los aspectos que deben considerarse, la parte restante de este punto define un método para el encaminamiento y la detección de bucle. Este texto no forma parte de la Recomendación.
Los párrafos que siguen describen un método sencillo de detección de bucle junto con un algoritmo de encaminamiento mínimo. El algoritmo es mínimo en el sentido de que presupone únicamente un conocimiento mínimo de cada DG y realiza los pasos de transferencia para evitar bucles (en el sentido que se indica a continuación). Por supuesto, este algoritmo puede mejorarse cuando un DG conoce mejor la topología de la red de los DG.
El algoritmo reconoce el hecho de que, en general, está legitimado (es decir, no deberían detectarse bucles) para entrar de nuevo en un DG si otro DG ha realizado una operación específica desde el último paso a través del DG antes de entrar de nuevo en él. Las operaciones legítimas son: conversión, ampliación-LD y redireccionamiento.
1)Notación: La secuencia de información de rastreo está constituida por
elementos-información-rastreo
designados de una forma
simplificada como [DG, acción-encaminamiento, operación], donde el DG es el
nombre de un DG, la acción de encaminamiento es
`retransmitido'
o
`reencaminado'
, la operación es
`conversión'
,
`operación-LD'
,
`redireccionamiento'
o
`nada'
. M designa
el mensaje que hay que transferir. DG(o) designa el DG vigente (aquel que
detecta en ese momento el bucle). Los vecinos representan el conjunto de los DG
adyacentes seleccionados [vecinos del DG(o)] que constituyen posibles
DG-retransmisores para M info-rastreo* y es el sufijo del info-rastreo obtenido
al considerar la cola de la secuencia info de rastreo que comienza con el
último elemento de info de rastreo [DG, r, op] donde op no es nada (nada indica
que no ha sido realizada ninguna operación por ningún DG).
2)Detección de bucle: Se examina info-rastreo para los bucles. Se detecta un bucle si la secuencia de info-rastreo contiene un sufijo [DG(o), retransmitido, op(o)] .^.^. [DG(p), retransmitido, op(p)] donde para todos los j tales que o &lab; j p el elemento de info de rastreo asociado es [DG(j), retransmitido, op(j)] y op(j) = nada. Es decir, se detecta un bucle si M llega a un DG que lo ha retransmitido ya y después cada DG lo ha retransmitido igualmente sin realizar ninguna otra operación que no sea la de encaminamiento. Si se detecta un bucle, entonces el algoritmo devuelve un error que indica el problema y finaliza.
3)Establecimiento del encaminamiento: Si no se detecta ningún bucle, se ajusta el conjunto, vecinos, si procede, para los pasos de transferencia de evitar-bucle en el contexto del presente mensaje (el ajuste no afecta a ningún otro mensaje).
a)Si no existe ningún bucle ni ninguna aparición de [DG(o), r, op] en info-rastreo* no se modifica de vecinos.
b)Si no existe ningún bucle pero hay una aparición de [DG(o), r, op] en info-rastreo* se eliminan de vecinos todos los DG que aparezcan en este sufijo del info-rastreo* que comienza con [DG(o), r, op]. Se modifica el elemento de info de rastreo añadido por el dominio vigente para mostrar reencaminado como acción de reencaminar. Se añade un parámetro DG-previo determinado de la forma siguiente: se coloca el último elemento de info de rastreo [DG(o), r, op] en info de rastreo. El DG-previo es el DG que aparece en el primer elemento de info de rastreo después del último elemento de info de rastreo de [DG(o), r, op].
c)En los casos a) y b) si vecinos está vacío, el algoritmo devuelve un error indicando el problema y finaliza.
4)Acción de reencaminamiento. Se selecciona un próximo salto desde vecinos para cada destinatario que haya de ser retransmitido.
14.4
Módulo del informe
El módulo del informe puede ser invocado por:
1)el módulo de entrada-informe, que transfiere un informe, o
2)el módulo principal, que transfiere un mensaje o una sonda con instrucciones de informe,
3)el módulo de salida-informe, que transfiere un informe con descripción de fallo.
Si se encuentra un error mediante los procedimientos internos de este módulo, no se genera ninguna salida. En caso contrario, el módulo de informe invoca el módulo de salida-informe o entrega-informe, que pasa un informe con instrucciones de transferencia o entrega, respectivamente. Véase la figura 10»X.411.
Nota
- La utilización de los informes deberá estar
sujeta a la política-seguridad en vigor.
Figure 10/X.411, (N), p.
Figure 11/X.411, (N), p.
14.4.1
Procedimiento de control
14.4.1.1
Argumentos
1)Un informe, o
2)un mensaje o sonda con instrucción de informe.
14.4.1.2
Resultados
1)Un informe con instrucciones de retransmisión o entrega, o
2)ningún resultado en el caso de encontrarse un error.
14.4.1.3
Errores
Ninguno. El informe, mensaje o sonda se descarta si se encuentra un error.
14.4.1.4
Descripción del procedimiento
1)Para un informe procedente de entrada-informe se llama primero al procedimiento de cabecera-informe para realizar la iniciación del rastreo y varios pasos iniciales de verificación. Una devolución nula indica un error; se descarta el informe y termina el proceso. En caso contrario, el proceso continúa en el paso 3 siguiente.
2)Para un mensaje o sonda se llama primero al procedimiento de generación-informe para crear un informe. Una devolución nula indica un error; se descarta el mensaje o la sonda y termina el proceso. Si se devuelve un informe el proceso continúa en el paso 3 siguiente.
3)Se llama al procedimiento de encaminamiento-informe para generar una instrucción de encaminamiento para el informe. Una devolución nula indica un error; se descarta el informe y termina el proceso. En el caso de una devolución positiva, se llama al procedimiento de actualización del rastreo para indicar el paso a través de este ATM. El procedimiento de control devuelve el informe finalizado junto con la instrucción de encaminamiento y termina, sujeto a la política-seguridad.
14.4.2
Procedimiento de cabecera-informe
Este procedimiento realiza la inicialización de traza, la detección de las violaciones de la expiración-mensaje, la comprobación inicial de seguridad, la detección de bucles y la comprobación de criticidad.
14.4.2.1
Argumentos
Un informe.
14.4.2.2
Resultados
El informe con la
información-rastreo
iniciada para este
ATM.
14.4.2.3
Errores
Ninguno. Si se detecta un error se descarta el informe.
14.4.2.4
Descripción del procedimiento
1)Si el informe ha cruzado una frontera entre dominios, se añade un
elemento-información-rastreo
para este dominio con el tiempo
presente como
tiempo-llegada
y
retransmisión
como
acción
. Se añade
igualmente un
elemento-información-rastreo-interna
indicando
si el informe ha cruzado o no una frontera de dominio.
2)Si la política-seguridad en vigor lo requiere, y»o si la
comprobación-autenticación-origen-informe
resulta
incorrecta, se descarta el informe y se termina el proceso.
3)Si alguno de los campos de ampliación es marcado como crítico para la transferencia pero el ATM no lo entiende semánticamente, se descarta el informe. Finaliza entonces el procedimiento.
4)Se realiza la detección de bucles. El algoritmo de detección de bucles está fuera del alcance de esta Recomendación. Sin embargo, en el 14.3.11 figura, como ejemplo, un algoritmo combinado de encaminamiento y de detección de bucles. Si se detecta un bucle, se descarta el informe y finaliza el procedimiento.
14.4.3
Procedimiento de generación-informe
Este procedimiento genera un informe que describe el éxito y»o el fallo de las operaciones deseadas por parte del ATM.
14.4.3.1
Argumentos
Un mensaje o sonda. Para cada destinatario con
responsabilidad
verdadera, se incluye una instrucción
por-destinatario que indica el éxito o el problema encontrado.
14.4.3.2
Resultados
Un informe que describe los éxitos y fallos que hay que comunicar.
14.4.3.3
Errores
Ninguno.
14.4.3.4
Descripción del procedimiento
Si el campo de
petición-informe-ATM-que-origina
del
sujeto así lo indica, se construye el informe con los argumentos descritos en
el cuadro 31/X.411, ampliado posteriormente por lo siguiente.
Se toman los argumentos de entrega
(
tiempo-entrega-diferida
,
tipo-de-usuario-STRM
o argumentos de no-entrega
(
código-motivo-no-entrega
,
código-diagnóstico-no-entrega
) para cada destinatario a
partir de las instrucciones pro-destinatario que acompañaban al mensaje sujeto.
En el caso de un informe de entrega, el
tiempo-entrega-mensaje
se toma de la información de rastreo
del mensaje o de la sonda. Si se comunica un fallo para un destinatario de una
LD, el
tipo-de-usuario-STRM
se pone a
LD
.
El
nombre-destinatario-informe
es el último elemento de la
historia-ampliación-LD
, si dicho elemento existe. Para
mensajes sin
historia-ampliación-LD
y para todas las sondas,
el
nombre-destino-informe
es el
nombre-originador
del sujeto. El
originador-y-ampliación-LD
contendrá el
nombre-originador
y el
tiempo-presentación-mensaje
del sujeto seguido del contenido
de la
historia-ampliación-LD
.
Nota
- No se genera el
nombre-LD-informadora
bajo ninguna de estas condiciones.
En el caso en que las instrucciones reflejen múltiples fallos, el informe debería reflejar el problema original, en vez del fallo de las acciones de recuperación subsiguientes.
Obsérvese que el ATM designa valores de
criticidad
para
campos copiados del sujeto (asunto). Estos nuevos valores reflejan la
criticidad con respecto al informe, no al asunto. El ATM no copiará en el
informe ninguna función crítica que no admita.
14.4.4
Procedimiento de encaminamiento-informe
Este procedimiento determina la acción de encaminamiento, si ha lugar, que ha de adoptarse en un informe. El encaminamiento-informe refleja las condiciones especiales que requiere un procedimiento de encaminamiento diferente del aplicable a los mensajes o sondas:
1)Un informe tiene un solo destinatario - el originador del mensaje que constituye el sujeto del informe, un punto-de-ampliación de LD, o, si la política local lo permite, un propietario de LD.
2)Fallos insuperables encontrados al encaminar un informe hacen que se descarte el informe. No se hace ningún intento para generar un informe ulterior, sobre la dificultad encontrada.
Las acciones de proceso que exigen estas condiciones, se describen en los puntos siguientes. Debería observarse que el encaminamiento de los informes está sujeto a la política-seguridad.
14.4.4.1
Argumentos
Uno de los siguientes:
1)un informe transferido a este ATM desde otro ATM y procesado con éxito por el procedimiento de cabecera-informe;
2)un informe creado por el procedimiento generación-informe interno a este ATM;
3)un informe devuelto desde el procedimiento de salida-informe junto con una descripción del fallo de transferencia encontrado.
14.4.4.2
Resultados
Uno de los siguientes:
1)el informe, junto con las instrucciones de retransmisión para el ATM del próximo salto;
2)el informe, junto con una indicación del usuario-STRM soportado localmente que debe recibir la entrega-informe.
14.4.4.3
Errores
Ninguno. Si no puede determinarse ningún destinatario local o ningún próximo salto, se descarta el informe
14.4.4.4
Descripción del procedimiento
1)Los informes retransmitidos a este ATM o generados localmente reciben una atención de encaminamiento normal como se decribe a continuación.
a)Si el destino-informe no es local en este ATM, se necesita la
retransmisión. El encaminamiento-informe intenta determinar la dirección del
próximo salto. En esta determinación se compara la
etiqueta-seguridad-mensaje
del informe con el
contexto-seguridad
para garantizar que no se reproducen
violaciones de la política-seguridad. Si tiene éxito, se devuelve el informe,
junto con esta información como resultado del procedimiento. Finaliza entonces
el procedimiento. A continuación se pasa el informe al procedimiento de
salida-informe.
Si no puede determinarse la dirección del próximo salto, se descarta entonces el informe y finaliza el procedimiento sin devolver ningún resultado.
b)Si el destino-informe es un usuario-STRM local en este ATM, y el campo de
petición-informe-originador
lo indica, se solicita la
entrega-informe (sujeta a la política-seguridad en vigor). El
encaminamiento-informe intenta determinar la dirección-O/D del destino del
informe. Si tiene éxito, se devuelve entonces el informe, junto con esta
información, como resultado del procedimiento, finaliza entonces el
procedimiento. A continuación se pasa el informe al procedimiento, de
entrega-informe.
Si no se solicitó el informe o no puede determinarse la dirección de destino del informe, se descarta éste y el procedimiento finaliza sin devolver ningún resultado.
c)Si el
nombre-destino-informe
corresponde a una LD local
en este ATM, este informe se encuentra en el proceso de encaminamiento hacia
atrás a lo largo de un trayecto de sucesivos puntos-ampliación de la LD. En el
campo de
otras-acciones
del
elemento-información-rastreo
, el valor
operación-LD
se pone en verdadero.
Cualquier proceso basado en una política de LD local podría producirse aquí;
por ejemplo, puede construirse una copia del informe y enviarla al propietario
de la LD. En este caso el
nombre-destino-informe
será el del
propietario de la LD y se construirá el
nombre-LD-informadora
para que contenga el nombre de la LD
del sujeto. Esta copia del informe no deberá contener el
contenido-devuelto
. Además se puede realizar aquí la
supresión de los informes.
Nota
- La posibilidad de que un propietario LD sea en
sí mismo una LD se deja para ulterior estudio.
Si no se va a suprimir el informe, el ATM sustituye el
nombre
O»D
existente en el campo de
nombre-destino-informe
por
el
nombre O»D
que precede inmediatamente al del campo del
originador-e-historia-ampliación-LD
. De esta forma, el
informe adquiere, como nuevo destino, la nueva entrada junto con la cadena de
entradas del campo del
originador-e-historia-ampliación-LD
:
Nombre-destino-informe
:
Nombre-O»D
previo de la LD de la copia procedente de
originador-e-historia-ampliación-LD
.
Nombre-LD-informadora
:
Generado únicamente en el caso de informes al propietario de la LD.
Para encaminar el informe a su nuevo destino el procedimiento de encaminamiento-informe se llama ahora a sí mismo de forma recurrente. Se devuelve el resultado devuelto procedente de esta llamada recurrente, si lo hay y finaliza el procedimiento.
2)Un informe devuelto por el procedimiento de salida-informe ha encontrado un fallo de transferencia en el procedimiento de retransmisión a otro ATM. El procedimiento de encaminamiento-informe intenta reencaminar dicho informe, es decir, calcula una dirección alternativa para el próximo salto (sujeta a la política-seguridad en vigor). Si se encuentra una dirección alternativa para el próximo salto, se devuelve entonces el informe, junto con esta información y la información de rastreo convenientemente modificada, a modo de resultado del procedimiento. Finaliza entonces el procedimiento. A continuación se pasa el informe al procedimiento de salida-informe.
Si no puede determinarse una dirección alternativa para el próximo salto, se descarta entonces el informe y finaliza el procedimiento sin devolver ningún resultado.
14.5
Vinculación-STRM y
desvinculación-STRM
14.5.1
Procedimiento de vinculación-STRM iniciado por
usuario-STRM
Este punto describe el comportamiento del ATM cuando un usuario-STRM invoca vinculación-STRM.
14.5.1.1
Argumentos
Los argumentos de vinculación-STRM se definen en el 8.1.1.1.1 .
14.5.1.2
Resultados
Los resultados de vinculación-STRM se definen en el 8.1.1.1.2 .
14.5.1.3
Errores
Los errores-vinculación se definen en el 8.1.2 .
14.5.1.4
Descripción del procedimiento
1)Si los recursos de los ATM no permiten normalmente el establecimiento de una nueva asociación, el procedimiento devuelve un error-vinculación de ocupado y finaliza.
2)En caso contrario, si la política-seguridad exige autenticación, el ATM
intenta tanto autenticar el usuario-STRM a través de las
credenciales-iniciador
suministradas, como comprobar la
posibilidad de aceptación del
contexto-seguridad
. Si no
pueden autenticarse las
credenciales-iniciador
, el
procedimiento devuelve un error-autenticación y finaliza. Si el
contexto-seguridad
no resulta aceptable, el procedimiento
devuelve un error-vinculación de contexto-seguridad-inaceptable y finaliza.
3)Si la autenticación tiene éxito y el
contexto-seguridad
resulta aceptable, el ATM acepta la asociación solicitada. El procedimiento
devuelve el
nombre-ATM
y las
credenciales-respondedor
. Se devuelven igualmente los
mensajes-esperando
si el usuario-STRM está abonado al
elemento-de-servicio retención para entrega. Finaliza entonces el
procedimiento.
4)Si no se requiere autenticación, se devuelve una espera-mensaje si el
usuario-STRM
se abona al elemento-de-servicio retención para
entrega, y el procedimiento finaliza.
14.5.2
Procedimiento de desvinculación-STRM iniciado por
usuario-STRM
Este punto describe el comportamiento del ATM cuando un usuario-STRM invoca desvinculación-STRM para liberar una asociación existente establecida por el usuario-STRM.
14.5.2.1
Argumentos
Ninguno.
14.5.2.2
Resultados
El procedimiento de desvinculación-STRM devuelve un resultado vacío como indicación de la liberación de la asociación.
14.5.2.3
Errores
Ninguno.
14.5.2.4
Descripción del procedimiento
El procedimiento libera la asociación, devuelve un resultado vacío y finaliza.
14.5.3
Procedimiento de vinculación-STRM iniciado por
ATM
Este punto describe los pasos dados por el ATM cuando emprende la tarea de establecer una asociación con un usuario-STRM.
14.5.3.1
Argumentos
Los argumentos de vinculación-STRM se definen en el 8.1.1.1.1 .
14.5.3.2
Resultados
Un identificador interno para la asociación establecida.
14.5.3.3
Errores
El procedimiento devuelve una indicación de fallo en el caso de que no pudiera establecerse la asociación.
14.5.3.4
Descripción del procedimiento
1)El procedimiento establece los valores para los argumentos definidos en el
8.1.1.1.1
. Pueden suministrarse
mensajes-esperando
si el usuario-STRM está abonado al
elemento-de-servicio de retención para entrega. Se toman los valores del
nombre-iniciador
,
contexto-seguridad
y
credenciales-iniciador
de la información interna.
2)El procedimiento determina la
dirección-usuario
del
usuario-STRM e intenta establecer una asociación con los argumentos del
8.1.1.1.1
. Si no tiene éxito, se devuelve una indicación de fallo y
finaliza el procedimiento.
3)Si tiene éxito, se examinan los resultados devueltos por el usuario-STRM
(definidos en el
8.1.1.1.2
). Se comprueba la corrección del
nombre-respondedor
y se realiza un intento de autenticar el
usuario-STRM a través de las
credenciales-respondedor
devueltas. Si la comprobación falla, el procedimiento cierra la conexión,
devuelve una indicación de fallo y finaliza.
4)Si ambas comprobaciones tienen éxito, el procedimiento devuelve el identificador de la asociación y finaliza.
14.5.4
Procedimiento de desvinculación-STRM iniciado por el
ATM
Se llama a este procedimiento para liberar una asociación con un usuario-STRM.
14.5.4.1
Argumentos
El identificador interno para la asociación que ha de liberarse.
14.5.4.2
Resultados
El procedimiento de desvinculación-STRM devuelve un resultado vacío como indicación de la liberación de la asociación.
14.5.4.3
Errores
Ninguno.
14.5.4.4
Descripción del procedimiento
El procedimiento libera la asociación, devuelve un resultado vacío y finaliza.
14.6
Puerto de remisión
14.6.1
Procedimiento de remisión-mensaje
Este punto describe el comportamiento del ATM cuando el usuario-STRM invoca la operación-abstracta de remisión-mensaje en un puerto de remisión.
14.6.1.1
Argumentos
Los argumentos de remisión-mensaje enumerados en el cuadro 3/X.411 y descritos en los puntos indicados en este cuadro.
14.6.1.2
Resultados
1)Los resultados de remisión-mensaje enumerados en el cuadro 5/X.411 y descritos en los puntos indicados en dicho cuadro se devuelven al usuario-STRM.
2)Se invoca el módulo de entrega diferida y se transfiere el mensaje remitido.
14.6.1.3
Errores
Véase el 8.2.1.1.3 para las descripciones de los errores-abstractos pertinentes.
14.6.1.4
Descripción del procedimiento
1)Comprobación de errores
El procedimiento de remisión-mensaje comprueba las condiciones de error. Si se encuentra alguna, se devuelve el error-abstracto indicado y termina todo proceso ulterior. El ATM no acepta la responsabilidad del mensaje deseado.
Errores de interés especial:
a)Errores de seguridad. Si la
etiqueta-seguridad-mensaje
no es compatible con el
contexto-seguridad
o, si procede, la
comprobación-autenticación-origen-mensaje
resulta incorrecta
se genera un error-seguridad.
b)Errores de criticidad. Si alguno de los campos de ampliación es marcado
como
crítico-para-remisión
, pero el ATM no lo entiende
semánticamente, se devuelve un error-función-crítica-no-permitida.
Si no se encuentran errores en esta etapa, continúa el proceso en el paso 2. Pueden encontrarse errores adicionales en estas últimas etapas del proceso, en cuyo caso el ATM adopta las medidas descritas anteriormente.
2)Procesamiento del nombre
El procedimiento siguiente se aplica al
nombre-originador
, al
nombre-destinatario
y al
destinatario-alternativo-solicitado-originador
, a menos
que se señale lo contrario.
a)Si el
nombre-O»D
contiene únicamente un
nombre-guía
, el ATM intenta obtener la
dirección-O»D
.
En el caso del
nombre-destinatario
, el ATM puede emplear
el
método-entrega-solicitada
, si está presente, como
indicación de cuál sea la forma de
dirección-O/D
con la que
que debe ponerse en correspondencia el
nombre-guía
. Si no es
posible encontrar una forma de
dirección-O/D
apropiada para
el
método-entrega-solicitado
, el ATM devuelve un
error-abstracto de especificado-indebidamente-destinatario.
b)Si el
nombre-O/D
contiene tanto el
nombre-guía
como la
dirección-O»D
no es
necesario dar validez a su asociación. Si se encuentra posteriormente que la
dirección-O»D
es inválida, el ATM procede como si no se
hubiera suministrado la
dirección-O»D
en el
nombre-O»D
. El procedimiento descrito en el a) anterior se
utiliza para obtener la
dirección-O»D
, que, caso de ser
válida, sustituye a la
dirección-O»D
suministrada en el
nombre-O»D
.
Si la
dirección-O»D
obtenida es inválida se devuelve un
error-abstracto como se describe en a) anterior.
c)Si un
nombre-destinatario
contiene una
dirección-O/D
de una forma no apropiada para el
método-entrega-solicitada
, si está presente, el ATM devuelve
el error-abstracto
destinatario-impropiamente-especificado
.
d)La validación de la
dirección-O/D
, tanto si se pasó
como argumento de la remisión-mensaje como si se obtuvo resolviendo el
nombre-guía
, consta de dos pasos. El primer paso da validez
a que la
dirección-O/D
implicada tiene la combinación de
atributos necesarios para ser una
dirección-O/D
válida
(véase el
8.5.5
). El segundo paso, que se aplica únicamente al
nombre-originador
da validez a que la
dirección-O/D
es, de hecho, la
dirección-O/D
del usuario-STRM que remite el mensaje.
3)Transferencia de responsabilidad, devolución de resultados
Si no se detecta ningún error en el proceso anterior, el ATM acepta la
responsabilidad del mensaje y así lo indica devolviendo los resultados de la
remisión-mensaje al usuario-STRM. Los resultados de la remisión-mensaje se
describen en el
8.2.1.1.2
. El ATM construye los argumentos del
identificador-remisión-mensaje
y del
tiempo-remisión-mensaje
según proceda. El
identificador-contenido
es idéntico al argumento
correspondiente de remisión-mensaje. Si lo solicitó el originador, el
ATM-que-origina genera la
prueba-de-remisión
utilizando el
algoritmo identificado por
identificador-algoritmo-prueba-de-remisión
y los argumentos
definidos en el
8.2.1.1.2.4
. Además se devuelve el
certificado-ATM-que-origina
.
4)Construcción del mensaje
Se construye un mensaje a partir de los argumentos de remisión-mensaje, posiblemente modificados en los pasos anteriores del proceso, más los argumentos adicionales sumnistrados por el ATM, especificados en el 12.2.1.1 .
Cuando está finalizado, el procedimiento de remisión-mensaje termina y se pasa el mensaje al módulo de entrega diferida para un proceso ulterior.
14.6.2
Procedimiento de remisión sonda
Este punto describe el comportamiento del ATM cuando el usuario-STRM invoca la operación-abstracta de usuario-STRM en un puerto de remisión.
14.6.2.1
Argumentos
Los argumentos de remisión sonda enumerados en el cuadro 7/X.411 y descritos en los puntos indicados en este cuadro.
14.6.2.2
Resultados
1)Los resultados de remisión-sonda enumerados en el cuadro 8/X.411 y descritos en los puntos indicados en dicho cuadro se devuelven al usuario-STRM.
2)Se invoca el módulo principal y se transfiere la sonda remitida.
14.6.2.3
Errores
Véase el 8.2.1.2.3 para las descripciones de los errores-abstractos pertinentes.
14.6.2.4
Descripción del procedimiento
1)Comprobación de errores
El procedimiento de remisión-sonda comprueba las condiciones de error. Si se encuentra alguna, se devuelve el error-abstracto indicado. El ATM no acepta la responsabilidad de la sonda deseada.
Errores de interés especial:
a)Errores de seguridad. Si la
etiqueta-seguridad-mensaje
no es compatible con el
contexto-seguridad
o si la
comprobación-autenticación-origen-sonda
resulta incorrecta
se genera un error-seguridad.
b)Errores de criticidad. Si uno de los argumentos externos resulta ser
crítico-para-remisión
, pero el ATM no lo entiende
semánticamente, se devuelve un error-función-crítica-no-permitida.
Si no se encuentran errores en esta etapa, continúa el proceso en el paso 2. Pueden encontrarse errores adicionales en estas últimas etapas del proceso, en cuyo caso el ATM adopta las medidas descritas anteriormente.
2)Procesamiento del nombre
Se aplica el procedimiento siguiente al
nombre-originador
,
nombre-destinatario
y
destinatario-alternativo-solicitado-originador
, a menos que
se señale lo contrario.
a)Si el
nombre-O/D
contiene únicamente un
nombre-guía
, el ATM intenta obtener la
dirección-O/D
.
En el caso del
nombre-destinatario
, el ATM puede utilizar
el
método-entrega-solicitado
, de haberlo, para indicar con
que forma de
dirección-O/D
, ha de hacerse corresponder el
nombre-guía
. Si no puede encontrarse una forma de
dirección-O/D
apropiada para el
método-entrega-solicitado
, el ATM devuelve un
error-abstracto de destinatario-especificado-indebidamente.
b)Si el
nombre-O/D
contiene tanto el
nombre
guía
como la
dirección-O/D
, no es necesario dar validez
a su asociación. Si se encuentra posteriormente que la
dirección-O/D
es inválida, el ATM procede como si no se
hubiera suministrado la
dirección-O/D
en el
nombre-O/D
. El procedimiento descrito en el punto a)
anterior se utiliza para obtener la
dirección-O/D
, que, en
caso de ser válida, sustituye a la
dirección-O/D
suministrada en el
nombre-O/D
.
Si la
dirección-O/D
obtenida es inválida, se devuelve un
error-abstracto como se describe en el punto a) anterior.
c)Si un
nombre-destinatario
contiene una
dirección-O/D
que sea de una forma inapropiada para el
método-entrega-solicitado
, de haberlo, el ATM devuelve el
error-abstracto-destinatario-especificado-impropiamente.
d)La validación de la
dirección-O/D
, tanto si se
transfirió como argumento de remisión-sonda, como si se obtuvo resolviendo el
nombre-guía
, consta de dos pasos. El primer paso da validez
a que la
dirección-O/D
implicada tiene la combinación de
atributos necesarios para ser una
dirección-O/D
válida
(véase el
8.5.5
). El segundo paso, que se aplica únicamente al
nombre originador
, da validez a que la
dirección-O/D
es, de hecho, la
dirección-O/D
del usuario-STRM que remite el mensaje.
3)Transferencia de responsabilidad, devolución de resultados
Si no se detecta ningún error en los pasos anteriores, el ATM acepta la
responsabilidad del mensaje y así lo indica devolviendo los resultados de
remisión-sonda al usuario-STRM. Los resultados de remisión-sonda se describen
en el
8.2.1.2.2
. El ATM construye los argumentos de
identificador-remisión-sonda
y del
tiempo-remisión-sonda
según convenga. El
identificador-contenido
es idéntico al argumento
correspondiente a remisión-sonda.
4)Construcción de la sonda
Se construye una sonda a partir de los argumentos de remisión-sonda, posiblemente modificados en los pasos anteriores del proceso, más los argumentos adicionales suministrados por el ATM.
Cuando está finalizado, el procedimiento de remisión-sonda termina y se pasa la sonda al módulo principal para un proceso ulterior.
14.6.3
Procedimiento de cancelación-entrega-diferida
Este punto describe el comportamiento del ATM cuando el usuario-STRM invoca la operación-abstracta de cancelación-entrega-diferida en un puerto de remisión para cancelar la entrega diferida de un mensaje previamente remitido al ATM.
14.6.3.1
Argumentos
Los argumentos de cancelación-entrega-diferida enumerados en el cuadro 10/X.411 y descritos en los puntos indicados en este cuadro.
14.6.3.2
Resultados
Como indicación de cancelación satisfactoria, se transfiere al usuario-STRM un resultado vacío.
14.6.3.3
Errores
Véase el 8.2.1.3.3 para las descripciones de los errores-abstractos pertinentes.
14.6.3.4
Descripción del procedimiento
1)Si ya ha sido proporcionada una
prueba-de-remisión
, el
ATM devuelve el error abstracto de demasiado-tarde-para-cancelar. No se cancela
la entrega del mensaje.
2)Si el ATM reconoce el argumento del
identificador-remisión-mensaje
como válido y asociado con un
mensaje que está reteniendo el ATM para su entrega-diferida, el ATM descarta
este mensaje como cancelado y supone que ya no tiene ninguna responsabilidad
sobre él.
3)Si el ATM reconoce el argumento del
identificador-remisión-mensaje
como válido pero referido a
un mensaje ya entregado a otro ATM, el ATM invoca el error-abstracto
demasiado-tarde-para-cancelar. No se cancela la entrega diferida del mensaje.
4)Si no se reconoce como válido el argumento del
identificador-remisión-mensaje
(porque el ATM nunca asignó
dicho valor o porque el ATM ya no tiene depositado el registro histórico de un
mensaje de entrega diferida que ha sido transferido o entregado) el ATM
devuelve entonces el error-abstracto de identificador-remisión-mensaje-inválido
o demasiado-tarde-para-cancelar, siendo la elección un asunto local.
14.6.4
Procedimiento control-remisión
Este punto describe el comportamiento del ATM al invocar la operación-abstracta de control-remisión en un puerto-remisión, para limitar transitoriamente las operaciones-abstractas del puerto-remisión que puede invocar el usuario-STRM. Estos controles permanecen en vigor durante la asociación presente, a menos que sean anulados por una operación-abstracta del control-remisión.
Nota
- La utilización de control-remisión deberá estar
sujeta a la política-seguridad en vigor. El argumento de control-remisión de
contexto-seguridad-permisible
limita el
contexto-seguridad
establecido durante la vinculación-STRM.
14.6.4.1
Argumentos
Los argumentos de control-remisión enumerados en el cuadro 12»X.411 y descritos en los puntos indicados en este cuadro.
14.6.4.2
Resultados
El usuario-STRM devuelve al ATM los resultados de control-remisión enumerados en el cuadro 13»X.411 y descritos en los puntos indicados en este cuadro.
14.6.4.3
Errores
El usuario-STRM puede devolver un error-seguridad. Véase el 8.2.1.4.3 para la descripción de este error-abstracto.
14.6.4.4
Descripción del procedimiento
Las circunstancias que hacen que un ATM invoque la operación-abstracta de control-remisión son asunto local, como lo son las medidas adoptadas durante y después de su consecución.
14.7
Puerto de entrega
14.7.1
Procedimiento de entrega-mensaje
Este punto describe los pasos dados por un ATM cuando se encarga de entregar un mensaje a uno o más usuarios-STRM.
La mayoría de las disposiciones de este punto se aplicarán igualmente al caso en que el ATM haya recibido una sonda con uno o más destinatarios locales. A menos que se señale lo contrario, todos los pasos del procedimiento, excepto la entrega física, se aplican al manejo de las sondas.
Nota
- La generación de informes estará sujeta a la
política-seguridad.
14.7.1.1
Argumentos
1)Un mensaje desde el módulo principal con instrucciones por-destinatatrio para entregar a uno o más usuarios-STRM locales.
2)Los argumentos de entrega-mensaje enumerados en el cuadro 15/X.411 y descritos en los puntos indicados en este cuadro se pasan al usuario-STRM destinatario.
14.7.1.2
Resultados
1)Un resultado vacío o, si se solicita, una
prueba-de-entrega
y, opcionalmente, un
certificado-destinatario
devuelto por el usuario-STRM como
indicación de una entrega con éxito sin requisitos de información.
2)Si se requiere un informe, se invoca el módulo principal y se pasa el mensaje con instrucciones por-destinatario describiendo los problemas de entrega encontrados y»o indicando las entregas con éxito sobre las que hay que informar.
14.7.1.3
Errores
Los errores-abstractos de entrega-mensaje que pueden ser devueltos por el usuario-STRM al ATM se describen en el 8.3.1.1.3 . Estas condiciones de error se comunican al módulo principal en los resultados descritos anteriormente.
14.7.1.4
Descripción del procedimiento
1)Si se alcanza la expiración del mensaje, se genera una instrucción de
informe para cada destinatario local. Los valores de
código-motivo-no-entrega
y
código-diagnóstico-no-entrega
son respectivamente
incapaz-de-transferir
y
máximo-tiempo-expirado
. Finaliza entonces el procedimiento.
2)Si cualquiera de los
campos-ampliación
por-mensaje se
pone en
crítico-para-entrega
pero el ATM no lo entiende
semánticamente, se genera una instrucción de informe por cada destinatario
local. Los valores de
código-motivo-no-entrega
y de
código-diagnóstico-no-entrega
se ponen en
incapaz-de-transferir
y
función-crítica-no-permitida
respectivamente.
3)En caso contrario, se establecen los valores para aquellos argumentos de la operación-abstracta entrega-mensaje que se aplican a todos los destinatarios (los argumentos de entrega-mensaje se describen en el 8.3.1.1.1 ).
4)Para cada destinatario con
responsabilidad
verdadera se
ejecutan los pasos 4-15. Finaliza entonces el procedimiento.
5)Para garantizar que durante la entrega, no se viola la política-seguridad,
se compara la
etiqueta-seguridad-mensaje
con el
contexto-seguridad
. Si la política-seguridad impide la
entrega entonces, con sujeción a la política de seguridad, se genera una
instrucción de informe para ese destinatario. Los valores de
código-motivo-no-entrega
y
código-diagnóstico-no-entrega
son
incapaz-de-transferir
y
error-mensajería-segura
, respectivamente.
6)Si las restricciones impuestas por una operación-abstracta de registro o de control-entrega impiden la entrega, el ATM entonces, sujeto a la política-seguridad en vigor, retendrá el mensaje hasta que se levanten la restricción o las restricciones aplicables.
7)Si expira el máximo tiempo de retención para un mensaje retenido (siendo
el valor máximo de este tiempo un asunto local) con las restricciones
aplicables todavía en vigor, se genera una instrucción de informe para este
destinatario. Los valores de
código-motivo-no-entrega
y de
código-diagnóstico-no-entrega
se ponen respectivamente en
incapaz-de-transferir
y
destinatario-indisponible
. Termina entonces el proceso para
este destinatario.
Nota
- Los pasos de proceso (5 y 6 anteriores)
asociados con las restricciones de control no se aplican en el caso de las
sondas.
8)Si se hace cumplir la entrega restringida, y el destinatario está en la
categoría de remitente no autorizado, entonces se genera una instrucción de
informe para ese destinatario. Se fija
código-motivo-no-entrega
en el valor
entrega-restringida
. En ese momento, termina el
procesamiento para ese destinatario.
9)El ATM establece los argumentos de la operación-abstracta de
entrega-mensaje que se aplican únicamente al destinatario individual: los
valores
identificador-entrega-mensaje
y
tiempo-entrega-mensaje
se describen en los
8.3.1.1.1.1
y 8.3.1.1.1.2. Todos los restantes argumentos se toman
directamente de los campos correspondientes del mensaje a entregar. Con las
excepciones indicadas a continuación, todos los argumentos indicados en el
cuadro 11»X.411 se incluyen en cada invocación de entrega-mensaje.
10)Si
revelación-de-destinatarios
tiene el valor
revelación-de-destinatarios-autorizada
, el ATM incluye en el
argumento de
nombre-otro-destinatario
todos los
destinatarios, que estén especificados por el originador, excepto el presente.
Obsérvese que si el destinatario es un miembro de una lista de distribución,
en el argumento de
nombre-otro-destinatario
no deben
incluirse otros miembros de esta lista de distribución. El destinatario es un
miembro de la lista de distribución si el campo de
historia-ampliación-LD
es no-vacío.
11)Si alguno de los
campos-ampliación
por-destinatario se
pone en
crítico-para-entrega
, pero el ATM no lo entiende
semánticamente, se genera una instrucción de informe para este destinatario.
Los valores de
código-motivo-no-entrega
y de
código-diagnóstico-no-entrega
se ponen respectivamente en
incapaz- de-transferir
y
función-crítica-no-permitida
.
12)En el caso de entrega de una unidad de acceso de entrega física, los argumentos de entrega física se incluyen en la entrega-mensaje. Estos argumentos se describen en los 8.2.1.1.1.14 a 8.2.1.1.1.23.
13)Una vez satisfechas todas las condiciones para una entrega con éxito, el ATM entregará físicamente el mensaje. La consecución de la entrega a un usuario-STRM destinatario coubicado es un asunto local. En el caso de un usuario-STRM destinatario distante, el ATM establece una asociación con este usuario-STRM (o utiliza uno existente) e invoca la operación-abstracta de entrega-mensaje a través de esta asociación. Al realizar una entrega con éxito, la responsabilidad distante o local del mensaje pasa del ATM al usuario-STRM destinatario.
14)Al realizar una entrega con éxito, si la
petición-informe-entrega-ATM-que-origina
tiene el valor de
informe
o de
informe auditado
, se genera
una instrucción de informe señalando la entrega con éxito. Se termina el
proceso para este destinatario.
15)En el caso de un usuario-STRM destinatario distante, si no existe o no
puede establecerse inicialmente una asociación o si existe un fallo de
transferencia a través de la asociación, el ATM puede repetir el intento de
establecimiento de asociación y/o transferir, siendo el número máximo y/o la
duración de las repeticiones un asunto local. Si, después de repetidas
tentativas no se ha conseguido la transferencia, el mensaje es considerado como
inentregable y, se genera una instrucción de informe, sujeta a la
política-seguridad en vigor. Los valores del
código-motivo-no-entrega
y del
código-diagnóstico-no-entrega
son respectivamente
fallo-transferencia
y
destinatario-indisponible
. Termina entonces el proceso para
este destinatario.
Nota
- Los pasos del proceso asociados con la
transferencia física de un mensaje al usuario-STRM destinatario no se aplican
en el caso de la sonda.
16)Devolución de los resultados y errores por el usuario-STRM
Si la operación-abstracta de entrega-mensaje tiene éxito, el usuario-STRM
devuelve como indicación de éxito o bien un resultado vacío o bien, si se
solicitase, una
prueba-de-entrega
y un
certificado-destinatario-facultativo.
Si la operación-abstracta de entrega-mensaje viola uno o más de los
controles impuestos por la operación-abstracta de control-entrega o de
registro, el usuario-STRM devuelve un error de control-entrega-violado. Si el
contexto-seguridad
dicta que el usuario-STRM no puede
admitir la operación-abstracta solicitada porque violaría la
política-seguridad, el usuario-STRM devuelve entonces un error-seguridad. En
este caso, la invocación de la entrega-mensaje ha fracasado y el ATM conserva
la responsabilidad del mensaje respecto de este destinatario. El mensaje es
retenido para hacer un reintento a continuación, o es enviado al módulo
principal para la generación de un informe. Termina entonces el proceso para
este destinatario.
14.7.2
Procedimiento de prueba-entrega-sonda
Este punto describe los pasos dados por un ATM cuando emprende la tarea de comprobar la posibilidad de entregar una sonda.
Nota
- La utilización de informes estará sujeta a la
política-seguridad.
14.7.2.1
Argumentos
1)Sonda del procedimiento interno con instrucciones por-destinatario para la prueba-entrega-sonda a uno a más usuarios STRM locales.
14.7.2.2
Resultados
Se invoca el módulo principal y se transfiere la sonda con instrucciones por destinatario que describen si habría ocurrido o no la entrega ficticia, y si no, por qué motivo.
14.7.2.3
Errores
Ninguno.
14.7.2.4
Descripción de procedimiento
En el 14.7.1 se describe la lógica de la entrega-mensaje. Se ejecutan todos los pasos de este punto, excepto aquellos indicados específicamente como no aplicables a la sonda.
14.7.3
Procedimiento de entrega-informe
Este punto describe los pasos dados por un ATM cuando se encarga de
entregar un informe al usuario-STRM. Se llama a la entrega-informe cuando un
ATM recibe un informe, procedente de la entrada-informe o al generarse dentro
del ATM, cuyo campo de
nombre originador
especifica un
usuario-STRM servido por este ATM.
14.7.3.1
Argumentos
1)Un informe del módulo de informe con instrucciones por-destinatario para entregarlas a un destinatario local.
2)Los argumentos de entrega-informe enumerados en el cuadro 18/X.411 y descritos en los puntos indicados en dicho cuadro se tranfieren al usuario-STRM destinatario.
14.7.3.2
Resultados
Un resultado vacío devuelto por el usuario-STRM como indicación de una entrega con éxito.
14.7.3.3
Errores
Los errores de entrega-informe que pueden devolver el usuario-STRM al TM se describen en el 8.3.1.2.3 .
14.7.3.4
Descripción del procedimiento
1)Para garantizar que no se viola la política-seguridad durante la
entrega-informe, se comprueba la
etiqueta-seguridad-mensaje
respecto del contexto-seguridad. Si la entrega-informe está prohibida por la
política-seguridad, se descarta el informe.
2)Si las restricciones impuestas por una operación-abstracta de registro o control-entrega invocada previamente prohiben la entrega-informe, el ATM retendrá, sujeto a la política-seguridad en vigor, el informe hasta que cesen la restricción o las restricciones aplicables. Los argumentos de la operación-abstracta de control-entrega o de registro establecen las restricciones según se describe en el 8.3.1.3.1 .
Si expira el máximo tiempo de retención para un informe retenido (siendo el valor máximo de este tiempo un asunto local) con las restricciones aplicables todavía en vigor, se descarta el informe.
3)Los argumentos para la operación-abstracta de entrega-informe se toman de los correspondientes campos del informe.
4)Si cualquiera de los
campos-ampliación
por-mensaje o
por-destinatario se pone en
crítico-para-entrega
, pero no es
entendido semánticamente por el ATM, se descarta el informe.
5)La consecución de la entrega-informe a un usuario-STRM coubicado es un asunto local. En el caso de un usuario-STRM distante, el ATM establece una asociación con dicho usuario-STRM (o utiliza uno existente) e invoca la operación-abstracta de entrega-informe a través de la asociación. Al tener éxito una entrega-informe, la responsabilidad distante o local del informe pasa del ATM al usuario-STRM.
6)En el caso de un usuario-STRM distante, si no puede establecerse inicialmente una asociación, el ATM puede repetir la tentativa, siendo el número máximo y la duración de las repeticiones un asunto local. Si, después de varias tentativas no se ha establecido la asociación, el informe se considera inentregable y se descarta.
7)Devolución de resultados y errores por el usuario-STRM.
Si la operación-abstracta de entrega-informe tiene éxito, el usuario-STRM devuelve un resultado vacío como indicación del éxito.
Si la operación-abstracta de entrega-informe viola uno o más controles impuestos por una operación-abstracta de control-entrega o de registro, el usuario-STRM devuelve un error de control-entrega-violado. En este caso, la invocación de entrega-informe ha fracasado y el ATM conserva la responsabilidad del informe.
14.7.4
Procedimiento de control-entrega
Este apartado describe el comportamiento del ATM cuando un usuario-STRM
servido por dicho ATM invoca la operación-abstracta de control-entrega. Esta
última impone y levanta restricciones sobre las operaciones-abstractas de
entrega-mensaje y entrega-informe. Estos controles permanecen vigentes durante
la presente asociación, a menos que sean anulados por un control-entrega
subsiguientes. Los controles-entrega limitan de forma transitoria el
contexto-seguridad
, pero no pueden provocar ninguna
violación de la política-seguridad.
Estos controles no se aplican al tratamiento de las sondas por el ATM.
14.7.4.1
Argumentos
Los argumentos de control-entrega enumerados en el cuadro 20»X.411 y descritos en el 8.3.1.3.1 .
14.7.4.2
Resultados
1)Los resultados del control-entrega enumerados en el cuadro 21»X.411 que se describen en el 8.3.1.3.2 , son devueltos por el ATM al usuario-STRM.
2)Varios parámetros de control de usuario-STRM retenidos por este ATM se sustituyen por valores transportados en los argumentos de control-entrega.
14.7.4.3
Errores
Véase el 8.3.1.3.3 para una descripción de los errores-abstractos pertinentes.
14.7.4.4
Descripción del procedimiento
1)Si el valor del argumento
restricción
es
eliminación
, todos los controles establecidos por cualquier
control-entrega previo se eliminan; la operación-abstracta está terminada y se
devuelve el resultado al usuario-STRM.
2)Si el valor del argumento
restricción
es
actualización
, y no existe ningún otro argumento presente,
se considera válida la petición y se devuelve el resultado al usuario-STRM.
En dichos casos todos los valores de control vigentes en ese momento permanecen sin modificación.
3)Si el valor del argumento
restricción
es
actualización
, y están presentes otros argumentos, se
comprueba la compatibilidad de estos argumentos con las condiciones a largo
plazo especificadas por la invocación más reciente de la operación-abstracta de
restricción en el puerto-administración (véase el
14.4.1
). Si no se
detecta ninguna incompatibilidad y está permitida la actualización dentro de la
política-seguridad, se llevan a cabo las actualizaciones indicadas, la
operación-abstracta finaliza y se devuelve el resultado al usuario-STRM.
4)Si se detecta alguna de las siguientes incompatibilidades con condiciones a largo plazo, el ATM devuelve un error-abstracto de control-viola-registro:
a)
Tipos-información-codificada-admisibles
tiene un tipo
no especificado entre los permitidos a largo plazo.
b)
Tipos-contenido-admisibles
tiene un contenido no
especificado entre los permitidos a largo plazo.
c)La
longitud-máxima-contenido-admisible
excede la
longitud aurorizada a largo plazo.
d)Se viola el
contexto-seguridad-admisible
.
En cualquiera de estos casos de error, se descarta el control-entrega y no se lleva a cabo.
14.8
Puerto de administración
14.8.1
Procedimiento de registro
Este punto describe el comportamiento del ATM cuando un usuario-STRM servido por este ATM invoca la operación-abstracta de registro.
14.8.1.1
Argumentos
Los argumentos de registro enumerados en el cuadro 23/X.411 y descritos en los puntos indicados en dicho cuadro.
14.8.1.2
Resultados
1)El procedimiento de registro devuelve un resultado vacío al usuario-STRM como indicación de éxito.
2)Varios parámetros del usuario-STRM retenidos por el ATM se sustituyen por valores transportados en los argumentos de registro.
14.8.1.3
Errores
Un error rechazado-registro devuelto al usuario-STRM, como se describe en el 8.4.1.1.3 .
14.8.1.4
Descripción del procedimiento
1)Se comprueba la correcta especificación de los argumentos de registro. Si alguno está incorrectamente especificado, el procedimiento de registro devuelve un error rechazado-registro y finaliza.
2)Si los argumentos de registro están correctamente especificados, los valores de los parámetros del usuario-STRM se sustituyen por los argumentos de registro, y finaliza el procedimiento.
14.8.2
Procedimiento de cambio-de-credenciales iniciado por
el usuario-STRM
Este punto describe el comportamiento del ATM cuando el usuario-STRM invoca la operación-abstracta de cambio-de-credenciales.
Nota
- Todos los cambios de credenciales estarán
sujetos a la política-seguridad en vigor.
14.8.2.1
Argumentos
Los argumentos de cambio-de-credenciales enumerados en el cuadro 25/X.411 y descritos en el 8.4.1.2.1 .
14.8.2.2
Resultados
1)El procedimiento de cambio-de-credenciales devuelve un resultado vacío al usuario-STRM como indicación de éxito.
2)Las credenciales del usuario-STRM retenidas por el ATM se modifican de
acuerdo con el argumento de
nuevas credenciales
.
14.8.2.3
Errores
El error-abstracto de nuevas-credenciales-inaceptables o antiguas-credenciales-incorrectamente-especificadas, descrito en el 8.4.1.2.3 y enumerado en el cuadro 26/X.411.
14.8.2.4
Descripción del procedimiento
Nota
- Todos los cambios de credenciales estarán
sujetos a la política-seguridad en vigor.
1)Si el valor del argumento de
antiguas-credenciales
no
es el mismo que el de las credenciales retenidas por el ATM para el
usuario-STRM que invoca la operación-abstracta, se devuelve al usuario-STRM un
error de antiguas-credenciales-incorrectamente-especificadas y finaliza el
procedimiento de cambio-de-credenciales.
2)En caso contrario, se comprueba la validez del argumento de
nuevas-credenciales
. Si se encuentra que es inválido (asunto
local dictado por la política-seguridad) se devuelve al usuario-STRM un error
de nuevas-credenciales-inaceptables y finaliza el procedimiento de
cambio-de-credenciales.
3)En caso contrario, las credenciales del usuario-STRM retenidas por este
ATM se sustituyen por el valor del argumento de las
nuevas-credenciales
, se devuelve un resultado vacío al
usuario-STRM como indicación de éxito y finaliza el procedimiento de
cambio-de-credenciales.
14.8.3
Procedimiento de cambio-de-credenciales iniciado por
el ATM
Este punto describe el comportamiento del ATM al cambiar sus credenciales retenidas por un usuario-STRM soportado localmente.
Nota
- Todos los cambios de credenciales estarán
sujetos a la política-seguridad en vigor.
14.8.3.1
Argumentos
Los argumentos de cambio-de-credenciales enumerados en el cuadro 25/X.411 y descrito en el 8.4.1.2.1 .
14.8.3.2
Resultados
El usuario-STRM devuelve un resultado vacío al procedimiento de cambio-de-credenciales como indicación de éxito.
14.8.3.3
Errores
El usuario-STRM puede devolver un error de nuevas-credenciales-inaceptables o antiguas-credenciales-incorrectamente-especificadas, según se describe en el 8.4.1.2.3 y se enumera en el cuadro 26/X.411.
14.8.3.4
Descripción del procedimiento
Nota
- Todos los cambios de credenciales estarán
sujetos a la política-seguridad en vigor.
1)El procedimiento invoca la operación-abstracta de cambio-de-credenciales para cambiar las credenciales del ATM retenidas por un usuario-STRM soportado-localmente. Las condiciones que hacen que un ATM cambie sus credenciales constituyen un asunto local.
2)Si se recibe del usuario-STRM el error de nuevas-credenciales-inaceptables o antiguas-credenciales-incorrectamente-especificadas, el ATM debe suponer que sus credenciales no han cambiado. A nivel local se puede emprender una actuación ulterior, después de la cual finaliza el procedimiento.
3)Si se recibe la devolución de un resultado vacío procedente del usuario-STRM, el ATM puede suponer que el procedimiento ha tenido éxito y que sus credenciales han cambiado. El procedimiento termina.
14.9
Vinculación-ATM y
desvinculación-ATM
14.9.1
Procedimiento de entrada-vinculación-ATM
Este punto describe el comportamiento del ATM cuando otro ATM invoca vinculación-ATM.
14.9.1.1
Argumentos
Los argumentos de vinculación-ATM se definen en el 12.1.1.1.1 y se enumeran en el cuadro 27/X.411.
14.9.1.2
Resultados
Los resultados de vinculación-ATM se definen en el 12.1.1.1.2 y se enumeran en el cuadro 28/X.411.
14.9.1.3
Errores
Los errores vinculación se definen en el 12.1.2 .
14.9.1.4
Descripción del procedimiento
1)Si los recursos de los ATM no permiten normalmente el establecimiento de una nueva asociación, el procedimiento devuelve un error-vinculación de ocupado y finaliza.
2)En caso contrario, si la política-seguridad exige la autenticación, el ATM
intenta tanto autenticar el ATM llamante a través de las
credenciales-iniciador
suministradas como comprobar la
posibilidad de aceptación del
contexto-seguridad
. Si no
pueden autenticarse las
credenciales-iniciador
, el
procedimiento devuelve un error-autenticación y finaliza. Si el
contexto-seguridad
no resulta aceptable, el procedimiento
devuelve un error de contexto-seguridad-inaceptable y finaliza.
3)Si la autenticación es satisfactoria y el
contexto-seguridad
resulta aceptable, el ATM establece la
asociación solicitada. El procedimiento devuelve el
nombre-ATM
y las
credenciales-respondedor
. Finaliza entonces el
procedimiento.
4)Si no se requiere autenticación, no hay resultados que devolver y el procedimiento finaliza.
14.9.2
Procedimiento de entrada-desvinculación-ATM iniciado
por usuario-STRM
Este punto describe el comportamiento del ATM cuando otro ATM invoca desvinculación-ATM para liberar una asociación existente establecida por el usuario-STRM.
14.9.2.1
Argumentos
Ninguno.
14.9.2.2
Resultados
El procedimiento de entrada-desvinculación-ATM devuelve un resultado vacío como indicación de la liberación de la asociación.
14.9.2.3
Errores
Ninguno.
14.9.2.4
Descripción del procedimiento
El procedimiento libera la asociación, devuelve un resultado vacío y finaliza.
14.9.3
Procedimiento de salida-vinculación-ATM
Este punto describe los pasos dados por el ATM cuando emprende la tarea de establecer una asociación con otro ATM.
14.9.3.1
Argumentos
1)El
nombre-ATM
del ATM con quién se ha establecido la
asociación.
2)El
contexto-seguridad
para la asociación.
14.9.3.2
Resultados
Un identificador interno para la asociación establecida.
14.9.3.3
Errores
El procedimiento devuelve una indicación de fallo en caso de no poderse establecer la asociación.
14.9.3.4
Descripción del procedimiento
1)El procedimiento establece los valores para los argumentos definidos en el
12.1.1.1.1
. Se toman los valores de
nombre-iniciador
,
contexto-seguridad
y
credenciales-iniciador
de la información interna.
2)El procedimiento determina la dirección del ATM e intenta establecer una asociación con los argumentos del 12.1.1.1.1 . Si no tiene éxito, se devuelve una indicación de fallo y finaliza el procedimiento.
3)Si tiene éxito, se examinan los resultados devueltos por el ATM llamado
(definido en el
12.1.1.1.2
). Se comprueba la corrección del
nombre-respondedor
y se realiza un intento de autenticar el
ATM a través de las
credenciales-respondedor
devueltas. Si
alguna de las comprobaciones falla, el procedimiento cierra la conexión,
devuelve una indicación de fallo y finaliza.
4)Si ambas comprobaciones tienen éxito, el procedimiento devuelve el identificador de la asociación y finaliza.
14.9.4
Procedimiento de salida-desvinculación-ATM
Se llama a este procedimiento para liberar una asociación con otro ATM.
14.9.4.1
Argumentos
El identificador interno de la asociación que ha de liberarse.
14.9.4.2
Resultados
El procedimiento de salida-desvinculación-ATM devuelve un resultado vacío como indicación de la liberación de la asociación.
14.9.4.3
Errores
Ninguno.
14.9.4.4
Descripción del procedimiento
El procedimiento libera la asociación, devuelve un resultado vacío y finaliza.
14.10
Puerto de transferencia
Nota
- Las medidas adoptadas en el
puerto-transferencia están sujetas a la política-seguridad en vigor.
14.10.1
Procedimiento de entrada-mensaje
Este punto describe el comportamiento del ATM cuando el otro ATM invoca la operación-abstracta de transferencia-mensaje en un puerto de transferencia.
14.10.1.1
Argumentos
Los argumentos de transferencia-mensaje enumerados en el cuadro 29/X.411 y descritos en los puntos indicados en este cuadro.
14.10.1.2
Resultados
1)Se invoca el módulo entrega-diferida y se pasa el mensaje transferido.
14.10.1.3
Errores
Ninguno.
14.10.1.4
Descripción del procedimiento
Al recibir un mensaje, mediante la consecución de una operación-abstracta de transferencia-mensaje (invocada desde un ATM vecino), se invoca el procedimiento de entrada-mensaje. Este procedimiento transfiere simplemente el mensaje al módulo entrega-diferida para determinar las acciones que debe emprender este ATM.
La responsabilidad sobre el mensaje pasa al ATM-receptor con la transferencia efectuada satisfactoriamente.
14.10.2
Procedimiento de entrada-sonda
Este punto describe el comportamiento del ATM cuando otro ATM invoca la operación-abstracta de transferencia-sonda en un puerto-transferencia.
14.10.2.1
Argumentos
Los argumentos de transferencia-sonda enumerados en el cuadro 30/X.411 y descritos en los puntos indicados en dicho cuadro.
14.10.2.2
Resultados
1)Se invoca el módulo principal y se pasa la sonda transferida.
14.10.2.3
Errores
Ninguno.
14.10.2.4
Descripción del procedimiento
Al recibir una sonda mediante la aparición de una operación-abstracta de transferencia-sonda (invocada desde un ATM vecino), se invoca el procedimiento de entrada-sonda. Este procedimiento simplemente pasa la sonda al módulo principal para determinar las acciones que debe emprender este ATM.
La responsabilidad de la sonda pasa al ATM receptor si la transferencia se realizó con éxito.
14.10.3
Procedimiento de entrada-informe
Este punto describe el comportamiento del ATM al recibir un informe en una puerta-transferencia mediante la aparición de una operación-abstracta de transferencia-informe invocada por otro ATM o al recibir una indicación para la generación de un informe procedente de una unidad de acceso tal como una UAEF.
14.10.3.1
Argumentos
Los argumentos de informe enumerados en el cuadro 31/X.411 y descritos en los puntos indicados en este cuadro.
14.10.3.2
Resultados
1)Se invoca el módulo informe y se pasa el informe transferido.
14.10.3.3
Errores
Ninguno.
14.10.3.4
Descripción del procedimiento
Al recibir una sonda mediante la aparición de una operación-abstracta de transferencia-sonda (invocada desde un ATM vecino), o al recibir una indicación para una generación de un informe procedente de una unidad de acceso tal como una UAEF, se invoca el procedimiento de entrada-informe. Este procedimiento simplemente transfiere el informe al módulo informe para determinar las acciones que debe emprender este ATM.
La responsabilidad de la sonda pasa al ATM receptor si la transferencia se realizó satisfactoriamente.
14.10.4
Procedimiento de salida-mensaje
Este punto describe los pasos dados por un ATM cuando éste se encarga de transferir un mensaje a otro ATM.
14.10.4.1
Argumentos
Un mensaje del procedimiento interno con instrucciones de encaminamiento para transferir a otro ATM. Los campos de este mensaje forman los argumentos de la operación-abstracta de transferencia-mensaje enumerados en el cuadro 29/X.411.
14.10.4.2
Resultados
Ninguno.
14.10.4.3
Errores
En el caso de un fallo de transferencia se invoca el módulo-principal y se pasa el mensaje con una instrucción por-mensaje que indica el motivo del fallo.
14.10.4.4
Descripción del procedimiento
El mensaje que hay que transferir proporciona los argumentos de la operación-abstracta de transferencia-mensaje. Debe observarse que el mensaje puede reflejar el proceso (por ejemplo, conversión de contenido, redireccionamiento, ampliación de la lista de distribución) llevado a cabo en este o en anteriores ATM.
1)Para garantizar que no se viola la política-seguridad durante la
transferencia, se compara la
etiqueta-seguridad-mensaje
con
el
contexto-seguridad
. Si se prohibe la transferencia debido
a la política-seguridad o a restricciones transitorias, el proceso continúa en
el paso 3 siguiente.
2)En caso contrario, el ATM establece una asociación con el ATM-receptor (o utiliza uno existente) e invoca la operación-abstracta de transferencia-mensaje a través de esta asociación. La consecución de la salida-mensaje indica que la transferencia ha tenido éxito y que el ATM-receptor acepta ahora la responsabilidad del mensaje. Finaliza ahora el procedimiento de salida-mensaje.
Si no existe una asociación o no puede establecerse inicialmente, o existe un fallo de transferencia a través de la asociación, el ATM puede repetir el intento de establecimiento de asociación y/o transferencia, siendo el máximo número y/o la duración de las repeticiones un asunto local.
3)Si después de repetidos intentos no se ha logrado la transferencia, o se ha detectado en el paso 1 una violación de seguridad, se considera el mensaje como no transferible y se devuelve, con el motivo del fallo indicado, al módulo principal para un posible reencaminamiento o redireccionamiento. La responsabilidad del mensaje permanece en el ATM emisor. Termina entonces el procedimiento de salida-mensaje.
14.10.5
Procedimiento de salida-sonda
Este punto describe los pasos dados por un ATM cuando éste se encarga de transferir una sonda a otro ATM.
14.10.5.1
Argumentos
Una sonda del procedimiento interno con instrucciones de encaminamiento para transferir a otro ATM. Los campos de esta sonda forman los argumentos de la operación-abstracta de transferencia-sonda enumerados en el cuadro 30/X.411.
14.10.5.2
Resultados
Ninguno.
14.10.5.3
Errores
En el caso de un fallo de transferencia se invoca el módulo principal y se transfiere la sonda con una instrucción por-mensaje que indica el motivo del fallo.
14.10.5.4
Descripción del procedimiento
La sonda que hay que transferir proporciona los argumentos de la operación-abstracta de transferencia-sonda. Debe observarse que la sonda puede reflejar el proceso (por ejemplo, redireccionamiento) llevado a cabo en este o en anteriores ATM.
1)Para garantizar que no se viola la política de seguridad durante la
transferencia, se compara la
etiqueta-seguridad-mensaje
con
el
contexto-seguridad
. Si se prohibe la transferencia debido
a la política-seguridad o a restricciones transitorias, el proceso continúa en
el paso 3 siguiente.
2)El ATM establece una asociación con el ATM receptor (o utiliza uno existente) e invoca la operación-abstracta de transferencia-sonda a través de esta asociación. La consecución de la salida-mensaje indica que la transferencia ha tenido éxito y que el ATM-receptor acepta ahora la responsabilidad de la sonda. Finaliza ahora el procedimiento de salida-sonda.
Si no existe una asociación o no puede establecerse inicialmente, o existe un fallo de transferencia a través de la asociación, el ATM puede repetir la tentativa de establecimiento de asociación y/o transferencia, siendo el máximo número y/o duración de las repeticiones un asunto local.
3)Si después de repetidos intentos no se ha logrado la transferencia, o se ha detectado en el paso 1 una violación de seguridad, se considera la sonda como no transferible y se devuelve, con el motivo del fallo indicado, al módulo principal para un posible reencaminamiento o redireccionamiento. La responsabilidad del mensaje permanece en el ATM emisor. Termina entonces el procedimiento de salida-sonda.
14.10.6
Procedimiento de salida-informe
Este punto describe los pasos dados por un ATM cuando se enfrenta con la transferencia de un informe a otro ATM.
14.10.6.1
Argumentos
Un informe del procedimiento interno con instrucciones de encaminamiento para transferir a otro ATM. Los campos de este informe forman los argumentos de la operación-abstracta de transferencia-informe enumerados en el cuadro 31/X.411.
14.10.5.2
Resultados
Ninguno.
14.10.6.3
Errores
El informe, junto con el motivo del fallo de transferencia se devuelven al módulo informe.
14.10.6.4
Descripción del procedimiento
El informe que hay que transferir proporciona los argumentos de la operación-abstracta de transferencia-informe. Debe observarse que el informe puede reflejar el proceso (por ejemplo, redireccionamiento) llevado a cabo en este o en anteriores ATM.
1)Para garantizar que no se viola la política de seguridad durante la
transferencia, se compara la
etiqueta-seguridad-mensaje
con
el
contexto-seguridad
. Si se prohibe la transferencia debido
a la política-seguridad o a restricciones transitorias, el proceso continúa en
el paso 3 siguiente.
2)El ATM establece una asociación con el ATM-receptor (o utiliza uno existente) e invoca la operación-abstracta de transferencia-informe a través de esta asociación. La consecución de la salida-informe indica que la transferencia ha tenido éxito y que el ATM-receptor acepta ahora la responsabilidad del informe. Finaliza ahora el procedimiento de salida-informe.
Si no existe una asociación o no puede establecerse inicialmente, o existe un fallo de transferencia a través de la asociación, el ATM puede repetir la tentativa de establecimiento de asociación y/o transferencia, siendo el máximo número y/o la duración de las repeticiones un asunto local.
3)Si después de repetidos intentos no se ha logrado la transferencia, o se ha detectado en el paso 1 una violación de seguridad, se considera el informe como no transferible y se devuelve, con el motivo del fallo indicado, al módulo informe para un posible reencaminamiento o redireccionamiento. La responsabilidad del informe permanece en el ATM emisor. Termina entonces el procedimiento de salida-informe.
ANEXO A (a la Recomendación X.411)
Definición de
referencia de los identificadores de objetos del STRM
Todos los identificadores de objetos que asigna esta Recomendación se indican en este anexo. El anexo es definitivo para todos, excepto para los módulos NSA.1 y el propio sistema de transferencia de mensajes. Las asignaciones definitivas para los primeros se producen en los propios módulos; en las cláusulas IMPORTAR aparecen otras referencias a ellas. Esas cláusulas están fijadas.
MTSObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0) object-identifiers(0)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS --
nada
--;
--
Sistema de transferencia de mensajes
id-mts OBJECT IDENTIFIER ::= {^joint-iso-ccitt mhs-motis(6) mts(3)^}--
no definitivo
--
Categorías de identificadores de objeto
id-mod OBJECT IDENTIFIER ::= {^id-mts 0^} --
módulos
id-ot OBJECT IDENTIFIER ::= {^id-mts 1^} --
tipos de
objeto
id-pt OBJECT IDENTIFIER ::= {^id-mts 2^} --
tipos de
puerta
id-cont OBJECT IDENTIFIER ::= {^id-mts 3^} --
tipos de
contenido
id-eit OBJECT IDENTIFIER ::= {^id-mts 4^} --
tipos de
información codificada
id-att OBJECT IDENTIFIER ::= {^id-mts 5^} --
atributos
id-tok OBJECT IDENTIFIER ::= {^id-mts 6^} --
tipos de
distintivo
id-sa OBJECT IDENTIFIER ::= {^id-mts 7^} --
tipos de
agentes seguros
--
Módulos
id-mod-object-identifiers OBJECT IDENTIFIER ::= {^id-mod 0^} --
no definitivo
id-mod-mts-abstract-service OBJECT IDENTIFIER ::= {^id-mod 1^} --
no definitivo
id-mod-mta-abstract-service OBJECT IDENTIFIER ::= {^id-mod
2^} --
no
definitivo
FIGURA A-1/X.411 (parte 1 de 3)
Definición de la sintaxis
abstracta de los identificadores de objetos del STRM
id-mod-upper-bounds OBJECT IDENTIFIER ::= {^id-mod 3^}
--
no
definitivo
--
Tipos de objeto
id-ot-mts OBJECT IDENTIFIER ::= {^id-ot 0^}
id-ot-mts-user OBJECT IDENTIFIER ::= {^id-ot 1^}
id-ot-mta OBJECT IDENTIFIER ::= {^id-ot 2^}
--
Tipos de puerto
id-pt-submission OBJECT IDENTIFIER ::= {^id-pt 0^}
id-pt-delivery OBJECT IDENTIFIER ::= {^id-pt 1^}
id-pt-administration OBJECT IDENTIFIER ::= {^id-pt 2^}
id-pt-transfer OBJECT IDENTIFIER ::= {^id-pt 3^}
--
Tipos de contenido
id-cont-undefined OBJECT IDENTIFIER ::= {^id-cont 0^}
id-cont-inner-envelope OBJECT IDENTIFIER ::= {^id-cont 1^}
--
Tipos de información codificada
id-eit-undefined OBJECT IDENTIFIER ::= {^id-eit 0^}
id-eit-telex OBJECT IDENTIFIER ::= {^id-eit 1^}
id-eit-ia5-text OBJECT IDENTIFIER ::= {^id-eit 2^}
id-eit-g3-facsimile OBJECT IDENTIFIER ::= {^id-eit 3^}
id-eit-g4-class-1 OBJECT IDENTIFIER ::= {^id-eit 4^}
id-eit-teletex OBJECT IDENTIFIER ::= {^id-eit 5^}
id-eit-videotex OBJECT IDENTIFIER ::= {^id-eit 6^}
FIGURA A-1/X.411 (parte 2 de 3)
Definición de la sintaxis
abstracta de los identificadores de objetos del STRM
id-eit-voice OBJECT IDENTIFIER ::= {^id-eit 7^}
id-eit-sfd OBJECT IDENTIFIER ::= {^id-eit 8^}
id-eit-mixed-mode OBJECT IDENTIFIER ::= {^id-eit 9^}
--
Atributos
id-att-physicalRendition-basic OBJECT IDENTIFIER ::= {^id-att 0^}
--
Tipos de testigos
id-tok-asymmetricToken OBJECT IDENTIFIER ::= {^id-tok 0^}
--
Tipos de agentes seguros
id-sa-ua OBJECT IDENTIFIER ::= {^id-sa 0^}
id-sa-ms OBJECT IDENTIFIER ::= {^id-sa 1^}
END --
of MTSObjectIdentifiers
FIGURA A-1/X.411 (parte 3 de 3)
Definición de la sintaxis
abstracta de los identificadores de objetos del STRM
ANEXO B (a la Recomendación X.411)
Definición de referencia de
los límites superiores de los parámetros del STRM
Este anexo define como referencia los límites superiores de varios tipos de
datos de longitud variable, cuyas sintaxis abstractas se definen en los módulos
NSA.1 del texto de esta Recomendación. Los límites superiores se definen en la
figura B-1/X.411.
MTSUpperBounds {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0) upper-bounds(3)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS --
nothing
--;
--
Límites superiores
ub-integer-options INTEGER ::= 256
ub-queue-size INTEGER ::= 2147483647
--
el mayor entero en 32 bits
ub-content-length INTEGER ::= 2147483647
--
el mayor entero en 32 bits
ub-password-length INTEGER ::= 62
ub-bit-options INTEGER ::= 16
ub-content-types INTEGER ::= 1024
ub-tsap-id-length INTEGER ::= 16
ub-recipients INTEGER ::= 32767
ub-content-id-length INTEGER ::= 16
ub-x121-address-length INTEGER ::= 15
ub-mts-user-types INTEGER ::= 256
ub-reason-codes INTEGER ::= 32767
ub-diagnostic-codes INTEGER ::= 32767
ub-supplementary-info-length INTEGER ::= 256
ub-extension-types INTEGER ::= 256
FIGURA B-1/X.411 (parte 1 de 3)
Definiciones de la sintaxis
abstracta de los límites superiores del STRM
ub-recipient-number-for-advice-length INTEGER ::= 32
ub-content-correlator-length INTEGER ::= 512
ub-redirections INTEGER ::= 512
ub-dl-expansions INTEGER ::= 512
ub-built-in-content-type INTEGER ::= 32767
ub-local-id-length INTEGER ::= 32
ub-mta-name-length INTEGER ::= 32
ub-country-name-numeric-length INTEGER ::= 3
ub-country-name-alpha-length INTEGER ::= 2
ub-domain-name-length INTEGER ::= 16
ub-terminal-id-length INTEGER ::= 24
ub-organization-name-length INTEGER ::= 64
ub-numeric-user-id-length INTEGER ::= 32
ub-surname-length INTEGER ::= 40
ub-given-name-length INTEGER ::= 16
ub-initials-length INTEGER ::= 5
ub-generation-qualifier-length INTEGER ::= 3
ub-organizational-units INTEGER ::= 4
ub-organizational-unit-name-length INTEGER ::= 32
ub-domain-defined-attributes INTEGER ::= 4
ub-domain-defined-attribute-type-length INTEGER ::= 8
ub-domain-defined-attribute-value-length INTEGER ::= 128
FIGURA B-1/X.411 (parte 2 de 3)
Definiciones de la sintaxis
abstracta de los límites superiores del STRM
ub-extension-attributes INTEGER ::= 256
ub-common-name-length INTEGER ::= 64
ub-pds-name-length INTEGER ::= 16
ub-postal-code-length INTEGER ::= 16
ub-pds-parameter-length INTEGER ::= 30
ub-physical-address-lines INTEGER ::= 6
ub-unformatted-address-length INTEGER ::= 180
ub-e163-4-number-length INTEGER ::= 15
ub-e163-4-sub-address-length INTEGER ::= 40
ub-built-in-encoded-information-types INTEGER ::= 32
ub-teletex-private-use-length INTEGER ::= 128
ub-encoded-information-types INTEGER ::= 1024
ub-security-labels INTEGER ::= 256
ub-labels-and-redirections INTEGER ::= 256
ub-security-problems INTEGER ::= 256
ub-privacy-mark-length INTEGER ::= 128
ub-security-categories INTEGER ::= 64
ub-transfers INTEGER ::= 512
ub-bilateral-info INTEGER ::= 1024
ub-additional-info INTEGER ::= 1024
END --
of MTSUpperBounds
FIGURA B-1/X.411 (parte 3 de 3)
Definiciones de la sintaxis
abstracta de los límites superiores del STRM
ANEXO C (a la Recomendación X.411)
Diferencias entre la Norma
ISO/CEI y la Recomendación del CCITT
En este anexo se identifican las
diferencias técnicas entre la Recomendación X.411 del CCITT y la Norma ISO/CEI
10021-4.
Estas diferencias son:
1) En la Recomendación X.411 los campos de ampliación se identifican mediante enteros. La publicación ISO/CEI 10021-4 permite además la utilización de identificadores de objeto para ampliaciones dentro de los DGPR y/o entre ellos.
2)En la Recomendación X.411 se establecen limitaciones de tamaño a un cierto número de campos de protocolo (véase el anexo B). En la publicación ISO/CEI 10021-4, los valores reales de las limitaciones no forman parte de la Norma.
Anexo D
Disk. 591 NF01/009 OPM: 01
- NF01/009 OPM: 01
- NF01/030 OPM: 01
PORTS^{^NF01/036 OPM: 01
ContraintAlternative NF01/047 OPM: 01
::= NF01/047 OPM: 01
SECCIóN 2 - NF01/034 OPM: 02
VALUE NOTATION Disk. 592 NF01/005 OPM: 02
::= NF01/005 OPM: 02
BIN-ERROR NF01/007 OPM: 02
[1] SET SNF01/047 OPM: 02
iii) NF01/048 OPM: 02
(cs,) - (cs,)
(1BT) (BT..)
(87.TE.13.S)
(A1.23s) / [26s]
FOLIOS: 426 - 467
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 11.09.89 PR
ID + LASER 10.10.89 JC
MAJ diskette 12.10.89 JC
Corr. LASER (1re épreuve) = 3eme 02.11.89 SJ
Espaces réservés 9.11.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 13.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 15.11.89 PC
BAT du 27/XI/89 1.12.89 PV
MAJ DISKETTE ........ ..
Recomendación X.413
SISTEMAS DE TRATAMIENTO DE MENSAJES:
DEFINICIóN DEL SERVICIO ABSTRACTO DE
ALMACENAMIENTO DE MENSAJES
(Melbourne, 1988)
El establecimiento en diversos países de servicios telemáticos y de servicios
de mensajes con almacenamiento y retransmisión basados en computador, y
asociados a redes públicas de datos, ha creado la necesidad de elaborar normas
para facilitar el intercambio de mensajes en el plano internacional entre los
abonados a esos servicios.
El CCITT,
considerando
(a) la necesidad de servicios de tratamiento de mensajes;
(b) la necesidad de transferir y almacenar mensajes de diferentes tipos;
(c) que la Recomendación X.200 define el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(d) que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones del CCITT;
(e) que las Recomendaciones de la serie X.500 especifican servicios y sistemas de guía;
(f) que los servicios y sistemas de tratamiento de mensajes se especifican en la serie de Recomendaciones: X.400, X.402, X.403, X.407, X.408, X.411, X.413 y X.419;
(g) que la mensajería interpersonal se especifica en las Recomendaciones X.420 y T.330,
recomienda por unanimidad
(1) que la definición del servicio abstracto de almacenamiento de mensajes sea la especificada en la sección 2;
(2) que los tipos de atributos generales y los tipos de acciones automáticas generales sean las especificadas en la sección 3;
(3) que los procedimientos para el almacenamiento de mensajes y la realización de puertos sean los especificados en la sección 4.
íNDICE
SECCIóN 1 -
Introducción
0Introducción
1Campo de aplicación
2Referencias
3Definiciones
4Abreviaturas
5Convenios
SECCIóN 2 -
Definición del servicio abstracto de
almacenamiento de mensajes
6Modelo de almacenamiento de mensajes
7Operaciones abstractas de vinculación y de desvinculación
8Operaciones abstractas
9Errores abstractos
SECCIóN 3 -
Tipos de atributos generales y tipos de
acciones automáticas generales
10Visión de conjunto
11Tipos de atributos generales
12Tipos de acciones automáticas generales
SECCIóN 4 -
Procedimiento para almacenamiento de mensajes y
realización de puertos
13Visión de conjunto
14Consumo del servicio abstracto de sistema de transferencia de mensajes
15Suministro del servicio abstracto de almacenamiento de mensajes
16Realización de puertos
Anexo A
-Asignación formal de identificadores de objeto
Anexo B
-Definición formal del servicio abstracto de
almacenamiento de mensajes
Anexo C
-Definición formal de tipos de atributos
generales
Anexo D
-Definición formal de tipos de acciones
automáticas generales
Anexo E
-Definición formal de límites superiores de
parámetros AM
Anexo F
-Ejemplos de la operación abstracta resumir
Anexo G
-Diferencias entre el texto de la Recomendación
X.413 del CCITT y el texto de la Norma ISO/CEI 10021-5
0 Introducción
Esta Recomendación forma parte de una serie de Recomendaciones que definen el tratamiento de mensajes (TM) en un entorno de sistemas abiertos distribuidos.
El tratamiento de mensajes proporciona el intercambio de mensajes entre usuarios en base al almacenamiento y retransmisión. El mensaje depositado por un usuario (el originador) es transferido a través del sistema de transferencia de mensajes (STRM) y entregado a uno o varios usuarios (los destinatarios).
Esta Recomendación define el servicio abstracto de almacenamiento de mensajes (servicio abstracto AM) que permite la extracción de mensajes de un dispositivo de almacenamiento de mensajes (AM) y el depósito indirecto de mensajes a través del AM en un sistema de tratamiento de mensajes (STM). El servicio abstracto AM proporciona también servicios de administración de mensajes, definidos por el servicio abstracto de sistema de transferencia de mensajes (STRM).
Esta Recomendación ha sido elaborada sobre la base de un acuerdo tomado conjuntamente entre el CCITT y la ISO. La correspondiente Norma Internacional es ISO 10021-5. El anexo G indica las diferencias entre los dos documentos.
1 Campo de aplicación
Esta Recomendación define el servicio abstracto de almacenamiento de mensajes. Este servicio abstracto se presta mediante el protocolo de acceso a la memoria de mensajes especificado en la Recomendación X.419 en combinación con el servicio abstracto STRM definido en la Recomendación X.411, junto con los servicios del elemento de servicio de operaciones a distancia (ESOD) definidos en la Recomendación X.219. La notación de sintaxis abstracta para los protocolos de la capa de aplicación utilizados en esta Recomendación se define en la Recomendación X.208.
Otras Recomendaciones definen otros aspectos del STM. La Recomendación X.400 define los servicios destinados a los usuarios, proporcionados por el STM. La Recomendación X.402 presenta una visión arquitectural del STM. La Recomendación X.407 da una descripción de los convenios de definición de servicio abstracto utilizados en STM. La Recomendación X.420 define el servicio abstracto para la mensajería interpersonal y define el formato de los mensajes interpersonales.
La sección 2 de esta Recomendación contiene la definición del servicio abstracto de almacenamiento de mensajes. El 6 describe el modelo AN. El 7 especifica la notación de sintaxis abstracta para las operaciones abstractas de vinculación y desvinculación. El 8 especifica la notación de sintaxis abstracta para las operaciones del servicio abstracto. El 9 especifica la notación de sintaxis abstracta para los errores del servicio abstracto.
La sección 3 de esta Recomendación define los tipos de atributos generales y los tipos de acciones automáticas generales relacionados con el AM. El 10 presenta una visión de conjunto. El 11 especifica la notación de sintaxis abstracta para los tipos de atributos generales. El 12 especifica la notación de sintaxis abstracta para los tipos de acciones automáticas generales.
La sección 4 de esta Recomendación describe los procedimientos para el almacenamiento de mensajes y la realización de puertos. El 13 presenta una visión de conjunto. El 14 describe la manera de suministrar el servicio abstracto de almacenamiento de mensajes. El 15 describe la manera de consumir el servicio abstracto de sistema de transferencia de mensajes. El 16 describe la manera de realizar los puertos del AM.
No se establecen requisitos para la conformidad con esta Recomendación.
2
Referencias
Para la lista de referencias, véase la Recomendación X.402.
3
Definiciones
3.1
Definiciones de términos usuales en STM
En la Recomendación X.402 figura una lista de términos usuales en el STM, con sus definiciones.
3.2
Definiciones de términos relativos al almacenamiento de
mensajes
Para los fines de esta Recomendación se aplican las siguientes definiciones:
3.2.1@
asociación abstracta
@
:
\Vinculación abstracta entre dos participantes en una comunicación, en esta
Recomendación la vinculación entre un AU y un AM para la prestación del
servicio abstracto AM, o entre un AM y un ATM para la prestación del servicio
abstracto STRM.\
3.2.2@
parámetros-vinculación-abstracta
@
:
\Parámetros definidos en este documento y que están contenidos en la operación
abstracta de vinculación.\
3.2.3@
parámetros-desvinculación-abstracta
@
:
\Parámetros definidos en este documento y que están contenidos en la operación abstracta de desvinculación.\
3.2.4@
puerto de administración
@
:
\Puerto que ofrece el conjunto de servicios abstractos (para STRM) de
administración dentro del servicio AM abstracto.\
3.2.5@
operación abstracta de alerta
@
:
\Operación abstracta que permite al AM señalar, sobre la base de criterios de
selección, el AU, que hay mensajes o informes en espera en el AM. Sólo puede
tener lugar sobre una asociación abstracta existente.\
3.2.6@
atributo
@
:
\Información de un
tipo particular que aparece en una inscripción en una base de información.\
3.2.7@
tipo de atributo
@
:
\Componente
de un atributo que indica la clase de información dada por éste.\
3.2.8@
valor de atributo
@
:
\Caso
particular de la clase de información indicada por un tipo de atributo.\
3.2.9@
aserción-valor-de atributo
@
:
\Proposición relativa a los valores de atributos en una inscripción que puede
ser verdadera, falsa o indefinida.\
3.2.10@
acción automática
@
:
\Acciones
que pueden ser realizadas automáticamente por el AM y que se basan en una
información previamente registrada, aportada por el propietario del AM a través
del AU.\
3.2.11@
tipo de acción automática
@
:
\Se utiliza un tipo de acción automática para indicar el tipo de acción
automática, por ejemplo Alerta.\
3.2.12@
alerta automática
@
:
\Acción
automática dentro del AM que da lugar a una operación abstracta de alerta o a
otra acción por el AM.\
3.2.13@
retransmisión automática
@
:
\Acción automática dentro del AM que provoca la retransmisión automática de un
mensaje a otro destinatario (o a otros destinatarios) por el AM.\
3.2.14@
inscripción-vástago
@
:
\Inscripción que no es la inscripción principal en una base de información. La
inscripción progenitora de una inscripción vástago puede ser la inscripción
principal, u otra inscripción vástago, lo que dependerá del número de niveles
de las inscripciones en cada caso.\
3.2.15@
número secuencial de vástago
@
:
\Número secuencial en una inscripción progenitora que apunta a una inscripción
vástago. Una inscripcón progenitora puede tener más de un valor del número
secuencial de vástago, lo que depende del número de inscripciones vástago.\
3.2.16@
componente condicional (C)
@
:
\Elemento NSA.1 que estará presente en un caso de su clase como prescribe esta
Recomendación. Véase
grado
.\
3.2.17@
longitud del contenido
@
:
\Atributo que da la longitud del contenido de un mensaje entregado (o contenido
devuelto).\
3.2.18@
contenido devuelto
@
:
\Atributo
que señala que un informe entregado (o un mensaje entregado) contenía un
contenido devuelto.\
3.2.19@
TIC convertidos
@
:
\Atributo
que identifica los tipos de información codificada del contenido del mensaje
después de la conversión.\
3.2.20@
hora de creación
@
:
\Atributo
que da la hora de creación (por la MM) de un asiento.\
3.2.21@
operación abstracta de
supresión
@
:
\Operación abstracta utilizada para
suprimir inscripciones una o más inscripciones en una base de información.\
3.2.22@
TIC entregados
@
:
\Atributo con
múltiples valores que da información sobre los TIC en un mensaje entregado.\
3.2.23@
inscripción de mensaje
entregado
@
:
\Inscripción en la base de información de
mensajes almacenados que se obtiene a partir de un mensaje entregado.\
3.2.24@
inscripción por informe
entregado
@
:
\Inscripción en la base de información de
mensajes almacenados que se obtiene a partir de un mensaje entregado.\
3.2.25@
inscripción
@
:
\Conjunto de
informaciones en una base de información. Véase inscripción principal,
inscripción progenitora e inscripción vástago para una ulterior clasificación
de las inscripciones.\
3.2.26@
información-asiento
@
:
\Parámetro, utilizado en operaciones abstractas, que transporta información
seleccionada desde una inscripción.\
3.2.27@
selección-información-inscripción
@
:
\Parámetro, utilizado en operaciones abstractas, que indica la información de un asiento que se está solicitando.\
3.2.28@
estado-inscripción
@
:
\Atributo
que da información sobre el estado de procesamiento de esa inscripción. Los
valores posibles son: nuevo, listado o procesado.\
3.2.29@
tipo-inscripción
@
:
\Atributo
que señala si una inscripción está asociada con un mensaje entregado o con un
informe entregado.\
3.2.30@
operación-abstracta de
captura
@
:
\Operación abstracta que permite recuperar
una inscripción de la base de información de mensajes almacenados.\
3.2.31@
restricciones a captura
@
:
\Restricciones impuestas por el AU a la clase de mensaje que él está preparado
para recibir como resultado de la operación. Las restricciones posibles son la
longitud del mensaje, los tipos de contenido y los TIC.\
3.2.32@
filtro
@
:
\Parámetro utilizado
en operaciones abstractas para probar una determinada inscripción en una base
de información y que es satisfecho o no satisfecho por esa inscripción.\
3.2.33@
elemento del filtro
@
:
\Aserción sobre la presencia de uno o más valores de un atributo de un
determinado tipo en una inscripción sometida a prueba. Cada aserción es
verdadera o falsa.\
3.2.34@
petición de retransmisión
@
:
\Parámetro que puede estar presente en una operación abstracta de depósito de
mensajes, invocada por el AU, para solicitar la retransmisión de un mensaje
desde el AM.\
3.2.35@
atributo general
@
:
\Conjunto
de atributos del AM que son válidos para todos los tipos de mensajes e
informes, independientemente del contenido. Sólo estos atributos del AM están
explícitamente definidos en esta Recomendacón.\
3.2.36@
acción automática general
@
:
\Acciones automáticas que son válidas para todos los tipos de mensajes e
informes, independientemente del contenido. Sólo estas acciones automáticas
están explícitamente definidas en esta Recomendación.\
3.2.37@
Grado
@
:
\Definido en la
Recomendación X.402.\
3.2.38@
puerto de depósito indirecto
@
:
\Puerto que ofrece el servicio abstracto de depósito indirecto dentro del
servicio abstracto AM. El servicio abstracto de depósito indirecto ofrece los
mismos servicios que el servicio abstracto de depósito de mensajes (del
servicio abstracto STRM) con la funcionalidad adicional de retransmitir
mensajes residentes en el AM.\
3.2.39@
base de información
@
:
\Objetos
dentro del AM que almacenan información relativa al servicio abstracto AM, por
ejemplo la base de información de mensajes almacenados, que almacena los
mensajes e informes que han sido entregados al AM.\
3.2.40@
tipo de base de información
@
:
\Tipo de la base de la información, por ejemplo mensajes almacenados.\
3.2.41@
límite
@
:
\Componente en el
parámetro selector que define el número máximo de inscripciones seleccionadas
que han de devolverse como resultado de una operación abstracta.\
3.2.42@
operación abstracta de
listar
@
:
\Operación abstracta que permite devolver, con
relación a ciertas inscripciones, una selección de esas inscripciones, así como
la información de atributo solicitada.\
3.2.43@
listado
@
:
\Valor del estado de
la inscripción.\
3.2.44@
Macro
@
:
\Véase la
Recomendación X.208.\
3.2.45@
inscripción principal
@
:
\Para
cada operación abstracta correcta que crea inscripción en una base de
información hay siempre una inscripción principal. Una información ulterior, o
más detallada, obtenida como resultado de la misma operación abstracta, puede
almacenarse en inscripciones vástagos.\
3.2.46@
componente obligatorio (O)
@
:
\Elemento NSA.1 que debe estar siempre presente en un caso de su clase. Véase
grado
.\
3.2.47@
concordancia
@
:
\Proceso de
comparar el valor suministrado en una aserción de valor de atributo con el
valor del tipo de atributo indicado, almacenado en el AM, o de decidir si el
tipo de atributo indicado está o no presente.\
3.2.48@
elemento de servicio de extracción de mensaje
(ESRM)
@
:
\Elemento del servicio de aplicación por medio
del cual un AU efectúa la extracción de mensajes de un AM, o cualquiera de las
diversas tareas conexas.\
3.2.49@
MM
@
:
\Memoria de mensajes
utilizado también como forma abreviada para
`proveedor del servicio
abstracto AM'
.\
3.2.50@
servicio abstracto AM
@
:
\Conjunto de capacidades que ofrece el AM a sus usuarios por medio de sus
puertos.\
3.2.51@
usuario del servicio abstracto
AM
@
:
\Consumidor del servicio abstracto AM. Este es el
AU.\
3.2.52@
proveedor del servicio abstracto
AM
@
:
\AM que proporciona el servicio abstracto AM.\
3.2.53@
usuario AM
@
:
\Forma abreviada
para
`usuario del servicio abstracto AM'
.\
3.2.54@
operación abstracta de depósito de
mensajes
@
:
\Operación abstracta que permite al AU
depositar un mensaje en el STRM a través del AM y/o retransmitir un mensaje del
AM al STRM.\
3.2.55@
atributo de múltiples
valores
@
:
\Atributo que puede tener asociados varios
valores.\
3.2.56@
nuevo
@
:
\Valor del estado de
la inscripción.\
3.2.57@
componente facultativo (F)
@
:
\Elemento NSA.1 que debe estar presente en un caso de su clase a discreción del
objeto (por ejemplo, el usuario) que suministra ese caso. Véase
grado
.\
3.2.58@
TIC originales
@
:
\Atributo que
identifica los tipos de información codificada originales del contenido del
mensaje.\
3.2.59@
contraorden
@
:
\Componente del
parámetro selector que indica que las restricciones previamente registradas
para esta operación abstracta no deben aplicarse a este caso de operación
abstracta.\
3.2.60@
inscripción progenitora
@
:
\Una
inscripción progenitora tiene una o más inscripciones vástagos, que fueron
creadas como resultado de la misma operación abstracta. Si una inscripción
progenitora no es una inscripción vástago de ninguna otra inscripción
progenitora, es una inscripción principal.\
3.2.61@
número secuencial de
progenitor
@
:
\Un número secuencial es una inscripción
vástago que apunta a su inscripción progenitora. En una inscripción vástago
sólo puede haber un número secuencial de progenitor.\
3.2.62@
petición de atributo parcial
@
:
\Componente de la selección de información de asiento que permite que sean
devueltos solamente los valores seleccionados de un atributo de múltiples
valores.\
3.2.63@
posición
@
:
\Las posiciones son
parámetros utilizados para especificar una cota de una gama.\
3.2.64@
procesado
@
:
\Valor del estado
de la inscripción.\
3.2.65@
gama
@
:
\Parámetro utilizado en
operaciones abstractas, para seleccionar una secuencia contigua de
inscripciones en una base de información.\
3.2.66@
operación abstracta
registro-AM
@
:
\Operación abstracta que permite al AU
registrar en el AM cierta información relativa al interfuncionamiento AU-AM.\
3.2.67@
registro
@
:
\Información que es
registrada en el AM y almacenada (hasta que es cambiada por una operación
abstracta de registro-AM entre asociaciones abstractas. (Véase registro-AM).\
3.2.68@
identificador de registro
@
:
\Identificador de un conjunto particular de parámetros para un tipo de acción
automática.\
3.2.69@
puerto de recuperación
@
:
\Puerto que ofrece el conjunto de servicios abstractos de extracción dentro del
servicio abstracto AM.\
3.2.70@
inscripción de contenido
devuelto
@
:
\Tipo de inscripción, en la base de
información de mensajes almacenados, que contiene el contenido devuelto de un
mensaje depositado anteriormente.\
3.2.71@
selector
@
:
\Parámetro
utilizado en operaciones abstractas, para seleccionar entradas a partir de una
base de información.\
3.2.72@
número secuencial
@
:
\Atributo
que identifica de manera única una inscripción. Los números secuenciales son
asignados en orden ascendente.\
3.2.73@
atributo univaluado
@
:
\Atributo que sólo puede tener asociado un valor.\
3.2.74@
intervalo
@
:
\Componente en el
resultado de la operación abstracta resumir que contiene los números
secuenciales más alto y más bajo de las inscripciones que concuerdan con los
criterios de selección.\
3.2.75@
mensajes almacenados
@
:
\La
base de información más importante en esta Recomendación, utilizada para
almacenar inscripciones que contienen mensajes e informes entregados por el
STRM al AM.\
3.2.76@
abono
@
:
\Acuerdo a largo plazo
entre el suministrador o administrador del AM y los clientes del AM
(propietarios del AM) sobre la disponibilidad y uso de prestaciones AM
opcionales tales como servicios y atributos opcionales. Esta Recomendación
presupone que se ha proporcionado tal mecanismo, pero no prescribe ni ofrece un
método normalizado sobre la forma de proporcionarlo.\
3.2.77@
subcadena
@
:
\Elemento de
filtro utilizado para especificar una cadena de caracteres que aparece (en el
mismo orden dado) en un valor de un atributo.\
3.2.78@
operación abstracta de
resumir
@
:
\Operación abstracta que permite obtener una
rápida visión de conjunto de la clase y el número de las inscripciones que
están almacenadas en ese momento en una base de información.\
3.2.79@
sinopsis
@
:
\Atributo
específico al contenido que puede utilizarse para describir la forma en que las
inscripciones vástagos, que contienen partes del contenido, están relacionadas
entre sí y con la inscripción principal. Este atributo tiene que estar
especificado en la Recomendación que describe el tipo de contenido; por
ejemplo, véase sinopsis de MIP, definida en la Recomendación X.420.\
4
Abreviaturas
En la Recomendación X.402 figura una lista de abreviaturas.
5
Convenios
Esta Recomendación utiliza los convenios de descripción enumerados en los cuatro puntos siguientes.
5.1
Convenios de descripción de los servicios
abstractos
Esta Recomendación utiliza los siguientes convenios de descripción, basados en la NSA.1, para los fines indicados:
1)La propia NSA.1, para especificar la sintaxis abstracta de bases de información y sus componentes, y los tipos de datos comunes.
2)La macro NSA.1 PORT y los convenios de definición de servicio abstracto asociados, de X.407, para especificar el puerto de extracción.
3)Las macros NSA.1, ABSTRACT-BIND, ABSTRACT-UNBIND, ABSTRACT-OPERATION, y ABSTRACT-ERROR y los convenios de definición de servicio abstracto asociados, de X.407, para especificar el servicio abstracto AM.
Cuando esta Recomendación describe una clase de estructura de datos que
tiene componentes, cada componente se clasifica según uno de los siguientes
grados
:
1)
Obligatorio
(O) - Un componente obligatorio tiene que
estar siempre presente en cada caso de la clase.
2)
Facultativo
(F) - Un componente facultativo estará
presente en un caso de la clase a discreción del objeto (por ejemplo, el
usuario) que suministra ese caso.
3)
Condicional
(C) - Un componente condicional estará
presente en un caso de la clase como lo prescriba esta Recomendación.
5.2
Convenios sobre los tipos de atributos utilizados en
el cuadro 1/X.413 (
11
)
Esta Recomendación utiliza los convenios indicados a continuación para la definición de los tipos de atributo del servicio abstracto AM.
En la columna encabezada por
Uno/múltiples valores
pueden aparecer los siguientes valores:
Sun solo valor
Mmúltiples valores
En la columna encabezada por
Nivel de soporte por el AM y
la AU de acceso
pueden aparecer los siguientes
valores:
Oobligatorio
Ffacultativo
En las columnas que llevan por encabezamiento
Presencia en
la inscripción de mensaje entregado
,
Presencia en la inscripción de informe
entregado
, y
Presencia de mensaje
devuelto
, la presencia de cada tipo de atributo se describe por uno de los
siguientes valores:
P
siempre presente
^ en la inscripción porque:
-es obligatorio para generación por el AM; o
-es un parámetro obligatorio con valor por defecto en la operación abstracta correspondiente.
C
condicionalmente presente
^ en la inscripción. Estaría
presente porque:
-el AM lo admite y el usuario está abonado al mismo; y
-estaba presente en un parámetro facultativo en la operación abstracta correspondiente.
-
siempre ausente
,^ en cualquier otro caso.
En las columnas encabezadas por
Disponible para listado
alerta
y
Disponible para resumir
pueden aparecer los
siguientes valores:
Nno
Ysí
5.3
Convenios de descripción para tipos de atributos
utilizados en el cuadro 2/X.413 (
11
)
Esta Recomendación utiliza los convenios enumerados más adelante en su definición de los tipos de atributos para el servicio abstracto AM. El 11 incluye el cuadro 2/X.413 que enumera los tipos de atributo.
En la columna encabezada por
Uno/múltiples valores
pueden aparecer los siguientes valores:
Sun solo valor
Mmúltiples valores
En la columna encabezada por
Generado en la fuente por
pueden aparecer los siguientes valores:
EMOperación abstracta de entrega de mensaje
AMAlmacenamiento de mensajes
EIOperación abstracta de entrega de informe.
5.4
Convenios relativos al tipo de caracteres utilizados
para texto en general
En toda la exposición de esta Recomendación los términos se escriben en
negrita
cuando están definidos, y en todas las demás
ocasiones no se destacan. En el texto inglés, los términos que son nombres
propios se escriben comenzando por mayúscula, no escribiéndose así los términos
genéricos. Los términos genéricos que se componen de múltiples palabras van
unidos con guiones.
5.5
Convenios relativos al tipo de caracteres utilizados
para las definiciones NSA.1
En toda la exposición de esta Recomendación, las definiciones se escriben
en un tipo diferente (
negrita
) de caracteres que el resto
del documento, a fin de resaltar la diferencia entre el texto normal y las
definiciones NSA.1. El tipo de caracteres utilizado para las definiciones NSA.1
es también de menor tamaño, que el utilizado para el texto ordinario. Cuando en
textos de acompañamiento se describen elementos de protocolo y valores de
elementos de NSA.1, sus nombres se escriben en
negrita
.
5.6
Reglas para las definiciones NSA.1
Las definiciones NSA.1 aparecen tanto en el cuerpo del documento para facilitar la exposición como formalmente, en anexos para referencia. Si se encuentran diferencias entre la NSA.1 utilizada en la exposición y la definida formalmente en el anexo correspondiente, se indica un error de especificación.
6 Modelo de almacenamiento de mensajes
El almacenamiento de mensajes (AM) se modela como un objeto atómico, que actúa como un proveedor de servicios a un usuario del servicio abstracto AM (es decir, un agente de usuario), y como un usuario de servicios proporcionados por el sistema de transferencia de mensajes (STRM).
Un AM desempeña un papel intermedio entre el AU y el STRM. Su función
primaria es aceptar la entrega de mensajes a nombre de un solo usuario final
del STM, y mantenerlos para que sean posteriormente extraídos por el agente de
usuario del usuario final. El AM proporciona también servicios de depósito de
mensajes y de administración de mensajes al AU, en efecto,
`atravesando'
el STRM. Esto permite al AM proporcionar una funcionalidad adicional en
comparación con el depósito directo en el ATM, como la retransmisión de
mensajes residentes en el AM.
Al igual que el AU, el AM actúa en representación de un solo usuario final del STM, es decir, no proporciona un servicio AM común a, o compartido entre, múltiples usuarios.
El AM se describe utilizando un modelo abstracto para definir los servicios proporcionados por el AM; el servicio abstracto de almacenamiento de mensajes. La figura 1/X.413 muestra el servicio abstracto AM en relación con su usuario y el servicio abstracto de sistema de transferencia de mensajes. En esta figura, las casillas abiertas representan el consumo del servicio abstracto y las casillas cerradas representan el suministro del servicio abstracto.
Figura 1/X.413, p.
Para una introducción y descripción del concepto del servicio abstracto y sus
convenios de definición, véase la Recomendación X.407.
En la mensajería segura, el AM se trata como un objeto independiente con identidad única, y tiene una clave (o un conjunto de claves) independiente con el AU.
6.1
Objeto almacenamiento de mensajes
El AM se modela como un objeto atómico. Suministra los servicios abstractos
de puerto de extracción AM al usuario del servicio abstracto AM. Actuando como
un proveedor del servicio abstracto STRM
`subrogado'
, el AM suministra
también los servicios abstractos de depósito y administración del STRM al
usuario del servicio abstracto AM (usuario AM), y actuando como un
`subrogado'
del AU, consume los servicios abstractos de puerto de
entrega, puerto de depósito y puerto de administración del STRM en su papel de
usuario del servicio abstracto STRM.
La definición formal del objeto almacenamiento de mensaje es la siguiente:
mS OBJECT PORTS^{^retrieval[S], indirectSubmission[S], administration[S], delivery[C], submission[C], administration[C]^} ::= id-ot-ms
El usuario AM se modela también como un objeto. Consume los servicios abstractos de puerto de extracción y puerto de depósito indirecto del AM y los servicios abstractos de puerto de administración proporcionados transparentemente por el AM.
msUser OBJECT PORTS^{^retrieval[C], indirectSubmission[C], administration[C]^} ::= id-ot-ms-user
6.2
Puertos de almacenamiento de
mensajes
Un AM proporciona puertos de extracción, depósito indirecto y administración al usuario del servicio abstracto AM. El conjunto de capacidades proporcionadas por estos puertos suministra el servicio abstracto AM. Las capacidades de extracción son exclusivas del AM. Estas capacidades incluyen la obtención de información sobre la captura (total o parcial), y la supresión de mensajes residentes en el AM. Se proporcionan capacidades adicionales para registrar ciertas acciones automáticas proporcionadas por el AM (esto es, retransmisión automática y alerta).
Nota
- La ISO proyecta de definir servicios
adicionales de gestión de mensajes proporcionados por el AM en nombre del AU
para el registro cronológico de mensajes entrantes y salientes y para
correlacionar automáticamente las notificaciones entrantes con la información
de registro cronológico sobre los mensajes salientes. Estos servicios están
fuera del ámbito de esta Recomendación.
A fin de proporcionar los servicios descritos en el 6.1 al usuario AM, el AM interactúa, a nombre del usuario AM, con el servicio abstracto STRM, y actúa como un consumidor de los puertos de entrega, depósito y administración del STRM. Los servicios abstractos proporcionados por los puertos STRM se definen en el 8 de la Recomendación X.411.
Por medio de la operación abstracta de vinculación, el AM autentica a un usuario AM antes de proporcionarle cualquiera de las mencionadas capacidades de extracción. Análogamente, los servicios abstractos STRM tienen que autenticar al usuario del servicio abstracto STRM antes de extender sus servicios a dicho usuario del servicio abstracto STRM.
Con excepción del servicio de alerta proporcionado por el puerto de extracción y el servicio de control de depósito proporcionado por el puerto de depósito indirecto, todos los servicios proporcionados por el servicio abstracto AM son invocados por el usuario AM y efectuados por el AM.
Pueden asignarse etiquetas de seguridad al AM de acuerdo con la política de seguridad que se esté aplicando. La política de seguridad puede también definir cómo han de utilizarse las etiquetas de seguridad para poner en práctica dicha política de seguridad. Si se asignan etiquetas de seguridad al AM, el tratamiento de los mensajes almacenados y los informes que llevan esas etiquetas de seguridad pueden verse afectados por la política de seguridad en vigor. Si no se asignan etiquetas de seguridad al AM, el tratamiento de los mensajes almacenados y de los informes es discrecional.
Si se establecen contextos de seguridad entre el AU y el AM, y entre el AM y el ATM, la etiqueta de seguridad que se asigna a un mensaje o a una sonda está confinada al contexto de seguridad concordante con la política de seguridad en vigor. Si no se establecen contextos de seguridad, la asignación de una etiqueta de seguridad a un mensaje o a una sonda queda a la discreción del originador.
6.2.1
Puerto de extracción
El
puerto de extracción
se define como sigue:
retrieval PORT CONSUMER INVOKES^{ Summarize, List, Fetch, Delete, Register-MS^} SUPPLIER INVOKES^{ Alert^} ::= id-pt-retrieval
Los detalles de los servicios abstractos de
puerto de
extracción
se describen en los
7
a 9.
6.2.2
Puerto de depósito indirecto
El
puerto de depósito indirecto
se define como sigue:
indirectSubmission PORT ::= submission
El
puerto de depósito indirecto
utiliza los servicios
abstractos de puerto de depósito definidos en el
8.2
de la
Recomendación X.411.
6.2.3
Puerto de administración
El
puerto de administración
se define en el
8.4
de la Recomendación X.411.
No tendrá interacción con el servicio abstracto de cambio de credenciales. Si el usuario AM necesita que sus credenciales sean actualizadas, se utiliza la operación abstracta registro en el AM. Véase el 8.6 .
6.3
Modelo de información
Este punto describe el modelo de información utilizado por el AM. Este es
un modelo de
bases de información
, constituido por
inscripciones
, que consisten en
atributos
.
6.3.1
Bases de información
El AM almacena y mantiene
bases de información
. Una
base de información
en el AM es una
`base de datos'
que contiene todas las
inscripciones
que representan objetos
constituyentes de una o más categorías particulares.
Esta Recomendación define y describe la
base de información
de mensajes almacenados
. Esta mantiene información derivada de entregas de
mensaje y entregas de informe al AM a través del puerto de entrega STRM, y se
describe en el
6.4
.
Nota
- Un futuro addéndum a la parte correspondiente
de la Norma ISO definirá bases de información adicionales para el registro,
denominadas registro de entrada y registro de salida, que están fuera del
alcance de la presente Recomendación del CCITT.
InformationBase ::= INTEGER^{ stored-messages (0), inlog (1), outlog (2)^} (0^.^.^ub-information-bases)
6.3.2
Inscripciones
Cada
base de información
está organizada como una
secuencia de
inscripciones
. Una
inscripción
representa un objeto y sólo uno (por ejemplo un
mensaje entregado) dentro de la
base de información
.
Cada inscripción se identifica por medio de su
número
secuencial
, que es único dentro de una
base de
información
, y es generado por el AM cuando se crean nuevas inscripciones.
Dentro de una
base de información
, el AM genera los
números secuenciales
en orden ascendente, sin reciclar.
Estos números no se reutilizan nunca.
SequenceNumber ::= INTEGER (0^.^.^ub-messages)
Nota
- Por ejemplo, el AM puede decidir atribuir
números secuenciales
utilizando el tiempo con una
granularidad suficiente para asegurar la unicidad.
6.3.3
Atributos
6.3.3.1
Introducción
Una
inscripción
consiste en un conjunto de
atributos
. Se representa en la figura 2/X.413.
Cada
atributo
proporciona un elemento de información
sobre los datos, o derivado de los datos, a que corresponde la
inscripción
. Uno de estos elementos de información es el
número secuencial
de la
inscripción
propiamente dicho, y otro es la
hora de creación
.
Un
atributo
consiste en un
tipo de
atributo
, que identifica la clase de información dada por un
atributo
, y el correspondiente (o los correspondientes)
valor o (valores) de atributo
, que son casos particulares de
la clase que aparece en la
inscripción
.
Attribute ::= SEQUENCE^{
type AttributeType,
values SEQUENCE (SIZE 1^.^.^ub-attribute-values) OF ANY --
DEFINED BY type
^}
Nota 1
- Así, por ejemplo, en una inscripción de
mensaje entregado (descrita en el
6.4
), el
tipo de
atributo
podría ser la
prioridad
del mensaje, y un
valor de atributo
correspondiente podría ser
urgente
.
Todos los
atributos
de una
inscripción
tienen que ser de
tipos de
atributo
distintos.
Para algunos
tipos de atributo
, un
atributo
puede contener únicamente un solo
valor de atributo
. Se dice entonces que tal
tipo de atributo
es
de un solo valor
(o
univaluado
). Para otros, un
atributo
puede contener uno o más
valores de atributo
, todos del
mismo tipo de datos NSA.1. Se dice de tal
tipo de atributo
que es de
múltiples valores
(o
multivaluado
). Al definirse el
tipo de
atributo
se enuncia si éste es un tipo de atributo
de un
solo valor
o de
múltiples valores
(véase el
6.3.3.2
).
Nota 2
- Así, por ejemplo, el
tipo de
atributo
para el
atributo nombre de originador
(descrito en el
11.2.28
) es
de un solo valor
, en
tanto que para
nombres de otros destinatarios
(descrito en
el
11.2.29
) es de
múltiples valores
.
Figure 2/X.413, p.
6.3.3.2
Tipo de atributo
Algunos
tipos de atributo
se normalizarán
internacionalmente. Otros
tipos de atributo
serán definidos
por autoridades administrativas nacionales y organizaciones privadas. Esto
implica que cierto número de autoridades distintas serán responsables de la
asignación de tipos de una manera que asegure que cada uno será distinto de
todos los demás tipos asignados. Esto se consigue identificando cada
tipo de atributo
con un identificador de objeto cuando se
define el
tipo de atributo
.
Attribute Type ::= OBJECT IDENTIFIER
Ciertos
tipos de atributo
de carácter general para la
base de información de mensajes almacenados se definen en el
11
de
esta Recomendación. Estos
tipos de atributo
se denominan
tipos de atributo generales
y los atributos de estos tipos
son
atributos generales
.
6.3.3.3
Valores de atributo
La definición de un
tipo de atributo
implica también la
especificación del tipo de datos NSA.1 con el cual tienen que ser conformes
tales atributos. El tipo de datos de un
valor de atributo
para el
tipo de atributo
se define mediante el identificador
de objeto para el
tipo de atributo
.
6.3.3.4
Definición de tipo de atributo y la macro
ATTRIBUTE
La definición de
tipo de atributo
comprende:
a)la asignación de un identificador de objeto al
tipo de
atributo
;
b)la indicación del tipo de datos NSA.1 de un
valor de
atributo
;
c)la indicación de un
atributo
de este
tipo
de atributo
puede tener más de un valor;
d)la indicación de si un
atributo
de este
tipo de atributo
puede utilizarse para filtrado basado en la
igualdad, subcadena y/o relaciones de ordenamiento (véase el
8.1.2
).
Nota
- Un filtro puede siempre detectar la presencia o
ausencia, en una inscripción, de un
atributo
de un
tipo de atributo
determinado.
La siguiente macro NSA.1 se utiliza para definir un
tipo de
atributo
. La definición formal de esta macro se da en la Recomendación
X.501 y se reproduce aquí como ayuda al lector.
ATTRIBUTE MACRO ::= BEGIN
TYPE NOTATION::=AttributeSyntax Multivalued^|^empty VALUE NOTATION::=value (VALUE OBJECT IDENTIFIER)
AttributeSyntax::=
"WITH ATTRIBUTE-SYNTAX"
SyntaxChoice
SyntaxChoice::=value (ATTRIBUTE-SYNTAX) Constraint^|^type MatchTypes
Constraint::=
"(Ð ConstraintAlternative "
)Ñ^|^empty
ConstraintAlternative::=StringConstraint^|^IntegerConstraint
StringConstraint::=
"SIZE"
"(Ð SizeConstraint "
)Ñ^|^empty
SizeConstraint::=SingleValue^|^Range
SingleValue::=value (INTEGER)
Range::=value (INTEGER)
".."
value (INTEGER)
IntegerConstraint::=
"(Ð Range "
)Ñ
MatchTypes::=
"MATCHES FOR"
Matches^|^empty
Matches::=Match Matches^|^Match
Match::=
"EQUALITY"
^|^
"SUBSTRINGS"
^|^
"ORDERING"
Multivalued::=
"SINGLE VALUE"
^|^
"MULTIVALUE"
^|^empty
END
La correspondencia entre las partes de la definición, enumeradas
anteriormente y los diversos elementos de la notación introducidos por la macro
ATTRIBUTE
, es la siguiente:
a)
Valor de MACRO
: El
identificador de
objeto
que se utiliza para identificar un atributo.
b)
Sintaxis de atributo
: Señala qué elección de sintaxis
se ha hecho.
c)
Elección de sintaxis
: Señala si el atributo está
definido externa o internamente. La sintaxis de todos los atributos definidos
en esta [Recomendación Parte de la Norma] se define internamente, lo que
significa que se utiliza la elección de
tipo de
concordancia-tipos
.
d)
Multivalorado
: indica si el atributo es de valor simple
o múltiple.
e)
Concordancia-tipos
: Da el tipo de datos del contenido
del atributo, y describe si el atributo puede o no hacerse concordar
(
"
) para
MATCHES FOR
"
igualdad
(
"
), para
EQUALITY
"
subcadenas
(
"
), y por una relación
de
SUB STRINGS
"
ordenamiento
(
"
). Si
la producción es vacía no se definen reglas de concordancia.
ORDERING
"
La concordancia a los efectos de esta Recomendación está limitada a lo siguiente:
i)
EQUALITY
se aplica a cualquier sintaxis de atributo. El
valor presentado debe ajustarse al tipo de datos de la sintaxis de atributo,
ii)
SUBSTRING
se aplica a cualquier sintaxis de atributo
con un tipo de datos de cadena. El valor presentado debe ser una secuencia
(
"
), en la que sus elementos se ajusten
al tipo de datos, y
SEQUENCE OF
"
iii)
ORDERING
es aplicable a cualquier sintaxis de
atributo para la que pueda definirse una regla que permita que un valor
presentado sea descrito como menor o igual que, o mayor que un valor objetivo.
El valor presentado debe ajustarse al tipo de datos de la sintaxis de atributo.
El AM lo utiliza para los tipos de datos INTEGER y UTCTime. Para los UTCTime el
orden es cronológico, no alfabético.
Las elecciones y parámetros restantes de la macro
ATTRIBUTE
no se utilizan en la presente Recomendación.
6.3.4
Inscripciones principales, inscripciones
progenitoras e inscripciones vástagos
Aunque las inscripciones en una base de información generalmente son
independientes unas de otras, el modelo de información AM permite relacionar
tales
inscripciones
unas con otras. Una
inscripción
, una
inscripción vástago
,
puede ser el vástago de otra, que es su
inscripción
progenitora
, en una relación estructurada en forma de árbol. Una
inscripción
que no es una
inscripción
vástago
se denomina
inscripción principal
.
Esta relación se registra por medio de dos
atributos
generales
especiales:
a)
número secuencial de progenitor
: Este atributo de un
solo valor da el número secuencial de una
inscripción
progenitora
de la
inscripción vástago
. No existe en una
inscripción principal
. Su definición se da en el
11.2.30
.
b)
número secuencial de vástago
: Este atributo de
múltiples valores da los números secuenciales de todas las
inscripciones vástagos
de una
inscripción
progenitora
. No existe en una inscripción que no sea una
inscripción progenitora
. Su definición se da en el
11.2.1
.
Las operaciones abstractas de un servicio abstracto AM (véase el
8
) actúan por defecto solamente sobre
inscripciones
principales
. Puede hacerse que algunas actúen sobre todas las
inscripciones: las
inscripciones principales
y las
inscripciones vástagos
. En particular, el argumento de una
operación abstracta de suprimir (véase el
8.5
) sólo puede
seleccionar
inscripciones principales
, en cuyo caso la
inscripción principal
y todos sus vástagos, y los vástagos
de sus vástagos, etc., serán suprimidos.
Nota
- Este concepto permite, por ejemplo, que las
partes de cuerpo de un mensaje interpersonal que contenga un mensaje
retransmitido (para detalles véase el
19.1
de la Recomendación
X.420) se representen por
inscripciones vástagos
individuales. El
atributo general de contenido
de la
inscripción principal
comprenderá el
contenido
completo, por lo que los datos que representan esa
parte del cuerpo
de mensaje, están lógicamente presentes en
más de una
inscripción
.
6.4
Mensajes almacenados
La
base de información de mensajes almacenados
actúa
como un depositario de la información obtenida de las operaciones abstractas
entrega de mensaje (MessageDelivery) y entrega de informe (ReportDelivery) del
puerto de entrega contiene inscripciones para mensajes entregados
(
inscripciones de mensaje entregado
) de un número abierto de
tipos de contenido, y para informes (
inscripciones de informe
entregado
). El AM crea una inscripción en la
base de
información de mensajes almacenados
cuando se entrega un mensaje o informe
al AM. Para más detalles sobre estos asientos y la manera de generarlos, véanse
los
11
y 15.
Para obtener información del contenido de un mensaje, el AM tiene que conocer la sintaxis y la semántica del contenido, señaladas mediante el tipo de contenido. En general, un caso concreto del AM tiene conocimiento de cero o más tipos de contenido. Cuando un AM encuentra un mensaje de cuyo tipo de contenido tiene un conocimiento insuficiente, está incapacitado para generar cualquier atributo específico al tipo de contenido en la inscripción del mensaje.
Un mensaje entregado o una notificación que llega pueden dar lugar a una
inscripción principal y a uno o más niveles de inscripciones vástagos. El caso
definido por esta Recomendación es aquél en que una notificación de no entrega
tiene un contenido devuelto (la
inscripción de informe
entregado
es la inscripción principal y el contenido devuelto es la
inscripción vástago, denominada
inscripción de contenido
devuelto
).
Las reglas para la división del contenido de un mensaje a través de varias
inscripciones son específicas para cada tipo de contenido. Puede utilizarse un
atributo de sinopsis
específico al contenido para indicar
cómo se relaciona la inscripción principal y las inscripciones vástagos
correspondientes. Cuando tal atributo se define, aparece en la Recomendación
que define el tipo de contenido propiamente dicho. El
atributo de
sinopsis
es construido por el AM.
Nota
- Para la mensajería interpersonal (Recomendación
X.420), los mensajes IP anidados dentro de un mensaje IP se representan, cada
uno de ellos, por una inscripción vástago. El tipo de atributo sinopsis-mip es
un ejemplo de un
tipo de atributo de sinopsis
específico del
contenido.
Una propiedad importante de una inscripción en los mensajes almacenados es
su
estado de inscripción
. Este es creado y mantenido por el
AM. Puede tomar los siguientes valores:
a)
Nuevo
- El mensaje no ha sido ni
listado
por un AU ni procesado automáticamente por el AM.
b)
Listado
- Se ha devuelto al AU información sobre el
mensaje en una operación abstracta de listado o en una operación abstracta de
captura, pero el mensaje no ha sido aún completamente
procesado
.
c)
Procesado
- O bien el AU ha
`capturado
completamente'
el mensaje, o el AM ha efectuado alguna acción automática
sobre el mismo. (Obsérvese que algunas acciones automáticas culminan en la
supresión del mensaje). La definición exacta de
`traído completamente'
es específica del contexto y aparece en la correspondiente Recomendación
específica del contenido.
El
estado de la inscripción
de una notificación de
(no)entrega pasa a ser
procesado
cuando se recupera el sobre
de informe entregado.
La definición del
estado de inscripción
es la siguiente:
EntryStatus ::= INTEGER^{ new (0), listed (1), processed (2)^}
6.5
Acciones automáticas
6.5.1
Introducción
Este punto define un marco para las
acciones automáticas
que pueden registrarse en el AM.
Una
acción automática
es una acción que ocurrirá
automáticamente cuando se satisfagan los criterios de registro asociados. El
resultado de una acción que se está invocando resulta visible externamente al
AM. Las
acciones automáticas
se registran en el AM
utilizando la operación abstracta de registro en el AM (véase el
8.6
).
Cada clase de
acción autom atica
se identifica por medio
de un
tipo de acción automática
. Asociado con el registro de
una
acción automática
hay un
parámetro
registro de acción automática
correspondiente, que es el parámetro (o
parámetros) que necesita el AM para efectuar automáticamente la
acción automática
registrada. El registro de una
acción automática
requiere el uso de un
identificador de registro de acción automática
para
identificar ese registro.
AutoActionRegistration ::= SEQUENCE^{ type AutoActionType, registration-identifier [0] INTEGER (1^.^.^ub-per-auto-action)DEFAULT1, registration-parameter [1] ANY DEFINED BY type^}
6.5.2
Tipo de acción automática
Algunos
tipos de acción automática
se normalizarán
imternacionalmente. Otros
tipos de acción automática
serán
definidos por autoridades administrativas nacionales y organizaciones privadas.
Esto significa que diversas autoridades distintas serán responsables de asignar
tipos de una forma que asegure que cada uno es distinto de todos los demás
tipos de acción automática
asignados. Esto se consigue
identificando cada
tipo de acción automática
mediante un
identificador de objeto cuando se define el
tipo de acción
automática
.
AutoActionType ::= OBJECT IDENTIFIER
Ciertos
tipos de acción automática
de carácter general
se definen en el
12
de esta Recomendación. Tales
tipos
de acción automática
se conocen como
tipos de acción
automática generales
y las
acciones automáticas
.
6.5.3
Parámetros de registro de acción
automática
La definición de un
tipo de acción automática
comprende
también la especificación del tipo de datos NSA.1 al cual debe ajustarse el
parámetro registro de acción automática
. El tipo de datos de
un
parámetro registro
se define mediante el identificador de
objeto para el
tipo de acción automática
.
6.5.4
Definición de tipo de acción automática y la
macro AUTO-ACTION
La definición de un
tipo de acción automática
comprende:
a)asignar un identificador de objeto al
tipo de acción
automática
;
b)indicar el tipo de datos NSA.1 del
parámetro registro de
acción automática
.
La siguiente macro NSA.1 puede (pero no tiene necesariamente que)
utilizarse para definir un
tipo de acción automática:
AUTO-ACTION MACRO ::= BEGIN TYPE NOTATION::=Registration VALUE NOTATION::=value (VALUE OBJECT IDENTIFIER)
Registration::=
"REGISTRATION PARAMETER IS"
type
END
La correspondencia entre las partes de la definición, tal como han sido
enumeradas anteriormente, y los diversos elementos de la notación introducida
por la macro
AUTO-ACTION
es la siguiente:
a)
Registro
: proporciona el tipo de datos de los
parámetros de registro asociados con una acción automática.
b)
Valor
: el
identificador de objeto
que se utiliza para identificar la acción automática.
Nota
- En la macro no se proporciona un soporte para
definir la interacción (si la hubiere) entre registros deferentes de las mismas
(o diferentes)
acciones automáticas
.
6.6
Retransmisión de un mensaje
El usuario AM utiliza la operación abstracta de depósito de mensaje y sus parámetros definidos en el 8.2 de la Recomendación X.411 para solicitar que un mensaje almacenado en el AM sea retransmitido explícitamente a otros usuarios.
El
parámetro petición de retransmisión
se define
utilizando la macro
EXTENSION
definida en el
9
de
la Recomendación X.411 de la forma siguiente:
forwarding-request EXTENSION SequenceNumber CRITICAL FOR SUBMISSION ::= 36
Si el
número secuencial
no corresponde al de una entrada
en la
base de información
de
mensajes
almacenados
, o corresponde a una entrada que es inapropiada para la
retransmisión, se informa de ello utilizando el error abstracto
petición incoherente
del
8.2.2.7
de la
Recomendación X.411.
7 Operaciones abstractas de vinculación y
de desvinculación
7.1
Operaciones abstractas de
vinculación
La
operación abstracta de vinculación AM
vincula los
puertos de depósito indirecto, extracción y administración del usuario AM
(consumidor) al AM (suministrador). El iniciador (de vinculación AM) es el
usuario AM, en tanto que el respondedor es el propio AM. Vinculación AM se
define como sigue:
MSBind ::= ABSTRACT-BIND TO {^IndirectSubmission[5], retrieval[5], administration[5]^} BIND ARGUMENTMSBindArgument RESULTMSBindResult BIND-ERRORMSBindError
Puede existir una sola asociación abstracta en un instante dado entre el AM y el usuario AM.
7.1.1
Argumento de vinculación-abstracta
Los parámetros
argumento de vinculación-abstracta
se
utilizan para identificar, autenticar y establecer el contexto de seguridad
para un usuario del servicio abstracto AM. Contienen también un conjunto de
restricciones a las inscripciones que han de devolverse como resultado de una
operación abstracta de captura y, finalmente, una solicitud de ser informado
sobre los tipos acción automática, tipos atributo y tipos contenido admitidos
por el AM.
La definición de estos parámetros es la siguiente:
MSBindArgument ::= SET^{
initiator-name ORAddressAndOrDirectoryName,
initiator-credentials [2] InitiatorCredentials,
security-context [3] IMPLICIT SecurityContext OPTIONAL,
fetch-restrictions [4] Restrictions OPTIONAL --
default is none
--,
ms-configuration-request [5] BOOLEAN DEFAULT FALSE,^}
1)
Nombre del iniciador
(C): Este argumento contiene el
nombre del iniciador de la asociación y es suministrado por el iniciador. Este
argumento se define con más detalles en el
8.1.1.1.1.1
de la
Recomendación X.411.
2)
Credenciales del iniciador
(O): Este parámetro contiene
las
credenciales
del iniciador de la asociación. Será
generado por el iniciador de la asociación abstracta.
Las
credenciales del iniciador
pueden ser utilizadas por
el respondedor para autenticar la identidad del iniciador (véase la
Recomendación X.509).
Si sólo se utiliza la
autenticación simple
, las
credenciales del iniciador
comprenden una contraseña simple.
Si se utilizan la
autenticación fuerte
, las
credenciales del iniciador
comprenden un
testigo vinculación iniciador
, y opcionalmente, un
certificado de iniciador
. El
testigo
vinculación iniciador
y el
certificado de iniciador
se
definen con más detalle en el
8.1.1.1.1.2
de la Recomendación X.411.
Las
credenciales de iniciador
del usuario AM pueden diferir
de las
credenciales de iniciador
utilizadas en vinculación
AM, como se define en el
8.1.1.1.1.2
de la Recomendación X.411.
3)
Contexto de seguridad
(F): Este parámetro identifica el
contexto de seguridad
sobre el cual se propone operar el
iniciador de la asociación abstracta. Es generado por el iniciador de la
asociación abstracta. El
contexto de seguridad
se define con
más detalles en el
8.1.1.1.1.3
de la Recomendación X.411.
El
contexto de seguridad
comprende una o más
etiquetas de seguridad
que definen la sensibilidad de
interacciones que pueden ocurrir entre el usuario del servicio abstracto AM y
el servicio abstracto AM mientras dura la asociación abstracta, en consonancia
con la
política de seguridad
en vigor. El
contexto de seguridad
será uno que esté permitido por las
etiquetas de seguridad de usuario
registradas, del usuario
del servicio abstracto AM, y por las
etiquetas de seguridad
asociadas con el AM.
En ausencia de este parámetro, no se establecen
contextos de
seguridad
entre el usuario del servicio abstracto AM y el servicio
abstracto AM, y la sensibilidad de interacciones que pueden ocurrir entre el
usuario del servicio abstracto AM y el servicio abstracto AM están a la
discreción del invocador del servicio abstracto.
4)
Restricciones de captura
(F): Contiene las
restricciones sobre las inscripciones que han de devolverse como resultado de
una operación abstracta de captura. Las
restricciones de
captura
siguen establecidas hasta que se ha emitido una operación
abstracta de desvinculación.
En ausencia de este argumento, su valor por defecto es que no es necesario
efectuar
restricciones de captura
.
Este argumento consiste en los siguientes componentes:
Restrictions ::= SET^{
allowed-content-types [0] SET SIZE (1^.^.^ub-content-types) OF OBJECT
IDENTIFIER
allowed-content-types [0] OPTIONAL
--
default is no restriction
--,
allowed-EITs [1] MS-EITs OPTIONAL --
el valor por
defecto es ausencia de
allowed-EITs [1]
restricciones
--,
maximum-content-length [2] ContentLength OPTIONAL --
el
valor por defecto es ausencia de
maximum-content-length [2]
restricciones
--^}
a)
Tipos de contenido autorizados
(C): Los tipos de
contenido que el usuario del servicio abstracto AM está dispuesto a aceptar
como resultado de una operación abstracta de captura. Todo mensaje cuyo tipo de
contenido sea diferente a los especificados no será retornado pero dará por
resultado un error, a menos que la operación abstracta de captura haya
contraordenado explícitamente la restricción.
En ausencia de este componente, el valor por defecto es que no es necesario efectuar restricciones a captura sobre tipos de contenido.
b)
TIC autorizados
(C): Los tipos de información
codificada que el usuario del servicio abstracto AM está dispuesto a aceptar
como resultado de una operación abstracta de captura. Si un mensaje contiene
tipos de información codificada diferentes de los especificados se efectuará un
filtrado a fin de que las partes TIC desautorizadas no se devuelvan junto con
el texto del mensaje. Si el mensaje completo consiste en TIC desautorizados, se
notificará un error. No se efectuará filtrado si la operación abstracta de
captura ha contraordenado explícitamente la restricción.
MS-EITs ::= SET SIZE (1^.^.^ub-encoded-information-types) OF MS-EIT
MS-EIT ::= OBJECT IDENTIFIER
En ausencia de este componente, el valor por defecto es que no es necesario
ejecutar
restricciones a captura
sobre tipos de información
codificada.
c)
Máxima longitud de contenido
(C): Longitud máxima del
contenido que el usuario del servicio abstracto AM está dispuesto a aceptar
como resultado de una operación abstracta de captura. Todo mensaje cuya
longitud de contenido
sea superior a la especificada no se
devolverá, sino que dará lugar a un error, a menos que la operación abstracta
de captura haya contraordenado explícitamente la restricción.
En ausencia de este componente, el valor por defecto es que no es necesario
efectuar
restricciones a captura
sobre la
longitud de contenido
.
5)
Petición de configuración AM
(C): Se solicita
petición de configuración AM
para obtener información sobre
cuáles de las acciones automáticas y atributos opcionales son admitidos por el
AM.
En ausencia de este componente, el valor por defecto es falso, que indica que no se está haciendo tal petición.
7.1.2
Resultados vinculación abstracta
Los parámetros
resultado de vinculación abstracta
son
los siguientes:
MSBindResult ::= SET^{ responder-credentials [2] ResponderCredentials, available-auto-actions [3] SET SIZE (1^.^.^ub-auto-actions) OF AutoActionType OPTIONAL, available-attribute-types [4] SET SIZE (1^.^.^ub-attributes-supported) OF Attribute Type available-attribute-types [4] OPTIONAL, alert-indication [5] BOOLEAN DEFAULT FALSE, content-types-supported [6] SET SIZE (1^.^.^ub-content-types) OF OBJECT IDENTIFIER content-types-supported [6] OPTIONAL^}
1)
Credenciales del respondedor
(M): Este parámetro
contiene las credenciales del respondedor de la asociación abstracta. Será
generado por el respondedor de la asociación abstracta.
Las
credenciales del respondedor
pueden ser utilizadas
por el iniciador para autenticar la identidad del respondedor (véase la
Recomendación X.509).
Si sólo se utiliza la
autenticación simple
, las
credenciales del respondedor
comprenden una
contraseña
simple asociada con el respondedor.
Si se utiliza una
autenticación fuerte
, las
credenciales del respondedor
comprenden un
testigo de vinculación respondedor
, y, opcionalmente, un
certificado del respondedor
, generados ambos por el
respondedor de la asociación abstracta. El
testigo de vinculación
respondedor
y el
certificado del respondedor
se definen
con más detalle en el
8.1.1.1.2.2
de la Recomendación X.411.
2)
Acciones automáticas disponibles
(C): Especifica un
conjunto de todas las posibles
acciones automáticas
admitidas por el AM (y no, sencillamente, las solicitadas por el usuario del
servicio abstracto AM). Sólo está presente si se hace una
petición de configuración AM
.
3)
Tipos de atributo disponibles
(C): Especifica el
conjunto de todos los atributos opcionales admitidos por el AM. Sólo está
presente si se hace una
petición de configuración AM
.
4)
Indicación de alerta
(C): Si es verdadera ha ocurrido
una condición de
alerta
con posterioridad a la última
indicación de alerta
correcta.
5)
Tipos de contenido admitidos
(C): Especifica un
conjunto de identificadores de objetos que definen los
tipos de
contenido
conocidos por el AM. Sólo está presente si se hace una
petición de configuración AM
7.1.3
Errores vinculación abstracta
Hay dos posibles errores que son definidos por el
puerto de
extracción
, a saber:
error de autenticación
y
contenido de seguridad inaceptable
.
La definición del error es:
MSBindError ::= ENUMERATED^{ authentication-error (0), unacceptable-security-context (1), unable-to-establish-association (2)^}
1)
Error de autenticación
(C): Este error da a conocer que
una asociación abstracta no puede establecerse porque las
credenciales
del iniciador no son aceptables o están
indebidamente especificadas.
El
error de autenticación
no tiene parámetros.
2)
Contexto de seguridad inaceptable
(C): Este error
informa que el
contexto de seguridad
propuesto por el
iniciador de la asociación abstracta es inaceptable para el respondedor.
El error de
contexto de seguridad inaceptable
no tiene
parámetros.
3)
Incapacidad para establecer asociación
(C): Este error
informa que el respondedor ha rechazado la tentativa del iniciador de
establecer una asociación abstracta.
El error
incapacidad para establecer asociación
no tiene
parámetros.
7.2
Operación desvinculación abstracta
La
operación-desvinculación-abstracta, Devinculación AM
cierra la asociación abstracta. La emisión de
operación-desvinculación-abstracta
da por resultado la
mitigación de cualesquiera
restricciones de captura
que se
especificaron en el argumento
operación-desvinculación-abstracta
. La
operación-desvinculación-abstracta
no tiene asociados
argumento, resultado ni error.
MSUnbind ::= ABSTRACT-UNBIND FROM {^indirectSubmission[S], retrieval[S], administration[S]^}
8
Operaciones
abstractas
Este punto define las siguientes
operaciones abstractas
disponibles en el puerto de extracción:
a)resumir;
b)listado;
c)captura;
d)supresión;
e)registro en el AM;
f)alerta.
El AM es el proveedor del servicio abstracto AM de cada una de estas
operaciones abstractas
. Para la definición formal del puerto
de extracción véase el
6.2
.
La operaciones abstractas pueden ser realizadas asíncronamente, con las siguientes condiciones. Las operaciones abstractas supresión y registro en el AM no se realizarán hasta que se hayan completado todas las operaciones abstractas pendientes. Además, estas operaciones abstractas se realizan en el orden en que son invocadas y hay que completarlas antes de que se realice cualquier otra operación abstracta. Como consecuencia de esto y del hecho de que las operaciones abstractas listado y captura cambian el estado de una inscripción de un mensaje, los resultados de las operaciones abstractas resumir, listar y captura pueden ser no determinísticos.
8.1
Tipos de datos comunes utilizados en las operaciones
abstractas
Este punto define un número de tipos de datos comunes que se utilizan en
algunas de las
operaciones abstractas
definidas en el resto
del
8
. Muchas de las
operaciones abstractas
emplean inscripciones y atributos definidos en el
6.3
.
Los tipos de datos comunes definidos en esta Recomendación son:
a)gama;
b)filtro;
c)selector;
d)selección de información de inscripción;
e)información de inscripción.
8.1.1
Gama
El parámetro
gama
se utiliza para seleccionar una
secuencia contigua de inscripciones a partir de una base de información.
Range ::= CHOICE^{ sequence-number-range [0] NumberRange, creation-time-range [1] TimeRange^}
NumberRange ::= SEQUENCE^{
from[0] SequenceNumber OPTIONAL -
omitido significa
que no tiene cota inferior
--,
to[1] SequenceNumber OPTIONAL -
omitido significa
que no tiene cota superior
--^}
TimeRange ::= SEQUENCE^{
from[0] CreationTime OPTIONAL -
omitido significa
que no tiene cota inferior
--,
to[1] CreationTime OPTIONAL -
omitido significa
que no tiene cota superior
--^}
CreationTime ::= UTCTime
Los componentes de
gama
tienen los siguientes
significados:
1)
Gama de números secuenciales
(C), y
2)
Gama de horas de creación
(C): Estos dos parámetros
identifican la secuencia contigua de inscripciones a seleccionar. La
gama de números secuenciales
se da en términos de
números secuenciales
, y la
gama de horas de
creación
se da en términos de
horas de creación
. La
hora de creación
de una inscripción es la hora (o fecha) en
que el AM generó la inscripción. Los
números secuenciales
de
inscripciones sucesivas están siempre en orden ascendente, pero varias
inscripciones adyacentes pueden tener la misma
hora de
creación
. Los parámetros de
gama de números
y de
gama de horas
tienen los siguientes significados:
a)
Desde
(F): Es el límite inferior de la
gama
.
En ausencia de este componente, el significado por defecto es
no hay límite inferior
, y la selección comienza con el
mensaje más antiguo (
número secuencial
más bajo) en la base
de información.
b)
Hasta
(F): Es el límite superior de la
gama
.
En ausencia de este componente el significado por defecto es
no hay límite superior
, y la selección termina con el último
mensaje (
número secuencial
más alto) en la base de
información.
8.1.2
Filtros
8.1.2.1
Filtro
Un parámetro
filtro
aplica una prueba para una
inscripción dada, la cual satisface o no satisface dicha prueba. Un
filtro
se expresa en términos de aserciones sobre la
presencia o el valor de ciertos atributos de la inscripción y es satisfecho
únicamente si su evaluación es
verdadero
(
true
).
Filter ::= CHOICE^{ item[0] FilterItem, and[1] SET SIZE (1^.^.^ub-nested-filters) OF Filter, or[2] SET SIZE (1^.^.^ub-nested-filters) OF Filter, not[3] Filter^}
Un
filtro
es o bien un
elemento de
filtro
, o una expresión que comprende
filtros
más
sencillos reunidos por medio de operadores lógicos
y
(
and
),
o
(
or
), y
no
(
not
).
Donde el
filtro
es:
a)un
elemento
, es
verdadero
únicamemte
si el correspondiente
elemento de filtro
es
verdadero
;
b)un
y
, es
verdadero
a menos que
cualquiera de los
filtros
del
conjunto
(
SET
) sea
falso
.
Nota
- En consecuencia, si el
conjunto
(
SET
) no contiene
filtros
, el
y
da el valor
verdadero
.
c)un
o
, es
falso
a menos que
cualquiera de los
filtros
del
conjunto
(
SET
) sea
verdadero
;
Nota
- En consecuencia, si el
conjunto
(
SET
) no contiene
filtros
, el
o
da el valor
falso
.
d)un
no
, es
verdadero
si el
filtro
es
falso
.
8.1.2.2
Elemento de filtro
A
elemento de filtro
es una aserción sobre la presencia
o valor(es) de un atributo de un tipo particular en la inscripción sometida a
prueba. Cada una de estas aserciones es
verdadera (true)
o
falsa (false)
.
FilterItem ::= CHOICE^{
equality [0] AttributeValueAssertion,
substrings [1] SEQUENCE^{
type AttributeType,
strings SEQUENCE SIZE (1^.^.^ub-attribute-values) OF CHOICE^{
initital [0] ANY --
DEFINED BY type
--,
any [1] ANY --
DEFINED BY type
--,
final [2] ANY --
DEFINED BY type
--^}^},
greater-or-equal [2] AttributeValueAssertion,
less-or-equal [3] AttributeValueAssertion,
present [4] AttributeType,
approximate-match [5] AttributeValueAssertion^}
Un elemento de filtro incluye un tipo de atributo que identifica el atributo particular en cuestión.
Una aserción sobre el valor de tal atributo sólo se evalúa si el tipo de atributo está definido, y el valor o valores del atributo contemplados son del tipo de datos definidos para valores de atributo de ese atributo.
Las aserciones sobre el valor de un atributo se evalúan determinando la concordancia del atributo para IGUALDAD (EQUALITY), SUBCADENAS (SUBSTRINGS), y ORDENAMIENTO (ORDERING), según se define en el 6.3.3.4 .
Cuando el
elemento de filtro
establece una aserción de:
a)
igualdad
, es
verdadero
si hay un
valor del atributo que es igual establecido en la aserción;
b)
subcadenas
, es
verdadero
únicamente
si hay un valor del atributo en el cual las
subcadenas
especificadas aparecen en el orden dado. Las
subcadenas
no
deben superponerse y pueden (pero no necesariamente tienen que) estar separadas
de los extremos del valor del atributo, y unas con respecto de otras, por cero
o más elementos de la
cadena
.
De estar presente, el primer carácter contenido en
inicial
, concordará con el primer carácter del valor de
atributo; de estar presente, el último carácter contenido en
final
concordará con el último carácter del valor de
atributo. De estar presente,
cualquiera
, concordará con
cualquier subcadena del valor de atributo;
c)
mayor o igual
, es
verdadero
únicamente si el orden relativo sitúa el valor suministrado
después de
cualquier valor del atributo;
d)
menor o igual
, es
verdadero
únicamente si el orden relativo sitúa el valor suministrado
antes que
cualquier valor del atributo;
e)
presente
, es
verdadero
únicamente si
dicho atributo está presente en el asiento.
f)
concordancia aproximada
, es
verdadero
únicamente si hay un valor del atributo que
concuerda con el que se ha hecho una aserción mediante algún algoritmo de
concordancia aproximada definido localmente (por ejemplo, variaciones de
deletreo, concordancia fonética, etc). En esta versión de la Recomendación no
hay directrices específicas para la concordancia aproximada. De no soportarse
la concordancia aproximada, debería tratarse este
elemento de
filtro
como una concordancia para
igualdad
.
Nota
- Si no se indican reglas de concordancia en la
definición de atributo, esto significa que sólo se puede probar la presencia
del atributo en un
elemento de filtro
.
8.1.2.3
Aserción de valor de atributo
Una
aserción de valor de atributo
es una proposición,
que puede ser
verdadera
,
falsa
, o
indefinida
, sobre los valores de una inscripción. Comprende
un tipo de atributo y un valor de atributo:
AttributeValueAssertion ::= SEQUENCE^{ typeAttributeType, valueANY DEFINED BY type^}
y es:
a)
indefinida
, si se da cualquiera de las siguientes
situaciones:
1)el tipo de atributo no está presente en la inscripción;
2)la definición del tipo de atributo no puede hacerse concordar por igualdad o por ordenación;
3)el valor de atributo no es conforme al tipo de datos de los valores de atributo;
b)
verdadera
, si la entrada contiene un atributo de ese
tipo de atributo, uno de cuyos valores de atributo concuerda con ese valor de
atributo;
c)
falsa
, en cualquier otro caso.
8.1.3
Selector
Un parámetro
selector
se utiliza para seleccionar
asientos a partir de una base de información. La selección opera en tres
etapas. En la primera, el conjunto total de inscripciones en la base de
información puede limitarse a un conjunto contiguo particular especificando su
gama. En segundo lugar, pueden seleccionarse las inscripciones dentro de este
conjunto especificando un filtro que deba ser satisfecho por la inscripción
seleccionada. En tercer lugar, se puede imponer un límite al número de
inscripciones así seleccionadas; en este caso, se seleccionan las inscripciones
con los números secuenciales más bajos.
Selector ::= SET^{
child-entries [0] BOOLEAN DEFAULT FALSE,
range [1] Range OPTIONAL --
default is
unbounded
--,
filter [2] Filter OPTIONAL --
default is all
entries within the specified range
--,
limit [3] INTEGER (1^.^.^ub-messages) OPTIONAL,
override [4] OverrideRestrictions OPTIONAL --
default is
that any fetch-restrictions in force
override [4]
do apply
--^}
Los componentes de
selector
tienen los siguientes
significados:
1)
Inscripciones vástagos
(F): Si
falso
, sólo se consideran para la selección las
inscripciones principales. Si
verdadero
, se consideran para
la selección las inscripciones principales y las inscripciones vástagos.
En la ausencia de este componente, el significado por defecto es
sólo se consideran las inscripciones principales
.
2)
Gama
(F): La notación de sintaxis abstracta de
gama
se indica en el
8.1.1
.
En ausencia de este componente, el significado por defecto es
no limitado
.
3)
Filtro
(F): La notación de sintaxis abstracta de
filtro
se da en el
8.1.2
.
En ausencia de este componente, el significado por defecto es
todas las inscripciones dentro de la gama especificada
.
4)
Límite
(F): Permite la especificación de un límite
superior al número de inscripciones que deberán seleccionarse.
En ausencia de este componente, se devolverán todas las inscripciones seleccionadas.
Nota
- La finalidad primaria del límite es impedir que,
en una operación abstracta, como consecuencia de selecciones mal formuladas, se
obtengan resultados enormes. Se puede utilizar también para presentar un número
exacto de conjuntos de información de modo que sean adecuados para un
determinado dispositivo de salida.
5)
Contraorden
(F): Si se requiere una contraorden de
cualquiera de las
restricciones de captura
, tienen que estar
presente los componentes correspondientes de
restricciones de
contraorden
.
OverrideRestrictions ::= BIT STRING^{ overrideContentTypesRestriction (0), overrideEITsRestriction (1), overrideContentLengthRestriction (2)^} (SIZE (1^.^.^ub-information-bases))
Los bits de
restricciones a contraorden
tienen los
significados siguientes:
a)
Restricción a tipos de contenido de contraorden
(O):
Este bit debe ponerse a 1 si la
restricción a tipos de
contenido
debe ser contraordenada.
Si este bit se pone a cero, se aplicarán las
restricciones a
tipos de contenido
especificadas en la operación abstracta de vinculación.
b)
Restricción a contraordenar TIC
(O): Este bit tiene que
ponerse a 1 si deberá contraordenarse
restricción a TIC
.
Si este bit se pone a cero, se aplicarán las
restricciones a
TIC
especificadas en la operación abstracta de vinculación.
c)
Restricción a contraordenar longitud de contenido
(O):
Este bit tiene que ponerse a 1 si la
restricción a longitud de
contenido
ha de ser contraordenada.
Si este bit se pone a cero, se aplicarán las
restricciones a
longitud de contenido
especificadas en la operación abstracta de
vinculación.
En ausencia de
restricciones a contraordenar
, el
significado por defecto es que se aplicarán todas las
restricciones de captura
especificadas en la operación
abstracta de vinculación.
8.1.4
Selección de información de inscripción
Un parámetro de
selección de formación de inscripción
indica qué información de una inscripción se está solicitando.
EntryInformationSelection ::= SET SIZE (0^.^.^ub-per-entry) OF AttributeSelection
Un conjunto vacío indica que se solicita información sobre la propia inscripción, y no sobre los atributos de la inscripción.
AttributeSelection ::= SET^{
typeAttributeType,
from[0] INTEGER (1^.^.^ub-attribute-values) OPTIONAL --
used if
type is multi valued
--,
count[1] INTEGER (1^.^.^ub-attribute-values) OPTIONAL --
used
if type is multi valued
--^}
Los componentes de
selección de información de
inscripción
tienen los siguientes significados:
1)
Tipo
(O): Indica el tipo-de-atributo del atributo.
2)
Desde
(F): Cuando el atributo tiene múltiples valores,
este entero da la posición relativa del primer valor que ha de devolverse. Si
especifica un valor más allá de los presentes en el atributo, no se devuelve
ningún valor. Este componente sólo está presente si el tipo de atributo tiene
múltiples valores. Si se omite, se devuelven los valores a partir del primer
valor.
3)
Cómputo
(F): Cuando un atributo tiene múltiples
valores, este entero da el número de valores a devolver. Si hay presentes en el
atributo menos que cómputo, se devuelven todos los valores. Este atributo sólo
está presente si el tipo de atributo es de múltiples valores. Si se omite, no
hay límite para el número de valores que se devuelven.
8.1.5
Información de inscripción
Un parámetro
información de inscripción
lleva
información seleccionada tomada de una inscripción.
EntryInformation ::= SEQUENCE^{ sequence-number SequenceNumber, attributes SET SIZE (1^.^.^ub-per-entry) OF Attribute OPTIONAL^}
Los componentes de
información de inscripción
tienen los
siguientes significados:
1)
Número secuencial
(O): Número secuencial que identifica
la inscripción. Véase el
6.3.2.2
.
2)
Atributos
(F): Conjunto de atributos seleccionados
tomados de la inscripción. Cuando se solicita expresamente por una petición de
atributo parcial, un atributo seleccionado que está definido como multivaluado
puede contener un subconjunto de todos los valores de atributo, en ese
atributo, almacenados en la inscripción. Este parámetro está ausente si no se
ha solicitado información procedente de los mensajes seleccionados, por
ejemplo, cuando el usuario del servicio abstracto AM sólo desea los números
secuenciales de los mensajes seleccionados.
8.2
Operación abstracta de resumir
La
operación abstracta de resumir
devuelve cómputos
resumen de inscripciones seleccionadas en una base de información. Además de
estos resúmenes, se devuelve también un cómputo de las inscripciones
seleccionadas, y sus números secuenciales más bajos y más alto. Pueden
solicitarse cero o más resúmenes individuales.
La
operación abstracta de resumir
sólo será correcta
cuando la base de información permite el acceso de acuerdo con el contexto de
seguridad y la política de seguridad en vigor.
Los atributos que pueden utilizarse para los resúmenes están restringidos. Para los atributos generales en la base de información de mensajes almacenados, las restricciones se indican en el cuadro 1/X.413.
Summarize ::= ABSTRACT-OPERATION ARGUMENT SummarizeArgument RESULT SummarizeResult ERRORS^{ AttributeError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
Nota
- En el anexo F se presenta un ejemplo de la
operación abstracta.
8.2.1
Argumento de resumir
SummarizeArgument ::= SET^{
information-base-type [0] InformationBase DEFAULT stored-messages,
selector [1] Selector,
summary-requests [2] SEQUENCE SIZE (1^.^.^ub-summaries) OF AttributeType
OPTIONAL
--
ausente si no se solicitan resúmenes
--^}
Los componentes de
argumento de resumir
tienen los
siguientes significados:
1)
Tipo de base de información
(F): Especifica qué
base de información
es direccionada por la operación
abstracta. Véase el
6.3.1
.
En ausencia del componente
tipo de base de información,
el significado por defecto es mensajes almacenados.
2)
Selector
(F): Es un conjunto de criterios de selección
para determinar que inscripciones han de resumirse. Véase el
8.1.3
.
3)
Peticiones de resúmenes
(F): Es la secuencia de tipos
de atributo para la cual se solicitan resúmenes. Este parámetro sólo está
presente si se solicita un resumen.
8.2.2
Resultado de resumir
En caso de éxito de la petición, se retornará el
resultado de
resumir
.
SummarizeResult ::= SET^{
next [0] SequenceNumber OPTIONAL,
count [1] INTEGER (0^.^.^ub-messages)^} --
de las
inscriciones seleccionadas
--,
span [2] Span OPTIONAL --
de las inscripciones
seleccionadas, omitidas si
span [2]
cuenta es cero
--,
summaries [3] Sequence SIZE (1^.^.^ub-summaries) OF Summary OPTIONAL)
Los componentes de
resultado de resumir
tienen los
siguientes significados:
1)
Siguiente
(C): Se devuelve cuando el número de
inscripciones seleccionadas sería mayor si no fuera por el límite especificado
en el selector. El componente contiene el número secuencial para la inscripción
siguiente que habrá sido seleccionada.
2)
Cómputo
(O): Es un entero que da el cómputo de las
inscripciones que concordaron con los criterios de selección.
3)
Intervalo
(C): Contiene los números secuenciales más
bajo y más alto de las inscripciones que concordaron con los criterios de
selección. Si está ausente no hay tales inscripciones.
Span ::= SEQUENCE^{ lowest[0] SequenceNumber, highest[1] SequenceNumber^}
Los componentes de
intervalo
tienen los siguientes
significados:
a)
Más bajo
(O): Es el punto inicial de
intervalo
, dado como un número secuencial (véase el
6.3.2.2
).
b)
Más alto
(O): Es el punto final de
intervalo
, dado como un número secuencial (véase el
6.3.2.2
).
4)
Resúmenes
(C): Se devuelve un
resumen
para cada
petición de resumen
.
Los
resúmenes
se devuelven en el orden en que fueron
solicitados.
Summary ::= SET^{
absent[0] INTEGER (1^.^.^ub-messages) OPTIONAL --
count of
entries where the attribute is
[0]
absent
--,
present[1] SET SIZE (1^.^.^ub-attribute-values) OF --
one for
each attribute value present
--
SEQUENCE^{
type AttributeType,
value ANY DEFINED BY type,
count INTEGER (1^.^.^ub-messages)^} OPTIONAL^}
Los componentes de
resumen
tienen los siguientes
significados:
a)
Ausente
(C): Cómputo de las inscripciones que no
contienen ningún atributo o tipo de atributo especificado en la petición. Se
omite si no hay tales inscripciones.
b)
Presente
(C): Resumen de las inscripciones que
contienen algún atributo del tipo de atributo especificado, descompuesto por
los valores de atributo presentes efectivamente. Se omite si no hay tales
inscripciones.
Los componentes de
presente
tienen los siguientes
significados:
i)
Tipo
(O): Tipo del atributo.
ii)
Valor
(O): Valor del atributo para el que se da el
cómputo.
iii)
Cómputo
(O): Cómputo de inscripciones con su valor de
atributo.
8.2.3
Errores abstractos de resumir
En caso de fracaso de la petición, se informa uno de los errores abstractos listados. Las circunstancias en que se notificarán los errores abstractos particulares se definen en el 9 .
8.3
Operación abstracta-listado
La
operación abstracta-listado
se utiliza para explorar
una base de información seleccionada a fin de buscar inscripciones de interés y
devolver la información seleccionada a dichas inscripciones.
La
operación abstracta-listado
sólo tendrá éxito cuando
la base de la información permita el acceso conforme al contexto de seguridad y
a la política de seguridad en vigor.
La información que puede seleccionarse para las inscripciones en una base de información puede estar restringida. Para los atributos generales en la base de información de mensajes almacenados, las restricciones se indican en el cuadro 1/X.413.
List ::= ABSTRACT-OPERATION ARGUMENT ListArgument RESULT ListResult ERRORS^{ AttributeError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
8.3.1
Argumento de listado
ListArgument ::= SET^{ information-base-type [0] InformationBase DEFAULT stored-messages, selector [1] Selector, requested-attributes [3] EntryInformationSelection OPTIONAL^}
Los componentes de
argumento de listado
tienen los
siguientes significados:
1)
Tipo de base de información
(F): Especifica qué base de
información es seleccionada por la operación abstracta. Véase el
6.3.1
.
En ausencia del componente
tipo base de información
, el
significado por defecto es mensajes almacenados.
2)
Selector
(O): Conjunto de criterios de selección para
determinar que inscripciones han de devolverse. Véase el
8.2.3
.
3)
Atributos solicitados
(F): Indica qué información, de
las inscripciones seleccionadas, debe devolverse en el resultado. Véase el
8.1.4
.
Si este parámetro está ausente, se utiliza el conjunto registrado de los
significados por defecto atributo de listado
. Para más
información sobre los significados por defecto, véase el
8.6.1
.
8.3.2
Resultado de listado
Si tiene éxito la petición, se devolverá
resultado de
listado.
ListResult ::= SET^{
next [0] SequenceNumber OPTIONAL,
requested [1] SEQUENCE SIZE (1^.^.^ub-messages) OF EntryInformation OPTIONAL
--
omitted
requested [1] if none found
--^}
Los componentes de
resultado de listado
tienen los
siguientes significados:
1)
Siguiente
(C): Se devolverá en el caso en que el número
de inscripciones seleccionadas sería mayor si no fuese por el límite
especificado en el selector. El componente contiene el número secuencial para
la siguiente inscripción que se habría seleccionado.
2)
Seleccionado
(C): Transporta la información de
inscripción solicitada (véase el
8.1.5
) a partir de cada inscripción
seleccionada (una o más), en orden ascendente del número secuencial. No está
presente en el caso en que se efectuó una búsqueda y no se seleccionó ninguna
inscripción.
8.3.3
Errores abstractos de listado
En caso de fracaso de la petición, se notificará uno de los errores abstractos de listado. Las circunstancias en las cuales se notifican los distintos errores abstractos se definen en el 9 .
8.4
Operación abstracta de captura
La
operación abstracta de captura
se utiliza para
devolver información seleccionada a partir de una inscripción específica en una
base de información. Alternativamente, se utiliza para devolver información
seleccionada a partir de la primera inscripción entre varias inscripciones de
interés; en este caso se devuelven también los números secuenciales de las
otras inscripciones seleccionadas. La
operación abstracta de
captura
sólo tendrá éxito cuando se soliciten bases de información
permitidas por el contexto de seguridad y la política de seguridad en vigor.
Una información de una inscripción puede ser capturada varias veces, hasta que la inscripción sea suprimida explícitamente por una operación abstracta de supresión.
Fetch ::= ABSTRACT-OPERATION ARGUMENT FetchArgument RESULT FetchResult ERRORS^{ AttributeError, FetchRestrictionError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
8.4.1
Argumento de captura
FetchArgument ::= SET^{ information-base-type [0] InformationBase DEFAULT stored-messages, item CHOICE^{ search [1] Selector, precise [2] SequenceNumber^}, requested-attributes [3] EntryInformationSelection OPTIONAL^}
Los componentes de
argumento de captura
tienen los
siguientes significados:
1)
Tipo de base de información
(F): Especifica qué base de
información es direccionada por la operación abstracta. Véase el
6.3.1
.
En ausencia del tipo de base de información, el significado por defecto es mensajes almacenados.
2)
Elemento
(O): Debe especificarse uno de los componentes
descritos más abajo para determinar qué inscripción ha de capturarse:
a)
Búsqueda
(C): Es un selector que especifica un conjunto
de inscripciones de las cuales la que tiene el número secuencial más bajo es la
inscripción que debe capturarse. Véase el
8.1.3
.
b)
Precisión
(C): Es el número secuencial de la
inscripción que debe capturarse. Véase el
6.3.2.2
.
3)
Atributos solicitados
(F): Indica qué información de la
inscripción seleccionada ha de devolverse en el resultado. Véase el
8.1.4
.
Si este parámetro está ausente, se utiliza el conjunto registrado de los
significados por
defecto del atributo de captura
. Para más
información sobre los significados por defecto, véase el
8.6.1
.
8.4.2
Resultado de captura
Si la petición tiene éxito, se retornará el
resultado de
captura
.
FetchResult ::= SET^{
entry-information [0] EntryInformation OPTIONAL --
if an
entry was selected
--,
list [1] SEQUENCE SIZE (1^.^.^ub-messages) OF SequenceNumber
list [1] OPTIONAL,
next [2] SequenceNumber OPTIONAL^}
Los componentes de
resultado de captura
tienen los
siguientes significados:
1)
Información de inscripción
(C): Es un conjunto de
atributos, de la inscripción, tal como fueron solicitados en el argumento.
Véase el
8.1.5
. No está presente en el caso que se efectúa una
búsqueda y no se selecciona ninguna inscripción.
2)
Lista
(C): Se devuelve cuando se efectuó una búsqueda y
se encontraron más de una inscripción que concordaba con el selector de la
búsqueda. La lista de los números secuenciales, en orden ascendente, de estas
inscripciones ulteriores.
3)
Siguiente
(C): Se devuelve en el caso en que el número
de inscripciones seleccionadas sería mayor si no fuese por el límite
especificado en el selector. El componente contiene el número secuencial para
la siguiente inscripción que se habría seleccionado.
8.4.3
Errores abstractos de captura
En caso de fracaso de la petición, se notificará uno de los errores abstractos listados. Las circunstancias en las cuales se notifican los distintos errores abstractos se definen en el 9 .
8.5
Operación abstracta de supresión
La
operación abstracta de supresión
se utiliza para
suprimir inscripciones seleccionadas en una base de datos. Una inscripción
principal y todas las inscripciones vástagos que dependen de la misma sólo
pueden ser suprimidas conjuntamente. Esto se efectúa especificando simplemente
la inscripción principal como argumento. La operación abstracta de supresión
sólo tendrá éxito cuando opere sobre las bases de información permitidas por el
contexto de seguridad y la política de seguridad en vigor.
Para bases de información específicas, puede haber restricciones a las
inscripciones que podrían suprimirse. Además, pueden efectuarse acciones
específicas del contenido, definidas en la Recomendación correspondiente que
define el tipo contenido. En lo que respecta a los mensajes almacenados, no
puede suprimirse ninguna inscripción, si el estado de esa inscripción (véase el
6.4
) es
`nuevo'
.
Delete ::= ABSTRACT-OPERATION ARGUMENT DeleteArgument RESULT DeleteResult ERRORS^{ DeleteError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
8.5.1
Supresión argumento
DeleteArgument ::= SET^{ information-base-type [0] InformationBase DEFAULT stored-messages, items CHOICE^{ selector [1] Selector sequence-numbers [2] SET SIZE (1^.^.^ub-messages) OF SequenceNumber^}^}
Los componentes de
supresión argumento
tienen los
siguientes significados:
1)
Tipo de base de información
(O): Especifica qué base de
información es direccionada por la operación abstracta. Véase el
6.3.1
.
En la ausencia del componente
tipo de base de
información
, el significado por defecto es mensajes almacenados.
2)
Elementos
(O): Para determinar las inscripciones que
han de suprimirse hay que especificar uno de los componentes descritos a
continuación:
a)
Selector
(C): Véase el
8.1.3
.
b)
Números secuenciales
(C): Una lista no ordenada de
números secuenciales
. Véase el
6.3.2.2
.
8.5.2
Resultado de supresión
Si la petición tiene éxito, se retornará el
resultado de
supresión
. No existen parámetros.
DeleteResult ::= NULL
8.5.3
Errores abstractos de supresión
En caso de fracaso de la petición, se notificará uno de los errores abstractos listados. Las circunstancias en las cuales se informan los distintos errores abstractos se definen en el 9 .
8.6
Operación abstracta de registro en AM
La operación abstracta de registro en AM se utiliza para registrar o eliminar diversas informaciones en el AM:
a)acciones automáticas;
b)lista por defecto de tipos de atributo;
c)nuevas credenciales;
d)nuevo conjunto de etiquetas de seguridad de usuario.
Register-MS ::= ABSTRACT-OPERATION ARGUMENT Register-MSArgument RESULT Register-MSResult ERRORS^{ AtrributeError, AutoActionRequestsError, InvalidParametersError, SecurityError, ServiceError^}
8.6.1
Argumento de registro en AM
Register-MS Arguments := SET^{
auto-action-registrations [0] SET SIZE (1^.^.^ub-auto-registrations)
OF AutoActionRegistra-
auto-action-registrations [0] tion OPTIONAL,
auto-action-deregistrations [1] SET SIZE (1^.^.^ub-auto-registrations)
OF AutoActionDere-
auto-action-deregistrations [1] gistration OPTIONAL,
list-attribute-defaults [2] SET SIZE (1^.^.^ub-default-registrations)
OF Attribute Type
list-attribute-defaults [2] OPTIONAL,
fetch-attribute-defaults [3] SET SIZE (1^.^.^ub-default-registrations)
OF Attribute Type
fetch-attribute-defaults [3] OPTIONAL,
change-credentials [4] SEQUENCE^{
old-credentials [0] IMPLICIT Credentials,
new-credentials [1] IMPLICIT Credentials^} OPTIONAL
--
misma selección que para las credenciales viejas
--,
user-security-labels [5] SET SIZE (1^.^.^ub-labels-and-redirections)
OF SecurityLabel
user-security-labels [5] OPTIONAL^}
Los componentes de argumento de registro en AM tienen los siguientes significados:
1)
Registro de acciones automáticas
(F): Es un conjunto de
registros de acción automática
(véase el
6.5.1
),
uno para cada acción automática a registrar. El
parámetro
registro de acción automática
nuevo prevalece sobre cualquier acción
automática registrada anteriormente (si la hubiere) con ese
identificador de registro
y
tipo de acción
automática
.
En ausencia el valor por defecto de
registros de acciones
automáticas
, es que no se registra ninguna nueva acción automática.
2)
Eliminaciones de acciones automáticas
(F): Es un
conjunto de
eliminación de acción automática
, una para cada
acción automática a eliminar. Es eliminada toda acción automática cuyo
identificador de registro
y
tipo de acción
automática
concuerdan con los que figuran en una
eliminación
de acción automática
.
AutoActionDeregistration ::= AutoActionRegistration (WITH COMPONENTS {^.^.^.^, registration-parameter ABSENT^}^)
En ausencia de
eliminaciones de acciones automáticas
, el
significado por defecto es que ninguna acción automática registrada sea
eliminada.
3)
Valores por defecto de atributos de listado
(F):
Especifica un conjunto por defecto de tipos de atributos para indicar qué
atributos deben devolverse para cualquier ulterior operación abstracta de
listado o alerta si el argumento selección de información de inscripción está
ausente.
En ausencia de
valores por defecto de atributos de
listado
, el significado por defecto es que no hay cambios en el valor por
defecto registrado (si lo hubiere).
Valores por defecto de
atributos de listado
es un conjunto vacío hasta que el usuario AM lo
cambie explícitamente por medio de la operación abstracta de registro en el AM.
4)
Valores por defecto de atributos de captura
(F):
Especifica un conjunto por defecto de tipos de atributo para indicar qué
atributos deben devolverse para cualquier ulterior operación abstracta de
captura si está ausente el argumento selección de información de asiento.
En ausencia de
valores por defecto de atributos de
captura
, el significado por defecto es que no se cambia el valor por
defecto registrado (si no hubiere).
Valores por defecto de
atributos de captura
es un conjunto vacío hasta que el usuario AM lo
cambie explícitamente por medio de la operación abstracta de registro en el AM.
5)
Cambio de credenciales
(F): Las credenciales viejas y
las nuevas, si se solicita
cambio de credenciales
.
Las
credenciales viejas
son las credenciales que tiene
actualmente un usuario, y las
credenciales nuevas
son las
credenciales que el usuario querría tener.
En ausencia de este argumento, el significado por defecto es que las credenciales registradas anteriormente se mantienen sin modificación.
Las credenciales del usuario AM pueden diferir de las
credenciales del iniciador
detalladas en el
8.1.1.1.1.2
de la Recomendación X.411.
6)
Etiquetas de seguridad de usuario
(F): Contiene las
etiquetas de seguridad
del usuario del servicio abstracto
AM, si han de cambiarse. Puede ser generado por el usuario del servicio
abstracto AM.
En ausencia de este argumento, las
etiquetas de seguridad de
usuario
se mantienen sin modificación.
Obsérvese que algunas
políticas de seguridad
sólo
permiten que las
etiquetas de seguridad de usuario
se
cambien de esta manera si se emplea un enlace seguro. Pueden preverse otros
medios locales de cambiar las
etiquetas de seguridad de
usuario
de una manera segura. Las
etiquetas de seguridad de
usuario
se definen en el
8.4.1.1.1.7
de la Recomendación X.411.
La
etiqueta de seguridad
se define en el
9
de
la Recomendación X.411.
8.6.2
Resultado de registro en el AM
Si la petición tiene éxito, se devolverá el resultado de registro en el AM. No hay parámetros.
Register-MSResult ::= NULL
8.6.3
Errores abstractos de registrar en el AM
Si la petición fracasa, se notificará uno de los errores abstractos listados. Las circunstancias en las que se notificarán los distintos errores abstractos se definen en el 9 .
8.7
Operación abstracta de alerta
La
operación abstracta de alerta
habilita al proveedor
del servicio abstracto AM para informar inmediatamente al usuario del servicio
abstracto AM sobre una nueva inscripción que ha sido introducida en el AM,
cuyos atributos concuerdan con los criterios de selección de uno de los
registros de alerta automática
(véase el
12.2
)
suministrados anteriormente utilizando la operación abstracta de registro en el
AM (véase el
8.6
).
La
operación abstracta de alerta
puede ser invocada
durante una asociación abstracta existente iniciada por el AU, y solamente como
un resultado de inscripciones nuevas que han sido creadas después del
establecimiento de la asociación abstracta.
Las inscripciones que concuerden con los criterios de selección que han
sido creados entre asociaciones abstractas se indicarán en el resultado de la
siguiente operación abstracta de vinculación para la asociación abstracta. Para
estas inscripciones no se invocará ninguna
operación abstracta de
alerta
. Véase el
7
.
La
operación abstracta de alerta
sólo tendrá éxito
cuando la base de información permita el acceso de acuerdo con el contexto de
seguridad y la política de seguridad en vigor.
Alert ::= ABSTRACT-OPERATION ARGUMENT AlertArgument RESULT AlertResult ERRORS^{ SecurityError^}
8.7.1
Argumento de alerta
AlertArgument ::= SET^{ alert-registration-identifier [0] INTEGER (1^.^.^ub-auto-actions), new-entry [2] EntryInformation OPTIONAL^}
Los componentes del
argumento de alerta
tienen los
siguientes significados:
1)
Identificador de registro de alerta
(O): Identifica
cuál de los
registros de alertas automáticas
produjeron la
alerta (véanse los
6.4
y 12.2).
2)
Inscripción nueva
(F): Contiene la información de la
inscripción nueva que fue solicitada en el
parámetro registro de
alerta automática
(véase el
12.2
). Está ausente cuando el
usuario del servicio abstracto AM no especificó un
registro de
alerta automática
.
8.7.2
Resultado de alerta
Si la petición tiene éxito, se devolverá el resultado de alerta.
AlertResult ::= NULL
8.7.3
Errores abstractos de alerta
Si la petición fracasa, se notificará uno de los errores abstractos listados. Las circunstancias en las cuales se notifican los distintos errores abstractos se definen en el 9 .
9
Errores abstractos
Este punto define los siguientes errores abstractos asociados con el uso de operaciones abstractas en el puerto de extracción:
a)ErrorDeAtributo;
b)ErrorDePeticiónDeAcciónAutomática;
c)ErrorDeSupresión;
d)ErrorDeRestricciónACaptura;
e)ErrorDeParámetrosInválidos;
f)ErrorDeGama;
g)ErrorDeSeguridad;
h)ErrorDeServicio;
i)ErrorDeNúmeroSecuencial.
9.1
Precedencia de los errores
El realizador de una operación abstracta no está obligado a continuar el procesamiento del mensaje más allá del punto en que se detectó un error. Esto permite a una realización la elección de si va o no a continuar el procesamiento de errores.
Nota
- Una implicación de esta regla es que el primer
error encontrado puede ser diferente en casos repetidos de la misma operación
abstracta, pues no tiene necesariamente que existir un orden lógico específico
en el cual procesar los distintos casos de la operación abstracta.
9.2
Error de atributo
Un
error de atributo
notifica un problema relacionado
con un atributo.
AttributeError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1^.^.^ub-per-entry) OF SET^{ problem [0] AttributeProblem, type [1] AttributeType, value [2] ANY DEFINED BY type OPTIONAL^}^}
AttributeProblem ::= INTEGER^{ invalid-attribute-value (0), unavailable-attribute-type (1), inappropriate-matching (2), attribute-type-not-subscribed (3), inappropriate-for-operation (4)^} (0^.^.^ub-error-reasons)
El parámetro tiene el siguiente significado:
1)
Problemas
(O): Los problemas concretos encontrados.
Puede indicarse un número cualquiera de problemas individuales, cada uno de los
cuales irá acompañado de una indicación del tipo de atributo, y, si fuese
necesario para evitar la ambigüedad, del valor que causó el problema:
a)
Valor de atributo no válido
(C): Un valor de atributo
contemplado especificado como argumento de la operación abstracta no se ajusta
al tipo de datos definido para el tipo de atributo en cuestión.
b)
Tipo de atributo no disponible
(C): Un tipo de atributo
contemplado utilizado como un argumento de la operación abstracta no es uno de
los admitidos por el proveedor del servicio abstracto AM. Si el proveedor del
servicio abstracto AM puede, de todas formas, realizar la operación, no está
prohibido que lo haga.
c)
Concordancia inapropiada
(C): El filtro contiene un
elemento de filtro en el cual un atributo se hace concordar utilizando una
operación (igualdad, ordenamiento, o subcadenas) que no está definida para ese
atributo.
d)
Tipo de atributo no abonado
(C): Un tipo de atributo
utilizado como un argumento de la operación abstracta no es uno de los tipos a
que está abonado el usuario del servicio abstracto AM.
Nota
- Un cambio en el abono no se refleja
necesariamente en los atributos presentes en una inscripción creada antes del
cambio.
e)
Inapropiado para operación
(C): Un tipo de atributo
utilizado como un argumento de la operación abstracta es inadecuado para el uso
requerido.
9.3
Error de petición de acción
automática
Un
error de petición de acción automática
notifica un
problema relacionado con el registro de una acción automática.
AutoActionRequestError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1^.^.^ub-auto-registrations) OF SET^{ problem [0] Auto-ActionRequestProblem, type [1] AutoActionType^}^}
AutoActionRequestProblem ::= INTEGER^{ unavailable-auto-action-type (0), auto-action-type-not-subscribed (1)^} (0^.^.^ub-error-reasons)
El parámetro tiene el siguiente significado:
1)
Problemas
(O): Los problemas concretos encontrados.
Puede indicarse cualquier número de problemas individuales, cada uno de los
cuales va acompañado de una indicación del
tipo de acción
automática
que causó el problema:
a)
Tipo de acción automática no disponible
- Un tipo de
acción automática utilizado como un argumento de la operación abstracta no es
uno de los admitidos por el proveedor del servicio abstracto AM.
b)
Tipo de acción no abonado
- Un tipo de acción utilizado
como un argumento de la operación abstracta no es uno de los tipos a que está
abonado el usuario del servicio abstracto AM.
9.4
Error de supresión
Un
error de supresión
notifica un problema que se
presenta al tratar de suprimir una o más inscripciones en una base de
información.
DeleteError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1^.^.^ub-messages) OF SET^{ problem [0] DeleteProblem, sequence-number [1] SequenceNumber^}^}
DeleteProblem ::= INTEGER^{ child-entry-specified (0), delete-restriction-problem (1)^} (0^.^.^ub-error-reasons)
El parámetro tiene el siguiente significado:
1)
Problema
(O): Los problemas concretos encontrados.
Puede indicarse cualquier número de problemas individuales, cada uno de los
cuales va acompañado de una indicación del número secuencial de la inscripción
que causó el problema:
a)
Inscripción vástago especificada
: Se ha tratado de
suprimir una inscripción vástago.
b)
Problema de restricción a supresión
: Se ha tratado de
violar una restricción especificada para la operación abstracta de supresión
(véase el
8.5
).
9.5
Error de restricción a captura
Un
error de restricción a captura
informa sobre una
tentativa de violar una restricción asociada con la operación abstracta de
captura.
FetchRestrictionError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1^.^.^ub-default-registrations) OF SET^{ problem [3] FetchRestrictionProblem, restriction CHOICE^{ content-type [0] ContentType, eit [1] MS-EITs, content-length [2] ContentLength^}^}^}
FetchRestrictionProblem ::= INTEGER^{ content-type-problem (1), eit-problem (2), content-length-problem (3)^} (0^.^.^ub-error-reasons)
El parámetro tiene el siguiente significado:
1)
Problemas
(O): Los problemas concretos encontrados.
Puede indicarse cualquier número de problemas individuales, cada uno de los
cuales va acompañado de una indicación del tipo de contenido infractor, del
tipo de información codificada o de la longitud del contenido que causó el
problema:
a)
Problema de tipo de contenido
(C): El tipo de contenido
del mensaje que se está capturando no está permitido por las restricciones a
captura actualmente en vigor.
b)
Problema de TIC
(C): Los tipos de información
codificada solicitados en la operación abstracta de captura no están permitidos
por las restricciones a captura actualmente en vigor.
c)
Problema de longitud de contenido
(C): La longitud de
contenido del mensaje que se está capturando es mayor que la autorizada por las
restricciones a captura actualmente en vigor.
9.6
Error de parámetro no válido
Un
error de parámetro no válido
notifica un problema de
semántica en el conjunto de parámetros recibidos. Este error se utilizaría, por
ejemplo, para notificar que un parámetro opcional estaba presente en un
contexto incorrecto, o para notificar que uno de los parámetros tiene un valor
inadecuado.
InvalidParametersError ::= ABSTRACT-ERROR PARAMETER NULL
Este error no tiene parámetros.
9.7
Error de gama
Un
error de gama
notifica un problema relacionado con el
límite especificado en un selector como un argumento a una operación abstracta.
RangeError ::= ABSTRACT-ERROR PARAMETER SET^{ problem [0] RangeProblem^}
RangeProblem ::= INTEGER^{ reversed (0)^} (0)^.^.^ub-error-reasons^}
El parámetro tiene el significado siguiente:
1)
Problemas
(O): Los problemas concretos encontrados:
a)
Invertido
(C): El límite superior indicaba un número
secuencial o una hora de creación anterior al indicado por el límite inferior.
9.8
Error de seguridad
Un
error de seguridad
notifica que la operación
abstracta solicitada no puede proporcionarse porque violaría la política de
seguridad en vigor. Este error se define en la Recomendación X.411.
9.9
Error de número secuencial
Un
error de número secuencial
notifica un problema
relacionado con el número secuencial especificado en un argumento de una
operación abstracta.
SequenceNumberError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [1] SET SIZE (1^.^.^ub-messages) OF SET^{ problem [0] SequenceNumberProblem, sequence-number [1] SequenceNumber^}^}
SequenceNumberProblem ::= INTEGER^{ no-such-entry (0)^} (0^.^.^ub-error-reasons)
El parámetro tiene el siguiente significado:
1)
Problemas
(O): Los problemas concretos encontrados.
Puede indicarse un número cualquiera de problemas individuales, cada uno de los
cuales va acompañado de una indicación de los números secuenciales que causaron
el problema:
a)
No hay tal inscripción
: El número secuencial
suministrado no concuerda con el de ninguna inscripción en la base de
información.
9.10
Error de servicio
Un
error de servicio
notifica un error relacionado con
la prestación del servicio.
ServiceError ::= ABSTRACT-ERROR PARAMETER SET^{ problem [0] ServiceProblem^}
ServiceProblem ::= INTEGER^{ busy (0), unavailable (1), unwilling-to-perform (2)^}^(0^.^.^ub-error-reasons)
Este parámetro tiene el siguiente significado:
1)
Problema
(O): El problema concreto encontrado:
a)
Ocupado
(C): El AM, o una parte de éste, está en este
momento demasiado ocupado para realizar la operación abstracta solicitada, pero
puede no estarlo en breve.
b)
No disponible
(C): El AM, o alguna parte del mismo,
está indisponible en este momento.
c)
No dispuesto a funcionar
(C): El AM no está preparado
para ejecutar esta petición porque conduciría a un consumo excesivo de
recursos.
SECCIóN 3 - TIPOS DE ATRIBUTOS GENERALES Y TIPOS DE ACCIONES AUTOMáTICAS GENERALES
10 Visión de conjunto
El modelo de información AM y los conceptos de
atributo
y de
acción automática
ya fueron presentados en los
6.3.3
y 6.5. El
11
define los
tipos de
atributo generales
que se especifican para AM. El
12
define los
tipos de acción automática generales
especificados para AM.
11
Tipos de atributos
generales
Los
tipos de atributos generales
son válidos para todos
los tipos de contenido mensaje. Otros tipos de atributo, que son específicos al
contenido, se definen en sus respectivas Recomendaciones, por ejemplo los tipos
de atributo específicos al SMIP para AM se definen en el anexo C de la
Recomendación X.420.
11.1
Visión de conjunto de los tipos de atributos
generales
Los
atributos generales
que pueden presentarse en una
inscripción de base de información de mensajes almacenados se enumeran en el
cuadro 1/X.413. Están constituidos principalmente a partir de la información de
los parámetros de las operaciones abstractas entrega de mensajes
(MessageDelivery) y entrega de informe (ReportDelivery) del servicio abstracto
STRM definido en el
8
de la Recomendación X.411 y esos atributos son
denominados correspondientemente. Algunos
atributos
generales
son generados y otros son simplemente conservados por el AM.
El cuadro 1/X.413 define los diversos
atributos
generales
y para cada tipo de atributo define lo siguiente:
-si el tipo de atributo tiene un solo valor o tiene valores múltiples;
-si es admitido o no por el AM y si el acceso al AU es obligatorio o facultativo;
-si el tipo de atributo siempre está presente, está presente de forma condicional, o está ausente en una inscripción de mensaje entregado, en una inscripción de informe entregado, o en una inscripción de contenido devuelto;
-si el tipo de atributo puede ser devuelto o no en una operación abstracta de listado o alerta;
-si el tipo de atributo puede o no ser utilizado en una operación abstracta de resumir.
Nota
- únicamente para los tipos de datos NSA.1
simples.
Para una descripción detallada de la clasificación del cuadro 1/X.413, véanse los convenios del 5.2 .
Un AM admite un tipo de atributo facultativo únicamente si hay un abono correcto al soporte de ese atributo (lo que implica que el AM y el AU que accede admiten dicho atributo). El abono a tipos de atributos facultativos puede hacerse para cada tipo de atributo, para cada AU.
11.2
Descripción de los tipos de atributos generales
Los siguientes puntos contienen una breve descripción de cada
tipo de atributo general
junto con su sintaxis abstracta
utilizando la macro ATRIBUTE descrita en el
6.3
.
Debe señalarse que algunos
atributos generales
se
utilizan básicamente para filtrar y listar, mientras que otros pueden contener
información más compleja (tipos de datos NSA.1 más estructurados) y
potencialmente voluminosa. Sólo pocos
atributos generales
resultan adecuados para los resúmenes.
11.2.1
Números secuenciales de vástago
Este atributo general, que tiene valores múltiples, contiene uno o más
`punteros'
hacia el nivel siguiente de inscripciones vástagos, si los
hay. Es generado por el AM. Está presente en una progenitora que tiene una o
más inscripciones vástagos asociadas. Está ausente en una inscripción que no
tiene inscripciones vástagos.
ms-child-sequence-numbers ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MULTI VALUE ::= id-att-child-sequence-numbers
Cuadro 1/X.413 [T1.413], p.
11.2.2
Contenido
Este atributo general contiene el contenido completo de un mensaje tal como lo entrega la operación abstracta entrega de mensaje o bien se presenta como un contenido devuelto por la operación abstracta entrega de informe. Para mayores detalles véanse los 8.2.1.1.1.37 y 8.3.1.2.1.14 de la Recomendación X.411.
ms-content ATTRIBUTE WITH ATTRIBUTE-SYNTAX Content SINGLE VALUE ::= id-att-content
11.2.3
Identificador de algoritmo de confidencialidad
del contenido
Este atributo general contiene el
identificador de
algoritmo
utilizado por el originador del mensaje para cifrar el contenido
del mensaje. Puede ser generado por el originador del mensaje. Para detalles
adicionales véase el
8.5.10
de la Recomendación X.411.
mt-content-confidentiality-algorithm-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX AlgorithmIdentifier SINGLE VALUE ::= id-att-content-confidentiality-algorithm-identifier
11.2.4
Correlación de contenido
Este atributo general contiene información que permite la correlación del contenido del mensaje. Puede ser generado por el AU de origen. Para detalles adicionales véase el 8.2.1.1.1.36 de la Recomendación X.411.
mt-content-correlator ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentCorrelator MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-correlator
11.2.5
Identificador de contenido
Este atributo general contiene un identificador para el contenido del mensaje. Puede ser generado por un AU de origen. Para detalles adicionales véase el 8.2.1.1.1.35 de la Recomendación X.411.
mt-content-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentIdentifier MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-identifier
11.2.6
Verificación de integridad del
contenido
Este atributo general proporciona a los destinatarios del mensaje una forma de validar que el contenido del mensaje no ha sido modificado. Puede ser generado por el originador del mensaje y puede especificar un valor diferente para cada destinatario del mensaje. Para detalles adicionales véase el 8.2.1.1.28 de la Recomendación X.411.
mt-content-integrity-check ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentIntegrityCheck SINGLE VALUE ::= id-att-content-integrity-check
11.2.7
Longitud del contenido
Este atributo general proporciona la longitud en octetos del contenido de un mensaje como fue entregado por la operación abstracta entrega de mensaje o de un contenido devuelto (si lo hay) notificado por la operación abstracta entrega de informe. Cuando no hay tal contenido devuelto, el atributo está ausente. Es generado por el AM.
ms-content-length ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentLength MATCHES FOR ORDERING SINGLE VALUE ::= id-att-content-length
11.2.8
Contenido devuelto
Este atributo general indica si el contenido ha sido devuelto en la operación abstracta entrega de informe. Es generado por el AM.
ms-content-returned ATTRIBUTE WITH ATTRIBUTE-SYNTAX BOOLEAN MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-returned
11.2.9
Tipo de contenido
Este atributo general es generado a partir del tipo de contenido en la operación abstracta entrega de mensaje o entrega de informe. Véase también el 8.2.1.1.1.34 de la Recomendación X.411.
mt-content-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-type
11.2.10
Prohibición de conversión con
pérdida
Este atributo general contiene información sobre si está permitida o prohibida la conversión con pérdida de información. Para detalles adicionales véase el 8.2.1.1.1.10 de la Recomendación X.411.
mt-conversion-with-loss-prohibited ATTRIBUTE WITH ATTRIBUTE-SYNTAX ConversionWithLossProhibited MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-conversion-with-loss-prohibited
11.2.11
TIC convertidos
Este atributo general, que tiene valores múltiples, identifica los tipos de información codificada del contenido después de la conversión, tal como lo indica la operación abstracta de entrega de mensaje o entrega de informe. Es generado por el AM. Está ausente si no se realizó ninguna conversión. Para detalles adicionales véanse los 8.3.1.1.1.8 y 8.3.1.2.1.5 de la Recomendación X.411.
ms-converted-EITs ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EIT MATCHES FOR EQUALITY MULTI VALUE ::= id-att-converted-EITs
11.2.12
Hora de creación
Este atributo general proporciona la hora (o fecha) en que se creó el asiento en el AM. Es generado por el AM. Para detalles adicionales véase el 6.3.2 .
Nota
- Dos o más inscripciones consecutivas pueden
tener la misma hora de creación.
ms-creation-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX CreationTime MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-creation-time
11.2.13
TIC entregados
Este atributo general, que tiene valores múltiples, identifica los tipos de información codificada en el contenido del mensaje tal como se entregó. Es generado por el AM basándose en la información sobre los TIC originales y los TIC convertidos en la operación abstracta entrega de mensaje.
ms-delivered-EITs ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EIT MATCHES FOR EQUALITY MULTI VALUE ::= id-att-delivered-EITs
11.2.14
Banderas de entrega
Este atributo general contiene información de entrega. Actualmente se utiliza únicamente para indicar la conversión implícita del contenido. Para mayores detalles véase el 8.2.1.1.1.9 de la Recomendación X.411.
mt-delivery-flags ATTRIBUTE WITH ATTRIBUTE-SYNTAX DeliveryFlags MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-delivery-flags
11.2.15
Historia de la ampliación de la
LD
Este atributo general, de múltiples valores, se utiliza para mostrar la historia de la ampliación de la lista de distribución. Contiene uno o más nombres de listas de distribución utilizados durante el proceso de ampliación. Está ausente si la entrega a dicho destinatario no implica ninguna ampliación de una lista de distribución. Para mayores detalles véase el 8.3.1.1.1.7 de la Recomendación X.411.
mt-dl-expansion-history ATTRIBUTE WITH ATTRIBUTE-SYNTAX DLExpansionHistory MULTI VALUE ::= id-att-dl-expansion-history
11.2.16
Estado de la inscripción
Este atributo general contiene el estado actual de cualquier inscripción en la base de información de mensajes almacenados. Es creado y mantenido por el AM. Para mayores detalles véase el 6.4 .
ms-entry-status ATTRIBUTE WITH ATTRIBUTE-SYNTAX EntryStatus MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-entry-status
11.2.17
Tipo de inscripción
Este atributo general contiene información que indica si una inscripción se refiere a un mensaje entregado o a un informe entregado. Es generado por el AM.
ms-entry-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EntryType MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-entry-type
EntryType ::= INTEGER^{ delivered-message (0), delivered-report (1), returned-content (2) (0^.^.^ub-entry-types)^}
11.2.18
Nombre del destinatario deseado
Este atributo general contiene el nombre O/D del destinatario previsto inicialmente si el mensaje ha sido redireccionado, y en donde cada valor representa un redireccionamiento. Para mayores detalles véase el 8.3.1.1.1.4 de la Recomendación X.411.
mt-intended-recipient-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-intended-recipient-name
11.2.19
Sobre de entrega de mensaje
Este atributo general contiene el
sobre de entrega de
mensaje
completo de un mensaje tal como es entregado por la operación
abstracta. Para mayores detalles véase el
9
de la Recomendación
X.411.
mt-message-delivery-envelope ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageDeliveryEnvelope SINGLE VALUE ::= id-att-message-delivery-envelope
11.2.20
Identificador de entrega de
mensajes
Este atributo general contiene el
identificador de entrega de
mensaje
proveniente de la operación abstracta entrega de mensaje. Para
mayores detalles véase el
8.3.1.1.1.1
de la Recomendación X.411.
mt-message-delivery-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageDeliveryIdentifier SINGLE VALUE ::= id-att-message-delivery-identifier
11.2.21
Hora de entrega del mensaje
Este atributo general contiene la
hora de entrega de
mensaje
procedente de la operación abstracta entrega de mensaje. Para
mayores detalles véase el
8.3.1.1.1.2
de la Recomendación X.411.
Nota
- No existe ningún atributo general
correspondiente al parámetro hora de entrega de la operación abstracta entrega
de informe, ya que para ser útil este tiempo de entrega debe estar
correlacionado con el nombre del destinatario al que fue entregado el mensaje.
Esta información se incluye en el atributo general información de informe.
mt-message-delivery-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageDeliveryTime MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-message-delivery-time
11.2.22
Verificación de la autenticación del origen
del mensaje
Este atributo general se calcula utilizando el algoritmo identificado por el identificador de autenticación del origen del mensaje. Proporciona al destinatario del mensaje una forma de autenticar el origen del mensaje y puede ser generado por el originador del mensaje. Para detalles adicionales véase el 8.2.1.1.1.29 de la Recomendación X.411.
mt-message-origin-authentication-check ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageOriginAuthenticationCheck SINGLE VALUE ::= id-att-message-origin-authentication-check
11.2.23
Etiqueta de seguridad del
mensaje
Este atributo general consta de un conjunto de atributos de seguridad que pueden incluir un identificador de política de seguridad, una clasificación de seguridad, una marca de confidencialidad, y un conjunto de categorías de seguridad. Para mayores detalles, véase el 8.2.1.1.1.30 de la Recomendación X.411.
mt-message-security-label ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageSecurityLabel SINGLE VALUE ::= id-att-message-security-label
11.2.24
Hora de depósito del mensaje
Este atributo general contiene la
hora de depósito del
mensaje
proveniente de una operación abstracta de entrega de mensaje. Para
mayores detalles véase el
8.2.1.1.2.2
de la Recomendación X.411.
mt-message-submission-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageSubmissionTime MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-message-submission-time
11.2.25
Testigo de mensaje
Este atributo general contiene el testigo asociado al mensaje. Es generado por el originador del mensaje y puede contener un valor diferente para cada destinatario del mensaje. Para detalles adicionales véase el 8.2.1.1.1.26 de la Recomendación X.411.
mt-message-token ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageToken SINGLE VALUE ::= id-att-message-token
11.2.26
TIC originales
Este atributo general, de múltiples valores, contiene los
tipos de información codificada originales
provenientes de
la operación abstracta entrega de mensaje. Es generado por el AM. Para detalles
adicionales véase el
8.2.1.1.1.33
de la Recomendación X.411.
ms-original-EITs ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EIT MATCHES FOR EQUALITY MULTI VALUE ::= id-att-original-EITs
11.2.27
Certificado de originador
Este atributo general contiene el certificado del originador del mensaje. Es generado por una fuente de confianza (por ejemplo una autoridad de certificación) y puede ser suministrado por el originador del mensaje. Para detalles adicionales véase el 8.2.1.1.1.25 de la Recomendación X.411.
mt-originator-certificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX Originator-Certificate SINGLE VALUE ::= id-att-originator-certificate
11.2.28
Nombre del originador
Este atributo general contiene el nombre O/D del originador de la operación abstracta entrega de mensaje. Para detalles adicionales véase el 8.2.1.1.1.1 de la Recomendación X.411.
mt-originator-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-originator-name
11.2.29
Otros nombres de destinatarios
Este atributo general, de múltiples valores, contiene los nombres O/D de todos los demás destinatarios especificados, si los hubiere, de un mensaje provenientes de la operación abstracta entrega de mensaje. Para mayores detalles véase el 8.3.1.1.1.6 de la Recomendación X.411.
mt-other-recipient-names ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY MULTI VALUE ::= id-att-other-recipient-names
11.2.30
Número secuencial de progenitor
Este atributo general apunta a una inscripción progenitora. Es generado por el AM. Siempre está presente en una inscripción vástago y está ausente en una inscripción principal.
ms-parent-sequence-number ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-parent-sequence-number
11.2.31
Campos de entrega de informes por
destinatario
Este atributo general, de múltiples valores, contiene información destinatario por destinatario de la operación abstracta entrega de informe. Para detalles adicionales véase el 8.3.1.2 de la Recomendación X.411.
mt-per-recipient-report-delivery-fields ATTRIBUTE WITH ATTRIBUTE-SYNTAX PerRecipientReportDeliveryFields MUTLI VALUE ::= id-att-per-recipient-report-delivery-fields
11.2.32
Prioridad
Este atributo general contiene la
prioridad
relativa del
mensaje proveniente de la operación abstracta entrega de mensaje. Si en el
parámetro de la operación abstracta entrega de mensaje no se proporciona ningún
valor al generar dicho atributo, el AM utiliza el valor por defecto. Para
detalles adicionales véase el
8.2.1.1.1.8
de la Recomendación X.411.
mt-priority ATTRIBUTE WITH ATTRIBUTE-SYNTAX Priority MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-priority
11.2.33
Petición de prueba de entrega
Este atributo general indica si el originador del mensaje necesita o no
prueba de entrega
del mensaje al destinatario. Puede ser
generada por el originador del mensaje y puede especificar un valor diferente
para cada destinatario del mensaje. Para detalles adicionales véase el
8.2.1.1.1.32
de la Recomendación X.411.
mt-proof-of-delivery-request ATTRIBUTE WITH ATTRIBUTE-SYNTAX ProofOfDeliveryRequest SINGLE VALUE ::= id-att-proof-of-delivery-request
11.2.34
Historia del redireccionamiento
Este atributo general, de múltiples valores, contiene la historia de los redireccionamientos al destinatario con el (los) motivo(s) proporcionados por la operación abstracta entrega de mensaje o entrega de informe. Para detalles adicionales véase el 8.3.1.1.1.5 de la Recomendación X.411.
mt-redirection-history ATTRIBUTE WITH ATTRIBUTE-SYNTAX RedirectionHistory MULTI VALUE ::= id-att-redirection-history.
11.2.35
Sobre de entrega de informe
Este atributo general contiene todos los parámetros de la operación abstracta entrega de informe, excepto el contenido devuelto (si lo hay). Para detalles adicionales véase el 8.3.1.2 de la Recomendación X.411.
mt-report-delivery-envelope ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportDeliveryEnvelope SINGLE VALUE ::= id-att-report-delivery-envelope
11.2.36
Nombre de la LD informante
Este atributo general contiene el nombre O/D de la lista de distribución que envió el informe al propietario de la lista de distribución. Para detalles adicionales véase el 8.3.1.2.1.4 de la Recomendación X.411.
mt-reporting-DL-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportingDLName SINGLE VALUE ::= id-att-reporting-DL-name
11.2.37
Certificado del ATM informante
Este atributo general contiene el certificado del ATM que generó el informe. Para detalles adicionales véase el 8.3.1.2.1.12 de la Recomendación X.411.
mt-reporting-MTA-certificate-ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportingMTACertificate SINGLE VALUE ::= id-att-reporting-MTA-certificate
11.2.38
Verificación de la autenticación del origen
del informe
Este atributo general proporciona una forma de autenticar el origen del informe. Para detalles adicionales véase el 8.3.1.2.1.13 de la Recomendación X.411.
mt-report-origin-authentication-check ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportOriginAuthenticationCheck SINGLE VALUE ::= id-att-report-origin-authentication-check
11.2.39
Clasificación de seguridad
Este atributo general comprende el parámetro clasificación de seguridad procedente de la etiqueta de seguridad del mensaje. Se define como un atributo separado para permitir su uso de la operación abstracta resumir. Para detalles adicionales véase el 8.5.9 de la Recomendación X.411.
mt-security-classification ATTRIBUTE WITH ATTRIBUTE-SYNTAX SecurityClassification MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-security-classification
11.2.40
Número secuencial
Este atributo general se utiliza para identificar la propia inscripción. Es atribuido por el AM al crear la inscripción. Para mayores detalles véase el 6.3.2 .
mt-sequence-number ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-sequence-number
11.2.41
Identificador de depósito asunto
Este atributo general contiene el identificador de depósito de mensaje o identificador de depósito de sonda del asunto del informe. Para mayores detalles véase el 8.3.1.2.1.1 de la Recomendación X.411.
mt-subject-submission-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectSubmissionIdentifier SINGLE VALUE ::= id-att-subject-submission-identifier
11.2.42
Nombre de este destinatario
Este atributo general contiene el nombre O/D de este destinatario (AM) procedente de la operación abstracta entrega de mensaje para mayores detalles véase el 8.3.1.1.1.3 de la Recomendación X.411.
mt-this-recipient-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-this-recipient-name
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.106.S)
(SANS FORMULES) Tableaux: 3 - Tabulateurs: 0
(BT..) Disk ... NF../... (OPM = ..)
(87.TE.14.S)
(A1.23s) / [26s]
FOLIOS: 468 - 501 (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 594-595 02.09.89 GG/PR
ID + Vérif. + diskette MAJ + laser 11.10.89 PV
Corr. LASER (1re épreuve) = 3eme 07.11.89 UT
Espaces réservés + Transfert + Impr. 10.11.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 16.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 17.11.89 PC
BAT du 27/XI/89 4.12.89 PV
MAJ s/disquettes ........ ..
11.3
Generación de los atributos generales
Este punto describe la forma en que se generan los atributos generales. La información se presenta en el cuadro 2/X.413. Para la descripción de las clasificaciones utilizadas véase el 5.3 .
Tableau 2/X.413 [1T2.413], p. 1
Tableau 2/X.413 [2T2.413], p. 2
Tableau 2/X.413 [3T2.413], p. 3
11.4
Abono a tipos de atributo
El abono a tipos de atributo es un asunto local. Si se cambia el abono a tipos de atributo, el AU puede recibir todos los atributos en el abono original para mensajes presentes en el AM cuando se cambió el abono. El tratamiento de estos atributos no abonados es un asunto local. Igualmente cuando se abona un nuevo atributo, el AU puede no recibir dicho atributo para mensajes que estaban ya en el AM cuando tuvo lugar el abono.
12
Tipos de acciones
automáticas
generales
Los
tipos de acciones automáticas generales
son válidos
para todos los tipos de contenido de mensaje. Sin embargo, su efecto detallado
puede ser específico de un contenido y así la descripción de los procedimientos
que se presentan en esta Recomendación pueden requerir el complemento de las
Recomendaciones respectivas, por ejemplo el procedimiento específico del SMIP
para el
tipo de acción automática general
de retransmisión
automática que se describe en el
19.4
de la Recomendación X.420.
Otros
tipos de acción automática
, que son específicos del
contenido, pueden definirse en sus Recomendaciones respectivas.
Las
acciones automáticas
se presentan en el
6.5
, y se registran y eliminan utilizando la operación abstracta
registro en AM descrita en el
8.6
.
Se definen los siguientes tipos de
acciones automáticas
generales
:
a)retransmisión automática;
b)alerta automática.
La operación de las
acciones automáticas
puede llevarse
a cabo estableciendo una política de seguridad.
Los puntos siguientes contienen una breve descripción de cada
tipo de acción automática general
junto con su sintaxis
abstracta, mediante la macro
AUTO-ACCIóN
definida en el
6.5
.
12.1
Retransmisión automática
La
acción automática retransmisión automática
permite al
proveedor del servicio abstracto AM
retransmitir
automáticamente cualquier mensaje que haya sido entregado a la base de
información de mensajes almacenados. La definición exacta de retransmisión
depende del contenido, pero siempre implica el depósito de un nuevo mensaje que
incorpora el contenido entregado al servicio abstracto STRM.
El
tipo de acción automática retransmisión automática
permite que uno o más conjuntos de parámetros
retransmisión
automática
sean registrados en el AM, cada uno identificado por su
identificador de registro de retransmisión automática
. Cada
parámetro registro de retransmisión automática
especifica
los criterios que determinarán si se aplica o no a un mensaje entregado en
particular, y si es así, una copia de dicho mensaje se
retransmite automáticamente
utilizando la operación
abstracta de depósito de mensaje. Esto quiere decir, que si un mensaje
concuerda con más de un conjunto de criterios, el mensaje será
retransmitido automáticamente
tantas veces como conjuntos de
criterios hayan sido satisfechos por el mensaje.
El
parámetro registro de retransmisión automática
especifica si la inscripción principal (y cualesquiera de las inscripciones
vástagos asociadas) que corresponden al mensaje deben o no suprimirse después
de la
retransmisión automática
. Si cualquiera de los
parámetros sobre los que se actúa indica no-supresión (o si falla cualquiera de
los depósitos), la inscripción no se suprime.
auto-forward AUTO-ACTION REGISTRATION PARAMETER IS AutoForwardRegistrationParameter ::= id-act-auto-forward
AutoForwardRegistrationParameter ::= SET^{ filter[0]Filter OPTIONAL, auto-forward-arguments[1]AutoForwardArguments, delete-after-auto-forwarding[2]BOOLEAN DEFAULT FALSE, other-parameters[3]OCTET STRING OPTIONAL^}
AutoForwardArguments ::= SET^{ COMPONENTS OF PerMessageAutoForwardFields, per-recipient-fields[1]IMPLICIT SEQUENCE (1..ub-recipients) OF [1]PerRecipient-AutoForwardFields^}
PerMessageAutoForwardFields ::= SET^{ originator-nameOriginatorName, content-identifierContentIdentifier OPTIONAL, priorityPriority DEFAULT normal, per-message-indicatorsPerMessageIndicators DEFAULT {^}, deferred-delivery-time[0]IMPLICIT DeferredDeliveryTime OPTIONAL, extensions[2]IMPLICIT PerMessageSubmissionExtensions DEFAULT {^}^}
PerRecipientAutoForwardFields ::= SET^{ recipient-nameRecipientName, originator-report-request[0]IMPLICIT OriginatorReportRequest, explicit-conversion[1]IMPLICIT ExplicitConversion OPTIONAL, extentions[2]IMPLICIT PerRecipientMessageSubmissionExtensions DEFAULT {^}^}
Los parámetros del
parámetro registro de retransmisión
automática
tienen los siguientes significados:
1)
Filtro
(F): Es un conjunto de criterios que una
inscripción nueva que representa un mensaje entregado debe satisfacer para que
el proveedor del servicio abstracto AM pueda
retransmitirla
automáticamente
utilizando este conjunto de parámetros.
La ausencia de este parámetro indica que todas las inscripciones nuevas son
retransmitidas automáticamente
.
2)
Argumentos de retransmisión automática
(O): Es un
conjunto de argumentos registrados que han de utilizarse para cada operación
abstracta de depósito de mensajes (véase el
8.2.1.1.1
de la
Recomendación X.411). Cualquier argumento que no sea ni registrado ni
obligatorio, no mencionado específicamente más adelante, estará ausente en cada
depósito de mensaje.
Si los argumentos siguientes no son registrados o bien son registrados con
sus valores por defecto, los valores utilizados para cada operación abstracta
de depósito de mensaje son los de los correspondientes argumentos de entrega de
mensaje:
prioridad
,
prohibición implícita de
conversión
, y
prohibición de conversión con pérdida
.
Si los argumentos siguientes no son registrados o bien son registrados con
sus valores por defecto, su presencia como argumentos de depósito de mensaje
depende de la presencia de los argumentos de entrega de mensaje
correspondientes, transformándose sus valores cuando proceda:
testigo de mensaje
,
identificador de algoritmo
de confidencialidad de contenido
,
verificación de integridad
de contenido
,
verificación de autenticación de origen de
mensaje
, y
etiqueta de seguridad del mensaje
.
Ciertos argumentos de depósito de mensaje pueden no ser registrados. Estos
son:
petición de prueba de depósito
,
tipo de
información codificada originales
,
tipo de contenido
, y
contenido
.
3)
Supresión tras retransmisión automática
(F): Indica si
una inscripción debe ser o no suprimida una vez que el depósito se haya hecho
correctamente.
La ausencia de este parámetro indica que no se debe suprimir el mensaje.
4)
Otros parámetros
(F): no es necesario que este
parámetro que es específico al contenido esté presente. Cuando lo esté, la
información que contiene se utilizará durante el procedimiento de
retransmisión automática
.
Nota
- Así, por ejemplo, con la mensajería
interpersonal, este parámetro puede contener el
comentario de
retransmisión automática
que se devuelve en una notificación de no
recepción, un prefijo especificado por el usuario y una nota de portada que
acompaña al mensaje IP que es retransmitido automáticamente. Para una
descripción del uso de
comentarios de retransmisión
automática
, véase el
19.4
de la Recomendación X.420.
12.2
Alerta automática
La
acción automática alerta automática
permite al
proveedor del servicio abstracto AM
alertar
automáticamente al usuario que está detrás del usuario del servicio abstracto
AM acerca de la entrega de cualquier mensaje que haya sido entregado a la base
de información de mensajes almacenados. La
alerta automática
únicamente se efectuará para inscripciones de mensajes entregados.
El
tipo de acción automática alerta automática
permite
que uno o más conjuntos de parámetros
alerta automática
sean
registrados en el AM, cada uno identificado por su
identificador
de registro de alerta automática
. Cada
parámetro registro de
alerta automática
especifica criterios que determinan si se aplica o no a
un determinado mensaje entregado. Si un mensaje concuerda con el filtro de más
de un registro de alerta automática, se procesará el registro concordante que
tenga el identificador de registro de alerta automática más bajo, y si al menos
se ha alertado con éxito a una dirección (o al AU), no se procesa ningún otro
registro. Si no se puede alertar con éxito a ninguna de estas direcciones, se
procesará el registro de alerta automática con el identificador que siga al más
alto. Esto continúa así hasta que al menos una o más direcciones del registro
hayan sido alertadas correctamente o se haya agotado la lista de registros.
La
operación abstracta de alerta
sólo será invocada si
se considera que las direcciones alerta en el registro de alerta automática
tienen como miembro al AU (véase el 2) más abajo). Si esta operación abstracta
de alerta tiene éxito, no se alertará ninguna otra dirección contenida en el
registro de alerta automática.
Auto-alert AUTO-ACTION REGISTRATION PARAMETER IS AutoAlertRegistrationParameter ::= id-act-auto-alert
AutoAlertRegistrationParameter ::= SET^{ filter[0]Filter OPTIONAL, alert-addresses[1]SEQUENCE SIZE (1..ub-alert-addresses) OF AlertAddress OPTIONAL, requested-attributes[2]EntryInformationSelection OPTIONAL^}
Los parámetros del
parámetro registro de alerta
automática
tienen los siguientes significados:
1)
Filtro
(F): Es un conjunto de criterios que debe
satisfacer una inscripción nueva, que representa mensaje entregado, para que el
proveedor de servicios abstractos AM le
alerte
automáticamente
utilizando este conjunto de parámetros.
La ausencia de este parámetro indica que se realizará la
alerta automática
para todas las inscripciones de mensajes
entregadas.
2)
Direcciones de alerta
(F): Este argumento identifica
los tipos de servicio de
alerta
que han de invocarse junto
con cualquier información requerida para ganar acceso a un caso específico del
servicio de
alerta
, y cualquier otra información que
necesite ser transmitida durante esas
alertas
.
La ausencia de este argumento significa que la operación abstracta de alerta informa al usuario del servicio AM de la existencia de una condición de alerta, sea utilizando la operación abstracta de alerta (véase el 8.7 ), (que sólo es posible si existe ya una asociación abstracta entre el usuario del servicio abstracto AM y el proveedor del servicio abstracto AM) o llamando mediante una bandera a la operación abstracta de vinculación la próxima vez que el usuario del servicio abstracto AM establezca una asociación abstracta (véase el 7 ). Si está presente el parámetro atributos solicitados, se considerará que el usuario de servicio abstracto AM (AU) figura entre las direcciones que han de alertarse.
Algunos tipos de
alerta
se normalizarán en el plano
internacional, otros serán definidos por autoridades administrativas nacionales
y organizaciones privadas. Esto implica que varias autoridades distintas serán
responsables de la asignación de tipos de una manera que garantice que cada uno
es distinto de todos los demás asignados. Esto se logra identificando cada tipo
con un identificador de objeto en el momento de definir el tipo, y definiendo
el tipo de datos NSA.1 de la información auxiliar de direccionamiento.
El
calificativo de alerta
contiene cualquier otra
información que deba ser transmitida durante la
alerta
automática
. La ausencia de ese parámetro significa que no se transmitirá
ninguna información adicional al usuario del servicio abstracto AM.
AlertAddress ::= SEQUENCE^{ address EXTERNAL, alert-qualifier OCTET STRING OPTIONAL^}
3)
Atributos solicitados
(F): Indica que información de
las inscripciones seleccionadas debe incluirse en la alerta automática. Véase
el
8.1.4
.
La ausencia de este parámetro significa que únicamente el
identificador de registro de alerta
estará presente en el
argumento de alerta
.
13 Visión de conjunto
Esta sección describe los procedimientos para el AM y la realización de puertos. Contiene una descripción del consumo del servicio abstracto STRM en el 14 . La prestación del servicio abstracto AM se describe en el 15 . La realización de puertos bajo la forma de elementos de servicio se describe en el 16 .
La realización de las operaciones abstractas descritas en los 14 y 15 estará sujeta a las exigencias de la política de seguridad (si hay alguna en vigor) que se aplica a los servicios abstractos STRM y a los servicios abstractos AM.
14
Consumo del servicio abstracto de
transferencia de mensajes
Este punto especifica cómo un AM consumirá el servicio abstracto STRM que se define en el 8 de la Recomendación X.411. Se trata el consumo de los puertos de entrega, depósito y administración STRM.
14.1
Consumo de los servicios abstractos de puerto de
entrega
Este punto trata la realización de las operaciones abstractas entrega de mensaje y entrega de informe y la invocación de la operación abstracta control de entrega. El consumo AM de servicios abstractos de puerto de entrega presupone que existe una asociación abstracta entre el suministrador del puerto de entrega (el ATM) y el consumidor del puerto de entrega (el AM). La realización de las operaciones abstractas es secuencial, sin que tenga lugar un procesamiento paralelo. Los casos de error no se describen.
14.1.1
Realización de la operación abstracta de entrega de
mensajes
Cuando el AM recibe una operación abstracta de entrega de mensaje, del ATM, sigue los pasos siguientes:
1)Devuelve un resultado de entrega de mensaje al ATM para indicar que la entrega tuvo éxito. El resultado de entrega de mensaje contendrá información de prueba de entrega si el mensaje entregado contiene un argumento de petición de prueba de entrega. Esta prueba de entrega puede calcularse utilizando la clave secreta-AM-asunto; para más detalles véanse los 8.5.7 y 8.3.1.1.2.2 de la Recomendación X.411.
2)El paso siguiente consiste en examinar si hay algunas acciones automáticas activadas. Las acciones automáticas son, en parte, específicas del contenido, por lo que se describen también en Recomendaciones específicas del contenido. La descripción específica del contenido tiene que contener reglas sobre el orden en que se ejecutan las acciones automáticas. La ejecución de acciones automáticas puede dar como resultado alertas, presentaciones, la creación de nuevas inscripciones y la posible supresión del mensaje entregado o de otros mensajes en el AM. Véase el 12.1 .
a)Si mediante una operación abstracta de registro en el AM se registran
criterios de retransmisión automática, la nueva inscripción se hace concordar
los criterios especificados. La concordancia se busca secuencialmente para cada
conjunto especificado de criterios de selección. Para cada
`golpe'
, se
genera un nuevo mensaje que el AM deposita en el ATM utilizando la operación
abstracta de depósito de mensaje (véase el
15.2.1
).
Las reglas sobre la manera de construir el nuevo mensaje retransmitido son asimismo específicas del contenido y por tanto se describen en las respectivas Recomendaciones específicas del contenido. Otros sucesos específicos del contenido deben efectuarse también en esta etapa (por ejemplo, la supresión de bucles de mensajes retransmitidos automáticamente y la expedición de una notificación de no recepción como se describe para el SMIP en el 19.4 de la Recomendación X.420. En función de los valores del argumento de la operación abstracta de registro en el AM para retransmisión automática, puede retenerse en el AM una copia del mensaje entregado. Si fracasa la tentativa de retransmisión automática, se mantiene siempre una copia a fin de evitar la pérdida de los mensajes.
Nota
- El tratamiento de un resultado o error sobre la
base de tal depósito es un asunto local.
b)Si se han hecho registros automáticos de alertas a través de la operación
abstracta de registro en el AM, la nueva inscripción se hace concordar con el
filtro de cada registro especificado. La concordancia se busca secuencialmente
para cada registro. Si se encuentra un
`golpe'
, se hace una tentativa de
invocar una operación abstracta de alerta desde el AM al AU. Esto sólo puede
hacerse si hay una asociación abstracta existente entre el AM y el AU. Si no
existe ninguna asociación abstracta, puede que el AM disponga de un medio local
o no normalizado para invocar una alerta. Cuando se han hecho tentativas de
alertar todas las direcciones registradas para una primera concordancia del
parámetro de registro, y se ha tenido éxito al menos en una de las alertas, la
acción automática de alerta ha sido completada con éxito y no se procesará
ningún otro registro de alerta. Si no se encontró un trayecto para dar la
alerta, el AM pone la bandera de alerta, que se comunica al AU la próxima vez
que el AU inicia una asociación abstracta hacia el AM.
Nota
- Si el mensaje entregado se suprimió como
resultado de una acción de retransmisión automática en a), es evidente que no
se efectúa la alerta automática.
3)Sólo después de haberse dado los pasos mencionados se hace visible una nueva inscripción fuera del AM a través del puerto de extracción. Si el mensaje entregado se suprimió como resultado de una acción automática, todo número secuencial que se atribuyó en el paso 2) no será reutilizado (a fin de no entrar en conflicto con las ampliaciones del registro cronológico mencionado en normas de la ISO). El estado de la inscripción (de esa inscripción) se fija a nuevo.
14.1.1.1
Reglas de generación para atributos generales
Los atributos facultativos se generan únicamente si están realizados por el AM y el usuario está abonado a los mismos. Los atributos generados forman una nueva inscripción (en algunos casos una inscripción progenitora e inscripciones vástagos, véase el 6 ) en el AM.
Para las reglas sobre la manera de generar los atributos generales, véanse el cuadro 1/X.413 y el 11.3 . Obsérvese que para los atributos generales que están ausentes en el sobre de entrega correspondiente, se genera, en la inscripción, un atributo con un valor o por defecto.
14.1.2
Realización de la operación abstracta entrega de
informe
Cuando el AM recibe una operación abstracta de entrega de informe procedente del ATM, sigue los pasos siguientes:
1)Devuelve un resultado de entrega de informe al ATM para indicar que la entrega tuvo éxito. El resultado de entrega de informe no tiene parámetros. Para más detalles véase el 8.3.1.2.2 de la Recomendación X.411.
2)Seguidamente, si alguna de las acciones automáticas u otros procedimientos internos están activados, se ejecutan dichas acciones o procedimientos. Estos son específicos del contenido y se describen en las respectivas Recomendaciones específicas del contenido.
14.1.2.1
Reglas de generación para atributos generales
Pueden generarse atributos cuando se recibe un mensaje o cuando se realiza una operación abstracta en el AM, activada por una invocación del AU.
Se generan todos los atributos obligatorios, véase el cuadro 1/X.413. Los atributos opcionales sólo se generan si están realizados por el AM y el usuario se ha abonado a los mismos. Los atributos generados forman una nueva inscripción (en algunos casos una inscripción progenitora e inscripciones vástagos, véase el 6 ) en el AM. Como parte del proceso pueden producirse las siguientes clases de atributos generales:
a)atributos generales generados por el propio AM (por ejemplo, número secuencial);
b)atributos generales generados a partir de las componentes del sobre de entrega de informe. Para los componentes que no están presentes, pero para los cuales se definen valores por defecto, se genera un atributo general que contiene el valor por defecto.
Las reglas de generación para a) y b) se describen en el 14.1.1.1 . Las reglas de generación para los atributos de contenido específicos se describen en las Recomendaciones respectivas específicas del contenido, por ejemplo, los atributos específicos al SMIP se describen en el anexo C de la Recomendación X.420.
Para las reglas sobre la manera de generar atributos generales, véanse el cuadro 1/X.413 y el 11.3 . Obsérvese que para los atributos generales que están ausentes del sobre de entrega correspondiente, se genera en la inscripción un atributo con valor por defecto.
14.1.3
Invocación de la operación abstracta de control de
entrega
Si el AM desea detener temporalmente el envío de mensajes e informes por el STRM, o modificar la máxima longitud de contenido o la prioridad más baja de los mensajes emitidos por el ATM, sigue los siguientes pasos:
1)Invoca una operación abstracta de control de entrega, que contiene los parámetros a cambiar. Para más detalles véase el 8.3.1.3 de la Recomendación X.411.
2)Obtiene la devolución de un resultado cuando el servicio abstracto STRM ha aceptado los cambios. El resultado contiene información sobre si hay o no mensajes y/o informes en espera en el ATM, debido a las restricciones en vigor. Para más detalles, véase el 8.3.1.3.2 de la Recomendación X.411.
3)Cuando el AM es capaz de aceptar cualquier mensaje o sonda en espera debe, a su vez, invocar una nueva operación abstracta de control de entrega para mitigar las restricciones. Los efectos de una operación abstracta de control de entrega se anulan cuando una nueva operación abstracta de control de entrega modifica las restricciones o cuando se libera la asociación abstracta.
14.2
Consumo de servicios abstractos de puerto de
depósito
Este punto trata la invocación de las operaciones abstractas depósito de mensaje, depósito de sonda, y anulación de entrega diferida, y el consumo de la operación abstracta de control de depósito. El consumo del servicio abstracto AM por el de los servicios abstractos de puerto de depósito presupone que existe una asociación abstracta entre el suministrador del puerto de depósito (el ATM) y el consumidor del puerto de depósito (el AM). Las operaciones abstractas se realizan en orden secuencial, sin que tenga lugar un procesamiento paralelo. Los casos de error no se describen.
14.2.1
Invocación de la operación abstracta de depósito de
mensaje
La iniciación de una operación abstracta de depósito de mensaje puede provenir de una acción automática dentro del AM o por el hecho de que el AU invocó una operación abstracta de depósito de mensaje al AM. A fin de depositar el mensaje en el ATM, el AM sigue los siguientes pasos:
1)Si el argumento de depósito de mensaje no contiene la ampliación de petición de retransmisión (véase el 6.6 ), invoca una operación abstracta de depósito de mensaje, que contiene el mensaje a depositar y sus parámetros asociados. Para más detalles véase el 8.2.1.1 de la Recomendación X.411. En caso contrario, verifica que la inscripción es un mensaje entregado e incorpora información procedente de un asiento de mensaje entregado en la base de información de los mensajes almacenados, y, entonces, invoca la operación abstracta de entrega de mensaje con el nuevo concepto. La retransmisión de inscripciones que no son mensajes entregados será objeto de ulterior estudio.
Obsérvese que aunque esta petición de inscripción es genérica, no tiene necesariamente que tener sentido para todos los tipos de contenido. Cuando tiene sentido, el tipo de contenido de la inscripción del mensaje entregado referenciado debe ser apropiado para incorporación en el argumento del contenido.
2)Obtiene la devolución de un resultado de depósito de mensaje cuando el ATM ha aceptado el depósito. El resultado de depósito de mensaje contiene entre otras cosas información sobre la identificación de, y la hora de depósito para, el mensaje depositado. Para más detalles, véase el 8.2.1.1.2 de la Recomendación X.411.
3)Si la operación abstracta de depósito de mensaje fue desencadenada por una operación abstracta correspondiente de depósito de mensaje al AM, proveniente del AU, el resultado de la operación abstracta se devuelve al AU en forma de un resultado de depósito de mensaje expedido por el AM. Este comportamiento garantiza que el mensaje ha sido efectivamente aceptado por el ATM antes de devolver el resultado al AU.
4)Si el ATM no ha aceptado el depósito de mensaje debido a problemas tales como un número secuencial no válido o un tipo de contenido inapropiado, el AM generará un error de petición incoherente. Obsérvese que todos los errores generados por el ATM son retransmitidos a través del AU.
5)Si está en vigor una política de seguridad, entonces, a fin de garantizar que tal política de seguridad no va a ser violada durante el depósito de un mensaje, el AM verifica la etiqueta de seguridad del mensaje, comparándola con el contexto de seguridad. Si el depósito de mensaje está prohibido sea por la política de seguridad, sea temporalmente por restricciones de seguridad, se indicará un error de seguridad.
14.2.2
Invocación de la operación abstracta de depósito de
sonda
Una operación abstracta de depósito de sonda se inicia porque el AU invocó una operación abstracta de depósito de sonda hacia el AM. A fin de depositar la sonda para el ATM, el AM sigue los siguientes pasos:
1)Invoca una operación abstracta de depósito de sonda, que contiene la sonda a depositar y sus parámetros asociados. Para más detalles véase el 8.2.1.2.1 de la Recomendación X.411.
2)Obtiene la devolución de un resultado de depósito de sonda cuando el ATM ha aceptado el depósito. El resultado contiene entre otras cosas información sobre la identificación de la hora de depósito de la sonda depositada. Para más detalles véase el 8.2.1.2.2 de la Recomendación X.411.
3)El resultado de la operación abstracta se devuelve a AU en forma de un resultado de depósito de sonda expedido por el AM. Este comportamiento garantiza que la sonda ha sido efectivamente aceptada por el ATM antes de que se devuelva el resultado al AU.
4)Si se está aplicando una política de seguridad, para garantizar que no se incumple tal política de seguridad durante el depósito de la sonda, el AM verifica la etiqueta de seguridad de mensaje de la sonda con respecto al contexto de seguridad. Si el depósito de sonda está prohibido sea por la política de seguridad o temporalmente por restricciones de seguridad, se genera un error de depósito de sonda.
14.2.3
Invocación de la operación abstracta anulación
entrega diferida
Una operación abstracta anulación entrega diferida se inicia porque el AU invocó una operación abstracta de anulación entrega diferida hacia el AM. A fin de enviar la anulación al ATM, el AM sigue los pasos siguientes:
1)Invoca una operación abstracta de anulación entrega diferida, que contiene la anulación que ha de depositarse y sus parámetros asociados. Para más detalles véase el 8.2.1.3.1 de la Recomendación X.411.
2)Obtiene la devolución de un resultado cuando el ATM ha aceptado la anulación. El resultado devuelto está vacío como indicación de éxito.
3)El resultado de la operación abstracta se devuelve al AU en forma de un resultado de anulación entrega diferida expedido por el AM. Este comportamiento garantiza que la sonda ha sido efectivamente aceptada (o no) por el ATM antes de que se devuelva el resultado al AU.
14.2.4
Realización de la operación abstracta control de
depósito
Si el ATM desea impedir que el AM deposite temporalmente mensajes o sondas, o modificar la longitud máxima del contenido, o la prioridad más baja de mensajes provenientes del AM, invoca una operación abstracta de control de depósito (para más detalles véase el 8.2.1.4.1 de la Recomendación X.411) hacia el AM. El AM reacciona con los pasos siguientes:
1)Invoca una correspondiente operación abstracta de control de depósito del AM al AU.
2)Espera a que el AU devuelva un resultado de control de depósito que contiene información sobre la existencia de mensajes o sondas en espera en el AU, debido a las restricciones vigentes. Para más detalles véase el 8.2.1.4.2 de la Recomendación X.411.
3)El AM devuelve un resultado de control de depósito al ATM, que contiene información procedente del AU.
4)Cuando el ATM es capaz de aceptar de nuevo cualesquiera mensajes o sondas debe asimismo invocar una nueva operación abstracta de control de depósito para mitigar las restricciones. Los efectos de una operación abstracta de control de depósito se anulan cuando una nueva operación abstracta de control de depósito modifica las restricciones o cuando se libera la asociación abstracta. El AM invoca entonces una operación abstracta de control de depósito correspondiente hacia el AU y espera el resultado del control de depósito.
14.3
Consumo de los servicios abstractos de puerto
de administración
Este punto trata de la realización de operaciones abstractas de registro y cambio de credenciales. El consumo de servicios abstractos de puerto de administración presupone que existe una asociación abstracta entre el suministrador del puerto de administración (el ATM) y el consumidor del puerto de administración (el AM). Las operaciones abstractas se realizan en orden secuencial, sin que tenga lugar un procesamiento paralelo. Los casos de error no se describen.
El uso, por el AM, del puerto de administración, está sujeto a la política de seguridad en vigor.
14.3.1
Invocación de la operación abstracta de registro
Una operación abstracta de registro se inicia porque el AU ha invocado una operación abstracta de registro hacia el AM. Para enviar el registro al ATM, el AM sigue los siguientes pasos:
1)Invoca una operación abstracta de registro, que contiene los nuevos datos a registrar. Para más detalles véase el 8.4.1.1.1 de la Recomendación X.411.
2)Obtiene la devolución de un resultado cuando el ATM ha aceptado el registro. El resultado devuelto está vacío como una indicación de éxito.
3)El ámbito de los cambios permitidos, por el AU a través del AM, en los argumentos de la etiqueta de seguridad de usuario está confinado a la política de seguridad en vigor.
14.3.2
Invocación de la operación abstracta cambio de
credenciales
Se inicia una operación abstracta de cambio de credenciales porque el AU ha invocado una operación abstracta cambio de credenciales hacia el AM. A fin de retransmitir las nuevas credenciales desde el AU al ATM, el AM sigue los pasos siguientes:
1)Invoca una operación abstracta de cambio de credenciales en el ATM, que contiene las nuevas credenciales a registrar. Para más detalles véase el 8.4.1.2.1 de la Recomendación X.411.
2)Obtiene la devolución de un resultado de cambio de credenciales cuando el ATM ha aceptado el cambio y almacena las nuevas credenciales. El resultado de cambio de credenciales o de un error proveniente del ATM se retransmite hacia el AU, y está vacío como una indicación de éxito.
14.3.3
Realización de la operación abstracta de cambio
de credenciales
Cuando el AM recibe una operación abstracta de cambio de credenciales y sus argumentos asociados, del ATM, sigue los pasos siguientes:
1)Establece que la información de argumento es válida para una operación abstracta de cambio de credenciales. Para más detalles, véase el 8.4.1.2 de la Recomendación X.411.
2)Verifica si existe una asociación abstracta entre el AM y el AU. Si no existe una asociación abstracta entre el AM y el AU, el ATM es informado por una indicación de error de que el cambio de credenciales no puede tener lugar en ese momento, y no se sigue adelante.
3)Si existe la asociación abstracta entre el AM y AU, el AM invoca hacia el AU una operación abstracta de cambio de credenciales.
4)Si el AU devuelve un resultado de cambio de credenciales vacío, que indica éxito, el AM devuelve al ATM un resultado correspondiente de cambio de credenciales y almacena las credenciales. Si el AU devuelve una indicación de error, esta se retransmite al ATM; para indicar el error. Obsérvese que el AM nunca devuelve una indicación de éxito al ATM antes de haber recibido el resultado correspondiente de retorno del AU.
15
Suministro del servicio abstracto
de almacenamiento de mensajes
Este punto especifica cómo un AM suministra el servicio abstracto de AM. Se trata el suministro de puertos de extracción, depósito indirecto, y administración.
15.1
Suministro de servicios abstractos de puerto
de extracción
Este punto trata del suministro de las operaciones abstractas de resumir, listado, captura, supresión, registro en el AM y alerta. El suministro del servicio abstracto AM de los servicios abstractos de puerto de extracción presupone que existe una asociación abstracta entre el suministrador del puerto de extracción (el AM) y el consumidor del puerto de extracción (el AU). Las operaciones abstractas se realizan en orden secuencial, sin que tenga lugar un procesamiento paralelo. No se describen todos los casos de errores.
15.1.1
Realización de la operación abstracta de resumir
Cuando el AM recibe una operación abstracta de resumir del AU, sigue los siguientes pasos:
1)Establece qué base de información es direccionada por la operación abstracta de resumir.
2)Verifica si hay inscripciones en la base de información. Si está vacía, se devuelve un resultado de resumir con una longitud cero y no se sigue adelante.
3)Verifica que los atributos generales de argumento y cualesquiera atributos específicos de contenido reconocidos por el AM son válidos para una operación abstracta de resumir. Para más detalles véase el 8.2.1 .
4)Acumula cómputos de conformidad con los atributos generales de argumento suministrados y cualesquiera atributos específicos de contenido reconocidos por el AM.
5)Devuelve al AU el resultado de resumir. Para más detalles véase el 8.2.2 .
6)Si se está aplicando una política de seguridad, a fin de garantizar que no se incumple esta política durante la operación abstracta de resumir, el AM verifica la clasificación de seguridad de la etiqueta de seguridad con respecto al contenido de seguridad. Si la política de seguridad prohíbe el resumir, deberá abandonarse tal operación abstracta e indicarse un error de seguridad.
15.1.2
Realización de la operación abstracta de listado
Cuando el AM recibe una operación abstracta de listado del AU, sigue los pasos siguientes:
1)Establece la base de información que resulta direccionada por la operación abstracta de listado.
2)Verifica que los atributos generales de argumento suministrados y cualesquiera atributos específicos de contenido reconocidos por el AM son válidos para una operación abstracta de listado. Para más detalles véase el 8.3.1 .
3)Identifica cero o varias inscripciones como solicitadas en el argumento de la operación abstracta, hasta cualquier límite especificado. Las inscripciones vástagos de una inscripción progenitora no se tienen en cuenta, a menos que hayan sido seleccionadas explícitamente en el argumento.
4)Si se ha especificado un conjunto de atributos generales solicitados como argumentos en la operación abstracta, se devuelven estos atributos generales, si están presentes, al AU, para cada inscripción seleccionada. Si no se ha hecho ninguna petición, se devuelven los valores por defecto de la operación abstracta de listado tal y como fueron especificados en una operación abstracta anterior de registro en el AM, si están presentes. Para más detalles véase el 8.3.2 . El estado de la inscripción de cada mensaje seleccionado se fija a listado.
5)Si se está aplicando una política de seguridad, a fin de garantizar que no se viola dicha política de seguridad durante la operación abstracta de listado, el AM verifica la etiqueta de seguridad del mensaje con respecto al contexto de seguridad. Si la operación de listado está prohibida, ya sea por la política de seguridad, o como consecuencia de restricciones provisionales de seguridad, se abandonará la operación abstracta de listado y se indicará un error de seguridad.
15.1.3
Realización de la operación abstracta de captura
Cuando el AM recibe una operación abstracta de captura del AU, sigue los pasos siguientes:
1)Establece qué base de información resulta direccionada por la operación abstracta de captura.
2)Verifica que los atributos generales de argumento suministrados son válidos para una operación abstracta de captura. Para más detalles véase el 8.4.1 .
3)Identifica cero o más inscripciones como solicitadas en el argumento de la operación abstracta, hasta cualquier límite especificado. Se excluyen las inscripciones vástagos de una inscripción progenitora, a menos que hayan sido seleccionadas expresamente en el argumento.
4)Si se ha especificado un conjunto de atributos generales como argumentos de una operación abstracta, se devuelven estos atributos generales, si están presentes, al AU, para la primera inscripción seleccionada. Si no se ha hecho ninguna petición, se devuelven los valores por defecto de la operación abstracta de captura, como se especifica en la operación abstracta anterior de registro en el AM, si están presentes. Si se encuentran varias inscripciones que satisfacen el criterio de búsqueda, se devuelven los números secuenciales para los asientos segundo y siguientes, en orden creciente. Si había más inscripciones concordantes que las especificadas en el límite, se devuelve también el número secuencial siguiente que rebasa el límite. Para más detalles véase el 8.4.2 .
5)Si se está aplicando una política de seguridad, entonces garantizar que tal política de seguridad no será violada durante la operación abstracta de captura, el AM verifica la etiqueta de seguridad del mensaje con respecto al contexto de seguridad. Si la operación abstracta de captura está prohibida por la política de seguridad, o por restricciones temporales de seguridad, deberá abandonarse la operación abstracta de captura e indicarse un error de seguridad.
15.1.4
Realización de la operación abstracta de
supresión
Cuando el AM recibe una operación abstracta de supresión, del AU, sigue los siguientes pasos:
1)Establece qué base de información resulta direccionada por la operación abstracta de supresión.
2)Verifica que los argumentos suministrados son válidos para una operación abstracta de supresión. Para más detalles véase el 8.5.1 .
3)Identifica la inscripción o lista de inscripciones solicitadas en el argumento de la operación abstracta.
4)Si cualquiera de las inscripciones tiene restricciones a la supresión véase el 8.5 , no se efectuará ninguna de las supresiones. En otro caso se efectúan todas las supresiones y se devuelve un resultado de supresión vacío al AU como indicación de éxito.
15.1.5
Realización de la operación abstracta de registro en
el AM
Cuando el AM recibe del AU una operación abstracta de registro en el AM sigue los pasos siguientes:
1)Verifica que los argumentos suministrados son válidos para una operación abstracta de registro en el AM. Para más detalles véase el 8.6.1 .
2)Reemplaza cualesquiera parámetros antiguos por los correspondientes parámetros nuevos. Las acciones automáticas afectan a las transacciones, tales como entregas de mensaje y entregas de informe, que se producen después de la iniciación o supresión de peticiones de acción automática, sin que haya procesamiento de inscripciones que ya residen en el AM en ese instante.
3)Devuelve un resultado de registro en el AM vacío al AU, para indicar que la operación abstracta ha sido realizada con éxito.
4)Si se está aplicando una política de seguridad, la operación abstracta de registro en el AM estará sujeta a dicha política. Algunas políticas de seguridad pueden solamente permitir que las etiquetas de seguridad de usuario se cambien si se emplea un enlace seguro. Pueden preverse otros medios locales para cambiar las etiquetas de seguridad de usuario de una manera segura.
15.1.6
Invocación de la operación abstracta de alerta
La invocación de la operación abstracta de alerta es el resultado del consumo del servicio abstracto de puerto de entrega (véase el 14.1.1 ).
Si la acción automática de alerta automática es iniciada por el AU, mediante una operación abstracta de registro en el AM, el servicio abstracto AM sigue los pasos siguientes:
1)Verifica si existe una asociación abstracta. En caso contrario, el AM no establecerá nunca una asociación abstracta, y no podrá invocarse una operación abstracta de alerta.
2)Si existe una operación abstracta, el AM invoca una operación abstracta que contiene la información de argumento pertinente (para más detalles véase el 8.7.1 ) y espera a que el AU le devuelva un resultado de alerta vacío como indicación de éxito.
3)Si no existe una asociación abstracta, existe la posibilidad de utilizar un protocolo no normalizado para informar al usuario. La señal de alerta en este caso puede darse en el terminal de usuario, pero, alternativamente, se puede dar por teléfono, por un indicador acústico, o por cualquier equipo terminal adecuado asociado con el usuario. Este último método puede utilizarse también en casos en que no se haya realizado la operación abstracta de alerta.
4)Si se está aplicando una política de seguridad, para garantizar que tal política no será violada durante la alerta, el AM verifica la etiqueta de seguridad de mensaje con respecto al contexto de seguridad. Si la operación abstracta de alerta está prohibida por la política de seguridad o por restricciones temporales de seguridad, la acción será definida por la política de seguridad en vigor.
15.2
Suministro de los servicios abstractos de puerto
de depósito indirecto
Este punto se refiere a la realización de las operaciones abstractas de depósito de mensaje, depósito de sonda y anulación de entrega diferida, y a la invocación de la operación abstracta de control de depósito. El suministro del servicio abstracto AM de los servicios abstractos de puerto de depósito indirecto presupone que existe una asociación abstracta entre el suministrador del puerto de depósito indirecto (el AM) y el consumidor del puerto de depósito indirecto (el AU). Las operaciones abstractas se realizan en orden secuencial, sin que tenga lugar un procesamiento paralelo. No se describen todos los casos de error.
15.2.1
Realización de la operación abstracta de depósito de
mensaje
Cuando el AM recibe una operación abstracta de depósito de mensaje y sus argumentos asociados, del AU, sigue los siguientes pasos:
1)Establece que la información de argumento es válida para una operación abstracta de depósito de mensaje; para más detalles véase el 8.2.1.1.1 de la Recomendación X.411.
2)Verifica los argumentos que han de establecerse si el contenido del mensaje fue suministrado por el AU, o si tiene que ser insertado por el AM (es decir, si está presente la ampliación de petición de retransmisión). En este último caso, si la inscripción es una inscripción de mensaje entregado, se inserta el mensaje correspondiente y se suprimen los argumentos relacionados con el AM. La retransmisión de inscripciones que no son mensajes entregados será objeto de ulterior estudio.
3)Verifica si existe ya una asociación abstracta entre el AM y el ATM. En caso contrario, el AM inicia tal asociación abstracta. Si no puede establecerse una asociación abstracta, se informa al AU, por una indicación de error, de que el depósito no tiene lugar en este momento, y no se sigue adelante.
4)Si existe la asociación abstracta entre el AM y el ATM, el AM invoca una operación abstracta de depósito de mensaje hacia el ATM, después de las eventuales modificaciones que se mencionan en el paso 2).
5)Si el ATM devuelve un resultado de depósito de mensaje (para más detalles véase el 8.2.1.1.2 de la Recomendación X.411), que indica éxito, el AM devuelve al AU un resultado correspondiente de depósito de mensaje que indica éxito. Obsérvese que el AM nunca devuelve una indicación de éxito al AU hasta haber recibido el correspondiente resultado de retorno del ATM. Esto tiene por objeto asegurar un servicio coherente desde el punto de vista del usuario, es decir, que el depósito entraña siempre que el ATM ha asumido la responsabilidad del mensaje, cuando el resultado regresa.
6)El AM puede elegir entre terminar la asociación abstracta con el ATM después de un cierto periodo de inactividad, o cuando el AU termina su asociación abstracta correspondiente con el AM.
15.2.2
Realización de la operación abstracta depósito de
sonda
Cuando el AM recibe una operación abstracta de depósito de sonda y sus argumentos asociados, del AU, sigue los pasos siguientes:
1)Establece que la información de argumento es válida para una operación abstracta de depósito de sonda. Para más detalles véase el 8.2.1.2.1 de la Recomendación X.411.
2)Verifica si ya existe una relación abstracta entre el AM y el ATM. En caso contrario, el AM inicia tal asociación abstracta. Si no puede establecerse una asociación abstracta, el AU es informado, mediante una indicación de error, de que el depósito no puede tener lugar en ese momento, y no se sigue adelante.
3)Si existe la asociación abstracta entre el AM y el ATM, el AM invoca una operación abstracta de depósito de sonda hacia el ATM.
4)Si el ATM devuelve un resultado de depósito de sonda (para más detalles véase el 8.2.1.2.2 de la Recomendación X.411), que indica éxito, el AM devuelve al AU un resultado correspondiente de depósito de sonda que indica éxito. Obsérvese que el AM nunca devuelve una indicación de éxito al AU antes de haber recibido el resultado correspondiente de retorno del ATM. Esto tiene por objeto asegurar un servicio coherente desde el punto de vista del usuario, es decir, que un depósito siempre entraña que el STRM ha asumido la responsabilidad de la sonda cuando el resultado regresa.
5)El AM puede elegir entre terminar la asociación abstracta con el ATM después de un cierto periodo de inactividad, o cuando el AU termina su asociación abstracta correspondiente con el AM.
15.2.3
Realización de la operación abstracta anulación de
entrega diferida
Cuando el AM recibe del AU una operación abstracta anulación de entrega diferida y sus argumentos asociados, sigue los pasos siguientes:
1)Establece que la información de argumento es válida para una operación abstracta anulación de entrega diferida. Para más detalles véase el 8.2.1.3.1 de la Recomendación X.411.
2)Verifica si existe una asociación abstracta entre el AM y el ATM. Si no, el AM inicia tal asociación abstracta. Si no puede establecerse una asociación abstracta el AU es informado por una indicación de error de que la operación de anulación de entrega diferida no puede realizarse en ese momento y dejan de seguirse los demás pasos.
3)Si existe la asociación abstracta entre el AM y el ATM, el AM invoca una operación abstracta anulación de entrega diferida hacia el ATM.
4)Si el ATM devuelve un resultado de anulación de entrega diferida (para más detalles véase el 8.2.1.3.2 de la Recomendación X.411), que indica éxito, el AM devuelve al AU un resultado correspondiente de anulación de entrega diferida que indica éxito. Obsérvese que el AM nunca devuelve una indicación de éxito al AU antes de haber recibido el resultado correspondiente de retorno del ATM. Esto tiene por objeto asegurar un servicio coherente desde el punto de vista del usuario, es decir, que un depósito entraña siempre que el STM ha asumido la responsabilidad de la sonda, cuando el resultado regresa.
5)El AM puede elegir entre terminar la asociación abstracta con el ATM después de un cierto periodo de inactividad, o cuando el AU termina su asociación abstracta correspondiente con el AM.
15.2.4
Invocación de la operación abstracta de control de
depósito
Si el AM recibe del ATM una operación abstracta de control de depósito, o si el AM por algún motivo interno, desea detener temporalmente el depósito de mensajes o sondas por el AU, o modificar la longitud máxima o la prioridad más baja de los mensajes procedentes del AU, el AM sigue los pasos siguientes:
1)Invoca una operación abstracta de control de depósito hacia el AU. Para más detalles véase el 8.2.1.4.1 de la Recomendación X.411.
2)Espera un resultado de control de depósito del AU (para más detalles véase el 8.2.1.4.2 de la Recomendación X.411), en el que se confirma la aceptación de la operación abstracta de control de depósito.
3)Si la operación abstracta de control de depósito había sido desencadenada por una operación abstracta correspondiente, del ATM al AM, el resultado de control de depósito procedente del AU se pasa del AM al ATM, y el AM espera a que el AU le devuelva el resultado de control de depósito.
15.3
Suministro de los servicios abstractos de puerto
de administración
Este punto trata la realización de operaciones abstractas de registro y cambio de credenciales. El suministro del servicio abstracto AM de los servicios abstractos de puerto de administración presupone que existe una asociación abstracta entre el suministrador del puerto de depósito indirecto (AM) y el consumidor del puerto de depósito indirecto (AU). Las operaciones abstractas se realizan en orden secuencial, sin que tenga lugar un procesamiento paralelo. No se describen todos los casos de error.
15.3.1
Realización de la operación abstracta de
registro
Cuando el AM recibe del AU una operación abstracta de registro y sus argumentos asociados, sigue los pasos siguientes:
1)Establece que la información de argumento es válida para una operación abstracta de registro. Para más detalles véase el 8.4.1.1.1 de la Recomendación X.411.
2)Verifica si ya existe una asociación abstracta entre el AM y el ATM. En caso contrario, el AM inicia tal asociación abstracta. Si no puede establecerse una asociación abstracta, el AU es informado por una indicación de error de que el depósito no puede tener lugar en este momento y no se sigue adelante.
3)Si existe la asociación abstracta entre el AM y el ATN, el AM invoca una operación abstracta de registro, hacia el ATM.
4)Si el ATM devuelve un resultado de registro (para más detalles véase el 8.4.1.1.2 de la Recomendación X.411) que indica éxito, el AM devuelve al AU el resultado correspondiente de registro que indica éxito. Obsérvese que el AM nunca devuelve al AU una indicación de éxito antes de haber recibido el resultado correspondiente devuelto por el ATM. Esto tiene por objeto asegurar un servicio coherente desde el punto de vista del usuario, es decir, que un depósito entraña siempre que el STRM ha asumido la responsabilidad del registro cuando regresa el resultado.
5)El AM puede elegir entre terminar la asociación abstracta con el ATM después de un cierto periodo de inactividad, o cuando el AU termina su asociación abstracta correspondiente con el AM.
6)El ámbito de los cambios que el AU está autorizado a introducir en las etiquetas de seguridad de usuario estará circunscrito por la política de seguridad en vigor. Algunas políticas de seguridad pueden permitir solamente que se cambien la etiquetas de seguridad de usuario de esta manera si se emplea un enlace seguro. Pueden preverse otros medios locales para cambiar las etiquetas de seguridad de usuario de una manera segura.
15.3.2
Invocación de la operación abstracta de cambio
de credenciales
Se inicia una operación abstracta de cambio de credenciales porque el ATM invocó una operación abstracta de cambio de credenciales, hacia el AM. A fin de retransmitir las credenciales nuevas desde el ATM al AU, el AM sigue los pasos siguientes:
1)Establece que la información de argumentos es válida para una operación abstracta de cambio de credenciales. Para más detalles véase el 8.4.1.2 de la Recomendación X.411. Si las credenciales antiguas son incorrectas y las credenciales nuevas no son aceptables, se devuelve una indicación de error, y no se sigue adelante.
2)Invoca una operación abstracta de cambio de credenciales sobre el AU, la cual contiene las nuevas credenciales a registrar. Para más detalles véase el 8.4.1.2 de la Recomendación X.411.
3)Obtiene en retorno un resultado de cambio de credenciales cuando el AU ha aceptado el cambio y almacena las nuevas credenciales. El resultado de cambio de credenciales, o un error resultante, proveniente del AU, se retransmiten al ATM.
15.3.3
Realización de la operación abstracta de cambio
de credenciales
Cuando el AM recibe una operación abstracta de cambio de credenciales y sus argumentos asociados desde el AU, sigue los pasos siguientes:
1)Establece que la información de argumento es válida para una operación abstracta de cambio de credenciales. Para más detalles, véase el 8.4.1.2 de la Recomendación X.411.
2)Verifica si ya existe una asociación abstracta entre el AM y el ATM. Si no existe, el AM inicia tal asociación abstracta. Si no puede establecerse una asociación abstracta, el AU es informado por una indicación de error de que el depósito no tiene lugar en ese momento, y dejan de efectuarse los pasos siguientes.
3)Si existe la asociación abstracta entre el AM y el ATM, el AM invoca una operación abstracta de cambio de credenciales hacia el ATM.
4)Si el ATM devuelve un resultado de cambio de credenciales, que indica éxito, el AM devuelve un resultado correspondiente de cambio de credenciales que indica éxito al AU, y almacena las credenciales. Si el ATM devuelve un error, este se retransmite hacia el AU para indicar ese error. Obsérvese que el AM nunca devuelve una indicación de éxito al AU antes de haber recibido la devolución del resultado correspondiente del ATM.
5)El AM puede elegir entre terminar la asociación abstracta con el ATM después de cierto periodo de inactividad, o cuando el AU termina su operación abstracta correspondiente con el AM.
16
Realización de
puertos
Este punto describe cómo se proporcionan los puertos de extracción, depósito y administración del servicio abstracto AM. Para una descripción de la forma en que el servicio abstracto STRM proporciona los puertos de entrega, depósito y administración, véase el 8 de la Recomendación X.411.
16.1
Puerto de extracción
Los servicios abstractos de puerto de extracción se realizan mediante una correspondencia biunívoca entre operaciones abstractas y operaciones reales en el elemento de servicio de extracción de mensajes (ESEM) descrito en la Recomendación X.419.
16.2
Puerto de depósito indirecto
Los servicios abstractos de puerto de depósito indirecto se realizan mediante una correspondencia biunívoca entre operaciones abstractas y operaciones reales en el elemento de servicio de depósito de mensajes (ESDM) que se describe en la Recomendación X.419.
16.3
Puerto de administración
Los servicios abstractos de puerto de administración se realizan mediante una correspondencia biunívoca entre operaciones abstractas y operaciones reales en el elemento de servicio de administración de mensaje (ESAM) que se describe en la Recomendación X.419.
ANEXO A (a la Recomendación X.413)
Asignación formal de
identificadores de objeto
Este anexo es parte integrante de esta
Recomendación.
Todos los identificadores de objeto asignados por esta Recomendación son asignados formalmente en el presente anexo utilizando la NSA.1. Los valores especificados se citan en los módulos NSA.1 de los anexos siguientes.
Este anexo es definitivo para todos los valores salvo para los módulos NSA.1 y para toda la materia relativa a esta Recomendación. Las asignaciones definitivas para los valores primeramente mencionados se presentan en los módulos propiamente dichos. La asignación para los segundos es fija. Otras referencias a los valores asignados a los módulos figuran en cláusulas IMPORT.
MSObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) object-identifiers(0)^} DEFINITIONS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS ID, id-ms FROM MHSObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) arch(5) modules(0) object-identifiers(0)^};
--
Categorías
id-mod --
modules
-- ID ::= {^id-ms 0^}
id-ot --
objects
-- ID ::= {^id-ms 1^}
id-pt --
port types
-- ID ::= {^id-ms 2^}
id-att --
attribute types
-- ID ::= {^id-ms 3^}
id-act --
auto-action types
-- ID ::= {^id-ms
4^}
--
Módulos
id-mod-object-identifiers
ID ::= {^id-mod 0^} --
not
definitive
id-mod-abstract-service ID ::= {^id-mod 1^} --
not
definitive
id-mod-attribute-types ID ::= {^id-mod 2^} --
not
definitive
id-mod-action-types ID ::= {^id-mod 3^} --
not
definitive
id-mod-upper-bounds ID ::= {^id-mod 4^} --
not
definitive
--
Objetos
id-ot-ms ID ::= {^id-ot 0^} id-ot-ms-user ID ::= {^id-ot 1^}
--
Tipos de puerto
id-pt-retrieval ID ::= {^id-pt 0^}
--
Tipos de atributo
id-att-child-sequence-numbers ID ::= {^id-att 0^} id-att-content ID ::= {^id-att 1^} id-att-content-confidentiality-algorithm-identifier ID ::= {^id-att 2^} id-att-content-correlator ID ::= {^id-att 3^} id-att-content-identifier ID ::= {^id-att 4^} id-att-content-integrity-check ID ::= {^id-att 5^} id-att-content-length ID ::= {^id-att 6^} id-att-content-returned ID ::= {^id-att 7^} id-att-content-type ID ::= {^id-att 8^} id-att-conversion-with-loss-prohibited ID ::= {^id-att 9^} id-att-converted-EITs ID ::= {^id-att 10^} id-att-creation-time ID ::= {^id-att 11^} id-att-delivered-EITs ID ::= {^id-att 12^} id-att-delivery-flags ID ::= {^id-att 13^} id-att-dl-expansion-history ID ::= {^id-att 14^} id-att-entry-status ID ::= {^id-att 15^} id-att-entry-type ID ::= {^id-att 16^} id-att-intended-recipient-name ID ::= {^id-att 17^} id-att-message-delivery-envelope ID ::= {^id-att 18^} id-att-message-delivery-identifier ID ::= {^id-att 19^} id-att-message-delivery-time ID ::= {^id-att 20^} id-att-message-origin-authentication-check ID ::= {^id-att 21^} id-att-message-security-label ID ::= {^id-att 22^} id-att-message-submission-time ID ::= {^id-att 23^} id-att-message-token ID ::= {^id-att 24^} id-att-original-EITs ID ::= {^id-att 25^} id-att-originator-certificate ID ::= {^id-att 26^} id-att-originator-name ID ::= {^id-att 27^} id-att-other-recipient-names ID ::= {^id-att 28^} id-att-parent-sequence-number ID ::= {^id-att 29^} id-att-per-recipient-report-delivery-fields ID ::= {^id-att 30^} id-att-priority ID ::= {^id-att 31^} id-att-priority-of-delivery-request ID ::= {^id-att 32^} id-att-redirection-history ID ::= {^id-att 33^} id-att-report-delivery-envelope, ID ::= {^id-att 34^} id-att-reporting-DL-name ID ::= {^id-att 35^} id-att-reporting-MTA-certificate ID ::= {^id-att 36^} id-att-report-origin-authentication-check ID ::= {^id-att 37^} id-att-security-classification ID ::= {^id-att 38^} id-att-sequence-number ID ::= {^id-att 39^} id-att-subject-submission-identifier ID ::= {^id-att 40^} id-att-this-recipient-name ID ::= {^id-att 41^}
--
Tipos de acciones automáticas
id-act-auto-forward ID ::= {^id-act 0^} id-act-auto-alert ID ::= {^id-act 1^}
END --
de Identificadores de objeto MSI
ANEXO B (a la Recomendación X.413)
Definición formal del
servicio abstracto de almacenamiento de mensajes
Este anexo es parte
integrante de esta Recomendación.
Este anexo, que es un suplemento a la sección 2, define formalmente el servicio abstracto de almacenamiento de mensajes. Emplea la NSA.1 y las macro OBJECT, PORT, ABSTRACT-BIND, ABSTRACT-UNBIND, ABSTRACT-OPERATION, y ABSTRACT-ERROR de la Recomendación X.407.
Nota
- La utilización de las macros ABSTRACT-BIND,
ABSTRACT-UNBIND, ABSTRACT-OPERATION, y ABSTRACT-ERROR que se derivan de las
macros BIND, UNBIND, OPERATION y ERROR del servicio de operaciones a distancia
(SOD) no implica que las operaciones abstractas y errores abstractos sean
invocados e informados a través de la frontera entre sistemas abiertos en cada
caso. Sin embargo, frecuentemente se hará esto. Precisamente la manera de
realizar esto es el tema de la Recomendación X.419.
MSAbstractService {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) abstract-service(1)^} DEFINITIONS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Macros de servicios abstractos
ABSTRACT-BIND, ABSTRACT-ERROR, ABSTRACT-OPERATION, ABSTRACT-UNBIND, OBJECT, PORT FROM AbstractServiceNotation {^joint-iso-ccitt mhs-motis(6) asdc(2) modules(0) notation(1)^}
--
Puertos AM
administration, delivery, submission,
--
Macro STM
EXTENSION,
--
Macros de servicios abstractos
ContentLength, ContentType, Credentials, InitiatorCredentials, ORAddressAndOrDirectoryName, ResponderCredentials, SecurityContext, SecurityError, SecurityLabel FROM MTSAbstractService {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)^}
--
Objetos AM
id-ot-ms, id-ot-ms-user, id-pt-retrieval FROM MSObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) object-identifiers(0)^}
--
Cota superior del servicio abstracto AM
ub-attributes-supported, ub-attribute-values, ub-auto-actions, ub-auto-registrations, ub-default-registrations, ub-error-reasons, ub-information-bases, ub-messages, ub-nested-filters, ub-per-auto-action, ub-per-entry, ub-summaries FROM MSUpperBounds {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) upper-bounds(4)^}
--
Cota superior del servicio abstracto STRM
ub-content-types, ub-encoded-information-types, ub-labels-and-redirections FROM MTSUpperBounds {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0) upper-bounds(3)^};
--
Objetos abstractos AM
MS OBJECT PORTS {^retrieval[S], indirectSubmission[S], administration[S], delivery[C], submission[C], administration[C]^} ::= id-ot-ms
msUser OBJECT PORTS {^retrieval[C], indirectSubmission[C], administration[C]^} ::= id-ot-ms-user
--
Tipos de puerto
indirectSubmission PORT ::= submission
retrieval PORT CONSUMER INVOKES^{ Summarize, List, Fetch, Delete, Register-MS^} SUPPLIER INVOKES^{ Alert^} ::= id-pt-retrieval
--
Macros
AUTO-ACTION MACRO ::=
BEGIN
TYPE NOTATION ::= Registration
VALUE NOTATION ::= value (VALUE
OBJECT IDENTIFIER)
Registration ::=
"REGISTRATION PARAMETER IS"
type
END
--
Tipos de datos comunes relacionados con el modelo de
información
InformationBase ::= INTEGER^{ stored-messages (0), inlog (1), outlog (2)^} (0.^.ub-information-bases)
SequenceNumber ::= INTEGER (0.^.ub-messages)
CreationTime ::= UTCTime
Attribute ::= SEQUENCE^{
type AttributeType,
values SEQUENCE SIZE (1.^.ub-attribute-values) OF ANY --
DEFINED BY TYPE
--^}
AttributeType ::= OBJECT IDENTIFIER
AutoActionRegistration ::= SEQUENCE^{ type AutoActionType, registration-identifier [0] INTEGER (1.^.ub-per-auto-action) DEFAULT 1, registration-parameter [1] ANY DEFINED BY type^}
AutoActionType ::= OBJECT IDENTIFIER
EntryStatus ::= INTEGER^{ new (0), listed (1), processed (2)^}
--
Vinculación abstracta
MSBind ::= ABSTRACT-BIND TO {^indirectSubmission[S], retrieval[S], administration[S]^} BIND ARGUMENT MSBindArgument RESULT MSBindResult BIND-ERROR MSBindError
MSUnbind ::= ABSTRACT-UNBIND FROM {^indirectSubmission[S], retrieval[S], administration[S]^}
MSBindArgument ::= SET^{
initiator-name ORAddressAndOrDirectoryName,
initiator-credentials [2] InitiatorCredentials,
security-context [3] IMPLICIT SecurityContext OPTIONAL,
fetch-restrictions [4] Restrictions OPTIONAL --
por defecto: ninguno
--,
ms-configuration-request [5] BOOLEAN DEFAULT FALSE,^}
Restrictions ::= SET^{
allowed-content-types [0] SET SIZE (1.^.ub-content-types) OF OBJECT IDENTIFIER
[0] OPTIONAL
--
default is no restriction
--,
allowed-EITs [1]
MS-EITs
OPTIONAL --
por defecto: sin restricción
--,
maximum-content-length [2] ContentLength OPTIONAL --
por defecto: sin restricción
--^}
MS-EITs ::= SET SIZE (1.^.ub-encoded-information-types) OF MS-EIT
MS-EIT ::= OBJECT IDENTIFIER
MSBindResult ::= SET^{ responder-credentials [2] ResponderCredentials, available-auto-actions [3] SET SIZE (1.^.ub-auto-actions) OF AutoActionType OPTIONAL, available-attribute-types [4] SET SIZE (1.^.ub-attributes-supported) OF AttributeType [0] OPTIONAL, alert-indication [5] BOOLEAN DEFAULT FALSE, content-types-supported [6] SET SIZE (1.^.ub-content-types) OF OBJECT IDENTIFIER [0] OPTIONAL^}
MSBindError ::= ENUMERATED^{ authentication-error (0), unacceptable-security-context (1), unable-to-establish-association (2)^}
--
Tipos de datos comunes para operaciones abstractas
Range ::= CHOICE^{ sequence-number-range [0] NumberRange, creation-time-range [1] TimeRange^}
NumberRange ::= SEQUENCE^{
from [0] SequenceNumber OPTIONAL --
omitido significa sin
cota inferior
--,
to [1] SequenceNumber OPTIONAL --
omitido significa sin
cota superior
--^}
TimeRange ::= SEQUENCE^{
from [0] CreationTime OPTIONAL --
omitido significa sin
cota inferior
--,
to [1] CreationTime OPTIONAL --
omitido significa sin
cota superior
--^}
Filter ::= CHOICE^{ item [0] FilterItem, and [1] SET SIZE (1.^.ub-nested-filters) OF Filter, or [2] SET SIZE (1.^.ub-nested-filters) OF Filter, not [3] Filter^}
FilterItem ::= CHOICE^{
equality [0] AttributeValueAssertion,
substrings [1] SEQUENCE^{
type AttributeType,
strings SEQUENCE SIZE (1.^.ub-attribute-values) OF CHOICE^{
initial [0] ANY --
DEFINED BY type
--,
any [1] ANY --
DEFINED BY type
--,
final [2] ANY --
DEFINED BY type
--^}^},
greater-or-equal [2] AttributeValueAssertion,
less-or-equal [3] AttributeValueAssertion,
present [4] AttributeType,
approximate-match [5] AttributeValueAssertion^}
AttributeValueAssertion ::= SEQUENCE^{ type AttributeType, value ANY DEFINED BY type^}
Selector ::= SET^{
child-entries [0] BOOLEAN DEFAULT FALSE,
range [1] Range OPTIONAL --
por defecto: no vinculado
--,
filter [2] Filter OPTIONAL --
por defecto: todos los
asientos dentro de la gama especificada
--,
limit [3] INTEGER (1.^.ub-messages) OPTIONAL,
override [4] OverrideRestrictions OPTIONAL --
por
defecto: cualquier restricción en vigor si se
aplica
--^}
OverrideRestrictions ::= BIT STRING^{ overrideContentTypesRestriction (0), overrideEITsRestriction (1), overrideContentLengthRestriction (2)^} (SIZE (1.^.ub-information-bases))
EntryInformationSelection::= SET SIZE(0.^.ub-per-entry) OF AttributeSelection
AttributeSelection ::= SET^{
type AttributeType,
from [0] INTEGER (1.^.ub-attribute-values)
OPTIONAL --
se usa si
el tipo es de
múltiples
valores
--,
count [1] INTEGER (1.^.ub-attribute-values)
OPTIONAL --
se usa si
el tipo es de
múltiples
valores
--^}
EntryInformation ::= SEQUENCE^{ sequence-number SequenceNumber, attributes SET SIZE (1.^.ub-per-entry) OF Attribute OPTIONAL^}
--
Parámetro de petición de retransmisión para depósito
indirecto
forwarding-request EXTENSION SequenceNumber CRITICAL FOR SUBMISSION ::= 36
--
Operaciones abstractas
Summarize ::= ABSTRACT-OPERATION ARGUMENT SummarizeArgument RESULT SummarizeResult ERRORS^{ AttributeError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
SummarizeArgument ::= SET^{
information-base-type [0] InformationBase DEFAULT
stored-messages,
selector [1] Selector,
summary-requests [2] SEQUENCE SIZE (1.^.ub-summaries) OF Attribute Type
OPTIONAL
--
ausente si no se solicitan resúmenes
--^}
SummarizeResult ::= SET^{
next [0] SequenceNumber OPTIONAL,
count [1] INTEGER (0.^.ub-messages) --
de las
inscripciones
solicitadas
--,
span [2] Span OPTIONAL --
de
las inscripciones seleccionadas,
se omite si cuenta
es cero
--,
summaries [3] SEQUENCE SIZE
(1.^.ub-summaries) OF Summary
OPTIONAL^}
Span ::= SEQUENCE^{
lowest [0] SequenceNumber,
highest [1] SequenceNumber^}
Summary ::= SET^{
absent [0] INTEGER (1.^.ub-messages) OPTIONAL
-- cómputo de
inscripciones donde el
atributo
[0]
está ausente
--,
present [1] SET SIZE (1.^.ub-attribute-values)
OF --
uno para
cada valor de
atributo presente
--
SEQUENCE^{
type AttributeType,
value ANY DEFINED BY type,
count INTEGER (1.^.ub-messages)^} OPTIONAL^}
List ::= ABSTRACT-OPERATION ARGUMENT ListArgument RESULT ListResult ERRORS^{ AttributeError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
ListArgument ::= SET^{ information-base-type [0] InformationBase DEFAULT stored-messages, selector [1] Selector, requested-attributes [3] EntryInformationSelection OPTIONAL^}
ListResult ::= SET^{
next [0] SequenceNumber OPTIONAL,
requested [1] SEQUENCE SIZE
(1.^.ub-messages) OF EntryInformation
OPTIONAL --
omitido si
no
[1]
se encuentra ninguno
--^}
--
Fetch ::= ABSTRACT-OPERATION ARGUMENT FetchArgument RESULT FetchResult ERRORS^{ AttributeError, FetchRestrictionError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
FetchArgument ::= SET^{ information-base-type [0] InformationBase DEFAULT stored-messages, item CHOICE^{ search [1] Selector, precise [2] SequenceNumber^}, requested-attributes [3] EntryInformationSelection OPTIONAL^}
FetchResult ::= SET^{
entry-information [0] EntryInformation OPTIONAL --
si se seleccionó alguna
inscripción
--,
list [1] SEQUENCE SIZE (1.^.ub-messages) OF SequenceNumber OPTIONAL,
next [2] SequenceNumber OPTIONAL^}
--
Delete ::= ABSTRACT-OPERATION ARGUMENT DeleteArgument RESULT DeleteResult ERRORS^{ DeleteError, InvalidParametersError, RangeError, SecurityError, SequenceNumberError, ServiceError^}
DeleteArgument ::= SET^{ information-base-type [0] InformationBaseDEFAULT stored-messages, items CHOICE^{ selector [1] Selector sequence-numbers [2] SET SIZE (1.^.ub-messages) OF SequenceNumber^}^}
DeleteResult ::= NULL
--
Register-MS ::= ABSTRACT-OPERATION ARGUMENT Register-MSArgument RESULT Register-MSResult ERRORS^{ AttributeError, AutoActionRequestError, InvalidParametersError, SecurityError, ServiceError^}
Register-MSArgument ::= SET^{
auto-action-registrations [0] SET SIZE
(1.^.ub-auto-registrations) OF AutoActionRegistration
OPTIONAL,
auto-action-deregistrations [1] SET SIZE (1.^.ub-auto-registrations)
OF AutoActionDeregistration
OPTIONAL,
list-attribute-defaults [2] SET SIZE (1.^.ub-default-registrations) OF
AttributeType OPTIONAL,
fetch-attribute-defaults [3] SET SIZE (1.^.ub-default-registrations)
OF AttributeType OPTIONAL,
change-credentials [4] SEQUENCE^{
old-credentials [0] IMPLICIT Credentials,
new-credentials [1] IMPLICIT Credentials^} OPTIONAL
--
same CHOICE as for old-credentials
--,
user-security-labels [5] SET SIZE
(1.^.ub-labels-and-redirections) OF SecurityLabel OPTIONAL^}
AutoActionDeregistration ::= AutoActionRegistration (WITH COMPONENTS {^.^.^., registration-parameter ABSENT^}^)
Register-MSResult ::= NULL
--
Alert ::= ABSTRACT-OPERATION ARGUMENT AlertArgument RESULT AlertResult ERRORS^{ SecurityError^}
AlertArgument ::= SET^{ alert-registration-identifier [0] INTEGER (1.^.ub-auto-actions), new-entry [2] EntryInformation OPTIONAL^}
AlertResult ::= NULL
--
Errores abstractos
AttributeError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1.^.ub-per-entry) OF SET^{ problem [0] AttributeProblem, type [1] AttributeType, value [2] ANY DEFINED BY type OPTIONAL^}^}
AttributeProblem ::= INTEGER^{ invalid-attribute-value (0), unavailable-attribute-type (1), inappropriate-matching (2), attribute-type-not-subscribed (3), inappropriate-for-operation (4)^} (0.^.ub-error-reasons)
--
AutoActionRequestError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1.^.ub-auto-registrations) OF SET^{ problem [0] AutoActionRequestProblem, type [1] AutoActionType^}^}
AutoActionRequestProblem ::= INTEGER^{ unavailable-auto-action-type (0), auto-action-type-not-subscribed (1)^} (0.^.ub-error-reasons)
--
DeleteError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1.^.ub-messages) OF SET^{ problem [0] DeleteProblem, sequence-number [1] SequenceNumber^}^}
DeleteProblem ::= INTEGER^{ child-entry-specified (0), delete-restriction-problem (1)^} (0.^.ub-error-reasons)
--
FetchRestrictionError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [0] SET SIZE (1.^.ub-default-registrations) OF SET^{ problem [3] FetchRestrictionProblem, restriction CHOICE^{ content-type [1] ContentType, eit [2] MS-EITs, content-length [3] ContentLength^}^}^}
FetchRestrictionProblem ::= INTEGER^{ content-type-problem (1), eit-problem (2), content-length-problem (3)^} (0.^.ub-error-reasons)
--
InvalidParametersError ::= ABSTRACT-ERROR PARAMETER NULL
--
RangeError ::= ABSTRACT-ERROR
PARAMETER SET^{ problem [0] RangeProblem^}
RangeProblem ::= INTEGER^{ reversed (0)^} (0.^.ub-error-reasons)
--
SequenceNumberError ::= ABSTRACT-ERROR PARAMETER SET^{ problems [1] SET SIZE (1.^.ub-messages) OF SET^{ problem [0] SequenceNumberProblem, sequence-number [1] SequenceNumber^}^}
SequenceNumberProblem ::= INTEGER^{ no-such-entry (0)^} (0.^.ub-error-reasons)
--
ServiceError ::= ABSTRACT-ERROR PARAMETER SET^{ problem [0] ServiceProblem^}
ServiceProblem ::= INTEGER^{ busy (0), unavailable (1), unwilling-to-perform (2)^} (0.^.ub-error-reasons)
END --
del servicio abstracto MSA
ANEXO C (a la Recomendación X.413)
Definición formal de tipos
de atributos generales
Este anexo es parte integrante de esta
Recomendación.
Este anexo, que es un suplemento a la sección 3, define formalmente los tipos de atributos generales aplicables a todas las formas de tratamiento de mensajes, y no solamente a una. Emplea la NSA.1 y la macro ATTRIBUTE.
MSGeneralAttributeTypes {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) general-attribute-types(2)^} DEFINITIONS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Identificadores de objeto de tipos de atributos
generales
id-att-child-sequence-numbers, id-att-content,
id-att-content-confidentiality-algorithm-identifier,
id-att-content-correlator, id-att-content-identifier,
id-att-content-integrity-check, id-att-content-length,
id-att-content-returned, id-att-content-type,
id-att-conversion-with-loss-prohibited, id-att-converted-EITs,
id-att-creation-time, id-att-delivered-EITs, id-att-delivery-flags,
id-att-dl-expansion-history,
id-att-entry-status, id-att-entry-type, id-intended-recipient-name,
id-att-message-delivery-envelope,
id-att-message-delivery-identifier, id-att-message-delivery-time,
id-att-message-origin-authentication-check,
id-att-message-security-label, id-att-message-submission-time,
id-att-message-token, id-att-original-EITs,
id-att-originator-certificate, id-att-originator-name,
id-att-other-recipient-names,
id-att-parent-sequence-number, id-att-priority,
id-att-proof-of-delivery-request, id-att-redirection-history,
id-att-report-delivery-envelope, id-att-reporting-DL-name,
id-att-reporting-MTA-certificate,
id-att-report-origin-authentication-check, id-att-sequence-number,
id-att-subject-submission-identifier,
id-att-this-recipient-name
FROM MSObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) ms(4)
modules(0) object-identifiers(0)^}
--
Macros de atributo
ATTRIBUTE, ATTRIBUTE-SYNTAX
FROM InformationFramework {^joint-iso-ccitt ds(5) modules(1)
informationFramework(1)^}
--
Tipos de datos del servicio abstracto AM
CreationTime, EntryStatus, MS-EIT, SequenceNumber
FROM MSAbstractService {^joint-iso-ccitt mhs-motis(6) ms(4)
modules(0) abstract-service(1)^}
--
Tipos de datos del servicio autenticación
AlgorithmIdentifier
FROM AuthenticationFramework {^joint-iso-ccitt ds(5) modules(1)
authentication-framework(7)^}
--
Tipos de datos del servicio abstracto STRM
Content, ContentCorrelator, ContentIdentifier, ContentIntegrityCheck,
ContentLength,
ConversionWithLossProhibited, DeliveryFlags, DLExpansionHistory,
MessageDeliveryEnvelope,
MessageDeliveryIdentifier, MessageDeliveryTime,
MessageOriginAuthenticationCheck,
MessageSecurityLabel, MessageSubmissionTime, MessageToken,
OriginatorCertificate, ORName,
PerRecipientReportDeliveryFields, Priority, ProofOfDeliveryRequest,
RedirectionHistory,
ReportDeliveryEnvelope, ReportingDLName, ReportingMTACertificate,
ReportOriginAuthenticationCheck, SecurityClassification,
subjectSubmissionIdentifier
FROM MTSAbstractService {^joint-iso-ccitt mhs-motis(6) mts(3)
modules(0)
mts-abstract-service(1)^}
--
Cota superior del servicio abstracto AM
ub-entry-types
FROM MSUpperBounds {^joint-iso-ccitt mhs-motis(6) ms(4)
modules(0) upper-bounds(4)^};
--
Tipos de atributo
ms-child-sequence-numbers ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MULTI VALUE ::= id-att-child-sequence-numbers
ms-content ATTRIBUTE WITH ATTRIBUTE-SYNTAX Content SINGLE VALUE ::= id-att-content
mt-content-confidentiality-algorithm-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX AlgorithmIdentifier SINGLE VALUE ::= id-att-content-confidentiality-algorithm-identifier
mt-content-correlator ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentCorrelator MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-correlator
mt-content-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentIdentifier MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-identifier
mt-content-integrity-check ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentIntegrityCheck SINGLE VALUE ::= id-att-content-integrity-check
ms-content-length ATTRIBUTE WITH ATTRIBUTE-SYNTAX ContentLength MATCHES FOR ORDERING SINGLE VALUE ::= id-att-content-length
ms-content-returned ATTRIBUTE WITH ATTRIBUTE-SYNTAX BOOLEAN MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-returned
mt-content-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-content-type
mt-conversion-with-loss-prohibited ATTRIBUTE WITH ATTRIBUTE-SYNTAX ConversionWithLossProhibited MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-conversion-with-loss-prohibited
ms-converted-EITs ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EIT MATCHES FOR EQUALITY MULTI VALUE ::= id-att-converted-EITs
ms-creation-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX CreationTime MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-creation-time
ms-delivered-EITs ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EIT MATCHES FOR EQUALITY MULTI VALUE ::= id-att-delivered-EITs
mt-delivery-flags ATTRIBUTE WITH ATTRIBUTE-SYNTAX DeliveryFlags MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-delivery-flags
mt-dl-expansion-history ATTRIBUTE WITH ATTRIBUTE-SYNTAX DLExpansionHistory MULTI VALUE ::= id-att-dl-expansion-history
ms-entry-status ATTRIBUTE WITH ATTRIBUTE-SYNTAX EntryStatus MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-entry-status
ms-entry-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX EntryType MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-entry-type
EntryType ::= INTEGER^{ delivered-message (0), delivered-report (1), returned-content (2) (0.^.ub-entry-types)^}
mt-intended-recipient-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-intended-recipient-name
mt-message-delivery-envelope ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageDeliveryEnvelope SINGLE VALUE ::= id-att-message-delivery-envelope
mt-message-delivery-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageDeliveryIdentifier SINGLE VALUE ::= id-att-message-delivery-identifier
mt-message-delivery-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageDeliveryTime MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-message-delivery-time
mt-message-origin-authentication-check ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageOriginAuthenticationCheck SINGLE VALUE ::= id-att-message-origin-authentication-check
mt-message-security-label ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageSecurityLabel SINGLE VALUE ::= id-att-message-security-label
mt-message-submission-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageSubmissionTime MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-message-submission-time
mt-message-token ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageToken SINGLE VALUE ::= id-att-message-token
ms-original-EITs ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EIT MATCHES FOR EQUALITY MULTI VALUE ::= id-att-original-EITs
mt-originator-certificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX OriginatorCertificate SINGLE VALUE ::= id-att-originator-certificate
mt-originator-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-originator-name
mt-other-recipient-names ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY MULTI VALUE ::= id-att-other-recipient-names
ms-parent-sequence-number ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-parent-sequence-number
mt-per-recipient-report-delivery-fields ATTRIBUTE WITH ATTRIBUTE-SYNTAX PerRecipientReportDeliveryFields MULTI VALUE ::= id-att-per-recipient-report-delivery-fields
mt-priority ATTRIBUTE WITH ATTRIBUTE-SYNTAX Priority MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-priority
mt-proof-of-delivery-request ATTRIBUTE WITH ATTRIBUTE-SYNTAX ProofOfDeliveryRequest SINGLE VALUE ::= id-att-proof-of-delivery-request
mt-redirection-history ATTRIBUTE WITH ATTRIBUTE-SYNTAX RedirectionHistory MULTI VALUE ::= id-att-redirection-history
mt-report-delivery-envelope ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportDeliveryEnvelope SINGLE VALUE ::= id-att-report-delivery-envelope
mt-reporting-DL-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportingDLName SINGLE VALUE ::= id-att-reporting-DL-name
mt-reporting-MTA-certificate ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportingMTACertificate SINGLE VALUE ::= id-att-reporting-MTA-certificate
mt-report-origin-authentication-check ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReportOriginAuthenticationCheck SINGLE VALUE ::= id-att-report-origin-authentication-check
mt-security-classification ATTRIBUTE WITH ATTRIBUTE-SYNTAX SecurityClassification MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-security-classification
ms-sequence-number ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-att-sequence-number
mt-subject-submission-identifier ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectSubmissionIdentifier SINGLE VALUE ::= id-att-subject-submission-identifier
mt-this-recipient-name ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORName MATCHES FOR EQUALITY SINGLE VALUE ::= id-att-this-recipient-name
END --
de tipos de atributos generales MSG
ANEXO D (a la Recomendación X.413)
Definición formal de tipos
de acciones automáticas generales
Este anexo, es parte integrante de esta
Recomendación.
Este anexo, que es un suplemento a la sección 3, define formalmente los tipos de acciones automáticas generales aplicables a todas las formas de tratamiento de mensajes, y no sólo a una de ellas. Emplea la NSA.1 y la macro AUTO-ACTION.
MSGeneralAutoActionTypes {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) general-auto-action-types(3)^} DEFINITIONS ::=
BEGIN
--
Prólogo
EXPORTS
--
Tipos de acciones automáticas generales
auto-forward, auto-alert;
IMPORTS
--
Identificadores de objeto de tipo de acción
automática general
id-act-auto-forward, id-act-auto-alert
FROM MSObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) ms(4)
modules(0) object-identifiers(0)^}
--
Macro de acción automática
AUTO-ACTION,
--
Tipos de datos del servicio abstracto AM
Content, Filter, EntryInformationSelection
FROM MSAbstractService {^joint-iso-ccitt mhs-motis(6) ms(4)
modules(0) abstract-service(1)^}
--
Tipos de datos del servicio abstracto STRM
ContentIdentifier, DeferredDeliveryTime, ExplicitConversion, OriginatorName,
OriginatorReportRequest, PerMessageIndicators, PerMessageSubmissionExtensions,
PerRecipientMessageSubmissionExtensions, Priority, RecipientName
FROM MTSAbstractService {^joint-iso-ccitt mhs-motis(6) mts(3)
modules(0) mts-abstract-service(1)^}
--
Cota superior del servicio abstracto AM
ub-alert-addresses
FROM MSUpperBounds {^joint-iso-ccitt mhs-motis(6) ms(4)
modules(0) upper-bounds(4)^};
--
Tipos de acciones
auto-forward AUTO-ACTION
REGISTRATION PARAMETER IS AutoForwardRegistrationParameter
::= id-act-auto-forward
AutoForwardRegistrationParameter ::= SET^{ filter [0] Filter OPTIONAL, auto-forward-arguments [1] AutoForwardArguments, delete-after-auto-forwarding [2] BOOLEAN DEFAULT TRUE, other-parameters [3] OCTET STRING OPTIONAL^}
AutoForwardArguments ::= SET^{ COMPONENTS OF PerMessageAutoForwardFields, per-recipient-fields [1] IMPLICIT SEQUENCE SIZE (1.^.ub-recipients) OF PerRecipient- per-recipient-fields [1] AutoForwardFields^}
PerMessageAutoForwardFields ::= SET^{ originator-name OriginatorName, content-identifier ContentIdentifier OPTIONAL, priority Priority DEFAULT normal, per-message-indicators PerMessageIndicators DEFAULT {^}, deferred-delivery-time [0] IMPLICIT DeferredDeliveryTime OPTIONAL, extensions [2] IMPLICIT PerMessageSubmissionExtensions DEFAULT {^}^}
PerRecipientAutoForwardFields ::= SET^{ recipient-name RecipientName, originator-report-request [0] IMPLICIT OriginatorReportRequest, explicit-conversion [1] IMPLICIT ExplicitConversion OPTIONAL, extensions [2] IMPLICIT PerRecipientMessageSubmissionExtensions extensions [2] DEFAULT {^}^}
auto-alert AUTO-ACTION REGISTRATION PARAMETER IS AutoAlertRegistrationParameter ::= id-act-auto-alert
AutoAlertRegistrationParameter ::= SET^{ filter [0] Filter OPTIONAL, alert-addresses [1] SEQUENCE SIZE (1.^.ub-alert-addresses) OF AlertAddress alert-addresses [1] OPTIONAL, requested-attributes [2] EntryInformationSelection OPTIONAL^}
AlertAddress ::= SEQUENCE^{ address EXTERNAL, alert-qualifier OCTET STRING OPTIONAL^}
END --
de tipos de acciones automáticas generales MSG
ANEXO E (a la Recomendación X.413)
Definición formal de
límites superiores de parámetros AM
Este anexo es parte integrante de
esta Recomendación.
Este anexo define para fines de referencia los límites superiores de diversos tipos de datos de longitud variable cuyas sintaxis abstractas se definen en módulos NSA.1 en el cuerpo de esta Recomendación.
MSUpperBounds {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0) upper-bounds(4)^} DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS --
nada
--;
--
Cota superior
ub-alert-addresses INTEGER ::= 16
ub-attribute-values
INTEGER ::= 32767 -- (215 -1)
el mayor entero que puede representarse con
-- (215 -1)
16 bits
--
ub-attributes-supported INTEGER ::= 1024
ub-auto-actions INTEGER ::= 16
ub-auto-registrations INTEGER ::= 1024
ub-default-registrations INTEGER ::= 1024
ub-entry-types INTEGER ::= 16
ub-error-reasons INTEGER ::= 16
ub-information-bases INTEGER ::= 16
ub-messages
INTEGER ::= 2147483647 -- (231 -1)
el mayor entero que puede representarse con
-- (231 -1)
32 bits
--
ub-nested-filters INTEGER ::= 32
ub-per-auto-action
INTEGER ::= 32767 -- (215 -1)
el mayor entero que puede representarse con
-- (215 -1)
16 bits
--
ub-per-entry INTEGER ::= 1024
ub-summaries INTEGER ::= 16
END --
de cotas superiores MSU
ANEXO F
Ejemplos de la operación abstracta de resumir
Este
anexo no es parte integrante de esta Recomendación.
Este anexo contiene un ejemplo del uso de la operación abstracta de resumir.
F.1
Las inscripciones en el ejemplo AM
Considérese un AM que contiene las siguientes inscripciones, una por cada
línea. Las columnas muestran los valores de los tipos de atributo indicados. Un
`-'
indica que el atributo está ausente de la inscripción.
Cuadro F-1/X.413 [T3.413], p.
F.2
Ejemplo de una petición de resumen
Supóngase que se requiere resumir todas las inscripciones
`nuevas'
por prioridad. El resultado requerido es la siguiente lista de cómputos. Los
números entre paréntesis son números secuenciales de los mensajes que
contribuyen a ese cómputo. Véase el cuadro F-2/X.413.
Cuadro F-2/X.413 [T4.413], p.
Los componentes del argumento-resumir deben establecerse como sigue:
selector:
filtro: Estado de la inscripción = nueva
peticiones de resumir tipo de atributo = Prioridad
Los componentes del resultado de resumir podrían ser los siguientes:
cómputo: 5 intervalo: más bajo: 15 más alto: 23
resúmenes: {^ausente: 1 {^presente: {^valor = normal, cómputo = 3^} {^valor = urgente, cómputo = 1^}^}
ANEXO G
Diferencias entre el texto de la Recomendación X.413
del CCITT y el texto de la Norma ISO/CEI 10021-5
Este
anexo no es parte integrante de esta Recomendación.
Sólo existen tres diferencias entre la Recomendación X.413 del CCITT y el MOTIS de la Norma ISO/CEI 10021-5.
1) El texto del CCITT contiene una restricción en el
7.1
según la cual sólo puede existir en cualquier
momento una asociación abstracta entre el AM y el usuario AM.
Esta restricción
no
está incluida en el
texto ISO/CEI.
2) Las partes de la notación NSA.1 que expresan límites superiores y se documentan en el anexo E, no se consideran constitutivas de la norma MOTIS, pero con una parte formal de la Recomendación X.413.
En la ISO, este nivel de funcionalidad está bajo la responsabilidad del
Grupo Especial sobre Normalización Funcional, que publica
Internationally Standardized Profiles
(ISP); esta
publicación contiene, por ejemplo, límites superiores para elementos de
protocolo.
SECCIóN 1 - Disk. 596 NF01/010 OPM: 01
Sección 1 - NF01/008 OPM: 01
Anexo D
NF01/009 OPM: 01
- NF01/009 OPM: 01
NF01/031 OPM: 01
id-as-mts-rtes NF01/036 OPM: 01
id-mod-mts-transfer-protocol OBJECT IDENTIFIER ::= {^id-mod 3^} Disk. 597
NF01/042 OPM: 02
(cs,) - (cs,)
(1BT) (BT..)
(87.TE.15.S)
(A1.23s) / [26s]
FOLIOS: 502 - 542
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 89.09.13 AR/SJ
ID + LASER 12.10.89 JC
MAJ diskette 18.10.89 JC
Corr. LASER (1re épreuve) = 3eme 06.11.89 GG/SJ
Espaces réservés 13.11.89 JC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 16.11.89 GH/PC
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs 0) 17.11.89 PC
BAT du 30/XI/89 5.12.89 PV
MAJ DISKETTE ........ ..
Recomendación X.419
SISTEMAS DE TRATAMIENTO DE MENSAJES: ESPECIFICACIONES
DE
^
PROTOCOLO
(Melbourne, 1988)
El establecimiento en diversos países de servicios telemáticos y servicios de
mensajes con almacenamiento y retransmisión controlados por computador, y
asociados a redes públicas de datos, crea la necesidad de establecer normas que
faciliten el intercambio internacional de mensajes entre los abonados a estos
servicios.
El CCITT,
considerando
(a)la necesidad de sistemas de tratamiento de mensajes;
(b)la necesidad de transferir y almacenar mensajes de diferentes tipos;
(c)que la Recomendación X.200 define el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(d)que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones especificadas por el CCITT;
(e)que las Recomendaciones de la serie X.500 definen los sistemas de guías;
(f)que los sistemas de tratamiento de mensajes se definen en la serie de Recomendaciones: X.400, X.402, X.403, X.407, X.408, X.411, X.413 y X.419; y
g)que la mensajería interpersonal se define en las Recomendaciones X.420 y T.330,
recomienda por unanimidad
(1)que el protocolo para el acceso al sistema de transferencia de mensajes (protocolo de acceso STRM-P3) se define en la sección 2;
(2)que el protocolo para el acceso al almacenamiento de mensajes (protocolo de acceso AM-P7) se define también en la sección 2;
(3)que el protocolo utilizado entre agentes de transferencia de mensajes (AMT) para proporcionar la operación distribuida del sistema de transferencia de mensajes (protocolo de transferencia STRM-P1) se define en la sección 3.
íNDICE
Sección 1 -
Introducción
0Introducción
1Campo de aplicación
2Referencias
3Definiciones
4Abreviaturas
5Convenios
Sección 2 -
Especificaciones del protocolo de acceso al
sistema de tratamiento de mensajes (STM)
6Descripción general de los protocolos de acceso STM
7Definición de la sintaxis abstracta del protocolo de acceso al sistema de transferencia de mensajes (STRM)
8Definición de la sintaxis abstracta del protocolo de acceso al almacenamiento de mensajes (AM)
9Relación de correspondencia con los servicios utilizados
10Conformidad
Sección 3 -
Especificaciones del protocolo de transferencia
del sistema de transferencia de
mensajes (STRM)
11Visión de conjunto del protocolo de transferencia del STRM
12Definición de la sintaxis abstracta del protocolo de transferencia del STRM
13Relación de correspondencia con los servicios utilizados
14Conformidad
Anexo A
-Definición de referencia de identificadores de
objeto del protocolo del sistema de tratamiento de mensajes (STM)
Anexo B
-Interfuncionamiento con los sistemas de 1984
Anexo C
-Diferencias entre los protocolos del sistema
de tratamiento de mensajes de 1984 y de 1988
Anexo D
-Diferencias entre las versiones del CCITT y de
la ISO
0 Introducción
Esta Recomendación pertenece a un conjunto de Recomendaciones que definen el tratamiento de mensajes en un entorno de sistemas abiertos distribuidos.
El tratamiento de mensajes proporciona el intercambio de mensajes entre
usuarios sobre la base de almacenamiento y retransmisión. Un mensaje depositado
por un usuario (el
originador
) es transferido a través del
sistema de transferencia de mensajes (STRM) y entregado a uno o más usuarios
(los
destinatarios
). Un usuario puede interactuar
directamente con el STRM, o indirectamente a través de un almacenamiento de
mensajes (AM).
El STRM comprende varios agentes de transferencia de mensajes (ATM) que transfieren mensajes y los entregan a sus destinatarios deseados.
Esta Recomendación ha sido elaborada conjuntamente por el CCITT y la ISO. El documento equivalente de la ISO es la Norma ISO 10021-6.
1
Campo de aplicación
Esta Recomendación especifica el protocolo de acceso STRM (P3) utilizado entre un agente usuario distante y el STRM para proporcionar acceso al servicio abstracto del STRM definido en la Recomendación X.411.
Esta Recomendación especifica también el protocolo de acceso AM (P7) utilizado entre un agente usuario distante y un almacenamiento de mensajes (AM) para proporcionar acceso al servicio abstracto AM definido en la Recomendación X.413.
Esta Recomendación especifica también el protocolo de transferencia STRM (P1) utilizado entre los ATM para proporcionar la operación distribuida del STRM definida en la Recomendación X.411.
En la Recomendación X.402 se identifican las otras Recomendaciones que especifican otros aspectos de los sistemas de tratamiento de mensajes.
En la sección 2 de esta Recomendación se especifican los protocolos de acceso STM (P3 y P7). En el 6 figura una visión general de los protocolos de acceso STM. En el 7 se define la sintaxis abstracta del protocolo de acceso STRM (P3). En el 8 se define la sintaxis abstracta del protocolo de acceso AM (P7). En el 9 se define la relación de correspondencia de los protocolos de acceso STM con los servicios utilizados. En el 10 se especifican los requisitos de conformidad para sistemas que aplican los protocolos de acceso STM.
En la sección 3 de esta Recomendación se especifica el protocolo de transferencia STRM (P1). En el 11 figura una visión general del protocolo de transferencia STRM (P1). En el 12 se define la sintaxis abstracta del protocolo de transferencia STRM (P1). En el 13 se define la relación de correspondencia del protocolo de transferencia STRM (P1) con los servicios utilizados. En el 14 se especifican los requisitos de conformidad para sistemas que aplican el protocolo de transferencia STRM (P1).
El anexo A proporciona una definición de referencia de los identificadores de objetos de protocolo STM citados en los módulos NSA.1 en el texto de esta Recomendación.
En el anexo B se describen las reglas de protocolo para el interfuncionamiento con realizaciones de la Recomendación X.411 (1984) mediante el protocolo de transferencia STRM (P1).
El anexo C identifica las diferencias entre la Recomendación X.411 (1984) y esta Recomendación.
El anexo D identifica las diferencias técnicas entre las versiones del CCITT y de la ISO, de la Recomendación X.419 del CCITT y la Norma 10021-6 de la ISO.
2
Referencias
Las referencias se indican en la Recomendación X.402.
3
Definiciones
Las definiciones figuran en la Recomendación X.402.
4
Abreviaturas
Las abreviaturas figuran en la Recomendación X.402.
5
Convenios
Esta Recomendación utiliza los convenios descriptivos indicados a continuación.
5.1
Términos
En esta Recomendación las palabras de términos definidos y los nombres y valores de parámetros de servicio y campos de protocolo, a menos que sean nombres propios, comienzan con una letra minúscula y están unidos por un guión como sigue: término-definido. Los nombres propios (en el texto inglés) comienzan con una letra mayúscula y no están unidos por un guión: Nombre propio.
5.2
Definiciones de sintaxis abstracta
Esta Recomendación define la sintaxis abstracta de los protocolos del STM utilizando la notación de sintaxis abstracta (NSA.1) definida en la Recomendación X.208 y la notación de operaciones a distancia definida en la Recomendación X.219.
6 Descripción general de los protocolos de
acceso STM
6.1
Modelo de protocolos de acceso STM
El 6 de la Recomendación X.411 describe un modelo abstracto del sistema de transferencia de mensajes (STRM) y el servicio abstracto STRM que proporciona a sus usuarios-STRM.
El 6 de la Recomendación X.413 describe un modelo abstracto de un almacenamiento de mensajes (AM) y el servicio abstracto AM que proporciona a su usuario-AM.
Este punto describe cómo se proporcionan el servicio abstracto STRM y el servicio abstracto AM por casos de comunicación de ISA cuando un usuario de servicio abstracto y un proveedor de servicio abstracto son realizados como procesos de aplicación situados en diferentes sistemas abiertos.
En el entorno de ISA, la comunicación entre procesos de aplicación se representa en términos de comunicación entre un par de entidades de aplicación (EA) que utilizan el servicio de presentación. La funcionalidad de una entidad de aplicación se descompone en un conjunto de uno o más elementos de servicio de aplicación (ESA). La interacción entre las EA se describe en términos de su utilización de los servicios proporcionados por los ESA.
El acceso al servicio abstracto STRM se consigue mediante tres elementos del servicio de aplicación, cada uno de los cuales proporciona un tipo de puerto que forma parte de un par entre un usuario STRM y el STRM en el modelo abstracto. El elemento de servicio de depósito de mensaje (ESDM) proporciona los servicios del puerto de depósito; el elemento de servicio de entrega de mensajes (ESEM) proporciona los servicios del puerto de entrega y el elemento de servicio de administración de mensajes (ESAM) proporciona los servicios del puerto de administración. Los ESDM, ESEM y ESAM son ESA asimétricos; es decir, los usuarios-ESA del STRM actúan como el consumidor, y los ESA del STRM actúan como el suministrador, del servicio abstracto STRM.
De manera similar, el acceso al servicio abstracto AM se efectúa mediante tres elementos de servicio de aplicación: el elemento de servicio de depósito de mensajes (ESDM) que proporciona el puerto de depósito indirecto; el elemento de servicio de extracción de mensajes (ESEXM) que proporciona los servicios del puerto de extracción; y el elemento de servicio de administracion de mensajes (ESAM) que proporciona los servicios del puerto de administración. Los ESA usuarios-AM actúan como el consumidor, y los ESA de AM actúan como el suministrador del servicio abstracto AM.
Estos elementos-de-servicio-de-aplicación son apoyados a su vez por otros elementos de servicio de aplicación.
El elemento de servicio de operaciones a distancia (ESOD) proporciona el paradigma petición/respuesta de las operaciones abstractas que se producen en los puertos en el modelo abstracto. Los ESDM, ESEM, ESEXM y ESAM proporcionan la función de correspondencia de la notación de sintaxis abstracta de un servicio abstracto con los servicios proporcionados por el ESOD.
Facultativamente, puede utilizarse el elemento de servicio de transferencia fiable (ESTF) para transferir de forma fiable las unidades de datos de protocolo de aplicación (UDPA) que contienen los parámetros de las operaciones entre las EA.
El elemento de servicio de control de asociación (ESCA) propoporciona el establecimiento y la liberación de una asociación de aplicación entre un par de EA Las asociaciones entre un usuario-STRM y el STRM pueden ser establecidas por el usuario STRM o el STRM. Las asociaciones entre un usuario-AM y un AM pueden ser establecidas solamente por el usuario-AM. Solo el iniciador de una asociación establecida puede liberarla.
La combinación de uno o más de los ESDM, ESEM, ESEXM y ESAM, junto con sus ESA de apoyo, define el contexto-aplicación de una asociación de aplicación. Obsérvese que puede utilizarse una sola asociación de aplicación para proporcionar uno o más tipos de puertos que forman parte de un par entre dos objetos en el modelo abstracto.
En el cuadro 1/X.419 se identifican los contextos de aplicación definidos en esta Recomendación para el protocolo de acceso STRM y el protocolo de acceso AM.
Si se soporta el protocolo de acceso STRM (P3), el soporte para los
contextos de aplicación
acceso-strm
y
acceso-forzado-strm
es obligatorio para un ATM. Si un ATM
apoya el contexto de aplicación
acceso-fiable-strm
, apoyará
también el
acceso-fiable-forzado-strm
, y viceversa. El apoyo
para cada uno de los contextos de aplicación del protocolo de acceso STRM (P3)
es facultativo para un usuario-STRM.
Si se soporta el protocolo de acceso AM (P7), el soporte para el contexto
de aplicación
acceso-am
es obligatorio para un AM, y el
apoyo para el contexto de aplicación
acceso-fiable-am
es
facultativo. El apoyo para cada uno de los contextos de aplicación en el
protocolo de acceso AM (P7) es facultativo para un usuario AM.
En la figura 1/X.419 se modela un contexto de aplicación entre un usuario
STRM y el STRM. La función de consumidor de los ESA usuario-STRM y la función
de suministrador de los ESA STRM se indica mediante un subíndice
`c'
, o
`s'
, respectivamente.
De manera similar, en la figura 2/X.419 se modela un contexto de aplicación entre un usuario AM y el AM.
Tableau 1/X.419 [T1.419], p.1
Figure 1/X.419, p.2
Figure 2/X.419, p.3
6.2
Servicios proporcionados por el protocolo de acceso
STRM
El protocolo de acceso STRM (P3) comprende las siguientes operaciones que proporcionan los servicios definidos en la Recomendación X.411:
Vinculación-STRM y desvinculación-STRM
a)vinculación-STRM
b)desvinculación-STRM
Elemento de servicio de depósito de mensajes (ESDM)
c)depósito-mensaje
d)depósito-sonda
e)cancelación-entrega-diferida
f)control-depósito
Elemento de servicio de entrega de mensajes (ESEM)
g)entrega-mensaje
h)entrega-informe
i)control-entrega
Elemento de servicio de administración de mensajes
(ESAM)
j)registro
k)cambio-credenciales.
6.3
Servicios proporcionados por el protocolo de acceso AM
El protocolo de acceso AM (P7) comprende las siguientes operaciones que proporcionan los servicios definidos en la Recomendación X.413:
Vinculación-AM y desvinculación-AM
a)vinculación-AM
b)desvinculación-AM
Elemento de servicio de depósito de mensajes (ESDM)
c)depósito-mensaje
d)depósito-sonda
e)cancelación-entrega-diferida
f)control-depósito
Elemento de servicio de extracción de mensajes (ESEXM)
g)resumen
h)listado
i)captura
j)supresión
k)registro-AM
l)alerta
Elemento de servicio de administración de mensajes
(ESAM)
m)registro
n)cambio-credenciales.
6.4
Utilización de servicios subyacentes
Los protocolos de acceso STM utilizan servicios subyacentes como se describe a continuación.
6.4.1
Utilización de
servicios
ESOD
El @elemento de servicio de operaciones a distancia (ESOD)\ se define en la Recomendación X.219.
El ESOD proporciona el paradigma petición/respuesta de operaciones a distancia.
Los ESDM, ESEM, ESEXM y ESAM son los únicos usuarios de los servicios OD-INVOCACION, OD-RESULTADO, OD-ERROR, OD-RECHAZO-U y OD-RECHAZO-P del ESOD.
Las operaciones a distancia del protocolo de acceso STRM (P3) y los protocolos de acceso AM (P7) son operaciones clase 2 (asíncronas).
6.4.2
Utilización de los
servicios ESTF
El @elemento de servicio de transferencia fiable (ESTF)\ se define en la Recomendación X.218.
El ESTF proporciona la transferencia fiable de unidades de datos de protocolo de aplicación (UDPA). El ESTF asegura que cada UDPA se transfiere completamente, exactamente una vez, o que se avisa al remitente de una excepción. El ESTF efectúa la recuperación tras el fallo de la comunicación y sistema final y minimiza el volumen de retransmisión necesaria para la recuperación.
Se definen contextos de aplicación alternativos con o sin servicios ESTF para apoyar los protocolos de acceso STM.
El ESTF se utiliza en el modo normal. La utilización del modo normal del ESTF implica la utilización del modo normal del ESCA y el modo normal del servicio de presentación.
Si el ESTF está incluido en un contexto de aplicación, vinculación-STRM y desvinculación-STRM (o vinculación-AM y desvinculación-AM) del protocolo de acceso STM son los únicos usuarios de los servicios TF-APERTURA y TF-CIERRE del ESTF. El ESOD es el único usuario de los servicios TF-TRANSFERENCIA, TF-SOLICITUD-TURNO, TF-CESIóN-TURNO, TF-P-ABORTO y TF-U-ABORTO del ESTF.
6.4.3
Utilización de los
servicios ESCA
El @elemento de servicio de control de aplicación (ESCA)\ se define en la Recomendación X.217.
El ESCA proporciona el control (establecimiento, liberación, aborto) de asociaciones de apliación entre las EA.
Si el ESTF está incluido en un contexto de aplicación, vinculación-STRM y desvinculación-STRM (o vinculación-AM y desvinculación-AM) del protocolo de acceso STM son los únicos usuarios de los servicios A-ASOCIACIóN y A-LIBERACIóN del ESCA en modo normal. El ESOD es el usuario de los servicios A-ABORTO y A-P-ABORTO del ESCA.
Si el ESTF está incluido en el contexto de aplicación, el ESTF es el único usuario de los servicios A-ASOCIACIóN, A-LIBERACIóN, A-ABORTO y A-P-ABORTO del ESCA. La utilización del modo normal del ESTF implica la utilización del modo normal del ESCA y del modo normal del servicio de presentación.
6.4.4
Utilización del
servicio
de presentación
El servicio de presentación se define en la Recomendación X.216.
La capa de presentación coordina la representación (sintaxis) de las semánticas en la capa de aplicación que deberán intercambiarse.
En modo normal, se utiliza un contexto de presentación diferente para cada sintaxis abstracta incluida en el contexto de aplicación.
El ESCA es el único usuario de los servicios P-CONEXIóN, P-LIBERACIóN, P-U-ABORTO y P-P-ABORTO del servicio de presentación.
Si el ESTF no está incluido en el contexto de aplicación, el ESOD es el único usuario del servicio P-DATOS del servicio de presentación.
Si el ESTF está incluido en un contexto de aplicación, el ESTF es el único usuario de los servicios P-COMIENZO-ACTIVIDAD, P-DATOS, P-SINCRONIZACIóN-MENOR, P-FIN-ACTIVIDAD, P-INTERRUPCIóN- ACTIVIDAD, P-DESCARTE-ACTIVIDAD, P-U-INFORME-EXCEPCIóN, P-REANUDACIóN-ACTIVIDAD, P-P-INFORME-EXCEPCIóN, P-SOLICITUD-TESTIGO y P-CESIóN-CONTROL del servicio de presentación. La utilización del modo normal del ESTF implica la utilización del modo normal del ESCA y del modo normal del servicio de presentación.
6.4.5
Utilización de servicios de capa inferior
El servicio de sesión se define en la Recomendación X.215. La capa de sesión estructura el diálogo del flujo de información entre sistemas finales.
Si el ESTF está incluido en la asociación de aplicación, la capa de presentación utiliza las unidades funcionales núcleo, semidúplex, excepciones, sincronización menor y gestión de actividad del servicio de sesión.
Si el ESTF no está incluido en la asociación de aplicación, la capa de presentación utiliza las unidades funcionales núcleo y dúplex del servicio de sesión.
El servicio de transporte se define en la Recomendación X.214. La capa de transporte proporciona la transferencia transparente de extremo a extremo de datos por la conexión de red subyacente.
La elección de la clase de servicio de transporte utilizado por la capa de sesión depende de los requisitos de multiplexación y recuperación tras los errores. El apoyo para la clase de transporte 0 (sin multiplexación) es obligatorio. No se utiliza el servicio acelerado de transporte.
El apoyo para otras clases es facultativo. Puede utilizarse una clase de multiplexación para multiplexar un protocolo de acceso STM y otros protocolos de acceso (por ejemplo, el protocolo de acceso de guía (PAG) definido en la Recomendación X.519) por la misma conexión de red. Puede elegirse una clase de recuperación tras los errores si se omite el ESTF de un contexto de aplicación en una conexión de red con una tasa de error residual inaceptable.
Se supone una red subyacente que apoya el servicio de red de ISA definido en la Recomendación X.213.
Una dirección de red es la que se define en las Recomendaciones X.121, E.163/E.164 o X.200 (dirección PASR de ISA).
7
Definición de la sintaxis
abstracta del protocolo de acceso al sistema de transferencia de mensajes
(STRM)
La sintaxis abstracta del protocolo de acceso STRM (P3) se define en la figura 3/X.419.
La sintaxis abstracta del protocolo de acceso STRM (P3) se define utilizando la notación de sintaxis abstracta (NSA.1) definida en la Recomendación X.208 y la notación de operaciones a distancia definida en la Recomendación X.219.
La definición de sintaxis abstracta del protocolo de acceso STRM (P3) tiene las siguientes partes principales:
-
Prólogo:
^ declaración de las exportaciones desde, e
importaciones al módulo de protocolo de acceso STRM (P3) (figura 3/X.419, parte
1).
-
Contextos de aplicación:
^ definiciones de contextos de
aplicación que pueden utilizarse entre un usuario-STRM y el STRM (figura
3/X.419, partes 2 y 3).
-
Elemento de servicio de depósito de mensaje:
^
definiciones del elemento de servicio de depósito de mensaje (ESDM) y sus
operaciones a distancia y errores (figura 3/X.419, parte 4).
-
Elemento de servicio de entrega de mensaje:
^
definiciones del elemento de servicio de entrega de mensaje (ESEM) y sus
operaciones a distancia y errores (figura 3/X.419, parte 5).
-
Elemento de servicio de administración de mensaje:
^
definiciones del elemento de servicio de administración de mensaje (ESAM) y sus
operaciones a distancia y errores (figura 3/X.419, parte 6).
MTSAccessProtocol {^joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) mts-access-protocol(1)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
EXPORTS
--
Elementos de servicio de aplicación
mSSE, mDSE, mASE;
IMPORTS
--
Elementos de servicio de aplicación y contextos de
aplicación
APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE
FROM Remote-Operations-Notation-extension {^joint-iso-ccitt
remote-operations(4)
notation-extension(2)^}
rTSE FROM Reliable-Transfer-APDUs {^joint-iso-ccitt reliable-transfer(3) apdus(0)^}
--
Parámetros de servicio abstracto STRM
MTSBind, MTSUnbind, MessageSubmission, ProbeSubmission, CancelDeferredDelivery,
SubmissionControl, MessageDelivery, ReportDelivery, DeliveryControl, Register,
ChangeCredentials, SubmissionControlViolated, ElementOfServiceNotSubscribed,
DeferredDeliveryCancellationRejected, OriginatorInvalid,
RecipientImproperlySpecified,
MessageSubmissionIdentifierInvalid, InconsistentRequest, SecurityError,
UnsupportedCriticalFunction, RemoteBindError, DeliveryControlViolated,
ControlViolatesRegistration,
RegisterRejected, NewCredentialsUnacceptable,
OldCredentialsIncorrectlySpecified
FROM MTSAbstractService {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0)
mts-abstract-service(1)¢}
--
Identificadores de objeto
id-ac-mts-access, id-ac-mts-forced-access, id-ac-mts-reliable-access,
id-ac-mts-forced-reliable-access,
id-as-acse, id-as-msse, id-as-mdse, id-as-mrse, id-as-mase, id-as-mts,
id-as-mts-rtse,
id-ase-msse, id-ase-mdse, id-ase-mase
FROM MHSProtocolObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) protocols(0)
modules(0) object-identifiers(0)^};
FIGURA 3/X.419 (parte 1 de 6)
Definición de sintaxis
abstracta del protocolo de acceso STRM (P3)
--
Contextos de aplicación que omiten el ESTF
--
Iniciado por el usuario-STRM
mts-access APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE^} BIND MTSBind UNBIND MTSUnbind REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^mSSE, mDSE, mASE^} ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-msse,-- of MSSE, including ROSE id-as-mdse,-- of MDSE, including ROSE id-as-mase,-- of MASE, including ROSE id-as-mts-- of MTSBind and MTSUnBind^--^} ::= id-ac-mts-access
--
Iniciado por el STRM
mts-forced-access APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE^} BIND MTSBind UNBIND MTSUnbind REMOTE OPERATIONS {^rOSE^} RESPONDER CONSUMER OF {^mSSE, mDSE, mASE^} ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-msse,-- of MSSE, including ROSE id-as-mdse,-- of MDSE, including ROSE id-as-mase,-- of MASE, including ROSE id-as-mts-- of MTSBind and MTSUnbind^--^} ::= id-ac-mts-forced-access
FIGURA 3/X.419 (parte 2 de 6)
Definición de sintaxis
abstracta del protocolo de acceso STRM (P3)
--
Contextos de aplicación que incluyen el ESTF en modo
normal
--
Iniciado por el usuario-STRM
mts-reliable-access APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE, rTSE^} BIND MTSBind UNBIND MTSUnbind REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^mSSE, mDSE, mASE^} ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-msse,-- of MSSE, including ROSE id-as-mdse,-- of MDSE, including ROSE id-as-mase,-- of MASE, including ROSE id-as-mts-rtse-- of MTSBind and MTSUnbind, including RTSE^--^} ::= id-ac-mts-reliable-access
--
Iniciado por el STRM
mts-forced-reliable-access APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE, rTSE^} BIND MTSBind UNBIND MTSUnbind REMOTE OPERATIONS {^rOSE^} RESPONDER CONSUMER OF {^mSSE, mDSE, mASE^} ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-msse,-- of MSSE, including ROSE id-as-mdse,-- of MDSE, including ROSE id-as-mase,-- of MASE, including ROSE id-as-mts-rtse-- of MTSbind and MTSUnBind, including RTSE^--^} ::= id-ac-mts-forced-reliable-access
FIGURA 3/X.419 (parte 3 de 6)
Definición de sintaxis
abstracta del protocolo de acceso STRM (P3)
--
Elemento de servicio de depósito de mensaje
mSSE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ message-submission, probe-submission, cancel-deferred-delivery^} SUPPLIER INVOKES^{ submission-control^} ::= id-ase-msse
--
Operaciones a distancia
message-submission MessageSubmission ::= 3
probe-submission ProbeSubmission ::= 4
cancel-deferred-delivery CancelDeferredDelivery ::= 7
submission-control SubmissionControl ::= 2
--
Errores a distancia
submission-control-violated SubmissionControlViolated ::= 1
element-of-service-not-subscribed ElementOfServiceNotSubscribed ::= 4
deferred-delivery-cancellation-rejected DeferredDeliveryCancellationRejected ::= 8
originator-invalid OriginatorInvalid ::= 2
recipient-improperly-specified RecipientImproperlySpecified ::= 3
message-submission-identifier-invalid MessageSubmissionIdentifierInvalid ::= 7
inconsistent-request InconsistentRequest ::= 11
security-error SecurityError ::= 12
unsupported-critical-function UnsupportedCriticalFunction ::= 13
remote-bind-error RemoteBindError ::= 15
FIGURA 3/X.419 (parte 4 de 6)
Definición de sintaxis
abstracta del protocolo de acceso STRM (P3)
--
Elemento de servicio de entrega de mensaje
mDSE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ delivery-control^} SUPPLIER INVOKES^{ message-delivery, report-delivery^} ::= id-ase-mdse
--
Operaciones a distancia
message-delivery MessageDelivery ::= 5
report-delivery ReportDelivery ::= 6
delivery-control DeliveryControl ::= 2
--
Errores a distancia
delivery-control-violated DeliveryControlViolated ::= 1
control-violates-registration ControlViolatesRegistration ::= 14
-- security-error ::= 12, defined in Part 4
-- unsupported-critical-function ::= 13, defined in Part 4
FIGURA 3/X.419 (parte 5 de 6)
Definición de sintaxis
abstracta del protocolo de acceso STRM (P3)
--
Elemento de servicio de administración de mensaje
mASE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ register, change-credentials^} SUPPLIER INVOKES^{ change-credentials^} ::= id-ase-mase
--
Operaciones a distancia
register Register ::= 1
change-credentials ChangeCredentials ::= 8
--
Errores a distancia
register-rejected RegisterRejected ::= 10
new-credentials-unacceptable NewCredentialsUnacceptable ::= 6
old-credentials-incorrectly-specified OldCredentialsIncorrectlySpecified ::= 5
END --
de protocolo de acceso STRM
FIGURA 3/X.419 (parte 6 de 6)
Definición de sintaxis
abstracta del protocolo^ de acceso STRM (P3)
8
Definición de la sintaxis abstracta
del protocolo de acceso al almacenamiento de mensajes (AM)
La sintasis abstracta del protocolo de acceso AM (P7) se define en la figura 4/X.419.
La sintaxis abstracta del protocolo de acceso AM (P7) se define utilizando la notación de sintaxis abstracta (NSA.1) definida en la Recomendación X.208, y la notación de operaciones a distancia definida en la Recomendación X.219.
La definición de sintaxis abstracta del protocolo de acceso AM (P7) tiene las siguientes partes principales:
-
Prólogo:
declaración de las exportaciones desde, e
importaciones al módulo de protocolo de acceso AM (P7) (figura 4/X.419, parte
1).
-
Contextos de aplicación:
definiciones de contextos de
aplicación que pueden utilizarse entre un usuario-AM y un AM (figura 4/X.419,
parte 2).
-
Elemento de servicio de extracción de mensajes:
definiciones del @elemento de servicio de extracción de mensajes (ESEXM)\ y sus
operaciones a distancia y errores (figura 4/419, partes 3 y 4).
MSAccessProtocol {^joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) ms-access-protocol(2)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
EXPORTS mRSE;
IMPORTS
--
Elementos de servicio de aplicación y contextos de
aplicación
APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE
FROM Remote-Operations-Notation-extension {^joint-iso-ccitt
remote-operations(4)
notation-extension(2)^}
rTSE FROM Reliable-Transfer-APDUs {^joint-iso-ccitt reliable-transfer(3) apdus(0)^}
mSSE, mASE FROM MTSAccessProtocol {^joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) mts-access-protocol(1)^}
--
Parámetros del servicio abstracto AM
MSBind, MSUnbind, Summarize, List, Fetch, Delete, Register-MS, Alert,
AttributeError,
AutoActionRequestError, DeleteError, FetchRestrictionError, RangeError,
SecurityError,
ServiceError, SequenceNumberError
FROM MSAbstractService {^joint-iso-ccitt mhs-motis(6) ms(4) modules(0)
abstract-service(1)^}
--
Identificadores de objeto
id-ac-ms-access, id-ac-ms-reliable-access, id-as-acse, id-as-msse, id-as-mrse,
id-as-mase, id-as-ms, id-as-ms-rtse, id-ase-mrse
FROM MHSProtocolObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) protocols(0)
modules(0) object-identifiers(0)^};
FIGURA 4/X.419 (parte 1 de 4)
Definición de sintaxis
abstracta del protocolo de acceso AM (P7)
--
Contexto de aplicación que omite el ESTF
ms-access APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE^} BIND MSBind UNBIND MSUnbind REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^mSSE, mRSE, mASE^} ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-msse,-- of MSSE, including ROSE id-as-mrse,-- of MRSE, including ROSE id-as-mase,-- of MASE, including ROSE id-as-ms-- of MSBind and MSUnbind^--^} ::= id-ac-ms-access
--
Contexto de aplicación que incluye el ESTF
ms-reliable-access APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE, rTSE^} BIND MSBind UNBIND MSUnbind REMOTE OPERATIONS {^rOSE^} INITIATOR CONSUMER OF {^mSSE, mRSE, mASE^} ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-msse,-- of MSSE, including ROSE id-as-mrse,-- of MRSE, including ROSE id-as-mase,-- of MASE, including ROSE id-as-ms-rtse-- of MSBind and MSUnbind, including RTSE^--^} ::= id-ac-ms-reliable-access
FIGURA 4/X.419 (parte 2 de 4)
Definición de sintaxis
abstracta del protocolo de acceso AM (P7)
--
Elemento de servicio de extracción de mensajes
mRSE APPLICATION-SERVICE-ELEMENT CONSUMER INVOKES^{ summarize, list, fetch, delete, register-MS,^} SUPPLIER INVOKES^{ alert^} ::= id-ase-mrse
--
Operaciones a distancia
summarize Summarize ::= 20
list List ::= 21
fetch Fetch ::= 22
delete Delete ::= 23
register-ms Register-MS ::= 24
alert Alert ::= 25
--
Errores a distancia
attribute-error AttributeError ::= 21
auto-action-request-error AutoActionRequestError ::= 22
delete-error DeleteError ::= 23
fetch-restriction-error FetchRestrictionError ::= 24
range-error RangeError ::= 25
security-error SecurityError ::= 26
service-error ServiceError ::= 27
FIGURA 4/X.419 (parte 3 de 4)
Definición de sintaxis
abstracta del protocolo de acceso AM (P7)
sequence-number-error SequenceNumberError::= 28
END --
de protocolo de acceso AM
FIGURA 4/X.419 (parte 4 de 4)
Definición de sintaxis
abstracta del protocolo de acceso AM (P7)
9 Relación de correspondencia con los servicios
utilizados
A continuación se define la relación de correspondencia de los protocolos de acceso STM con los servicios utilizados.
En el 9.1 se define la correspondencia con los servicios utilizados para contextos de aplicación que omiten el ESTF. En el 9.2 se define la relación de correspondencia con los servicios utilizados para contextos de aplicación que incluyen el ESTF.
9.1
Contextos de aplicación que omiten el
ESTF
Este punto define la relación de correspondencia de los protocolos de acceso STM con los servicios utilizados para contextos de aplicación que omiten el ESTF. El apoyo para esta correspondencia es facultativo para la conformidad con esta Recomendación.
9.1.1
Relación de correspondencia con ESCA
Este punto define la relación de correspondencia de los servicios abstractos-vinculación (vinculación-STRM o vinculación-AM) y servicios abstractos-desvinculación (desvinculación-STRM o desvinculación-AM) con los servicios del ESCA en modo normal para contextos de aplicación que omiten el ESTF. El ESCA se define en la Recomendación X.217.
9.1.1.1
Servicio abstracto-vinculación con A-ASOCIACIóN
El servicio abstracto-vinculación se corresponde con el servicio A-ASOCIACIóN del ESCA. A continuación se califica la utilización de los parámetros del servicio A-ASOCIACIóN.
9.1.1.1.1
Modo
Este parámetro será suministrado por el indicador de la asociación en la
primitiva Petición A-ASOCIACIóN, y tendrá el valor
`modo normal'
.
9.1.1.1.2
Nombre de contexto de aplicación
El iniciador de la asociación propondrá uno de los contextos de aplicación definidos en esta Recomendación que omiten el ESTF en una primitiva Petición A-ASOCIACIóN (véase el cuadro 1/X.419).
9.1.1.1.3
Información de usuario
La correspondencia de la operación-vinculación del servicio abstracto-vinculación con el parámetro información de usuario de la primitiva Petición A-ASOCIACIóN se define en la Recomendación X.219.
9.1.1.1.4
Lista de definición de contexto de
presentación
El iniciador de la asociación suministra la lista de definiciones de contexto de presentación en la primitiva Petición A-ASOCIACIóN.
La lista de definiciones de contexto de presentación comprende una definición de contexto de presentación para cada sintaxis abstracta incluida en el contexto de aplicación. Una definición de contexto de presentación comprende un identificador de contexto de presentación y un nombre de sintaxis abstracta para el ESA. Cada sintaxis abstracta denominada para los ESDM, ESEM, ESEXM y ESAM comprende las UDPA de ESOD.
En los 7 y 8 se definen las sintaxis abstractas incluidas en los contextos de aplicación.
9.1.1.1.5
Calidad de servicio
Este parámetro será suministrado por el iniciador de la asociación en la
primitiva Petición A-ASOCIACIóN y por el respondedor de la asociación en la
primitiva Respuesta A-ASOCIACIóN. Los parámetros
`control ampliado'
y
`transferencia de diálogo optimizada'
se pondrán a no requeridos. Los
parámetros restantes serán tales que se utilicen valores por defecto.
9.1.1.1.6
Requisitos de sesión
Este parámetro será fijado por el iniciador de la asociación en la primitiva Petición A-ASOCIACIóN y por el respondedor de la asociación en la primitiva Respuesta A-ASOCIACIóN. El parámetro se fijará para especificar las siguientes unidades funcionales:
a)núcleo
b)dúplex.
9.1.1.2
Servicio abstracto-desvinculación con
A-LIBERACIóN
El servicio abstracto-desvinculación se corresponde con el servicio A-LIBERACIóN del ESCA. A continuación se califica la utilización de los parámetros del servicio A-LIBERACIóN.
9.1.1.2.1
Resultado
Este parámetro tendrá el valor
`afirmativo'
.
9.1.1.3
Utilización de los servicios A-ABORTO y
A-P-ABORTO
El ESOD es el usuario de los servicios A-ABORTO y A-P-ABORTO del ESCA.
9.1.2
Relación de correspondencia con ESOD
Los servicios ESDM, ESEM, ESEXM y ESAM se corresponden con los servicios OD-INVOCACIóN, OD-RESULTADO, OD-ERROR, OD-RECHAZO-U y OD-RECHAZO-P del ESOD. La relación de correspondencia de la notación de sintaxis abstracta de los ESDM, ESEM, ESEXM y ESAM con los servicios ESOD se define en la Recomendación X.219.
9.2
Contextos de aplicación que incluyen el
ESTF
Este punto define la relación de correspondencia de los protocolos de acceso STM con los servicios utilizados para contextos de aplicación que incluyen el ESTF de modo normal. El apoyo para esta correspondencia es facultativo para la conformidad con esta Recomendación. No se definen correspondencias con el ESTF en el modo X.410-1984. El ESTF se define en la Recomendación X.218.
9.2.1
Relación de correspondencia con TF-APERTURA y
TF-CIERRE
Este punto define la correspondencia de los servicios abstractos-vinculación (vinculación-STRM o vinculación-AM) y los servicios abstractos-desvinculación (desvinculación-STRM o desvinculación-AM) con los servicios TF-APERTURA y TF-CIERRE del ESTF en modo normal.
9.2.1.1
Servicio abstracto-vinculación con TF-ABRIR
El servicio abstracto-vinculación corresponde con el servicio TF-APERTURA del ESTF. A continuación se califica la utilización de los parámetros del servicio TF-APERTURA.
9.2.1.1.1
Modo
Este parámetro será suministrado por el iniciador de la asociación en la
primivita Petición TF-APERTURA y tendrá el valor
`modo normal'
.
9.2.1.1.2
Nombre de contexto de aplicación
El iniciador de la asociación propondrá uno de los contextos de aplicación definidos en esta Recomendación que incluyen el ESTF en modo normal en la primitiva Petición TF-APERTURA (véase el cuadro 1/X.419).
9.2.1.1.3
Datos de usuario
La relación de correspondencia de la operación-vinculación del servicio abstracto-vinculación con el parámetro datos de usuario de la primitiva Petición TF-APERTURA se define en la Recomendación X.219.
9.2.1.1.4
Lista de definiciones de contexto de
presentación
El iniciador de la asociación suministrará la lista de definiciones de contexto de presentación en la primitiva Petición TF-APERTURA.
La lista de definiciones de contexto de presentación comprende una definición de contexto de presentación para cada sintaxis abstracta incluida en el contexto de aplicación. Una definición de contexto de presentación comprende un identificador de contexto de presentación y un nombre de sintaxis abstracta para el ESA. Cada sintaxis abstracta denominada para los ESDM, ESEM, ESEXM y ESAM incluye las UDPA del ESOD. La sintaxis abstracta denominada para el ESTF incluye la sintaxis abstracta para la operación-vinculación del servicio abstracto-vinculación.
En los 7 y 8 se definen las sintaxis abstractas incluidas en los contextos de aplicación.
9.2.1.2
Servicio abstracto-desvinculación con TF-CIERRE
El servicio abstracto-desvinculación se corresponde con el servicio TF-CIERRE del ESTF.
9.2.2
Relación de correspondencia con ESOD
Los servicios ESDM, ESEM y ESAM se corresponden con los servicios OD-INVOCACIóN, OD-RESULTADO, OD-ERROR, OD-RECHAZO-U y OD-RECHAZO-P del ESOD. La correspondencia de la notación de sintaxis abstracta de los ESDM, ESEM, ESEXM y ESAM con los servicios ESOD se efectúa como se define en la Recomendación X.219.
ESOD es el usuario de los servicios TF-TRANSFERENCIA, TF-SOLICITUD-TURNO, TF-CESIóN-TURNO, TF-P-ABORTO y TF-U-ABORTO del ESTF. La utilización de los servicios ESTF por el ESOD se define en la Recomendación X.229.
9.2.2.1
Gestión del turno
La Recomendación X.229 define la utilización por el ESOD de los servicios TF-SOLICITUD-TURNO y TF-CESIóN-TURNO del ESTF para gestionar el turno.
En el cuadro 2/X.419 se definen los valores del parámetro prioridad del servicio TF-SOLICITUD-TURNO utilizado por el ESOD para pedir el turno.
La prioridad cero es la prioridad máxima y se reserva para la acción de liberación de la asociación por el iniciador.
La prioridad uno es la utilizada por el ESOD para la UDPA, ODRCH y la UDPA ODER para proporcionar los servicios OD-RECHAZO-U y OD-ERROR del ESOD.
La prioridad dos es utilizada por el ESOD para la UDPA OBRS para proporcionar los servicios OD-RESULTADO del ESOD.
Las prioridades tres a siete se utilizarán para la UDPA ODIV para
proporcionar el servicio OD-INVOCACIóN para las operaciones a distancia del
protocolo de acceso STM. En el caso de una operación a distancia cuyos
argumentos incluyen un mensaje, la UDPA ODIV tiene prioridad como una función
de la prioridad del mensaje,
urgente
,
normal
o
no urgente
.
CUADRO 2/X.419 [T2.419], p.
10
Conformidad
Un sistema (AU, AM o ATM) que pretenda la conformidad con los protocolos de acceso STM especificados en esta Recomendación cumplirá los requisitos indicados en los 10.1, 10.2 y 10.3.
10.1
Requisitos de declaración
Se declarará lo siguientes:
a)el tipo de sistema para el cual se pretende la conformidad (AU, AM, ATM o ATM/AM);
b)los contextos de aplicación definidos en la sección 2 de esta Recomendación para los cuales se pretende la conformidad.
Puede pretenderse la conformidad para el protocolo de acceso STRM (P3), para el protocolo de acceso AM (P7), o para ambos. En el cuadro 3/X.419, se clasifica el apoyo para contextos de aplicación requeridos para la conformidad con el protocolo de acceso STRM (P3). En el cuadro 4/X.419, se clasifica el apoyo para contextos de aplicación requeridos para la conformidad con el protocolo de acceso AM (P7).
CUADRO 3/X.419 [T3.419], p.
CUADRO 4/X.419 [T4.419], p.
10.2
Requisitos estáticos
El sistema:
a)será conforme con la(s) definición(es) de sintaxis abstracta de los protocolos de acceso STM definidos en los 7 y 8 de esta Recomendación, requeridos por los contextos de aplicación para los cuales se pretende la conformidad.
10.3
Requisitos dinámicos
El sistema:
a)será conforme con la relación de correspondencia con servicios utilizados definida en el 9 de esta Recomendación, requerida por los contextos de aplicación para los cuales se pretende la conformidad.
b)será conforme con la utilización de servicios subyacentes definida en el 6.4 de esta Recomendación.
SECCIóN 3 -ESPECIFICACIONES DEL PROTOCOLO DE TRANSFERERENCIA DEL SISTEMA DE TRANSFERENCIA DE MENSAJES (STRM)
11
Visión de conjunto del protocolo
de transferencia del STRM
11.1
Modelo
El 10 de la Recomendación X.411 perfecciona el modelo abstracto del sistema de transferencia de mensajes (STRM), presentado primero en el 6 de dicha Recomendación, para mostrar que el objeto STRM comprende una colección de objetos de agente de transferencia de mensaje (ATM) que cooperan juntos para formar el STRM y ofrecer el servicio abstracto STRM a sus usuarios.
En el modelo abstracto perfeccionado se modelan interacciones entre los ATM como un conjunto de operaciones abstractas que se producen en el puerto de transferencia que forma parte de un par, entre los ATM.
En este punto se describe cómo los casos de comunicación de ISA proporcionan el servicio abstracto ATM, cuando los ATM son realizados como procesos de aplicación situados en diferentes sistemas abiertos.
En el entorno de ISA, la comunicación entre procesos de aplicación se representa en términos de comunicación entre un par de entidades de aplicación (EA) que utilizan el servicio de presentación. La funcionalidad de una EA se descompone en un conjunto de uno o más elementos de servicio de aplicación (ESA). La interacción entre las EA se describe en términos de su utilización de los servicios proporcionados por los ESA.
Los servicios de puerto de transferencia del modelo abstracto son apoyados por un elemento de servicio de aplicación, el elemento de servicio de transferencia de mensaje (ESTM), que a su vez es apoyado por otros dos elementos de servicio de aplicación, el elemento de servicio de transferencia fiable (ESTF) y el elemento de servicio de control de asociación (ESCA).
El elemento de servicio de transferencia fiable (ESTF) se utiliza para transferir fiablemente unidades de datos de protocolo de aplicación (CUDPA) que contienen el mensaje, sondas e informes entre las EA.
El elemento de servicio de control de asociación (ESCA) permite el establecimiento y la liberación de una asociación de aplicación entre un par de EA. Cualquiera de los dos ATM puede establecer las asociaciones entre los ATM. Sólo el iniciador de una asociación establecida puede liberarla.
La combinación del ESTM, el ESTF y el ESCA define el contexto de aplicación de una asociación de aplicación.
En la figura 4/X.419 se presenta un modelo del contexto de aplicación entre los ATM.
Se definen tres contextos de aplicación para el protocolo de transferencia STRM como se indica en el cuadro 5/X.419.
Cuadro 5/X.419 [T5.419], p.
Se define el
protocolo-transferencia-strm-1984
para el
interfuncionamiento con aplicaciones de la Recomendación X.411 de 1984. En este
contexto de aplicación, la sintaxis abstracta del ESTM está restringida a la
definida en la Recomendación X.411 de 1984. Estas restricciones se identifican
subrayando
las extensiones de 1988 a la sintaxis
abstracta del ESTM en el módulo NSA.1 definido en la Recomendación X.411. Los
cambios se indican también en el anexo C a esta Recomendación a efectos de
referencia. El
protocolo-transferencia-strm-1984
es apoyado
por el ESTF en el modo X.410-1984. El apoyo para el
protocolo-transferencia-strm-1984
es obligatorio para la
conformidad con esta Recomendación.
Se define el
protocolo-transferencia-strm
para permitir
el interfuncionamiento entre aplicaciones que apoyan la funcionalidad ampliada
de 1988 mediante sistemas que han tenido una mejora mínima con respecto a la
conformidad con la Recomendación X.411 de 1984. El
protocolo-transferencia-strm
proporciona la transparencia
controlada del sistema mejorado a las extensiones de 1988. El
protocolo-transferencia-strm
es apoyado por el ESTF en el
modo X.410-1984. El apoyo para el
protocolo-transferencia-strm
es obligatorio para la
conformidad con esta Recomendación.
El contexto de aplicación
transferencia-strm
es apoyado
por el ESTF en modo normal. Se prevé que, con el tiempo, la mayoría de los
sistemas pasarán a apoyar el contexto de aplicación
transferencia-strm
. El apoyo para el contexto de aplicación
transferencia-strm
es facultativo para la conformidad con
esta Recomendación. Obsérvese que en la Norma ISO 10021-6, el apoyo para el
contexto de aplicación
transferencia-strm
es obligatorio. Es
probable que en una futura versión de esta Recomendación el apoyo al contexto
de aplicación
transferencia-strm
sea obligatorio, como parte
de la estrategia de migración para permitir el apoyo para funcionalidad
ampliada y maximizar el interfuncionamiento.
Figure 4/X.419, p.
11.2
Servicios proporcionados por el protocolo de
transfererencia STRM
El protocolo de transferencia STRM (P1) proporciona los siguientes servicios definidos en la Recomendación X.411:
Vinculación-ATM y desvinculación-ATM
a)vinculación-ATM
b)desvinculación-ATM
Elemento de servicio de transferencia de mensajes
(ESTM)
c)transferencia de mensaje
d)transferencia de sonda
e)transferencia de informe.
11.3
Utilización de servicios subyacentes
El protocolo de transferencia STRM (P1) utiliza los servicios subyacentes como se describe a continuación.
11.3.1
Utilización de los servicios ESTF
El elemento de servicio de transferencia fiable (ESTF) se define en la Recomendación X.218.
El ESTF proporciona la transferencia fiable de unidades de datos de protocolo de aplicación (UDPA). El ESTF asegura que cada UDPA se transfiere completamente una sola vez, o que se avisa al remitente de una excepción. El ESTF efectúa la recuperación tras el fallo de comunicación y del sistema final y minimiza el volumen de retransmisión necesario para la recuperación.
Los servicios ESTF se utilizan para apoyar el protocolo de transferencia STRM (P1). El apoyo para el ESTF en el modo X.410-1984 es obligatorio. El apoyo al ESTF en modo normal es facultativo. Obsérvese que en la Norma ISO 10021-6, el apoyo al ESTF en modo normal es obligatorio, y el apoyo al ESTF en el modo X.410-1984 es facultativo.
La utilización del modo X.410-1984 del ESTF implica la utilización del modo X.410-1984 del ESCA y el modo X.410-1984 del servicio de presentación. La utilización del modo normal del ESTF implica la utilización del modo normal del ESCA y el modo normal del servicio de presentación.
El protocolo de transferencia STMR (P1) es el único usuario de los servicios TF-APERTURA,TF-CIERRE, TF-TRANSFERENCIA, TF-SOLICITUD-TURNO, TF-CESIóN-TURNO, TF-P-ABORTO y TF-U-ABORTO del ESTF.
11.3.2
Utilización de servicios ESCA
El elemento de servicio de control de asociación (ESCA) se define en la Recomendación X.217.
El ESCA proporciona el control (establecimiento, liberación, aborto) de asociaciones de aplicación entre las EA.
El ESTF es el único usuario de los servicios A-ASOCIACIóN, A-LIBERACIóN, A-ABORTO y A-P-ABORTO del ESCA. La utilización del modo X.410-1984 del ESTF implica la utilización del modo X.410-1984 del ESCA y el modo X.410-1984 del servicio de presentación. La utilización del modo normal del ESTF implica la utilización del modo normal del ESCA y modo normal del servicio de presentación.
11.3.3
Utilización del servicio de
presentación
El servicio de presentación se define en la Recomendación X.216.
La capa de presentación coordina la representación (sintaxis) de las semánticas de la capa de aplicación que han de intercambiarse.
En modo X.410-1984, se utiliza un solo contexto de presentación por defecto para la conexión de presentación subyacente. Este contexto de presentación incluye una sola sintaxis abstracta para todos los ESA incluidos en el contexto de aplicación (es decir, ESTM, ESTF y ESCA).
En modo normal, se utiliza un contexto de presentación diferente para cada sintaxis abstracta incluida en el contexto de aplicación.
No se utiliza el direccionamiento de capa de presentación para el protocolo de transferencia de mensaje (P1) en el modo X.410-1984.
El ESCA es el único usuario de los servicios P-CONEXIóN, P-LIBERACIóN, P-U-ABORTO y P-P-ABORTO del servicio de presentación.
El ESTF es el único usuario de los servicios P-COMIENZO-ACTIVIDAD, P-DATOS, P-SINCRONIZACIóN-MENOR, P-FINALIZACIóN-ACTIVIDAD, P-INTERRUPCIóN-ACTIVIDAD, P-DESCARTE-ACTIVIDAD, P-U-INFORME-EXCEPCIóN, P-REANUDACIóN-ACTIVIDAD, P-P-INFORME-EXCEPCIóN, P-SOLICITUD-TESTIGO y P-CESIóN-CONTROL del servicio de presentación. La utilización del modo X.410-1984 del ESTF implica la utilización del modo X.410-1984 del ESCA y del modo X.410-1984 del servicio de presentación. La utilización del modo normal del ESTF implica la utilización del modo normal del ESA y del modo normal del servicio de presentación.
11.3.4
Utilización de servicios de capa
inferior
El servicio de sesión se define en la Recomendación X.215. La capa de sesión estructura el diálogo del flujo de información entre los sistemas finales.
La utilización del ESTF requiere la utilización de las unidades funcionales núcleo, semidúplex, excepciones, sincronización menor y gestión de actividad por la capa de presentación.
El direccionamiento de la capa de sesión no se utilliza para el protocolo de transferencia STRM (P1) cuando se emplea el ESTF en el modo X.410-1984. Es decir, no se pasará una dirección de sesión en la UDPS conexión de la capa de sesión.
El servicio de transporte se define en la Recomendación X.214. La capa de transporte proporciona la transferencia transparente de extremo a extremo de datos por la conexión de red subyacente.
La elección de la clase de servicio de transporte utilizado por la capa de sesión depende de los requisitos de multiplexión y recuperación tras los errores. El apoyo para la clase 0 es obligatorio. No se utiliza el servicio acelerado de transporte.
El apoyo para otras clases es facultativo. La utilización de una clase de recuperación tras los errores junto con el ESTF duplica mecanismos para la recuperación tras los errores.
La dirección de transporte comprende una dirección de red y un identificador de punto de acceso de servicio de transporte (identificador PAST). El identificador PAST es transportado en el protocolo de capa de transporte. Cuando se utiliza el ESTF en el modo X.410-1984, este consta de hasta dieciséis dígitos del AI5.
Se supone una red subyacente que admite el servicio de red de ISA definido en la Recomendación X.213.
La dirección de red se define en las Recomendaciones X.121, E.163/E.164 o X.200 (dirección PASR de ISA).
11.4
Establecimiento y liberación de asociaciones
Las asociaciones entre dos EATM se crean mediante acuerdos bilaterales que abarcan:
a)el número máximo de asociaciones que pueden existir simultáneamente;
b)el uso o no de asociaciones de monólogo o bidireccionales alternadas;
c)el contexto de aplicación que se ha de utilizar;
d)el ATM que será responsable del establecimiento de las asociaciones;
e)el hecho de que las asociaciones estén permanentemente establecidas o sean establecidas y liberadas según sea necesario.
12
Definición de la sintaxis
abstracta del protocolo de transferencia del STRM
La sintaxis abstracta del protocolo de transferencia STRM (P1) se define en la figura 5/X.419.
La sintaxis abstracta del protocolo de transferencia STRM (P1) se define utilizando la notación de sintaxis abstracta (NSA.1) definida en la Recomendación X.208 y la notación de operaciones a distancia definida en la Recomendación X.219.
La definición de la sintaxis abstracta del protocolo de transferencia STRM (P1) tiene las siguientes partes principales:
-
Prólogo:
Declaración de las exportaciones desde, e
importaciones al módulo de protocolo de transferencia STRM (P1) (figura
5/X.419, parte 1).
-
Contextos de aplicación:
Definiciones de los contextos
de aplicación utilizados entre los ATM (figura 5/X.419, parte 2).
-
Elemento de servicio de transferencia de mensaje:
Definiciones del elemento de servicio de transferencia de mensaje (ESTM)
(figura 5/X.419, parte 3).
-
Unidades de datos de protocolo de aplicación STRM:
Definiciones de las unidades de datos de protocolo de aplicación STRM (UDPA):
mensaje, sonda e informe (figura 5/X.419, parte 3).
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
EXPORTS;
IMPORTS
--
Elementos de servicio de aplicación y contextos de
aplicación
APPLICATION-SERVICE-ELEMENT, APPLICATION-CONTEXT, aCSE
FROM Remote-Operations-Notation-extension {^joint-iso-ccitt
remote-operations(4)
notation-extension(2)^}
rTSE
FROM Reliable-Transfer-APDUs {^joint-iso-ccitt reliable-transfer(3) apdus(0)^}
--
Parámetros de servicio abstracto de puerto de
transferencia de ATM
MTABind, MTAUnbind, Message, Probe, Report
FROM MTAAbstractService {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0)
mta-abstract-service(2)^}
--
Identificadores de objeto
id-ac-mts-transfer, id-as-acse, id-as-mta-rtse, id-as-mtse, id-ase-mtse
FROM MHSProtocolObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) protocols(0)
modules(0) object-identifiers(0)^}
FIGURA 5/X.419 (parte 1 de 3)
Definición de la sintaxis
abstracta del protocolo de^ transferencia STRM (P1)
--
Contexto de aplicación que incluye el ESTF en modo
normal
mts-transfer APPLICATION-CONTEXT APPLICATION SERVICE ELEMENTS {^aCSE, rTSE, mTSE^} BIND MTABind UNBIND MTAUnbind ABSTRACT SYNTAXES^{ id-as-acse,-- of ACSE id-as-mts-rtse-- of MTABind and MTAUnbind, including RTSE id-as-mtse-- of MTSE --^} ::= id-ac-mts-transfer
--
Contexto de aplicación que incluye el ESTF en modo
X.410-1984
mts-transfer-protocol INTEGER ::= 12
--
Contexto de aplicación para interfuncionamiento con P1
1984
mts-transfer-protocol-1984 INTEGER ::= 1
FIGURA 5/X.419 (parte 2 de 3)
Definición de la sintaxis
abstracta del protocolo de^ transferencia STRM (P1)
--
Elemento de servicio de transferencia de mensaje
mTSE APPLICATION-SERVICE-ELEMENT ::= id-ase-mtse
--
Unidades de datos de protocolo de aplicación del
STRM
MTS-APDU ::= CHOICE^{ message [0] Message, probe [2] Probe, report [1] Report^}
END --
del protocolo de transferencia STRM
FIGURA 5/X.419 (parte 3 de 3)
Definición de la sintaxis
abstracta del protocolo de^ transferencia STRM (P1)
13 Relación de correspondencia con los
servicios utilizados
A continuación se define la relación de correspondencia del protocolo de transferencia STRM (P1) con los servicios utilizados.
En el 13.1 se define la correspondencia del protocolo de transferencia STRM (P1) con servicios utilizados para contextos de aplicación que incluyen el ESTF en el modo X.410-1984. En el 13.2 se define la correspondencia del protocolo de transferencia STRM (P1) con servicios utilizados para contextos de aplicación que incluyen el ESTF en modo normal.
13.1
Relación de correspondencia con ESTF en modo
X.410-1984
En este punto se define la correspondencia del protocolo de transferencia STRM (P1) con servicios utilizados para contextos de aplicación que incluyen el ESTF en modo X.410-1984. El mantenimiento de esta correspondencia es obligatorio para la conformidad con esta Recomendación.
En el 13.1.1 se define la relación de correspondencia de los servicios vinculación-ATM y desvinculación- ATM con los servicios TF-APERTURA y TF-CIERRE del ESTF en el modo X.410-1984. En el 13.1.2 se define la relación de correspondencia de los servicios transferencia de mensaje, transferencia de sonda y transferencia de informe con el servicio TF-TRANSFERENCIA del ESTF. En el 13.1.3 se describe la gestión del turno utilizando los servicios TF-SOLICITUD-TURNO y T-CESIóN-TURNO del ESTF. En el 13.1.4 se define la utilización del servicio TF-P-ABORTO del ESTF. En el 13.1.5 se define la utilización del servicio TF-U-ABORTO del ESTF (no utilizado en el modo X.410-1984).
13.1.1
Relación de correspondencia con TF-APERTURA y
TF-CIERRE
Este punto define la correspondencia de los servicios vinculación-ATM y desvinculación-ATM con los servicios TF-APERTURA y TF-CIERRE del ESTF en el modo X.410-1984.
13.1.1.1
Vinculación-ATM con TF-APERTURA
El servicio vinculación-ATM se corresponde con el servicio TF-APERTURA del ESTF. A continuación se califica la utilización de los parámetros del servicio TF-APERTURA.
13.1.1.1.1
Protocolo de aplicación
Este parámetro será suministrado por el iniciador de la asociación en la
primitiva Petición TF-APERTURA y tendrá el valor
protocolo-transferencia-strm
(un valor entero de
`12'
) o
protocolo-transferencia-strm-1984
(un valor
entero de
`1'
).
13.1.1.1.2
Datos de usuario
El iniciador de la asociación hace corresponder el valor del tipo definido en la cláusula ARGUMENT del servicio vinculación-ATM con el parámetro datos de usuario de la primitiva Petición TF-APERTURA.
Si el respondedor de la asociación suministra el parámetro resultado de la
primitiva Respuesta TF-APERTURA con el valor
`aceptado'
, se hace
corresponder el valor del tipo definido en la cláusula RESULT del servicio
vinculación-ATM con el parámetro datos de usuario de la primitiva Respuesta
TF-APERTURA.
En caso de error, el respondedor de la asociación suministra el parámetro
resultado de la primitiva Respuesta TF-APERTURA con el valor
`rechazado
(permanente)'
o
`rechazado (transitorio)'
. En el caso de
`rechazado (permanente)'
, el parámetro datos de usuario de la primitiva
Respuesta TF-APERTURA será
error-autentificación
, o
modo-diálogo-inaceptable
.
13.1.1.1.3
Modo
Este parámetro será suministrado por el iniciador de la asociación en la
primitiva Petición TF-APERTURA y tendrá el valor
`modo X.410-1984)'
.
13.1.1.2
Desvinculación-ATM con TF-CIERRE
Desvinculación-ATM se corresponde con el servicio TF-CIERRE del ESTF. En el modo X.410-1984, el servicio TF-CIERRE no tiene parámetros.
13.1.2
Relación de correspondencia con TF-TRANSFERENCIA
Los servicios transferencia de mensaje, transferencia de sonda y transferencia de informe se corresponden con el servicio TF-TRANSFERENCIA del ESTF.
Un ESTM puede emitir una primitiva Petición TF-TRANSFERENCIA solamente si posee el turno (véase el 13.1.3 ) y si no hay primitiva Confirmación de TF-TRANSFERENCIA pendiente.
A continuación se califica la utilización de los parámetros del servicio TF-TRANSFERENCIA.
13.1.2.1
UDPA
El emisor hará corresponder el valor de la UDPA-STRM con el parámetro UDPA de la primitiva Petición P-TRANSFERENCIA.
Para el servicio transferencia de mensaje, la UDPA STRM es un mensaje. Para el servicio transferencia de sonda, la UDPA STRM es una sonda. Para el servicio transferencia de informe, la UDPA STRM es un informe.
13.1.2.2
Tiempo de transferencia
El valor de este parámetro se especifica mediante una regla local del emisor. Puede relacionarse con la prioridad de la UDPA (véase el 13.1.3.1.1 ).
13.1.3
Gestión del turno
Este punto describe la gestión del turno utilizando los servicios TF-SOLICITUD-TURNO y TF-CESIóN-TURNO del ESTF.
El ESTM debe poseer el turno antes de que pueda utilizar el servicio TF-TRANSFERENCIA para transferir un mensaje, sonda o informe.
El ESTM sin el turno puede emitir una primitiva Petición TF-SOLICITUD-TURNO cuyo parámetro prioridad refleja la UDPA de máxima prioridad que espera transferencia.
El ESTM que posea el turno puede emitir una primitiva Petición TF-CESIóN-TURNO cuando no tiene otras UDPA para transferir. Emitirá una primitiva Petición TF-CESIóN-TURNO en respuesta a una primitiva Indicación TF-SOLICITUD-TURNO cuando no tiene otras UDPA para transferir de prioridad igual o mayor que la indicada en la primitiva Indicación TF-SOLICITUD-TURNO. Si tiene UDPA de prioridad inferior aún por transferir, puede emitir una primitiva Petición TF-CESIóN-TURNO, cuyo parámetro prioridad refleja la UDPA de máxima prioridad que espera transferencia.
13.1.3.1
Utilización del
servicio TF-SOLICITUD-TURNO
Un ESTM emite la primitiva Petición TF-SOLICITUD-TURNO para pedir el turno. Puede hacerlo así solamente si no posee ya el turno.
Si el iniciador de la asociación suministró un valor del parámetro modo
diálogo de
`monólogo'
y un valor del parámetro turno inicial de
`iniciador de asociación'
, no se utilizará el servicio
TF-SOLICITUD-TURNO.
A continuación se califica la utilización del parámetro del servicio TF-SOLICITUD-TURNO.
13.1.3.1.1
Prioridad
El valor del parámetro prioridad es suministrado por el ESTM que pide el turno y refleja la UDPA de máxima prioridad que espera transferencia.
La prioridad cero es la prioridad máxima, y se reserva para la acción de liberación de la asociación por el iniciador.
La prioridad uno se asignará a mensajes cuyo campo de prioridad (definido en el 8.2.1.1.1.8 de la Recomendación X.411) tiene el valor urgente. La prioridad uno se asignará también a sondas e informes.
La prioridad dos se asignará a mensajes cuyo campo de
prioridad
es
normal
.
La prioridad tres se asignará a mensajes cuyo campo de
prioridad
es
no urgente
.
Si se establece más de una asociación entre dos ATM, pueden asignarse las
UDPA-STRM a asociaciones de acuerdo con sus prioridades. Pueden utilizarse
varias asociaciones para transportar UDPA-STRM de la misma prioridad. En una
asociación cualquiera, las UDPA-STRM de más alta prioridad se envían antes que
las UDPA-STRM de más baja prioridad; las UDPA-STRM de la misma prioridad se
envían
`primera en entrar, primera en salir'
.
13.1.3.2
Utilización del
servicio TF-CESIóN-TURNO
Un ESTM emite la primitiva Petición TF-CESIóN-TURNO para ceder el turno a su par. Puede hacerlo así solamente si posee el turno.
Si el iniciador de la asociación suministró un valor del parámetro modo
diálogo de
`monólogo'
y un valor del parámetro turno inicial de
`iniciador de asociación'
, no se utilizará el servicio TF-CESIóN-TURNO.
El servicio TF-CESIóN-TURNO no tiene parámetros.
13.1.4
Utilización del servicio
TF-P-ABORTO
El proceso de aplicación es el usuario del servicio TF-P-ABORTO del ESTF.
El servicio TF-P-ABORTO proporciona una indicación al proceso de aplicación de que la asociación de aplicación no puede mantenerse (por ejemplo, porque no es posible la recuperación).
El servicio TF-P-ABORTO no tiene parámetros.
13.1.5
Utilización del
servicio
TF-U-ABORTO
El servicio TF-U-ABORTO del ESTF no está disponible en el modo X.410-1984.
13.2
Relación de correspondencia con
ESTF en modo normal
En este punto se define la relación de correspondencia del protocolo de transferencia STRM (P1) con servicios utilizados para contextos de aplicación que incluyen el ESTF en modo normal. El mantenimiento de esta correspondencia es facultativo para la conformidad con esta Recomendación. Obsérvese que en la Norma ISO 10021-6, el mantenimiento del ESTF en modo normal es obligatorio.
En el 13.2.1 se define la correspondencia de los servicios vinculación-ATM y desvinculación-ATM con los servicios TF-APERTURA y TF-CIERRE del ESTF en modo normal. En el 13.2.2 se define la correspondencia de los servicios transferencia de mensajes, transferencia de sonda y transferencia de informe con el servicio TF-TRANSFERENCIA del ESTF. El 13.2.3 describe la gestión del turno utilizando los servicios TF-SOLICITUD-TURNO y TF-CESIóN-TURNO del ESTF. En el 13.2.4 se define la utilización del servicio TF-P-ABORTO del ESTF. En el 13.2.5 se define la utilización del servicio TF-U-ABORTO del ESTF.
13.2.1
Relación de correspondencia con TF-APERTURA y
TF-CIERRE
Este punto define la correspondencia de los servicios vinculación-ATM y desvinculación-ATM con los servicios TF-APERTURA y TF-CIERRE del ESTF en modo normal.
13.2.1.1
Vinculación-ATM con TF-APERTURA
El servicio vinculación-ATM se corresponde con el servicio TF-APERTURA del ESTF. A continuación se califica la utilización de los parámetros del servicio TF-APERTURA.
13.2.1.1.1
Modo
Este parámetro será suministrado por el iniciador de la asociación en la
primitiva Petición TF-APERTURA y tendrá el valor
`modo normal'
.
13.2.1.1.2
Nombre de contexto de aplicación
El iniciador de la asociación propondrá el contexto de aplicación
strm-transferencia
, definido en esta Recomendación, en la
primitiva Petición TF-APERTURA.
13.2.1.1.3
Datos de usuario
La correspondencia de la operación-vinculación del servicio vinculación-ATM con el parámetro datos de usuario de la primitiva Petición TF-APERTURA se define en la Recomendación X.219.
13.2.1.1.4
Lista de definiciones de contexto de
presentación
El iniciador de la asociación suministra la lista de definiciones de contexto de presentación en la primitiva Petición TF-APERTURA.
La lista de definiciones de contexto de presentación comprende una definición de contexto de presentación para cada sintaxis abstracta incluida en el contexto de aplicación. Una definición de contexto de presentación comprende un identificador de contexto de presentación y un nombre de sintaxis abstracta para el ESA. La sintaxis abstracta denominada para el ESTF incluye la sintaxis abstracta para la operación-vinculación.
En el 12 se definen las sintaxis abstractas incluidas en el contexto de aplicación.
13.2.1.2
Desvinculación-ATM con TF-CIERRE
Desvinculación-ATM se corresponde con el servicio TF-CIERRE de ESTF.
No se utiliza ningún parámetro del servicio TF-CIERRE en modo normal.
13.2.2
Relación de correspondencia con TF-TRANSFERENCIA
Los servicios transferencia de mensaje, transferencia de sonda y transferencia de informe se corresponden con el servicio TRANSFERENCIA del ESTF.
La correspondencia de estos servicios con el servicio TF-TRANSFERENCIA en modo normal es idéntica a la correspondencia en modo X.410-1984, definida en el 13.1.2 .
13.2.3
Gestión de turno
El ESTM debe poseer el turno antes de que pueda utilizar el servicio TF-TRANSFERENCIA para transferir un mensaje, sonda o informe.
La gestión del turno en modo normal es idéntica a la gestión del turno en el modo X.410-1984, definida en el 13.1.3 .
13.2.4
Utilización del servicio TF-P-ABORTO
El proceso de aplicación es el usuario del servicio TF-P-ABORTO del ESTF.
El servicio TF-P-ABORTO proporciona una indicación al proceso de aplicación de que la asociación de aplicación no puede mantenerse (por ejemplo, porque no es posible la recuperación).
El servicio TF-P-ABORTO no tiene parámetros.
Obsérvese que la utilización del servicio TF-P-ABORTO en el modo normal es idéntica a la utilización del servicio TF-P-ABORTO en el modo X.410-1984.
13.2.5
Utilización del servicio TF-U-ABORTO
El proceso de aplicación es el usuario del servicio TF-U-ABORTO del ESTF.
El servicio TF-U-ABORTO permite que el proceso de aplicación aborte la asociación de aplicación. El servicio TF-U-ABORTO puede ser solicitado por el iniciador o por el respondedor de la asociación.
No se utiliza ningún parámetro de servicio TF-U-ABORTO en modo normal.
Obsérvese que el servicio TF-U-ABORTO no está disponible en el modo X.410-1984.
14
Conformidad
Un
`DG'
que pretende ser conforme con el protocolo de transferencia
STRM (P1) especificado en esta Recomendación cumplirá los requisitos indicados
en los
14.1, 14.2
y 14.3.
14.1
Requisitos en materia de declaración
Se declara lo siguiente:
a)los contextos de aplicación definidos en la sección 3 de esta Recomendación para los cuales se pretenda la conformidad;
b)si se admite el modo monólogo, bidireccional alternado, o ambos modos, monólogo y diálogo bidireccional alternado;
c)si el DG puede actuar como iniciador o como respondedor, o como iniciador y como respondedor de una asociación.
En el cuadro 6/X.419, se clasifica el apoyo para contextos de aplicación requeridos para la conformidad con el protocolo de transferencia STRM (P1).
Tableau 6/X.419 [T6.419], p.
14.2
Requisitos estáticos
El DG:
a)será conforme con la definición de la sintaxis abstracta del protocolo de transferencia STRM (P1) definido en el 12 de esta Recomendación.
14.3
Requisitos dinámicos
El DG:
a)será conforme con los procedimientos para operación distribuida del STRM definidos en la Recomendación X.411;
b)será conforme con la relación de correspondencia con los servicios utilizados definida en el 13 de esta Recomendación, requerida por los contextos de aplicación para los cuales se pretende la conformidad; el mantenimiento de la relación de correspondencia con el ESTF en modo X.410-1984 es obligatorio, y el mantenimiento de la relación de correspondencia con el ESTF en modo normal es facultativo;
c)será conforme con las reglas para el interfuncionamiento con los DG conformes a la Recomendación X.411 definidos en el anexo B de esta Recomendación;
d)será conforme con la utilización de servicios subyacentes definida en el 11.3 de esta Recomendación.
ANEXO A (a la Recomendación X.419)
Definición de
referencia de identificadores de objeto del protocolo del
sistema de tratamiento de mensajes (STM)
Todos los identificadores de objeto que esta Recomendación asigna, son asignados en el presente anexo. Sin embargo, dicho anexo no es definitivo para todas las asignaciones. En los módulos del texto de esta Recomendación figuran otras asignaciones definitivas, a las que se hace referencia en este anexo.
MHSProtocolObjectIdentifiers^{^joint-iso-ccitt mhs-motis(6) protocols(0) modules(0) object-identifiers(0)^}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
--
Prólogo
--
Exporta todo
IMPORTS -- nothing -- ;
--
protocolos STM
id-mhs-protocols OBJECT IDENTIFIER ::=^{^joint-iso-ccitt mhs-motis(6) protocols(0)^}^-- not definitive
--
Categorías de identificadores de objeto
id-mod OBJECT IDENTIFIER ::=^{^id-mhs-protocols 0^}-- modules
id-ac OBJECT IDENTIFIER ::=^{^id-mhs-protocols 1^}-- application contexts
id-as OBJECT IDENTIFIER ::=^{^id-mhs-protocols 2^}-- abstract syntaxes
id-ase OBJECT IDENTIFIER ::=^{^id-mhs-protocols 3^}-- application service elements
--
Módulos
id-mod-object-identifiers OBJECT IDENTIFIER ::=^{^id-mod 0^}-- not definitive
id-mod-mts-access-protocol OBJECT IDENTIFIER ::=^{^id-mod 1^}-- not definitive
id-mod-ms-access-protocol OBJECT IDENTIFIER ::=^{^id-mod 2^}-- not definitive
id-mod-mts-transfer-protocol OBJECT IDENTIFIER ::=^{^id-mod 3^}-- not definitive
FIGURA 6/X.419 (parte 1 de 3)
Definición de la sintaxis
abstracta de identificadores de objeto de protocolo STM
--
Contextos de aplicación
--
Protocolo de acceso STRM
id-ac-mts-access OBJECT IDENTIFIER ::=^{^id-ac 0^}
id-ac-mts-forced-access OBJECT IDENTIFIER ::=^{^id-ac 1^}
id-ac-mts-reliable-access OBJECT IDENTIFIER ::=^{^id-ac 2^}
id-ac-mts-forced-reliable-access OBJECT IDENTIFIER ::=^{^id-ac 3^}
--
Protocolo de acceso AM
id-ac-ms-access OBJECT IDENTIFIER ::=^{^id-ac 4^}
id-ac-ms-reliable-access OBJECT IDENTIFIER ::=^{^id-ac 5^}
--
Protocolo de transferencia STRM
id-ac-mts-transfer OBJECT IDENTIFIER ::=^{^id-ac 6^}
--
Sintaxis abstractas
id-as-acse OBJECT IDENTIFIER ::=^{^joint-iso-ccitt association-control (2) abstract-syntax (1) opdus (0) version1 (1)^}
id-as-msse OBJECT IDENTIFIER ::=^{^id-as 1^}
id-as-mdse OBJECT IDENTIFIER ::=^{^id-as 2^}
id-as-mrse OBJECT IDENTIFIER ::=^{^id-as 5^}
id-as-mase OBJECT IDENTIFIER ::=^{^id-as 6^}
id-as-mtse OBJECT IDENTIFIER ::=^{^id-as 7^}
id-as-mts-rtse OBJECT IDENTIFIER ::=^{^id-as 8^}
id-as-ms OBJECT IDENTIFIER ::=^{^id-as 9^)
FIGURA 6/X.419 (parte 2 de 3)
Definición de la sintaxis
abstracta de identificadores de objeto de protocolo STM
id-as-ms-rtse OBJECT IDENTIFIER ::=^{^id-as 10^}
id-as-mts OBJECT IDENTIFIER ::=^{^id-as 11^}
--
Elemento de servicio de aplicación
id-ase-msse OBJECT IDENTIFIER ::=^{^id-ase 0^}
id-ase-mdse OBJECT IDENTIFIER ::=^{^id-ase 1^}
id-ase-mrse OBJECT IDENTIFIER ::=^{^id-ase 2^}
id-ase-mase OBJECT IDENTIFIER ::=^{^id-ase 3^}
id-ase-mtse OBJECT IDENTIFIER ::=^{^id-ase 4^}
END --
de identificadores de objeto de protocolo
FIGURA 6/X.419 (parte 3 de 3)
Definición de la sintaxis
abstracta de identificadores de objeto de protocolo STM
ANEXO B (a la Recomendación X.419)
Interfuncionamiento con los
sistemas de 1984
En este anexo se definen las reglas que han de cumplir
los DG que pretendan la conformidad con esta Recomendación (denominados en
adelante
`sistemas de 1988'
) cuando interfuncionan con realizaciones
conformes a la Recomendación X.411 (1984) del CCITT (denominadas en adelante
`sistemas 1984'
) que utilizan el protocolo de transferencia STRM (P1).
En el Î B.1 se definen las reglas para establecer las asociaciones que deberá cumplir un sistema 1988 cuando interfunciona con un sistema 1984.
En el Î B.2 se definen las reglas que deberá cumplir un sistema 1988 cuando transfiere una UDPA STRM a un sistema 1984.
En el Î B.3 se definen las reglas que deberá cumplir un sistema 1988 cuando recibe una UDPA-STRM de un sistema 1984.
Nota
- Como la Recomendación X.411 (1984) sólo define
las interacciones en la frontera de un dominio de gestión administrativo
(DGAD), la reglas de interfuncionamiento en este anexo sólo se aplican en dicha
frontera.
Se han añadido otros tipos a la clase universal de tipos NSA.1 comparados con los definidos en la Recomendación X.409 (1984). Por tanto, se amplían las especificaciones de sustitución válidas para un tipo ANY. Obsérvese que los sistemas 1984 pueden ser incapaces de tratar los tipos universales ampliados. Es probable que un sistema 1984 pueda tratar correctamente estos campos incluso si contienen los tipos ampliados. Sin embargo, estos campos destinados a un sistema 1984 deben limitarse a los tipos universales definidos en la Recomendación X.409 (1984).
Las reglas básicas de codificación para NSA.1 ofrecen más flexibilidad que la Recomendación X.409 (1984) para la forma larga de los octetos de longitud. Las primeras permiten utilizar más octetos de longitud que el mínimo necesario, pero no así la segunda. Por lo tanto, en el interfuncionamiento con un sistema 1984, es necesario respetar esta limitación, y utilizar el menor número posible de octetos, sin octetos guía que tengan el valor 0.
B.1
Establecimiento de la asociación
Este punto define las limitaciones que observará un sistema 1988 con vinculación-ATM al establecer una asociación con un sistema 1984. No hay restricciones con desvinculación-ATM.
Se utilizará el
protocolo-transferencia-strm-1984
,
definido en el
12
, para la compatibilidad con el sistema 1984.
B.1.1
Credenciales de iniciador/credenciales de
respondedor
No se imponen limitaciones a estos elementos puesto que los elementos correspondientes de la Recomendación X.411 (1984) fueron definidos cada uno para ser un tipo ANY. Sin embargo, obsérvese que un sistema 1984 estará limitado en su utilización de estos elementos al interfuncionar con sistemas 1988 como se describe anteriormente.
B.1.2
Contexto de seguridad
Este elemento facultativo no será generado por un sistema 1988 al interfuncionar con un sistema 1984. Obsérvese que un sistema 1984 no es capaz de generar este elemento.
B.1.3
Error-vinculación
El valor de error-vinculación
contexto-seguridad-inaceptable
no será generado por un
sistema 1988.
B.2
Reglas para la transferencia a sistemas 1984
En este punto se definen las reglas de interfuncionamiento que deberá
cumplir un sistema 1988 al transferir una UDPA-STRM a un sistema 1984. La
transformación de una UDPA-STRM conforme con la Recomendación X.411 en una
conforme con la Recomendación X.411 (1984) se denomina
paso a
un grado inferior
. Las reglas se expresan en términos
de las acciones que han de realizar al sistema 1988 sobre cada elemento de
protocolo del protocolo de transferencia STRM (P1).
Para una UDPA-STRM dada, si ninguna de las reglas indica que fallaría el paso a un grado inferior, se pasará la UDPA-STRM a un grado inferior de acuerdo con todas las reglas aplicables antes de ser transferida al sistema 1984.
Si una o más de las reglas consideran que el paso a un grado inferior ha fallado, la acción realizada por el ATM es igual que si la transferencia hubiera fallado (véase el 14 de la Recomendación X.411).
Nota
- La pérdida potencial o real de información
causada por la aplicación de estas reglas puede afectar a la estrategia de
encaminamiento futura de un ATM.
En el resto de este punto se especifican las reglas para cada uno de los elementos de protocolo. Los elementos de protocolo no mencionados específicamente se transferirán inalterados. A menos que se establezca otra cosa, las reglas especificadas se aplican en cualquier UDPA-STRM que aparece en los elementos de protocolo.
B.2.1
Ampliaciones
Si están presentes cualesquiera elementos de
ampliaciones
por mensaje y ningún
campo-de-ampliación
está marcado como
crítico-para-transferencia
o
crítico-para-entrega
, se suprimirán los elementos
ampliaciones
.
Si están presentes cualesquiera elementos de
ampliaciones
por mensaje y cualquier
campo-de-ampliación
está marcado
crítico-para-transferencia
o
crítico-para-entrega
, fracasará el paso a un grado inferior.
Estas reglas se aplicarán antes de cualesquiera de las reglas descritas en los subapartados siguientes.
B.2.2
Información bilateral por dominio
Si un elemento de
dominio-privado
está presente en un
elemento de
información-bilateral-por-dominio
, se suprimirá
el elemento de
información-bilateral-por-dominio
.
En los demás casos, la
información-bilateral-por-dominio
permanecerá inalterada.
B.2.3
Información de rastreo/información de
rastreo intermedia de asunto
Si un elemento
otras-acciones
está presente en
cualquiera de los
elementos-de-información-de-rastreo
o
elementos-de-información-de-rastreo-intermedia-de-asunto
, se
suprimirá el elemento
otras-acciones
.
En los demás casos, no se alterará la
información-de-rastreo
o
información-de-rastreo-intermedia-de-asunto
.
B.2.4
Nombre de originador/nombre de destino de informe
Si el
nombre-de-originador
en un
sobre-de-transferencia-de-mensaje
o en un
sobre-de-transferencia-de-sonda
, o si el
nombre-de-destino-de-informe
en un
sobre-de-transferencia-de-informe
no pueden pasarse a un
grado inferior de acuerdo con las reglas indicadas para
nombre-OD
(véase el Î B.2.7), fracasará el paso a un grado
inferior.
En los demás casos el elemento no se alterará.
B.2.5
Campos por destinatario de mensaje o transferencia de
sonda
Si un
nombre-de-destinatario
en los
campos-por-destinatario
de un
sobre-transferencia-de-mensaje
o de un
sobre-de-transferencia-de-sonda
, no pueden pasarse a un
grado inferior de acuerdo con las reglas para
nombre-OD
(véase el Î B.2.7), o existe cualquier
campo-de-ampliación-por-destinatario
y está marcado
crítico-para-transferencia
o
crítico-para-entrega
:
a)si el elemento de
responsabilidad
correspondiente tiene
el valor
responsable
, fracasará el paso a un grado inferior;
b)si el elemento
responsabilidad
correspondiente tiene el
valor
no-responsable
, se suprimirá el elemento para dicho
destinatario de los
campos-por-destinatario
.
Nota
- Las reglas de paso a un grado inferior implican
que la
revelación-de-destinatarios
no es ni crítica para
transferencia ni crítica para entrega.
B.2.6
Campos por-destinatario de
transferencia-de-informe
Si un
nombre-de-destinatario-real
o un
nombre-de-destinatario-deseado
en los
campos-por-destinatario
de un
contenido de
transferencia de informe
no pueden pasarse a un grado inferior de acuerdo
con las reglas indicadas para
nombre-OD
(véase el Î B.2.7),
se suprimirá el elemento correspondiente de
campos-por-destinatario
. Si todos los elementos de
campos-por-destinatario
se suprimen de esta manera,
fracasará el paso a un grado inferior.
B.2.7
Nombre-OD
El
nombre-OD
se pasará a un grado inferior suprimiendo
el
nombre-de-guía
si está presente, y pasando a un grado
inferior la
dirección-OD
(véase el Î B.2.8).
B.2.8
Dirección-OD
Si la
dirección-OD
contiene cualesquiera atributos
codificados tanto como cadenas teletex como cadenas imprimibles, se suprimirán
las cadenas teletex.
Si la
dirección-OD
es una
dirección-OD-numérica
o una
dirección-OD-de-terminal
que contiene un
nombre-de-dominio-privado
, la
dirección-OD
no puede pasarse a un grado inferior.
Si la
dirección-OD
es una
dirección-OD-telemática
:
a)que contiene un
nombre-de-país
, un
nombre-de-dominio-de-administración
, una
dirección-de-red
, facultativamente
atributos-definidos-por-el-dominio
y ningún otro, la
dirección-OD
no se alterará.
b)que contiene una
dirección-de-red
, facultativamente
un
identificador-de-terminal
, y ningún otro, la
dirección-OD
no se modificará.
c)que contiene combinaciones de atributos distintos a los anteriores, se
suprimirán todos los atributos excepto la
dirección-de-red
y
el
identificador-del-terminal
, si está presente.
Si la
dirección-OD
contiene cualesquiera atributos
codificados como cadenas teletex y las cadenas imprimibles correspondientes
están asusentes, la
dirección-OD
no puede pasarse a un grado
inferior.
Si después de aplicar todas las reglas anteriores la
dirección-OD
contiene aún cualesquiera
atributos-de-ampliación
, la
dirección-OD
no puede pasarse a un grado inferior.
B.2.9
Tipos-de-información-codificada
Los
tipos-de-información-codificada
básicos indicados
por identificadores de objeto se corresponderán con el bit correspondiente en
tipos-de-información-codificada-básica
, se suprimirán los
identificadores de objetos.
Se harán corresponder otros
tipos-de-información-codificada
indicados por
identificadores de objetos con el bit
indefinido
en
tipos-de-información-codificada-básica
, y se suprimirán los
identificadores de objetos.
No se alterará ningún
parámetro-no-básico
, excepto los
de los tipos
g4-clase-1
y
modo-mixto
. Los
g4-clase-1
y
modo-mixto
pueden
transformarse de acuerdo con reglas deducidas de las Recomendaciones T.73
(1984), T.400, T.501 y T.503; si esto no es posible, fracasará el paso a un
grado inferior.
No obstante las reglas anteriores, se suprimirán
tipos-de-información-codificada
en un
contenido-de-transferencia-de-informe
.
B.2.10
Tipo-de-contenido y contenido
Si el
tipo-de-contenido
en un mensaje o sonda es
indicado por un entero, no se alterará. El
contenido
en el
mensaje tampoco se alterará.
Si el
tipo-de-contenido
en un mensaje es indicado por
un identificador de objeto, se hará corresponder con el valor entero
externo
en vez de con el identificador de objeto. El
identificador de objeto y el
contenido
se combinarán juntos
en un valor de tipo EXTERNAL y este valor será el contenido del nuevo
contenido
. El identificador de objeto será la referencia
directa de EXTERNAL y el contenido del
contenido
OCTET
STRING será su codificación alineada en octetos. La codificación del
contenido
OCTET STRING será las de las reglas de
codificación básica de la NSA.1.
Si el
tipo-de-contenido
en una sonda es indicado por un
identificador de objeto, fracasará el paso al grado inferior.
El
tipo-de-contenido
en un informe se suprimirá. El
contenido-devuelto
no se modificará.
B.3
Reglas para recibir de los sistemas 1984
Este punto define las reglas de interfuncionamiento que deberá cumplir un sistema 1988 al recibir una UDPA-STRM de un sistema 1984.
Se han establecido limitaciones de tamaño para varios elementos de protocolo de transferencia STRM (P1). A condición de que el sistema 1984 observe estas restricciones, una UDPA-STRM correctamente codificada recibida de un sistema 1984 es conforme también con el protocolo de transferencia STRM 1988 (P1). Por tanto, el sistema 1988 no tiene que realizar acciones especiales.
B.4
Irregularidades del servicio
La utilización de listas de redireccionamiento y distribución en presencia de las fronteras de dominio 1988/1984 pueden conducir a algunas irregularidades, que se enumeran seguidamente:
-los destinatarios pueden no ser capaces de advertir que han recibido un mensaje debido a la ampliación o al redireccionamiento de LD;
-cuando un mensaje atraviesa un dominio 1984, se pierde el historial de la ampliación y el historial del redireccionamiento. Esto puede causar la detección prematura del bucle de encaminamiento y producir como resultado el fallo del redireccionamiento o de la ampliación. Obsérvese que sólo un LD con dirección-OD 1984 compatible puede encontrarse con este problema;
-los ATM 1984 devolverán notificaciones al originador del mensaje en lugar de redireccionarlas por el trayecto de ampliación de la LD;
-los sistemas 1984 pueden contemplar nuevos valores distinguidos para elementos de protocolo de enteros que les son desconocidos.
ANEXO C (a la Recomendación X.419)
Diferencias entre los
protocolos del sistema de tratamiento de mensajes de 1984 y
de 1988
En este anexo se identifican las diferencias entre el protocolo
de acceso STRM (P3) y el protocolo de transferencia STRM (P1) definido en esta
Recomendación y los protocolos P3 y P1 definidos en la Recomendación X.411
(1984). No se mencionan aquí las diferencias de carácter puramente redaccional.
Las diferencias se identifican en términos de las adiciones u otras
modificaciones efectuadas en los elementos de protocolo presentes en P3 y P1
definidos en la Recomendación X.411 (1984). Las diferencias se indican con más
precisión en las definiciones de sintaxis abstracta en la Recomendación X.411,
en la cual cada tipo de datos que ha sido modificado se destaca por medio de un
subrayado
.
En el Î C.1 se identifican las diferencias en el protocolo de acceso STRM (P3). En el Î C.2 se identifican las otras diferencias en el protocolo de transferencia STRM (P1).
C.1
Diferencias del protocolo de acceso STRM (P3)
Este punto identifica las diferencias entre el protocolo de acceso STRM (P3) definido en esta Recomendación y el protocolo P3 definido en la Recomendación X.411 (1984).
C.1.1
Limitaciones de tamaño
Se han establecido restricciones para limitar la longitud de los tipos de
cadena, el número de elementos en un tipo SET OF o SEQUENCE OF, y la gama de
valores de tipos INTEGER en todos los parámetros definidos en la Recomendación
X.411 (1984) con excepción del
contenido
de mensaje.
C.1.2
Modificaciones a tipos fundamentales
Se han ampliado los parámetros
nombre-OD
,
tipo-de-contenido
,
tipos-de-información-codificada
y
contenido
, que aparecen en varios lugares en los argumentos
y resultados de operaciones, como se describe a continuación.
C.1.2.1
Nombre-OD
Se han añadido dos nuevos parámetros facultativos al
nombre-OD
.
El primero de éstos es un conjunto de
atributos-de-ampliación
que proporciona los medios para
utilizar el conjunto de caracteres teletex para los
atributos-definidos-de-dominio
y
normalizados
, especificar una
dirección-OD-postal
para entrega física y especificar una
dirección-de-terminal
a partir de una
dirección-de-red-ampliada
.
El segundo de éstos es un
nombre-de-guía
, definido en la
Recomendación X.501.
Si solamente están presentes los
atributos-definidos-de-dominio
,
normalizados
o
atributos de ampliación
,
entonces el
nombre-OD
constituye una
dirección-OD
. En los demás casos, un
nombre-de-guía
está también presente. Si un
nombre-de-guía
sólo está presente, puede ser necesario hacer
corresponder el
nombre de guía
con una
dirección-OD
(por ejemplo, utilizando la guía).
C.1.2.2
Tipo-de-contenido
Se ha añadido la opción de identificar el
tipo-de-contenido
con un identificador de objeto en vez de
con un entero. Este es el método preferido para identificar los nuevos
tipos-de-contenido
y se desaconseja la asignación de nuevos
valores de enteros. Se han definido tres nuevos valores para la elección de
enteros:
indefinido
,
externo
y
mensajeria-interpersonal-1988
.
C.1.2.3
Tipos-de-información-codificada
Se ha añadido la opción de especificar un conjunto de
tipos-de-información-codificada
externos. Todos los nuevos
tipos-de-información-codificada
se añadirán como un
identificador de objeto.
Se ha modificado la definición de los
parámetros-no-básicos
para los tipos
g4-clase-1
y
modo-mixto
, ya que la
definición referenciada en las Recomendaciones T.400, T.501 y T.503 difiere
ahora de la previamente referenciada en la Recomendación T.73 (1984) y que
ahora utiliza etiquetado explícito en lugar de implícito.
C.1.2.4
Contenido
El
contenido
de un mensaje es aún del tipo OCTET
STRING. Si el
tipo-de-contenido
es identificado por el valor
de entero
externo
, el
contenido
se
denomina un
contenido-externo
. Los valores de OCTET STRING
para un
contenido-externo
serán la codificación NSA.1 de un
EXTERNAL.
C.1.3
Ampliaciones
La mayoría de las ampliaciones del servicio abstracto STRM definido en la
Recomendación X.411 se ajustan al protocolo mediante la adición de un solo
parámetro de
ampliaciones
en los sobres y resultados de
operaciones. El parámetro está ausente cuando no se requieren ampliaciones.
Puede estar presente en:
-
Sobre-de-depósito-de-mensaje
, mensaje por mensaje y
destinatario por destinatario.
-
Resultado-de-depósito-de-mensaje
.
-
Sobre-de-depósito-de-sonda
, sonda por sonda y
destinatario por destinatario.
-
Resultado-de-depósito-de-sonda
.
-
Sobre-de-entrega-de-mensaje
.
-
Sobre-de-entrega-de-informe
, informe por informe y
destinatario por destinatario.
C.1.4
Vinculación
En la Recomendación X.411 (1984), las credenciales de tipo ANY se
intercambian utilizando el argumento y resultado de vinculación. El tipo de ANY
está limitado en esta Recomendación a una elección de
credenciales-simples
(una cadena del AI5 o una OCTET
STRING), o
credenciales-fuertes
basadas en técnicas
criptográficas.
Se ha añadido al argumento un parámetro facultativo para especificar un
contexto-de-seguridad
. Se ha añadido un nuevo error para
indicar un
contexto-de-seguridad-inaceptable
.
C.1.5
Depósito-de-mensaje
Se han hecho facultativos los parámetros
tipo-de-información-codificada-original
y
conversión-explícita
en el
sobre-de-depósito-de-mensaje
.
Se han añadido dos nuevos errores:
petición-incoherente
y
error-de-seguridad
.
C.1.6
Depósito-de-sonda
Igual que para depósito de mensaje, véase el Î C.1.5.
C.1.7
Cancelación-entrega-diferida
Esta operación no se cambia virtualmente con excepción de las limitaciones de tamaño descritas en el Î C.1.1 y la supresión de error de mensaje transferido (subsumido por cancelación de entrega diferida rechazada).
C.1.8
Control-de-depósito
Se ha añadido al argumento un parámetro facultativo
contexto-de-seguridad-permisible
.
Se ha añadido al resultado un parámetro facultativo
tipos-de-contenido-de-espera
para especificar los
tipos-de-contenido
de cualesquiera mensajes en espera
retenidos debido a controles prevalecientes. Se ha añadido el indicador
otras-etiquetas-de-seguridad
al parámetro
mensajes-en-espera
del resultado.
Se ha añadido un error:
error-de-seguridad
.
C.1.9
Entrega-de-mensaje
Se han hecho facultativos los parámetros
tipos-de-información-codificada-original
y
banderas de entrega
en el
sobre-de-entrega-de-mensajes
, y se ha añadido a éste un
parámetro facultativo
identificador de contenido
.
La operación se ha hecho confirmada añadiendo una cláusula RESULT, que
contiene dos parámetros de seguridad facultativos:
certificado-de-destinatario
y
prueba-de-entrega
.
Se ha añadido un nuevo error:
errror-de-seguridad
.
C.1.10
Entrega-de-informe
Se han añadido dos nuevos parámetros facultativos al
sobre-de-entrega-de-informe
:
tipo-de-contenido
y
tipos-de-información-codificada-original
del mensaje
original.
Se han definido cinco nuevos
códigos-de-motivo-de-no-entrega
y 35 nuevos
códigos-de-diagnóstico-de-no-entrega
.
Se han añadido cinco nuevos valores del parámetro
tipo-de-usuario-STRM
:
almacenamiento-de-mensaje
,
lista de distribución
,
unidad-de-acceso-de-entrega-física
,
destinatario-físico
y
otros
.
La operación se ha hecho confirmada añadiendo una cláusula RESULT (que no transporta parámetros).
Se ha añadido un nuevo error:
errror-de-seguridad
.
C.1.11
Control-de-entrega
Se han añadido dos nuevos parámetros de control facultativos al argumento:
tipos-de-contenido-permisible
y
con
texto-de-seguridad-permisible
.
Se ha añadido al resultado un parámetro facultativo
tipos-de-contenido-en-espera
.
Se han añadido dos nuevos errores:
control-que-viola-registro
y
error-de-seguridad
.
C.1.12
Registro
Se han añadido dos nuevos parámetros facultativos al argumento:
tipos-de-contenido-entregable
y
etiquetas-y-redirecciones
.
Se han alterado los rótulos sobre los parámetros
operaciones-restringidas
,
permisibles
y
longitud-de-contenido-máximo-permisible
de los
controles-de-entrega-por-defecto
. Se ha añadido el parámetro
tipos-de-contenido-permisibles
.
C.1.13
Cambio-de-credenciales
Se han limitado estos tipos posibles suministrados para las credenciales
en esta operación, como se describe en el Î C.1.4. Se ha limitado también la
relación entre los tipos suministrados para
credenciales-antiguas
y
credenciales-nuevas
(para que sean del mismo tipo).
C.2
Diferencias del protocolo de transferencia STRM
(P1)
Este punto identifica las diferencias entre el protocolo de transferencia STRM (P1) definido en esta Recomendación y el protocolo P1 definido en la Recomendación X.411 (1984).
Las siguientes modificaciones del protocolo de transferencia STRM (P1) son las mismas que las definidas para el protocolo de acceso STRM (P3): limitaciones de tamaño (véase el Î C.1.1), cambios a tipos fundamentales (véase el Î C.1.2) y vinculación (véase el Î C.1.4).
A continuación se detallan otras modificaciones del protocolo de transferencia STRM (P1).
C.2.1
Campos-externos
Se utiliza el nuevo parámetro
ampliaciones
para incluir
la mayoría de las ampliaciones del servicio abstracto al protocolo de
transferencia STRM (P1) (véase el Î C.1.3). El parámetro está ausente cuando no
se requieren ampliaciones. Puede estar presente en:
-
Sobre-de-transferencia-de-mensaje
, mensaje por mensaje y
destinatario por destinatario.
-
Sobre-de-transferencia-de-sonda
, sonda por sonda y
destinatario por destinatario.
-
Sobre-de-transferencia-de-informe
.
-
Contenido-de-transferencia-de-informe
, informe por
informe y destinatario por destinatario.
C.2.2
Otras diferencias
Se han añadido dos parámetros facultativos a los campos de transferencia
informe por informe del
sobre-transferencia-de-informe
:
tipos-de-información-codificada-original
y
tipo-de-contenido
.
Se ha añadido un
identificador-de-dominio-privado
facultativo al parámetro
información-bilateral-por-dominio
de los
sobres-de-transferencia-de-mensaje
y
de-sonda
. Esto permite que la
información-bilateral-por-dominio
sea enviada a los DGPR así
como a los DGAD.
Se ha añadido un parámetro facultativo
otras-acciones
a
los elementos de
información-de-rastreo
. Los nuevos
parámetros transportan dos banderas:
redireccionado
para
indicar que el mensaje fue redireccionado por un DG y
ampliado
para indicar que el DG amplió una lista de
distribución.
ANEXO D (a la Recomendación X.419)
Diferencias entre las
versiones del CCITT y de la ISO
En este anexo se identifican las
diferencias técnicas entre las versiones del CCITT y de la ISO del texto de la
Recomendación X.419 y de la Norma ISO 10021-6 según se relacionan con el
mantenimiento del protocolo de transferencia STRM (P1)
Estas diferencias son:
1)En la Recomendación X.419 del CCITT es un requisito de conformidad obligatorio tener la capacidad de interfuncionar con realizaciones de la Recomendación X.411 (1984) del CCITT que utilizan el protocolo de transferencia STRM (P1) (para DGAD-DGAD y DGAD-DGPR). En la Norma ISO 10021-6, la capacidad para interfuncionar con sistemas 1984 es facultativa (para DGPR-DGPR y dentro del dominio).
2)En la Recomendación X.419 del CCITT el mantenimiento de la relación de correspondencia del protocolo de transferencia STRM (P1) con el ESTF en el modo X.410-1984, es un requisito de conformidad obligatorio; el mantenimiento de la relación de correspondencia con el ESTF en modo normal es facultativo. En la Norma 10021-6 de la ISO el mantenimiento de la relación de correspondencia con el ESTF en el modo normal es obligatorio, y el mantenimiento de la relación de correspondencia con el ESTF en el modo X.410-1984 es facultativo.
Nota
- Una realización que sea conforme solamente con
la relación de correspondencia obligatoria de la Norma ISO 10021-6 no será
capaz de interfuncionar con realizaciones de la Recomendación X.411 (1984) del
CCITT, ni con realizaciones que sean conformes solamente con la relación de
correspondencia obligatoria de la Recomendación X.419 (1988) del CCITT, y
viceversa.
3)En la Recomendación X.419 del CCITT, hay requisitos para el mantenimiento de servicios de capa inferior (véase el 11.3.4 ). En la Norma 10021-6 de la ISO estos requisitos se omiten.
(H.T.=OUI)
TAB.???
FICHIER: H.T. =
(87.TA.108.S)
(SANS FORMULES) Tableaux: 1 - Tabulateurs: ..
(BT..) Disk ... NF../... (OPM = ..)
(87.TE.16.S)
(A1.23s) / [26s]
FOLIOS: 543 - 582 (SANS MEP) (DO
PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie diskettes 598-600 14.09.89 PR/UT/YB
ID + Vérif. + diskette MAJ + laser 17.10.89 PV
Corr. LASER (1re épreuve) = 3eme 07.11.89 UT
Espaces réservés + Transfert + Impr. 14.11.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 21.11.89 SP
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs .) ........ ..
BAT du 30/XI/89 6.12.89 PV
MAJ s/disquettes ........ ..
Recomendación X.420
SISTEMAS DE TRATAMIENTO DE MENSAJES:
SISTEMA DE MENSAJERíA INTERPERSONAL
(Málaga-Torremolinos, 1984; modificada en Melbourne, 1988)
El establecimiento en diversos países de servicios telemáticos y servicios de
mensajes con almacenamiento y retransmisión controlados por computador, y
asociados a redes públicas de datos, crea la necesidad de establecer normas que
faciliten el intercambio internacional de mensajes entre los abonados a estos
servicios.
El CCITT,
considerando
(a) la necesidad de sistemas de tratamiento de mensajes;
(b) la necesidad de transferir y almacenar mensajes de diferentes tipos;
(c) que la Recomendación X.200 define el modelo de referencia de interconexión de sistemas abiertos para aplicaciones del CCITT;
(d) que las Recomendaciones X.208, X.217, X.218 y X.219 sirven de base para las aplicaciones especificadas por el CCITT;
(e) que las Recomendaciones de la serie X.500 definen los sistemas de guía;
(f) que los sistemas de tratamiento de mensajes se definen en la serie de Recomendaciones: X.400, X.402, X.403, X.407, X.408, X.411, X.413 y X.419;
(g) que la mensajería interpersonal se define en las Recomendaciones X.420 y T.330,
recomienda por unanimidad
(1) que el intercambio de objetos de información abstractos que los usuarios intercambian en mensajería interpersonal se defina como se indica en la sección 2;
(2) que el servicio abstracto ofrecido a usuarios en mensajería interpersonal se defina como se indica en la sección 3;
(3) que la manera de proporcionar el servicio abstracto sea la especificada en la sección 4.
íNDICE
SECCIóN 1 -
Introducción
0
Introducción
1
Campo de aplicación
2
Referencias
3
Definiciones
4
Abreviaturas
5
Convenios
5.1NSA.1
5.2Grado
5.3Términos
SECCIóN 2 -
Objetos de información abstracta
6
Visión de conjunto
7
Mensajes interpersonales
7.1Tipos de componentes del campo de encabezamiento
7.2Campos de encabezamiento
7.3Tipos de parte de cuerpo
8
Notificaciones interpersonales
8.1Campos comunes
8.2Campos de no recepción
8.3Campos de recepción
SECCIóN 3 - Definición de servicio abstracto
9
Visión de conjunto
10
Tipos de objetos primarios
10.1Usuario de sistema de mensajería interpersonal
10.2Sistema de mensajería interpersonal
11
Tipos de puertos primarios
11.1Generación
11.2Recepción
11.3Gestión
12
Operaciones abstractas
12.1Operaciones abstractas de generación
12.2Operaciones abstractas de recepción
12.3Operaciones abstractas de gestión
13
Errores abstractos
13.1Error de abono
13.2Destinatario especificado indebidamente
14
Otras capacidades
SECCIóN 4 -
Provisión del servicio abstracto
15
Visión de conjunto
16
Tipos de objetos secundarios
16.1Agente de usuario del sistema de mensajería interpersonal
16.2Dispositivo de almacenamiento de mensajes del sistema de mensajería interpersonal
16.3Agente telemático
16.4Unidad de acceso télex
16.5Unidad de acceso a entrega física
16.6Sistema de transferencia de mensajes
17
Tipos de puertos secundarios
17.1Depósito
17.2Entrega
17.3Extracción
17.4Administración
17.5Importación
17.6Exportación
18
Operación de agente de usuario
18.1Variables de estado
18.2Ejecución de operaciones de generación
18.3Ejecución de operaciones de gestión
18.4Invocación de operaciones de recepción
18.5Procedimientos internos
19
Operaciones de almacenamiento de mensajes
19.1Creación de objetos de información
19.2Mantenimiento de atributos
19.3Notificación de no recepción
19.4Retransmisión automática
20
Contenido de mensajes
20.1Contenido
20.2Tipo de contenido
20.3Longitud de contenido
20.4Tipos de información codificada
21
Realización de puertos
22
Conformidad
22.1Relación generación-recepción
22.2Requisitos de enunciados de conformidad
22.3Requisitos estáticos
22.4Requisitos dinámicos
Anexo A
-Ampliaciones del encabezamiento
Anexo B
-Tipos de parte de cuerpo ampliado
Anexo C
-Atributos del almacenamiento de mensajes
Anexo D
-Definición de referencia de identificadores de
objeto
Anexo E
-Definición de referencia de objetos de
información abstractos
Anexo F
-Definición de referencia de objetos
funcionales
Anexo G
-Definición de referencia de servicio abstracto
Anexo H
-Definición de referencia de ampliaciones de
encabezamiento
Anexo I
-Definición de referencia de tipos de parte de
cuerpo ampliado
Anexo J
-Definición de referencia de atributos de
almacenamiento de mensajes
Anexo K
-Definición de referencia de límites superiores
Anexo L
-Sustentación del servicio de mensajería
interpersonal
Anexo M
-Diferencias entre la Recomendación del CCITT y
la Norma de la ISO
Anexo N
-Resumen de las modificaciones de la
Recomendación del CCITT de 1984
SECCIóN 1 - INTRODUCCIóN
0 Introducción
Esta Recomendación forma parte de un conjunto de Recomendaciones sobre tratamiento de mensajes. El conjunto completo proporciona un bosquejo general para un sistema de tratamiento de mensajes (STM) realizado por un número cualquiera de sistemas abiertos cooperantes.
El STM tiene por finalidad permitir a los usuarios intercambiar mensajes sobre una base de almacenamiento y retransmisión. Un mensaje depositado por cuenta de un usuario, el originador, es transportado por el sistema de transferencia de mensajes (STRM) y entregado posteriormente a agentes de uno o más usuarios adicionales, los destinatarios. Un usuario es asistido en la preparación, el almacenamiento y la representación de mensajes por un agente de usuario (AU). Facultativamente, es asistido en el almacenamiento de mensajes por un dispositivo de almacenamiento de mensajes (AM). El STRM comprende un número de agentes de transferencia de mensajes (ATM) que, colectivamente, realizan la función de transferencia de mensajes por almacenamiento y retransmisión.
Esta Recomendación define la aplicación tratamiento de mensajes denominada
mensajería interpersonal
, especificando en el proceso el
tipo de contenido de mensajes y los procedimientos asociados conocidos por
P2
.
El texto de esta Recomendación está sujeto al acuerdo mutuo entre el CCITT y la ISO. La especificación ISO/CEI correspondiente es la ISO 10021-7.
1 Campo de aplicación
Esta Recomendación define la
mensajería interpersonal
,
que es una forma de tratamiento de mensajes prevista para la correspondencia
comercial o privada entre personas.
Esta Recomendación forma parte de una serie de Recomendaciones sobre tratamiento de mensajes. La Recomendación X.402 constituye la introducción a la serie mencionada e identifica otros documentos de la misma.
La base y fundamento arquitecturales del tratamiento de mensajes se define en otras Recomendaciones. La Recomendación identifica también estos otros documentos.
Esta Recomendación está organizada como sigue. La sección 1 es la introducción. La sección 2 define las clases de objetos de información intercambiados en la mensajería interpersonal. La sección 3 define el servicio abstracto asociado. La sección 4 especifica la forma de proporcionarlo. Los anexos contienen información suplementaria importante.
Los requisitos para la conformidad con esta Recomendación se indican en el 22 .
2
Referencias
En esta Recomendación se cita la Recomendación X.402, muchos de los documentos citados en ésta, y los indicados a continuación.
Norma ISO 639.2Code for the representation of names of languages.
Recomendación T.4Normalización de los aparatos facsímil del grupo 3 para la transmisión de documentos.
Recomendación T.30Procedimientos de transmisión de documentos por facsímil por la red telefónica general conmutada.
Recomendación T.100Intercambio de información internacional para el videotex interactivo.
Recomendación T.101Interfuncionamiento internacional de servicios videotex.
Recomendación T.330Acceso telemático al SMIP.
Recomendación X.420 (1984)Sistemas de tratamiento de mensajes: capa de agente de usuario del servicio de mensajería interpersonal.
Guía del realizador de la serie X.400, versión 6, 6 de noviembre de 1987.
3
Definiciones
Para los fines de esta Recomendación, son aplicables las definiciones de la Recomendación X.402.
4
Abreviaturas
Para los fines de esta Recomendación, son aplicables las abreviaturas de la Recomendación X.402.
5
Convenios
Esta Recomendación utiliza los convenios descriptivos identificados a continuación.
5.1
NSA.1
Esta Recomendación utiliza, para los fines indicados, los siguientes convenios descriptivos basados en la notación de sintaxis abstracta uno (NSA.1):
a)para definir los objetos de información de mensajería interpersonal, y otros tipos de datos y valores de todas clases, la propia NSA.1;
b)para definir los objetos funcionales de mensajería interpersonal, las macros OBJECT y REFINE de la Recomendación X.407;
c)para definir el servicio abstracto de mensajería interpersonal, las macros PORT y ABSTRACT-OPERATION y ABSTRACT-ERROR de la Recomendación X.407;
d)para definir las
ampliaciones de encabezamiento
, la
macro HEADING-EXTENSION del
7.2.17
;
e)para definir
tipos de parte de cuerpo ampliada
, la
macro EXTENDED-BODY-PART-TYPE del
7.3.12
;
f)para definir atributos AM, la macro ATTRIBUTE de la Recomendación X.500.
Los diversos usos de la notación NSA.1 se recapitulan en el cuadro 1/X.420. Con las dos excepciones que pueden verse fácilmente en el cuadro, la NSA.1, cuando se utiliza, aparece dos veces, una vez en el cuerpo de la Recomendación para facilitar la exposición y una segunda vez, en una forma bastante redundante, en un anexo, con fines de referencia.
Tableau 1/X.420 [T1.420], p.
Si aparecen diferencias entre la NSA.1 utilizada en la exposición y la
indicada en la referencia, se indica un error de especificación.
Obsérvese que los rótulos NSA.1 están implícitos en todo el módulo NSA.1 definido en el anexo; el módulo es definitivo a ese respecto.
Nota 1
- El uso de NSA.1 para describir una clase o
una información no implica, por sí mismo, que esa información se transporta
entre dos sistemas abiertos. El hecho de que la información, en virtud de su
descripción en NSA.1 y de las reglas de codificación básicas de la NSA.1, tenga
una sintaxis de transferencia concreta puede no tener ninguna importancia. La
información transportada realmente entre sistemas se designa como tal por su
inclusión en un protocolo de aplicación.
Nota 2
- El uso de las macros ABSTRACT-OPERATION y
ASTRACT-ERROR, derivada de las macros correspondientemente denominadas de
operaciones a distancia, no implica que las operaciones y los errores
abstractos sean invocados y comunicados a través de la frontera entre sistemas
abiertos. El hecho de que las operaciones y los errores abstractos, en virtud
de su descripción mediante estas macros y con una especificación adicional
mínima, podrían ser en efecto invocadas a través de SOD, no tiene ninguna
importancia en el presente contexto.
5.2
Grado
Esta Recomendación utiliza el concepto de grado desarrollado en la Recomendación X.402.
5.3
Términos
En la presente Recomendación, los términos se escriben en
negrita
cuando son definidos, y en
cursiva
cuando se hace referencia a los mismos antes de su
definición, sin resaltarlos en todas las demás ocasiones.
Los términos que son nombres propios se escriben (en el texto inglés) con mayúsculas, no así los términos genéricos.
SECCIóN 2 - OBJETOS DE INFORMACIóN ABSTRACTA
6 Visión de conjunto
Esta sección describe abstractamente los objetos de información que los
usuarios intercambian en mensajería interpersonal. Son de dos clases:
mensajes interpersonales (MIP)
y
notificaciones interpersonales (NIP)
. Una notificación
interpersonal acusa la recepción, por un usuario, de un mensaje interpersonal.
InformationObject ::= CHOICE { ipm[0] IPM, ipn[1] IPN^}
Esta sección trata los siguientes puntos:
a)Mensajes interpersonales.
b)Notificaciones interpersonales.
Nota 1
- La utilización, en toda esta sección, de
palabras tales como
`originador'
y
`destinatario'
presupone el
hecho de que los
MIP
y las
NIP
son
transportados entre usuarios como el contenido de mensajes (véase el
20
). Estas palabras, por tanto, se refieren a los papeles que
desempeñan los usuarios y las LD en esas transferencias.
Nota 2
- Un
MIP
^ puede aparecer
(véase
7.3.8
) en el
cuerpo
^ de otro
MIP
^ que a su vez es transportado como el contenido de un
mensaje. Las palabras
`originador'
y
`destinatario'
deberán
entenderse en el contexto del transporte de un
MIP
como el
contenido (completo) de un mensaje, y no un componente del
cuerpo
de otro
MIP
transportado.
Nota 3
- Un
MIP
^ o
NIP
^ hace diversas aserciones sobre su propia
transferencia (por ejemplo, sobre quién origina el mensaje que lo contiene).
Además, una
NIP
hace aserciones sobre la transferencia del
MIP
al que ella responde. No se verifica ninguna de estas
aserciones.
7 Mensajes interpersonales
Un @
mensaje interpersonal (MIP)
@ \es un miembro de la
clase primaria de objeto de información transportado entre usuarios en
mensajería interpersonal.
IPM ::= SEQUENCE { heading Heading, body Body^}
Tiene los siguientes componentes:
a)
Encabezamiento
: Conjunto de
campos de
encabezamiento
(o
campos
), cada uno de los cuales es un
elemento de información que da una característica del MIP (por ejemplo, su
importancia).
b)
Cuerpo
: Secuencia de
partes de
cuerpo
, cada una de las cuales es un objeto de información que el MIP
deberá transportar entre usuarios (por ejemplo, un documento).
Body ::= SEQUENCE OF BodyPart
La estructura de un MIP se representa en la figura 1/X.420.\
Este punto define y describe los tipos de componentes más importantes del campo de encabezamiento y define los campos de encabezamiento y los tipos de parte de cuerpo.
Nota
- Un MIP puede asimilarse a una nota comercial.
En efecto, los términos
`Encabezamiento'
y
`Cuerpo'
evocan esa
analogía.
Figure 1/X.420, (N), p.
7.1
Tipos de componentes del campo de encabezamiento
En el encabezamiento figuran elementos de información de varias clases. A
continuación se definen y se describen estos tipos de componente de campo de
encabezamiento-
identificador de MIP
,
especificador de destinatario
, y
descriptor O/D
.
7.1.1
Identificador de MIP
Un
identificador de MIP
es un elemento de información
que identifica de manera única e inequívoca a un MIP, distinguiéndolo de todos
los demás MIP que sean enviados por un usuario cualquiera.
IPMIdentifier ::= [APPLICATION 11] SET { user ORAddress OPTIONAL, user-relative-identifier LocalIPMIdentifier^}
Un identificador de MIP tiene los siguientes componentes:
a)
Usuario
(F): Identifica el usuario que origina el MIP.
Una de las direcciones O/D de usuario. Se desaconseja la omisión de este
componente.
b)
Identificador relativo al usuario
Local IPMIdentifier ::= PrintableString (SIZE (0.^.ub-local-ipm-identifier))
Nota
- El
`11'
en el identificador de MIP es el
único rótulo de la NSA.1 empleado a nivel de la aplicación que es asignado por
esta Recomendación.
7.1.2
Especificador de destinatario
Un
especificador de destinatario
es un elemento de
información que describe un destinatario (preferido) de un MIP y que puede
hacerle ciertas peticiones.
RecipientSpecifier ::= SET { recipient[0]ORDescriptor, notification-requests[1]NotificationRequests DEFAULT {^}, reply-requested[2]BOOLEAN DEFAULT FALSE^}
Un especificador de destinatario tiene los siguientes componentes:
a)
Destinatario
(O): Identifica el destinatario preferido
en cuestión. Un
descriptor O/D
.
Si el componente
peticiones de notificación
o
respuesta solicitada
hace una petición del destinatario
preferido, estará presente el componente
nombre formal
del
descriptor O/D
antes mencionado.
b)
Peticiones de notificación
(D sin valores): Puede hacer
ciertas peticiones del destinatario preferido, señalado por el componente
destinatario.
NotificationRequests ::= BIT STRING { rn (0), nrn (1), ipm-return (2)^}
Este componente puede tomar simultáneamente cualesquiera de los valores que
siguen, con la excepción de que el valor
rn
no debe
seleccionarse a menos que se haya elegido el valor
nrn
:
i)
rn
^ (nr): Se solicita una
notificación de recepción
^ en
circunstancias prescritas en el
8
.
ii)
nrn
^ (nnr): Se solicita una
notificación de no recepción
^ en las
circunstancias prescritas en el
8
.
iii)
ipm-return
^ (devolución de MIP): Se solicita que se
devuelva el MIP en cualquier
notificación de no recepción
.
c)
Respuesta solicitada
(D falso): Indica si se solicita o
no una respuesta del destinatario preferido designado por el componente
destinatario. Es un booleano.
Una
respuesta
es un MIP enviado en respuesta a otro. Un
usuario puede responder a un MIP aunque no se haya pedido una respuesta y, en
efecto, incluso si él no figura entre los destinatarios preferidos del MIP.
Además, un usuario al que se le ha pedido una respuesta, puede dejar de
responder.
7.1.3
Descriptor O/D
Un
descriptor O/D
es un elemento de información que
identifica un usuario o LD.
ORDescriptor ::= SET { formal-nameORName OPTIONAL, Free-form-name[0]FreeFormName OPTIONAL, telephone-number[1]telephoneNumber OPTIONAL^}
Un descriptor O/D tiene los siguientes componentes:
a)
Nombre formal
(C): Identifica al usuario o LD en
cuestión. Es uno de sus nombres O/D.
Este componente condicional estará presente si se satisfacen uno o más de los criterios que se indican a continuación (pero puede también estar presente en el caso contrario):
i)El componente
nombre de forma libre
^ está ausente.
ii)El descriptor O/D aparece en el campo de encabezamiento
destinatarios de respuesta
.
iii)El descriptor O/D es el componente destinatario de un especificador de destinatario, y se satisfacen las condiciones indicadas en el apartado a) del 7.1.2 .
b)
Nombre de forma libre
FreeFormName ::= TeletexString (SIZE (0.^.ub-free-form-name))
c)
Número de teléfono
TelephoneNumber ::= PrintableString (SIZE (0.^.ub-telephone-number))
Nota
- Pueden aparecer uno o más descriptores O/D en
cada uno de los siguientes campos de encabezamiento: originador, usuarios
autorizantes, destinatarios primarios, destinatarios de copia, destinatarios de
copia ciega, y destinatarios de respuesta. Además, puede aparecer un descriptor
O/D en los siguientes campos de notificación (véase el
8
):
Originador de NIP y destinatario preferido de MIP.
7.2
Campos de encabezamiento
Los campos que pueden aparecer en el encabezamiento de un MIP son los definidos y descritos a continuación.
Heading ::= SET { this-IPMThisIPMField, originator[0]OriginatorField OPTIONAL, authorizing-users[1]AuthorizingUsersField OPTIONAL, primary-recipients[2]PrimaryRecipientsField DEFAULT {^}, copy-recipients[3]CopyRecipientsField DEFAULT {^}, blind-copy-recipients[4]BlindCopyRecipientsField OPTIONAL, replied-to-IPM[5]RepliedToIPMField OPTIONAL, obsoleted-IPMs[6]ObsoletedIPMsField DEFAULT {^}, related-IPMs[7]RelatedIPMsField DEFAULT {^}, subject[8]EXPLICIT SubjectField OPTIONAL, expiry-time[9]ExpiryTimeField OPTIONAL, reply-time[10]ReplyTimeField OPTIONAL, reply-recipients[11]ReplyRecipientsField OPTIONAL, importance[12]ImportanceField DEFAULT normal, sensitivity[13]SensitivityField OPTIONAL, auto-forwarded[14]AutoForwardedField DEFAULT FALSE, extensions[15]ExtensionsField DEFAULT {^}^}
Algunos campos tienen componentes siendo por tanto compuestos, y no
indivisibles. Un componente de un campo se denomina
subcampo
.
7.2.1
Este MIP
El campo de encabezamiento
este MIP
(O) identifica el
MIP. Comprende un identificador de MIP.
ThisIPMField ::= IPMIdentifier
7.2.2
Originador
El campo de encabezamiento
originador
(F) identifica el
originador del MIP. Comprende un descriptor O/D.
OriginatorField ::= ORDescriptor
7.2.3
Usuarios autorizantes
El campo de encabezamiento
usuarios autorizantes
(C)
identifica a los cero o más usuarios que son los
usuarios
autorizantes
del MIP. Comprende una secuencia de subcampos, siendo cada
uno de ellos un descriptor O/D, uno para cada uno de esos usuarios.
AuthorizingUsersField ::= SEQUENCE OF AuthorizingUsersSubfield
AuthorizingUsersSubfield ::= ORDescriptor
Un
usuario autorizante
es un usuario que, sea
individualmente o en concierto con otros, autoriza la originación de un MIP. La
palabra
`autoriza'
utilizada anteriormente no se define con precisión en
esta Recomendación; su significado se lo dan los usuarios.
Este campo condicional estará presente únicamente si los usuarios autorizantes son otros distintos del originador del MIP.
Nota
- Supóngase, por ejemplo, que un director da
instrucciones a su secretario(a) para que origine un MIP en su nombre. En este
caso, el(la) secretario(a), que es el originador del MIP, podría considerar que
el director es el usuario autorizante.
7.2.4
Destinatarios primarios
El campo de encabezamiento
destinatarios primarios
(D
sin subcampos, es decir, elementos) identifica a los cero o más usuarios y LD
que son los
`destinatarios primarios'
del MIP. Identifica también las
respuestas que los usuarios autorizantes solicitan de cada uno de esos usuarios
y de cada miembro de esas LD. Comprende una secuencia de subcampos, cada uno de
los cuales es un especificador de destinatario, uno para cada destinatario
primario.
PrimaryRecipientsField ::= SEQUENCE OF PrimaryRecipientsSubfield
PrimaryRecipientsSubfield ::= RecipientSpecifier
La frase
`destinatarios primarios'
utilizada anteriormente no está
definida con precisión en esta Recomendación; su significado se lo dan los
usuarios.
Nota
- Los destinatarios primarios, por ejemplo,
pudieran ser los usuarios y las LD, cuyos miembros se espera actúen sobre el
MIP.
7.2.5
Destinatarios de copia
El campo de encabezamiento
destinatarios de copia
(D sin
subcampos, es decir, elementos) identifica a los cero o más usuarios y LD que
son los
`destinatarios de copia'
del MIP. Identifica también las
respuestas que los usuarios autorizantes solicitan de cada uno de esos usuarios
y de cada miembro de esas LD. Comprende una secuencia de subcampos, cada uno de
los cuales es un especificador de destinatario, uno para cada destinatario de
copia.
CopyRecipientsField ::= SEQUENCE OF CopyRecipientsSubfield
CopyRecipientsSubfield ::= RecipientSpecifier
La frase
`destinatarios de copia'
no está definida con precisión en
esta Recomendación; su significado se lo dan los usuarios.
Nota
- Los destinatarios de copia, por ejemplo,
podrían ser los usuarios a los cuales se transfiere el MIP para información, o
las LD a cuyos miembros se transfiere el MIP para información.
7.2.6
Destinatarios de copia ciega
El campo de encabezamiento
destinatarios de copia ciega
(C) identifica a los cero o más usuarios y LD que son los
`destinatarios'
de copia
ciega
previstos del MIP.
Identifica también las respuestas que los usuarios autorizantes solicitan de
cada uno de esos usuarios y de cada miembro de esas LD. Comprende una secuencia
de subcampos siendo cada uno de ellos un especificador de destinatario, uno
para cada destinatario de copia
ciega
.
BlindCopyRecipientsField ::= SEQUENCE OF BlindCopyRecipientsSubfield
BlindCopyRecipientsSubfield ::= RecipientSpecifier
La frase
`destinatarios de copia'
que aparece anteriormente tiene el
mismo significado que en el
7.2.5
. Un destinatario de copia
ciega
es un destinatario cuyo rol no se revela a los
destinatarios primarios ni a los de copia.
En el caso de un MIP previsto para un destinatario de copia ciega, este campo condicional estará presente e identificará a ese usuario o LD. El que deba o no identificar también a los otros destinatarios de copia ciega es un asunto local. En el caso de un MIP previsto para un destinatario primario o un destinatario de copia, este campo estará ausente o no identificará ningún usuario ni LD.
7.2.7
MIP contestado
El campo de encabezamiento
MIP contestado
(C) identifica
al MIP al cual responde el presente MIP. Comprende un identificador de MIP.
RepliedToIPMField ::= IPMIdentifier
Este campo condicional estará presente únicamente si el MIP es una respuesta.
Nota
- En el contexto de
retransmisión
, debe distinguirse cuidadosamente entre el
MIP retransmisor
y el
MIP
retransmitido
. Este campo debe identificar a cuál de estos dos MIP
corresponde la respuesta.
7.2.8
MIP obsoletos
El campo de encabezamiento
MIP obsoletos
(D sin
subcampos, es decir, elementos) identifica a los cero o más MIP que los
usuarios autorizantes del presente MIP consideran obsoletos por este MIP.
Comprende una secuencia de subcampos, siendo cada uno de ellos un identificador
de MIP, uno para cada MIP.
ObsoletedIPMsField ::= SEQUENCE OF obsoletedIPMSubfield
ObsoletedIPMsSubfield ::= IPMIdentifier
Nota
- En el contexto de
retransmisión
, debe tenerse cuidado de distinguir entre el
MIP retransmisor
y el
MIP
retransmitido
. Este campo debe identificar cuál de estos dos MIP se hace
obsoleto por el presente MIP.
7.2.9
MIP relacionados
El campo de encabezamiento
MIP relacionados
(D sin
subcampos, es decir, elementos) identifica a los cero o más MIP que el usuario
autorizante del presente MIP considera relacionados con este MIP. Comprende una
secuencia de subcampos, cada uno de los cuales es un identificador de MIP, uno
para cada MIP.
RelatedIPMsField ::= SEQUENCE OF RelatedIPMsSubfield
RelatedIPMsSubfield ::= IPMIdentifier
La palabra
`relacionados'
, utilizada anteriormente, no está definida
con precisión en esta Recomendación; su significado se lo dan los usuarios.
Nota 1
- Un MIP relacionado podría ser, por ejemplo,
uno examinado en el cuerpo del MIP presente.
Nota 2
- En el contexto de
retransmisión
, debe distinguirse cuidadosamente entre el
MIP retransmisor
y el
MIP
retransmitido
. Este campo debe identificar cuál de estos dos MIP está
relacionado con el presente MIP.
7.2.10
Asunto
El campo de encabezamiento
asunto
(F) identifica el
asunto del MIP. Es una cadena teletex de cero a un número prescrito de
caracteres (véase el anexo K), tomados del subjuego gráfico del juego de
caracteres de cadena teletex. Se desaconseja una longitud cero.
SubjectField ::= TeletexString (SIZE (0.^.ub-subject-field))
7.2.11
Hora de expiración
El campo de encabezamiento
hora de expiración
(F)
identifica cuándo los usuarios autorizantes consideran que el MIP pierde su
validez. Comprende una fecha y una hora.
ExpiryTimeField ::= Time
7.2.12
Hora de respuesta
El campo de encabezamiento
hora de respuesta
(F)
identifica el momento hasta el cual los usuarios autorizantes solicitan (pero
no exigen) que se originen las eventuales respuestas al presente MIP. Comprende
una fecha y una hora.
ReplyTimeField ::= Time
7.2.13
Destinatarios de respuesta
El campo de encabezamiento
destinatarios de respuesta
(C) identifica a los cero o más usuarios y LD a los cuales los usuarios
autorizantes piden (pero no les exigen) que estén entre los destinatarios
preferidos de las eventuales respuestas al presente MIP. Comprende una
secuencia de subcampos, cada uno de los cuales es un descriptor O/D, uno para
cada usuario o LD.
ReplyRecipientsField ::= SEQUENCE OF ReplyRecipientsSubfield
ReplyRecipientsSubfield ::= ORDescriptor
Este campo condicional estará presente únicamente si los destinatarios de respuesta deseados no son el originador del presente MIP.
Nota
- Si este campo está presente e identifica a
varios usuarios y LD el originador puede incluirse él mismo entre ellos. Si
opta por no hacerlo, no se le considerará entre los destinatarios de copia
deseados.
7.2.14
Importancia
El campo de encabezamiento
importancia
(D
normal
) identifica la importancia que los usuarios
autorizantes atribuyen al MIP. Puede adoptar uno de los siguientes valores:
baja
,
normal
, o
alta
.
ImportanceField ::= ENUMERATED^{ low (0), normal (1), high (2)^}
Los valores indicados más arriba no están definidos en esta Recomendación; su significado se los dan los usuarios.
7.2.15
Sensibilidad
El campo de encabezamiento
sensibilidad
(C) identifica
la sensibilidad que los usuarios autorizantes atribuyen al MIP.
SensitivityField ::= ENUMERATED^{ personal (1), private (2), company-confidential (3)^}
Este campo puede adoptar uno de los siguientes valores:
a)
personal
^: El MIP es transportado a los destinatarios
preferidos en su carácter de individuos, y no en el de sus capacidades
profesionales.
b)
privado
^: El MIP debe transportarse a los
destinatarios preferidos, y no a otros.
c)
confidencial de empresa
^: El MIP contiene información
que sólo debe tratarse de acuerdo con procedimientos especiales de la empresa.
Este campo condicional estará presente únicamente si el MIP es sensible.
7.2.16
Retransmitido automáticamente
El campo de encabezamiento
retransmitido automáticamente
(D
falso
) indica si el MIP es o no el resultado de
retransmisión automática
. Es un
booleano.
AutoForwardedField ::= BOOLEAN
7.2.17
Ampliaciones
El campo de encabezamiento
ampliaciones
(D no
ampliaciones
, es decir, marcas) transporta una información
que no esta contenida en ningún otro campo de encabezamiento. Comprende un
conjunto de cero o más
ampliaciones de encabezamiento
(o
ampliaciones
), cada una de las cuales transporta un elemento
de esa información.
ExtensionsField ::= SET OF HeadingExtension
HeadingExtension ::= SEQUENCE^{ type OBJECT IDENTIFIER, value ANY DEFINED BY type DEFAULT NULL NULL^}
Cada ampliación tiene los siguientes componentes:
a)
Tipo
(O): Identifica la semántica y restringe la
sintaxis abstracta del componente
valor
. Es un
identificador de objeto.
b)
Valor
(D nulo): Elemento de información cuya sintaxis
abstracta sólo está restringida por el componente tipo. Es un Any.
Los componentes tipo de todas las ampliaciones del campo ampliaciones deberán ser diferentes unos de otros. No es necesario que cada ampliación definida aparezca en el campo.
Todas las ampliaciones se definen en el anexo A. Así, cada componente tipo de la ampliación tendrá uno de los valores indicados en ese anexo. Una ampliación cuyo componente tipo tenga otro valor deberá ser ignorada.
Toda ampliación se define por medio de la siguiente macro.
HEADING-EXTENSION MACRO ::=
BEGIN
TYPENOTATION ::=
"VALUE"
type | empty
VALUENOTATION ::= value (VALUE OBJECT IDENTIFIER)
END
Un caso de notación de tipo de la macro identifica el tipo de datos al cual estará circunscrito el componente valor de la ampliación. Si no se identifica explícitamente ningún tipo, se supone nulo.
Un caso de notación de valor de la macro identifica el identificador de objeto que aparecerá como el componente tipo de la amplicación.
Nota
- En futuras versiones de esta Recomendación se
podrán definir ampliaciones adicionales. Además, es probable que, en las
futuras versiones, se añada información sólo por medio de este campo.
7.3
Tipos de parte de cuerpo
A continuación se describen y definen los tipos de parte de cuerpo que pueden aparecer en el cuerpo de un MIP.
BodyPart ::= CHOICE^{ ia5-text[0]IA5TextBodyPart, voice[2]VoiceBodyPart, g3-facsimile[3]G3FacsimileBodyPart, g4-class1[4]G4Class1BodyPart, teletex[5]TeletexBodyPart, videotex[6]VideotexBodyPart, encrypted[8]EncryptedBodyPart, message[9]MessageBodyPart, mixed-mode[11]MixedModeBodyPart, bilaterally-defined[14]BilaterallyDefinedBodyPart, nationally-defined[7]NationallyDefinedBodyPart, externally-defined[15]ExternallyDefinedBodyPart^}
Las partes de cuerpo de algunos tipos definidos más adelante tienen dos
componentes:
parámetros
y
datos
. El
componente
parámetro
(O) comprende una secuencia de
elementos de información que describen el objeto de información representado
por la parte de cuerpo y que típicamente son parámetros de formato y de
control. El componente
datos
(O) es el objeto de información
propiamente dicho.
Nota 1
- En la Recomendación X.420 (1984), los rótulos
específicos del contexto 1 y 10 indican partes de cuerpo telex y documento
formateable simple, respectivamente, que ya no están definidas. Por tanto, en
la parte de cuerpo se evita el empleo de estos rótulos.
Nota 2
- En ciertas circunstancias, un MIP puede
experimentar una conversión en su tránsito entre los usuarios. Tal suceso de
transferencia puede alterar un tipo de parte de cuerpo.
7.3.1
Texto AI5
Una parte de cuerpo
texto AI5
representa texto
construido con caracteres del AI5. Tiene componentes parámetros y datos.
IA5TextBodyPart ::= SEQUENCE^{ parameters IA5TextParameters, data IA5TextData^}
IA5TextParameters ::= SET^{ repertoire [0] Repertoire DEFAULT ia5^}
IA5TextData ::= IA5String
El componente parámetros comprende los siguientes parámetros:
a)
Repertorio
(D
AI5
): Identifica el
juego de caracteres a que está limitado el componente Datos.
Repertoire ::= ENUMERATED^{ ita2 (2), ia5^ (5)^}
Este parámetro puede adoptar uno cualquiera de los siguientes valores:
i)
ATI2
^: El componente datos estará limitado al juego
de caracteres del ATI2 (es decir telex).
ii)
AI5
^: El componente datos puede tomar caracteres del
juego completo de caracteres del AI5.
El componente datos es el texto, una cadena AI5. Puede contener líneas de cualquier longitud. Siempre que se reproduzca este componente (por ejemplo, en una pantalla o en una impresora para un usuario), deberá presentarse la totalidad del texto (y no una parte del mismo; por ejemplo, las líneas podrán dividirse de modo que continúen en el renglón siguiente, pero no podrán truncarse).
Nota
- Muchos terminales tienen una longitud de línea
máxima de 80 caracteres. En consecuencia, las líneas cuya longitud no sea
superior a ésta probablemente se presenten satisfactoriamente (por ejemplo, lo
más probable es que no serán divididas).
7.3.2
Voz
Una parte de cuerpo
voz
representa conversación. Tiene
componentes parámetros y datos.
VoiceBodyPart ::= SEQUENCE^{ parameters VoiceParameters, data VoiceData^}
VoiceParameters ::= SET --
para ulterior estudio
VoiceData ::= BIT STRING --
para ulterior estudio
Los parámetros de tal parte de cuerpo, y la técnica de codificación de la conversación digitalizada que esos parámetros pudieran identificar y parametrizar serán objeto de ulterior estudio.
El componente datos es la conversación, una cadena de bits.
7.3.3
Facsímil G3
Una parte de cuerpo
facsímil G3
representa imágenes
facsímil del grupo 3. Tiene componentes parámetros y datos.
G3FacsimileBodyPart ::= SEQUENCE^{ parameters G3FacsimileParameters, data G3FacsimileData^}
G3FacsimileParameters ::= SET^{ number-of-pages[0]INTEGER OPTIONAL, non-basic-parameters[1]G3FascimileNonBasicParameters OPTIONAL^}
G3FacsimileData ::= SEQUENCE OF BIT STRING
El componente parámetros comprende los siguientes parámetros:
a)
Número-de-páginas
(F): Identifica el número de páginas
de datos facsímil del grupo 3 presentes en el componente datos. Es un entero no
negativo.
b)
Parámetros-no-básicos
(C): Identifica los parámetros no
básicos (PNB) para el facsímil del grupo 3 que caracterizan al componente
datos. Es un descriptor de PNB G3.
Este parámetro condicional estará presente si el cuerpo contiene dos o más partes de cuerpo facsímil G3 (pero puede también estar presente en otro caso).
El componente datos lo forman las imágenes facsímil, que son una secuencia de cadenas de bits, cada una de las cuales codifica una sola página de datos facsímil del grupo 3, como se especifica en las Recomendaciones T.4 y T.30.
Nota 1
- El componente número-de-páginas identifica el
número de elementos en la secuencia que constituye el componente datos y es por
tanto redundante.
Nota 2
- Si el cuerpo comprende una sola de estas
partes de cuerpo, sus PNB pueden (pero no están obligados a) ser transportados
por medio de la envolvente del mensaje que contiene el MIP.
7.3.4
G4 Clase 1
Una parte de cuerpo
G4 Clase 1
representa un documento
en forma final del género que puede ser procesado por terminales facsímil del
grupo 4 clase 1. Comprende una secuencia de elementos de protocolo que
describen la estructura de la disposición del documento.
G4Class1BodyPart ::= SEQUENCE OF ProtocolElement
7.3.5
Teletex
Una parte de cuerpo
teletex
representa un documento
teletex. Tiene componentes parámetros y datos.
TeletexBodyPart ::= SEQUENCE^{ parameters TeletexParameters, data TeletexData^}
TeletexParameters ::= SET^{ number-of-pages[0]INTEGER OPTIONAL, telex-compatible[1]BOOLEAN DEFAULT FALSE, non-basic-parameters[2]TeletexNonBasicParameters OPTIONAL^}
TeletexData ::= SEQUENCE OF TeletexString
El componente parámetros comprende los siguientes parámetros:
a)
Número-de-páginas
(F): Identifica el número de páginas
del texto teletex presentes en el componente datos. Es un entero no negativo.
b)
Compatible-telex
(D
falso
): Indica
si el documento en el componente datos es o no compatible con el telex. Es un
booleano.
Si este parámetro tiene el valor
verdadero
(
true
), cada cadena teletex en el componente datos estará
limitada al juego de caracteres del AIT2. Ninguna línea tendrá una longitud
superior a 69 caracteres.
c)
Parámetros-no-básicos
(C): Identifica los PNB para
teletex que caracterizan el componente datos. Es un descriptor PNB teletex.
Este parámetro condicional estará presente si el cuerpo contiene dos o más partes de cuerpo teletex (pero puede también estar presente en otro caso).
El componente datos es el documento, una Secuencia de cadenas teletex, cada una de las cuales codifica una de sus páginas.
Nota 1
- El componente número-de-páginas identifica el
número de elementos en la secuencia que constituye el componente datos, y es
por tanto redundante.
Nota 2
- Si el cuerpo comprende una sola parte de
cuerpo, sus PNB pueden (pero no tienen necesariamente que) ser transportados
por medio del sobre del mensaje que contiene el MIP.
7.3.6
Videotex
Una parte de cuerpo
videotex
representa datos videotex.
Tiene componentes parámetros y datos.
VideotexBodyPart ::= SEQUENCE^{ parameters VideotexParameters, data VideotexData^}
VideotexParameters ::= SET^{ syntax [0] VideotexSyntax OPTIONAL^}
VideotexData ::= VideotexString
El componente parámetro comprende los siguientes parámetros:
a)
Sintaxis
(F): Identifica la sintaxis del componente
datos. Cuando no hay parámetros, se considera que la sintaxis no está
especificada.
VideotexSyntex ::= INTEGER^{ ids (0), data-syntax1 (1), data-syntax2 (2), data-syntax3 (3)^}
Este parámetro puede adoptar uno de los siguientes valores, cada uno de los cuales designa una de las sintaxis videotex definidas en las Recomendaciones T.100 y T.101:
i)
sdi
^: Sintaxis de datos de interfuncionamiento
(sintaxis SDI).
ii)
sintaxis-de-datos1
^: Sintaxis de datos 1.
iii)
sintaxis-de-datos2
^: Sintaxis de datos 2.
iv)
sintaxis-de-datos3
^: Sintaxis de datos 3.
El componente datos está constituido por los datos videotex, que constituyen una cadena videotex. Se ajustará a la sintaxis videotex designada por el parámetro sintaxis.
7.3.7
Cifrado
Una parte de cuerpo
cifrado
representa el resultado de
cifrar una parte de cuerpo de un tipo definido por esta Recomendación. Tiene
componentes parámetros y datos.
EncryptedBodyPart ::= SEQUENCE^{ parameters EncryptedParameters, data EncryptedData^}
EncryptedParameters ::= SET --
para ulterior estudio
EncryptedData ::= BIT STRING --
para ulterior estudio
Los parámetros de esta parte de cuerpo, y la técnica de cifrado que estos parámetros pudieran identificar y parametrizar, quedan para ulterior estudio.
El componente datos es la parte de cuerpo cifrada, formada por una cadena de bits. Los bits de la cadena cifrarán un valor de datos del tipo BodyPart (NSA.1) codificado de acuerdo con las reglas básicas de codificación de la Recomendación X.209.
7.3.8
Mensaje
Una parte de cuerpo
mensaje
representa un MIP y,
facultativamente, su sobre de entrega. Tiene componentes parámetros y datos.
MessageBodyPart ::= SEQUENCE^{ parameters MessageParameters, data MessageData^}
MessageParameters ::= SET^{ delivery-time[0]MessageDeliveryTime OPTIONAL, delivery-envelope[1]OtherMessageDeliveryFields OPTIONAL^}
MessageData ::= IPM
El componente parámetros comprende los siguientes parámetros.
a)
Hora-de-entrega
(F): Fecha y hora en que fue entregado
el MIP. Se desaconseja la presencia de este componente estando ausente el
componente sobre de entrega.
b)
Sobre-de-entrega
(F): Los demás campos de entrega de
mensaje del MIP. Se desaconseja la presencia de este componente en ausencia del
componente hora-de-entrega.
El componente datos es el MIP.
La inclusión de un MIP dentro de otro como se describe en el presente punto
se denomina
retransmisión
de ese MIP. El MIP englobante se
denomina
MIP retransmisor
, el MIP englobado se denomina el
MIP retransmitido
.
Nota 1
- La posible inclusión en el futuro de
identificador de mensaje en el componente parámetros queda para ulterior
estudio. Su omisión presente proporciona la compatibilidad con la Recomendación
X.420 (1984).
Nota 2
- No se verifica el que el MIP y el sobre de
entrega contemplado de una parte de cuerpo mensaje sean, en todo sentido,
genuinos.
7.3.9
Modo mixto
Una parte de cuerpo
modo mixto
representa un documento
en forma final de género que puede ser procesado por terminales teletex modo
mixto y terminales facsímil del grupo 4, clases 2 y 3. Está constituida por una
secuencia de elementos de protocolo que describen la estructura de disposición
del documento.
MixedModeBodyPart ::= SEQUENCE OF ProtocolElement
7.3.10
Definida bilateralmente
Una parte de cuerpo
definida bilateralmente
representa
un objeto de información cuya semántica y sintaxis abstracta son
convenidas bilateralmente
por el originador y todos los
destinatarios potenciales del MIP. Está constituida por una cadena de octetos.
BilaterallyDefinedBodyPart ::= OCTET STRING
Nota
- Se desaconseja el uso de este tipo de parte de
cuerpo. Ella antedata el tipo de parte de cuerpo definido externamente y se
mantiene con miras a la compatibilidad descendente con la Recomendación X.420
(1984). El tipo de parte de cuerpo definido externamente proporciona las mismas
capacidades, y otras más, y se prefiere su uso, por ejemplo, porque en el mismo
se distingue claramente entre las partes de cuerpo definidas por una comunidad
de usuarios y las definidas por otra.
7.3.11
Definida nacionalmente
Una parte de cuerpo
definida nacionalmente
representa un
objeto de información cuya semántica y sintaxis abstracta están definidas
nacionalmente por un país cuya identidad está
convenida
bilateralmente
por el originador y todos los destinatarios potenciales del
MIP. Está constituida por un tipo Any.
NationallyDefinedBodyPart ::= ANY
Nota 1
- Este tipo de parte de cuerpo está destinado a
ser utilizado en comunicación dentro de un mismo país, siendo el país en
cuestión, implícitamente el del originador y el de todos los destinatarios
potenciales.
Nota 2
- Se desaconseja la utilización de este tipo de
parte de cuerpo. Ella antedata el tipo de parte de cuerpo definido externamente
y se mantiene con miras a la compatibilidad descendente con la Recomendación
X.420 (1984). El tipo de parte de cuerpo definido externamente proporciona las
mismas capacidades, y otras más, y su uso se prefiere, por ejemplo, porque en
el mismo distingue claramente entre las partes de cuerpo definidas por un país
y las definidas por otro.
7.3.12
Definida externamente
Una parte de cuerpo
definida externamente
representa un
objeto de información cuya semántica y sintaxis abstracta son designadas por un
identificador de objeto transportado en la parte de cuerpo. Tiene componentes
parámetros y datos.
ExternallyDefinedBodyPart ::= SEQUENCE^{ parameters [0] ExternallyDefinedParameters OPTIONAL, data ExternallyDefinedData^}
ExternallyDefinedParameters ::= EXTERNAL
ExternallyDefinedData ::= EXTERNAL
Los componentes parámetros y datos son externos (véase el 32 de la Recomendación X.208). Sus componentes referencia-directa deben estar presentes, y sus componentes referencia-indirecta y descriptor-de-valor-de-datos estarán ausentes.
Sobre la base del tipo de parte de cuerpo definida externamente, todos los tipos de parte de cuerpo se dividen en las dos importantes clases siguientes:
a)
básico
: contiene cualquier tipo de parte de cuerpo,
excepto definida externamente. Se designa por un entero (un rótulo NSA.1
específico del contexto).
Todos los tipos de parte de cuerpo básicos se definen en esta Recomendación.
b)
ampliado
: contiene el tipo de parte de cuerpo definida
externamente, limitado a uno cualquiera de los valores del componente
referencia-directa del componente datos de tal parte de cuerpo. Se designa por
un identificador de Objeto.
Algunos (pero no necesariamente todos) los tipos de parte de cuerpo ampliado se definen en el anexo B de esta Recomendación.
Cada tipo de parte de cuerpo ampliado que define esta Recomendación está definido por medio de la siguiente macro. Cada tipo de parte de cuerpo ampliado definido en otro lugar deberá también ser definido.
EXTENDED-BODY-PART-TYPE MACRO ::= BEGIN TYPENOTATION::= Parameters Data VALUENOTATION::= value (VALUE OBJECT IDENTIFIER)
Parameters::=
"PARAMETERS"
type
"IDENTIFIED"
"BY"
value
(OBJECT
::= IDENTIFIER) | empty
Data::=
"DATA"
type
END
Un caso de notación de tipo de la macro define, por medio de su cláusula PARáMETROS, el tipo del valor de datos que es representado por el componente parámetros del tal parte de cuerpo (definida externamente) (un tipo externo) y el identificador de objeto que aparece en el componente referencia-directa de este componente de parámetros. La omisión del componente de parámetros va implicada por la omisión de esta cláusula. Un caso de notación del tipo define también, por medio de su cláusula DATOS, el tipo del valor de datos representado por el componente datos de tal parte de cuerpo (un tipo externo).
Un caso de la notación de valor de la macro define el identificador de objeto que aparece como el componente referencia-directa del componente datos de tal parte de cuerpo (definida externamente). El identificador de objeto identifica las reglas de codificación para la parte de cuerpo. Aquellas partes de cuerpo cuyos tipos están definidos en esta Recomendación se codificarán utilizando las reglas básicas de codificación de NSA.1.
Nota 1
- Este tipo de parte de cuerpo permite el
intercambio de objetos de información de todas clases, cada uno de los cuales
está identificado de manera inequívoca y única. Esta identificación se basa en
el componente referencia-directa mencionado anteriormente, que es un
identificador de objeto. Los identificadores de objeto se obtienen fácilmente,
por ejemplo, por los organismos nacionales y organizaciones privadas.
Nota 2
- Si una parte de cuerpo definida externamente
posee un componente parámetros, el identificador de objeto de su componente
referencia-directa se asigna al mismo tiempo y por la misma autoridad
denominadora que la del componente de referencia-directa del componente datos.
Nota 3
- Al igual que las partes de cuerpo de otros
tipos, una parte de cuerpo definida externamente puede ser objeto de una
conversión. Sin embargo, la especificación del algoritmos de conversión pueden
estar fuera del ámbito de la Recomendación X.408 del CCITT.
Nota 4
- Los tipos básicos de parte de cuerpo existen
por razones puramente históricas, antedatando el tipo de parte de cuerpo
definida externamente.
8
Notificaciones
interpersonales
Una
notificación interpersonal (NIP)
es un miembro de
una clase secundaria de objetos de información transportado entre usuarios en
mensajería interpersonal.
IPN ::= SET^{ -- common-fields -- COMPONENTS OF CommonFields, choice [0] CHOICE^{ non-receipt-fields [0] NonReceiptFields, receipt-fields [1] ReceiptFields^}^}
Una NIP puede adoptar una de las formas siguientes:
a)
notificación-de-no-recepción (NNR)
: NIP que informa al
originador de un MIP que dicho mensaje no se recibirá, no se aceptará o se
recibirá con retardo.
NRN ::= IPN --
con campos-de-no-recepción elegidos
b)
notificación de recepción (NR)
: NIP que informa al
originador de un MIP que éste ha sido recibido, o que se espera y está
dispuesta su futura recepción.
RN ::= IPN --
con campos-de-recepción elegidos
El MIP al que se refiere una NIP se denomina
MIP asunto
.
Sólo un AU al que se entrega efectivamente el MIP asunto originará una NIP
relacionada con dicho MIP, y originará, como máximo, una tal NIP que deberá ser
transportada al originador del MIP asunto.
Un destinatario efectivo deberá originar una NIP solamente de acuerdo con
el componente peticiones de notificación del
especificador
de destinatario asunto
. El
especificador de destinatario asunto
es el especificador de
destinatario en el encabezamiento del MIP asunto, como resultado del cual se
entrega a ese usuario el MIP asunto.
Se determina el especificador de destinatario asunto examinando las secuencias de especificadores de destinatario que constituyen los campos de encabezamiento destinatarios primarios, destinatarios de copia y destinatarios de copia ciega del MIP asunto. Los campos se examinan en el orden en que son mencionados en el párrafo anterior. Dentro de cada campo, los especificadores se examinan en el orden en que allí aparecen. El especificador de destinatario asunto es el primero encontrado cuyo componente destinatario tiene como valor un descriptor O/D cuyo componente nombre formal está presente y tiene como valor, bien un nombre O/D del destinatario preferido, como resultado del cual el MIP asunto fue entregado al usuario a cuyo nombre se efectuó el examen, o bien, si el usuario recibe el MIP por figurar en una LD, un nombre O/D que aparece en la historia de ampliación de la LD del mensaje (véase el 8.3.1.1.1.7 de la Recomendación X.411).
Una NIP consta de un conjunto de elementos de información denominados
campos de notificación
(o
campos
), cada
uno de los cuales es de una de las clases siguientes:
a)
campo común
: Campo de notificación aplicable a las NNR
y las NR.
b)
campo de no recepción
: Campo de notificación aplicable
a las NNR solamente.
c)
campo de recepción
: Campo de recepción aplicable a las
NR solamente.
La estructura de una NIP se describe en la figura 2/X.420.
A continuación se definen y describen los campos, de cada una de las clases mencionadas, que puedan aparecer en una NIP.
8.1
Campos comunes
A continuación se definen y describen los campos comunes:
CommonFields ::= SET^{ subject-ipmSubjectIPMField, ipn-originator[1]IPNOriginatorField OPTIONAL, ipm-preferred-recipient[2]IPMPreferredRecipientField OPTIONAL, conversion-eitsConversionEITsField OPTIONAL^}
8.1.1
MIP asunto
El campo común
MIP asunto
(O) identifica el MIP asunto.
Consta de un identificador de MIP.
SubjectIPMField ::= IPMIdentifier
8.1.2
Originador de NIP
El campo común
originador de NIP
(F) identifica el
originador de la NIP. Consta de un descriptor O/D.
IPNOriginatorField ::= ORDescriptor
Si el originador de la NIP es un destinatario preferido del MIP asunto, el descriptor O/D antes mencionado deberá ser exactamente el que es el valor del componente destinatario del especificador del destinatario asunto.
Figure 2/X.420, (N), p.
8.1.3
Destinatario preferido de MIP
El campo común
destinatario preferido de MIP
(C)
identifica el destinatario preferido del MIP asunto que da lugar a su entrega
al originador de la NIP (que será un destinatario alternativo, miembro de una
LD o sustituto). Consta de un descriptor O/D.
IPMPreferredRecipientField ::= ORDescriptor
El descriptor O/D mencionado será exactamente el que es el valor del componente destinatario del especificador de destinatario asunto.
Este campo condicional estará presente si y sólo si identificase a un usuario que no fuese el originador de la NIP o una LD.
8.1.4
TIC de conversión
El campo común
TIC de conversión
(C) identifica los TIC
del MIP asunto al efectuarse la entrega al originador de la NIP. Consta de un
descriptor de TIC.
ConversionEITsField ::= EncodedInformationTypes
Este campo condicional estará presente si y sólo si el MIP estaba sujeto a una conversión para entrega del originador de la NIP.
8.2
Campos de no recepción
A continuación se definen y describen los campos de no recepción:
NonReceiptFields ::= SET^{ non-receipt-reason[0]NonReceiptReasonField, discard-reason[1]DiscardReasonField OPTIONAL, auto-forward-comment[2]AutoForwardCommentField OPTIONAL, returned-ipm[3]ReturnedIPMField OPTIONAL^}
8.2.1
Motivo de no recepción
El campo de no recepción
motivo de no recepción
(O)
indica el motivo por el cual el originador de la NNR no ha recibido el MIP
asunto (aunque se le haya entregado).
NonReceiptReasonField ::= ENUMERATED^{ ipm-discarded (0), ipm-auto-forwarded (1)^}
Este campo puede adoptar uno de los siguientes valores:
a)
mip-descartado
^: El MIP fue descartado. Este caso es
objeto de una explicación ulterior por el campo motivo de descarte.
b)
mip-retransmitido-automáticamente
^: El MIP fue
retransmitido automáticamente. Este caso es objeto de una explicación ulterior
por el campo
comentario de retransmisión
automática
.
8.2.2
Motivo de descarte
El campo de no recepción
motivo de descarte
(C) indica
el motivo por el cual fue descartado el MIP asunto (después de su entrega al
originador de la NNR y antes de su recepción).
DiscardReasonField ::= ENUMERATED^{ ipm-expired (0), ipm-obsoleted (1), user-subscription-terminated (2)^}
Este campo puede adoptar uno de los siguientes valores:
a)
mix-expirado
^: Estaba en vigor descarte automático,
los MIP expirados se descartaban, y llegó el tiempo identificado por el campo
de encabezamiento hora de expiración del MIP asunto.
b)
mip-obsoleto
^: Estaba en vigor descarte automático,
los MIP obsoletos se estaban descartando, y el campo de encabezamiento MIP
absoletos de otro MIP, entregado al originador de las NNR, identificó el MIP
asunto.
c)
terminado-el-abono-del-usuario
^: El abono a
mensajería interpersonal del originador de la NNR ha terminado.
Este campo condicional estará presente únicamente si el campo motivo de no
recepción tiene el valor
mip-descartado
.
8.2.3
Comentario de retransmisión automática
El campo de no recepción
comentario de retransmisión
automática
(C) es una información suministrada previamente con esta
finalidad por el originador de la NNR. Consta de una cadena imprimible de cero
a un número prescrito de caracteres (véase el anexo K), tomados del juego de
caracteres de cadena imprimible. Se desaconseja una longitud de cero.
AutoForwardCommentField ::= AutoForwardComment
AutoForwardComment ::= PrintableString (SIZE (0.^.ub-auto-forward-comment)
El valor de este campo será exactamente el argumento del comentario de
retransmisión automática de la operación abstracta
cambio
retransmisión automática
, como resultado de la cual fue retransmitido
automáticamente el MIP.
Este campo condicional estará presente únicamente si el campo motivo de no
recepción tiene el valor
mip-retransmitido automáticamente
y se ha suministrado el argumento mencionado del comentario de retransmisión
automática.
8.2.4
MIP devuelto
El campo de no recepción
MIP devuelto
(C) es
precisamente el MIP asunto.
ReturnedIPMField ::= IPM
Este campo condicional estará presente únicamente si
devolución-mip
se encuentra entre los valores del
componente peticiones de notificación del especificador de destinatario asunto
y el MIP asunto no está sujeto a conversión para su entrega al originador de la
NNR.
8.3
Campos de recepción
A continuación se definen y describen los campos de recepción:
ReceiptFields ::= SET^{
receipt-time[0]ReceiptTimeField,
acknowledgment-mode[1]AcknowledgmentModeField DEFAULT manual,
suppl-receipt-info[2]SupplReceiptInfoField DEFAULT
""
^}
8.3.1
Hora de recepción
El campo de recepción
hora de recepción
(O) identifica
el momento en que el originador de la NR recibió el MIP asunto. Comprende una
fecha y una hora.
ReceiptTimeField ::= Time
8.3.2
Modo acuse de recibo
El campo de recepción
modo acuse de recibo
(D
manual
) identifica el modo según el cual se originó la NR.
AcknowledgmentModeField ::= ENUMERATED^{ manual (0), automatic (1)^}
Este campo puede adoptar uno de los valores siguientes:
a)
manual
^: La NR fue originada por medio de la
operación abstracta
generación NR
.
b)
automático
^: La NR fue originada como resultado de
acuse automático de recibo
.
8.3.3
Información de recepción suplementaria
El campo de recepción
información de recepción
suplementaria
(F) proporciona información suplementaria sobre la recepción
del MIP asunto por el originador de la NR. Comprende una cadena imprimible de
cero a un número prescrito de caracteres (véase la Recomendación X.411),
tomados del juego de caracteres de cadena imprimible.
SupplReceiptInfoField ::= SupplementaryInformation
SECCIóN 3 -
9 Visión de conjunto
Esta sección define el servicio abstracto que caracteriza la mensajería interpersonal, y describe el entorno en el cual este servicio se proporciona y utiliza. Para esta definición y descripción se utilizan los convenios de definición de servicio abstracto de la Recomendación X.407.
Esta sección trata de los siguientes puntos:
a)Tipos de objetos primarios.
b)Tipos de puertos primarios.
c)Operaciones abstractas.
d)Errores abstractos.
e)Otras capacidades.
10
Tipos de objetos
primarios
El entorno en que tiene lugar la mensajería interpersonal puede modelarse
como un objeto abstracto que en lo sucesivo se denominará el
entorno de mensajería interpersonal (EMIP)
.
ipme OBJECT ::= id-ot-ipme
El EMIP, cuando es redefinido (es decir, cuando se efectúa su descomposición funcional), puede considerarse que comprende objetos menores que interactúan por medio de puertos.
ipme-refinement REFINE ipme AS ipms origination [S] PAIRED WITH ipms-user reception [S] PAIRED WITH ipms-user management [S] PAIRED WITH ipms-user ipms-user-RECURRING ::= id-ref-primary
Los objetos menores se denominan
objetos primarios
de
mensajería interpersonal. Incluyen un objeto central único, el
sistema de mensajería interpersonal
(SMIP)
y numerosos objetos periféricos denominados
usuarios de sistema de mensajería interpersonal (usuarios
SMIP)
.
La estructura del EMIP se describe en la figura 3/X.420.
A continuación se definen y describen los tipos de objetos primarios. Los tipos de puertos a través de los cuales interactúan los tipos de objeto primario se examinan en el 11 .
Figure 3/X.420, (N), p.
10.1
Usuario de sistema de mensajería
interpersonal
Un
usuario de sistema de mensajeria interpersonal (usuario
SMIP)
es un usuario que interviene en mensajería interpersonal. Un usuario
SMIP origina, recibe, u origina y recibe, objetos de información de los tipos
definidos en la sección dos.
ipms-user OBJECT PORTS^{ origination [C], reception [C], management [C]^} ::= id-ot-ipms-user
El EMIP comprende cualquier número de usuarios SMIP.
Nota 1
- Como sugiere su nombre, la mensajería
interpersonal es típicamente una actividad de personas. Por esa razón, en esta
Recomendación se utilizan pronombres personales (por ejemplo,
`él'
) para
hacer referencia a usuarios SMIP. Sin embargo, esta práctica no tiene por
objeto la exclusión de otros usos, no típicos de la mensajería interpersonal,
en los cuales los usuarios SMIP no son personas.
Nota 2
- Por razones de brevedad, en la parte restante
de esta Recomendación, el término
`usuario'
se emplea con el significado
de
`usuario SMIP'
.
10.2
Sistema de mensajería interpersonal
El
sistema de mensajería interpersonal (SMIP)
es el
objeto por medio del cual todos los usuarios comunican unos con otros en
mensajería interpersonal.
ipms OBJECT PORTS^{ origination [S], reception [S], management [S]^} ::= id-ot-ipms
El EMIP comprende exactamente un SMIP.
11
Tipos de puertos
primarios
Los objetos primarios de la mensajería interpersonal están unidos entre sí,
e interactúan unos con otros por medio de puertos. Estos puertos, que son
suministrados por el SMIP, se denominan
puertos primarios
de
mensajería interpersonal. Son de los tres tipos definidos más adelante.
Nota
- En el
16
, el SMIP se descompone en
objetos aún menores, entre los cuales está el sistema de transferencia de
mensajes (STRM). Este hecho se ha tenido previamente en cuenta en la presente
sección por la inclusión de ciertas capacidades de STRM en el servicio
abstracto SMIP.
11.1
Generación
Un
puerto de generación
es el medio por el cual un solo
usuario transfiere al SMIP mensajes que contienen objetos de información de los
tipos definidos en la sección dos. A través de ese puerto, el usuario genera
mensajes interpersonales
y
notificaciones
de recepción
. Además, a través de tal puerto, el usuario puede generar
sondas.
El SMIP suministra un puerto de originación para cada usuario (con excepción de los usados indirectos servidos por UAEF; véase el 16.5 ).
11.2
Recepción
Un
puerto de recepción
es el medio por el cual el SMIP
transporta a un usuario simple mensajes que contienen objetos de información de
los tipos definidos en la sección dos. A través de este puerto el usuario puede
recibir
mensajes interpersonales
y
notificaciones interpersonales
. Además, a través de tal
puerto el usuario puede recibir informes.
El SMIP suministra un puerto de recepción a cada usuario.
11.3
Gestión
Un
puerto de gestión
es el medio por el cual un usuario
simple cambia información relativa a sí mismo, que figura en un fichero del
SMIP. Por medio de tal puerto el usuario activa y desactiva
descarte automático
,
acuse automático de
recibo
y
retransmisión automática
.
El SMIP proporciona un puerto de gestión para cada usuario (con excepción de los usuarios indirectos servidos por UAEF; véase el 16.5 ).
12 Operaciones abstractas
El
servicio abstracto SMIP
A continuación se definen y describen las operaciones abstractas disponibles en los puertos de generación, recepción y gestión, respectivamente. Los errores abstractos que dichas operaciones pueden provocar se tratan en el 13 .
Nota 1
- El servicio abstracto SMIP no comprende
operaciones abstractas de vinculación ni operaciones abstractas de
desvinculación.
Nota 2
- El SMIP auténtica (es decir, establece la
identidad de) el usuario típico antes de ofrecerle el servicio abstracto SMIP.
Por este medio puede verificar, por ejemplo, que el usuario es un abonado SMIP.
La autenticación, cuando se requiera, es implícita (y no explícita) en la
definición del servicio abstracto SMIP.
Nota 3
- La finalidad de la definición del servicio
abstracto SMIP no es la de prescribir los interfaces de usuarios de
realizaciones de porciones del SMIP, sino la de aclarar el significado y el uso
que se desea hacer de los objetos de información descritos en la sección dos.
Un interfaz de usuario no necesita proporcionar instrucciones en
correspondencia biunívoca con las operaciones abstractas del servicio, ni
siquiera dividir la labor entre el usuario y el SMIP, como lo hace el servicio.
Nota 4
- En el
16
, el SMIP se descompone en
objetos entre los cuales se encuentra el STRM. En este punto, se refleja este
hecho por la inclusión de diversos elementos de información definidos por el
STRM, en el servicio abstracto SMIP.
12.1
Operaciones abstractas de realizaciones
Las operaciones abstractas disponibles en el puerto de generación son invocadas por el usuario y efectuadas por el SMIP.
origination PORT CONSUMER INVOKES^{ OriginateProbe, OriginateIPM, OriginateRN^} ::= id-pt-origination
12.1.1
Generación sonda
La operación abstracta
generación sonda
genera una sonda
con relación a (una clase de) mensajes cuyo contenido está constituido por MIP.
OriginateProbe ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] ProbeSubmissionEnvelope, content [1] IPM^} RESULT SET^{ submission-identifier [0] ProbeSubmissionIdentifier, submission-time [1] ProbeSubmissionTime^} ERRORS^{ SubscriptionError, RecipientImproperlySpecified^}
Esta operación abstracta tiene los siguientes argumentos:
a)
Sobre
(O): Sobre de depósito de sonda, cuya composición
está definida por el servicio abstracto STRM. El AU proporciona todos los
componentes del sobre, excepto los siguientes que son suministrados por el
usuario:
i)Las opciones deseadas para cada mensaje (es decir, los indicadores y las ampliaciones para cada mensaje).
ii)Los nombres O/D de los destinatarios preferidos y las opciones por cada destinatario (es decir, petición de informe del originador, conversión explícita, y ampliaciones) deseadas para cada uno.
b)
Contenido
(O): Caso de la clase de MIP cuya
entregabilidad se sondea.
Esta operación abstracta tiene los siguientes resultados:
1)
Identificador de depósito
(O): Identificador de
depósito de sonda que el STRM asigna a la sonda.
2)
Hora de depósito
(O): Fecha y hora en que la sonda fue
depositada directamente.
12.1.2
Generación MIP
La operación abstracta
generación MIP
origina un mensaje
cuyo contenido es un MIP.
OriginateIPM ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageSubmissionEnvelope, content [1] IPM^} RESULT SET^{ submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime^} ERRORS^{ SubscriptionError, RecipientImproperlySpecified^}
Esta operación abstracta tiene los siguientes argumentos:
a)
Sobre
(O): Sobre depósito de mensaje, cuya constitución
está definida por el servicio abstracto STRM. El AU suministra todos los
componentes de sobre salvo los siguientes, que son proporcionados por el
usuario:
i)Las opciones deseadas para cada mensaje (es decir, prioridad, indicadores para cada mensaje, hora de entrega diferida, y ampliaciones).
ii)Los nombres O/D de los destinatarios preferidos y las opciones para cada destinatario (es decir, petición de informe de originador, conversión explícita, y ampliaciones) deseadas para cada uno.
b)
Contenido
(O): El MIP que se está originando. Su campo
de encabezamiento de reenvío automático deberá estar ausente o tener el valor
falso
.
Esta operación abstracta tiene los siguientes resultados:
1)
Identificador de depósito
(O): Identificador de
depósito de mensaje que el STRM asigna al depósito.
2)
Hora de depósito
(O): Fecha y hora en que el mensaje
fue depositado directamente.
12.1.3
Generación NR
Operación abstracta
generación NR
cuyo contenido es una
NR.
OriginateRN ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageSubmissionEnvelope, content [1] RN^} RESULT SET^{ submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime^} ERRORS^{ SubscriptionError, RecipientImproperlySpecified^}
Una NR será generada solamente por un destinatario efectivo del MIP asunto con relación al cual se ha solicitado una NR por medio del componente peticiones de notificación del especificador del destinatario asunto del MIP.
El usuario no deberá haber originado previamente una RN en respuesta al MIP asunto, por medio de la presente operación abstracta o un acuse automático de recibo.
Esta operación abstracta tiene los siguientes argumentos:
a)
Sobre
(O): Sobre de depósito de mensaje, cuya
constitución está definida por el servicio abstracto STRM. El AU suministra
todos los componentes de sobre salvo los siguientes, que son proporcionados por
el usuario:
i)Las opciones deseadas para cada mensaje (es decir, prioridad, indicadores para cada mensaje, y ampliaciones). Deberá prohibirse la conversión implícita, la prioridad será la del MIP asunto.
ii)Los nombres O/D de los destinatarios preferidos y opciones para cada destinatario (es decir, conversión explícita y ampliaciones) deseadas, para cada uno. No se solicitarán informes.
b)
Contenido
(O): La RN que se está originando.
Esta operación abstracta tiene los siguientes resultados:
1)
Identificador de depósito
(O): El identificador de
depósito de mensaje lo asigna el STRM al depósito.
2)
Hora de depósito
(O): Fecha y hora en que el mensaje
fue depositado directamente.
12.2
Operaciones abstractas de recepción
Las operaciones abstractas disponibles en un puerto de recepción son invocadas por el SMIP y efectuadas por el usuario.
reception PORT SUPPLIER INVOKES^{ ReceiveReport, ReceiveIPM, ReceiveRN, ReceiveNRN^} ::= id-pt-reception
Nota 1
- Por haberse definido abstractamente, el SMIP
no proporciona el almacenamiento de los mensajes recibidos, pues el hecho de
que lo proporcione, o de que no lo proporcione, para un determinado usuario no
influye en forma alguna en la capacidad del usuario para comunicar con otros
usuarios. En consecuencia el suministro de almacenamiento es un asunto local.
Nota 2
- Por estas consideraciones, la operación
abstracta
recepción MIP
, por ejemplo, expele un MIP del
SMIP porque su finalidad es aclarar el significado del paso de transferencia de
recepción. En cambio, las capacidades de un usuario al que se proporciona el
almacenamiento de los mensajes recibidos podría incluir una instrucción
`visualización MIP'
que permitiera al usuario visualizar el MIP
entregado (y quizás ya recibido) cuyo identificador de MIP él especifica, y que
le permita proceder de esta manera todas las veces que desee, introduciendo
repetidamente la instrucción. La primera, pero no las ulteriores utilizaciones
de la instrucción para visualizar un determinado MIP, representa la realización
concreta de la operación abstracta de recepción MIP en tal realización.
12.2.1
Recepción informe
La operación abstracta
recepción informe
recibe un
informe.
ReceiveReport ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] ReportDeliveryEnvelope, undelivered-object [1] InformationObject OPTIONAL^} RESULT ERRORS {^}
El informe recibido puede estar relacionado con uno de los siguientes puntos originado previamente por los destinatarios del informe:
a)Una sonda referente a un mensaje cuyo contenido era un MIP, que fue originado con la operación abstracta generación sonda.
b)Un mensaje cuyo contenido era una NNR, que fue originado como resultado de un descarte automático o una retransmisión automática.
c)Un mensaje cuyo contenido era una NR, que fue originado con la operación
abstracta generación NR o por
acuse de recibo automático
.
d)Un mensaje cuyo contenido era un MIP, que fue originado con la operación
abstracta generación MIP o por
retransmisión
automática
.
Esta operación abstracta tiene los siguientes argumentos:
1)
Sobre
(O): Sobre de entrega de informe, cuya
composición está definida por el servicio abstracto STRM.
2)
Objeto no entregado
(C): Contenido del mensaje sobre
cuyo estado se está informando. Es un MIP o una NIP.
Si el informe fue provocado por una invocación anterior de la operación abstracta generación sonda, este argumento condicional estará ausente. Si el informe fue provocado por una invocación anterior de la operación abstracta generación MIP, el argumento estará presente si y sólo si se solicitó devolución del contenido. En otro caso (es decir, si el informe fue provocado por una NIP) el argumento estará ausente.
Esta operación abstracta no tiene resultados.
12.2.2
Recepción MIP
La operación abstracta
recepción MIP
recibe un mensaje
cuyo contenido es un MIP.
ReceiveIPM ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageDeliveryEnvelope, content [1] IPM^} RESULT ERRORS {^}
Esta operación abstracta tiene los siguientes argumentos:
a)
Sobre
(O): Sobre de entrega del mensaje.
b)
Contenido
(O): MIP que es el contenido del mensaje.
Esta operación abstracta no tiene resultados.
12.2.3
Recepción NR
La operación abstracta
recepción NR
recibe un mensaje
cuyo contenido es una NR. La NR es provocada por un MIP generado con la
operación abstracta generación MIP.
ReceiveRN ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageDeliveryEnvelope, content [1] RN^} RESULT ERRORS {^}
Esta operación abstracta tiene los siguientes argumentos:
a)
Sobre
(O): Sobre de entrega del mensaje.
b)
Contenido
(O): NR que es el contenido del mensaje.
Esta operación abstracta no tiene resultados.
12.2.4
Recepción NNR
La operación abstracta
recepción NNR
recibe un mensaje
cuyo contenido es una NNR. La NNR es provocada por un MIP originado con la
operación abstracta generación MIP.
ReceiveNRN ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageDeliveryEnvelope, content [1] NNR^} RESULT ERRORS {^}
Esta operación abstracta tiene los siguientes argumentos:
a)
Sobre
(O): Sobre de entrega del mensaje.
b)
Contenido
(O): NNR que es el contenido del mensaje.
Esta operación abstracta no tiene resultados.
12.3
Operaciones abstractas de gestión
Las operaciones abstractas disponibles en un puerto de gestión son invocadas por el usuario y ejecutadas por el SMIP.
management PORT CONSUMER INVOKES { ChangeAutoDiscard, ChangeAutoAcknowledgment, ChangeAutoForwarding^} ::= id-pt-management
12.3.1
Cambio descarte automático
La operación abstracta
cambio descarte automático
activa
o desactiva el
descarte automático
, es decir, el descarte
automático por el SMIP de MIP expirados u obsoletos, entregados al usuario,
pero aún no recibidos por éste.
ChangeAutoDiscard; ::= ABSTRACT-OPERATION ARGUMENT SET { auto-discard-expired-IPMs [0] BOOLEAN, auto-discard-obsolete-IPMs [1] BOOLEAN^} RESULT ERRORS {^}
Cuando el SMIP descarta automáticamente un MIP, origina una NNR a nombre del usuario únicamente si se había solicitado del mismo una de estas notificaciones por medio del componente peticiones de notificación del especificador de destinatario asunto.
Esta operación abstracta tiene los siguientes argumentos:
a)
Descarte automático de MIP expirados
(O):
Independientemente de que los MIP expirados deban ser o no descartados
automáticamente. Es un booleano.
b)
Descarte automático de MIP obsoletos
(O):
Independientemente de que los MIP obsoletos sean o no descartados
automáticamete. Es un booleano.
Esta operación abstracta no tiene resultados.
12.3.2
Cambio acuse de recibo automático
La operación abstracta
cambio acuse de recibo automático
activa o desactiva
acuse de recibo automático
, la generación
automática de NR por el SMIP en nombre del usuario. Esta generación se produce
al entregarse los MIP que solicitan NR del usuario por medio de los componentes
peticiones de notificación de sus especificadores de destinatario asunto.
ChangeAutoAcknowledgment ::= ABSTRACT-OPERATION ARGUMENT SET { auto-acknowledge-IPMs [0] BOOLEAN, auto-acknowledge-suppl-receipt-info [1] SupplementaryInformation OPTIONAL^} RESULT ERRORS { SubscriptionError^}
Esta operación abstracta tiene los siguientes argumentos:
a)
Acuse de recibo automático de MIP
(O):
Independientemente de que acuse o no recibo automáticamente de los MIP. Es un
booleano.
b)
Información de recepción suplementaria de acuse de
recibo automático
(C): Campo de información de recepción
suplementaria de cada NR provocada por un acuse de recibo automático.
Este argumento condicional estará presente únicamente si el argumento de los
MIP con acuse de recibo automático tiene el valor
verdadero
.
Esta operación abstracta no tiene resultados.
12.3.3
Cambio retransmisión automática
La operación abstracta
cambio retransmisión automática
activa o desactiva la
retransmisión automática
,
retransmisión automática de MIP por el SMIP a usuarios o LD especificadas
previamente. Esta retransmisión se produce al entregarse los MIP.
ChangeAutoForwarding ::= ABSTRACT-OPERATION ARGUMENT SET { auto-forward-IPMs [0] BOOLEAN, auto-forward-recipients [1] SEQUENCE OF ORName OPTIONAL, auto-forward-heading [2] Heading OPTIONAL, auto-forward-comment [3] AutoForwardComment OPTIONAL^} RESULT ERRORS { SubscriptionError, RecipientImproperlySpecified^}
El cuerpo de cada MIP, originado por el SMIP como resultado de una retransmisión automática comprende una sola parte de cuerpo de tipo mensaje. El contenido del mensaje representado por la parte de cuerpo es el MIP retransmitido.
Cuando el SMIP retransmite automáticamente un MIP, origina una NNR en nombre del usuario si y sólo si se había solicitado de él tal notificación por medio del componente peticiones de notificación del especificador del destinatario asunto.
Esta operación abstracta tiene los siguientes argumentos:
a)
MIPs de retransmisión automático
(O):
Independientemente o no de que los MIP deban ser reenviados automáticamente. Es
un booleano.
b)
Destinatarios de retransmisión automática
(C): Los
usuarios o LD a los cuales deben retransmitirse los MIP. Es una secuencia de
nombres O/D.
Este argumento condicional estará presente únicamente si el argumento de los
MIP de retransmisión automática tiene el valor
verdadero
.
c)
Encabezamiento de retransmisión automática
(C):
Encabezamiento que ha de utilizarse para cada retransmisión de MIP. El campo de
encabezamiento retransmitido automáticamente deberá tener el valor
verdadero
.
Este argumento condicional estará presente únicamente si el argumento MIP de
retransmisión automática tiene el valor
verdadero
.
d)
Comentario de retransmisión automática
(C): Valor que
ha de suministrarse como el campo de no recepción comentario de retransmisión
automática de cada NNR transportada al originador de un MIP retransmitido
automáticamente.
Este argumento condicional estará presente únicamente si el argumento de los
MIP retransmisión automática tiene el argumento
verdadero
.
Esta operación abstracta no tiene resultados.
Nota
- Esta operación abstracta está prevista para
definir la esencia de la retransmisión automática, y no para impedir que se
ofrezcan capacidades de retransmisión automática más sofisticadas; por ejemplo,
como las de un AM.
13
Errores abstractos
Los errores abstractos que pueden ser informados en respuesta a la invocación de las operaciones abstractas disponibles en los puertos de generación, recepción y gestión se definen y describen a continuación o como parte de la definición del servicio abstracto STRM.
Nota
- El conjunto de errores abstractos representados
más adelante tiene una finalidad ilustrativa, y no es exhaustivo.
13.1
Error de abono
El error abstracto
error de abono
notifica que el
usuario no está abonado a uno o más de los elementos de servicio implícitos en
su invocación de la operación abstracta cuya ejecución ha sido abortada.
SubscriptionError ::= ABSTRACT-ERROR PARAMETER SET { problem [0] SubscriptionProblem^}
Este error abstracto tiene los siguientes parámetros:
a)
Problema
(O): Problema referente al abono, con el cual
se ha tropezado.
SubscriptionProblem ::= ENUMERATED { ipms-eos-not-subscribed(0), mts-eos-not-subscribed (1)^}
Este parámetro puede adoptar uno de los siguientes valores:
i)
eds-SMIP-no-abonado
^: Elemento de servicio SMIP no
abonado.
ii)
eds-STRM-no-abonado
^: Elemento de servicio STRM no
abonado.
13.2
Destinatario especificado indebidamente
El error abstracto
destinatario indebidamente
especificado
notifica que no son válidos uno o más de los nombres O/D
suministrados como argumentos o como componentes de los argumentos de la
operación abstracta cuya ejecución ha sido abortada.
Este error abstracto está definido por el servicio abstracto STRM.
14 Otras capacidades
Además de las capacidades comprendidas en el servicio abstracto SMIP, definidas anteriormente, el SMIP extenderá transparentemente a cada usuario las capacidades del AM y del STRM identificadas más adelante. (La enumeración de estas capacidades anticipan necesariamente el hecho, indicado en el 16 , de que los AM y el STRM se encuentran entre las partes componentes de los SMIP.)
Se proporcionarán las siguientes capacidades adicionales:
a)
Depósito
^: Capacidades del puerto de depósito de los
AM o de los STRM no incluidos en el servicio abstracto SMIP, por ejemplo, la
posibilidad de anular la entrega de un mensaje generado anteriormente cuyo
contenido es un MIP (pero no una NR), si se seleccionó entrega diferida.
b)
Entrega
^: Capacidades del cuerpo de entrega de los
STRM no comprendidas en el servicio abstracto SMIP, por ejemplo, la posibilidad
de controlar temporalmente las clases de objetos de información que el STRM
transporta al AU del usuario.
c)
Administración
^: Capacidades del puerto de
administración de los AM o los STRM.
d)
Extracción
^: Capacidades del puerto de extracción de
los AM.
Además de lo anteriormente expresado y como asunto local, los SMIP pueden proporcionar a los usuarios capacidades adicionales que no están definidas o no están limitadas por esta Recomendación. Entre estas capacidades están las de la guía.
Nota
- Las capacidades requeridas a que se refiere
este punto están excluidas de la definición formal del servicio abstracto SMIP
por razones puramente pragmáticas, en particular, porque su inclusión
reproducía en gran parte, e innecesariamente, las definiciones de las
operaciones abstractas AM y STRM sobre las cuales se basan dichas capacidades.
SECCIóN 4 -
15 Visión de conjunto
Esta sección especifica cómo el SMIP proporciona el servicio abstracto SMIP a los usuarios.
Esta sección trata los siguientes temas:
a)Tipos de objetos secundarios.
b)Tipos de puertos secundarios.
c)Operación de agente de usuario.
d)Operaciones de almacenamiento de mensajes.
e)Contenido de mensajes.
f)Realización de puertos.
g)Conformidad.
16
Tipos de objetos
secundarios
El SMIP puede describirse mediante un modelo que comprende objetos menores que interactúan entre sí por medio de puertos (adicionales).
ipms-refinement REFINE ipms AS mTS submission[S]PAIRED WITH ipms-ua, ipms-ms delivery[S]PAIRED WITH ipms-ua, ipms-ms administration[S]PAIRED WITH ipms-ua, ipms-ms ipms-ua RECURRING origination[S]VISIBLE reception[S]VISIBLE management[S]VISIBLE ipms-ms RECURRING submission[S]PAIRED WITH ipms-ua retrieval[S]PAIRED WITH ipms-ua administration[S]PAIRED WITH ipms-ua tlma RECURRING origination[S]VISIBLE reception[S]VISIBLE management[S]VISIBLE tlxau RECURRING origination[S]VISIBLE reception[S]VISIBLE management[S]VISIBLE pdau RECURRING reception[S]VISIBLE ::= id-ref-secondary
Estos objetos menores se denominan
objetos secundarios
de la mensajería interpersonal. Comprenden un objeto central único, el STRM, y
numerosos objetos periféricos:
agentes de usuario del sistema
de mensajería interpersonal (AU SMIP)
,
dispositivos de almacenamiento de mensajes del
sistema de mensajería interpersonal (AM SMIP)
,
agentes telemáticos (ATLM)
,
unidades de acceso télex (UATLX)
, y unidades de acceso a
entrega física (UAEF).
La estructura del SMIP se describe en la figura 4/X.420. Como se indica en
dicha figura, los
AU SMIP
,
ATLM
,
UATLX
y
UAEF
son instrumentos por
medio de los cuales el SMIP proporciona el servicio abstracto a los usuarios.
A continuación se definen y describen los tipos de objeto secundario. Los tipos de puertos por medio de los cuales interactúan dichos tipos de objetos se examinan en el 17 .
Nota 1
- La presentación anterior comprende todas las
posibles interconexiones entre todos los objetos posibles. Ignora la posible
ausencia de objetos de un tipo determinado (por ejemplo, UAEF) y
configuraciones lógicas específicas del
AM SMIP
. Estas
últimas se identifican en la Recomendación X.402.
Nota 2
- La Recomendación T.330 extiende de hecho el
servicio abstracto de mensajería interpersonal mediante su definición de un
puerto
misceláneo
, que no se muestra en la figura. Véase
la nota en el
16.3
.
Nota 3
- El STRM abastece a los puertos de importación
y exportación. Sin embargo, como esos puertos no están definidos formalmente
(en la Recomendación X.411), no se incluyen en la presentación formal anterior.
16.1
Agente de usuario del sistema de mensajería
interpersonal
Un @
agente de usuario del sistema de mensajería
interpersonal (AU SMIP)
\ es un AU diseñado para
facilitar la utilización, por un solo usuario, de la mensajería interpersonal.
Lo ayuda a generar, recibir, o a generar y recibir mensajes que contienen
objetos de información de los tipos definidos en la sección dos.
ipms-ua OBJECT PORTS { origination[S], reception[S], management[S], submission[C], delivery[C], retrieval[C], administration[C]^} ::= id-ot-ipms-ua
Figure 4/X.420, (N), p.
El SMIP comprende un número cualquiera de AU SMIP.
Nota
- Por razones de brevedad, en el resto de esta
Recomendación se usa el término
`AU'
con el significado de
`AU
SMIP'
.
16.2
Dispositivo de almacenamiento de mensajes del sistema
de mensajería interpersonal
Un @
dispositivo de almacenamiento de mensajes del sistema
de mensajería interpersonal (AM SMIP)
\ es un AM
diseñado para facilitar la utilización por un solo usuario, de la mensajería
interpersonal. Le ayuda a depositar, aceptar la entrega, o a depositar y
aceptar la entrega de mensajes que contienen objetos de información de los
tipos definidos en la sección dos.
ipms-ms OBJECT PORTS^{ submission[S], retrieval[S], administration[S], submission[C], delivery[C], administration[C]^} ::= id-ot-ipms-ms
El SMIP comprende cualquier número de AM SMIP.
Nota
- Por razones de brevedad, en el resto de esta
Recomendación se utiliza el término
`AM'
con el significado de
`AM
SMIP'
.
16.3
Agente telemático
Un @
agente telemático (ATLM)
\ es un UA que ayuda a un
solo usuario indirecto a emplear la mensajería interpersonal a partir de un
terminal telemático, junto con ese terminal y a la red que los une. Un ATLM
ayuda al usuario a generar, recibir, o a generar y recibir mensajes que
contienen objetos de información de los tipos definidos en la sección dos.
tlma OBJECT PORTS { origination[S], reception[S], management[S], miscellanea[S]^} ::= id-ot-tlma
El SMIP comprende cualquier número de ATLM.
Nota 1
- Un ATLM consume puertos importación y
exportación. Sin embargo, como dichos puertos no están definidos formalmente
(en la Recomendación X.411), no se incluyen en la definición de ATLM mencionada
anteriormente.
Nota 2
- En la Recomendación T.330 se define un puerto
misceláneo
del ATLM. Este no forma parte del servicio
abstracto SMIP en su forma más general, que es el asunto de esta Recomendación.
En lugar de esto, comprende capacidades disponibles solamente para un usuario
ATLM. Por esta razón, no se considera ulteriormente en esta Recomendación y no
se incluye en el perfeccionamiento formal del SMIP que figura en el
16
.
16.4
Unidad de acceso télex
Una @
unidad de acceso télex (UATLX)
\ es una UA que ayuda
a cualquier número de usuarios indirectos a utilizar la mensajería
interpersonal a partir de terminales télex. Les ayuda a generar, recibir o a
generar y recibir mensajes que contienen objetos de información de los tipos
definidos en la sección dos.
tlxau OBJECT PORTS { origination[S], reception[S], management[S]^} ::= id-ot-tlxau
El SMIP comprende cualquier número de UATLX.
Nota
- Una UATLX consume puertos de importación y
exportación. Sin embargo, como dichos puertos no están definidos formalmente
(en la Recomendación X.411), no se incluyen en la definición formal de UATLX
mencionada anteriormente.
16.5
Unidad de acceso a entrega física
En el presente contexto, una unidad de acceso a entrega física (UAEF) ayuda a cualquier número de usuarios indirectos a utilizar la mensajería interpersonal por medio de un servicio de entrega física (SEF). Les ayuda a recibir (pero no a generar) mensajes que contienen objetos de información de los tipos definidos en la sección dos.
pdau OBJECT PORTS { reception[S]^} ::= id-ot-pdau
El SMIP comprende cualquier número de UAEF.
Nota
- Una UAEF consume puertos de importación y
exportación. Sin embargo, como dichos puertos no están definidos formalmente
(en la Recomendación X.411), no se incluyen en la definición formal de UAEF
mencionada anteriormente.
16.6
Sistema de transferencia de mensajes
En el presente contexto, el sistema de transferencia de mensajes (STRM) transporta objetos de información de los tipos definidos en la sección dos entre AU, AM, ATLM y UA.
El SMIP comprende un solo STRM.
17
Tipos de puertos
secundarios
Los objetos secundarios de la mensajería interpersonal están unidos e
interactúan entre si por medio de puertos. Estos puertos, que son
proporcionados por los AM y STRM, se denominan
puertos
secundarios
de mensajería interpersonal. Son de los tipos identificados
más adelante.
Las capacidades incorporadas en un puerto de depósito, un puerto de extracción, y un puerto de administración constituyen el servicio abstracto AM. Estas capacidades se definen en la Recomendación X.413.
Las capacidades incorporadas en un puerto de depósito, un puerto de entrega y un puerto de administración constituyen el servicio abstracto STRM. Se definen en la Recomendación X.411.
Nota
- Por medio de la operación abstracta de
vinculación que vigila sus puertos, un AM o el STRM autentican típicamente otro
objeto secundario antes de ofrecer sus servicios abstractos a ese objeto.
17.1
Depósito
En el presente contexto, un puerto de depósito es el medio por el cual un AU (directa o indirectamente) o un AS (directamente) deposita sondas relativas a, o mensajes que contienen, objetos de información de los tipos definidos en la sección dos.
Un AM proporciona un puerto de depósito a su AU.
El STRM proporciona un puerto de depósito a cada AU configurado sin un AM y a cada AM.
17.2
Entrega
En el presente contexto, un puerto de entrega es el medio por el cual un AU o AM acepta la entrega de informes relativos a, y mensajes que contienen, objetos de información de los tipos definidos en la sección dos.
El STRM proporciona un puerto de entrega cada AU configurado sin un AM, y a cada AM.
17.3
Extracción
En el presente contexto, un puerto de
extracción
es el
medio por el cual un AU extrae informes relativos a, y mensajes que contienen,
objetos de información de los tipos definidos en la sección dos.
Un AM proporciona un puerto de extracción a su AU.
17.4
Administración
En el presente contexto, un puerto de administración es el medio por el cual un AU cambia información sobre el mismo o su usuario en un fichero con el AM, o un AU, o un AM cambia tal información en un fichero con el STRM.
Un AM proporciona un puerto de administración a su AU.
El STRM proporciona un puerto de administración a cada AU configurado sin un AM y a cada AM.
17.5
Importación
En el presente contexto, un puerto de importación es el medio por el cual el STRM importa informes relativos a mensajes que contienen objetos de información de los tipos definidos en la sección dos.
El STRM proporciona un cuerpo de importación a cada UA (o ATLM).
17.6
Exportación
En el presente contexto, un puerto de exportación es el medio por el cual el STRM exporta sondas relativas a, y mensajes que contienen, objetos de información de los tipos definidos en la sección dos.
El STRM proporciona un puerto de exportación a cada UA (o ATLM).
18
Operación de agente de
usuario
Un AU tiene que emplear el STRM de una manera particular con el fin de proporcionar (correctamente) el servicio abstracto de SMIP a su usuario. Si el usuario está equipado con un AM, este último contribuye a la prestación del servicio abstracto y, por tanto, está sujeto a las mismas reglas.
Son objeto de éste punto las reglas que gobiernan la operación de un AU (y un AM). La operación de un ATLM o un AU está fuera del ámbito de esta Recomendación.
Nota 1
- Se debe a razones históricas el que la
Recomendación que define el servicio abstracto de SMIP especifique también la
forma en que un AU (y un AM), pero no un ATLM o UA, lo proporciona.
Nota 2
- La finalidad de este punto no es imponer ni
limitar innecesariamente la realización de un AU real, sino aclarar el
significado y el efecto deseado del servicio abstracto SMIP.
18.1
Variables de estado
La operación de un AU se describe a continuación con ayuda de
variables de estado
. Una
variable de
estado
es un elemento de información cuyo valor registra los resultados de
las interacciones pasadas del AU con su usuario e influye en las interacciones
futuras. Las variables de estado son comunes, es decir, están compartidas por
los puertos de originación, recepción y gestión del AU.
El AU mantiene cada variable de estado continuamente, es decir, a través
del abono del usuario al SMIP. A cada variable de estado booleana se le asigna
el valor
falso
cuando comienza el abono. Los valores
iniciales de otras variables de estado no tienen importancia y por eso no se
especifican.
El AU cambia sus variables de estado cuando efectúa o invoca operaciones abstractas. El AU consulta esas variables para determinar cómo ha de efectuar operaciones abstractas, la forma de hacerlo y si deben invocarse y cómo dichas operaciones. Sus valores (si existen) tienen importancia para la vinculación y desvinculación de puertos.
Nota
- Las variables de estado son dispositivos
didácticos que no tienen por finalidad limitar innecesariamente la realización
de un AU real. En particular, un AU no necesita mantener estructuras de datos
al tiempo de la ejecución que corresponden a variables de estado si el
comportamiento requerido del mismo puede asegurarse de otra manera.
18.2
Ejecución de operaciones de generación
Un AU deberá ejecutar las operaciones abstractas, que pone a disposición en su puerto de generación, como se indica a continuación. Al efectuar estas operaciones particulares, el AU no modifica ninguna de sus variables de estado.
En la ejecución de estas operaciones, el AU invoca las siguientes operaciones abstractas del servicio abstracto STRM (que, en el resto de este punto, se indicarán de una manera no calificada con respecto a su fuente):
a)depósito de sonda,
b)depósito de mensaje.
Nota
- En respuesta a la invocación de estas
operaciones abstractas, un AU notificará los errores abstractos según proceda.
La especificación de las circunstancias precisas en las cuales deberá
notificarse cada error abstracto está fuera del ámbito de esta Recomendación.
18.2.1
Generación sonda
Un AU ejecutará la operación abstracta generación sonda invocando depósito de sonda con los argumentos indicados más adelante y devolviendo a su usuario los resultados que también se indican más adelante.
Los argumentos de depósito sonda serán los siguientes:
a)
Sobre:
Los componentes de este argumento que
constituyen los campos para cada sonda serán los siguientes; los que no se
mencionen explícitamente más abajo serán como los especificados por el
argumento sobre de generación sonda:
i)
Nombre-de-originador:
Nombre O/D del usuario del AU.
ii)
Tipo-de-contenido, longitud-de-contenido y
tipos-de-información- codificada-original:
Determinados a partir del argumento contenido de generación sonda, especificado en los
20.2
a 20.4.
iii)
Identificador-de-contenido:
Su especificación u
omisión es un asunto local.
Los componentes de este argumento que constituyen campos para cada destinatario serán los especificados por el argumento de sobre de generación sonda.
Los resultados de generación sonda serán los siguientes:
1)
Identificador-de-depósito:
Resultado del
identificador de depósito de sonda del depósito de sonda.
2)
Hora-de-depósito:
Resultado de la hora de depósito de
sonda del depósito de sonda.
Nota 1
- El AU ignorará todas las propiedades del
argumento contenido de generación sonda que no sean las mencionadas
anteriormente.
Nota 2
- La manera en que el AU emplea el resultado de
identificador de contenido del depósito de sonda es un asunto local.
18.2.2
Generación MIP
Un AU efectuará la operación abstracta generación MIP invocando depósito de mensaje con los argumentos indicados más adelante, y devolviendo a su usuario los resultados que también se indican más adelante.
Los argumentos de depósito de mensaje serán los siguientes:
a)
Sobre:
Los componentes de este argumento que
constituyen campos para cada mensaje serán los siguientes; los que no se
mencionan explícitamente se especificarán por el argumento del sobre de
generación MIP:
i)
Nombre-de-originador:
Nombre O/D del usuario del AU.
ii)
Tipo-de-contenido y
tipos-de-información-codificada-original:
Determinados a
partir del argumento de contenido de generación MIP como se especifica en los
20.2
y 20.4, respectivamente.
iii)
Identificador-contenido:
Su especificación u
omisión es un asunto local.
Los componentes de este argumento que constituyen campos para cada destinatario serán los especificados por el argumento del sobre de generación MIP.
b)
Contenido:
Determinado a partir del argumento del
contenido de generación MIP (identificado como un MIP), como se especifica en
el
20.1
.
Si el campo de encabezamiento de los destinatarios de copia ciega del MIP identifica uno o más usuarios y LD, el AU invocará el depósito de mensaje repetidas veces, variando en cada ocasión el campo de encabezamiento para ajustarse a los requisitos de ocultación de información del 7.2.6 .
Los resultados de MIP serán los siguientes:
1)
Identificador-de-depósito:
Resultado del
identificador de depósito de mensaje del depósito de mensaje.
2)
Hora-de-depósito:
Resultado de la hora de depósito de
mensaje del depósito de mensaje.
Nota 1
- La forma en que el AU emplea el resultado del
identificador de contenido del depósito de mensaje es un asunto local.
Nota 2
- La inclusión del resultado de ampliaciones
del depósito de mensaje entre los resultados de generación MIP es un asunto de
orden propio y queda para ulterior estudio.
18.2.3
Generación NR
Un AU realizará la operación abstracta generación NR invocando un depósito de mensaje con los argumentos indicados más adelante, y devolviendo a su usuario los resultados que también se indican más adelante.
Los argumentos de depósito de mensaje serán los siguientes:
a)
Sobre:
Los componentes de este argumento, que
constituyen campos para cada mensaje, serán los siguientes; los que no se
mencionan explícitamente más adelante serán especificados por el argumento del
sobre de generación NR:
i)
Nombre-del-originador:
Nombre O/D del usuario del AU.
ii)
Tipo-de-contenido y
tipos-de-información-codificada-original:
Determinados a
partir de la NR como se especifica en los
20.2
y 20.4,
respectivamente.
iii)
Identificador-de-contenido:
Su especificación u
omisión es un asunto local.
iv)
Hora-de-entrega-diferida:
Omitida.
Los componentes de este argumento que constituyen campos para cada destinatario serán especificados por el argumento del sobre de generación NR.
b)
Contenido:
Determinado a partir del argumento del
contenido de generación NR (identificado como una NR) como se especifica en el
20.1
.
Los resultados de generación NR serán los siguientes:
1)
Identificador-de-depósito:
Resultado del
identificador-de-depósito-de-mensaje del depósito de mensaje.
2)
Hora-de-depósito:
Resultado de la
hora-de-depósito-de-mensaje del depósito de mensaje.
Nota 1
- La manera en que el AU emplea el resultado
del identificador de contenido del depósito de mensaje es un asunto local.
Nota 2
- La inclusión del resultado de ampliaciones
del depósito de mensaje entre los resultados de generación NR es un asunto de
índole propia y queda para ulterior estudio.
18.3
Ejecución de operaciones de gestión
Un AU ejecutará las operaciones abstractas que pone a disposición en su puerto de gestión, como se especifica más adelante. El AU modifica una o más de sus variables de estado (véase más abajo) al efectuar cada operación.
Nota
- En respuesta a la invocación de estas
operaciones abstractas, un AU notifica errores abstractos según proceda. La
especificación de las circunstancias precisas en las cuales debe informarse
cada error abstracto está fuera del ámbito de esta Recomendación.
18.3.1
Cambio descarte automático
Para ayudar a proporcionar esta operación abstracta, un AU mantiene las siguientes variables de estado.
a)
Descarte-automático-de-MIP-expirados
: Es un booleano
que indica si el descarte automático está o no vigente para los MIP expirados.
b)
Descarte-automático-de-MIP-obsoletos
: Es un booleano
que indica si el descarte automático está o no vigente para los MIP obsoletos.
Un AU ejecutará la operación abstracta cambio descarte automático registrando los valores de los argumentos de descarte automático de MIP expirados y descarte automático de MIP obsoletos en las variables de estado denominadas correspondientemente.
18.3.2
Cambio acuse de recibo automático
Para ayudar a proporcionar esta operación abstracta, un AU mantiene las siguientes variables de estado:
a)
Acuse-de-recibo-automático-de-MIP
: Es un booleano que
indica si el acuse de recibo automático está o no vigente.
b)
Información-recepción-suplementaria-de-acuse-recibo-automático
: Campo información recepción suplementaria de cada NR provocada por acuse de recibo automático.
Un AU ejecutará la operación abstracta Cambio acuse de recibo automático
registrando el valor del argumento de acuse de recibo automático de MIP en la
variable de estado denominada correspondientemente. Si ese valor es
verdadero
, registrará también el valor del argumento de
acuse recibo automático de recepción de información suplementaria en la
variable de estado denominada correspondientemente.
18.3.3
Cambio de retransmisión
automática
Para ayudar a proporcionar esta operación abstracta, un AU mantiene las siguientes variables de estado:
a)
MIP-con-retransmisión-automática
b)
Destinatarios-de-retransmisión-automática
c)
Encabezamiento-de-retransmisión-automática
verdadero
.
d)
Comentario-de-retransmisión-automática
Un AU efectuará la operación abstracta cambio retransmisión automática
registrando el valor del argumento de los MIP retransmitidos automáticamente en
la variable de estado denominada correspondientemente. Si ese valor es
verdadero
registrará también los valores de los argumentos
de destinatarios de retransmisión automática, encabezamiento de retransmisión
automática, y comentarios de retransmisión automática, en las variables de
estado denominadas correspondientemente.
18.4
Invocación de
operaciones
de recepción
Un AU invocará las operaciones abstractas disponibles en su puerto de recepción como se especifica más adelante. El AU no modifica ninguna de sus variables de estado en relación con la invocación de estas operaciones.
El AU invoca estas operaciones en respuesta a la invocaciòn STRM de las siguientes operaciones abstractas del servicio abstracto STRM (las cuales, durante el resto de este punto, no serán calificadas en lo que respecta a su fuente):
a)Entrega de informe.
b)Entrega de mensaje.
Nota
- Las operaciones abstractas de un puerto de
recepción no notifican errores.
18.4.1
Recepción informe
Cuando el STRM invoca entrega de informe en un puerto de entrega del AU, el AU invocará la operación abstracta recepción informe con los siguientes argumentos:
a)
Sobre
^: Argumento del sobre de entrega de informe.
b)
Objeto-no-entregado
^: Determinado a partir del
argumento contenido devuelto de la entrega de informe, como se especifica en el
20.1
.
Nota
- Toda forma de empleo, por el AU, del componente
identificador de contenido del argumento de sobre de entrega de informe es un
asunto local.
18.4.2
Recepción MIP
Cuando el STRM invoca entrega de mensaje en un puerto de entrega del AU, y su argumento de contenido codifica un MIP como se especifica en el 20.1 , el AU invocará la operación abstracta recepción MIP con los siguientes argumentos, a condición de que el mensaje no esté sujeto a retransmisión automática, ni a descarte automático (véase el 18.5 ):
a)
Sobre
^: Argumento del sobre de entrega de mensaje.
b)
Contenido
^: Determinado a partir del argumento del
contenido de entrega de mensaje como se especifica en el
20.1
(pero
ya no será marcado como un MIP).
18.4.3
Recepción NR
Cuando el STR invoca entrega de mensaje en un puerto de entrega del AU, y su argumento de contenido codifica una NR como se especifica en el 20.1 , el AU invocará la operación abstracta recepción NR con los siguientes argumentos:
a)
Sobre
^: Argumento del sobre de entrega de mensaje.
b)
Contenido
^: Determinado a partir del argumento del
contenido de entrega de mensaje como se especifica en el
20.1
(pero
ya no será marcado como una NR).
18.4.4
Recepción NNR
Cuando el STRM invoca entrega de mensaje en un puerto de entrega del AU, y su argumento de contenido codifica una NNR como se especifica en el 20.1 , el AU invocará la operación abstracta recepción NNR con los siguientes argumentos:
a)
Sobre
^: Argumento del sobre de entrega de mensaje.
b)
Contenido
^: Determinado a partir del argumento del
contenido de entrega de mensaje como se especifica en el
20.1
(pero
ya no será marcado como NNR).
18.5
Procedimientos internos
Un AU aplicará, como se indica más adelante, los procedimientos internos de descarte automático, acuse de recido automático, y reenvío automático para dejar concluidas las operaciones abstractas disponibles en su puerto de gestión.
Los procedimientos comprenden las siguientes operaciones abstractas del servicio abstracto STRM (las cuales, en el resto de este punto, no serán calificadas con respecto a su fuente):
a)Depósito de mensaje.
b)Entrega de mensaje.
Como se deduce de lo anteriormente expuesto, en el curso de los procedimientos, el AU tiene ocasión de invocar entrega de mensaje. Su actuación sobre los resultados de esta operación abstracta es un asunto local.
El AU considerará como candidato para cada procedimiento, individualmente, cada mensaje con relación al cual se cumplan las siguientes condiciones:
a)El STRM ha transportado el mensaje al AU invocando entrega de mensaje en el puerto de entrega del AU.
b)El AU no ha transportado el mensaje al usuario invocando recepción MIP en el puerto de recepción del usuario.
c)El mensaje contiene un MIP (y no una NIP).
Nota
- Con relación al anterior apartado b), el
mensaje podría ser detenido en el AU, por ejemplo, como caso típico, por motivo
de indisponibilidad del usuario.
18.5.1
Descarte automático
El AU aplicará un descarte automático a cada mensaje candidato en base a que sus respectivos contenidos cumplan las siguientes condiciones:
a)La variable de estado descarte automático de MIP expirados tiene el valor
verdadero
y han pasado la fecha y hora señaladas por el
campo hora de expiración del MIP.
b)La variable de estado descarte de MIP obsoletos tiene el valor
verdadero
y otro MIP candidato identifica el MIP candidato
presente por medio de su campo de encabezamiento MIP obsoletos.
El AU descartará automáticamente cada mensaje como sigue.
18.5.1.1
Descarte de MIP
El AU descartará el MIP a fin de que nunca se transfiera al usuario.
18.5.1.2
Construcción de NNR
El AU construirá una NNR si y sólo si así se le solicita por medio del componente peticiones de notificación del especificador del destinatario asunto del MIP.
La NNR tendrá los campos comunes prescritos para el acuse de recibo automático (véase el 18.5.2.1 ).
La NNR tendrá los siguientes campos de recepción:
a)
Motivo de no recepción:
Valor
mip
descartado
.
b)
Motivo de descarte:
Valor
mip-expirado
o
mip-obsoleto
, el que
sea aplicable. Si ninguno de los dos es aplicable, se puede especificar
cualquiera de ellos.
c)
Comentario de reenvío automático:
Omitido.
d)
MIP devuelto:
Si se ha solicitado la devolución del
MIP por medio del componente peticiones de notificación de su especificador de
destinatario asunto, y está ausente el componente tipos de información
codificada convertida del argumento del sobre de entrega de mensaje, el MIP.
Omitido en otro caso.
18.5.1.3
Depósito de NNR
El AU depositará la NNR anteriormente mencionada (si existe) invocando depósito de mensaje. El argumento de su sobre será el prescrito para acuse automático de recibo (véase el 18.5.2.2 ), el argumento de su contenido se determina a partir de la NNR como se especifica en el 20.1 .
18.5.2
Acuse de recibo automático
El AU aplicará un acuse de recibo automático a cada mensaje candidato atendiendo a que sus contenidos respectivos cumplan las siguientes condiciones:
a)La variable de estado acuse de recibo automático tiene el valor
verdadero
y el MIP solicita una NR del usuario del AU por
medio del componente peticiones de notificación del especificador de
destinatario asunto del MIP.
El AU acusará recibo automáticamente de cada uno de estos mensajes de acuerdo con lo siguiente.
18.5.2.1
Construcción de NR
El AU construirá una NR.
La NR tendrá los siguientes campos comunes:
a)
MIP sujeto:
El campo de encabezamiento Este MIP del
MIP.
b)
Originador de NIP:
Especificado u omitido como asunto
local (pero, desde luego, conforme al
8.1.2
).
c)
Destinatario preferido del MIP:
El componente
destinatario del especificador de destinatario asunto del MIP, a menos que su
componente nombre formal sea el nombre O/D del usuario del AU, en cuyo caso
deberá omitirse este campo.
d)
Conversión de TIC:
Componente tipos de información
codificada convertida del argumento del sobre de entrega de mensaje.
La NR tendrá los siguientes campos de recepción:
a)
Hora de recepción:
La fecha y hora en cuestión.
b)
Modo de acuse de recibo:
El valor
automático
.
c)
Información de recepción suplementaria:
La variable
de estado información de recepción suplementaria de acuse de recibo automático.
18.5.2.2
Depósito de NR
El AU depositará la NR mencionada anteriormente invocando depósito de mensaje con los siguientes argumentos:
a)
Sobre:
Los componentes de este argumento serán los
prescritos para la realización de la operación abstracta generación NR con las
siguientes excepciones:
i)
Prioridad:
Como se especifica por el argumento del
sobre de entrega de mensaje.
ii)
Indicadores para cada mensaje:
Asunto local, con la
salvedad de que entre los valores especificados deberá estar
conversión prohibida
.
iii)
Campos para cada destinatario:
Un campo único cuyo
componente nombre de destinatario formará parte del componente nombre de
originador del argumento del sobre de entrega de mensaje. No se solicitarán
informes.
b)
Contenido:
Determinado a partir de la NR como se
especifica en el
20.1
.
18.5.3
Retransmisión automática
El AU aplicará una retransmisión automática a cada mensaje candidato, si la
variable de estado retransmisión MIP tiene el valor
verdadero
.
El AU retransmitirá automáticamente tal mensaje de acuerdo con lo siguiente.
18.5.3.1
Prevención de bucles
El AU suprimirá la retransmisión automática si y sólo si el MIP que ha de retransmitirse contiene en sí mismo un MIP retransmisor que ha sido creado previamente por el AU. Se suprimirá la retransmisión automática con independencia de que el MIP retransmisor aparezca (directamente) en la parte de cuerpo mensaje del MIP que haya de retransmitirse, o (anidado) en una parte de cuerpo mensaje del MIP que aparece en tal parte de cuerpo.
El AU considerará que ha sido él mismo quien ha creado el MIP retransmisor
antes mencionado (cuyo campo de encabezamiento retransmitido automáticamente
tiene el valor
verdadero
) si y sólo si el componente
nombre de originador del componente parámetros del MIP concuerda con el nombre
O/D del usuario del AU.
Nota
- La retransmisión automática de un MIP de la
clase descrita anteriormente constituirá un
`bucle'
autorretransmisor.
18.5.3.2
Construcción de MIP
El AU construirá un MIP retransmisor cuyo encabezamiento es la variable de
estado encabezamiento de retransmisión automática (teniendo su campo
retransmitido automáticamente el valor
verdadero
) y cuyo
cuerpo comprende una sola parte de cuerpo de tipo mensaje.
La parte de cuerpo mensaje tendrá los siguientes componentes:
a)
Parámetros:
Argumento del sobre de entrega de
mensaje.
b)
Datos:
MIP a retransmitir.
18.5.3.3
Depósito de MIP
El AU depositará el MIP que ha construido en la forma mencionada anteriormente invocando depósito de mensaje con los siguientes argumentos:
a)
Sobre:
Los componentes de este argumento serán los
siguientes:
i)
Nombre de originador:
Nombre O/D del usuario del AU.
ii)
Tipo de contenido y tipos de información codificada
original
^: Determinados a partir del MIP como se
especifica en los
20.2
y 20.4.
iii)
Identificador de contenido:
Especificado y omitido
como asunto local.
iv)
Prioridad
^: Como se especifica mediante el argumento
del sobre de entrega de mensaje.
v)
Indicadores para cada mensaje y ampliaciones:
Asunto
local.
vi)
Hora de entrega diferida:
Omitida.
vii)
Campos para cada destinatario:
Sus componentes
nombre de destinatario serán los nombres O/D que constituyen la variable de
estado destinatarios de reenvío. Sus otros componentes son un asunto local.
b)
Contenido:
Determinado a partir del MIP como se
especifica en el
20.1
.
18.5.3.4
Construcción de NNR
El AU construirá una NNR si y sólo si se le solicita por medio del componente peticiones de notificación del especificador de destinatario asunto del MIP retransmitido.
La NNR tendrá los campos comunes prescritos para efectuar el acuse de recibo automático.
La NNR tendrá los siguientes campos de recepción:
a)
Motivo de no recepción:
Valor
mip
retransmitido automáticamente
.
b)
Motivo de descarte:
Omitido.
c)
Comentario de retransmisión automática:
Variable de
estado comentario de reenvío automático.
d)
MIP devuelto:
Si se solicita la devolución de MIP por
medio del componente peticiones de notificación de su especificador de
destinatario asunto, y el componente tipos de información codificada convertida
del argumento del sobre de entrega de mensaje está ausente, el MIP. Omitido en
otro caso.
18.5.3.5
Depósito de NNR
El AU depositará la NNR mencionada anteriormente (si la hubiere), invocando depósito de mensaje. El argumento del sobre de depósito de mensaje será el prescrito para acuse de recibo automático, determinándose el argumento de su contenido a partir de la NNR especificada en el 20.1 .
MONTAGE: FIN Rec. X.420 sur le reste de cette page
PARAMATERS DISK 1 NF01/022 OPM = 01 non-message NF01/030 OPM = 01 [0] NF01/030 OPM = 01 id-mod DISK 2 NF01/003 OPM = 02 ID ::= {^id-ipoms 10^} -- NF01/003 OPM = 02 id-mod-extended-body-part-types NF01/004 OPM = 02 id-bat-bilaterally-defined-body-parts NF01/008 OPM = 02 user-relative-identifier NF01/015 OPM = 02 [10] NF01/015 OPM = 02 VALUE NOTATION NF01/021 OPM = 02 ::= NF01/021 OPM = 02 parameters [0] NF01/023 OPM = 02 administration NF01/035 OPM = 02 [C] NF01/035 OPM = 02 enveloppe NF01/045 OPM = 02 submission-identifier NF01/045 OPM = 02 PARAMETERS NF01/055 OPM = 02 non-message DISK 3 NF01/008 OPM = 03 ub-auto-forward-comment NF01/034 OPM = 03 (cs,) - (cs,)
(1BT) (BT..)
(87.TE.17.S)
(A1.23s) / [26s]
FOLIOS: 582 - 628
(DO PRC.COSY.2)
MEP {TPS.NON.PHOTO "[PA1]"} : OK= [1]
Saisie 14.09.89 GG
ID + LASER 16.10.89 AF
MAJ diskette 18.10.89 AF
Corr. LASER (1re épreuve) = 3eme 09.11.89 GG
Espaces réservés 14.11.89 PC
AJOUTER (PA1) (CL1,0,0,0) pour MEP
MEP + LASER 22.11.89 SP
Corr. MEP ........ ..
Insertion des tableaux (tabulateurs...) ........ ..
BAT du 5/XII/89 6.12.89 PV
MAJ DISKETTE ........ ..
MONTAGE: REC. X.420 en tête de cette page
19
Operaciones de almacenamiento de
mensajes
Un AM deberá efectuar ciertas funciones específicas a la mensajería interpersonal para ser calificado como un AM SMIP y distinguirse de esa manera de un AM genérico. Estas funciones se tratan en el presente punto.
19.1
Creación de objetos de información
Un AM SMIP satisfará las siguientes exigencias relacionadas con los objetos de información que él mantiene:
a)El AM mantendrá un objeto de información separado para cada MIP o NIP (o para cada mensaje que contenga un MIP o NIP) que se le entrega.
b)El AM mantendrá como un objeto de información separado no solamente cada MIP retransmisor (o cada mensaje que contenga un tal MIP) [de acuerdo con el apartado a)] sino también cada MIP retransmitido (o mensaje que contenga un tal MIP) (recurrentemente).
c)El AM asignará números secuenciales, teniendo en cuenta primeramente la profundidad, a los mensajes en la jerarquía formada por un MIP retransmisor y sus MIP retransmitidos.
Ejemplo
- Si el MIP
A
^contiene
los MIP
B
^ y
C
^ entre sus partes de
cuerpo, y si el MIP
B
contiene los MIP
D
y
E
entre sus partes de cuerpo, los
números secuenciales se asignarán a los MIP en el orden siguiente:
A
,
B
,
D
,
E
, y
C
.
19.2
Mantenimiento de atributos
Un AM SMIP satisfará los siguientes requisitos relacionados con los atributos del AM:
a)Para cada MIP o NIP contenido por el AM, éste admitirá los atributos del anexo C tal como están allí especificados.
b)Para cada MIP contenido en el AM, éste dará los siguientes significados a los valores definidos del atributo estado del AM:
i)
nuevo:
^ No se han transportado valores de atributo al
AU.
ii)
listado:
^ Se ha transportado al AU al menos un valor
de atributo y no ha sido transportada al menos una parte de cuerpo.
iii)
procesado:
^ Todas las partes de cuerpo han sido
transportadas al AU.
c)Para cada NIP contenido en el AM, éste dará los siguientes significados a los valores definidos del atributo estado del AM:
i)
nuevo:
^ No se han transportado atributos al AU.
ii)
listado:
^ Se ha transportado al AU al menos un valor
de atributo, y se ha transportado al menos un valor de atributo distinto de MIP
devuelto.
iii)
procesado:
^ Todos los atributos, con la posible
excepción de MIP devuelto, han sido transportados al AU.
d)El atributo estado del AM reflejará la situación antes de la invocación de una operación abstracta que modifica su valor.
e)El atributo tipo de contenido de cada MIP o NIP (o de cada mensaje que lo contenga) que se entrega al AM tendrá el valor id-mct-p2-1984 o id-mct-p2-1988 (véase el anexo D), según proceda, lo que dependerá del tipo de contenido del mensaje entregado (véase el 20.2 ).
19.3
Notificación de no recepción
El AM, cuando descarta un MIP mientras está realizando una operación
abstracta supresión, del servicio abstracto AM, depositará una NNR si así se ha
solicitado y el atributo estado del AM del MIP tiene el valor
listado
.
19.4
Retransmisión automática
Un AM SMIP realizará la acción de retransmisión automática (Recomendación X.413) como se especifica en el 18.5.3 . Utiliza el componente otros-parámetros del argumento de registro de retransmisión automática de la operación abstracta del servicio abstracto AM. El tipo de datos del componente otros-parámetros se define de la manera siguiente:
Forwarded Info ::= SET^{ auto-forwarding-comment [0] AutoForwardComment OPTIONAL, cover-note [1] IA5TextBodyPart OPTIONAL, this-ipm-prefix [2] PrintableString (SIZE (1.^.ub-ipm-identifier-suffix)) OPTIONAL^}
Además, el AM cumplirá los siguientes requisitos:
a)Depositará una NNR, incluso si deja una copia del MIP retransmitido.
b)Tomará el campo comentario de reenvío de la NNR, si existe, extrayéndolo del componente otros-parámetros.
c)Tomará la nota-de cubierta, si existe, que deberá incluirse junto con el MIP retransmitido, extrayéndolo del componente otros-parámetros.
d)Prefijará el componente identificador relativo al usuario del campo este MIP del encabezamiento del MIP reenviante con este-prefijo-mip, si existe.
Nota
- Un AM (SMIP) no efectúa descartes automáticos
ni acuses de recibo automáticos, siendo las posibles excepciones un asunto
local.
19.5
Retransmisión manual
Un AM SMIP soportará la retransmisión manual de un mensaje utilizando la ampliación de petición-retransmisión de la Recomendación X.413, como se especifica en el 6.6 . El usuario de AM SMIP puede someter un MIP, incluyendo encabezamiento y cuerpo, utilizando la operación de depósito de mensaje, e identificar un mensaje que ya está en el AM y ha de combinarse con un cuerpo de mensaje depositado, para su retransmisión al (o a los) destinatarios del mensaje, utilizando la ampliación de petición-retransmisión.
El cuerpo de mensaje depositado y el mensaje retransmitido se combinan insertando el mensaje retransmitido, como una parte de cuerpo de mensaje en el cuerpo de mensaje depositado.
20
Contenido de
mensajes
Como ya se ha visto, diversos objetos secundarios (por ejemplo, AU) tienen ocasión de transportar los objetos de información descritos en la sección dos como contenidos de mensajes, y también de transportar sondas relativas a tales mensajes. Este punto especifica de manera precisa cómo deben hacerlo.
Las reglas que gobiernan la transmisión de esos mensajes y sondas, así como
la semántica y la sintaxis abstracta y de transferencia de su contenido, se
denominan
protocolo de mensajería interpersonal (P2)
.
Nota
- El nombre,
`P2'
, refleja el hecho
histórico de que éste fue el segundo protocolo de tratamiento de mensajes que
se desarrolló.
20.1
Contenido
Un objeto secundario que deposita un mensaje que contiene un MIP o una NIP suministrará como los octetos de la cadena de octetos que constituye el contenido del mensaje, el resultado de codificar objeto de información (InformationObject) de la sección dos de acuerdo con las reglas básicas de codificación de la Recomendación X.209.
20.2
Tipo de contenido
Un objeto secundario que deposita un mensaje que contiene un MIP o una NIP seleccionará su tipo de contenido de la manera siguiente.
Si el MIP o la NIP cumple todas las limitaciones, se especificará el entero 2:
i)El encabezamiento (de un MIP) está desprovisto del campo ampliaciones.
ii)El cuerpo (de un MIP) está desprovisto de partes de cuerpo definido externamente.
iii)El elemento parámetros de toda parte de cuerpo videotex: .^.^. (de un MIP) está desprovisto de miembro de sintaxis.
iv)Cada componente del MIP o de la NIP que es un valor de un tipo de datos definido como parte del servicio abstracto STRM cumple las limitaciones de la Recomendación X.411 (1984).
Los tipos en cuestión son los listados en la cláusula IMPORTS del módulo NSA.1 definido en el anexo E. Las restricciones en cuestión se detallan en un anexo de la Recomendación X.419.
v)El elemento datos de toda parte de cuerpo mensaje (de un MIP) cumple estas mismas limitaciones (en forma recurrente).
En otro caso, se especificará el entero 22.
Nota 1
- El protocolo de contenido de mensaje
designado (aquí) por el entero 2 es idéntico al especificado por la
Recomendación X.420 (1984) (aclarada por la versión 6 de la Recomendación
Guía del realizador de las Recomendaciones
de la serie X.400
), con excepción del tipo de parte de cuerpo documento
formatizable simple, definido en esta última, que se ha omitido en la primera.
Nota 2
- Se aconseja el uso del entero 2, mencionado
anteriormente, con preferencia al entero 22, para facilitar el
interfuncionamiento entre sistemas conformes a esta Recomendación y sistemas
conformes (solamente) a la Recomendación X.420 (1984).
El STRM no hace conversiones entre protocolos de contenido de mensaje. Por tanto, no hace conversiones entre el P2 definido en esta Recomendación solamente (y señalado por el entero 22) y el P2 definido por esta Recomendación y por la Recomendación X.420 (1984) (y señalado por el entero 2).
20.3
Longitud de contenido
Un objeto secundario que presenta una sonda relativa a un mensaje que contiene un MIP o una NIP especificará como longitud del contenido de mensaje el tamaño en octetos de la codificación del caso en cuestión del objeto de información (InformationObject) de la sección dos (elección de un MIP o una NIP) cuando se siguen las reglas básicas de codificación de la Recomendación X.209. Si esas reglas permiten varias codificaciones (por ejemplo, la primitiva y la construida) de ese objeto de información (InformationObject), la longitud de contenido puede reflejar cualquiera de las dos.
20.4
Tipos de información codificada
Un objeto secundario que deposita un mensaje que contiene un MIP o una NIP especificará los @tipos de información codificada (TIC)\ y los parámetros no básicos (PNB) de los mensajes de la manera siguiente.
En el caso de una NIP, los TIC básicos serán
no
especificado
.
En el caso de un MIP, los TIC básicos y los PNB se especificarán de acuerdo con las reglas siguientes:
a)
Partes de cuerpo múltiples:
^ Los TIC básicos (si
existen) y los PNB (si existen) del mensaje comprenderán la unión lógica de los
TIC básicos y los PNB de las partes de cuerpo individuales del MIP,
respectivamente.
b)
Parte de cuerpo mensaje retransmitido:
^ Los TIC
básicos (si existen) y los PNB (si existen) de una parte de cuerpo mensaje
serán los mismos del mensaje retransmitido.
c)
Parte de cuerpo definido externamente:
^ Una parte de
cuerpo definido externamente cuyo tipo ampliado corresponde a un tipo básico
(véase el anexo B) se tratará de manera prescrita para el tipo básico.
Cualquier otro tipo de parte de cuerpo ampliado se tratará como sigue. Si al
tipo corresponden uno o más TIC definidos externamente, serán especificados. De
no ser así, se indicará TIC
no definido
. En cualquiera de
los dos casos, no se especificará ningún PNB.
d)
Parte de cuerpo básico:
^ Los TIC básicos (si existen)
y los PNB (si existen) de una parte de cuerpo individual de un tipo que no sea
mensaje ni definido externamente dependerán del tipo de parte de cuerpo
especificado en el cuadro 2/X.420. Un tipo de parte de cuerpo para el cual el
cuadro no especifica TIC básicos no provocará el establecimiento de bits en la
cadena de bits de los TIC básicos.
e)
Parte de cuerpo cifrado:
^ El efecto de una parte de
cuerpo cifrado en los TIC básicos y los PNB que deben especificarse será objeto
de ulterior estudio.
Cduadro 2/X.420 [T2.420], p.
21 Realización de puertos
En la Recomendación X.419 se especifica la manera en que un AM o el STRM realiza concretamente los puertos secundarios que proporciona.
La forma en que un AU, ATLM, o UA realiza concretamente los puertos primarios que proporciona está fuera del ámbito de esta Recomendación.
Nota 1
- Un interfaz de usuario de AU es un asunto
local. Es posible una gran diversidad de interfaces que comprenden por ejemplo
gran variedad de dispositivos de entrada/salida.
Nota 2
- Una realización, por el ATLM, de sus puertos
primarios se especifica, en parte, en la Recomendación T.330 del CCITT.
Nota 3
- Una UA proporciona sus puertos primarios por
medio del sistema de comunicación particular a que da acceso esa UA.
22
Conformidad
A continuación se indican los requisitos que debe satisfacer un objeto
secundario (excluido el STRM) y su realizador cuando éste anuncia que el objeto
secundario es conforme a esta Recomendación. Cierto número de requisitos de
conformidad distinguen entre
sustentar en la generación y
sustentar en la recepción
.
22.1
Relación generación-recepción
Se dice que un AU, ATLM, o UA
sustentan en la generación
un determinado campo de encabezamiento, ampliación de encabezamiento, tipo de
parte de cuerpo básico, o tipo de parte de cuerpo ampliado, únicamente si
acepta, conserva y emite, exactamente como se prescribe en esta Recomendación,
ese determinado campo de encabezamiento o ampliación, o partes de cuerpo de ese
tipo determinado básico o ampliado, en todo momento que un usuario lo invoque
para transportar un MIP que los contenga, al STRM o al AM del usuario (este
último solamente en el caso de un AU).
Se dirá que un AU, ATLM o UA
sustenta en recepción
un
determinado campo de encabezamiento, ampliación de encabezamiento, tipo de
parte de cuerpo básico, o tipo de parte de cuerpo ampliado, únicamente si
acepta, conserva, y emite, exactamente como prescribe esta Recomendación, ese
determinado campo de encabezamiento o ampliación, partes de cuerpo de ese tipo
determinado básico o ampliado, en todo momento que el STRM o un AM de usuario
(este último solamente en el caso de un AU) lo invoque para transportar al
usuario un MIP que los contenga.
Nota
- De hecho, una UADP no sustenta nada en
generación porque ella no es el suministrador del puerto de generación.
22.2
Requisitos de los enunciados de conformidad
El realizador de un AU SMIP, AM SMIP, ATLM, o UA enunciará lo siguiente. Para cada uno de los puntos indicados a continuación deberá hacer enunciados separados relativos a la conformidad en la generación y la conformidad en recepción:
a)Los campos de encabezamiento y las ampliaciones de encabezamiento para los cuales anuncia conformidad.
b)Los tipos de parte de cuerpo básico y ampliado para los cuales anuncia conformidad.
c)En el caso de un AU SMIP o AM SMIP, los atributos de AM específicos o la mensajería interpersonal para los cuales anuncia conformidad.
22.3
Requisitos estáticos
Un AU SMIP, AM SMIP, ATLM, o UA satisfarán los siguientes requisitos estáticos:
a)Un AU SMIP, AM SMIP, ATLM o UA establecerá los campos de encabezamiento y las ampliaciones de encabezamiento, y los tipos de parte de cuerpo básico y ampliado para los cuales se anuncia conformidad.
b)Un AU SMIP o AM SMIP sustentará los atributos de AM específicos a la mensajería interpersonal para los cuales se anuncia conformidad, pero incluirá como mínimo los designados como obligatorios en el anexo C.
c)Un AU SMIP, AM SMIP, ATLM o UA realizará concretamente sus puertos abstractos como se especifica en el 21 .
d)Un AU SMIP o AM SMIP deberá poder depositar y aceptar la entrega de mensajes de los dos tipos de contenido indicados en el 20.2 . Un ATLM o UA deberá poder importar y exportar tales mensajes.
22.4
Requisitos dinámicos
Un AU SMIP, AM SMIP, ATLM o UA satisfarán los siguientes requisitos dinámicos:
a)Un AU SMIP o AM SMIP seguirá las reglas de operación especificadas en el 18 ó 19, respectivamente.
b)Un AU SMIP, AM SMIP, ATLM o UA depositará y aceptará la entrega de mensajes cuyo contenido sea el especificado en el 20 .
c)Un AU SMIP, AM SMIP, ATLM o UA inscribirá en el STRM su capacidad para aceptar entregas de mensajes de los dos tipos de contenido indicados en el 20.2 .
ANEXO A (a la Recomendación X.420)
Ampliaciones del
encabezamiento
Este anexo define todas las ampliaciones de encabezamiento (actualmente definidas).
A.1
Copia incompleta
La ampliación de encabezamiento
copia incompleta
, por su
presencia, indica que una o más partes de cuerpo o campos de encabezamiento
están ausentes del cuerpo del MIP (el caso presente del MIP). La ampliación
comprende un nulo (por defecto).
Incomplete-copy HEADING EXTENSION ::= id-hex-incomplete copy
Si esta ampliación está ausente del campo de ampliaciones, se considerará que todas las partes de cuerpo están presentes.
A.2
Idiomas
La ampliación de encabezamiento
idiomas
identifica los
idiomas utilizados en la composición del campo de encabezamiento asunto y
cuerpo del MIP. La ampliación comprende un conjunto de cero o más cadenas
imprimibles, siendo cada una de ellas uno de los códigos de idioma de dos
caracteres identificados en ISO 639.2.
languages HEADING-EXTENSION VALUE SET OF Language ::= id-hex-languages
Language ::= PrintableString (SIZE (2.^.2))
Si esta ampliación está ausente del campo de encabezamiento ampliaciones o no se indica ningún idioma, los idiomas deberán considerarse no especificados.
ANEXO B (a la Recomendación X.420)
Tipos de parte de
cuerpo ampliado
Para cada tipo de parte de cuerpo básico, esta Recomendación define como sigue un tipo de parte de cuerpo ampliado.
ia5-text-body-part EXTENDED-BODY-PART-TYPE PARAMETERSIA5TextParameters IDENTIFIED BY id-ep-ia5-text DATAIA5TextData ::= id-et-ia5-text
voice-body-part EXTENDED-BODY-PART-TYPE PARAMETERSVoiceParameters IDENTIFIED BY id-ep-voice DATAVoiceData ::= id-et-voice
g3-facsimile-body-part EXTENDED-BODY-PART-TYPE PARAMETERSG3FacsimileParameters IDENTIFIED BY id-ep-g3-facsimile DATAG3FacsimileData ::= id-et-g3-facsimile
g4-class1-body-part EXTENDED-BODY-PART-TYPE DATAG4Class1BodyPart ::= id-et-g4-class1
teletex-body-part EXTENDED-BODY-PART-TYPE PARAMETERSTeletexParameters IDENTIFIED BY id-ep-teletex DATATeletexData ::= id-et-teletex
videotex-body-part EXTENDED-BODY-PART-TYPE PARAMETERSVideotexParameters IDENTIFIED BY id-ep-videotex DATAVideotexData ::= id-et-videotex
encrypted-body-part EXTENDED-BODY-PART-TYPE PARAMETERSEncryptedParameters IDENTIFIED BY id-ep-encrypted DATAEncryptedData ::= id-et-encrypted
message-body-part EXTENDED-BODY-PART-TYPE PARAMETERSMessageParameters IDENTIFIED BY id-ep-message DATAMessageData ::= id-et-message
mixed-mode-body-part EXTENDED-BODY-PART-TYPE DATAMixedModeBodyPart ::= id-et-mixed-mode
bilaterally-defined-body-part EXTENDED-BODY-PART-TYPE DATABilaterallyDefinedBodyPart ::= id-et-bilaterally-defined
nationally-defined-body-part EXTENDED-BODY-PART-TYPE DATANationallyDefinedBodyPart ::= id-et-nationally-defined
ANEXO C (a la Recomendación X.420)
Atributos del
almacenamiento de mensajes
Como se ha descrito en la Recomendación X.413, un AM mantiene y proporciona acceso a ciertos atributos (por ejemplo, la importancia) de cada objeto de información contenido en el mismo. Un atributo comprende un tipo y, según el tipo de que se trate, uno o más valores. Los atributos que pueden adoptar varios valores simultáneamente (pertenecientes todos ellos a un solo objeto) se denominan atributos de múltiples valores (o multivaluados) y los que sólo pueden adoptar un valor se denominan atributos de un solo valor (o univaluados). Algunos atributos corresponden a objetos de información de todas clases, y otros objetos de información de ciertas clases (por ejemplo, los de la sección 2).
Este anexo define los atributos de AM específicos de la mensajería interpersonal.
Todos los atributos definidos en este anexo, con excepción de los que corresponden a los tipos de parte de cuerpo ampliado (que no pueden enumerarse: véase el Î C.3.6) se enumeran en la primera columna del cuadro C-1/X.420. En este cuadro se indica su presencia en una inscripción de mensaje entregado. Ninguno de ellos aparece en una inscripción de informe entregado ni en una inscripción de contenido devuelto. En cuanto a los símbolos utilizados en el cuadro, véase la Recomendación X.413.
C.1
Atributos de resumen
Algunos atributos resumen un objeto de información de mensajería interpersonal. Estos atributos se definen y describen a continuación.
C.1.1
Tipo de inscripción de MIP
El atributo
tipo de inscripción MIP
identifica un tipo
de objeto de información.
ipm-entry-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPMEntryType MATCHES FOR EQUALITY SINGLE VALUE ::= id-sat-ipm-entry-type
IPMEntryType ::= ENUMERATED^{ ipm(0), rn(1), nrn(2)^}
Este atributo puede adoptar uno de los siguientes valores:
a)
mip:
^ El objeto de información es un MIP.
b)
nr:
^ El objeto de información es una NR.
c)
nnr:
^ El objeto de información es una NNR.
Un AM que admite este atributo lo mantendrá para un objeto de información contenido en el mismo si y solo si ese objeto es un mensaje cuyo contenido es un MIP o un NIP.
Tableau C-1/X.420 [1T3.420], p. 2
Tableau C-1/X.420 [2T3.420], p. 3
C.1.2
Sinopsis de MIP
El atributo
sinopsis de MIP
da la estructura,
características, tamaño y estado de procesamiento de un MIP para la
granularidad de partes de cuerpo individuales.
ipm-synopsis ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPMSynopsis SINGLE VALUE ::= id-sat-ipm-synopsis
La sinopsis de un MIP consta de una sinopsis de cada una de sus partes de cuerpo. Las sinopsis aparecen en el mismo orden que las partes de cuerpo.
IPMSynopsis ::= SEQUENCE OF BodyPartSynopsis
La sinopsis de una parte de cuerpo adopta una de dos formas, lo que depende de que la parte de cuerpo sea del tipo mensaje. Esto permite a la sinopsis de un MIP retransmisor abarcar las partes de cuerpo de cada MIP retransmitido (recurrentemente), así como las del propio MIP retransmisor.
BodyPartSynopsis ::= CHOICE^{ message[0]MessageBodyPartSynopsis non-message[1]NonMessageBodyPartSynopsis^}
MessageBodyPartSynopsis ::= SEQUENCE^{ number[0]SequenceNumber, synopsis[1]IPMSynopsis^}
NonMessageBodyPartSynopsis ::= SEQUENCE^{ type[0]OBJECT IDENTIFIER, parameters[1]ExternallyDefinedParameters, size[2]INTEGER, processed[3]BOOLEAN DEFAULT FALSE^}
La sinopsis de una parte de cuerpo de mensaje tiene los siguientes componentes:
a)
Número
(O): Número secuencial que el AM asigna a la
inscripción representada por la parte de cuerpo mensaje.
b)
Sinopsis
(O): Sinopsis del MIP que forma el contenido
del mensaje representado por la parte de cuerpo.
La sinopsis de una parte de cuerpo de un tipo diferente de mensaje tiene los siguientes componentes. A los fines de esta sinopsis, se considera que la parte de cuerpo es del tipo definido externamente, independientemente (véase el anexo B) de que sea o no transportada al AM:
a)
Tipo
(O): Parte de cuerpo de tipo ampliado, es decir,
el componente referencia directa del componente datos de la parte de cuerpo. Es
un identificador de objeto.
b)
Parámetros
(O): Parámetros de formato y de control de
la parte de cuerpo, es decir, el componente parámetros de la parte de cuerpo.
Es un cualquiera (Any).
c)
Tamaño
(O): Tamaño en octetos de la codificación de
componente codificación del componente datos de la parte de cuerpo, cuando se
siguen las reglas básicas de codificación de la Recomendación X.209. Si esas
reglas permiten varias codificaciones (por ejemplo, la primitiva y la
construida) del componente, el tamaño puede reflejar cualquiera de ellas. Es un
entero.
d)
Procesado
(D
falso
): Indicación de
si la parte de cuerpo ha sido o no transportada al AU por medio de la operación
abstracta listado o captura del AM. Es un booleano.
Un AM que admite este atributo deberá mantenerlo para un objeto de información contenido por el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP.
Nota
- Como consecuencia de su variabilidad el valor
del componente tamaño debe considerarse solamente como una estimación del
tamaño de la parte de cuerpo.
C.2
Atributos del encabezamiento
Del encabezamiento de un MIP se derivan algunos atributos los cuales se definen y describen a continuación.
C.2.1
Encabezamiento
El abributo
encabezamiento
es el encabezamiento
(completo) de un MIP.
heading ATTRIBUTE WITH ATTRIBUTE-SYNTAX Heading SINGLE VALUE ::= id-hat-heading
Un AM que admite este atributo lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP.
C.2.2
Análisis del encabezamiento
Algunos atributos tienen como valores descriptores O/D seleccionados
después de un análisis del encabezamiento. Dichos valores identifican
destinatarios
`primarios'
,
`de copia'
, y
`de copia ciega'
de un MIP con relación al cual se ha solicitado una NR, NNR, o respuesta.
rn-requestors ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-rn-requestors
nrn-requestors ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-nrn-requestors
reply-requestors ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-reply-requestors
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP cuyo encabezamiento solicita, de al menos un usuario o LD, un NR, NNR o respuesta, respectivamente. Mantendrá un valor de atributo para cada especificador de destinatario en el campo de destinatarios primarios, de copia, o de copia ciega del MIP, campo cuyo componente peticiones de notificación incluye el valor nr (en el caso del primer atributo) o nnr (en el caso del segundo), o cuyo componente respuesta solicitada significa, por su presencia o ausencia, que se ha solicitado una respuesta (en el caso del tercero). El valor será el componente destinatario del especificador de destinatario.
C.2.3
Campos del encabezamiento
Algunos atributos llevan los nombres de campos de encabezamiento y tienen estos campos como sus valores. Para la ordenación de los atributos de hora de expiración y hora de respuesta se sigue el orden cronológico creciente.
this-ipm ATTRIBUTE WITH ATTRIBUTE-SYNTAX This IPMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-this-ipm
originator ATTRIBUTE WITH ATTRIBUTE-SYNTAX OriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-originator
replied-to-IPM ATTRIBUTE WITH ATTRIBUTE-SYNTAX RepliedToIPMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-replied-to-IPM
subject ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-hat-subject
expiry-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX ExpiryTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-expiry-time
reply-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReplyTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-reply-time
importance ATTRIBUTE WITH ATTRIBUTE-SYNTAX ImportanceField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-importance
sensitivity ATTRIBUTE WITH ATTRIBUTE-SYNTAX SensitivityField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-sensitivity
auto-forwarded ATTRIBUTE WITH ATTRIBUTE-SYNTAX AutoForwardedField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-auto-forwarded
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP cuyo encabezamiento contiene el campo cuyo nombre lleva el atributo.
C.2.4
Subcampos del encabezamiento
Algunos atributos llevan los nombres de campos de encabezamiento y tienen como valores subcampos de esos campos.
authorizing-users ATTRIBUTE WITH ATTRIBUTE-SYNTAX AuthorizingUsersSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-authorizing-users
primary-recipients; ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrimaryRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-primary-recipients
copy-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX CopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-copy-recipients
blind-copy-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX BlindCopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-blind-copy-recipients
obsoleted-IPMs ATTRIBUTE WITH ATTRIBUTE-SYNTAX ObsoletedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-obsoleted-IPMs
related-IPMs ATTRIBUTE WITH ATTRIBUTE-SYNTAX RelatedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-related-IPMs
reply-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReplyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-reply-recipients
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP cuyo encabezamiento contiene el campo cuyo nombre lleva el atributo. Mantendrá un valor de atributo para cada subcampo.
C.2.5
Ampliaciones del encabezamiento
Algunos atributos llevan los nombres de ampliaciones de encabezamiento y tienen como valores los valores de estas ampliaciones o una parte de los mismos.
incomplete-copy ATTRIBUTE WITH ATTRIBUTE-SYNTAX incompleteCopyExtensionValue MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-incomplete-copy
languages ATTRIBUTE WITH ATTRIBUTE-SYNTAX Language MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-languages
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP cuyo encabezamiento contiene la ampliación cuyo nombre lleva el atributo. En el caso de los atributos de idioma, el AM mantendrá un valor de atributo para cada idioma identificado por la ampliación.
C.3
Atributos de cuerpo
Algunos atributos se derivan del cuerpo de un MIP. Estos atributos se definen y describen a continuación.
C.3.1
Cuerpo
El atributo
cuerpo
es el cuerpo (completo) de un MIP.
body ATTRIBUTE WITH ATTRIBUTE-SYNTAX Body SINGLE VALUE ::= id-bat-body
Un AM que admite este atributo lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP.
C.3.2
Partes de cuerpo básico
Algunos atributos llevan los nombres de tipos de parte de cuerpo básico y tienen como valores, con una excepción, tales parte de cuerpo.
Un AM contiene cada MIP retransmitido (es decir, cada parte de cuerpo mensaje) como un objeto de información por su propio derecho, separado del MIP retransmisor. Ese objeto de información, por supuesto, es un mensaje cuyo contenido es un MIP. El atributo partes de cuerpo de mensaje, que se indica más adelante, tiene por tanto como valores la secuencia de números que el AM asigna a esos mensajes.
ia5-text-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX IA5TextBodyPart MULTI VALUE ::= id-bat-ia5-text-body-parts
voice-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX VoiceBodyPart MULTI VALUE ::= id-bat-voice-body-parts
g3-facsimile-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX G3FacsimileBodyPart MULTI VALUE ::= id-bat-g3-facsimile-body-parts
g4-class1-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX G4Class1BodyPart MULTI VALUE ::= id-bat-g4-class1-body-parts
teletex-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexBodyPart MULTI VALUE ::= id-bat-teletex-body-parts
videotex-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX VideotexBodyPart MULTI VALUE ::= id-bat-videotex-body-parts
encrypted-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX EncryptedBodyPart MULTI VALUE ::= id-bat-encrypted-body-parts
message-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MULTI VALUE ::= id-bat-message-body-parts
mixed-mode-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX MixedModeBodyPart MULTI VALUE ::= id-bat-mixed-mode-body-parts
bilaterally-defined-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX BilaterallyDefinedBodyPart MULTI VALUE ::= id-bat-bilaterally-defined-body-parts
nationally-defined-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX NationallyDefinedBodyPart MULTI VALUE ::= id-bat-nationally-defined-body-parts
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP cuyo cuerpo contiene una o más partes de cuerpo del tipo cuyo nombre lleva el atributo. Mantendrá un valor de atributo para cada una de esas partes de cuerpo.
C.3.3
Componentes de parámetros de parte de cuerpo
básico
Algunos atributos llevan los nombres de tipos de parte de cuerpo básico y tienen como valores los componentes parámetros de esas partes de cuerpo.
ia5-text-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX IA5TextParameters MULTI VALUE ::= id-bat-ia5-text-parameters
voice-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX VoiceParameters MULTI VALUE ::= id-bat-voice-parameters
g3-facsimile-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX G3FacsimileParameters MULTI VALUE ::= id-bat-g3-facsimile-parameters
teletex-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexParameters MULTI VALUE ::= id-bat-teletex-parameters
videotex-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX VideotexParameters MULTI VALUE ::= id-bat-videotex-parameters
encrypted-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX EncryptedParameters MULTI VALUE ::= id-bat-encrypted-parameters
message-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageParameters MULTI VALUE ::= id-bat-message-parameters
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si el objeto es un mensaje cuyo contenido es un MIP cuyo cuerpo contiene una o más partes de cuerpo del tipo cuyo nombre lleva el atributo. Mantendrá un valor de atributo para cada una de esas partes de cuerpo.
C.3.4
Componentes de datos de parte de cuerpo
básico
Algunos atributos llevan los nombres de tipos de parte de cuerpo básico y tienen como valores componentes datos de esas partes de cuerpo.
ia5-text-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX IA5TextData MULTI VALUE ::= id-bat-ia5-text-data
voice-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX VoiceData MULTI VALUE ::= id-bat-voice-data
g3-facsimile-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX G3FacsimileData MULTI VALUE ::= id-bat-g3-facsimile-data
teletex-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexData MULTI VALUE ::= id-bat-teletex-data
videotex-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX VideotexData MULTI VALUE ::= id-bat-videotex-data
encrypted-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX EncryptedData MULTI VALUE ::= id-bat-encrypted-data
message-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageData MULTI VALUE ::= id-bat-message-data
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP cuyo cuerpo contiene una o más partes de cuerpo del tipo cuyo nombre lleva el atributo. Mantendrá un valor de atributo para cada una de esas partes de cuerpo.
C.3.5
Tipos de partes de cuerpo ampliado
El atributo
tipos de parte de cuerpo ampliado
identifica
los tipos de parte de cuerpo ampliado representados en un MIP.
extended-body-part-types ATTRIBUTE WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY MULTI VALUE ::= id-bat-extended-body-part-types
Un AM que admite este atributo lo mantendrá para un objeto de información contenido en el mismo, si y solo si el objeto es un mensaje cuyo contenido es un MIP cuyo cuerpo contiene uno o más partes de cuerpo definido externamente. Mantendrá un valor de atributo para cada tipo presente. El valor designará el tipo como se especifica en el 7.3.12 .
Nota
- Cada valor de este atributo corresponde a uno
de los atributos descritos en el Î C.3.6.
C.3.6
Partes de cuerpo ampliado
Algunos atributos, no denominados, tienen como sus valores los componentes codificación (véase el 7.3.12 ) de los externos NSA.1 que constituyen los componentes datos de partes de cuerpo definido externamente.
A cada tipo de parte de cuerpo ampliado corresponden dos atributos. El primer atributo es designado por el identificador de objeto que es el componente referencia directa (véase también aquí el 7.3.12 ) del externo que constituye el componente datos de una parte de cuerpo de ese tipo. El contenido de este primer atributo es dicho componente datos. El segundo atributo es designado por el identificador de objeto que es el componente referencia directa del externo que constituye el componente parámetros de una parte de cuerpo de ese tipo. El contenido de este segundo atributo es dicho componente parámetros.
Un AM que admite una de estas parte de cuerpo mantendrá ambos atributos para un objeto de información contenido en el mismo, si y solo si el objeto es un mensaje cuyo contenido es un MIP cuyo cuerpo contiene una o más partes de cuerpo del tipo que corresponde a ese atributo. Mantendrá un valor de cada atributo para cada una de esas partes de cuerpo.
Nota 1
- Los atributos de parte de cuerpo ampliado no
pueden enumerarse en la práctica, pues los tipos de parte de cuerpo ampliado no
pueden enumerarse entonces.
Nota 2
- El atributo tipos de parte de cuerpo ampliado
(véase el Î C.3.5) determina los atributos de parte de cuerpo ampliado para un
MIP determinado.
C.4
Atributos de notificación
Algunos atributos se derivan de una NIP. Estos atributos se definen y describen a continuación.
C.4.1
Campos comunes
Algunos atributos llevan los nombres de campos comunes y tienen esos campos como valores.
subject-ipm ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectIPMField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-subject-ipm
ipn-originator ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPNOriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-ipn-originator
ipm-preferred-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPMPreferredRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-ipm-preferred-recipient
conversion-eits ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EITs MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-conversion-eits
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es un MIP que contiene el campo cuyo nombre lleva el atributo.
C.4.2
Campos de no recepción
Algunos atributos llevan los nombres de campos de no recepción y tienen esos campos como valores.
non-receipt-reason ATTRIBUTE WITH ATTRIBUTE-SYNTAX NonReceiptReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-non-receipt-reason
discard-reason ATTRIBUTE WITH ATTRIBUTE-SYNTAX DiscardReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-discard-reason
auto-forward-comment ATTRIBUTE WITH ATTRIBUTE-SYNTAX AutoForwardCommentField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-auto-forward-comment
returned-ipm ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReturnedIPMField SINGLE VALUE ::= id-nat-returned-ipm
Un AM que admite uno de estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es una NNR que contiene el campo cuyo nombre lleva el atributo.
C.4.3
Campos de recepción
Algunos atributos llevan los nombres de campos de recepción y tienen esos nombres como valores. Para la ordenación del atributo hora de recepción se sigue el orden cronológico creciente.
receipt-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReceiptTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-nat-receipt-time
acknowledgment-mode ATTRIBUTE WITH ATTRIBUTE-SYNTAX AcknowledgmentModeField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-acknowledgment-mode
suppl-receipt-info ATTRIBUTE WITH ATTRIBUTE-SYNTAX SupplReceiptInfoField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-suppl-receipt-info
Un AM que admite estos atributos lo mantendrá para un objeto de información contenido en el mismo, si y solo si ese objeto es un mensaje cuyo contenido es una NR que contiene el campo cuyo nombre lleva el atributo.
ANEXO D (a la Recomendación X.420)
Definición de
referencia de indicadores de objeto
El anexo define, con fines de referencia, diversos identificadores de objeto mencionados en módulos NSA.1 de anexos subsiguientes. Utiliza NSA.1.
Todos los identificadores de objeto asignados por esta Recomendación figuran como tales en este anexo. El anexo es definitivo con respecto a todos ellos, salvo los que corresponden a módulos NSA.1 y a la aplicación SMIP propiamente dicha. Las asignaciones definitivas para los primeros vienen dadas en los propios módulos; otras referencias a los mismos se dan en cláusulas IMPORT. Los últimos son fijos.
IPMObjectIdentifiers {^joint-iso-ccitt mhs-motis(6) modules(0) object-identifiers(0)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS --
nada
--;
ID ::= OBJECT IDENTIFIER
--
Mensajería Interpersonal
(
no
definitivo
)
id-ipms ID ::= {^joint-iso-ccitt mhs-motis(6) ipms(1)^} --
no definitivo
--
Categorías
id-mod ID ::= {^id-ipms 0^} --
módulos; no
definitivos
id-ot ID ::= {^id-ipms 1^} --
tipos de objeto
id-pt ID ::= {^id-ipms 2^} --
tipos de puerto
id-ref ID ::= {^id-ipms 3^} --
perfeccionamientos
id-et ID ::= {^id-ipms 4^} --
tipos de parte de cuerpo
ampliado
id-hex ID ::= {^id-ipms 5^} --
ampliaciones de
encabezamiento
id-sat ID ::= {^id-ipms 6^} --
atributos de resumen
id-hat ID ::= {^id-ipms 7^} --
atributos de
encabezamiento
id-bat ID ::= {^id-ipms 8^} --
atributos de cuerpo
id-nat ID ::= {^id-ipms 9^} --
atributos de notificación
id-mct ID ::= {^id-ipms 10^} --
tipos de contenido de
mensaje
id-ep ID ::= {^id-ipms 11^} --
parámetros de parte de
cuerpo ampliado
--
Módulos
id-mod-object-identifiers ID ::= {^id-mod 0^} --
no
definitivo
id-mod-functional-objects ID ::= {^id-mod 1^} --
no
definitivo
id-mod-information-objects ID ::= {^id-mod 2^} --
no
definitivo
id-mod-abstract-service ID ::= {^id-mod 3^} --
no
definitivo
id-mod-heading-extensions ID ::= {^id-mod 6^} --
no
definitivo
id-mod-extended-body-part-types ID ::= {^id-mod 7^} --
no
definitivo
id-mod-message-store-attributes ID ::= {^id-mod 8^} --
no
definitivo
id-mod-upper-bounds ID ::= {^id-mod 10^} --
no
definitivo
--
Tipos de objeto
id-ot-ipme ID ::= {^id-ot 0^} id-ot-ipms-user ID ::= {^id-ot 1^} id-ot-ipms ID ::= {^id-ot 2^} id-ot-ipms-ua ID ::= {^id-ot 3^} id-ot-ipms-ms ID ::= {^id-ot 4^} id-ot-tlma ID ::= {^id-ot 5^} id-ot-tlxau ID ::= {^id-ot 6^} id-ot-pdau ID ::= {^id-ot 7^}
--
Tipos de puerto
id-pt-origination ID ::= {^id-pt 0^} id-pt-reception ID ::= {^id-pt 1^} id-pt-management ID ::= {^id-pt 2^}
--
Perfeccionamientos
id-ref-primary ID ::= {^id-ref 0^} id-ref-secondary ID ::= {^id-ref 1^}
--
Tipos de parte de cuerpo ampliado
id-et-ia5-text ID ::= {^id-et 0^} id-et-voice ID ::= {^id-et 1^} id-et-g3-facsimile ID ::= {^id-et 2^} id-et-g4-classe1 ID ::= {^id-et 3^} id-et-teletex ID ::= {^id-et 4^} id-et-videotex ID ::= {^id-et 5^} id-et-encrypted ID ::= {^id-et 6^} id-et-message ID ::= {^id-et 7^} id-et-mixed-mode ID ::= {^id-et 8^} id-et-bilaterally-defined ID ::= {^id-et 9^} id-et-nationally-defined ID ::= {^id-et 10^}
--
Ampliaciones de encabezamiento
id-hex-incomplete-copy ID ::= {^id-hex 0^} id-hex-languages ID ::= {^id-hex 1^}
--
Atributos de resumen
id-sat-ipm-entry-type ID ::= {^id-sat 0^} id-sat-ipm-synopsis ID ::= {^id-sat 1^}
--
Atributos de encabezamiento
id-hat-heading ID ::= {^id-hat 0^} id-hat-this-ipm ID ::= {^id-hat 1^} id-hat-originator ID ::= {^id-hat 2^} id-hat-replied-to-IPM ID ::= {^id-hat 3^} id-hat-subject ID ::= {^id-hat 4^} id-hat-expiry-time ID ::= {^id-hat 5^} id-hat-reply-time ID ::= {^id-hat 6^} id-hat-importance ID ::= {^id-hat 7^} id-hat-sensitivity ID ::= {^id-hat 8^} id-hat-auto-forwarded ID ::= {^id-hat 9^} id-hat-authorizing-users ID ::= {^id-hat 10^} id-hat-primary-recipients ID ::= {^id-hat 11^} id-hat-copy-recipients ID ::= {^id-hat 12^} id-hat-blind-copy-recipients ID ::= {^id-hat 13^} id-hat-obsoleted-IPMs ID ::= {^id-hat 14^} id-hat-related-IPMs ID ::= {^id-hat 15^} id-hat-reply-recipients ID ::= {^id-hat 16^} id-hat-incomplete-copy ID ::= {^id-hat 17^} id-hat-languages ID ::= {^id-hat 18^} id-hat-rn-requestors ID ::= {^id-hat 19^} id-hat-nrn-requestors ID ::= {^id-hat 20^} id-hat-reply-requestors ID ::= {^id-hat 21^}
--
Atributos de cuerpo
id-bat-body ID ::= {^id-bat 0^} id-bat-ia5-text-body-parts ID ::= {^id-bat 1^} id-bat-voice-body-parts ID ::= {^id-bat 2^} id-bat-g3-facsimile-body-parts ID ::= {^id-bat 3^} id-bat-g4-class1-body-parts ID ::= {^id-bat 4^} id-bat-teletex-body-parts ID ::= {^id-bat 5^} id-bat-videotex-body-parts ID ::= {^id-bat 6^} id-bat-encrypted-body-parts ID ::= {^id-bat 7^} id-bat-message-body-parts ID ::= {^id-bat 8^} id-bat-mixed-mode-body-parts ID ::= {^id-bat 9^} id-bat-bilaterally-defined-body-parts ID ::= {^id-bat 10^} id-bat-nationally-defined-body-parts ID ::= {^id-bat 11^} id-bat-extended-body-part-types ID ::= {^id-bat 12^} id-bat-ia5-text-parameters ID ::= {^id-bat 13^} id-bat-voice-parameters ID ::= {^id-bat 14^} id-bat-g3-facsimile-parameters ID ::= {^id-bat 15^} id-bat-teletex-parameters ID ::= {^id-bat 16^} id-bat-videotex-parameters ID ::= {^id-bat 17^} id-bat-encrypted-parameters ID ::= {^id-bat 18^} id-bat-message-parameters ID ::= {^id-bat 19^} id-bat-ia5-text-data ID ::= {^id-bat 20^} id-bat-voice-data ID ::= {^id-bat 21^} id-bat-g3-facsimile-data ID ::= {^id-bat 22^} id-bat-teletex-data ID ::= {^id-bat 23^} id-bat-videotex-data ID ::= {^id-bat 24^} id-bat-encrypted-data ID ::= {^id-bat 25^} id-bat-message-data ID ::= {^id-bat 26^}
--
Atributos de notificación
id-nat-subject-ipm ID ::= {^id-nat 0^} id-nat-ipn-originator ID ::= {^id-nat 1^} id-nat-ipm-preferred-recipient ID ::= {^id-nat 2^} id-nat-conversion-eits ID ::= {^id-nat 3^} id-nat-non-receipt-reason ID ::= {^id-nat 4^} id-nat-discard-reason ID ::= {^id-nat 5^} id-nat-auto-forward-comment ID ::= {^id-nat 6^} id-nat-returned-ipm ID ::= {^id-nat 7^} id-nat-receipt-time ID ::= {^id-nat 8^} id-nat-acknowledgment-mode ID ::= {^id-nat 9^} id-nat-suppl-receipt-info ID ::= {^id-nat 10^}
--
Tipos de contenido de mensaje
^
(
para uso por AM solamente
)
id-mct-p2-1984 ID ::= {^id-mct 0^} --
P2 1984
id-mct-p2-1988 ID ::= {^id-mct 1^} --
P2 1988
--
Parámetros de parte de cuerpo ampliado
id-ep-ia5-text ID ::= {^id-ep 0^} id-ep-voice ID ::= {^id-ep 1^} id-ep-g3-facsimile ID ::= {^id-ep 2^} id-ep-teletex ID ::= {^id-ep 4^} id-ep-videotex ID ::= {^id-ep 5^} id-ep-encrypted ID ::= {^id-ep 6^} id-ep-message ID ::= {^id-ep 7^}
END --
of IPMSObjectIdentifiers
ANEXO E (a la Recomendación X.420)
Definición de
referencia de objetos de información abstractos
Este anexo, que es un suplemento de la sección dos, define con fines de referencia los objetos de información abstractos de mensajería interpersonal.
IPMSInformationObjects {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) information-objects(2)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Límites superiores SMIP
ub-auto-forward-comment, ub-free-form-name, ub-ipm-identifier-suffix, ub-local-ipm-identifier, ub-subject-field, ub-telephone-number ---- FROM IPMSUpperBounds {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) upper-bounds(10)^}
--
TAMD
ProtocolElement ---- FROM dTAM
--
Servicio abstracto STRM
EncodedInformationTypes, G3FacsimileNonBasicParameters, MessageDeliveryTime, ORAddress, ORName, OtherMessageDeliveryFields, SupplementaryInformation, TeletexNonBasicParameters, ---- FROM MTSAbstractService {^joint-iso-ccitt mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)^};
Time ::= UTCTime
--
Objeto de información
InformationObject ::= CHOICE^{ ipm [0] IPM, ipn [1] IPN^}
--
MIP
IPM ::= SEQUENCE^{
heading Heading,
body
Body^}
--
Encabezamiento
Heading ::= SET^{ this-IPM ThisIPMField, originator [0] OriginatorField OPTIONAL, authorizing-users [1] AuthorizingUsersField OPTIONAL, primary-recipients [2] PrimaryRecipientsField DEFAULT {^}, copy-recipients [3] CopyRecipientsField DEFAULT {^}, blind-copy-recipients [4] BlindCopyRecipientsField OPTIONAL, replied-to-IPM [5] RepliedToIPMField OPTIONAL, obsoleted-IPMs [6] ObsoletedIPMsField DEFAULT {^}, related-IPMs [7] RelatedIPMsField DEFAULT {^}, subject [8] EXPLICIT SubjectField OPTIONAL, expiry-time [9] ExpiryTimeField OPTIONAL, reply-time [10] ReplyTimeField OPTIONAL, reply-recipients [11] ReplyRecipientsField OPTIONAL, importance [12] ImportanceField DEFAULT normal, sensitivity [13] SensitivityField OPTIONAL, auto-forwarded [14] AutoForwardedField DEFAULT FALSE, extensions [15] ExtensionsField DEFAULT {^}^}
--
Tipos de componente de encabezamiento
IPMIdentifier ::= [APPLICATION 11] SET^{ user ORAdress OPTIONAL user-relative-identifier LocalIPMIdentifier^}
LocalIPMIdentifier ::= PrintableString (SIZE (0.^.ub-local-ipm-identifier))
RecipientSpecifier ::= SET^{ recipient [0] ORDescriptor, notification-requests [1] NotificationRequests DEFAULT {^}, reply-requested [2] BOOLEAN DEFAULT FALSE^}
NotificationRequests ::= BIT STRING^{ rn(0), nrn(1), ipm-return(2)^}
ORDescriptor ::= SET^{ formal-name ORName OPTIONAL, free-form-name [0] FreeFormName OPTIONAL, telephone-number [1] TelephoneNumber OPTIONAL^}
FreeFormName ::= TeletexString (SIZE (0.^.ub-free-form-name))
TelephoneNumber ::= PrintableString (SIZE (0.^.ub-telephone-number))
--
Campo de encabezamiento este MIP
ThisIPMField ::= IPMIdentifier
--
Campo de encabezamiento originador
OriginatorField ::= ORDescriptor
--
Campo de encabezamiento usuarios autorizantes
AuthorizingUsersField ::= SEQUENCE OF AuthorizingUsersSubfield
AuthorizingUsersSubField ::= ORDescriptor
--
Campo de encabezamiento destinatarios primarios
PrimaryRecipientsField ::= SEQUENCE OF PrimaryRecipientsSubfield
PrimaryRecipientsSubfield ::= RecipientSpecifier
--
Campo de encabezamiento destinatarios de copia
CopyRecipientsField ::= SEQUENCE OF CopyRecipientsSubfield
CopyRecipientsField ::= RecipientsSpecifier
--
Campo de encabezamiento destinatarios de copia
ciega
BlindCopyRecipientsField ::= SEQUENCE OF BlindCopyRecipientsSubfield
BlindCopyRecipientsField ::= RecipientsSpecifier
--
Campo de encabezamiento MIP contestado
RepliedToIPMField ::= IPMIdentifier
--
Campo de encabezamiento MIP obsoleto
ObsoletedIPMsField ::= SEQUENCE OF ObsoletedIPMsSubfield
ObsoletedIPMsSubfield ::= IPMIdentifier
--
Campo de encabezamiento MIP conexos
RelatedIPMsField ::= SEQUENCE OF RelatedIPMsSubfield
RelatedIPMsSubfield ::= IPMIdentifier
--
Campo de encabezamiento asunto
SubjectField ::= TeletexString (SIZE (0.^.ub-subject-field))
--
Campo de encabezamiento hora de expiración
ExpiryTimeField ::= Time
--
Campo de encabezamiento hora de respuesta
ReplyTimeField ::= Time
--
Campo de encabezamiento destinatarios de respuesta
ReplyRecipientsField ::= SEQUENCE OF ReplyRecipientsSubfield
ReplyRecipientsSubfield ::= ORDescriptor
--
Campo de encabezamiento importancia
ImportanceField ::= ENUMERATED^{ low (0), normal (1), high (2)^}
--
Campo de encabezamiento sensibilidad
SensitivityField ::= ENUMERATED^{ personal (1), private (2), company-confidential (3)^}
--
Campo de encabezamiento retransmitido
automáticamente
AutoForwardedField ::= BOOLEAN
--
Campo de encabezamiento ampliaciones
ExtensionsField ::= SET OF HeadingExtension
HeadingExtension ::= SEQUENCE^{ type OBJECT IDENTIFIER, value ANY DEFINED BY type DEFAULT NULL NULL^}
HEADING-EXTENSION MACRO ::=
BEGIN
TYPE NOTATION ::=
"VALUE"
type^|^empty
VALUE NOTATION ::= value (VALUE OBJECT
IDENTIFIER)
END
--
Cuerpo
Body ::= SEQUENCE OF BodyPart
BodyPart ::= CHOICE^{ ia5-text [0] IA5TextBodyPart, voice [2] VoiceBodyPart, g3-facsimile [3] G3FacsimileBodyPart, g4-class1 [4] G4Class1BodyPart, teletex [5] TeletexBodyPart, videotex [6] VideotextBodyPart, encrypted [8] EncryptedBodyPart, message [9] MessageBodyPart, mixed-mode [11] MixedModeBodyPart, bilaterally-defined [14] BilaterallyDefinedBodyPart, nationally-defined [7] NationallyDefinedBodyPart, externally-defined [15] ExternallyDefinedBodyPart^}
--
Parte de cuerpo texto AI5
IA5TextBodyPart ::= SEQUENCE^{ parameters IA5TextParameters, data IA5TextData^}
IA5TextParameters ::= SET^{ repertoire [0] Repertoire DEFAULT ia5^}
IA5TextData ::= IA5String
Repertoire ::= ENUMERATED^{ ita2(2), ia5 (5)^}
--
Parte de cuerpo voz
VoiceBodyPart ::= SEQUENCE^{ parameters Voiceparameters, data VoiceData^}
VoiceParameters ::= SET --
para ulterior estudio
VoiceData ::= BIT STRING --
para ulterior estudio
--
Parte de cuerpo facsímil G3
G3FacsimileBodyPart ::= SEQUENCE^{ parameters G3FacsimileParameters, data G3FacsimileData^}
G3FacsimileParameters ::= SET^{ number-of-pages [0] INTEGER OPTIONAL, non-basic-parameters [1] G3FacsimileNonBasicParameters OPTIONAL^}
G3FacsimileData ::= SEQUENCE OF BIT STRING
--
Partes de cuerpo G4 clase 1 y modo mixto
G4Class1BodyPart ::= SEQUENCE OF ProtocolElement
MixedModeBodyPart ::= SEQUENCE OF ProtocolElement
--
Partes de cuerpo teletex
TeletexBodyPart ::= SEQUENCE^{ parameters TeletexParameters, data TeletexData^}
TeletexParameters ::= SET^{ number-of-pages [0] INTEGER OPTIONAL, telex-compatible [1] BOOLEAN DEFAULT FALSE, non-basic-parameters [2] TeletexNonBasicParameters OPTIONAL^}
TeletexData ::= SEQUENCE OF TeletexString
--
Parte de cuerpo videotex
VideotexBodyPart ::= SEQUENCE^{ parameters VideotexParameters, data VideotexData^}
VideotexParameters ::= SET^{ syntax [0] VideotexSyntax OPTIONAL^}
VideotexSyntax ::= INTEGER^{ ids (0), data-syntax1 (1), data-syntax2 (2), data-syntax3 (3)^}
VideotexData ::= VideotexString
--
Parte de cuerpo cifrado
EncryptedBodyPart ::= SEQUENCE^{ parameters EncryptedParameters, data EncryptedData^}
EncryptedParameters ::= SET --
para ulterior estudio
EncryptedData ::= BIT STRING --
para ulterior estudio
--
Parte de cuerpo mensaje
MessageBodyPart ::= SEQUENCE^{ parameters MessageParameters, data MessageData^}
MessageParameters ::= SET^{ delivery-time [0] MessageDeliveryTime OPTIONAL, delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL^}
MessageData ::= IPM
--
Parte de cuerpo definido bilateralmente
BilaterallyDefinedBodyPart ::= OCTET STRING
--
Parte de cuerpo definido nacionalmente
NationallyDefinedBodyPart ::= ANY
--
Parte de cuerpo definido externamente
ExternallyDefinedBodyPart ::= SEQUENCE^{ parameters [0] ExternallyDefinedParameters OPTIONAL, data ExternallyDefinedData^}
ExternallyDefinedParameters ::= EXTERNAL
ExternallyDefinedData ::= EXTERNAL
EXTENDED-BODY-PART-TYPE MACRO ::= BEGIN TYPE NOTATION ::= Parameters Data VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
Parameters ::=
"PARAMETERS"
type
"IDENTIFIED"
"BY"
value (OBJECT
IDENTIFIER)^|^empty
Data ::=
"DATA"
type
END
--
NIP
IPN ::= SET^{ -- common-fields -- COMPONENTS OF CommonFields, choice [0] CHOICE^{ non-receipt-fields [0] NonReceiptFields, receipt-fields [1] ReceiptFields^}^}
RN ::= IPN --
con campos de recepción elegidos
NRN ::= IPN --
con campos de no recepción elegidos
CommonFields ::= SET^{ subject-ipm SubjectIPMField, ipn-originator [1] IPNOriginatorField OPTIONAL, ipm-preferred-recipient [2] IPMPreferredRecipientField OPTIONAL, conversion-eits ConversionEITsField OPTIONAL^}
NonReceiptFields ::= SET^{ non-receipt-reason [0] NonReceiptReasonField, discard-reason [1] DiscardReasonField OPTIONAL, auto-forward-comment [2] AutoForwardCommentField OPTIONAL, returned-ipm [3] ReturnedIPMField OPTIONAL^}
ReceiptFields ::= SET^{
receipt-time [0] ReceiptTimeField,
acknowledgment-mode [1] AcknowledgmentModeField DEFAULT
manual,
suppl-receipt-info [2] SupplReceiptInfoField DEFAULT
"^"
^}
--
Campos comunes
SubjectIPMField ::= IPMIdentifier
IPNOriginatorField ::= ORDescriptor
IPMPreferredRecipientField ::= ORDescriptor
ConversionEITsField ::= EncodedInformationTypes
--
Campos de no recepción
NonReceiptReasonField ::= ENUMERATED^{ ipm-discarded (0), ipm-auto-forwarded (1)^}
DiscardReasonField ::= ENUMERATED^{ ipm-expired (0), ipm-obsoleted (1), user-subscription-terminated (2)^}
AutoForwardCommentField ::= AutoForwardComment
AutoForwardComment ::= PrintableString (SIZE (0.^.ub-auto-forward-comment))
ReturnedIPMField ::= IPM
--
Campos de recepción
ReceiptTimeField ::= Time
AcknowledgmentModeField ::= ENUMERATED^{ manual (0), automatic (1)^}
SupplReceiptInfoField ::= SupplementaryInformation
--
Realización de almacenamiento de mensajes
ForwardedInfo ::= SET { auto-forwarding-comment [0] AutoForwardComment OPTIONAL, cover-note [1] IA5TextBody Part OPTIONAL, this-ipm-prefix [2] PrintableString (SIZE (1.^.ub-ipm-identifier-suffix)) OPTIONAL^}
END --
de ObjetosdeInformación SMIP
ANEXO F (a la Recomendación X.420)
Definición de
referencia de objetos funcionales
Este anexo que es un suplemento a los 10, 11 y 16, define con fines de referencia los objetos funcionales de mensajería interpersonal. Utiliza las macros OBJECT y REFINE de la Recomendación X.407.
IPMSFunctionalObjects {^joint-iso-ccitt^ mhs-motis(6) ipms(1) modules(0) functional-objects(1)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Servicio abstracto SMIP
management, origination, reception
----
FROM IPMSAbstractService {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) abstract-service(3)^}
--
Identificadores de objeto SMIP
id-ot-ipme, id-ot-ipms, id-ot-ipms-ms, id-ot-ipms-ua,
id-ot-ipms-user, id-ot-pdau, id-ot-tlma, id-ot-tlxau,
id-ref-primary, id-ref-secondary
----
FROM IPMSObjectidentifiers {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) object-identifiers(0)^}
--
Servicio abstracto ATLM
miscellanea
----
FROM TLMAAbsService {^ccitt
recommendation(0) t(20) 330 tlmaabsservice(0)^}
--
Servicio abstracto AM
retrieval
----
FROM MSAbstractService {^joint-iso-ccitt
mhs-motis(6) ms(4) modules(0) abstract-service(1)^}
--
Servicio abstracto STRM
administration, delivery, mTs, submission
----
FROM MTSAbstractService {^joint-iso-ccitt
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)^}
--
Convenios de definición del servicio abstracto
OBJECT, REFINE
----
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
--
Tipo de objeto
`Raíz'
ipme OBJECT ::= id-ot-ipme
--
Perfeccionamiento primario
ipme-refinement REFINE ipme AS ipms origination [S] PAIRED WITH ipms-user reception [S] PAIRED WITH ipms-user management [S] PAIRED WITH ipms-user ipms-user RECURRING ::= id-ref-primary
--
Tipos de objeto primario
ipms-user OBJECT PORTS^{ origination [C], reception [C], management [C]^} ::= id-ot-ipms-user
ipms OBJECT PORTS^{ origination [S], reception [S], management [S]^} ::= id-ot-ipms
--
Perfeccionamiento secundario
ipms-refinement REFINE ipms AS mTs submission [S] PAIRED WITH ipms-ua, ipms-ms delivery [S] PAIRED WITH ipms-ua, ipms-ms administration [S] PAIRED WITH ipms-ua, ipms-ms ipms-ua RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE ipms-ms RECURRING submission [S] PAIRED WITH ipms-ua retrieval [S] PAIRED WITH ipms-ua administration [S] PAIRED WITH ipms-ua tlma RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE tlxau RECURRING origination [S] VISIBLE reception [S] VISIBLE management [S] VISIBLE pdau RECURRING reception [S] VISIBLE ::= id-ref-secondary
--
Objetos secundarios
ipms-ua OBJECT PORTS^{ origination [S], reception [S], management [S], submission [C], delivery [C], retrieval [C], administration [C]^} ::= id-ot-ipms-ua
ipms-ms OBJECT PORTS^{ submission [S], retrieval [S], administration [S], submission [C], delivery [C], administration [C]^} ::= id-ot-ipms-ms
tlma OBJECT PORTS^{ origination [S], reception [S], management [S], miscellanea [S]^} ::= id-ot-tlma
tlxau OBJECT PORTS^{ origination [S], reception [S], management [S]^} ::= id-ot-tlxau
pdau OBJECT PORTS^{ reception [S]^} ::= id-ot-pdau
END --
de ObjetosFuncionalesSMIP
ANEXO G (a la Recomendación X.420)
Definición de
referencia de servicio abstracto
Este anexo, que es un suplemento a los 12 y 13, define con fines de referencia el servicio abstracto SMIP. Utiliza las macros PORT, ABSTRACT-OPERATION y ABSTRACT-ERROR de la Recomendación X.407.
IPMSAbstractService {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) abstract-service(3)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Objetos de información SMTP
AutoForwardComment, Heading, IPM, NRN, RN
----
FROM IPMSInformationObjects {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) information-objects(2)^}
--
Identificadores de objeto SMIP
id-pt-management, id-pt-origination, id-pt-reception
----
FROM IPMSObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) object-identifiers(0)^}
--
Servicio abstracto STRM
MessageDeliveryEnvelope, MessageSubmissionEnvelope,
MessageSubmissionIdentifier, MessageSubmissionTime,
ProbeSubmissionEnvelope, ProbeSubmissionIdentifier,
ProbeSubmissionTime, RecipientImproperlySpecified,
ReportDeliveryEnvelope,
----
FROM MTSAbstractService {^joint-iso-ccitt
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)^}
--
Convenios de definición del servicio abstracto
ABSTRACT-ERROR, ABSTRACT-OPERATION, PORT
----
FROM AbstractServiceNotation {^joint-iso-ccitt
mhs-motis(6) asdc(2) modules(0) notation(1)^};
Time ::= UTCTime
--
Puertos
origination PORT CONSUMER INVOKES^{ OriginateProbe, OriginateIPM, OriginateRN^} ::= id-pt-origination
reception PORT SUPPLIER INVOKES^{ ReceiveReport, ReceiveIPM, ReceiveRN, ReceiveNRN^} ::= id-pt-reception
management PORT CONSUMER INVOKES^{ ChangeAutoDiscard, ChangeAutoAcknowledgment, ChangeAutoForwarding^} ::= id-pt-management
--
Operaciones abstractas de generación
OriginateProbe ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] ProbeSubmissionEnvelope, content [0] IPM^} RESULT SET^{ submission-identifier [0] ProbeSubmissionIdentifier, submission-time [1] ProbeSubmissionTime^} ERRORS^{ SubscriptionError, RecipientImproperlySpecified^}
OriginateIPM ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageSubmissionEnvelope, content [0] IPM^} RESULT SET^{ submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime^} ERRORS^{ SubscriptionError, RecipientImproperlySpecified^}
OriginateRN ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageSubmissionEnvelope, content [0] RN^} RESULT SET^{ submission-identifier [0] MessageSubmissionIdentifier, submission-time [1] MessageSubmissionTime^} ERRORS^{ SubscriptionError, RecipientImproperlySpecified^}
--
Operaciones abstractas de recepción
ReceiveReport ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] ReportDeliveryEnvelope, undelivered-object [1] InformationObject OPTIONAL^} RESULT ERRORS {^}
ReceiveIPM ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageDeliveryEnvelope, content [1] IPM^} RESULT ERRORS {^}
ReceiveRN ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageDeliveryEnvelope, content [1] RN^} RESULT ERRORS {^}
ReceiveNRN ::= ABSTRACT-OPERATION ARGUMENT SET^{ envelope [0] MessageDeliveryEnvelope, content [1] NRN^} RESULT ERRORS {^}
--
Operaciones abstractas de gestión
ChangeAutoDiscard ::= ABSTRACT-OPERATION ARGUMENT SET^{ auto-discard-expired-IPMs [0] BOOLEAN, auto-discard-obsolete-IPMs [1] BOOLEAN^} RESULT ERRORS {^}
ChangeAutoAcknowledgment ::= ABSTRACT-OPERATION ARGUMENT SET^{ auto-acknowledge-IPMs [0] BOOLEAN auto-acknowledge-suppl-receipt-info [1] SupplementaryInformation^} RESULT ERRORS^{ SubcriptionError^}
ChangeAutoForwarding ::= ABSTRACT-OPERATION ARGUMENT SET^{ auto-forward-IPMs [0] BOOLEAN, auto-forward-recipients [1] SEQUENCE OF ORName OPTIONAL, auto-forward-heading [2] Heading OPTIONAL, auto-forward-comment [3] AutoForwardComment OPTIONAL^} RESULT ERRORS^{ SubcriptionError, RecipientImproperlySpecified^}
--
Errores abstractos
SubscriptionError ::= ABSTRACT-ERROR PARAMETER SET^{ problem [0] SubscriptionProblem^}
SubscriptionProblem ::= ENUMERATED^{ ipms-eos-not-subscribed (0), mts-eos-not-subscribed (1)^}
END --
de ServicioAbstractoSMIP
ANEXO H (a la Recomendación X.420)
Definición de
referencia de ampliaciones de encabezamiento
Este anexo, que constituye un suplemento al anexo A, define con fines de referencia las ampliaciones de encabezamiento definidas para mensajería interpersonal. Utiliza la macro HEADING-EXTENSION del 12.2.17 .
IPMSHeadingExtensions {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) heading-extensions(6)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Objetos de información SMIP
HEADING-EXTENSION
----
FROM IPMSInformationObjects {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) information-objects(2)^};
--
Identificadores de objeto SMIP
id-hex-incomplete-copy, id-hex-languages
----
FROM IPMSObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) object-identifiers(0)^};
--
Copia incompleta
incomplete-copy HEADING-EXTENSION ::= id-hex-incomplete-copy
IncompleteCopy ::= NULL
--
Idiomas
languages HEADING-EXTENSION VALUE SET OF Language ::= id-hex-languages
Language ::= PrintableString (SIZE (2.^.2))
END --
de AmpliacionesdeEncabezamientoSMIP
Definición de
referencia de tipos de parte de cuerpo ampliado
Este anexo, que es un suplemento al anexo B, define con fines de referencia ciertos tipos de parte de cuerpo ampliado.
IPMSExtendedBodyPartTypes {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) extended-body-part-types(7)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
IMPORTS
--
Objetos de información SMIP
BilaterallyDefinedBodyPart, EncryptedData,
EncryptedParameters, EXTENDED-BODY-PART-TYPE, G3FacsimileData,
G3FacsimileParameters, G4Class1BodyPart, IA5TextData,
IA5TextParameters, MessageData, MessageParameters,
MixedModeBodyPart, NationallyDefinedBodyPart, TeletexData,
TeletexParameters, VideotexData, VideotexParameters,
VoiceData, VoiceParameters
----
FROM IPMSInformationObjects {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) information-objects(2)^}
--
Identificadores de objeto SMIP
id-ep-encrypted,
id-ep-g3-facsimile,
id-ep-ia5-text,
id-ep-message,
id-ep-teletex,
id-ep-videotex,
id-ep-voice,
id-et-bilaterally-defined, id-et-encrypted id-et-g3-facsimile,
id-et-g4-class1, id-et-ia5-text, id-et-message,
id-et-mixed-mode, id-et-nationally-defined, id-et-teletex,
id-et-videotex, id-et-voice
----
FROM IPMSObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) object-identifiers(0)^};
--
Parte de cuerpo ampliado texto AI5
ia5-text-body-part EXTENDED-BODY-PART-TYPE PARAMETERS IA5TextParameters IDENTIFIED BY id-ep-ia5-text DATA IA5TextData ::= id-et-ia5-text
--
Parte de cuerpo ampliado voz
voice-body-part EXTENDED-BODY-PART-TYPE PARAMETERS VoiceParameters IDENTIFIED BY id-ep-voice DATA VoiceData ::= id-et-voice
--
Parte de cuerpo ampliado facsímil G3
g3-facsimile-body-part EXTENDED-BODY-PART-TYPE PARAMETERS G3FacsimileParameters IDENTIFIED BY id-ep-g3-facsimile DATA G3FacsimileData ::= id-et-g3-facsimile
--
Parte de cuerpo ampliado G4 clase 1
g4-class1-body-part EXTENDED-BODY-PART-TYPE DATA G4Class1BodyPart ::= id-et-g4-class1
--
Parte de cuerpo ampliado teletex
teletex-body-part EXTENDED-BODY-PART-TYPE PARAMETERS TeletexParameters IDENTIFIED BY id-ep-teletex DATA TeletexData ::= id-et-teletex
--
Parte de cuerpo ampliado videotex
videotex-body-part EXTENDED-BODY-PART-TYPE PARAMETERS VideotexParameters IDENTIFIED BY id-ep-videotex DATA VideotexData ::= id-et-videotex
--
Parte de cuerpo ampliado cifrado
encrypted-body-part EXTENDED-BODY-PART-TYPE PARAMETERS EncryptedParameters IDENTIFIED BY id-ep-encrypted DATA EncryptedData ::= id-et-encrypted
--
Parte de cuerpo ampliado mensaje
message-body-part EXTENDED-BODY-PART-TYPE PARAMETERS MessageParameters IDENTIFIED BY id-ep-message DATA MessageData ::= id-et-message
--
Parte de cuerpo ampliado modo mixto
mixed-mode-body-part EXTENDED-BODY-PART-TYPE DATA MixedModeBodyPart ::= id-et-mixed-mode
--
Parte de cuerpo ampliado definido bilateralmente
bilaterally-defined-body-part EXTENDED-BODY-PART-TYPE DATA BilaterallyDefinedBodyPart ::= id-et-bilaterally-defined
--
Parte de cuerpo ampliado definido nacionalmente
nationally-defined-body-part EXTENDED-BODY-PART-TYPE DATA NationallyDefinedBodyPart ::= id-et-nationally-defined
END --
de TiposDeParteDeCuerpoAmpliadoSMIP
ANEXO J (a la Recomendación X.420)
Definición de
referencia de atributos de almacenamiento^ de mensajes
Este anexo, que es un suplemento al anexo C, define con fines de referencia los atributos de AM específicos a mensajería interpersonal. Utiliza la macro ATRIBUTE de la Recomendación X.500.
IPMSMessageStoreAttributes {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) message-store-attributes(8)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo
.
IMPORTS
--
Ampliaciones de encabezamiento SMIP
IncompleteCopy, Language
----
FROM IPMSHeadingExtensions {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) heading-extensions(6)^}
--
Objetos de información SMIP
AcknowledgmentModeField, AuthorizingUsersSubfield,
AutoForwardCommentField, AutoForwardedField,
BilaterallyDefinedBodyPart, BlindCopyRecipientsSubfield, Body,
ConversionEITsField, CopyRecipientsSubfield,
DiscardReasonField, EncryptedBodyPart, EncryptedData,
EncryptedParameters, ExpiryTimeField,
ExternallyDefinedParameters, G3FacsimileBodyPart,
G3FacsimileData, G3FacsimileParameters, G4Class1BodyPart,
Heading, IA5TextBodyPart, IA5TextData, IA5TextParameters,
ImportanceField, IPMPreferredRecipientField,
IPNOriginatorField, MessageBodyPart, MessageData,
MessageParameters, MixedModeBodyPart,
NationallyDefinedBodyPart, NonReceiptReasonField,
ObsoletedIPMsSubfield, ORDescriptor, OriginatorField,
PrimaryRecipientsSubfield, ReceiptTimeField,
RelatedIPMsSubfield, RepliedToIPMField,
ReplyRecipientsSubfield, ReplyTimeField, ReturnedIPMField,
SensitivityField, SubjectField, SubjectIPMField,
SupplReceiptInfoField, TeletexBodyPart, TeletexData,
TeletexParameters, ThisIPMField, VideotexBodyPart,
VideotexData, VideotexParameters, VoiceBodyPart, VoiceData,
VoiceParameters
----
FROM IPMSInformationObjects {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) information-objects(2)^}
--
Identificadores de objeto SMIP
id-bat-bilaterally-defined-body-parts, id-bat-body,
id-bat-encrypted-body-parts, id-bat-encrypted-data,
id-bat-encrypted-parameters, id-bat-extended-body-part-types
id-bat-g3-facsimile-body-parts, id-bat-g3-facsimile-data,
id-bat-g3-facsimile-parameters, id-bat-g4-class1-body-parts
id-bat-ia5-text-body-parts, id-bat-ia5-text-data,
id-bat-ia5-text-parameters, id-bat-message-body-parts,
id-bat-message-data, id-bat-message-parameters,
id-bat-mixed-mode-body-parts,
id-bat-nationally-defined-body-parts,
id-bat-teletex-body-parts, id-bat-teletex-data,
id-bat-teletex-parameters, id-bat-videotex-body-parts,
id-bat-videotex-data, id-bat-videotex-parameters,
id-bat-voice-body-parts, id-bat-voice-data,
id-bat-voice-parameters, id-hat-authorizing-users,
id-hat-auto-forwarded, id-hat-blind-copy-recipients,
id-hat-copy-recipients, id-hat-expiry-time, id-hat-heading,
id-hat-importance, id-hat-incomplete-copy, id-hat-languages,
id-hat-nrn-requestors, id-hat-obsoleted-IPMs,
id-hat-originator, id-hat-primary-recipients
id-hat-related-IPMs, id-hat-replied-to-IPM,
id-hat-reply-recipients, id-hat-reply-requestors,
id-hat-reply-time, id-hat-rn-requestors, id-hat-sensitivity,
id-hat-subject, id-hat-this-ipm, id-nat-acknowledgment-mode,
id-nat-auto-forward-comment, id-nat-conversion-eits,
id-nat-discard-reason, id-nat-ipm-preferred-recipient,
id-nat-ipn-originator, id-nat-non-receipt-reason,
id-nat-receipt-time, id-nat-returned-ipm, id-nat-subject-ipm,
id-nat-suppl-receipt-info, id-sat-ipm-entry-type,
id-sat-ipm-synopsis
----
FROM IPMSObjectIdentifiers {^joint-iso-ccitt
mhs-motis(6) ipms(1) modules(0) object-identifiers(0)^}
--
Servicio abstracto AM
MS-EITs, SequenceNumber
----
FROM MSAbstractService {^joint-iso-ccitt
mhs-motis(6) ms(4) modules(0) abstract-service(1)^}
--
Servicio abstracto STRM
EncodedInformationTypes
----
FROM MTSAbstractService {^joint-iso-ccitt
mhs-motis(6) mts(3) modules(0) mts-abstract-service(1)^};
--
Marco de información de guía
ATTRIBUTE
----
FROM InformationFramework {^joint-iso-ccitt
ds(5) modules(1) informationFramework(1)^};
Time ::= UTCTime
--
ATRIBUTOS RESUMEN
--
Tipo de inscripción MIP
ipm-entry-type ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPMEntryType MATCHES FOR EQUALITY SINGLE VALUE ::= id-sat-ipm-entry-type
IPMEntryType ::= ENUMERATED^{ ipm (0), rn (1), nrn (2)^}
--
Sinopsis MIP
ipm-synopsis ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPMSynopsis SINGLE VALUE ::= id-sat-ipm-synopsis
IPMSynopsis ::= SEQUENCE OF BodyPartSynopsis
BodyPartSynopsis ::= CHOICE^{ messsage [0] MessageBodyPartSynopsis, non-messsage [1] NonMessageBodyPartSynopsis^}
MessageBodyPartSynopsis ::= SEQUENCE^{ number [0] SequenceNumber, synopsis [1] IPMSynopsis^}
NonMessageBodyPartSynopsis ::= SEQUENCE^{ type [0] OBJECT IDENTIFIER, parameters [1] ExternallyDefinedParameters, size [2] INTEGER, processed [3] BOOLEAN DEFAULT FALSE^}
--
ATRIBUTOS DE ENCABEZAMIENTO
--
Encabezamiento
heading ATTRIBUTE WITH ATTRIBUTE-SYNTAX Heading SINGLE VALUE ::= id-hat-heading
--
Análisis de encabezamiento
rn-requestors ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-rn-requestors
nrn-requestors ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-nrn-requestors
reply-requestors ATTRIBUTE WITH ATTRIBUTE-SYNTAX ORDescriptor MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-reply-requestors
--
Campos de encabezamiento
this-ipm ATTRIBUTE WITH ATTRIBUTE-SYNTAX ThisIPMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-this-ipm
originator ATTRIBUTE WITH ATTRIBUTE-SYNTAX OriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-originator
replied-to-IPM ATTRIBUTE WITH ATTRIBUTE-SYNTAX RepliedToIPMField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-replied-to-IPM
subject ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-hat-subject
expiry-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX ExpiryTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-expiry-time
reply-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReplyTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-hat-reply-time
importance ATTRIBUTE WITH ATTRIBUTE-SYNTAX ImportanceField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-importance
sensitivity ATTRIBUTE WITH ATTRIBUTE-SYNTAX SensitivityField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-sensitivity
auto-forwarded ATTRIBUTE WITH ATTRIBUTE-SYNTAX AutoForwardedField MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-auto-forward
--
Subcampos de encabezamiento
authorizing-users ATTRIBUTE WITH ATTRIBUTE-SYNTAX Authorizing-UsersSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-authorizing-users
primary-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX PrimaryRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-primary-recipients
copy-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX CopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-copy-recipients
blind-copy-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX BlindCopyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-blind-copy-recipients
obsoleted-IPMs ATTRIBUTE WITH ATTRIBUTE-SYNTAX ObsoletedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-obsoleted-IPMs
related-IPMs ATTRIBUTE WITH ATTRIBUTE-SYNTAX RelatedIPMsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-related-IPMs
reply-recipients ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReplyRecipientsSubfield MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-reply-recipients
--
Ampliaciones de encabezamiento
incomplete-copy ATTRIBUTE WITH ATTRIBUTE-SYNTAX IncompleteCopy MATCHES FOR EQUALITY SINGLE VALUE ::= id-hat-incomplete-copy
languages ATTRIBUTE WITH ATTRIBUTE-SYNTAX Language MATCHES FOR EQUALITY MULTI VALUE ::= id-hat-languages
--
ATRIBUTOS DE CUERPO
--
Cuerpo
body ATTRIBUTE WITH ATTRIBUTE-SYNTAX Body SINGLE VALUE ::= id-bat-body
--
Partes de cuerpo básico
ia5-text-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX IA5TextBodyPart MULTI VALUE ::= id-bat-ia5-text-body-parts
voice-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX VoiceBodyPart MULTI VALUE ::= id-bat-voice-body-parts
g3-facsimile-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX G3FacsimileBodyPart MULTI VALUE ::= id-bat-g3-facsimile-body-parts
g4-class1-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX G4Class1BodyPart MULTI VALUE ::= id-bat-g4-class1-body-parts
teletex-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexBodyPart MULTI VALUE ::= id-bat-teletex-body-parts
videotex-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX VideotexBodyPart MULTI VALUE ::= id-bat-videotex-body-parts
encrypted-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX EncryptedBodyPart MULTI VALUE ::= id-bat-encrypted-body-parts
message-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX SequenceNumber MULTI VALUE ::= id-bat-message-body-parts
mixed-mode-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX MixedModeBodyPart MULTI VALUE ::= id-bat-mixed-mode-body-parts
bilaterally-defined-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX BilaterallyDefinedBodyPart MULTI VALUE ::= id-bat-bilaterally-defined-body-parts
nationally-defined-body-parts ATTRIBUTE WITH ATTRIBUTE-SYNTAX NationallyDefinedBodyPart MULTI VALUE ::= id-bat-nationally-defined-body-parts
--
Componentes parámetros de parte de cuerpo básico
ia5-text-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX IA5TextParameters MULTI VALUE ::= id-bat-ia5-text-parameters
voice-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX VoiceParameters MULTI VALUE ::= id-bat-voice-parameters
g3-facsimile-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX G3FacsimileParameters MULTI VALUE ::= id-bat-g3-facsimile-parameters
teletex-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexParameters MULTI VALUE ::= id-bat-teletex-parameters
videotex-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX VideotexParameters MULTI VALUE ::= id-bat-videotex-parameters
encrypted-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX EncryptedParameters MULTI VALUE ::= id-bat-encrypted-parameters
message-parameters ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageParameters MULTI VALUE ::= id-bat-message-parameters
--
Componentes datos de parte de cuerpo básico
ia5-text-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX IA5TextData MULTI VALUE ::= id-bat-ia5-text-data
voice-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX Voice-Data MULTI VALUE ::= id-bat-voice-data
g3-facsimile-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX G3FacsimileData MULTI VALUE ::= id-bat-g3-facsimile-data
teletex-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX TeletexData MULTI VALUE ::= id-bat-teletex-data
videotex-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX VideotexData MULTI VALUE ::= id-bat-videotex-data
encrypted-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX EncryptedData MULTI VALUE ::= id-bat-encrypted-data
message-data ATTRIBUTE WITH ATTRIBUTE-SYNTAX MessageData MULTI VALUE ::= id-bat-message-data
--
Tipos de parte de cuerpo ampliado
extended-body-part-types ATTRIBUTE WITH ATTRIBUTE-SYNTAX OBJECT IDENTIFIER MATCHES FOR EQUALITY MULTI VALUE ::= id-bat-extended-body-part-types
--
Partes de cuerpo ampliado
-- (
Estos atributos no pueden enumerarse. Véase el Î
C.3.6
)
--
ATRIBUTOS DE NOTIFICACIóN
--
Campos comunes
subject-ipm ATTRIBUTE WITH ATTRIBUTE-SYNTAX SubjectIPMField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-subject-ipm
ipn-originator ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPNOriginatorField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-ipn-originator
ipm-preferred-recipient ATTRIBUTE WITH ATTRIBUTE-SYNTAX IPMPreferredRecipientField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-ipm-preferred-recipient
conversion-eits ATTRIBUTE WITH ATTRIBUTE-SYNTAX MS-EITs MATCHES FOR EQUALITY MULTI VALUE ::= id-nat-conversion-eits
--
Campos de no recepción
non-receipt-reason ATTRIBUTE WITH ATTRIBUTE-SYNTAX NonReceiptReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-non-receipt-reason
discard-reason ATTRIBUTE WITH ATTRIBUTE-SYNTAX DiscardReasonField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-discard-reason
auto-forward-comment ATTRIBUTE WITH ATTRIBUTE-SYNTAX AutoForwardCommentField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-auto-forward-comment
returned-ipm ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReturnedIPMField SINGLE VALUE ::= id-nat-returned-IPM
--
Receipt fields
receipt-time ATTRIBUTE WITH ATTRIBUTE-SYNTAX ReceiptTimeField MATCHES FOR EQUALITY ORDERING SINGLE VALUE ::= id-nat-receipt-time
acknowledgment-mode ATTRIBUTE WITH ATTRIBUTE-SYNTAX AcknowledgmentModeField MATCHES FOR EQUALITY SINGLE VALUE ::= id-nat-acknowledgment-mode
suppl-receipt-info ATTRIBUTE WITH ATTRIBUTE-SYNTAX SupplReceiptInfoField MATCHES FOR EQUALITY SUBSTRINGS SINGLE VALUE ::= id-nat-suppl-receipt-info
END --
of IPMSMessageStoreAttributes
Definición de
referencia de límites superiores
Este anexo define, con fines de referencia, los límites superiores de diversos ítems de información de longitud variable cuyas sintaxis están definidas en los módulos NSA.1 de anexos anteriores.
IPMSUpperBounds {^joint-iso-ccitt mhs-motis(6) ipms(1) modules(0) upper-bounds(10)^} DEFINITIONS IMPLICIT TAGS ::= BEGIN
--
Prólogo
--
Exporta todo.
IMPORTS --
nada
--;
--
Límites superiores
ub-auto-forward-comment INTEGER ::= 256
ub-free-form-name INTEGER ::= 64
ub-ipm-identifier-suffix INTEGER ::= 2
ub-local-ipm-identifier INTEGER ::= 64
ub-subject-field INTEGER ::= 128
ub-telephone-number INTEGER ::= 32
END --
of IPMSUpperBounds
ANEXO L (a la Recomendación X.420)
Sustentación del
servicio de mensajería interpersonal
El servicio de mensajería interpersonal proporcionado por el SMIP a los
usuarios se define en términos no técnicos en la Recomendación X.400. El
servicio comprende cierto número de elementos de servicio (
EDS
MIP
), cada uno de los cuales representa un aspecto del servicio, y está
definido en uno o dos párrafos de texto ordinario. El presente anexo indica con
detalle cómo la presente especificación, más técnica, realiza cada EDS MIP. De
manera equivalente, el anexo identifica los aspectos de la especificación que
un AU, por ejemplo, tiene que establecer para que pueda decirse del mismo que
admite un EDS MIP determinado.
Asociados con cada EDS MIP hay uno o más elementos de información que pueden aparecer como componentes de MIP. El elemento de información asociado con el EDS MIP indicación de sensibilidad, por ejemplo, es el campo de encabezamiento sensibilidad. Se dice que un AU, ATLM, o UA admite un determinado EDS MIP en la generación o recepción si y solo si admite en la generación o recepción (véase el 22.1 ) los elementos de información asociados con ese EDS MIP.
Nota 1
- La tarea de realizar un EDS MIP puede
incumbir, en principio a cualquiera de los objetos secundarios obtenidos
mediante el perfeccionamiento del SMIP. En el presente contexto, sin embargo,
se supone que el STRM y cada AM, por el hecho de ser independientes de la
aplicación, admiten todo EDS MIP, y que proceden de esta manera sin haber
tomado disposiciones especiales acerca de los mismos.
Nota 2
- Como se describe en el
14
, un AU
pone a disposición de su usuario muchas de las capacidades que ofrece su AM.
Estas capacidades realizan los elementos del servicio de extracción de mensajes
que se define en la Recomendación X.400. La correspondencia entre los elementos
de ese servicio y las capacidades técnicas asociadas se especifica en la
Recomendación X.413.
Nota 3
- Como se describe en el
14
, un AU
pone a disposición de su usuario muchas de las capacidades que ofrece el STRM.
Estas capacidades realizan los elementos del servicio de transferencia de
mensajes que se define en la Recomendación X.400. La correspondencia entre los
elementos de ese servicio y las capacidades técnicas asociadas se especifican
en la Recomendación X.411.
L.1
Sustentación de componentes de especificador de
destinatario
Algunos EDS MIP se realizan por medio de componentes especificador de destinatario. Los EDS MIP de esta categoría se indican en la primera columna del cuadro L-1/X.420. La segunda y tercera columnas identifican el componente especificador de destinatario, y el valor de ese componente, que son los elementos de información asociados con cada EDS MIP que figura en la lista.
Cuadro L-1/X.420 [T4.420], p.
L.2
Sustentación de campos de encabezamiento
Algunos EDS MIP se realizan por medio de campos de encabezamiento. Los EDS MIP de esta categoría se indican en la primera columna del cuadro L-2/X.420. La segunda columna indica los campos de encabezamiento que son los elementos de información asociados con cada EDS MIP que figura en la lista. En el caso del campo ampliaciones, la segunda columna indica también, entre paréntesis, la ampliación de encabezamiento correspondiente.
L.3
Sustentación de aspectos de cuerpo
Algunos EDS MIP se realizan por medio de aspectos del cuerpo. Los EDS MIP de esta categoría se indican en la primera columna del cuadro L-3/X.420. La segunda columna indica el aspecto del cuerpo que es el elemento de información asociado con cada EDS MIP que figura en la lista.
Tableau L-2/X.420 [T5.420], p. 5
Tableau L-3/X.420 [T6.420], p.
ANEXO M
Diferencias entre la Recomendación del CCITT y Norma
de la ISO
Este anexo no forma parte de esta Recomendación.
Este anexo enumera todas las diferencias que existen entre esta Recomendación y la correspondiente Norma Internacional de la ISO, salvo las que son puramente redaccionales.
Las diferencias que existen son las siguientes:
a) La Norma Internacional de la ISO correspondiente a la presente Recomendación define una parte de cuerpo texto general, definición que no figura en esta Recomendación.
b) Los límites superiores del anexo K forman parte integrante de esta Recomendación, pero no forman parte integrante de la correspondiente Norma Internacional de la ISO.
c) El texto del CCITT sobre el especificador de destinatario
asunto del
8
, establece que puede contener
`un
nombre O/D del destinatario preferido'
o
`un nombre O/D
que aparece en la historia de ampliación de la LD'
. La
Norma ISO ha excluido esta segunda posibilidad.
ANEXO N
Resumen de las modificaciones de la Recomendación del
CCITT^ de 1984
Este anexo no forma parte integrante de esta
Recomendación.
Desde el punto de vista de la redacción, esta Recomendación difiere sustancialmente de la Recomendación X.420 (versión de 1984). Desde el punto de vista técnico, sin embargo, las diferencias son pequeñas. El presente anexo enumera las modificaciones técnicas. Tiene por finalidad ayudar al realizador de la Recomendación X.420 (1984), permitiéndole saber, mediante una rápida ojeada, cómo su realización podría resultar afectada por la especificación de 1988.
La presente especificación recoge únicamente las siguientes modificaciones sustanciales relativas al interfuncionamiento entre los AU, AM, ATLM y UA según las versiones de 1984 y 1988. Todas, salvo la primera, son modificaciones del formato de los objetos de información ahora definidos en el módulo NSA.1, IPMSInformationObjects:
a) El tipo de contenido asignado a P2 ha cambiado. P2, que antes se identificaba por el entero 2, se identifica ahora por el entero 2 ó 22, según la funcionabilidad empleada en un caso particular de comunicación por medio del STRM (véase el 20.2 ).
b) Se desaconseja ahora la omisión del miembro usuario de IPMIdentifier.
c) Se ha añadido a encabezamiento el miembro ampliaciones. Su grado es facultativo.
d) Se han abandonado los tipos de parte de cuerpo télex y documento formatizable simple. (La primera había sido identificada pero no definida.)
e) Se ha añadido el miembro sintaxis a VideotexParameters. Su grado es facultativo.
f) Se desaconseja ahora la presencia del miembro hora de entrega de MessageParameters en ausencia de su miembro sobre de entrega, o viceversa.
g) Se han añadido a BodyPart las alternativas definido-bilateralmente y definido-externamente.
h) Han variado los siguientes elementos de protocolo, definidos en la Recomendación X.411 e incorporados en elementos de protocolo de esta Recomendación, mediante referencia:
i) ORName
ii) ORAddress
iii) MessageDeliveryEnvelope
iv) EncodedInformationTypes
v) SupplementaryInformation
i) Actualmente se desaconseja especificar un valor de longitud cero a cualquiera de los siguientes tipos de datos:
i) LocalIPMIdentifier
ii) FreeFormName
iii) TelephoneNumber
iv) SubjectField
v) AutoForwardComment
j)Se han impuesto límites superiores a ciertos elementos de protocolo de longitud variable.
Nota
- Los límites superiores impuestos son los
indicados en el
4.3
de la versión 6 de la
Guía del
realizador de las Recomendaciones de la serie X.400
.