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.