RFC 2739

I’ve been doing a fair bit of development work of late on Upwork, joining the gig economy in my spare time. Yes, that gig economy time eats into my blogging time, and yes, the pay is… well, it’s gig economy pay.

But I’ve missed programming, and I do enjoy it. Even if programming now, compared to programming in the 90s, seems to involve a lot more Googling and a lot less remembering how each language does things differently. Like Thoth groused once: this new tech will destroy people’s memory.

I’ve been doing a fair bit of work for Ribose, and their involvement in RFC standards. IT Standards have been something I’ve been involved with professionally for over a decade, though I’ve been working in areas more heavy-handedly run than RFC. It’s been good to put some coding support behind such efforts; and you can peek at my handiwork over at github.

What’s not been as good has been to look up close at how some of those RFC standards have actually been specified. Heavy-handed process has its advantages, and in at least some instances, those advantages have been foregone. As a result, there are some RFC standards… with holes in them.

I know this shouldn’t come as a surprise to anyone. I also know that vCard 3.0, one of those RFC standards I’ve been grappling with writing a grammar for to validate, is a standard that people look at sneeringly with good reason. It’s old, it’s texty, it’s clunky. And it’s way too lax compared to vCard 4.0: people did learn over time that a thousand flowers blooming in IT standards is not a good thing, and v4.0 is miles more tractable. (But of course, it’s the bad old lax version that still has market share.)

But I haven’t had occasion to look that closely at an RFC spec before. And vCard 3.0 was quite a baptism of fire.

I won’t go into the full detail of all the inconsistencies and vaguenesses of the vCard 3.0 spec in RFC 2426. At least, not yet. I will however point to the rather large list of errata associated with RFC 2426, and the even larger list associated with vCard 4.0, RFC 6350.  (Of course RFC 6350 has more errata: it has a more rigorous grammar.) Errata don’t come up when you google RFCs and take the text file as your first hit; and I feel greatly disappointed that errata are not promoted more aggressively in the publication of RFCs: that’s just negligence. It’s also a mechanism that can’t keep up if the initial specification did a really poor job: there are several errata which have been acknowledged as valid, but are not being actioned (Held for Document Update), because to address them would require a brand new version of the spec. RFC 6350 dates from 2011: still waiting for those Held for Document Update fixes…

I reserve special ire, though, for RFC 2739.

vCard 2.1 was a much dumber version of the spec than v3.0. It also was conjured up outside the RFC process, and good luck finding a spec for it online now. One of the vCard 2.1 misfeatures that v3.0 addressed was its mystery meat parameters. In v3.0, all parameters of properties are key/value pairs:

ADR;TYPE=WORK,PREF:;;100 Waters Edge;Baytown;LA;30314;United States of America

The key is TYPE, and its values are WORK and PREF.

In vCard 2.1, the TYPE key was implicit in parameters: you could leave it out:

ADR;WORK;PREF:;;100 Waters Edge;Baytown;LA;30314;United States of America

If you’re parsing this, of course, that’s a gratuitous headache: why should I have to store a bunch of exceptions, and have values stand in for keys?

So. That went away in v3.0. Good.

RFC 2739 is an update to vCard. Since it is an RFC spec, it can only be an update to an RFC spec, and the only RFC version of vCard at the time was v3.0. In fact, that’s the version of vCard they cite: “[3] Dawson, F. and T. Howes, “vCard MIME Directory Profile”, RFC 2426, September 1998.”

Let’s go to §2.3 of RFC 2739, shall we?

Since the vCard [3] specification doesn’t specify how to encode
calendaring URIs in a vCard, this section is provided as an extension
to vCard which specifies how to encode calendaring URIs within a
vCard.

Inside a vCard object, four new properties are defined: “CALURI”,
“CAPURI”, “CALADRURI”, and “FBURL”, as defined above.

Any vCard can have one or more of these properties, each representing
a calendar or free/busy time that is associated with the user.

One of these properties can be designated as the “default” by adding
the “PREF” parameter.

Here is a simple example of a vCard containing a “FBURL” and a
“CALURI”.

 BEGIN:VCARD
 VERSION:3.0
 N:Dun;Alec
 FN:Alec Dun
 ORG:Microsoft Corporation
 ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
   Redmond;WA;98052-6399;USA
 TEL;WORK;MSG:+1-206-936-4544
 TEL;WORK;FAX:+1-206-936-7329
 EMAIL;INTERNET:user@host1.com
 CALADRURI;PREF:mailto:user@host1.com
 CALURI;PREF:http://cal.host1.com/user/cal.ics
 FBURL;PREF:http://cal.host1.com/user/fb.ifb
 CALURI:http://cal.company.com/projectA/pjtA.ics
 FBURL:http://cal.company.com/projectA/pjtAfb.ifb
 END:VCARD

Do you see what they’ve done?

No?

Look again:

One of these properties can be designated as the “default” by adding the “PREF” parameter.

The… which parameter?

the “PREF” parameter.

v3.0 doesn’t have a PREF parameter. We got rid of it as v2.1 mystery meat, remember? What it has instead is TYPE:PREF.

Don’t tell me…

BEGIN:VCARD 
VERSION:3.0

You’re seeing that, right? My eyes are not playing tricks on me, right?

BEGIN:VCARD 
VERSION:3.0

And what does their vCard 3.0 example look like, in an RFC publishing an official update to the vCard 3.0 spec, and illustrating how their new properties look?

CALADRURI;PREF:mailto:user@host1.com

Which is of course vCard 2.1 mystery meat parameter for CALADRURI;TYPE:PREF:mailto:user@host1.com. In the official illustration of a new vCard 3.0 property.

Oh, that’s not the worst of it. The worst of it is:

ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way; Redmond;WA;98052-6399;USA

;WORK? ;POSTAL? ;PARCEL? This is not vCard 3.0. That’s vCard 2.1. And an RFC spec has put this stuff, in an example illustrating its proposal, under a VERSION:3.0 header.

Which means that I’ve had to introduce PREF as a vCard 2.1 style mystery meat parameter into my vCard 3.0 grammar, because after all, that’s in what’s in the spec.

Who do I excoriate for this, then?

      T. Small
      XpertSite.Com
      D. Hennessy
      ISOCOR
      F. Dawson
      Lotus

Yeah, they’re the authors of RFC 2739, and they deserve a whole lot of opprobrium. You only had one job, guys. To write an update of an RFC spec. An update of an RFC spec that is not supposed to undermine the spec itself, and send it through a wormhole back in time, back to a land of mystery meat and Word Documents publishing technical standards.

But you know, that’s not my main annoyance here.

Go to https://www.rfc-editor.org/errata_search.php?rfc=2739

Yup. No errata reported. Since January 2000. On a version of vCard that remained the latest version for the next 11 years, and still has most of the market share.

I did just stumble on this issue, and I have no idea how prevalent this kind of thing is with RFCs. But technical standards trade in reputation: that’s what gives them their authority. If you can’t trust an authority to keep their technical standards error free (over 17 years), it’s going to be hard to trust any spec that authority comes out with.