Graham Klyne | 8 Nov 14:07

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

(Continue reading)

Frank Ellermann | 8 Nov 18:15
Picon
Picon

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


Graham Klyne wrote:

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

Point - that solves my first nit, X-Archived-At can be registered, but not
with "Status: standard".  Martin's draft proposes a "Status: deprecated",
so far that should be okay.

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

ACK, your concept is better than my "impossible".  With a provisional entry
and "Status: deprecated" at the same time folks are free to (ab)use this
X-header-field for completely different purposes.  If they're smart they
don't do this or at least wait some years, but that's another issue... :-)

>> === 2nd point ===
[...]
>> 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.
(Continue reading)

Graham Klyne | 8 Nov 22:45

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


Frank Ellermann wrote:
> Graham Klyne wrote:
> 
>> I think a distinction needs to be drawn here between *registration* and
>> *standardization*.
> 
> Point - that solves my first nit, X-Archived-At can be registered, but not
> with "Status: standard".  Martin's draft proposes a "Status: deprecated",
> so far that should be okay.
> 
>> 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.
> 
> ACK, your concept is better than my "impossible".  With a provisional entry
> and "Status: deprecated" at the same time folks are free to (ab)use this
> X-header-field for completely different purposes.  If they're smart they
> don't do this or at least wait some years, but that's another issue... :-)

:)  No argument from me.

>>> === 2nd point ===
> [...]
>>> 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
(Continue reading)


Gmane