On 5/11/2018 7:41 PM, John Levine wrote:
I'd change all of the SHOULD to MUST, as in
you have to do this if you want to interoperate.
The working group should consider the choice of normative level, but
where I landed is that a MUST is not needed and actually could be
counterproductive.
Having an entry in the registry probably does facilitate
interoperability at scale, but it isn't (always) required for it. What
it /is/ required for is avoiding naming collisions.
Consider the long history of email header fields that weren't registered
but which interoperated quite nicely...
> (You don't have to
> do it if you have a private agreement, but private agreements are out
> of the scope of standards.)
I don't see the basis for saying that private agreements are out of
scope, on the matter of registration.
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.
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.
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...)
In section 3.1 on SRV it says about Proto "any name defined by
Assigned Numbers or locally may be used (as for Service)." Urrgh.
I'd say that any protocol whose name is in the attrleaf registry is
You appear to have quote the portion introduced with:
"The text of that specification is hereby updated from:"
which is taken from the existing SRV specification, and appear to have
missed the 'from', rather than focusing on the next set of text,
introduced with:
"The updated text is:"
which does not contain the text you find problematic.
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
ems
fax
ft
h323
iax
ical-access
ical-sched
ifax
im
mms
pres
pstn
pstn
sip
sms
unifmsg
vcard
videomsg
voice
voicemsg
vpim
web
xmpp
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?
this draft add a note that any new enumservice types added MUST be
added to this registry if URIs can refer to them. There's currently
24 type names. It happens that none of them collide with other top
level names but since they only apply to URI it wouldn't matter if
they did.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
