[Ietf-message-headers] Re: Permanent or provisional?

Graham Klyne wrote:

> in general, I note that requesting a provisional registration
> in no way precludes moving later to a permanent registration.

Yes, Martin's Archived-At could have been an example for this
procedure (if "could have been" is English, I hope it's clear).

Compare <http://article.gmane.org/gmane.ietf.rfc822/10973>, the
first of 20 articles here on this list from my POV.  At this
time GMaNe did not yet support Archived-At.

That didn't make it into the provisional registry.  Maybe IANA
didn't get the mail, or Martin forgot to send it after the two
weeks.

The "designated expert" part of RFC 3864 apparently also didn't
make it to IANA so far, their "assignments" page says "(need to
fill in)" in <http://www.iana.org/numbers.html#M> for RFC 3864.

Possibly the IESG simply forgot to appoint an expert.  Without
that IANA is lost.  For the http header fields they now have
both provisional _and_ permanent registrations.  IMHO that makes
no sense for _identical_ specifications (in this case RFC 4229):

<http://www.iana.org/assignments/message-headers/prov-headers.html>

To see what happens I've now submitted Archive-At for netnews
claiming that it already exists for mail (CC to Martin because
he's the change controller of his I-D).

> I would expect that a header destined for the standards track
> would be provisionally registered pretty much as soon as it is
> first published.

Yes, obviously it's a good idea to get feedback about issues like
the RFC 2822 <specials> - certainly more relevant than the rather
esoteric pending "[FWS] CRLF" erratum.

> [[
>   The assignment policy for
>   such registration is "Specification Required", as defined by RFC
>   2434 [3], where the specification must be published in an RFC
>   (standards-track, experimental, informational or historic), or as
>   an "Open Standard" in the sense of RFC 2026, section 7 [1].
> ]]
> That text is a bit limiting... maybe also add ", or has been
> approved for such publication".

Jabber could be special, they are their own SDO. but apparently
the header field draft is no JEP <http://www.jabber.org/protocol/>

Maybe limit the "approved for such publication" to the case of
RFCs.  For other document series like JEP or this obscure PICS
header field nobody knows or cares how their "approval" works.

> Looking over the text I'd also be inclined to indicate more
> explicitly that the IESG also has discretion to approve
> registration of any entry in the permanent registry, to avoid
> potential wrangling over such small points.

For permanent entries specified in IETF RFCs that's no issue,
if they don't like it why would they approve the RFC ?  For
independent RFCs or other standards it's an idea.  Maybe the
designated expert could handle this.  The IESG shouldn't be
forced to offer their speculations about the merits of header
fields defined by other SDOs, that could be a conflict of
interests.

Frank

_______________________________________________
Ietf-message-headers mailing list
Ietf-message-headers@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-message-headers