Document input size guidance for HTTP-exposed ISCC generation

[titusz]

Problem

None of the content-code IEPs (IEP-0003 through IEP-0009) specify input size limits. For Data-Code and Instance-Code this is fine (streaming hashers handle arbitrarily large inputs), but several functions process full inputs in memory:

• gen_text_code_v0 (IEP-0003): Full text n-gram generation in memory
• gen_image_code_v0 (IEP-0004): Image pixel array in memory
• gen_audio_code_v0 (IEP-0005): Chromaprint feature array in memory
• gen_video_code_v0 (IEP-0006): Frame signature array in memory

When ISCC generation is exposed via HTTP APIs, unbounded inputs create denial-of-service potential.

Proposal

Add implementer guidance (as a section in existing IEPs or as a standalone security considerations document):

• When exposing ISCC generation via HTTP, implementers SHOULD enforce request-level size limits.
• Text content >10 MB provides diminishing returns for similarity hash quality.
• Audio chromaprint arrays >1M entries and video frame arrays >10K frames exceed practical utility.

This keeps the core algorithms unconstrained (no spec changes needed) while giving API implementers the security guidance they need.

Checklist

• Security considerations section or guidance document created
• Recommended size limits documented for web-exposed deployments