On 11/29/10 12:59 PM, Tony Finch wrote:
That's an informal description of the formal syntax defined in RFCs 608, 810, 952.
hierarchical names appear in 921, not 608 or 810, and 952 references 921.
I am confused. You say double hyphens were forbidden then you say they were permitted.
it would be wicked difficult to change something from forbidden to permitted if the underlying rational for the restriction were in fielded implementations which were interoperable over some ranges of test values.
on the other hand, anything forbidden by policy alone may be permitted, and permitted in a non-fictive sense, by a mere change of policy.
a restriction which may be relaxed is proof of (a) overspecification error in a mechanism specification, or (b) absence of specification in a mechanism specification, usually known as a policy statement.
a restriction which must be further restricted is proof of (a) underspecification error in a mechanism specification, or (b) a restriction of policy.
we seem to be discussing the first case, not the second, when discussing texts prior to liman's. we seem to be discussing the second case, not the first, and with no claim of underspecification of restriction of policy, when discussing liman's text.
I think your earlier message meant that before RFC 1123 the allocation policy did not exactly match the permitted syntax, e.g. double hyphens and single character labels were permitted by the syntax but not allocated; initial digits were not permitted by the syntax but were allocated (and eventually the documented syntax caught up with the policy). I also think you are agreeing with my argument that alpha-only TLDs are a policy matter.
i thought that was obvious, but yes, and more broadly, that over-constraint is a distraction at best, and potentially worse than a mere distraction. no one should have any illusions about the scope of error possible, as there are two roots right now, and managing the requirements for their increased divergence seems prudent.
and my preference is for no i-d at all at this point. i don't want to be in cartagena next week or san francisco next spring or ... and hear someone say "the ietf made us do it" for some unfortunate value of "it".
-e _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
