Re: informal last call for draft-duerst-archived-at-06

Frank Ellermann 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-...

I think a distinction needs to be drawn here between *registration* and
*standardization*.

RFC3864 [http://www.rfc-editor.org/rfc/rfc3864.txt] is silent (by intent, if my
memory serves) on the issue of name formats, since it seemed to serve no useful
purpose to place arbitrary constraints on name forms.  In particular, it is the
*protocol* standards that circumscribe what can and cannot be a (standard or
otherwise) header field.

Of course, the email protocol specifications prohibit the *standardization* of
X- header field names, so that effectively precludes their inclusion od X-... in
the permanent header registry (as email header fields).  But I see no reason why
the X-Archived-At header should not be included in the provisional registry --
indeed to do so seems to me to be entirely in accord with that registry's purpose.

...

My nit here is that it's not clear from the templates or immediately surrounding
text in [http://www.ietf.org/internet-drafts/draft-duerst-archived-at-06.txt]
whether permanent of provisional registration is being requested.  The template
forms in RFC3864 include the text

   PERMANENT MESSAGE HEADER FIELD REGISTRATION TEMPLATE:

or

   PROVISIONAL MESSAGE HEADER FIELD SUBMISSION TEMPLATE:

I wouldn't insist on that exact form, but I think the IANA considerations
section should make it clear what is being requested.

> 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:

I think provisional registration of X-Archived-At as "deprecated" (as requested)
is more useful in this case.

> | 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".

Responding to the last paragraph only -- I'm not sure how it relates to the
preceding text -- I think that the "experimentation" has been fully conducted by
W3C and their mailing lists using X-Archived-At, so I'm not sure why one would
consider "experimental" status at this time.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact