Tuesday, March 09, 2021
Christmas in March—The Clockwork Gift
On Christmas, one of the gifts I received from Bunny was a small flat box, about 7″ by 7″ and an inch thick—perhaps a CD, but it was no CD. No, there was a small grey pouch with a clock winding key, and two pictures of a grandfather clock (technically, a “grandmother clock” as it's not quite 6′ (2m) in height; both are a type of “longcase clock”).
“It's currently being restored,” said Bunny. “So sorry it's not here in person.”
“Wow!” I said. “It looks just like the one I had as a kid!” Yes, it's true. I was the only kid I knew in high school with a longcase clock in their room. It belonged to my maternal grandparents. When my grandfather died and my grandmother moved in, the clock came with her. My Mom wasn't all that keen on clock, what with all the constant ticking. I, on the other hand, loved it. I did not mind the ticking at all (and that probably explains why I don't mind using the IBM Model M keyboard).
After my Mom died, my uncle (Mom's brother) came down to help move his mother to live with him, and he ended up taking the clock as well. Sigh.
Bunny knows I have a thing for grandfather clocks, as I tend to fawn over them when we're antique window shopping. So it's wonderful that she decided to get me one for Christmas, even though it wasn't here on Christmas.
Josef & Joseph certainly took their time with the restoration, but they wanted to make sure not only it worked, but it worked flawlessly! It finally arrived at Chez Boca today.
![[A grandmother clock from Colonial Mfc. Co.] I'll take this tick tock over TikTok any day.](/2021/03/09/longcase.jpg "I'll take this tick tock over TikTok any day.")
Oh, there were plenty of logistics in getting it home. And way more in getting it set up, spending way over an hour getting various shims under the feet of the clock to get it level. It turns out that even out by 1° from true will eventually bring the pendulum to a stop, and the chimes won't always strike true.
So now it's quietly ticking away (and it's not nearly as loud as one would expect), keeping time quite nicely. It's a nice feeling to know I'll have a time-keeping piece that will survive the next Carrington Event.
Wednesday, March 10, 2021
Notes on an overheard conversation while passing by a building
“Oh! That building is so hideous! It's … what? Monstrous?”
“Brutalist.”
“That's it! Brutalism!”
“But it's not quite Brutalism.”
“No, this building has windows.”
Thursday, March 11, 2021
Place your bets!
I just checked my Gmail account and I received an update on the Mt. Pfeiffer situation five days ago—apparently it is still melting so I guess there's still time to place a bet as to when it will ment completely away.
There's also about 50 recipients to that email, and I'm wondering if I'm supposed to be related to the other four Conner's who received this email. I supposed I should notify the sender, especially given this disclaimer at the bottom of the email:
This message is intended only for the use of the addressee(s) and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not the intended recipient(s), you are hereby notified that any dissemination of this communication is strictly prohibited.
If you have received this communication in error, please erase all copies of the message and its attachments and notify us immediately.
Your email address and contact information will be stored within XXX's Customer Relationship Management platforms (CRM) and Communication Management Systems and may be used by XXX for lawful business purposes. XXX does not share or sell your contact information. Details about how we use your information and your rights are contained within our Privacy Policy (click here to view our Privacy Policy).
But if I notify the sender of their mistake, I won't get closure! I'm now emotionally attached to Mt. Pfeiffer's fate! Oh the dilemma!
Wednesday, March 17, 2021
Is there a reason for an indulgence of lepcrechauns on the front lawn? And who replaced the grass with clover?
I'm in the Computer Room. Bunny is in the family room watching TV. I suddenly hear a tune that sounds eerily familiar—I know this music! It's from a TV show, but I can't remember which one. I rush out, only to find it's a commercial using the music.
Darn!
But it's so familiar! I grab my phone and fire up Shazam. “Excuse me,” I say, as I grab the remote from Bunny to rewind and watch the commercial over again. Shazam listens, and then says “Dave Allen At Large.”
That's it!
Dave Allen was an Irish commedian and my friend Bill and I would watch his TV show when we were in high school. I haven't thought about him or his TV show in years! And yet for some odd reason, I was reminded of him today.
I wonder if it has anything to do with the lepcrehauns on the lawn?
Oh, I've got to go—dinner is ready, corned beef and cabbage—wait a minute …
Thursday, March 18, 2021
Leave it to the phone companies to make simple ideas complex
These telephone DNS records are typically expected to contain a record with the type NAPTR. NAPTR, generally speaking, is intended to map addresses (more properly URNs) to other types of addresses. For example, E.164 to SIP. So the NAPTR record, typically, would provide an address type of E2U+sip which indicates ENUM (E.164 number mapping) to the SIP protocol.
Fascinatingly, the actual payload of an NAPTR record is… a regular expression. The regular expression specifies a transformation (with capture groups and the whole nine yards) from the original address (the E.164 number) to the new address type. In theory, this allows optimization of NAPTR records at higher levels of the hierarchy if components of the original address are also used in the new address. This is one of many areas of DNS that are trying perhaps too hard to be clever.
Computers Are Bad: can I get your number domain
I'm very surprised I haven't mentioned NAPTR records before, because I have to deal with them at The Corporation. The service we provide to our customers, the Oligarchic Cell Phone Companies, is to translate a phone number, such as “867-5309” to “Jenny,” and that is done via DNS using NAPTR records. I was surprised at first, because I was expecting the Oligarchic Cell Phone Companies to use some esoteric and proprietary protocol to handle such information, but nope—it's via DNS. One complication here is that each phone company keeps its own database of numbers to names, and you have to negotiate with, and more importantly, pay, each one to query their data. Now, because The Corporation has all these contracts in place, all an Oligarchic Cell Phone Company has to do is pay us to get access to the name databases of the other Oligarchic Cell Phone Companies.
A classic middleman situation here.
But getting back to the article. The author uses the example
+18002662278 as an example of an E.164 global number (where
E.164 is a standard from ITU), but the example is a bad one, because 800 numbers are
not global numbers! You can only dial 800 numbers from North
America, so to present +18002662278 as a global number is
incorrect. This is an issue for us, because Project: Sippy-Cup has to deal with both global and
“local” numbers (where “local” means—intra-country code calling). and yes, we
get a ton of 800 numbers sent in as global numbers (then again, we get an
amazing assortment of garbage numbers from the Oligarchic Cell Phone
Companies, including all zeros, all ones, numbers with international dialing
prefixes, short codes, service codes, and it wouldn't surprise me if we get
ZIP codes from time to time—you'd
think the Oligarchic Cell Phone Companies would filter out such garbage, but
hey, they're the Oligarchic Cell Phone Companies, they don't have to
care).
I also agree with the author about the use of regular expressions in the NAPTR record. It complicates the spec and in the decade I've been working at The Corporation, I've yet to see anyone use the regular expression transformation, and in the source code parse NAPTR records is this comment from the original developer: “Skip the insanely stupid regexp pattern; we are ignoring it.”
The name lookups are not using the “E2U+sip” addressing, but
“E2U+pstndata:cnam” addressing, based off a draft
standard from twelve years ago. And reading that specification is a hoot
in the light of the harsh reality of … um … reality. It defines the
pstndata: scheme as:
pstndatauri = "pstndata:" datatype ["/" telephone-
subscriber ] ";" content
datatype = "cnam"
; Other datatypes can be defined by adding
; alternative values.
content = [ mediatype ] [ ":base64" ] "," data
mediatype = [ type "/" subtype ] *( ";" parameter )
data = *urlchar
parameter = attribute "=" value
where "telephone-subscriber" is imported from RFC 3966
[19], "urlchar" is imported from RFC 2396 [20], and
"attribute" and "value" are imported from RFC 2045 [21].
LIES! ALL LIES!
Okay, it's not quite that bad, but having dealt with all three
RFCs mentioned, I'm not sure the
author of the specification carefully read the them, or considered deeply how
they might interact. The definition of telephone-subscriber
contains not only the “phone number” but also parameters separated by
semicolons! I have code to parse telephone-
subscriber but I can't use it here because in reality, it
conflicts with this definition (why yes, the whole notion of parsing this
data came up recently at work, why do you ask?) It's always fun when reality
trumps theory (no, not really).
So as the author states, “DNS does handle phone numbers!” But it's not quite as simple as IP addresses.
