Re: [Ietf-message-headers] Permanent or provisional? (was: Jabber-ID header field)

[Bruce Lilly <[e-mail]>]

On Fri September 29 2006 05:16, Graham Klyne wrote:
> [This message is more about reviewing RFC3864 than the specific Jabber-id header]
> 
> Frank Ellermann wrote:
> >> Why not start with registration in the provisional registry
> > 
> > Permanent and RFC is better for MUA implementors.
> 
> Sure, ...
> 
> But, in general, I note that requesting a provisional registration in no way
> precludes moving later to a permanent registration.
> 
> And the barrier for provisional registration being so much lower (this the
> Jabber-ID draft would be sufficient), it's easy to get a record of its intended
> purpose published where developers can find it.  I would expect that a header
> destined for the standards track would be provisionally registered pretty much
> as soon as it is first published.

Agreed so far.

> In this case, it looks as things might move quite quickly, so going straight for
> the permanent registry saves some administration.

I'm not so sure -- there seem to be a significant number of issues that need
to be resolved; at minimum, starting with provisional would give interested
parties an opportunity to work out the bugs before moving to permanent, while
reserving the field name.

> I'd like to think it can be 
> done as soon as IESG approves the draft for standards-track publication.  Hmmm,
> checking [http://www.rfc-editor.org/rfc/rfc3864.txt]:
> 
> [[
>       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".

As 3864's primary co-author, you are of course in a better position than I am
to interpret the intent of 3864 as written.   That said, I read it as "RFC first
(with all of the discourse and review required for that), then assignment".
Indeed, all but two of the existing Internet Message Format field assignments in
the permanent registry are for fields which have long been defined in published
RFCs.

[The converse is another story; RFC 4021 omitted a number of RFC-defined fields.
Draft-lilly-legacy-fields is (was?) an attempt to resolve some of those, but it
seems to have gotten bogged down...  Those who look at the archive or who have
been watching this list since its inception may recall that that draft was
written in April 2005 as announced here.]

The case under discussion here differs from all of those legacy fields.  It is
also somewhat of a test case, as it appears to be the first non-legacy field to
be discussed on this list [Martin Duerst made an inquiry nearly seven months ago,
but that seems to have evoked no discussion].  I think the discussion is good; a
number of relevant issues have been raised.  Compare that to the two new Internet
Message Format fields that have been registered in the permanent registry without
discussion here; neither is particularly useful and both have either syntax or
semantics problems that might have been resolved had the fields been discussed
here.

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

"Discretion to approve" is fine, but there still needs to be an approved open
specification and a registration template.

BCP 90 (RFC 3864) also says that the registration templates should be sent to this
discussion list (section 4.3) or incorporated in a defining RFC.

Given the aforementioned issues, I'd prefer to see discussion here required even
if the registration template is (presumably subsequently) published in a defining
RFC.

_______________________________________________
Ietf-message-headers mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf-message-headers