> Here are some additional remarks: > > o Two forms of solicitation tags are used interchangeably in the draft: > net.example:ADV and net.example.adv. While both are translated to the same > domain name, which is the correct form?
Both are valid. > > o Is the colon mandatory? No, and for the ddds app, one does s/:/./g as part of the first well-known rule. > > o The script suggests that a name example.com:FOO.Bar is translated into > Bar.FOO.example.com -- is that the intent? Yes. > > o The draft does not mention various syntax restrictions for the tags > resulting > 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. > > o While the presence of the "_" should not lead to problems during NAPTR > resolution, it may confuse operators (dto absence of restrictions for "-"). > > o The draft mentions the "registrant" where the better term would be zone > maintainer (or owner), since a registrant only appears at the highest > "registration" level. One could argue that the 3rd level domain is > "registered" at the 2nd level, but that's confusing the term. Unfortunately > 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". > > 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. > > o Are the solicitaion class keywords expected to be related to the sender's > domain name, the recipient's or a third party's? Do "users" of this scheme > thus have to deal with NAPTR RRs? > Nobody has to deal with NAPTR RR's, but this does give the UI designer the ability to do lookups. However, a solicitation class keyword might come from the sender, it might come from somebody else. For example, a policy maker might require the use of gov.example.adv, the sender might do com.example.iwanttoselltoyou, a voluntary industry group might allow the use of org.example.betterbusinessburea, and the very sophisticated marketer might even include a special label that the recipient has invented to get past filters. So, the answer is all of the above. > o The wildcard discussion > > Wildcards are appropriate for this application, allowing multiple > solicitation class keywords that share a common prefix to all point > to the same URI > > seems to encourage the use of wildcards to solve the provisioning issue. > A big caveat text might be appropriate then. > 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. ) Let me know if I've answered your questions ... I'm hoping not to revise since we're so far along, but if that's what it takes, I'm happy to do so. With a couple small exceptions, I read your queries all as request for clarification, not revision, but I may have been overly optimistic. :) Regards, Carl . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
