Resumen

  • Date expresa cuándo el creador consideró terminado el mensaje y listo para enviarse, no cuándo la red lo transportó de verdad.
  • Los relays de Netnews necesitaban limitar el historial de Message-ID vistos. Aplicar el límite a la fecha de composición podía rechazar como viejo un artículo recién inyectado.
  • Injection-Date añadió la hora del ingreso sin reemplazar Date. Mejoró la evidencia de admisión, pero no autenticó al autor ni convirtió un reloj en verdad universal.

El artículo del lunes que apareció el viernes

Una persona termina de escribir mientras no tiene conexión. La aplicación fija Date el lunes y guarda el artículo. Cuatro días después, el posting agent logra entregarlo a un servidor de noticias.

El lunes es correcto para quien escribió: señala el momento en que declaró completo el texto. Para un relay que conserva un historial finito, también puede parecer la marca de un artículo antiguo que regresa después de que su Message-ID dejó de estar en la base de duplicados.

Modificar la fecha a viernes facilitaría el paso, a costa de inventar otro momento de creación. Mantenerla puede activar el rechazo por antigüedad. El conflicto no nace de un reloj defectuoso, sino de exigir a una sola marca que documente la escritura y autorice la circulación.

Netnews salió de esa falsa alternativa con una segunda fecha que no tenía permiso para borrar la primera.

Date protegía la cronología del creador

La RFC 1036, de 1987, llamaba a Date —antes Posted— la fecha en que el mensaje se publicó originalmente en la red. Debía permanecer sin cambios durante la propagación. Así, cada salto no podía reiniciar silenciosamente la historia.

La RFC 5322 precisó la semántica de origen. La fecha corresponde al instante en que el creador indicó que el mensaje estaba completo y listo para entrar en la entrega. No pretende indicar el transporte real. Su ejemplo de un portátil desconectado conserva la hora en que el usuario puso el mensaje en cola, no aquella en que volvió a conectarse.

Esa distinción convierte Date en memoria del acto de creación. También impide tratarla como evidencia suficiente del ingreso. El reloj puede estar desajustado, el valor puede ser falso o la espera puede ser legítimamente larga. Incluso una fecha perfecta responde a otra pregunta.

El precio de recordar cada Message-ID

Netnews distribuye artículos entre agentes independientes. La RFC 5537 obliga a relaying agents y serving agents a registrar lo ya visto y rechazar una segunda oferta del mismo artículo. Sin esa memoria, el flood-fill puede repetir indefinidamente el tráfico.

Guardar para siempre todos los Message-ID haría crecer la historia sin límite. Por eso se permite un intervalo de corte. El servidor puede rechazar artículos fechados antes de la ventana y eliminar sus registros antiguos, ya que una reaparición también fallaría el control temporal. La RFC menciona siete días como convención mínima en Usenet y advierte que un intervalo inferior al tiempo de propagación puede bloquear algo que el servidor jamás había recibido.

La fecha no demuestra una duplicación. Permite acotar cuánto tiempo se guarda la prueba capaz de reconocerla. Una ventana breve ahorra antes, pero sacrifica retrasos legítimos; una larga conserva más evidencia y consume más recursos.

Si el cálculo usa composición, también cuenta como edad de red los días en que el artículo ni siquiera estuvo en ella.

Injection-Date obtuvo una autoridad limitada

La RFC 5536 define Injection-Date como la fecha y hora en que el artículo fue inyectado en la red. La finalidad es que los servidores comprueben la antigüedad con un valor puesto por un news server al ingresar, no con el valor que el user agent añadió al redactar.

El campo debe insertarse en la inyección. Aun así, los agentes deben aceptar artículos que no lo tengan porque el software anterior no lo conocía. Cuando falta, RFC 5537 recurre a Date. La compatibilidad permitió desplegar la mejora sin exigir una ruptura simultánea.

El límite decisivo es la no sustitución. Al añadir Injection-Date, un agente no puede alterar un Date ya existente. Además, las dos máquinas pueden tener relojes desincronizados; la marca de ingreso podría parecer anterior a la de composición. El estándar no convierte la resta entre ambas en una prueba infalible.

El nombre documentado reemplazó al usado pero no especificado NNTP-Posting-Date, ahora obsoleto. Normalizar el campo coordinó significados, no relojes.

Tres tiempos con tres alcances

RFC 5537 usa Injection-Date, y solo en su ausencia Date, para la optimización habitual del historial. Los relays y servidores examinan la fecha futura excesiva y, si aplican un corte, la comparan con su ventana.

Otra estrategia envejece el registro desde la primera observación local. En el esquema descrito, la retención debe superar el corte al menos 24 horas para cubrir el margen permitido de fechas futuras. Esa alternativa ya revela una tercera hora.

La RFC 3977 la formaliza: un servidor NNTP mantiene un arrival timestamp y entrega números locales siguiendo ese orden. La llegada pertenece a un servidor, no a todo Netnews.

Las marcas no son intercambiables:

  • Date pertenece a la declaración de finalización del creador;
  • Injection-Date pertenece al cruce de la frontera de ingreso;
  • arrival time pertenece a la recepción de un servidor concreto.

Una demora entre servidores no reescribe al autor. Una espera del autor no prueba que el artículo haya estado recirculando.

Varias entradas no daban varias edades

Por resiliencia o por redes separadas, el mismo artículo podía ofrecerse a más de un injecting agent. La intención seguía siendo un solo artículo: cuando los caminos convergieran, Message-ID permitiría aceptar una vez y suprimir lo repetido.

RFC 5537 exige que Message-ID, Date e Injection-Date sean idénticos en todas las copias del proto-artículo. Si un artículo ya inyectado se prepara para entrar en otra red, esos tres campos se conservan sin modificaciones. Actualizar la segunda fecha en cada puerta haría que una sola publicación recuperara juventud una y otra vez.

Así, Injection-Date no significa simplemente la hora actual de cualquier gateway. En la inyección múltiple, forma parte de la continuidad necesaria para que diferentes puntos representen el mismo ingreso editorial.

El pasado siguió dentro del protocolo

El software antiguo ignora el nuevo campo y usa Date para sus cortes. RFC 5537 reconoce que una composición muy anterior puede propagarse peor aunque lleve un Injection-Date válido.

Cuando Message-ID y Date ya están presentes, el posting agent debería añadir la segunda marca si ha pasado más de un día y debe hacerlo al entregar a varios injecting agents. El agente de ingreso controla valores demasiado futuros o antiguos y añade su hora cuando corresponda. Cerca del usuario todavía puede explicar el rechazo; más adelante, un relay solo ve los campos.

La transición no prometió una decisión uniforme. Transportó evidencia nueva sin retirar la vieja ruta de compatibilidad.

El registro no certifica el reloj

Injection-Date es una afirmación temporal de un agente de ingreso. No es firma criptográfica, prueba de autoría ni garantía de sincronización. Tampoco indica aprobación de moderación, lectura humana, llegada a cada servidor o vencimiento de la retención local.

El registro de campos de mensaje de IANA lo enumera como campo estándar de Netnews y remite a RFC 5536. El registro asegura un nombre compartido; no avala cada valor ni prueba adopción universal.

La ganancia histórica fue contener la autoridad de las fechas. El autor conservó la suya. La red añadió una observación para su propia admisión. Cada servidor mantuvo además su llegada. El sistema ganó precisión porque dejó de presentar una sola hora como dueña de todos los acontecimientos.