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:

• part 1: If you're not Unicode, you're just wrong!
• part 2: Try not to use the wrong functions!
• part 3: There's no "I" in DIY, either!
• part 4: the 'path' to Hell is paved with IDN bugs
• part 5: Stephen Colbert's job is not in any jeopardy
• part 6: It isn't like there's an "I" in EAI, either!
• part 7: IDN comes to AdWords 
• part 8: Punycode don't do the PUA
• part 9: Who needs IDN support? How much? When? (Part 1)

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:

• The actual read-world truth, which is enforced by the real world;
• The developer experience of how things work, which is enforced by the collective developer community;
• The MSDN/TechNet documentation, which is created doc doc writers informed be specs, that periodically are updated by bug reports;
• The Windows/Office Protocol Documents, which were overseen by principal and partner architects in an grander view of product details.

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:

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:

• Real test work to ignore the warning to keep the DNS and NetBIOS name linked, combined with
• Strongly push to fix bugs in the components like the network stack and Active Directory to minimize the risk of people who want to do this split with special attention on removal of DnsHostnameToComputerName dependencies in IPV6 scenarios since NetBIOS is not available than anyway, making the dependency artificial and
• A strong push to allow alternatives to the "default to the computer name" scenarios until/unless these other problems are resolved.

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:

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

referenced by

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