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

[Graham Klyne <[e-mail]>]

Bruce Lilly wrote:
> 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.

[...]

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

(Maybe so:  initially, jabber-id was looking like a simple non-controversial
spec, so aiming for permanent was not an unreasonable aspiration.  But this
isn't really what matters here...)

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

Well, that's how I read the text, too!  But my perspective is that the *intent*
is served by having permanent registration allowed as soon as standards-track
publication has been approved.

> The case under discussion [...]  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].

Yup.  I can't recall if Martin was requesting provisional or permanent, though I
suspect it was the former, hence less scope for controversy.

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

Ack.  I think most of us who've worked with this process over any period
recognize the value of peer review.  Sometimes, though, it can be challenging
getting peers to actually do some reviewing ;)

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

Well, yes to all of that.  My presumption here is that the IESG won't depart
from the documented procedures unless there is a compelling reason to do so.

Don't forget that registration, even permanent registration, does not of itself
constitute a standard or even any level of approval.   It is entirely
conceivable that one may wish to put an existing escaped-to-the-wild header
field name in the permanent registry with a health warning saying "DON'T use
this".  (The additional effect of preventing registration of any header with the
same protocol/name combination would seem to be mostly desirable in such a case,
if only for the avoidance of confusion.)

#g

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

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