Soil and "Pimp" Sessions

Soil and "Pimp" Sessions is a Japanese jazz band that I've taken quite a liking to. I first learned about them when they released a single with Shina Ringo called "カリソメ乙女" (Karisome Otome) back in 2006. They have had a number of videos on YouTube which I enjoyed, but I just couldn't get my hands on one of their albums. It doesn't look like they have a distributor in the U.S. and none of the record stores I visited in Japan stocked them either.





So you can imagine my surprise and delight when iTunes started carrying their albums around November of last year. The U.S. iTunes store even. I've since stocked up bought 20 or so songs of theirs and have yet to be disappointed. The best I can tell, the U.S. iTunes store is selling all of their albums.

To top it all off, Shina Ringo's latest album, 三文ゴシップ (sanmon gossip) not only includes the 2006 Karisome Otome single, but includes another awesome collaboration　with Soil and Pimp Sessions: マヤカシ優男 (Mayakashi Yasaotoko). There isn't a video for it, but you can preview the song on YouTube. Don't worry, the lyrics for this song are all in English.

Even though they are a Japanese band, since it is jazz, most of the songs have no lyrics. That said, What few words there are do tend to be English. Which makes them a very approachable band to international audiences. In fact, right now they are in the middle of a European Tour. They have a live show schedule on their web site; I know I'll be watching to see when they come to San Francisco.

Back in California

Well, we're back in California and getting settled in. I had a month off to get moved out of our place in Tokyo and moved into our new place in Mountain View. It has been a hectic month but the last few days have been relaxing. That said, I'm ready to get back to work.

Anyway, I've got a whole backlog of things I've been meaning to blog about so hopefully I'll be a little more frequent with the updates for a while.

No place like home

Well, I've wrapped up my time here in Tokyo and preparing to move back to California. Barring a few small obstacles -- like just noticing that our passports had expired and frantically visiting the U.S. Embassy to get new ones -- we should be back in the U.S. by this time next week.

My coworkers gave me a nice farewell party which was quite fun. I'm not sure why, but I got pretty choked up on my last day at the office. I'm sure part of it was the relief of finally going home, but a lot of it was that I really liked my coworkers. They were the best part of working in Japan.

This past week I've had more time and finally gotten a chance to see more of the neighborhood where we have been living. It is actually a pretty nice area. It is a shame that it took over 2 years before I could actually enjoy it. Nonetheless I'm really looking forward to going home.

Yattsuke Shigoto

My friend Matt introduced me to a Japanese singer/songwriter named Shiina Ringo a few years back. I've taken quite a liking to her music, but one of her songs has really grown on me since I've been in Tokyo. It is a song called 「やっつけ仕事」(Yattsuke Shigoto), which means a job done half-assed. For me, the lyrics reflect the general feeling of apathy and soullessness that Tokyo seems to emanate. I guess it may be different for natives, but this song speaks to me. It speaks to me every time I get on the train and stair blankly off into the distance or pretend to sleep like everyone around me.

Feeling down today, I thought I would check to see if there were any English translations of the lyrics. All I could find was one terrible almost-literal translation that killed the voice of the song. So I whipped up a translation of my own (below).

I'm pretty confident that this translation captures the spirit of the song, even if I did stray from the literal translation by a wide margin on a couple of lines. The only line I'm not happy with is the one about the high-speed traffic jam. In Japan, if there is a traffic jam on a highway (which is literally called a "high-speed road"), they just say high-speed (road) traffic-jam, omitting the word "road". Hence producing the contradictory, "high-speed" traffic jam.

The only other part I'm not satisfied with at the pronouns. Japanese doesn't have pronouns and it isn't clear who is saying what in the song. I just assumed that everything was being said from a first-person perspective, since that is normally the case in most songs.

In case you are interested, the original Japanese lyrics are here. There are a couple versions of the song on iTunes also.

Yattsuke Shigoto - Shiina Ringo

Every day I'm assaulted by the ring of phones
I just want some peace and quiet

You call it a "high-speed" traffic jam, but isn't it slow?
I'm indifferent to reasoning contrary to reality

I can't think of anything good
But I'm not indignant about anything either
What day was it today?
I guess it doesn't much matter
Ah, all I want is something memorable

This consistency wears down my individuality
Maybe I'll just get an arranged marriage

Please control me
I hate boredom
When's the last Ginza-line train?
I guess it's not a big deal
Ah, I wish I could be a machine

Hey, what was "love" again?
I can't remember
I can't remember

I can't think of anything good
But I'm not indignant about anything either
What day was it today?
I guess it doesn't much matter
Ah, all I want is something memorable

Please control me
I hate boredom
When's the last Ginza-line train?
I guess it's not a big deal

I can't think of anything good
I can't think of anything good
I can't think of anything good

Hey, what was "love" again?

When Standards Collide

I can't help but shake my head in disappointment every time I run across some specification that is blatantly in violation of the standards it is built on. When I encounter a specification published by an ostensibly-reputable professional organization that contradicts my understanding of the underlying protocols, at first I'm confused. Is my understanding faulty? My memory bad (hint: it is)? Is there a new RFC that updated the protocol when I wasn't looking?

As a recent example, I finally got my hands on the WRIX Interconnect 1.03 specification from the Wireless Broadband Alliance. In which, they specify that partner ISPs must support "passwords up to 253 characters which contain a mixture of alphabetic, numeric, and special characters"; this is written in the comments for the the User-Password attribute in a RADIUS Access-Request packet.

There are two problems with this text that I'm amazed industry professionals did not correct (assuming they noticed):

1. RFC 2865 section 5.2 clearly states that the maximum length of the User-Password attribute is 130 octets, including the 2-byte attribute header. In other words, the encrypted password text cannot be longer than 128 octets. If this were the only issue, I'd be inclined to believe that the 128 octet limit has been relaxed in a later RFC.


2. Which leads to the second issue: RFC 2865 says the *encrypted* password text cannot be longer than 128 octets. Section 5.2 also lays out the encryption algorithm, which is a 16-byte block cipher. Being a block cipher, the password plaintext is padded out to a multiple of 16 bytes before the encryption is applied. Which means that a 7 octet password will encrypt to 16 octets of encrypted text. The 253 character password specified by WRIX would encrypt to 256 octets of encrypted text. RADIUS allocates 8 bits per attribute to represent the length of that attribute in octets, including the attribute's 2-byte header. So, if you have 256 octets of encrypted text, the total length of the attribute would be 258 octets.
   

So, in order to comply with the WRIX Interconnect 1.03 specification, it would appear you are required to violate both RFC 2865 and physics (to get 258 values represented with just 8 bits).

What baffles me is that I would have expected the difficulty of implementing the specification as written would have become obvious in compatibility testing. Surely someone has written unit tests based on the spec to test their implementation. At least once. Right? Right?

Anyway, I imagine the intent of the specification's authors was only to violate RFC 2865 and leave the violation of physics to the hardware guys. It looks like they wanted partner ISPs to allow the longest password representable by the User-Password attribute, ignoring the 128-octet stated limit. Since the encryption algorithm always produces encrypted text that is a multiple of 16-bytes in length and the longest encrypted text that can be stored in the User-Password attribute is 255 - 2 = 253 octets, the question is what is the largest multiple of 16 less than or equal to 253?

240. 240 octets.

Any plaintext 241 octets long or longer will encrypt to 256 bytes of encrypted data, which is not representable by a RADIUS User-Password attribute. So, a more reasonable specification would require implementers to support "passwords up to 240 characters which contain a mixture of alphabetic, numeric, and special characters."

Maybe in revision 1.04.

The Value of a Comfortable Office

As I sat at my desk sweating in the dead of winter, I got to thinking about how people's comfortable working temperature must be cultural. Offices are hot in Japan. In the summer, their CoolBiz campaign has businesses setting the thermostats to 28 degrees Celsius (82.4 degrees Fahrenheit). I just checked, it is winter and the thermostat in my office is reading 30 degrees (86 degrees Fahrenheit). In contrast, offices in the U.S. have traditionally been regulated to 72 degrees Fahrenheit.

I know my productivity suffers when I'm uncomfortable. It suffers doubly when I can only type with one hand because I'm fanning myself with the other. But is this just because of differences in cultural sensitivity to heat?

Out of curiosity, I did a quick search and found this interesting opinion piece written by Professor Shin-ichi Tanabe of Waseda University. Some of the interesting points in his opinion piece are:

• A guidebook recently published by the Federation of European Heating, Ventilating and Air Conditioning Associations (REHVA) reports that 21.8°C is the optimal room temperature to foster intellectual productivity.

  
  21.8°C is a little over 71 degrees Fahrenheit...almost exactly what offices in the U.S. set their temperatures too. Perhaps we have a hint why U.S. and European workers are the most productive in the world?



• ...28°C seems a little too high for a room temperature setting in summer. The most comfortable temperature when sleeping naked is 29°C. People burn more calories in the workplace than at home where they are more relaxed, and however casually they may dress, they are still not naked in the workplace.

  
  While there are studies showing some variance in comfortable working temperatures depending on culture and gender, it would seem that 28°C can't be comfortable for anyone.



• Raising the cooling temperature of a standard building in Tokyo from 25°C to 28°C could increase energy efficiency by 15%, which is equivalent to saving ¥72 per square meter of office space during the COOLBIZ campaign. On the other hand, the resulting decrease in working efficiency could cause a loss of 13,000 yen per square meter of office space.

  
  What kind of company loses 13,000 yen to save 72 yen? A Japanese company, apparently.
  

1.1.1.1

A number of captive portal implementations, including products from Cisco and Nomadix, use 1.1.1.1 as a virtual IP address, HTTP requests to which are redirected to the access control server's logout page. A quick google search turns up numerous network service providers, mostly wireless ISPs, that use 1.1.1.1 to access their logout pages.

This trick has worked because the 1.1.1.1 IP address resided in an IP block that was reserved by the IANA, so there could be no server that actually used that IP address.

However, this month the IANA assigned the 1.0.0.0/8 IP block to the Asia-Pacific NIC. As its name implies, APNIC is responsible for the allocation of IP addresses in Asia and the Pacific, meaning that there may come a day when a company in China, Australia, or elsewhere is allocated a subnet containing the 1.1.1.1 IP address.

In short, the 1.1.1.1 IP address no longer resides in reserved IP space. Network access servers should stop using it.