I borrowed my neighbour's pressure washer today, and it was fun! First, it's a water toy. Second, it's a power tool. These are two great things that go great together. It's a gas engine, thus loudish, and the spray nozzle is long so both hands have to hold on (one holding down the handle the whole time, which can get fatiguing but that's the worst thing about the job).

My red patio paving tiles were covered in scum prior to this afternoon. Scum came particularly from the eaves of our house, which drain dirty rainwater right on to the patio and then across the tiles to the azaleas. But even away from the path of the scummy rainwater, it was still dirty and black because the drainage is terrible and it rains a fair bit here in winter. I curse the previous owner of the house who designed the eaves and patio this way -- it looks good but isn't as functional as you'd think.

Using the power washer on this blackened, scummy patio is like spray-painting in reverse. With each stroke of the DirtBlaster® rotating nozzle it was as if I painted the tile its original colour. I discovered if I moved the spray nozzle quickly enough over scummy tiles I could see a spiral pattern, proving to myself that this nozzle indeed rotated somehow, although it circled so fast that the water output looked like the surface of a cone. It was like having in my hands a magical staff that fires a cone of cleaning.

After the red tiles, I moved on to the blacktop driveway, the concrete front sidewalk walk, and the back walk. Things got a little messy there, in the tight corner between two sturdy wooden fences, the ground was dirty and the power washer sprayed mud right back out of this corner and onto me. As I finished up I considered turning the power washer on myself, but concluded that a real shower would probably be more satisfying. I looked around for other things to clean, considered whether bushes and trees and wooden sidings needed power washing, and regretfully turned it off and returned it to the neighbour. Until next time.

You won't find me talking about cooking or touting cookbooks much, so pay attention. Cook's Illustrated The New Best Recipe is a different kind of cookbook. You think you know how to make basic french toast? I thought I did. As it turns out, I had only a dim clue, and I needed to use less eggs, much more milk, some flour, vanilla and sugar. I haven't had this book for very long, I don't cook often, and I only cook for myself, as the man around the house prefers not to eat my cooking (probably for justifiable historical reasons). But every few weeks since getting this cookbook I've tried a simple recipe. Here are my results so far:

• The french toast: amazing. Getting the inside custardy, and the outside not to taste like fried eggs, is a total win. Their way is not noticeably harder than doing it my old way. I even cheated by using the wrong bread (nowhere in the recipe did they even admit to the possibility of using wheat-and-7-grain bread) and it was still terrific.


• Pasta tossed with oil (and a little garlic, parsley, etc): Very good and relatively easy, a solid recipe though perhaps not mind-blowing. I don't have much to compare to because I wasn't in the habit of making pasta without a sauce before.


• Chicken cutlets: amazing. Brining chicken naturally takes longer, as does preparing the liquid, flour mix and bread crumbs to dip in. But holy fowl, does this make the most tender piece of chicken I have ever eaten, inside or out of a restaurant. Ever. I was worried because the breast meat seemed too moist when I started to eat, but the liquid was clear and the meat was cooked -- it was just that juicy. Again, I got this result even with a little cheating: I used frozen meat, mostly thawed by the time I turned it into cutlets. I only ate one piece fresh out of the frying pan and that was the one that caused the religious experience, but the cold or reheated leftover cutlets were also highly worth eating.

I guess the deal is that this cookbook explains so much -- not just explaining exactly what to do but why, for example what effect omitting some ingredient or step had in their tests -- makes up for me being the kind of cook who may sometimes take a few shortcuts. I have better guidance about what kind of shortcut really matters.

Colby Cosh points to this article on making more roads in Dhaka off-limits to rickshaws. Opponents of the proposal point out that rickshaws carry 54% of the city traffic using less space than private transport does, and that when more roads are put off-limits to rickshaws, their drivers' incomes dip significantly downwards. Overall, I have to say that it's nice to see reasoned debate on the topic of public transport including not only government-managed public transport but also privately-organized public transport. In most North American cities, it's easy to forget that there are many other kinds of public transport beyond the city buses and subway systems.

For a few years I worked downtown, on the close edge of the shopping and financial districts and right near a subway stop. But for various reasons the subway didn't work for me and I took the train. The problem with the train was that the train terminus was a long walk from the office (25 or 30 minutes) and I didn't like biking downtown. City buses were slower than walking! Sometimes I'd wait for a city bus for twice as long as the supposed period between buses, and then of course the next thing I'd see would be a packed full city bus with one or two empty buses stuck behind it (quite stuck, as these buses used overhead wires for power, and couldn't pass one another). Even after catching a bus on-time it was a toss-up whether it would actually move faster than a pedestrian. One day I noticed the jitney.

The jitney is easy miss despite the fact that it's an unusual vehicle, an ancient royal blue shuttle bus with big white amateur lettering. It goes from the train to various points downtown and back to the train. It only operates during prime commute hours and its schedule is carefully tailored to the train schedule. And it goes fast, taking alternate routes when necessary, changing lanes and sometimers letting passengers off on the left of a one-way street if the right side is too clogged. It took 5-10 minutes to take the jitney from the train to the office, was never late, and it cost the same as the city bus.

The problem? It was illegal. It's illegal to offer a jitney service to multiple passengers in most North American cities. That system allows public buses/subways and taxis to monopolize in-city public transport under limiting rules. It would also be illegal for somebody to run a private commuter bus service up and down the major highway here, and the public systems haven't integrated their services enough to do so (or perhaps have decided not to offer a more attractive option, so as to push people towards public commuter trains). It would be hard to change the status quo although some people are thinking about it.

I hope countries that still have creativity and open competition in public transport are wiser than North Americans. Keep those rickshaws on the road!

Finally I can prove that this is still a knitting blog, too. I lost a hard drive and I lost the data cord to my camera (separate events). These together made me have to do a bit more work than usual to post pictures and edit pages. But finally I've posted a couple pictures of stuff finished in March on my knitting page.

Also in my Flickr set, there's a related picture of my cat. Related to knitting. Well, she always helps me when I take photos of my knitting. This time I helped her take an even closer role, that's all.

Jackrabbit is now a full Apache project, and Jackrabbit 1.0 is released. Jackrabbit is a reference implementation of Java API called the Java Content Repository (JCR). A repository that stores JCR can be used to store arbitrary data, just like a database can, but it's more flexible. Instead of storing data in tables, a JCR repository stores data in a hierarchy of nodes and properties. JCR can replace JDBC in many applications that require a structured repository.

Cosmo uses JCR to store shares, calendars, events and other resources. The reason we use JCR instead of a database is because JCR has a more flexible data model, and because a hiearchical data model is closer to the data models of iCalendar and the Web. There are lots of applications today that use databases when hierarchical storage would be a more appropriate model, but databases are so standard that it's still going to take a while for this alternative to gain ground. It's important to have a standard API for accessing this new kind of repository, so that a server implementation doesn't get locked into one back-end.

As with all new technologies, the reality still falls slightly short of the promise.

• Cosmo has had to compensate for performance issues, particularly if a node has many child nodes. Flexibility has a cost, though I expect this will be improved over time.
  


• JCR implementations are still rather new and I'm not aware of much interoperability testing, so we don't expect we would actually be easy to replace Jackrabbit with another JCR implementation and just have Cosmo work. Still, it wouldn't be terrible either.


• According to BCM, both the XPath and the SQL query syntaxes that JCR provides didn't quite suffice for doing the kind of date queries we do, so BCM had to work around JCR to do time-range queries for calendaring. This kind of trick, bypassing the standard API to use the repository's own non-standard API, obviously makes the replacement issue more difficult.
  

I've been looking for a better understanding of what a trade deficit is, and why it's supposed to be bad, and whether it really is bad. The conventional wisdom as I've always heard it, is that the US has a large ongoing trade deficit causing job loss, debt servicing costs, and possibly currency instabilities if the foreign owners of American dollars suddenly get uneasy. Wikipedia has a discussion of the points of view of those who believe it's harmful, those who believe it's not, and those who believe it's meaningless. Whether the Wikipedia article is balanced, I can't tell. But clearly, just because a "skyrocketing trade deficit" is a great scare news article headline, and fun to accuse Republicans of, or perversely blame China for, doesn't naturally make it a bad thing. .

I can see two possible sources of gut-level unease, the kind of feelings which make people assume a trade deficit must be bad, bad, bad: fear of debt (guilt over not saving), and guilt over consumerism. The debt question comes up if the trade deficit consists of goods for debt: foreign countries exchange their goods for a promise to pay later, including interest. A trade deficit is associated with low rates of saving, again obviously bad. The consumerism guilt comes up because it makes Americans seem greedy that they import so much oil from the Middle East and so many consumer goods from Asia: it's probably felt to be evidence that Americans must be greedier than others if Americans consume so much that they have this nasty trade deficit as a result. Take these bad feelings together, and you have the question of whether it's wise to be going into so much debt just to consume more than anybody else does. When you put it that way most people are going to think it's a bad idea of course.

But it's not that simple. Japan was troubled for years by maintaining a trade surplus, where it sold desirable goods to the US but had little to use those US dollars for. The dollars fueled some purchasing of US investment properties (companies and real estate) at excessive prices. It may also be possible to maintain a trade deficit without going into debt but it's not clear to me whether a debt-free trade deficit would really make people who oppose trade deficits that much happier.

Today Colby Cosh pointed to an article in which, ironically, a Chinese economist may explain why the US trade deficit, in particular, may be calculated as much larger than it actually is. Products that are less than tangible are the problem when tallying up the numbers, of course. It makes me start to fall on the side of those who think it's meaningless. Maybe it's mostly a fictional problem, an arbitrary equation wherein we put one kind of desirable things on the left side of the equation, and another kind of desirable things on the right side, but leave a few terms out because they're too hard to add up, and finish by trying to make the numbers come out even so that it seems tidier.

Getting Things Done

Almost a year ago, I read David Allen's book Getting Things Done (GTD), and decided to apply a couple principles. I already tried to review incoming email once only, but that just wasn't quite working consistently for me, and I regularly had from 40 to 80 emails sitting in my Inbox, unfiled, because I hadn't dealt with them or decided whether or how to deal with them. At 100 emails I would usually feel overwhelmed and go back to some earlier emails and just decide, finally, not to do anything with them, and clear back out down to 40 or so.

I had also tried keeping track of tasks in a separate list from my Inbox but that also hadn't worked for me. One problem was that the list grew too big, easily to 60 items or so within a couple weeks of starting it. I needed to break it down somewhat. Breaking it down by project seemed obvious but then I had several lists and no way to see what was most important. And still there were tasks that I just didn't tackle.

The biggest value trick I got from GTD, above all the other good advice, was to organize my task list by context, rather than by project. My contexts have been:

• At the computer (offline)
• Online
• At home
• At work
• Agendas
  
• Errands
• Phone calls
• Waiting
• Later/maybe
• Done

The 'agendas' list made me look particularly organized because as soon as I had a chance to talk to somebody like my manager or somebody else I work with a lot, I could look really smart and prepared even if I hadn't actually prepared for that specific meeting. I made meetings more productive and didn't forget to cover issues that I'd previously noted I needed to cover. Naturally, the "at home" and "at work" categories kept me from sifting through tasks at an inappropriate moment, so at any moment there seems to be less pressure, less possible things to do, easier to focus. All good stuff.

But there's even more to the system than that, and I believe it's hooked into another classic piece of advice, also covered in GTD: that of identifying the next action.

It's actually very hard to identify the next action in many projects. Back when one of my projects was to get my eyes fixed up, I futzed around for maybe a year before actually setting up an eye doctor. Aside from indecision and being busy, part of the reason was because I hadn't correctly identified the first step -- without thinking too hard about it, I had only the fuzzy idea that I needed to setup an appointment with an eye surgeon. But before I could actually do that step I needed the phone number of an eye surgeon. Before that, I needed to know which eye surgeon. Before that, I needed to get some kind of recommendation. And before that, I needed to know who to ask for a recommendation. Finally, I asked a cataract eye surgeon for a recommendation, and the rest followed more easily (for the record, it was Dr. Volpicelli at Peninsula Laser Eye Medical Group).

So how does organizing tasks by context help? Because in order to decide whether the next task is one I can do at work, at home or on the phone, I need to have a concrete idea what the next task is. It makes me break down each project earlier.

Following this discipline, together with weekly reviews to see which tasks are stale and which projects don't have tasks currently in the active list, may have made me up to 20% more productive at times. It's hard to say. I don't always follow the discipline but I'm getting better.

The tool I use for the lists of tasks is called iOrganize. It's not optimized for this task, but it's sufficient. It's good at taking quick notes, giving them titles, and moving them from one category to another. I wish it could assign reminders to tasks, or optional due dates, but that's OK, it's not actually required for the way I work. I put a ** in front of the title of important tasks, trying to have from two to five tasks with "**" at any time. This allows me to search for important tasks very quickly and sort them to the top of each context list. There's a priority field too, but that doesn't allow me to search, and it didn't exist in the previous version of iOrganize so I'm already used to having "**".



I know there's many ways people follow GTD, there are blogs and near-cults out there and I'm certain there are more specialized tools, maybe I'll use one of them someday. This is just what works for me.

RFC 4331 is now up: Quota and Size Properties for Distributed Authoring and Versioning (DAV) Collections. It's my first RFC as author.

Scott Mace interviewed me for IT Conversations, and the podcast is now available, on the topic of calendars and calendar interoperability standards. Is it wierd listening to yourself or what?

You know you're working on standards too much when...

I saw a traffic sign today on University Ave. that said "Bicycles may use sidewalk". My very first reaction was that the text should be "Bicycles MAY use sidewalk"[1]. It was followed by the thought that it should also read "... thus, pedestrians MUST be prepared to encounter bicycles on the sidewalk."

[1] IETF standards have to use capitalized MAY, MUST and SHOULD to be absolutely clear when the specification is prescriptive, i.e. making a requirement, and not just being descriptive.

Ukrainian Christmas may be a Canadian prairie province tradition, according to Colby Cosh. I'm from the prairie provinces myself and love the tradition. My mother grew up in Manitoba and we celebrated Ukrainian Christmas each year in January. Often we opened Christmas presents that day, too. We'd usually travel two days to our grandparents' house for Dec 25 Christmas, with four kids, two parents, winter gear and all the presents we had to give away to aunts, uncles, cousins and grandparents, stuffed to within a foot of the ceiling of our full-sized van. After that, there just wasn't room for the stack of presents my parents bought for us kids, or that we'd bought for each other. So we'd leave those presents at home and delay gratification until early January with Ukrainian Christmas.

Of course the day also provided an opportunity for my mother to become a Ukrainian babushka, to cook the dishes she'd had as a child and serve them as a special treat for her own children: lovely yummy perogies, delicious sweet kutia, hearty holubtsi and the rest of the traditional twelve meatless dishes. The odd thing? We're not Ukrainian. Not at all. On my mother's side, English and Scottish Canadians. Nor did she take this tradition on for my father's family, who are almost all French-Canadian with a couple Scots and possibly Indian ancestors thrown in. No, she just picked up this Ukrainian tradition from proximity in rural Manitoba.

One year, living in Ontario when I was fifteen or sixteen, we nearly missed Ukrainian Christmas. My mom was travelling home the day before, but her trip was delayed somehow. When she called, my father and sister and I looked at each other in dismay, unable to imagine missing the traditional feast. No pyrogies? No kutia? How would we survive winter without? We talked each other into doing this ourselves even though my father's better with ad-hoc cooking than with established recipes, and my sister (younger) and I hadn't had much experience. But we dove in, hunting down Mom's recipes written on stained index cards, and even making stuff up when we got stuck. The kutia was great (almost impossible to mess up), I seem to recall the holubtsi was tricky to roll up in neat bundles but it was quite edible as messy piles of flavored rice somewhat contained in cabbage wrappings. The pyrogies were the toughest and many fell apart during boiling (later we discovered that they weren't supposed to have butter in the dough). But it all tasted OK, and we tallied up twelve dishes by liberally counting bread and buns and different kinds of pickles (including the necessary beet pickles) each as separate dishes. I felt so grown-up when my mother came home just in time for dinner and we enjoyed our feast.

Today I still do this, even now that I'm in California with no family nearby. For one, it gives me the chance to serve a distinctive meal for some vegetarian/kosher friends. It's also, naturally, a chance to reminisce as I cook and taste the flavours. In those years when I travel back to Canada during Christmas and Hannukah, it's my one chance to do a family holiday evening with my closest California friends. When I'm lucky, some years I manage to have a Christmas, a Hannukah and a Ukrainian Christmas dinner too. Each year I remember that one year I asked my mother why we do Ukrainian Christmas when we aren't Ukrainian. She answered that it was her belief that everybody should be able to adopt the culture of their choice, without limitations due to actual genetic descent. Three mid-winter feasts a year? That's my kind of multi-culturalism.

Another Outlook connector link related to yesterday's post: caldavxp is Mark Slater's project to develop a CalDAV plugin (technically, a message store provider) for Outlook. I learned today some of the many, many ways one can extend Outlook, it gets pretty complicated I take it.

At next week's CalConnect meeting in Utah (brrrr... but thanks Novell for hosting), I suspect one of the topics will be whether it's possible to write some kind of plugin for Outlook so that it can talk to calendar servers other than Exchange. Naturally one obvious approach is to write a generic CalDAV plugin for Outlook, and this kind of thing would make it much easier for many organizations to migrate to a standards-based approach.

The technical barriers are daunting. Outlook doesn't seem to have been designed for this kind of plugin at all. Such a plugin might have to use undocumented APIs even to work at all, and then naturally have lots of code to handle changes in those APIs from release to release. Some embryonic work is in progress at OpenConnector if anybody wants to jump right in, or I can put people in touch with each other so email me. At this point, amongst the group of people I've been talking to, we're not even convinced we have a decent approach outlined (so input from MAPI experts is particularly welcome) let alone how much work it would be. But we're starting to talk.

We're getting very, very close with CalDAV. Draft version 09 is submitted and I'm sure it will be posted soon. There's not a lot of open issues remaining (one is how to use ETags, which is the topic of lively discussions in both the CalDAV and the WebDAV mailing lists). Interoperability is pretty good already -- I got a great reception at ApacheCon when I demo'ed Chandler publishing a new event to a calendar shared on Cosmo, and then used Sunbird to refresh the shared calendar and see the new event (note that Chandler 0.6 was just released so you can do this too). We'll have one more interoperability event in January before likely finishing the draft and submitting it. We plan to do pseudo-last-calls in WebDAV and CALSIFY WGs but if you've been waiting to read the draft, it's great to get comments even before last-calls.

Tom Evslin posts with several reasons why Web sites don't provide APIs -- and yet predicts that many more will provide APIs in the future. I can add one more reason, and that's the risk that with an API, somebody would build an application that presented the data through an alternative UI, and the site would lose eyeballs. For example, if Yahoo Group calendars could be sucked down in iCalendar format, people would probably visit the site less often and receive fewer ad impressions.

Still, I agree with Tom that despite all these forces against opening up APIs,
there are even stronger forces for having APIs -- competitive advantage. Some company hoping to compete at lower cost will provide the API and try to make up the revenue in other ways or simply survive with less ad revenue. If the service is more valuable with the API people will move to that service. I hope that in a year or few, people won't stand for a calendar Web site that doesn't let them use a standard API to have direct access to their own calendar data.

Favorite Songs of Stalkers

6. "I Will Follow You", by Ricky Nelson

"I will follow you
Follow you wherever you may go
There isn't an ocean too deep
A mountain so high it can keep me away"

5. "I will Follow", by U2

If you walkaway, walkaway
I walkaway, walkaway...I will follow

4. "The Power of Love", by Air Supply

Even though there may be times
It seems I'm far away
Never wonder where I am
'Cause I am always by your side

3. "I'll Drive All night" by Celine Dion

So just remember -
I'm gonna make you mine
I'm gonna drive all night
till the morning light
I'm gonna roll till dawn
with the windows down
and the radio on
You know I'd drive all night
just to hold you tight

2. "Nothing Can Keep Me From You" by Kiss

Wherever you are, that's where I'm gonna be
No matter how far, you'll never be that far from me
Some how I would find you, move heaven and earth to be by your side
Oh, I'd walk, this world to walk, beside you

1. "I'll Be Watching You" by Sting

Every breath you take
And every move you make
Every bond you break
Every step you take
I'll be watching you

0. Christmas Bonus Stalker Song:

He sees you when you're sleeping
He knows when you're awake
He knows if you've been bad or good
So be good for goodness sake!
O! You better watch out!
You better not cry.
Better not pout, I'm telling you why.
Santa Claus is coming to town.

I posted to a couple IETF lists about yubnub.org, a nice productivity hack -- a command-line for the Web. Since I'm always looking up IETF WG charters, internet-drafts and RFCs, I found the existing 'rfc' command and added two more.

To jump to an RFC: rfc xxxx

e.g. 'rfc 2822' (don't forget space)

Internet-Draft Database Search: (shows list with filename substring match): ids keyword

e.g. 'ids dusseault' to find draft-dusseault-caldav-08, but not draft-ietf-webdav-rfc2518bis because 'dusseault' isn't in the title of that one

To jump to a WG charter: wg wgname

e.g. 'wg imapext'

Now Dan Gurney has extended the 'rfc' command so you can use text as well as numbers. You don't have to remember that iTIP is RFC2447, just type 'rfc itip' in the yubnub.org interface, and see results. Thanks Dan!

BTW I personally setup yubnub to work on the address line or search box in Firefox so I don't even go to yubnub before typing my command. One less step on the way to what I need!

For those who follow my crafty pursuits, I've just posted pictures in the gallery of the mini-quilt I finished this weekend. Well it's more of a wall hanging made with quilting (no piecing).

Also if you saw the Butterfly Quilt for Ally, posted earlier on the gallery, well everybody loves it and wants to be my niece too. I don't have an opinion from my real niece (she's only one year old, after all, and extraordinarily easily bored) but her parents love the quilt. Whoo hoo!

It's been a busy few weeks, which is why I'm only now posting about another IETF meeting although it happened Nov 7. The meeting was the XML-PATCH-OPS BOF, and here are the official minutes.

The SIMPLE WG has been working on some HTTP extensions and using XML in order to allow instant messaging clients to interoperably edit buddy lists (stored on the IM server) and other configuration data. Special functionality to modify/retrieve XML stored on an HTTP server is rampant these days, so it seemed like a good idea to consider general mechanisms, rather than only design mechanisms limited to SIMPLE use cases. So Jari Urpalainen has been working on a general XML diff, or patch algorithm -- like Unix diff files, only specialized for XML (operations that can add or remove branches from the XML tree structure, rather than operations on lines as in text diffs).

Once the SIMPLE WG was potentially working on such general mechanisms, it seemed like a good idea to hold a BOF (Birds Of a Feather) meeting to see if there were general use cases and find or identify other potential IETF participants. Some places where we thought we'd see interest:

• WebDAV allows authors to collaborate on documents stored on HTTP servers. Sometimes these documents are quite large and it would be useful to be able to upload changes without sending the entire file again. In fact, Adobe engineers have talked to me about this -- some of their WebDAV functionality is intentionally designed to limit the number of times large files are exchanged between client and server, so that the user isn't constantly waiting for slow uploads or downloads. Obviously an XML patch format only works if the document is in XML, but some Adobe tools do support XML formats (e.g. InDesign). Another piece to this puzzle is the HTTP PATCH operation I've proposed, an idea I intend to come back to shortly particularly if I get any help (hint, hint).
  
• The NETCONF WG is pursuing ways to interoperably configure network devices and has also settled on using XML and HTTP. They've got very similar problems of wanting to make small changes to large data sets.
  
• Large Web pages in XHTML could be edited using an XML diff format to upload only changes.
• Large Web pages in XHTML could be downloaded faster using RFC3229 and an XML diff format. A text diff is used today but an XML diff format could be even more efficient, particularly for...
• Blog feeds. Today, a blog feed can be a large XML file, in Atom or RSS format. Today, if the ETag or Last-Modified timestamp of the blog feed changes, the newsreader client downloads the entire file. Similarly, to add a single new post to the feed, blog editing tools may have to upload a new feed file (unless the server does this magically somehow). This is really just a special case of the general "large files being shared" case, but since blogging generates so much traffic it seemed worth mentioning.
  

Anyway, even with all these potential use cases, the only people who came to the BOF meeting with definite interest were SIMPLE WG participants. There wasn't even enough interest from outside SIMPLE to merit a separate mailing list, let alone to add non-SIMPLE requirements or
to form a separate effort. So the work proceeds on the SIMPLE mailing list. Still, I plan to keep up with Jari's work and possibly help him generalize it further -- for example, we may add the ability to make changes to text values of XML elements without replacing the entire text value.

Note that there exist other XML diff formats, but none of them are standardized. Microsoft's got one, the W3C has tackled this both for rdf and more generally (though the W3C didn't have any guidance for the IETF when we asked about this BOF), and it's been the subject of several theses: treepatch, diffxml and a survey.

In the past the IETF tried to discuss in a green-field manner how to internationalize email addresses and other email headers. None of the many options seemed really low-risk, however, and those discussions didn't get very far -- rat-holes being very frequent, and people having very different notions about what a solution could look like and what the outcomes and side effects might be.

The BOF I attended last week, however, was much more focused: it was about whether or not the IETF should charter a group to work on a specific experimental solution for internationalizing email addresses as outlined in several draft documents. That solution focuses on SMTP, so that "consenting adults" in an environment that wants to do i18n addresses may do so, and SMTP agents have a reasonable way to deal with these addresses when communicating to the wider world. It's a somewhat transitional approach, acknowledging that existing Mail User Agents (MUAs) and Mail Transport Agents (MTAs) won't immediately be able to handle these.

The discussion was mostly abour risks and unknowns. Some of the risks:

• It's not known how (and when, and by whom) IMAP would be updated to handle i18n addresses, and how clean that could be.

• It's not known how POP would be updated to handle i18n addresses (Chris Newman stepped into the line of fire here)

• It could be difficult to manage VCards, iCalendar objects, and Web pages where mailto URLs and email addresses appear. Some of these support i18n, some don't; even ones that do may have incompatible representations.
  

• Although i18n addresses are supposed to remain within these groups of consenting adults and be transformed before transmission to non-i18n MTAs, it's not known to what extent these would actually leak out.

• When these do leak out, the user experience of email users with non-i18n MUAs could be unsatisfactory.

• There will probably be serious difficulties when non-i18n MUAs are used to try address mail with i18n addresses -- it's possible that sometimes only an i18n address is known and the user can't figure out how to enter it or isn't allowed to by their software.

Normally the IETF is rather risk averse when there are so many unknowns, particularly when 'Net fragmentation might occur. In the past the IETF has gone around and around trying to get more certainty before even chartering a working group. This time, however, since there have been so many discussions and stalled related efforts before, the attendees took a leap into the unknown and approved the working group -- unanimously, I believe. Imagine Admiral Farragut's sailors taking a "hum" and deciding together to damn the torpedoes.