这两天我彻底扎进SIGN的技术文档，还有点上头。
然后我又发现了一迷人的设计！
W3C Bitstring Status List v1.0 §2.2 的属性表格里，有一行字：
"The ttl is an OPTIONAL property... If not present, no default value is assumed."
人话就是：不写，我不管；缓存多久，你说了算。
W3C 把这个皮球踢给了所有部署方。SIGN接住了，然后也没踢出去。部署指南里 ttl 依然可选，依然没有场景分级默认值的原始状态。
但我后来想明白了，这个"懒设计"是有道理的。$SIGN
W3C 把 ttl 设成 OPTIONAL，因为它想太清楚了：
状态列表的刷新周期，本质上是业务决策，不是技术决策。驾照撤销和医疗授权凭证的撤销，对时效性的要求差了几个数量级。
把决策留给部署方，是规范层唯一正确的选择，因为你不能用一个参数统治所有场景，强行规定只会制造新的错误。
所以SIGN 选择在协议层保持沉默，把决策权留在离业务最近的地方。
这是它对部署复杂性的真实理解。
但理解复杂性，和帮助部署方驾驭复杂性是有差距的。
W3C §7.2 列出了设定有效期时需要考量的五个维度：更新频率、监管要求、声誉风险、网络负担、Verifier 对状态列表有效期上限的容忍度。但SIGN的部署指南里一个都没承接。
准备在主权级场景部署SIGN 的工程师，打开文档，看到的是"TTL 可选"。然后还要自己去读 W3C 规范，推导业务场景的时效性要求，写一个没有任何参照的配置值。
这不是赋权，这是甩锅！@SignOfficial
赋权是给你决策权的同时，给你做决策所需要的参照系。甩锅是把决策权丢过来，然后转身走掉。
我想问 SIGN 一件事：能不能在懒得做一些事的同时，也稍微勤快点告诉一下部署方，这个决定该怎么做？
不是替他们做决定。而是给他们一张地图。
地图和答案是不一样的。而SIGN现在给人留的，还是一片空白...