[ Charset ISO-8859-1 unsupported, converting... ] > > > 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?
Um, yes, that would be normative. :) That's an artifact of the previous drafting process for 3865 (we thought we were using an iana registry and then moved to the reversed domain name issue. Let me address this specifically. > > > 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. Will do. > > > > 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. > Hmmm ... let me figure out how to deal with it. A valid point. > > > 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". Not a problem ... I can clarify this. > > > > 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. OK ... I do see the issue here. Let me consult with a couple of people who are more idn literate than I am and propose an answer. I think the answer is s/:/./ then apply IDN, but I hear what you're saying on the ambiguity and I think this may require a sentence explaining what to do if you're going to use the naptr-based scheme in conjunction with 3865. Again, I think there is a clean solution, but let me make sure it works. > > > 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. > I can add a note explaining that issue, but I'd like to come down in favor of wild cards. That said, I think the issue needs to be clearly stated. Regards, Carl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
