> > domain name, which is the correct form? > > Both are valid.
So, they seem to be equal, but what's the point in having the ':' then? RFC 3865 says: "The initial set of solicitation class keywords all begin with a domain name with the labels reversed, followed by a colon." Isn't that normative? > No, and for the ddds app, one does s/:/./g as part of the first well-known > rule. Sure, but if there's no semantic difference a comment to that regard could clarify this. > > from the use of the DNS: label length, overall tag length, unavailability > > of ".." (likewise "::", ":.", ".:"). Also, neither RFC 3865 nor this > > draft mention case insensitivity. > > 3865 does, I believe, restrict each part of a label to be valid, and does > deal with overall tag length and stuff. It says that the tag (or list of tags) may not exceed 1000 characters in length, but does not constrain the length to 253 characters or the label length to 63. Also it allows "an arbitrary set of characters drawn from the following construct", where you can't translate example.com:Foo::Bar into a valid domain name. > > this already happened in RFC 3865. > > Hmmm ... suggestions at this point on what I should do? Registrant came from > several folks because it implies "person with admin control and people whom > have been delegated that capability by the person with admin control". Zone administrator is a more neutral term because that applies at every level whereas "registrant" is ICANNish vocabulary for someone having registered a domain name with a "registry". "dissident.example.com" may be administered by an entity applying different policies than the entity responsible for "example.com". > > o solicitation class tags have a very restricted character set, especially > > they don't support non ASCII characters. In what form would IDNs be > > handled? Would "xn--" encoding also apply to the past-colon part? > > IDN sits in valid domain names, so each part of a label could in fact be > encoded in IDN. The colon is syntactically equivalent to a period, so the > rules apply to post-colon parts. But then I couldn't have "org.�ntisp�m:SP�M" in the header (not even properly MIME-Header encoded), but would have to write "org.xn--ntispm-9taf:xn--spm-rla". For the part left of the colon an application or library might help, but identifying the part after the ':' as a domain label is tough. > Doesn't really encourage them so much as say (along with other DDDS apps) > that they have a potential role and you should look to current best practices >. > At least, that's what I meant. :) (DDDS requires that I state if they > are allowed or not, so I did. ) NAPTR suffers from the subtyping problem, even more if applied at a zone apex or with wildcards - that's why I'd prefer them being explicitly discouraged. And wildcards are often abused to solve the provisining problem, i.e. to save the administrator the work to enter several predictable RRs into the zone. > couple small exceptions, I read your queries all as request for clarification Well yes, most :-) Thanks for your quick response. -Peter . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
