Tema: standards
-
Números de teléfono E.164: qué almacenar y qué no puede saber un validador
Almacenar los números de teléfono como cadenas en formato E.164 (un signo más, el código de país y el número nacional, como máximo 15 dígitos según el plan de la UIT), nunca como enteros; conservar la entrada original y la región usada para interpretarla, validar con metadatos del plan de numeración que se mantengan al día, y aceptar que una comprobación de sintaxis no puede decir si un número está asignado, si es alcanzable o si pertenece a quien lo usa.
-
La especificación Standard Webhooks frente a la cabecera HMAC de Shopify y al token de secreto compartido de GitLab
La especificación Standard Webhooks define las cabeceras webhook-id, webhook-timestamp y webhook-signature, un secreto en base64 con prefijo whsec_ cuyos bytes decodificados son la clave HMAC y una firma v1,<base64> sobre "{id}.{timestamp}.{payload}"; los tokens de firma de GitLab (GitLab 19.0, disponibilidad general en 19.1) la implementan tal cual. Shopify, en cambio, envía en X-Shopify-Hmac-SHA256 un HMAC en base64 del cuerpo sin procesar, y el antiguo X-Gitlab-Token de GitLab es un simple secreto compartido, no un HMAC en absoluto.
-
Fundamentos de vCard 4.0: el formato text/vcard para intercambiar contactos
Una vCard es un documento text/vcard en UTF-8 formado por BEGIN:VCARD, VERSION:4.0, un FN obligatorio y propiedades estructuradas opcionales (N, TEL, EMAIL, ADR, UID, REV) con parámetros; los valores escapan las comas, los puntos y coma y las barras invertidas, y las líneas de contenido se pliegan a un máximo de 75 octetos. jCard (RFC 7095) transporta el mismo modelo en JSON.
-
Cabeceras List-Unsubscribe y de baja con un clic (RFC 2369 y RFC 8058)
RFC 2369 define cabeceras que permiten a los clientes de correo ofrecer acciones de lista; el «one-click» de RFC 8058 añade una URI HTTPS en List-Unsubscribe más List-Unsubscribe-Post: List-Unsubscribe=One-Click, procesada mediante un POST HTTPS sin redirección y sin pasos adicionales, con ambas cabeceras cubiertas por DKIM. Las directrices de Google exigen a los remitentes masivos que lo admitan.
-
XML hoy: bien formado frente a válido, espacios de nombres y cuándo sigue siendo la opción adecuada
Un documento XML bien formado cumple la sintaxis; uno válido, además, satisface una DTD o un esquema. Los espacios de nombres dan a cada elemento y atributo un nombre expandido formado por el URI del espacio de nombres y el nombre local, enlazado mediante declaraciones xmlns cuyos prefijos son arbitrarios y cuya forma por defecto no se aplica a los atributos. XML sigue siendo la opción adecuada para documentos de contenido mixto y para ecosistemas cuyos vocabularios y herramientas ya son XML.
-
Códigos de país y de moneda en los datos: ISO 3166-1 e ISO 4217 sin sorpresas
Guarda los países como códigos ISO 3166-1 alfa-2 y las monedas como códigos ISO 4217 alfa-3 junto con su exponente de unidad menor, versiona las tablas de códigos porque sus entradas cambian y nunca derives un código del otro: un país no tiene un único idioma ni una única moneda, y códigos como UK o XXX son trampas.
-
Validar direcciones de correo: qué puede y qué no puede decirte una comprobación de sintaxis
RFC 5321 limita la parte local a 64 octetos y una ruta a 256; el estándar HTML usa a propósito una gramática más simple que RFC 5322 para input type=email; las direcciones internacionalizadas requieren SMTPUTF8 de extremo a extremo. Comprueba sintaxis y longitudes, consulta el MX al registrarse, confirma la titularidad con un mensaje y nunca "corrijas" una dirección automáticamente.
-
Dígitos de control: qué detectan Luhn, ISBN-13 y el módulo 97 de IBAN, y qué no
Un dígito de control es redundancia calculada a partir de los demás caracteres de un identificador para detectar errores de copia antes de una consulta: Luhn (módulo 10 con dígitos duplicados alternos) protege los números de tarjeta, ISBN-13 usa pesos alternos 1 y 3, e IBAN usa ISO/IEC 7064 MOD 97-10 con dos dígitos. Detectan errores de un solo carácter y la mayoría de las transposiciones adyacentes, pero nunca un identificador erróneo que sea válido.
-
GeoJSON y coordenadas geográficas: primero la longitud, WGS 84 y la regla de la mano derecha
La RFC 7946 fija las posiciones de GeoJSON como [longitud, latitud, elevación opcional] en grados decimales WGS 84, envuelve las geometrías en objetos Feature y FeatureCollection con un miembro properties, exige anillos de polígono cerrados con exteriores en sentido antihorario, recomienda cortar las geometrías en el antimeridiano y aclara que el número de dígitos no expresa incertidumbre.
-
RateLimit y RateLimit-Policy frente a X-RateLimit-*: cómo leer las cabeceras de cuota que envíe una API
Un Internet-Draft del IETF (draft-ietf-httpapi-ratelimit-headers-11, mayo de 2026) propone los campos RateLimit y RateLimit-Policy (p. ej. RateLimit: "default";r=50;t=30) para anunciar la cuota antes de un 429, pero sigue siendo un borrador. La mayoría de las API actuales envían sus propias cabeceras del tipo x-ratelimit-limit/-remaining/-reset o nada más que Retry-After, que define RFC 9110 (segundos o una HTTP-date) y que RFC 6585 permite en un 429.
Legible por máquina: JSON