Re: [VCARDDAV] vCard format and lack of interoperability

Alessandro Rossini <me@alessandrorossini.org> Mon, 19 November 2012 12:42 UTC

Return-Path: <me@alessandrorossini.org>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5432421F8471 for <vcarddav@ietfa.amsl.com>; Mon, 19 Nov 2012 04:42:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.979
X-Spam-Level:
X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztCX-xaHV88i for <vcarddav@ietfa.amsl.com>; Mon, 19 Nov 2012 04:42:58 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5124B21F846C for <vcarddav@ietf.org>; Mon, 19 Nov 2012 04:42:58 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so3965716lbk.31 for <vcarddav@ietf.org>; Mon, 19 Nov 2012 04:42:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=rkgJBwo2iJiBpCvcCmLdW8jqfJ2djs/D8gkNoJu1GTc=; b=A6WcMRugyiPhfi326623LAhwRw24XHtpEtbOgLTxD6FhIBM28rXRhi9kod/njdMfL8 cBC155okWmkPZhYnsGKo60QUHPJqRcX9lo/wPEV072FtTH7/0S2Wm8l4qmhJr2ICJ3tX r0miRb7OzHQTvRkGbp5EX7H06rVdOv+N6BEnxS5vGhE+j8Oy1cdWLpgVVQDbCJRuOgv5 rkm+CARQJRO4lbqTubal2kyxaGZXpOZBALonGlVoBIibjTZhLy3eLeTq7oTN8ql7JyNa 9MlZvxHCMID6EaDyc5N54lA5RXD4DbmRNQvYM2wtCka2+KeF/bfnC8THtWljzJ8esi25 2aCQ==
Received: by 10.112.17.169 with SMTP id p9mr5030473lbd.9.1353328977060; Mon, 19 Nov 2012 04:42:57 -0800 (PST)
Received: from [10.0.0.7] ([80.202.107.209]) by mx.google.com with ESMTPS id fp7sm3494724lab.4.2012.11.19.04.42.54 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2012 04:42:56 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Alessandro Rossini <me@alessandrorossini.org>
In-Reply-To: <50A69522.6050401@gmail.com>
Date: Mon, 19 Nov 2012 13:42:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7F6B0CBF-B7A5-44D9-B3AF-B46133319C06@alessandrorossini.org>
References: <68174210-640D-42BF-995F-3987AD9AF3A8@alessandrorossini.org> <50A69522.6050401@gmail.com>
To: "vcarddav@ietf.org" <vcarddav@ietf.org>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmywwCRp0SarDJOuB7hWNntHVux4gt6qmcb4+/UNXzqSQAa0hHv8TAeTUN8mdVI+TJzTI8+
Subject: Re: [VCARDDAV] vCard format and lack of interoperability
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 12:42:59 -0000

On 16 Nov 2012, at 20:33, Doug Royer <douglasroyer@gmail.com> wrote:

> Non standard properties are not for interoperability. They are so that a vendor can put their own extension into an object (vCard or iCal) and provide what they see as a value added reason to use their product. By allowing these non-standard properties and parameters into both iCal and vCard it provides a standard way to add vendor value added data that will not crash other vendors. The fact it does not crash them, is a great sign for vCard and iCal.

I understand that non-standard properties are not meant for interoperability, but I do not see why they should be included in the specification. In my opinion, open standards should first and foremost promote interoperability and prevent vendor lock-in.

By way of an analogy, browser vendors also introduced non-standard HTML tags and CSS properties to provide what they saw as a value-added reason to use their browser. These tags and properties did not crash other browsers, but they did prevent interoperability and promote vendor lock-in, which is exactly the opposite of what open standards should aim at.

Cheers,
--
Alessandro Rossini
http://alessandrorossini.org
http://twitter.com/alerossini