There's no "I" in IDN, part 10: Who needs IDN support? How much? When? (Part 2)

by Michael S. Kaplan, published on 2011/09/21 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/09/21/10214081.aspx


Previous parts in this series:

Let me see, was i in the last part talking about:

ISSUE 3: Can machine names support the full range of Unicode too?

This issue is the reason I put IDN in quotes -- because the only real connection it has to IDN is how many different services/applications on each machine -- like IIS or Terminal Services or Remote Desktop or SQL Server or whoever -- that uses the machine name by default.

In some cases, those services and applications have a way to create other names, and in some cases they don't.

But the fact that the default is so often the machine makes it compelling in the former cases and required in the latter.

For this issue, the support is incomplete.

This incompleteness is something I'll cover in the next part of the series.....

 This ISSUE #3 is a really good way to see there are four kinds of actual definitions of TRUTH for Windows/Microsoft technology:

Now in the ideal world, all four amount to the same thing; in practice this seldom the case.

Now the general problem is that there are two computer names to deal with: the NetBIOS name, and the DNS name.

NetBIOS, as is described in Wikipedia:

In 1986, Novell released Advanced Novell NetWare 2.0 featuring the company's own NetBIOS emulator. Its services were encapsulated within NetWare's IPX/SPX protocol using the NetBIOS over IPX/SPX (NBX) protocol.

In 1987, a method of encapsulating NetBIOS in TCP and UDP packets, NetBIOS over TCP/IP (NBT), was published. It was described in RFC 1001 ("Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods") and RFC 1002 ("Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications"). The NBT protocol was developed in order to "allow an implementation [of NetBIOS applications] to be built on virtually any type of system where the TCP/IP protocol suite is available," and to "allow NetBIOS interoperation in the Internet."

 Now those two RFC have e some contradiction in the NetBIOS naming rules, as described here and in the [MS-NBTE] protocol doc:

[RFC1001] and [RFC1002] are confusing with respect to the definition of the name syntax. [RFC1001] section 5.2 states: "The name space is flat and uses sixteen alphanumeric characters. Names may not start with an asterisk (*)."

[RFC1002] section 4.1 states: "The following is the uncompressed representation of the NetBIOS name "FRED", which is the 4 ASCII characters, F, R, E, D, followed by 12 space characters (0x20)."

It should be clear from the previous statement, because an asterisk and space characters are not letters or numbers, that the term "alphanumeric characters" is confusing at best.

This document clarifies the ambiguity by specifying that the name space is defined as sixteen 8-bit binary bytes, with no restrictions, except that the name SHOULD NOT<2><3> start with an asterisk (*).

Neither [RFC1001] nor [RFC1002] discusses whether names are case-sensitive. This document clarifies this ambiguity by specifying that because the name space is defined as sixteen 8-bit binary bytes, a comparison MUST be done for equality against the entire 16 bytes. As a result, NetBIOS names are inherently case-sensitive.

It is important to understand that the choice of name used by a higher-layer protocol or application is up to that protocol or application and not NetBIOS. A NetBIOS over TCP implementation MUST NOT enforce the use of the convention discussed in section 1.8.

Now that I think of it, Larry Osterman's How do I compare two different NetBIOS names? blog is helpful here for developer truths

As the SetComputerNameEx docs point out how by convention the NetBIOS and DNS names are linked and problems with breaking he link:

ValueMeaning
ComputerNamePhysicalDnsDomain

Sets the primary DNS suffix of the computer.

ComputerNamePhysicalDnsHostname

Sets the NetBIOS and the Computer Name (the first label of the full DNS name) to the name specified in lpBuffer. If the name exceeds MAX_COMPUTERNAME_LENGTH characters, the NetBIOS name is truncated to MAX_COMPUTERNAME_LENGTH characters, not including the terminating null character.

ComputerNamePhysicalNetBIOS

Sets the NetBIOS name to the name specified in lpBuffer. The name cannot exceed MAX_COMPUTERNAME_LENGTH characters, not including the terminating null character.

Warning: Using this option to set the NetBIOS name breaks the convention of interdependent NetBIOS and DNS names. Applications that use the DnsHostnameToComputerName function to derive the NetBIOS name from the first label of the DNS name will fail if this convention is broken.

And then there is the crucial bit, from the [MS-NBTE] protocol doc:

5. If the NetBIOS name from the LMHOSTS file is less than 16 bytes in length, pad the name with spaces, and uppercasing all characters within the ASCII range which results in ComputerName.

Note that the letters A-Z are changed by an UPPERCASING operation, which means that if the casing rules specified here are used any population of the naming table then the biggest concerns developers have told me about the OEMCP dependencies that affect casing are not true (since A-Z are the same on every OEMCP). Though this point is not entirely clear and unless someone reviewed actual code I'd frankly be suspicious anyway.

Especially given that the original NetBIOS spec required case sensitivity and even old NetBEUI specs have the same rules (after uppercasing).

Also note the UI to allow computer name change includes the ES_OEMCOVERT flag (see Raymond Chen's What is the deal with the ES_OEMCONVERT flag? blog on how crazy *that* flag is, because even in current UI the owners don't  want to remove the ES_OEMCONVERT as they are worried on the unclear impact on the OEMCP on NetBIOS that one feels comfortable changing.

So even the end the fact that DNS names are tied to the NetBIOS names which may not be the impacted as much as anyone thinks when one sticks with the Unicode version of DnsHostnameToComputerName function (DnsHostnameToComputerNameW) and the ES_OEMCOVERT usage.

And thus the machine name namespace is sharply limited until:

The only happy ending to all of this is that this is that there are ways to limit the impact of the computer  name issues hemorrhaging into other areas....

Oh, and the fact that functions like the DnsValidateName function have text like this:

Note  If DnsValidateName returns DNS_ERROR_NON_RFC_NAME, the error should be handled as a warning that not all DNS servers will accept the name. When this error is received, note that the DNS Server does accept the submitted name, if appropriately configured (default configuration accepts the name as submitted when DNS_ERROR_NON_RFC_NAME is returned), but other DNS server software may not. Windows DNS servers do handle NON_RFC_NAMES.

So maybe one day we'll be better here...


Yuhong Bao on 21 Sep 2011 11:46 PM:

"in an  gg view "

What does that mean?

Michael S. Kaplan on 22 Sep 2011 12:01 AM:

great global? :-)


referenced by

2013/10/17 There's no "I" in IDN, part 19: There's no "I" in IPv6, either!

2013/10/08 There's no "I" in IDN, part 18: There isn't even an "I" in John C. Klensin's name!

2013/09/13 There's no "I" in IDN, part 17: EAI made it to China, and everybody knows it!

2013/04/19 There's no "I" in IDN, part 16: It's a good thing they decided to call it EAI!

2012/10/12 There's no "I" in IDN, part 15: Still no 'I' in EAI.... but we could use an US sometime soon!

2012/08/08 There's no "I" in IDN, part 14: It turns out there's no "I" in IE, either

2012/05/18 There's no "I" in IDN, part 13: Desktop and Managed and Metro; oh my!

2012/02/27 There's no "I" in IDN, part 12: Emoji + IDN == U+1F4A9 (PILE OF POO)

2011/10/25 There's no "I" in IDN, part 11: There's no place like ::1, not even 127.0.0.1!

go to newer or older post, or back to index or month or day