The author closed them on 30-09, all with the recommendation. The limits
stay as proposed and freeze with format 3. A single file inside a folder
downloads directly, with the ZIP as a second option, and the page offers
each file of the ZIP as an uncopied slice of it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Un fichero de un solo segmento va al fichero fijo de OPFS; sin ficheros, solo se muestra el comentario.
- En los demás casos, un ZIP propio: entradas almacenadas, bit 11, sin descriptores de datos ni entradas de carpeta.
- En los demás casos, un ZIP propio en ese mismo fichero: entradas almacenadas, bit 11, sin descriptores de datos ni entradas de carpeta.
- Como las entradas van sin comprimir, cada fichero ocupa un tramo continuo del ZIP. La página ofrece la descarga suelta de cualquier fichero de la lista como un corte del ZIP, sin copiarlo, y el ZIP entero para descargarlo todo con sus carpetas.
- Con un único fichero dentro de una carpeta, la descarga principal es el fichero, con su nombre, y el ZIP con la carpeta es la segunda opción (decisión 8 del apartado 9).
- El CRC-32 se parchea con escrituras posicionadas (`TempFileHandle` pasa a `FileSystemWritableFileStream`).
- ZIP64 cuando hay 0xFFFF entradas o más, o algún tamaño u offset ≥ 0xFFFFFFFF.
- Tiempos: hora DOS en UTC, recortada a 1980–2107. El extra 0x000A va siempre y es el que manda; después, 0x5455 solo si 0 ≤ t ≤ 2³¹ − 1. Una entrada sin mtime recibe round_time.
@ -509,20 +511,32 @@ Ejemplos:
- un lector que informa `ERR_HEAD_INVALID` antes de EOF no es conforme;
- el escritor omite una mtime negativa.
### 9. Preguntas abiertas de la entrega 1
Hay que cerrarlas antes de redactar el texto del spec. Cada una lleva su recomendación.
1. ¿Código nuevo `ERR_HEAD_INVALID`? Sí: separa un escritor defectuoso de un CBOR roto.
2. ¿`AREA_LEN` = 512 para los escritores de las entregas 1 y 2? Sí: cuesta 490 bytes por cápsula y oculta la firma. La alternativa es fijar ya el área final, por ejemplo 4096, para todo escritor: cuesta unos 3,5 KB por cápsula y quita la fuga del área de 512 (apartado 0.4), pero el tamaño del token aún no es definitivo.
3. ¿El área la fija la versión del spec, y el mapa `security` sigue en su versión 1 cuando llegue el sello? Sí: así un lector de la entrega 2 sigue comprobando la firma en una cápsula de la entrega 3. La alternativa, una versión 2 de `security` con su propia área, haría que ese lector lo mostrara todo como no soportado.
4. ¿Tablas propias, generadas de UCD 17.0.0? Sí: la regla ligera deja pasar colisiones NFC/NFD, y cada motor trae su versión de Unicode.
5. ¿Aceptar que un head de versión nueva falle tras la fecha? No: §22 exige un formato nuevo para todo cambio que un lector anterior solo detectaría después de pedir el release. En el formato 3 el head va siempre en su versión 1 (apartado 2).
6. ¿Escribir solo el formato 3? Sí.
7. Límites: comentario 16 KiB, autor 256 B, ruta 1024 B, segmento 255 B, profundidad 32, 65 535 ficheros, head 16 MiB y área 64 KiB. Falta confirmarlos.
8. ¿Un único fichero dentro de una carpeta? En ZIP.
9. ¿Cápsulas solo con comentario? El lector acepta C = 0; el escritor exige un fichero o un comentario.
10. ¿Rechazar un '-' inicial? No, solo avisar.
### 9. Decisiones de la entrega 1
El autor cerró el 30-09 las diez preguntas abiertas, todas con la recomendación:
1. Hay un código nuevo, `ERR_HEAD_INVALID`: separa un escritor defectuoso de un CBOR roto.
2. Los escritores de las entregas 1 y 2 usan `AREA_LEN` = 512: cuesta 490 bytes por cápsula y oculta la firma. Se descartó fijar ya un área de 4096.
3. El área la fija la versión del spec, y el mapa `security` sigue en su versión 1 cuando llegue el sello. Así un lector de la entrega 2 sigue comprobando la firma en una cápsula de la entrega 3.
4. Las tablas Unicode son propias, generadas de UCD 17.0.0.
5. El head va siempre en su versión 1. Una versión nueva exige un formato nuevo (§22), así que nunca falla tras la fecha por su versión.
6. Los escritores de la v0.10 solo escriben el formato 3.
7. Los límites quedan como se propusieron, y con el formato 3 quedan congelados: subirlos exigiría un formato nuevo.
| Límite | Valor |
|---|---|
| Comentario | 16 KiB |
| Autor declarado | 256 B |
| Ruta | 1024 B |
| Segmento | 255 B |
| Profundidad | 32 segmentos |
| Ficheros | 65 535 |
| Head | 16 MiB |
| Área | 64 KiB |
8. Un único fichero dentro de una carpeta se descarga directamente, con su nombre, y el ZIP con la carpeta es una opción (apartado 5). No cambia el formato.
9. El lector acepta una cápsula sin ficheros (C = 0); el escritor exige un fichero o un comentario.
10. Un '-' inicial en una ruta solo da un aviso.
---
@ -810,8 +824,8 @@ Un revisor comprobó que los arreglos de Fable y las decisiones del autor están
| # | Hallazgo | Resolución |
|---|---|---|
| 1 | Un head de versión 2 dentro del formato 3 solo fallaría tras pedir el release, contra §22 | El head va siempre en su versión 1, y la pregunta 5 de la entrega 1 pasa a «No» (apartados 2 y 9) |
| 2 | El área de la entrega 3 dependía de que el escritor supiera sellar, y un área de 512 delata que no hay sello | El área depende solo de la versión del spec; dos fugas nuevas declaradas; la alternativa de 4096 en la pregunta 2; la versión del spec de cada entrega (apartados 0.4, 2 y 9) |
| 1 | Un head de versión 2 dentro del formato 3 solo fallaría tras pedir el release, contra §22 | El head va siempre en su versión 1 (apartados 2 y 9) |
| 2 | El área de la entrega 3 dependía de que el escritor supiera sellar, y un área de 512 delata que no hay sello | El área depende solo de la versión del spec; dos fugas nuevas declaradas; la alternativa de 4096, descartada; la versión del spec de cada entrega (apartados 0.4, 2 y 9) |
| 3 | Faltaban §55.1 y otras secciones en los cambios del spec | Añadidas (apartados 8 y 15) |
| 4 | Los avisos al extraer comparaban el nombre tal cual | Comparan la clave de R7 (apartado 3) |
| 5 | HFS+ solo ignora ZWNJ y ZWJ, y su límite es de 255 unidades UTF-16 tras NFD | R3 corregido y con ese límite (apartado 3) |
