Martin Duerst wrote:
I plan to submit it to the IESG for further processing soon, unless
any serious problems are found.
=== 1st issue ===
It's not exactly serious, but IMO you just can't register anything X-...
You can explain what it was, and why anybody using it should upgrade
to Archived-At, but you can't register X-Archived-At. STD 11 / RFC 822
says X-... is user territory.
Just delete section 5.2, integrating 5.1 into 5. If you want to add
another example (news usage without Message-ID) you could take this:
| Xref: news.gmane.org gmane.ietf.message-headers:30
| Archived-At: <http://permalink.gmane.org/gmane.ietf.message-headers/30>
But that's of course only "lillyguilding", in other words it's almost
ready, minus the X-... nit.
=== 2nd point ===
I'm not sure about section 2.4, Archived-At as URI will do for some
years: IRI-producers can as well produce URIs, but "old" Archived-At
consuments like my tools support only some URI schemes, no "raw" IRIs.
Besides raw UTF-8 in message headers is strictly impossible, and the
planned EAI experiment might still limit its scope to local parts in
addresses (excluding Message-IDs).
Archived-At has "intended status: standards track", not "experimental".
=== 3rd detail ===
The source of <unstructured> isn't obvious for readers, I guess you
talk about <unstructured> as in RFC 2822. Why not simply specify the
85 possible URI characters ? With that you'd get something like:
~~~ old ~~~
"Archived-At:" [FWS] '<' unstructured '>' CRLF
~~~ new ~~~
"Archived-At:" [FWS] "<" [FWS] 1*( 1*uri-char [FWS] ) ">" CRLF
uri-char = unreserved / reserved / pct-encoded ; compare RFC 3986
~~~ end ~~~
Sanity check, we need to find 128 -32 (C0) -1 (SP) -1 (DEL) = 94
unreserved is ALPHA (52) + DIGIT (10) + "-","_","~","." (4) = 66
reserved is gen-delims (7) + sub-delims (11) = 18
pct-encoded is "%" (1) + 2HEXDIG (already covered) = 1
Illegal VCHARs: '"', '<', '>', '\', '^', '`', '{', '|', '}' = 9
Please make sure to cc: me personally
As long as it's an ASCII-address no problem. :-)
Frank