Re: [VCARDDAV] review of draft-cauchie-vcarddav-oma-cab-extensions

Likepeng <likepeng@huawei.com> Thu, 23 June 2011 02:13 UTC

Return-Path: <likepeng@huawei.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 1A49A1F0C44 for <vcarddav@ietfa.amsl.com>; Wed, 22 Jun 2011 19:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.074
X-Spam-Level:
X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=0.525, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 DPLerCtXjOTO for <vcarddav@ietfa.amsl.com>; Wed, 22 Jun 2011 19:13:14 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id DAF681F0C3D for <vcarddav@ietf.org>; Wed, 22 Jun 2011 19:13:13 -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 <0LN800A7B0U0FX@szxga04-in.huawei.com> for vcarddav@ietf.org; Thu, 23 Jun 2011 10:13:12 +0800 (CST)
Received: from szxrg01-dlp.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 <0LN8009TL0U0VA@szxga04-in.huawei.com> for vcarddav@ietf.org; Thu, 23 Jun 2011 10:13:12 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACA13957; Thu, 23 Jun 2011 10:13:11 +0800 (CST)
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 23 Jun 2011 10:13:09 +0800
Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.112]) by szxeml409-hub.china.huawei.com ([169.254.57.252]) with mapi id 14.01.0270.001; Thu, 23 Jun 2011 10:13:11 +0800
Date: Thu, 23 Jun 2011 02:13:10 +0000
From: Likepeng <likepeng@huawei.com>
In-reply-to: <4E026E3D.2040306@stpeter.im>
X-Originating-IP: [10.70.109.110]
To: Peter Saint-Andre <stpeter@stpeter.im>, CardDAV <vcarddav@ietf.org>
Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F22B876D@szxeml506-mbx.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Accept-Language: zh-CN, en-US
Thread-topic: [VCARDDAV] review of draft-cauchie-vcarddav-oma-cab-extensions
Thread-index: AQHMMSz/1oB8J9phMUi+k+7O93FKE5TKE/mg
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <4E026E3D.2040306@stpeter.im>
Cc: "dany.cauchie@orange-ftgroup.com" <dany.cauchie@orange-ftgroup.com>
Subject: Re: [VCARDDAV] review of draft-cauchie-vcarddav-oma-cab-extensions
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: Thu, 23 Jun 2011 02:13:15 -0000

Thanks Peter for the review.

>1. Is the OMA spec stable? Can it be added to the Normative References section? Without being able to look at that spec, aspects of this I-D cannot be easily understood.

Yes, it is stable. We will add that as Normative Reference in the revision.

>2. Some of these properties seem quite OMA-specific. Do they really belong in the global namespace? (Others are more general and I think they're fine for inclusion in the global namespace.)

Yes, some of the properties are only applied in the OMA context.

> 3. I like CONTACT-LANGUAGE and I'm wondering why we didn't define that already in the base vCard4 spec. :)

OK. Glad to hear that.

> 4. SERVICE seems somewhat underspecified; in particular the "label" is just a free-form name for the service, but it seems that different people might call the same service by different names, leading to confusion (e.g., "facebook" vs. "FaceBook", "Google" vs. "Gmail" vs."Google Talk").

Let's improve that in the next version.

>5. How is PUBLICNOTE different from NOTE in the base spec? The example ("Out of my office today") seems more like presence than vCard.

Let me check with Dany (one of the co-author) about this.

> 6. Clearly there is some relationship among CONTACT-STATUS-MAIN, CONTACT-STATUS-UPDATED, and CONTACT-STATUS-TEMPORARY based on a subscription model that is not described here. It would be good to provide a high-level overview of the subscription model so that readers understand the relationship. (This would also help tie in ACCEPT, ACK, and CONTACT-ID-REF.) Also, are there security implications involved in exposing these subscription states in a public manner? I think there might be...

Yes, it is related to subscription model. And we will add more information to the draft to explain that.

Kind Regards
Kepeng

-----Original Message-----
From: vcarddav-bounces@ietf.org [mailto:vcarddav-bounces@ietf.org] On Behalf Of Peter Saint-Andre
Sent: Thursday, June 23, 2011 6:36 AM
To: CardDAV
Subject: [VCARDDAV] review of draft-cauchie-vcarddav-oma-cab-extensions

<hat type='individual'/>

A few comments on draft-cauchie-vcarddav-oma-cab-extensions...

1. Is the OMA spec stable? Can it be added to the Normative References section? Without being able to look at that spec, aspects of this I-D cannot be easily understood.

2. Some of these properties seem quite OMA-specific. Do they really belong in the global namespace? (Others are more general and I think they're fine for inclusion in the global namespace.)

3. I like CONTACT-LANGUAGE and I'm wondering why we didn't define that already in the base vCard4 spec. :)

4. SERVICE seems somewhat underspecified; in particular the "label" is just a free-form name for the service, but it seems that different people might call the same service by different names, leading to confusion (e.g., "facebook" vs. "FaceBook", "Google" vs. "Gmail" vs.
"Google Talk").

5. How is PUBLICNOTE different from NOTE in the base spec? The example ("Out of my office today") seems more like presence than vCard.

6. Clearly there is some relationship among CONTACT-STATUS-MAIN, CONTACT-STATUS-UPDATED, and CONTACT-STATUS-TEMPORARY based on a subscription model that is not described here. It would be good to provide a high-level overview of the subscription model so that readers understand the relationship. (This would also help tie in ACCEPT, ACK, and CONTACT-ID-REF.) Also, are there security implications involved in exposing these subscription states in a public manner? I think there might be...

Peter

--
Peter Saint-Andre
https://stpeter.im/