This article's use of external links may not follow Wikipedia's policies or guidelines. (July 2024) |
Notación de sintaxis abstracta uno | |
Estado | En vigor; reemplaza a X.208 y X.209 (1988) |
---|---|
Año iniciado | 1984 |
Última versión | (21/02) Febrero 2021 |
Organización | UIT-T |
Comité | Grupo de estudio 17 |
Normas básicas | ASN.1 |
Normas relacionadas | X.208 , X.209 , X.409, X.509 , X.680 , X.681, X.682, X.683 |
Dominio | criptografía , telecomunicaciones |
Sitio web | https://www.itu.int/rec/T-REC-X.680/ |
La notación de sintaxis abstracta uno ( ASN.1 ) es un lenguaje de descripción de interfaz (IDL) estándar para definir estructuras de datos que se pueden serializar y deserializar de forma multiplataforma. Se utiliza ampliamente en telecomunicaciones y redes informáticas , y especialmente en criptografía . [1]
Los desarrolladores de protocolos definen estructuras de datos en módulos ASN.1, que generalmente son una sección de un documento de estándares más amplio escrito en el lenguaje ASN.1. La ventaja es que la descripción ASN.1 de la codificación de datos es independiente de un lenguaje de programación o de computadora en particular. Debido a que ASN.1 es legible tanto para humanos como para máquinas , un compilador ASN.1 puede compilar módulos en bibliotecas de código, codecs , que decodifican o codifican las estructuras de datos. Algunos compiladores ASN.1 pueden producir código para codificar o decodificar varias codificaciones, por ejemplo, empaquetadas, BER o XML .
ASN.1 es una norma conjunta del Sector de Normalización de las Telecomunicaciones de la Unión Internacional de Telecomunicaciones (UIT-T) en el Grupo de Estudio 17 de la UIT-T y la Organización Internacional de Normalización / Comisión Electrotécnica Internacional (ISO/IEC), definida originalmente en 1984 como parte de CCITT X.409:1984. [2] En 1988, ASN.1 pasó a tener su propia norma, X.208 , debido a su amplia aplicabilidad. La versión de 1995, sustancialmente revisada, está cubierta por la serie X.680 . [3] La última revisión de la serie de recomendaciones X.680 es la Edición 6.0, publicada en 2021. [4]
ASN.1 es una notación de declaración de tipo de datos. No define cómo manipular una variable de ese tipo. La manipulación de variables se define en otros lenguajes, como SDL (lenguaje de especificación y descripción) para el modelado ejecutable o TTCN-3 (notación de prueba y control de prueba) para pruebas de conformidad. Ambos lenguajes admiten de forma nativa las declaraciones ASN.1. Es posible importar un módulo ASN.1 y declarar una variable de cualquiera de los tipos ASN.1 declarados en el módulo.
ASN.1 se utiliza para definir una gran cantidad de protocolos. Sus usos más extendidos siguen siendo las telecomunicaciones, la criptografía y la biometría.
Protocolo | Especificación | Reglas de codificación especificadas o habituales | Usos |
---|---|---|---|
Protocolo Interledger | Especificación ILPV4 | Reglas de codificación de octetos | |
NTCIP 1103 - Protocolos de gestión del transporte | Norma técnica nacional de protección de datos 1103 | Reglas de codificación de octetos | Gestión del tráfico, el transporte y la infraestructura |
Servicios de directorio X.500 | La serie de recomendaciones UIT X.500 | Reglas de codificación básicas, reglas de codificación diferenciadas | Certificados LDAP, TLS ( X.509 ), autenticación |
Protocolo ligero de acceso a directorios (LDAP) | RFC 4511 | Reglas básicas de codificación | |
Estándares de criptografía PKCS | Estándares de criptografía PKCS | Reglas de codificación básicas y reglas de codificación diferenciadas | Claves asimétricas, paquetes de certificados |
Manejo de mensajes X.400 | La serie de recomendaciones UIT X.400 | Un competidor temprano del correo electrónico | |
EMV | Publicaciones de EMVCo | Tarjetas de pago | |
T.120 Conferencias multimedia | Serie de recomendaciones UIT T.120 | Reglas de codificación básicas, reglas de codificación empaquetadas | Protocolo de escritorio remoto (RDP) de Microsoft |
Protocolo simple de administración de red (SNMP) | RFC 1157 | Reglas básicas de codificación | Gestión y monitorización de redes y ordenadores, en particular características relacionadas con el rendimiento y la fiabilidad. |
Protocolo común de información de gestión (CMIP) | Recomendación UIT X.711 | Un competidor de SNMP pero más capaz y no tan popular | |
Sistema de señalización nº 7 (SS7) | Serie de recomendaciones Q.700 de la UIT | Gestión de conexiones telefónicas a través de la Red Telefónica Pública Conmutada (RTPC) | |
Protocolos multimedia de la serie H de la UIT | Las series de recomendaciones H.200, H.300 y H.400 de la UIT | Voz sobre Protocolo de Internet (VOIP) | |
Protocolo de interfuncionamiento BioAPI (BIP) | ISO/IEC 24708:2008 | ||
Marco común de formatos de intercambio biométrico (CBEFF) | Norma NIST IR 6529-A | Reglas básicas de codificación | |
Contextos de autenticación para biometría (ACBio) | ISO/IEC 24761:2019 | ||
Aplicaciones de telecomunicaciones asistidas por computadora (CSTA) | [1] | Reglas básicas de codificación | |
Comunicaciones dedicadas de corto alcance (DSRC) | SAE J2735 | Reglas de codificación empaquetadas | Comunicación del vehículo |
IEEE 802.11p (onda IEEE) | IEEE 1609.2 | Comunicación del vehículo | |
Sistemas de Transporte Inteligente (ETSI ITS) | ETSI EN 302 637 2 (CAM) ETSI EN 302 637 3 (DENM) | Reglas de codificación empaquetadas no alineadas | Comunicación del vehículo |
Sistema global de comunicaciones móviles (GSM) | [2] | Comunicaciones de telefonía móvil 2G | |
Servicio general de radio por paquetes (GPRS) / Velocidades de datos mejoradas para la evolución de GSM (EDGE) | [3] | Comunicaciones de telefonía móvil 2.5G | |
Sistema universal de telecomunicaciones móviles (UMTS) | [4] | Comunicaciones de telefonía móvil 3G | |
Evolución a largo plazo (LTE) | [5] | Comunicaciones de telefonía móvil 4G | |
5G | [6] | Comunicaciones de telefonía móvil 5G | |
Protocolo de alerta común (CAP) | [7] | Reglas de codificación XML | Intercambio de información de alerta, como las alertas Amber |
Comunicaciones de enlace de datos entre el controlador y el piloto (CPDLC) | Comunicaciones aeronáuticas | ||
Servicios de extensión de enlaces espaciales (SLE) | Comunicaciones de sistemas espaciales | ||
Especificación de mensajes de fabricación (MMS) | ISO 9506-1:2003 | Fabricación | |
Transferencia, acceso y gestión de archivos (FTAM) | Un competidor temprano y más capaz del Protocolo de Transferencia de Archivos, pero que rara vez se utiliza hoy en día. | ||
Protocolo de elementos de servicio de operaciones remotas (ROSE) | Recomendaciones UIT X.880, X.881 y X.882 | Una forma temprana de llamada a procedimiento remoto | |
Elemento de servicio de control de asociación (ACSE) | Recomendación UIT X.227 | ||
Protocolo de redes de control y automatización de edificios (BACnet) | ASHRAE 135-2020 | Reglas de codificación BACnet | Automatización y control de edificios, como alarmas contra incendios, ascensores, sistemas HVAC, etc. |
Kerberos | RFC 4120 | Reglas básicas de codificación | Autenticación segura |
WiMAX 2 | Redes de área amplia | ||
Red inteligente | Serie de recomendaciones Q.1200 de la UIT | Telecomunicaciones y redes informáticas | |
X2AP | Reglas básicas de codificación alineada y empaquetada | ||
Interfaz de transferencia de interceptación legal (LI) | ETSI TS 102 232-1 | Interceptación legal |
ASN.1 está estrechamente asociado con un conjunto de reglas de codificación que especifican cómo representar una estructura de datos como una serie de bytes. Las reglas de codificación estándar de ASN.1 incluyen:
Reglas de codificación | Identificador de objeto | Valor del descriptor de objeto | Especificación | Unidad de serialización | Elementos codificados discernibles sin conocimiento previo de la especificación | Octeto alineado | Reglas de notación de control de codificación definidas | Descripción | |
---|---|---|---|---|---|---|---|---|---|
Punteado | IRI | ||||||||
Reglas básicas de codificación (BER) [5] | 2.1.1 | /ASN.1/Codificación básica | Codificación básica de un único tipo ASN.1 | UIT X.690 | Octeto | Sí | Sí | No | La primera regla de codificación especificada. Codifica los elementos como secuencias de longitud de etiqueta y valor (TLV). Normalmente, proporciona varias opciones sobre cómo se deben codificar los valores de los datos. Esta es una de las reglas de codificación más flexibles. |
Reglas de codificación distinguidas (DER) [6] | 2.1.2.1 | /ASN.1/BER‑Derivado/ | Codificación diferenciada de un único tipo ASN.1 | UIT X.690 | Octeto | Sí | Sí | No | Un subconjunto restringido de las reglas de codificación básica (BER). Se utiliza normalmente para elementos firmados digitalmente porque, dado que las DER permiten menos opciones de codificación y debido a que los valores codificados con DER tienen más probabilidades de volver a codificarse en los mismos bytes exactos, las firmas digitales producidas por un valor abstracto determinado serán las mismas en todas las implementaciones y las firmas digitales producidas sobre datos codificados con DER serán menos susceptibles a ataques basados en colisiones. |
Reglas de codificación canónica (CER) [7] | 2.1.2.0 | /ASN.1/ | Codificación canónica de un único tipo ASN.1 | UIT X.690 | Octeto | Sí | Sí | No | Un subconjunto restringido de las Reglas de codificación básica (BER). Emplea casi todas las mismas restricciones que las Reglas de codificación distinguida (DER), pero la diferencia notable es que las CER especifican que muchos valores grandes (especialmente cadenas) deben "dividirse" en elementos de subcadena individuales en la marca de 1000 bytes o 1000 caracteres (según el tipo de datos). |
Reglas básicas de codificación empaquetada (PER) alineadas [8] | 2.1.3.0.0 | /ASN.1/ | Codificación empaquetada de un solo tipo ASN.1 (alineación básica) | UIT X.691 | Poco | No | Sí | No | Codifica valores en bits, pero si los bits codificados no son divisibles por ocho, se añaden bits de relleno hasta que un número entero de octetos codifique el valor. Es capaz de producir codificaciones muy compactas, pero a expensas de la complejidad, y los PER dependen en gran medida de las restricciones impuestas a los tipos de datos. |
Reglas básicas de codificación empaquetada (PER) no alineadas [8] | 2.1.3.0.1 | /ASN.1/ | Codificación empaquetada de un solo tipo ASN.1 (básico no alineado) | UIT X.691 | Poco | No | No | No | Una variante de las reglas de codificación básica alineada (PER), pero no rellena los valores de datos con bits para producir un número entero de octetos. |
Reglas de codificación empaquetada canónica (CPER) alineadas [8] | 2.1.3.1.0 | /ASN.1/ | Codificación empaquetada de un único tipo ASN.1 (alineado canónicamente) | UIT X.691 | Poco | No | Sí | No | Una variante de las reglas de codificación empaquetada (PER) que especifica una única forma de codificar valores. Las reglas de codificación empaquetada canónica tienen una relación similar con las reglas de codificación empaquetada que la que tienen las reglas de codificación distinguida (DER) y las reglas de codificación canónica (CER) con las reglas de codificación básica (BER). |
Reglas de codificación empaquetada canónica (CPER) no alineadas [8] | 2.1.3.1.1 | /ASN.1/ | Codificación empaquetada de un único tipo ASN.1 (canónico no alineado) | UIT X.691 | Poco | No | No | No | Una variante de las reglas de codificación canónica alineada (CPER), pero no rellena los valores de datos con bits para producir un número entero de octetos. |
Reglas básicas de codificación XML (XER) [9] | 2.1.5.0 | /ASN.1/Codificación XML/ | Codificación XML básica de un único tipo ASN.1 | UIT X.693 | Personaje | Sí | Sí | Sí | Codifica datos ASN.1 como XML. |
Reglas de codificación XML canónicas (CXER) [9] | 2.1.5.1 | /ASN.1/Codificación XML/ | Codificación XML canónica de un único tipo ASN.1 | UIT X.693 | Personaje | Sí | Sí | Sí | |
Reglas de codificación XML extendidas (EXER) [9] | 2.1.5.2 | /ASN.1/Codificación XML/ | Codificación XML extendida de un único tipo ASN.1 | UIT X.693 | Personaje | Sí | Sí | Sí | |
Reglas de codificación de octetos (REA) [10] | 2.1.6.0 | Codificación OER básica de un único tipo ASN.1 | UIT X.696 | Octeto | No | Sí | Un conjunto de reglas de codificación que codifica valores en octetos, pero no codifica etiquetas ni determinantes de longitud como las Reglas de codificación básica (BER). Los valores de datos codificados mediante las Reglas de codificación de octetos suelen parecerse a los que se encuentran en los protocolos "basados en registros". Las Reglas de codificación de octetos (OER) se diseñaron para que fueran fáciles de implementar y para producir codificaciones más compactas que las producidas por las Reglas de codificación básica (BER). Además de reducir el esfuerzo de desarrollo de codificadores/descodificadores, el uso de OER puede reducir la utilización del ancho de banda (aunque no tanto como las Reglas de codificación empaquetadas), ahorrar ciclos de CPU y reducir la latencia de codificación/descodificación. | ||
Reglas de codificación canónica (REA) [10] | 2.1.6.1 | Codificación OER canónica de un único tipo ASN.1 | UIT X.696 | Octeto | No | Sí | |||
Reglas de codificación JSON (JER) [11] | UIT X.697 | Personaje | Sí | Sí | Sí | Codifica datos ASN.1 como JSON. | |||
Reglas de codificación de cadenas genéricas (GSER) [12] | 1.2.36.79672281.0.0 | Reglas de codificación de cadenas genéricas (GSER) | RFC 3641 | Personaje | Sí | No | Una especificación incompleta para codificar reglas que produzcan valores legibles para humanos. El propósito de GSER es representar datos codificados al usuario o datos de entrada del usuario, en un formato muy sencillo. GSER fue diseñado originalmente para el Protocolo ligero de acceso a directorios (LDAP) y rara vez se utiliza fuera de él. Se desaconseja el uso de GSER en protocolos reales, ya que no todas las codificaciones de cadenas de caracteres admitidas por ASN.1 se pueden reproducir en él. | ||
Reglas de codificación BACnet | ASHRAE135 | Octeto | Sí | Sí | Sí | Codifica elementos como secuencias de valor de longitud de etiqueta (TLV) como las Reglas de codificación básicas (BER). | |||
Reglas de codificación específicas de señalización (SER) | Documento interno de I+D de France Telecom | Octeto | Sí | Sí | Se utiliza principalmente en protocolos relacionados con las telecomunicaciones, como GSM y SS7. Está diseñado para producir una codificación idéntica a la de ASN.1 que producirían los protocolos existentes anteriormente no especificados en ASN.1. | ||||
Reglas de codificación ligera (LWER) | Documento interno del INRIA. | Palabra de memoria | Sí | Se origina a partir de un documento interno producido por INRIA que detalla la "Sintaxis ligera de árbol plano" (FTLWS). Abandonada en 1997 debido al rendimiento superior de las reglas de codificación empaquetadas (PER). Opcionalmente, transmisión Big-Endian o Little-Endian, así como palabras de memoria de 8 bits, 16 bits y 32 bits. (Por lo tanto, hay seis variantes, ya que hay seis combinaciones de esas opciones). | |||||
Reglas de codificación de bits mínimos (MBER) | Poco | Propuesto en la década de 1980. Concebido para ser lo más compacto posible, como las Reglas de codificación empaquetadas (PER). | |||||||
Reglas de codificación empaquetadas NEMA | Poco | Una especificación de reglas de codificación incompleta producida por NEMA. Es incompleta porque no puede codificar ni decodificar todos los tipos de datos ASN.1. Compacta como las reglas de codificación empaquetadas (PER). | |||||||
Reglas de codificación de alta velocidad | "Reglas de codificación para redes de alta velocidad" | La definición de estas reglas de codificación fue un subproducto del trabajo de INRIA sobre la sintaxis ligera de árbol plano (FTLWS). |
Las recomendaciones de ASN.1 proporcionan una serie de reglas de codificación predefinidas. Si ninguna de las reglas de codificación existentes es adecuada, la Notación de control de codificación (ECN) ofrece una forma para que el usuario defina sus propias reglas de codificación personalizadas.
La codificación de correo con privacidad mejorada (PEM) no tiene ninguna relación con ASN.1 y sus códecs, pero los datos ASN.1 codificados, que a menudo son binarios, suelen estar codificados con PEM para que puedan transmitirse como datos de texto, por ejemplo, a través de relés SMTP o mediante búferes de copiar y pegar.
Este es un ejemplo de módulo ASN.1 que define los mensajes (estructuras de datos) de un protocolo Foo ficticio :
DEFINICIONES DE PROTOCOLO FOOO ::= BEGIN FooQuestion ::= SECUENCIA { númeroDeSeguimiento ENTERO , pregunta IA5String } FooAnswer ::= SECUENCIA { preguntaNumber ENTERO , respuesta BOOLEAN } FIN
Esta podría ser una especificación publicada por los creadores del protocolo Foo. Los flujos de conversación, los intercambios de transacciones y los estados no están definidos en ASN.1, sino que se dejan para otras notaciones y descripciones textuales del protocolo.
Suponiendo un mensaje que cumple con el Protocolo Foo y que se enviará a la parte receptora, este mensaje en particular ( unidad de datos de protocolo (PDU)) es:
myQuestion FooQuestion ::= { trackingNumber 5 , pregunta "¿Hay alguien ahí?" }
ASN.1 admite restricciones de valores y tamaños, y extensibilidad. La especificación anterior se puede cambiar a
DEFINICIONES DE PROTOCOLO FOOO ::= BEGIN FooQuestion ::= SECUENCIA { númeroDeSeguimiento ENTERO ( 0 . . 199 ), pregunta IA5String } FooAnswer ::= SECUENCIA { preguntaNumber ENTERO ( 10. . 20 ), respuesta BOOLEAN } FooHistory ::= SECUENCIA { preguntas SECUENCIA ( TAMAÑO ( 0. . 10 )) DE FooPregunta , respuestas SECUENCIA ( TAMAÑO ( 1. . 10 )) DE FooRespuesta , unaMatriz SECUENCIA ( TAMAÑO ( 100 )) DE ENTERO ( 0. . 1000 ), ... } FIN
Este cambio restringe que los valores de trackingNumbers estén entre 0 y 199 inclusive, y que los de questionNumbers estén entre 10 y 20 inclusive. El tamaño de la matriz questions puede estar entre 0 y 10 elementos, y el de answers entre 1 y 10 elementos. El campo anArray es una matriz de 100 elementos de longitud fija de números enteros que deben estar en el rango de 0 a 1000. El marcador de extensibilidad '...' significa que la especificación de mensajes FooHistory puede tener campos adicionales en futuras versiones de la especificación; los sistemas compatibles con una versión deberían poder recibir y transmitir transacciones de una versión posterior, aunque solo podrían procesar los campos especificados en la versión anterior. Los buenos compiladores ASN.1 generarán (en C, C++, Java, etc.) código fuente que comprobará automáticamente que las transacciones se encuentren dentro de estas restricciones. Las transacciones que violen las restricciones no deberían aceptarse desde la aplicación ni presentarse a ella. La gestión de restricciones en esta capa simplifica significativamente la especificación del protocolo porque las aplicaciones estarán protegidas contra violaciones de restricciones, lo que reduce el riesgo y los costos.
Para enviar el mensaje myQuestion a través de la red, el mensaje se serializa (codifica) como una serie de bytes utilizando una de las reglas de codificación . La especificación del protocolo Foo debe nombrar explícitamente un conjunto de reglas de codificación para usar, de modo que los usuarios del protocolo Foo sepan cuál deben usar y esperar.
A continuación se muestra la estructura de datos que se muestra arriba como myQuestion codificada en formato DER (todos los números están en hexadecimal):
30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
DER es una codificación de tipo-longitud-valor , por lo que la secuencia anterior se puede interpretar, con referencia a los tipos estándar SEQUENCE, INTEGER y IA5String, de la siguiente manera:
30 — etiqueta tipo que indica SECUENCIA13 — longitud en octetos del valor que sigue 02 — etiqueta de tipo que indica número ENTERO 01 — longitud en octetos del valor que sigue 05 — valor (5) 16 — etiqueta de tipo que indica IA5String (IA5 significa el conjunto completo ISO 646 de 7 bits, incluidas las variantes, pero generalmente es US-ASCII) 0e — longitud en octetos del valor que sigue 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — valor ("¿Hay alguien ahí?")
Como alternativa, es posible codificar la misma estructura de datos ASN.1 con reglas de codificación XML (XER) para lograr una mayor legibilidad humana "por cable". Aparecería así: los 108 octetos siguientes (el recuento de espacios incluye los espacios utilizados para la sangría):
<FooQuestion> <trackingNumber> 5 </trackingNumber> <question> ¿Hay alguien ahí? </question> </FooQuestion>
Como alternativa, si se emplean reglas de codificación empaquetadas , se producirán los siguientes 122 bits (16 octetos suman 128 bits, pero aquí solo 122 bits llevan información y los últimos 6 bits son simplemente relleno):
01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0
En este formato, las etiquetas de tipo para los elementos requeridos no están codificadas, por lo que no se pueden analizar sin conocer los esquemas esperados utilizados para codificar. Además, los bytes para el valor de IA5String se empaquetan utilizando unidades de 7 bits en lugar de unidades de 8 bits, porque el codificador sabe que codificar un valor de byte de IA5String requiere solo 7 bits. Sin embargo, los bytes de longitud aún se codifican aquí, incluso para la primera etiqueta de entero 01 (pero un empaquetador PER también podría omitirlo si sabe que el rango de valores permitido cabe en 8 bits, e incluso podría compactar el byte de valor único 05 con menos de 8 bits, si sabe que los valores permitidos solo pueden caber en un rango más pequeño).
Los últimos 6 bits del PER codificado se rellenan con bits nulos en los 6 bits menos significativos del último byte c0: estos bits adicionales no pueden transmitirse ni usarse para codificar otra cosa si esta secuencia se inserta como parte de una secuencia PER no alineada más larga.
Esto significa que los datos PER no alineados son esencialmente un flujo ordenado de bits, y no un flujo ordenado de bytes como en el caso de los PER alineados, y que será un poco más complejo de decodificar por software en los procesadores habituales porque requerirá desplazamiento y enmascaramiento de bits contextuales adicionales y no direccionamiento directo de bytes (pero la misma observación sería cierta con los procesadores modernos y las unidades de memoria/almacenamiento cuya unidad mínima direccionable es mayor que 1 octeto). Sin embargo, los procesadores modernos y los procesadores de señales incluyen soporte de hardware para una decodificación interna rápida de flujos de bits con manejo automático de unidades de cómputo que cruzan los límites de las unidades de almacenamiento direccionables (esto es necesario para un procesamiento eficiente en códecs de datos para compresión/descompresión o con algunos algoritmos de cifrado/descifrado).
Si se requiriera alineación en los límites de octetos, un codificador PER alineado produciría:
01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f
(en este caso, cada octeto se rellena individualmente con bits nulos en sus bits más significativos no utilizados).
La mayoría de las herramientas que admiten ASN.1 hacen lo siguiente:
Se puede encontrar una lista de herramientas que admiten ASN.1 en la página web de herramientas del UIT-T.
ASN.1 es similar en propósito y uso a Google Protocol Buffers y Apache Thrift , que también son lenguajes de descripción de interfaz para serialización de datos multiplataforma. Al igual que esos lenguajes, tiene un esquema (en ASN.1, llamado "módulo") y un conjunto de codificaciones, generalmente codificaciones de tipo-longitud-valor. A diferencia de ellos, ASN.1 no proporciona una implementación de código abierto única y fácilmente utilizable, y se publica como una especificación para ser implementada por proveedores externos. Sin embargo, ASN.1, definido en 1984, los precede por muchos años. También incluye una variedad más amplia de tipos de datos básicos, algunos de los cuales están obsoletos, y tiene más opciones de extensibilidad. Un solo mensaje ASN.1 puede incluir datos de múltiples módulos definidos en múltiples estándares, incluso estándares definidos con años de diferencia.
ASN.1 también incluye compatibilidad integrada con restricciones de valores y tamaños. Por ejemplo, un módulo puede especificar un campo entero que debe estar en el rango de 0 a 100. También se puede especificar la longitud de una secuencia de valores (una matriz), ya sea como una longitud fija o como un rango de longitudes permitidas. Las restricciones también se pueden especificar como combinaciones lógicas de conjuntos de restricciones básicas.
Los valores utilizados como restricciones pueden ser literales utilizados en la especificación PDU o valores ASN.1 especificados en otra parte del archivo de esquema. Algunas herramientas ASN.1 pondrán estos valores ASN.1 a disposición de los programadores en el código fuente generado. Si se utilizan como constantes para el protocolo que se está definiendo, los desarrolladores pueden utilizarlos en la implementación lógica del protocolo. De este modo, todas las PDU y las constantes del protocolo se pueden definir en el esquema, y todas las implementaciones del protocolo en cualquier lenguaje compatible se basan en esos valores. Esto evita que los desarrolladores tengan que codificar manualmente las constantes del protocolo en el código fuente de su implementación. Esto ayuda significativamente al desarrollo del protocolo; las constantes del protocolo se pueden alterar en el esquema ASN.1 y todas las implementaciones se actualizan simplemente mediante la recompilación, lo que promueve un ciclo de desarrollo rápido y de bajo riesgo.
Si las herramientas ASN.1 implementan correctamente la comprobación de restricciones en el código fuente generado, esto actúa para validar automáticamente los datos del protocolo durante la operación del programa. Generalmente, las herramientas ASN.1 incluirán la comprobación de restricciones en las rutinas de serialización/deserialización generadas, lo que generará errores o excepciones si se encuentran datos fuera de los límites. Es complejo implementar todos los aspectos de las restricciones ASN.1 en un compilador ASN.1. No todas las herramientas admiten la gama completa de posibles expresiones de restricciones. Tanto el esquema XML como el esquema JSON admiten conceptos de restricciones similares. La compatibilidad de las herramientas con las restricciones varía. El compilador xsd.exe de Microsoft las ignora.
ASN.1 es visualmente similar a la forma aumentada Backus-Naur (ABNF), que se utiliza para definir muchos protocolos de Internet como HTTP y SMTP . Sin embargo, en la práctica son bastante diferentes: ASN.1 define una estructura de datos, que se puede codificar de varias maneras (por ejemplo, JSON, XML, binario). ABNF, por otro lado, define la codificación ("sintaxis") al mismo tiempo que define la estructura de datos ("semántica"). ABNF tiende a usarse con más frecuencia para definir protocolos textuales legibles por humanos y, por lo general, no se usa para definir codificaciones de tipo-longitud-valor.
Muchos lenguajes de programación definen formatos de serialización específicos del lenguaje. Por ejemplo, el módulo "pickle" de Python y el módulo "Marshal" de Ruby. Estos formatos son generalmente específicos del lenguaje. Tampoco requieren un esquema, lo que los hace más fáciles de usar en escenarios de almacenamiento ad hoc, pero inadecuados para protocolos de comunicaciones.
De manera similar, JSON y XML no requieren un esquema, lo que los hace fáciles de usar. Ambos son estándares multiplataforma que gozan de gran popularidad en los protocolos de comunicación, en particular cuando se combinan con un esquema JSON o XML .
Algunas herramientas ASN.1 pueden traducir entre ASN.1 y el esquema XML (XSD). La traducción está estandarizada por la ITU. Esto permite que un protocolo se defina en ASN.1 y también automáticamente en XSD. Por lo tanto, es posible (aunque quizás no sea aconsejable) tener en un proyecto un esquema XSD compilado por herramientas ASN.1 que produzcan código fuente que serialice objetos a/desde un formato de cable JSON. Un uso más práctico es permitir que otros subproyectos consuman un esquema XSD en lugar de un esquema ASN.1, tal vez adecuando la disponibilidad de las herramientas para el lenguaje de elección del subproyecto, con XER utilizado como el formato de cable del protocolo.
Para obtener más detalles, consulte Comparación de formatos de serialización de datos .