Hi Jack,
On 03/08/09 23:26, Jack Schwartz wrote: > Hi Dave. > > After coding up the changes per RFC 3696, it occurred that in the past > I've used an underscore in the name without problems. I'm not sure > that's the right document. > > Meantime, I've found out that what this is used for is a multicast DNS > address. There is a document: > http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt Since we plan to introduce support for service discovery over unicast DNS in future, I think we should take into account restrictions applying to both (mDNS & uDNS). Looking at the document covering service discovery over DNS in general [1], I have found following paragraph which might help to clarify this. From this it seems that * from technical point of view, any UTF-8 character can be used in any part of DNS label including (but not limited to) service instance name, as "... the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose . " That said (and from last paragraph) * user is not obliged to support whole character set and it is allowed to pick up just a subset - in similar way it was applied for naming of unicast DNS domains. Jan [1] ... Service Instance Name = <Instance> . <Service> . <Domain> The <Instance> portion of the Service Instance Name is a single DNS label, containing arbitrary precomposed (Unicode Normalization Form C [UAX15]) UTF-8-encoded text [RFC 3629]. It is a user-friendly name, meaning that it is allowed to contain any characters, without restriction, including spaces, upper case, lower case, punctuation -- including dots -- accented characters, non-roman text, and anything else that may be represented using UTF-8. Although the original DNS specifications [RFC 1033][RFC 1034][RFC 1035] recommended that host names contain only letters, digits and hyphens (because of the limitations of the typing-based user interfaces of that era), Service Instance Names are not host names. Service Instance Names are not intended to ever be typed in by a user accessing a service; the user accesses a service by selecting its name from a list of choices presented on the screen. "Clarifications to the DNS Specification" [RFC 2181] directly discusses the subject of allowable character set in Section 11 ("Name syntax"), and explicitly states that the traditional letters-digits-hyphens rule only applies to conventional host names: Occasionally it is assumed that the Domain Name System serves only the purpose of mapping Internet host names to data, and mapping Internet addresses to host names. This is not correct, the DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose. The DNS itself places only one restriction on the particular labels that can be used to identify resource records. That one restriction relates to the length of the label and the full name. The length of any one label is limited to between 1 and 63 octets. A full domain name is limited to 255 octets (including the separators). The zero length full name is defined as representing the root of the DNS tree, and is typically written and displayed as ".". Those restrictions aside, any binary string whatever can be used as the label of any resource record. Similarly, any binary string can serve as the value of any record that includes a domain name as some or all of its value (SOA, NS, MX, PTR, CNAME, and any others that may be added). Implementations of the DNS protocols must not place any restrictions on the labels that can be used. In particular, DNS servers must not refuse to serve a zone because it contains labels that might not be acceptable to some DNS client programs. Note that just because this protocol supports arbitrary UTF-8-encoded names doesn't mean that any particular user or administrator is obliged to make use of that capability. Any user is free, if they wish, to continue naming their services using only letters, digits and hyphens, with no spaces, capital letters, or other punctuation. ...
