I don't want to rathole on MUST vs. SHOULD because the more I think about
it the less I understand the difference.
Consider the long history of email header fields that weren't registered but
which interoperated quite nicely...
Sort of. Everything interoperated fine in the sense that we ignored x-
headers that we didn't understand but the number that were created by one
system and parsed by another is pretty small. I can only think of x-face
which worked because there was a clear spec even though it never made it
to IANA.
The best I can guess is that there is an underlying assumption that normative
language only applies to formally published specifications, but there's
nothing in the current draft language to support that.
No, it's that standards are about interoperating with people you don't
know. That was the point of the two-implementation rule. This particular
situation is unusually squishy because we have a list of protocol names
and a list of enumservice types that aren't in the registry but in
practice it'd work fine if someone used one of them because none of the
names currently conflict.
Note that SHOULD really is the same as MUST, except it allows for a 'unless
you really know what you are doing'. That, it seems to me, is exactly right,
for this issue.
Except that in reality people violate MUST all the time, often for good
reasons. This is why I don't understand the difference any more.
In section 1 you might want to add a sentence or two pointing out that
every rrtype has its own _name namespace, something that took a lot of
us quite a while to figure out.
I'll urge not doing that. Yes, it's a mathematical truth, but it's one that
I believe some/many other folk will find confusing in practical terms. (I
know I certainly did...)
Then it should be more than a sentence or two, long enough to explain it.
It needs to be clear people who might register future names that if _foo
on SRV and _foo on TXT mean different things, that's not a problem.
You appear to have quote the portion introduced with:
"The text of that specification is hereby updated from:"
Oops, never mind.
For URIs, I'd add all of the existing enumservice type names to the
draft-ietf-dnsop-attrleaf initial name list in section 3.1, and in
I'll guess that you mean the existing entries in the 'type' column of:
https://www.iana.org/assignments/enum-services/enum-services.xhtml
which appears to be:
acct
email ...
which seems quite a lot of pre-loading, for an RR that has almost no use, so
far. I would instead suggest pre-loading only those 'type' values we know to
be already in use and press for additional entries when they will get used.
This is what we've done for Proto, so why not the same approach for
enumservice?
I suppose that's OK. Do we have any idea of what the handful of URIs in
the wild actually use?
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
