Re: [Emailcore] Ticket #8: Need a registry of header fields that are Ok to add after submission

[Dave Crocker <[e-mail]>]

On 7/28/2021 7:16 AM, Alexey Melnikov wrote:
> On 26/07/2021 17:18, Dave Crocker wrote:
...
>> Technical specifications or Applicability Statements, or the like, 
>> will contain the normative information about acceptable use of a 
>> header field.  Providing such information in a registry will, 
>> therefore, be redundant.  (Possibly adding the risk of divergence, 
>> over time.)
> 
> One of the main purposes of the proposed registry is to be able to find 
> a specific RFC that defines a particular header field. So the advice of 
> "just find the RFC" is not particularly helpful, considering how many 
> there are now.

Alexey,

I don't recall hearing anyone say anything like 'just find the RFC', so 
I'm not sure what you are referencing.

In the meeting discussion, I noted that I'd neglected to include the 
specification citation in the list of information that goes with the 
registry entry.  The /specific/ specification citation.

On reviewing my above "Technical specification or..." paragraph, above, 
I think I was not at all clear enough.  Attempting to fix that:

      Technical specifications or Applicability statements, or the like 
contain the relevant technical detail, including normative language.  A 
registry needs to point to such documents but should not replicate 
details from them.  Replication of details invites divergence.


> Also, the registry will contain header fields not necessarily defined in 
> an RFC (e.g. header fields already in use in the wild), which would 
> serve a useful purpose.

The choice of whether to allow registration entries that do not have a 
citable specification is obviously a strategic choice.  Since a main 
function of registration is to avoid collisions, there an argument for 
being permissive.

But the absence of a specification means that it won't be possible for 
folk to easily find out what the registered entry is used for; that's an 
argument for being more demanding.

For something like header-fields, the namespace is essentially infinite. 
  So my own preference is to require /some/ specification, but not be 
very demanding about the process for producing it.


> I don't think I agree about the risk of divergence: we will populate the 
> registry once for known header fields and then future RFCs will just 
> update the registry.

Right.  We don't have any issue with redundant details between RFC821 
and RFC822, or their successors.

My concern about divergence isn't really all that unusual.

My own lesson from 821/822, and similar examples, is to specify 
normative information in one place and everywhere else to just cite it 
(albeit somethings offering a terse bit of prose to summarize, but in a 
way that can't be taken as normative.)


> As our community will know about existence of this 
> new registry, I don't think it will be likely that RFC authors will 
> forget to update it.

"Our community" is large and diverse and often doesn't know about 
details others consider important.

Hanging around an industry email trade association is educational, for 
seeing what technical information people in the industry do and do not have.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net