Re: [VCARDDAV] vCard format and lack of interoperability

Robert Smith <royersoftwareandservices@gmail.com> Mon, 19 November 2012 16:51 UTC

Return-Path: <royersoftwareandservices@gmail.com>
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 1484221F855E for <vcarddav@ietfa.amsl.com>; Mon, 19 Nov 2012 08:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[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 qS9nu664AH+P for <vcarddav@ietfa.amsl.com>; Mon, 19 Nov 2012 08:51:50 -0800 (PST)
Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57FFE21F86CF for <vcarddav@ietf.org>; Mon, 19 Nov 2012 08:51:50 -0800 (PST)
Received: by mail-da0-f44.google.com with SMTP id h15so2264080dan.31 for <vcarddav@ietf.org>; Mon, 19 Nov 2012 08:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=74P9PzoC2bR4IlfYazI5kmKA0Lpg6OIdx6i3Oukngy4=; b=GSNtIlmaffbGJsZOlYDHzwLtF+ButHhD83UPWUXNGGYKs73IdeuEnVVPYtWtK2q4IZ bLKhWxm+29upBZzz4Gev4zSbGEJKsOmLjmETaW4Bb83+jibAIECglOaXDMUyCCvbXlU5 bgwWbZKw16Lr0poNzkB/7lrOvw35V8uKsMDJZWpzZjrkdbKeS/fYJpg7ARM50T307V8k zd5A8jJL01rk2bifuxFTDrTQBZIfcsEQkEdDEeWgBFIyWcSieVb+f/yimuY4NiHuK8mJ t21xYu1laLtBKut0plcVtCxUS2sZ1LdbItl1QfZ4DhjLbiYmXevL6vjSDEhF76J5Rnft mIqQ==
Received: by 10.68.138.229 with SMTP id qt5mr39725318pbb.122.1353343910095; Mon, 19 Nov 2012 08:51:50 -0800 (PST)
Received: from [192.168.15.99] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPS id c8sm6438197pav.4.2012.11.19.08.51.48 (version=SSLv3 cipher=OTHER); Mon, 19 Nov 2012 08:51:49 -0800 (PST)
Message-ID: <50AA63A4.9040109@gmail.com>
Date: Mon, 19 Nov 2012 09:51:48 -0700
From: Robert Smith <royersoftwareandservices@gmail.com>
Organization: Software and Services
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: vcarddav@ietf.org
References: <68174210-640D-42BF-995F-3987AD9AF3A8@alessandrorossini.org> <50A69522.6050401@gmail.com> <7F6B0CBF-B7A5-44D9-B3AF-B46133319C06@alessandrorossini.org>
In-Reply-To: <7F6B0CBF-B7A5-44D9-B3AF-B46133319C06@alessandrorossini.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 16:51:51 -0000

Robert Smith
714-989-6135

On 11/19/2012 05:42 AM, Alessandro Rossini wrote:
> 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. ...
Because when there is no standard way to put vendor extension in the 
objects, vendors put them in anyway and
break other vendors.