On Sun, 2004-06-13 at 05:27, Hallam-Baker, Phillip wrote:
The bottom line is that RFC 1464 was a syntax proposal design
to simplify information sharing. A registry was proposed to
control name collisions, but that never happened. It still
seems to be a reasonable approach and perhaps someone will
put it back on the standards track someday if appropriate.
I agree with most of the idea, but I don't agree with the
registry part.
According to ICANN, IANA is costing $700,000 a year to
maintain. I think it is time to either look at why it
costs so much and work to reduce it, or start looking for
engineering designs that do not depend on registry functions.
Whether there are too many people maintaining the registry information
is separate concern from whether a registry is needed. Moving Protocol
Number Assignment to a function of the IETF rather an IANA is a decision
well beyond the scope of this group. A registry is a vital function
that must be employed to ensure the function of past and future
protocols.
In the case of DNS RR prefixing there is no real problem
since the possible name space is essentially unlimited.
The chance of accidental collision is minimal.
The value that a registry would provide is as a concordance.
As there are already protocols using text records to store random
strings, collision avoidance is depending upon labels. The problem is
uses of a label as a sub-domain is prone to collision irrespective of
the differences of the labels as a result of wild cards, as there would
be motivation for using such a mechanism regardless of how it was
specified.
The engineering way to deal with this problem would be to move
to a competent document format such as XML, assign all
code points automatically from a dictionary and build the
concodances and indexes automatically from the documents
themselves.
A concordance, (a registry) would need to encompass not just the
specification being developed, but other specifications either in
progress or already in use. There would need to be agreement where this
information is to be centralized and arbitrated, and it would need to be
kept current and updated. You imply such specification is free from
conflict but that is hand waving. Just as using a domain name is not
free from conflict as it could have been owned by prior entities where
previous history is unknown without a registry.
This is somewhat over-engineered for our case since we
already have a unique key, the group name is in theory
unique over time.
Work group names were never ensured not to conflict with anything but
work groups. In addition, these groups expire and are no longer a ready
reference.
Using _MARID as the prefix is practically guaranteed to
be accidental collision free.
As a label, it would not be free from conflict even if indeed no other
protocol used the label. As a token, it is already in conflict with
random text strings.
Adding the protocol identifier to the base prefix is
arguably an improvement, since we might use _SMPT._MARID.
Again as a label, this offers little assurance. Using more characters
for a token embedded in the text reduces chances of a collision, but so
would an embedded checksum of the entire record where such chances of
collision would billions of times less using just 8 characters. It
would also ensure the TXT record would be generated as a result of a
script that would likely perform format checks in addition to
calculating the checksum. A checksum can defend against random strings.
To allow future protocols the use of same mechanism, a registry is still
needed. It has already been proposed the XML header is not included
within the TXT record, such that XML registries offer no benefit as this
information is virtual and too bulky for DNS.
-Doug