Resumen

  • La RFC 5365 define un servicio SIP para mensajería instantánea en modo pager: recibe un MESSAGE con una lista plana de URI y una carga útil, devuelve 202 Accepted y actúa como B2BUA especializado para originar un MESSAGE nuevo por destinatario.
  • El 202 sólo demuestra que el servicio recibió la solicitud y va a intentarlo. Cada salida tiene Request-URI, To, Call-ID, CSeq, Max-Forwards y Via propios; puede fallar, quedar incierta o necesitar una prueba de entrega adicional que la especificación deja fuera de alcance.
  • La dirección debe impedir que el estado de aceptación se convierta en un indicador de entrega. También debe separar el payload copiado de la identidad afirmada, la privacidad, el ámbito de credenciales, la audiencia criptográfica y el historial de destinatarios que el intermediario reconstruye.

El primer recibo llegó antes que las acciones

La comodidad de una lista improvisada es temporal además de sintáctica. Alice envía una sola solicitud, el servicio la acepta rápidamente y el trabajo de crear mensajes para los destinatarios continúa después. La interfaz puede cerrar el gesto humano antes de que la infraestructura conozca los resultados.

RFC 5365 utiliza una petición MESSAGE multipart. Una parte contiene la lista plana definida para el uso de listas de recursos; otra contiene el mensaje instantáneo. El cliente señala que requiere recipient-list-message. El servidor examina la lista y origina una solicitud independiente para cada URI canónica.

La respuesta 202 encaja con ese diseño asíncrono. No intenta resumir eventos futuros. Dice que el servicio recibió la solicitud y que intentará procesarla. La propia RFC advierte que la respuesta no ofrece información sobre si los MESSAGE generados se entregaron correctamente.

El error operativo nace cuando una métrica cambia el sustantivo sin avisar. «Solicitudes aceptadas» se etiqueta como «mensajes enviados»; más tarde, el mismo contador aparece como «mensajes entregados». La cifra permanece constante y su afirmación se vuelve cada vez más fuerte sin nueva evidencia.

Aceptar era una acción del servicio de lista

El sujeto del 202 es el servicio al que Alice dirigió la petición. No es Bob, no es el servidor de Bob y no es el dispositivo donde Bob leería el mensaje. Esta gramática importa: toda evidencia debe nombrar al actor que pudo observar el hecho.

El servicio puede validar formato, soporte de la opción, autorización de Alice y contenido básico antes de responder. Todavía debe descomponer el multipart, resolver destinatarios, aplicar duplicados según RFC 5363, preparar cuerpos, decidir identidad y privacidad, elegir rutas y ejecutar transacciones posteriores.

Un 202 legítimo puede preceder a un fallo legítimo. La ruta de Bob puede no existir; el siguiente salto puede rechazar el MESSAGE; una regla de confianza puede suprimir una identidad; una clave puede impedir construir un historial protegido; el proceso puede caer después de responder. Ninguna de estas posibilidades hace falso el 202. Hace falso tratarlo como recibo final.

Por eso el modelo de estados no debe reemplazar accepted por delivered. Debe añadir estados y evidencias: aceptado por el servicio, operación creada, intento emitido, respuesta downstream observada, recibo de entrega recibido y efecto en el cliente cuando sea relevante.

Cada destinatario abrió una transacción nueva

RFC 5365 describe al servicio como un B2BUA especializado. En el lado de entrada funciona como servidor; en el lado de salida, como cliente que origina mensajes. No reenvía una única transacción por varias rutas.

Para cada destinatario debería construir un To nuevo, un Call-ID nuevo y su propia secuencia CSeq. Inicializa Max-Forwards e inserta Via. La Request-URI deja de señalar al servicio de lista y pasa a señalar el destino individual.

La nueva identidad transaccional impide inferir resultados a partir del ingreso. El Call-ID de Alice no es la clave universal de los mensajes hijos. A la vez, guardar sólo los Call-ID nuevos perdería la unidad causal que explica por qué nacieron.

La estructura correcta conserva un identificador de ejecución parental, el conjunto canónico de destinatarios, una intención por posición y uno o varios intentos por intención. El Call-ID y CSeq pertenecen al intento SIP; la relación con la entrada pertenece al registro del servicio.

Así se puede reintentar sólo la posición adecuada. Repetir la solicitud parental por una única incertidumbre puede duplicar entregas ya completadas, y el 202 original no ayuda a distinguirlas.

La carga útil no arrastró su contexto de seguridad

El servicio suele copiar los cuerpos que constituyen el mensaje, como texto o imágenes. Esa continuidad semántica puede hacer pensar que todo el sobre conserva su identidad. La RFC exige lo contrario en puntos críticos.

Un cuerpo S/MIME u otro cuerpo de seguridad cifrado para el servicio de lista no debe copiarse a los destinatarios. Ellos no son su audiencia y quizá no puedan descifrarlo. El intermediario consume aquello que le estaba dirigido y construye otra representación para la salida.

Si, después de retirar la lista y los cuerpos destinados al servicio, queda una sola parte, debe quitarse el wrapper multipart/mixed. Por tanto, la solicitud completa puede cambiar byte por byte aunque el contenido conversacional sea equivalente.

Una comprobación robusta conserva hashes por parte, tipos MIME, Content-Disposition, regla de transformación y audiencia. Comparar todo el mensaje como blob castigaría una transformación obligatoria. Comparar únicamente el texto renderizado permitiría cambiar adjuntos o disposiciones sin alarma.

El resultado de entrega pertenece a la nueva representación. Un hash del payload entrante demuestra qué contenido se aceptó; no demuestra que el cuerpo correcto se construyó, protegió, emitió y presentó a cada receptor.

El remitente visible tampoco era una prueba de entrega

El valor From de salida debe conservar el valor de entrada, sujeto a privacidad. El tag no se mantiene como si continuara el mismo diálogo, y un servicio de privacidad co-localizado tiene prioridad.

Bob puede ver a Alice aunque la solicitud concreta haya sido originada por el servidor. Esa elección mejora la experiencia humana, pero no convierte la pantalla de Bob en una verificación criptográfica de extremo a extremo. El servicio autenticó, aplicó política y decidió qué representación de remitente podía emitir.

P-Asserted-Identity sigue reglas aún más explícitas. Puede propagarse cuando llega de una fuente confiable y sale hacia un primer salto confiable. Debe suprimirse ante un salto no confiable cuando se pidió privacidad. El servicio puede crear una afirmación si autenticó al usuario y puede mapearlo a un URI SIP o SIPS.

Así, payload, From y PAI pueden contar tres continuidades distintas: contenido, autor conversacional y afirmación dentro de un dominio de confianza. Ninguna constituye por sí sola un recibo de entrega.

Las credenciales terminaban donde terminaba su realm

Authorization y Proxy-Authorization responden a un ámbito de autenticación. Si el realm corresponde al servicio de lista MESSAGE, el servicio no debería copiar esos campos a la solicitud siguiente. Haber autenticado a Alice frente al intermediario no autoriza presentar su secreto ante Bob.

Si la cabecera corresponde a otro realm, la RFC exige copiar el valor pertinente. La regla no es borrar siempre ni copiar siempre. Clasifica la autoridad que planteó el desafío.

En el registro basta guardar tipo, realm, decisión y motivo sin retener el secreto. Si se almacenan credenciales brutas para explicar un fallo, la observabilidad crea una vulnerabilidad mayor que la que intentaba diagnosticar.

La separación de realm también evita una lectura engañosa del 202. El servicio pudo aceptar correctamente gracias a una credencial que jamás debía cruzar la frontera. El downstream puede necesitar otra autenticación y producir otro resultado.

El historial de participantes tenía su propio éxito o fallo

El servicio puede construir recipient-list-history para funciones como responder a todos. No copia simplemente la lista original. Aplica las reglas de RFC 5364 para To, Cc, Bcc y anonimato, y debería cifrar la vista para el receptor.

El cuerpo entregado a Bob puede ser correcto mientras su historial revela de más. También puede fracasar la creación del historial aunque el texto del mensaje esté intacto. Son componentes con provenance, audiencia y criterios de éxito distintos.

La prueba debe asociar cada vista a su receptor: versión de entrada, política aplicada, miembros visibles, exclusiones, hash del cuerpo y protección utilizada. Una vista creada para Bob no demuestra qué debía ver Carol.

Esta construcción es otro motivo por el que la aceptación temprana no puede cerrar el caso. Entre el 202 y la emisión quedan decisiones de divulgación que pueden causar daño irreversible.

Los componentes de URI eran sugerencias bajo contrato

Una URI SIP puede incorporar componentes de header. El servicio puede decidir por componente si honra una indicación como Accept-Contact. El hname especial body no debe sustituir la carga útil y puede descartarse.

Una URI también puede traer un parámetro de método. RFC 5365 ordena ignorarlo si pide otra cosa: este servicio genera MESSAGE y no puede convertirse mediante datos de la lista en un emisor de INVITE u otra acción.

El límite protege la semántica de la API. El llamador controla los destinatarios y ciertos detalles permitidos; no controla la naturaleza completa del actor intermediario. Un registro debería indicar qué componentes fueron aceptados, rechazados o ignorados.

De nuevo, la aceptación del contenedor no prueba que cada preferencia fuera aplicada. La interfaz debe devolver o exponer las decisiones si el comportamiento importa al usuario.

El estado final necesitaba un vocabulario por destinatario

RFC 5365 deja fuera de alcance el diseño concreto del estado de entrega. Eso no autoriza al producto a inventar certeza. Obliga a declarar qué observaciones existen y qué afirmaciones pueden sostener.

Para cada destinatario, el sistema puede distinguir: no se creó operación; operación preparada; petición emitida; respuesta SIP provisional; respuesta final de aceptación o rechazo; recibo de entrega de una capa superior; efecto observado; estado desconocido dentro de un límite temporal.

Los estados deben incluir causa y momento. «Falló» sin saber si no se intentó, se rechazó o quedó sin observación no permite una repetición segura. «Éxito» sin nombrar aceptación o entrega convierte una abstracción útil en falsa certeza.

Un agregado sólo puede derivarse de las posiciones individuales. Nunca puede reducir el denominador a las transacciones visibles ni clasificar lo desconocido como éxito para cerrar un panel. La ausencia de evidencia es un estado operativo, no un voto afirmativo.

El registro IANA no era telemetría

IANA registra recipient-list-message y disposiciones asociadas para que las implementaciones compartan nombres. El registro demuestra una asignación estandarizada; no demuestra que un servidor determinado aplique bien privacidad, identidad, MIME o resultados.

RFC 5365 se publicó en octubre de 2008 como Standards Track. RFC 3851 quedó obsoleta en la evolución de S/MIME, incluido RFC 8551. Una implementación actual debe elegir mecanismos criptográficos actuales sin perder la frontera conceptual: todo cuerpo protegido tiene una audiencia concreta.

La nota de Lu Heng sobre especificación inicial mínima ayuda a leer esta división. El protocolo estandariza el contrato compartido mínimo; la ruta, confianza, política de privacidad y comprobación de efectos quedan donde existe información local. Su nota sobre capas de realidad añade que un estado simbólico —202, hash, etiqueta— no debe sustituir la realidad operativa posterior.

Esas notas son lentes declaradas, no fuentes del protocolo. Las reglas técnicas proceden de las RFC y del registro IANA.