IETF Logo Mail Archive

Re: [VCARDDAV] Synchronization: experimental RFC?

Kepeng Li <likepeng@huawei.com> Wed, 07 April 2010 01:40 UTC

Return-Path: <likepeng@huawei.com>
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 86ACC3A67D4 for <vcarddav@core3.amsl.com>; Tue, 6 Apr 2010 18:40:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.294
X-Spam-Level: **
X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1]
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 GCyPLKz9U3Xa for <vcarddav@core3.amsl.com>; Tue, 6 Apr 2010 18:40:56 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5B0383A6781 for <vcarddav@ietf.org>; Tue, 6 Apr 2010 18:40:56 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0H00C52GNVSV@szxga04-in.huawei.com> for vcarddav@ietf.org; Wed, 07 Apr 2010 09:40:43 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L0H00I71GNVAD@szxga04-in.huawei.com> for vcarddav@ietf.org; Wed, 07 Apr 2010 09:40:43 +0800 (CST)
Received: from l43852k ([10.70.109.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L0H00D04GNRRR@szxml04-in.huawei.com> for vcarddav@ietf.org; Wed, 07 Apr 2010 09:40:43 +0800 (CST)
Date: Wed, 07 Apr 2010 09:40:39 +0800
From: Kepeng Li <likepeng@huawei.com>
In-reply-to: <4BBB4A69.5010706@viagenie.ca>
To: 'Marc Blanchet' <marc.blanchet@viagenie.ca>, 'Simon Perreault' <simon.perreault@viagenie.ca>
Message-id: <010001cad5f3$5412ae00$fc380a00$@com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: text/plain; charset="gb2312"
Content-language: zh-cn
Content-transfer-encoding: quoted-printable
Thread-index: AcrVmKOZ6j3TM2BRQKybLGye7szr/QAWcsoA
References: <4BBB344E.1090301@viagenie.ca> <4BBB4A69.5010706@viagenie.ca>
Cc: vcarddav@ietf.org
Subject: Re: [VCARDDAV] Synchronization: experimental RFC?
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, 07 Apr 2010 01:40:57 -0000

>short summary: leave it as is, unless text is flawed.
+1

Another thing is, separating it into another draft will require extra work
on both drafts. We could put this kind of effort to identify potential bugs,
and fix them.

Kepeng
-----邮件原件-----
发件人: vcarddav-bounces@ietf.org [mailto:vcarddav-bounces@ietf.org] 代表
Marc Blanchet
发送时间: 2010年4月6日 22:51
收件人: Simon Perreault
抄送: vcarddav@ietf.org
主题: Re: [VCARDDAV] Synchronization: experimental RFC?

To me, the question is not the number of RFCs. One of the key issues 
that has been reported when we started working on vcard4 was about 
synchronisation. We did spent a lot of wg time trying to come to a 
solution. So to me, if we don't deliver any text on synch, then we are 
missing an important piece.

Moreover, our charter specifically talks about sync.:
") A revision of the vCard specification (RFC2426) at proposed
standard status. This revision shall include other vCard standardized
extensions (RFC 2739, 4770) and extensions assisting synchronization
technologies (for example, a per-entry UUID or per-attribute sequence
number). Other extensions shall be considered either in the base
specification or in additional documents."

Therefore, we must have sync section.

About 7.2.5, it might be not fully informative, but I would suggest that 
we should not try to be perfect for this version of vcard4, as intended 
to be Proposed Standard RFC. When more experience with implementations 
and synchronisation will be in the field, we could revisit this section 
7 and add more clues about what we found and move it to Draft Standard.

short summary: leave it as is, unless text is flawed.

Marc, as individual.

Simon Perreault a écrit :
> WG,
> 
> Is the section on synchronization (section 7) experimental? Should it be 
> moved to a separate RFC with experimental status? It has never been 
> implemented. See section 7.2.5 in particular...
> 
> It would be easy for me to do so if that is the working group's 
> consensus, so I don't care. (Actually, it would potentially result in a 
> higher RFC count for me, so I do care!)
> 
> Simon


-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

_______________________________________________
VCARDDAV mailing list
VCARDDAV@ietf.org
https://www.ietf.org/mailman/listinfo/vcarddav

v2.23.0 | Report a Bug | By Email