Re: [VCARDDAV] wg concensus to publish?

Mike Douglass <douglm@rpi.edu> Wed, 29 September 2010 14:43 UTC

Return-Path: <douglm@rpi.edu>
X-Original-To: vcarddav@core3.amsl.com
Delivered-To: vcarddav@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3001A3A6D82 for <vcarddav@core3.amsl.com>; Wed, 29 Sep 2010 07:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.793
X-Spam-Level:
X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfxZ4oDGABXk for <vcarddav@core3.amsl.com>; Wed, 29 Sep 2010 07:43:14 -0700 (PDT)
Received: from smtp5.server.rpi.edu (smtp5.server.rpi.edu [128.113.2.225]) by core3.amsl.com (Postfix) with ESMTP id 70CEE3A6B5E for <vcarddav@ietf.org>; Wed, 29 Sep 2010 07:43:13 -0700 (PDT)
Received: from [128.113.124.139] (crustacean-11.dynamic.rpi.edu [128.113.124.139]) (authenticated bits=0) by smtp5.server.rpi.edu (8.13.1/8.13.1) with ESMTP id o8TEhUww023894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Sep 2010 10:43:40 -0400
Message-ID: <4CA35092.6080506@rpi.edu>
Date: Wed, 29 Sep 2010 10:43:30 -0400
From: Mike Douglass <douglm@rpi.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20100908 Lightning/1.0b2 Thunderbird/3.1.3
MIME-Version: 1.0
To: jsmarr@stanfordalumni.org
References: <mailman.0.1285713916.16023.vcarddav@ietf.org> <D4F81374-AEA3-4CB7-9A50-BED4B412AAA2@Khare.org> <4EA4C9A81F6E7DCA25EF49CA@socrates.local> <1EDEC283-554A-4C2C-8D45-D57E813A5A7E@Khare.org> <4CA2CA92.1010606@rpi.edu> <AANLkTi=6k8Po7O72yQ8c1LJ2PQ=+TYdqDYqOjTdNTu9Y@mail.gmail.com>
In-Reply-To: <AANLkTi=6k8Po7O72yQ8c1LJ2PQ=+TYdqDYqOjTdNTu9Y@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010807090507070103020407"
X-Bayes-Prob: 0.0001 (Score 0)
X-RPI-SA-Score: 2.20 (**) [Hold at 15.00] HTML_MESSAGE, RATWARE_GECKO_BUILD, SARE_LWSHORTT, 22490(-25)
X-CanItPRO-Stream: outgoing
X-Canit-Stats-ID: Bayes signature not available
X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.2.225
Cc: CardDAV <vcarddav@ietf.org>
Subject: Re: [VCARDDAV] wg concensus to publish?
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 29 Sep 2010 14:43:22 -0000

  Mostly because I believe that vcard 4 is an honest - though maybe not 
perfect - attempt to build on the experience of vcard3.

The discussion over the use of SORT-AS is a case in point. Vcard 3 
implementations implement ordering in almost as many ways as there are 
applications. My experience with vcard 3 has been that importing data 
from one application into another almost always leads to misordered and 
duplicated data - some will insist on the data being written they way 
they want to order it, others try to parse it and order according to the 
result and so on. The end result is that I almost always end up 
reentering fields.

I don't believe vcard4 is the answer to everything but it's a good start 
and my experience suggests that the mismatch between v4 and what follows 
will be much less than between almost any 2 current v3 implementations.

Filip Navara  has pointed out some of the specific remaining issues - 
there's still time to discuss these in the context of a last call but I 
still don't believe that publishing as an RFC should hinder the efforts 
at alignment. It might even help as we can concentrate on that issue 
rather than essentially restarting the whole process.

On 09/29/2010 02:01 AM, Joseph Smarr wrote:
> Mike-I agree with you assessment, which is why I would ask the 
> flip-side of your question: why publish vcard 4 unless/until we think 
> it will materially solve the problems you point out? Publishing a new 
> spec always has a cost--it will add confusion and consume time and 
> increase legacy, as there's one more version of one more spec to learn 
> and support--and if the immediate next step is to work on 4.1 with 
> better alignment, more simplicity, etc.--as you and others have often 
> suggested--then I thing it begs the question of what we gain by 
> publishing now, other than "it's been 2 years, so people would like to 
> see a result", which i don't think is a good enough reason. :)
>
> On Tue, Sep 28, 2010 at 10:11 PM, Mike Douglass <douglm@rpi.edu 
> <mailto:douglm@rpi.edu>> wrote:
>
>      My experience as a user is that current address book
>     implementations are a completely non-interoperable disaster.
>
>     I have had the unhappy experience of moving my wifes contacts 3
>     times - which has largely led her back to a paper address book -
>     and i completely concur with her decision. I cannot, as an
>     implementor, defend the current state of affairs. If you never
>     have to move your contacts you may be fine. If you do, they will
>     end up misordered, duplicated or just missing - I don't even move
>     my own contacts - it almost never works.
>
>     I mostly keep quiet at home about being a vcard 4/carddav implementor.
>
>     This is all to say that we have nothing to congratulate ourselves
>     on with the current state of affairs.
>
>     One of the important questions for the short term - still
>     unanswered - is:
>
>     If we go ahead and publish vcard 4 core, what will prevent us
>     getting better alignment with PoCo/W3c etc within some reasonable
>     period of time in say version 4.1?
>
>
>     On 09/28/2010 11:32 PM, Rohit Khare wrote:
>
>         On Sep 28, 2010, at 8:03 PM, Cyrus Daboo wrote:
>
>             I am a little confused by this statement. What "brand
>             name" and which "non-IETF" standard are you referring to?
>
>
>         You are correct, and I should be more careful. The pre-XML
>         vCard3 standard (RFC 2425/6) is a fairly direct mapping of the
>         work of the Versit Consortium, as acknowledged in the RFC (as
>         was vCard 2.1 at the IMC, in turn).
>
>         You are also correct that I shouldn't call vCard "non-IETF",
>         since rev 3.0 is a Proposed Standard regardless of its
>         origins. vCard4 is a significant improvement (but all the
>         same, a significant departure) from the line-by-line encoding
>         that's in the marketplace today.
>
>         The sense in which I believe my observation was intended to be
>         fair and helpful is that the term "vCard" as used by range of
>         products, from embedded hardware to the latest in social Web
>         services in the cloud, all refer to the loosely interoperable
>         line-by-line encoding that's been in use for almost 20 years.
>
>         Best,
>          Rohit
>
>         http://en.wikipedia.org/wiki/VCard
>
>             Versitcard was originally proposed in 1995 by the Versit
>             Consortium, which consisted of Apple, AT&T Technologies
>             (later Lucent), IBM and Siemens. In December 1996,
>             ownership of the format was handed over to the Internet
>             Mail Consortium, a trade association for companies with an
>             interest in Internet e-mail.
>
>         See also the press release handing off to Paul Hoffman,
>         http://www.imc.org/pdi/versit-to-imc.html
>         _______________________________________________
>         VCARDDAV mailing list
>         VCARDDAV@ietf.org <mailto:VCARDDAV@ietf.org>
>         https://www.ietf.org/mailman/listinfo/vcarddav
>
>
>     -- 
>
>     Mike Douglass douglm@rpi.edu <mailto:douglm@rpi.edu>
>     Senior Systems Programmer
>     Communication&  Collaboration Technologies      518 276
>     6780(voice) 2809
>     (fax)
>     Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
>
>
>     _______________________________________________
>     VCARDDAV mailing list
>     VCARDDAV@ietf.org <mailto:VCARDDAV@ietf.org>
>     https://www.ietf.org/mailman/listinfo/vcarddav
>
>

-- 

Mike Douglass                           douglm@rpi.edu
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180