Subject: Re: [VCARDDAV] Last call on vCard extensions from OMA CAB

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 05 Apr 2012 14:21:11 -0600

On 3/5/12 6:38 AM, Simon Perreault wrote:

> This is to initiate a two week working group last call on this draft:
> https://datatracker.ietf.org/doc/draft-ietf-vcarddav-oma-cab-extensions/

Sorry about the late feedback -- things got kind of busy there before
and during IETF 83. :)

Some time ago I reviewed an earlier version of this document. The
revised I-D is much more readable and well-focused, so kudos to the
authors! I have only a few small comments...

Abstract and Introduction: "important" contact fields -- they are
important to CAB but not *necessarily* to anyone else (although they
seem generally useful to me). I'd remove this word.

Section 1.1: s/search paradigm/search function/

The LEVEL parameter has possible (do you mean "allowable" or "defined"?)
values of "beginner", "average", and "expert" when used with EXPERTISE
and "high", "medium", and "low" when used with HOBBY or INTEREST. Why
not just use "high", "medium", and "low" for all three? IMHO an
EXPERTISE of "low" is the same as an EXPERTISE of "beginner" (etc.) so I
see no reason for different lexical representations of what is the same
basic concept.

Peter

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

---

From: Likepeng <[email-masked]>
Date: Fri, 6 Apr 2012 07:56:00 +0000

Thanks Peter for the review.

I also reviewed the spec again, and find an editorial issue:

In Abstract and Introduction section: we need to add reference to OMA Data Synchronization, 
here is the reference we can add in the reference section:

   [OMA-DS]  Open Mobile Alliance, "Data Synchronization Protocol", March 2009, <http://www.openmobilealliance.org/Technical/release_program/docs/copyrightclick.aspx?pck=DS&file=V1_2_2-20090319-A/OMA-TS-DS_Protocol-V1_2_2-20090319-A.pdf>.

Kind Regards
Kepeng
-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Peter Saint-Andre
发送时间: 2012年4月6日 4:21
收件人: Simon Perreault
抄送: [email-masked]
主题: Re: [VCARDDAV] Last call on vCard extensions from OMA CAB

Peter

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

_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 06 Apr 2012 11:31:23 -0400

Hi,
My feedback (sorry it is late):

Major:

- There is no mention of i18n issues. In particular all the freeform text 
properties need to support LANGUAGE and ALTID parameters, and follow the 
behaviors of those defined in 6350. Basically, all the properties defined 
in this spec must follow similar syntax to TITLE and ROLE defined in 6350, 
since they are similar in nature to those. Please see the 6350 ABNF for the 
TITLE and ROLE parameters and make sure similar parameters are included - 
though I think there is an open question as to whether a TYPE parameter 
should be allowed on the new properties. For example, in my vCard I might 
want to put:

EXPERTISE;TYPE=home;LEVEL=beginner:kids soccer coach
EXPERTISE;TYPE=work;LEVEL=expert:Python programmer

So I think TYPE is valuable to have on the new properties.

- ORG-DIRECTORY - why is this a property as opposed to a parameter on the 
6350 ORG property? If it remains a property then it needs to have similar 
parameters to ORG defined on it (at least TYPE, PREF, PID and ALTID). Maybe 
also LANGUAGE if the URI points to a web page that might have localized 
variants?

- INDEX - who is responsible for making sure INDEX is specified 
consistently across a set of properties? What happens if two properties 
have the same INDEX value? What if some properties have INDEX and others do 
not - what is the default value? Are negative values (or zero) allowed?

- LEVEL - should allow for ' / iana-token / x-name' as value options and 
should define a registry of values.

Minor:

- §2.1,2.2,2.3 Value type - change 'A single string value.' to 'A single 
text value.'

Nits:

- §1.1, ¶3: change 'managed' to 'manages'

- §2.1, might be better phrasing Purpose this way:

    To specify a field of expertise for the object that the vCard refers to.

-- 
Cyrus Daboo

---

From: Renato Iannella <[email-masked]>
Date: Sun, 8 Apr 2012 21:21:03 +1000

>> https://datatracker.ietf.org/doc/draft-ietf-vcarddav-oma-cab-extensions/

The update seem fine.
My previous comment was on INTEREST as it was also proposed in "To Represent the Social Network Information of an Individual [1].
But I now assume [1] has expired?

Cheers

Renato Iannella
http://renato.iannella.it

[1] http://tools.ietf.org/html/draft-george-vcarddav-vcard-extension-03

---

From: Barry Leiba <[email-masked]>
Date: Sun, 8 Apr 2012 11:58:52 -0400

> [1] http://tools.ietf.org/html/draft-george-vcarddav-vcard-extension-03

That expired quite some time ago, and was replaced by this
working-group document:
  http://tools.ietf.org/html/draft-ietf-vcarddav-social-networks

I thought we'd set the replacement information in the tracker, but I
guess not; the chair might consider asking iesg-secretary to do that.

In any case, the social-networks document will almost certainly be
dropped by the working group, owing to lack of interest in working on
it.  We have tried for two years to get social networking developers
to work with us on it, and they just don't want to.  See this message
for information about the latest attempt:
  http://www.ietf.org/mail-archive/web/vcarddav/current/msg02509.html

If there's stuff in that document that you think should be carried
forward, please propose a way to do it.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 08 Apr 2012 10:12:58 -0600

> guess not; the chair might consider asking iesg-secretary to do that.

The author can do it, and ietf-action is better because iesg-secretary
is for special IESG people. ;-)

Peter

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