At 4:21 PM -0800 1/23/07, Jim Fenton wrote:
Paul Hoffman wrote:
Greetings again. One significant change in the new draft is the
addition in Section 7 of "In all cases, new values are assigned
only for Standards Track RFCs approved by the IESG." This change
came at the request of Cullen Jennings, an AD. In that request, he
says "Glad to talk about pros and cons of this", so I am Cc'ing him
on this thread.
This change precludes IANA from registering values for
IESG-approved Experimental RFCs, or IESG-approved
independently-submitted Informational RFCs. Normally, "standards
track only" is used in protocols where there is a limited-size
namespace, and "RFC only" is used in places where namespace size is
not a concern but there is a desire for a stable, long-lived
reference for every entry in the namespace.
Maybe we want "RFC only", not "standards track only", particularly
so that people can create Experimental RFCs and have them be used
in an interoperable fashion as a way of determining whether they
should later be elevated to standards track.
I generally agree with "RFC only", but haven't thought about all
eight of the registries that -base asks to have created. It's not
clear that we want to do this with all of them. For example, we
might want to set a higher bar for the signature or hash algorithm
than for creation of a new signature tag.
Why? These are just registrations. No one has to follow them if they
don't want. If they see something in the IANA registry that has an
RFC number different than the dkim-base RFC number, they will clearly
go read the spec before doing anything. If someone has done the work
to get something through the IETF process, or the RFC Editor process,
that indicates enough effort.
From our experience in IKEv2, having different levels of requirements
for different registries is just a headache.
--Paul Hoffman, Director
--Domain Assurance Council
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html