John,
I appreciate your points. I understand that there are tradeoffs. Perhaps
we do need community input on this.
Normally I copy the wg on genart reviews. Since there was no wg here I
didn't do that, and forget to copy the Last Call list. How do I fix that
and include your reply? Should further community discussion occur on the
last call list, or is something more bounded better?
More inline below.
On 9/17/23 2:34 PM, John C Klensin wrote:
[snip]
The EMAILCORE WG got hit by that problem while working on
draft-ietf-emailcore-rfc5321bis which, among other things,
specifies most of what appears in that Mail Parameters registry.
It is particularly important for email because there has been a
history of implementations and providers making up their own
stuff and not bothering to register. Most of the relevant
registries have traditionally specified standards track or
IESG-approved Experimental, which is clearly too high a barrier
to entry for anyone who does not want to take the time or who
just does not want to mess with, or recognize the authority of,
the IETF or IANA. It isn't clear that Specification Required is
a much lower barrier, especially for that second group or if the
Designated Expert initiates a community review. If one wants
no, or absolutely minimal, barriers, then only FCFS will do. On
the other hand, there are implementers and designers who still
think that the IETF is useful and that a serious community
review could improve the details of what they want to do. So
the plan, and the one preferred for name-value pairs for SMTP
LIMITS, if that the registrant picks between FCFS (with minimal
requirements for documentation or anything else) and full
standards track review, including the documentation requirements
for the latter. The registry would then indicate which one was
chosen and potentially contain different information for the two.
See Section 8 of draft-ietf-emailcore-rfc5321bis-19 or
draft-klensin-iana-consid-hybrid for different takes about how
the above might be specified, but with the understanding that
the right way to approach this would be in a revision to RFC
8126/ BCP 26.
My philosophy on registries is that
1) Documents referencing a registry need to be absolutely clear where
the registry can be found. (I want to be able to use what is in the
document to search and find the right registry the first time!)
And the registries themselves need to:
2) Provide sufficient info so a developer implementing a spec can
discover all specs relevant to him by following references, including
references to registries. (So we don't require the developer to be psychic.)
3) Give enough information to screen out most entries that aren't
relevant to a developer's task without reading the associated document.
(This is most important when there are many entries in the registry.)
I'm troubled by FCFS registries that don't provide enough information to
be understood by an arbitrary developer without prior knowledge. This
makes the item proprietary. I guess I'm ok with it if the intent is to
support proprietary features.
john
p.s. did you intend to copy the Last Call list?
Yes :-(
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
