| Click here to select a new forum. |
| Did classic MacOS officially support other character encodings for AppleTalk's Name Binding Protocol? |
Posted by: NJRoadfan on 2024-07-29 19:15:51
This came up during my work on Netatalk. Officially, Netatalk 2.x allows one to display and create NBP entities and zone names in any supported character encoding (ex: MacHebrew, MacGreek, MacJapanese, etc.) The "official" documentation, Inside AppleTalk, is pretty quiet on this. It only provides information on MacRoman encoding in Appendix D and an extended character case mapping table. There are no mentions of alternative mappings. Prior to System 7.1 and WorldScript, support for international text was pretty limited in the OS, so I'm not surprised that there is little about this in Inside AppleTalk.
So, were folks in Japan naming their LaserWriters with kana? Were folks in Greece adding some Ω power to their Mac's name on the network? This could cause chaos, as NBP has no way of transmitting what encoding a name should be using. That Ω would display as ø on MacRoman systems! |
Posted by: cheesestraws on 2024-08-03 02:19:43
I was pretty sure it was all meant to be MacRoman originally, but I agree it's hard to find that actually stated anywhere - it more just seems to be a assumption. What the software actually does I don't know. Though I don't think it would cause quite as much chaos as perhaps you're thinking: networks were smaller and it's highly likely that all the Macs on a given LAN (at least for most deployments) would have had the same character encoding due to sheer geography. |
Posted by: Arbee on 2024-08-03 11:16:34
In practice the only place you'd likely find a multi-encoding AppleTalk network back in the day was probably Apple itself. But this does feel like the kind of detail that Apple would sweat, so I'm a little surprised the documentation is so quiet about it. |
Posted by: stepleton on 2024-08-04 01:49:58
I dunno --- consider an institution like CERN, where you have academics and specialists from all over the world. I can imagine there being a research group in the early '90s with a couple dozen researchers and technicians dedicated to a single experiment, everyone using an AppleTalk network for sharing stuff.
Or even a moderately-sized university with an international student body might encounter this. |
Posted by: NJRoadfan on 2024-08-04 08:33:02
Another thing to consider is alternate platforms. I think both the 8-bit Apple II and GS/OS AppleTalk stacks assume MacRoman encoding. I don't know about PC clients, but anything on DOS and Windows has to support converting from their native encodings to Apple's. I don't know if these assume MacRoman on the AppleTalk side of things too. |
Posted by: cheesestraws on 2024-08-05 10:08:23
Well, NBP doesn't communicate character encoding on names, so an assumption has to be made somewhere. There are only really two (and a half) possible situations:
- On a machine that doesn't live in a world with multiple character encodings in any organised way (e.g. Apple II), you just have to pick one and stick to it. I'd bet MacRoman in this case, but I haven't checked.
- On a machine which lives in a world with Mac-style multiple character encodings, it still has to pick one and stick to it. Is it valid for it to use the system encoding here, or does it default to MacRoman anyway? If the former, how do the special characters work? Are they just in the same place in all eligible encodings?
- The half-a-situation: on a machine which lives in a world with multiple character sets which aren't Mac-style, do you try to map Mac-style encodings to your local encodings? (this is what this feature in netatalk appears to be attempting). Or do you just use MacRoman anyway?
consider an institution like CERN, where you have academics and specialists from all over the world
Well, they can't have multiple character sets that all work properly - NBP doesn't carry character encoding with a name, so you either have to use a consistent character encoding across the whole network or someone's getting mojibake.
I suspect this is an artefact of NBP existing before the internationalisation stuff was really thought through, and then being stuck with backwards-compatibility nightmares. Hooray for tech debt. |
Posted by: pl212 on 2024-08-05 11:24:19
It's interesting -- System 7.1 was the first version that was "World Ready" with WorldScript, right? I wonder if there was any circa-1992 update to AppleTalk docs, or recommendations to not try anything crazy, at that time...
I think "someone’s getting mojibake" is simultaneously a rallying cry, a motivational goal, and an accurate description of outcomes for this kind of thing in the 1990s. |
Posted by: stepleton on 2024-08-05 12:08:16
Well, they can't have multiple character sets that all work properly - NBP doesn't carry character encoding with a name, so you either have to use a consistent character encoding across the whole network or someone's getting mojibake. That's my expectation! I meant to suggest though that it probably wasn't too unusual. People probably just tolerated it or fell back on whatever least-common denominator solution could get you to the files you needed. |
Posted by: pl212 on 2024-10-19 23:44:09
A zone is identified by a zone name, which can be up to 32 characters long and can include standard characters as well as AppleTalk special characters. To include a special character, type a colon followed by two hexadecimal characters that represent the special character in the Macintosh character set. Perhaps of interest, from:
https://www.cisco.com/en/US/docs/ios/11_0/access/configuration/guide/acat.html |
| 1 |