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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Jun 2011 16:35:41 -0600

<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/

---

From: Likepeng <[email-masked]>
Date: Thu, 23 Jun 2011 02:13:10 +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: [email-masked] [mailto:[email-masked]] 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'/>

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/

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 23 Jun 2011 10:37:34 -0400

Hi ,

> confusion (e.g., "facebook" vs. "FaceBook", "Google" vs. "Gmail" vs.

WRT SERVICE I would like to draw people's attention to 
<http://tools.ietf.org/id/draft-daboo-vcard-service-type-00.txt> (which is 
now expired). This takes a different approach of defining a SERVICE-TYPE 
parameter for use on existing properties such as EMAIL and IM. This allow 
those communications properties to be "tagged" with the service provider 
identifier.

I wonder whether instead of SERVICE we should be using the existing vCard 
URL property combined with SERVICE-TYPE. The existing property already 
states "social networking site identifiers" as one possible use case. I 
realize this might make it a little bit harder to do a simple one-to-one 
mapping with OMA attributes, but I do think we should try and re-use 
existing vCard properties where ever it makes sense.

-- 
Cyrus Daboo

---

From: Simon Perreault <[email-masked]>
Date: Mon, 27 Jun 2011 07:37:10 -0400

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

As I said in my review (which I just posted), we already have LANG in 
the base spec...

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org