Subject: [VCARDDAV] vcardrev+xml next steps

From: Marc Blanchet <[email-masked]>
Date: Fri, 01 Oct 2010 13:24:39 -0400

After the concensus call about whether or not sending the vcardrev+xml 
drafts to IETF Last Call, there were a number of NOs that were expressed.

Given the late status of vcard, significant review over the years and 
current charter specific deliverables, there is no place for a major 
change of vcard. And there is no place for delaying the process forever.

However, if the NOs proponents can write a short description of the 
specific and actionable issues, then we can improve the specifications. 
Moreover, the best way to bring this input is to propose alternate text 
to the current text.

Since we are approaching next IETF, the deadline is set to October 11th, 
in order to find resolution on the issues and to give the document 
editors enough time to incorporate WG consensus regarding technical 
issues before the document submission deadline on 2010-10-25 
<http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79>

Therefore, this is a call to the NOs proponents to do the following:
- provide a short description of the specific and actionable issues
- provide alternate text to the current text
- by October 11th 23h59 GMT.
- each issue sent separately to the mailing list with a specific subject.

Regards,
Marc, co-chair.

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

---

From: Renato Iannella <[email-masked]>
Date: Mon, 4 Oct 2010 20:07:31 +1000

With the MEMBER field, I can create a list of vCard objects that are members of a named group.
(I assume the MEMBER field can define a UID field?)

However, can I say from a person's vCard object that they are a member of that group? (ie a bidirectional link)

If not, then I recommend we support this key structural feature for people/orgs/groups.

Cheers

Renato Iannella
http://renato.iannella.it

---

From: Simon Perreault <[email-masked]>
Date: Mon, 04 Oct 2010 08:24:59 -0400

> However, can I say from a person's vCard object that they are a member of that group? (ie a bidirectional link)

No, and this is intentional. It's a matter of access control. Only
people having write access to the group's vCard can change its members.

How would you deal with this issue with bidirectional membership?

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

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 04 Oct 2010 08:44:08 -0400

Hi Simon,

--On October 4, 2010 8:24:59 AM -0400 Simon Perreault 
<[email-masked]> wrote:

>> With the MEMBER field, I can create a list of vCard objects that are
>> members of a named group. (I assume the MEMBER field can define a UID
>> field?)
>>

Plus it would be very hard to maintain accurate back-links to groups unless 
all the vcards were "managed" in some fashion (e.g. something like the 
CardDAV directory gateway).

-- 
Cyrus Daboo

---

From: Renato Iannella <[email-masked]>
Date: Tue, 5 Oct 2010 11:07:16 +1000

> people having write access to the group's vCard can change its members.

Sorry - this is confusing me now....I was under the impression - and it states clearing in Section 9 - that "The vCard objects have no inherent authentication or privacy"

I want to express that I am a member of a Group. I think that I should be able to do that in my vCard object.

Cheers

Renato Iannella

---

From: Renato Iannella <[email-masked]>
Date: Tue, 5 Oct 2010 11:09:27 +1000

On 4 Oct 2010, at 22:44, Cyrus Daboo wrote:

> Plus it would be very hard to maintain accurate back-links to groups unless all the vcards were "managed" in some fashion (e.g. something like the CardDAV directory gateway).

Really not much different than me saying i am RELATED to Fred - he does not have to maintain a same relationship back to my vCard...

Cheers

Renato Iannella

---

From: Andrew McMillan <[email-masked]>
Date: Mon, 04 Oct 2010 22:15:51 -0400

On Tue, 2010-10-05 at 11:07 +1000, Renato Iannella wrote:
> Sorry - this is confusing me now....I was under the impression - and
> it states clearing in Section 9 - that "The vCard objects have no
> inherent authentication or privacy"
> 

Hi Renato,

It seems inevitable that automatically maintaining any bidirectionality
would fail against (e.g.) me adding you to a group I created in my
addressbook which references your vcard from your addressbook home on
that same server, for the permission reasons Simon mentioned.

Or (even more impossibly) maintaining backlinks to my offline
addressbook collection which refers to your online vcard.

However there might be reasons to indicate group membership in the
reverse direction (separately to any capability of automatically
maintaining such links), but it is not clear to me that this would offer
anything more than can be achieved by simply adding a category to the
vcard.

Regards,
					Andrew.

-- 
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com                            +64(272)DEBIAN
              "It's not just a computer -- it's your ass."
                             -- Cal Keegan

------------------------------------------------------------------------

---

From: Simon Perreault <[email-masked]>
Date: Tue, 05 Oct 2010 08:37:52 -0400

> inherent authentication or privacy"

This certainly does not imply that anybody can write to any vCard!

> I want to express that I am a member of a Group. I think that I
> should be able to do that in my vCard object.

Sure. Here's an example:

BEGIN:VCARD
VERSION:4.0
FN:Me
UID:urn:uuid:089e4fd1-8398-4af3-ac3e-e2b0cf7a2252
END:VCARD
BEGIN:VCARD
VERSION:4.0
KIND:group
FN:My group
MEMBER:urn:uuid:089e4fd1-8398-4af3-ac3e-e2b0cf7a2252
END:VCARD

Why does it need to be bidirectional?

Simon

---

From: Renato Iannella <[email-masked]>
Date: Thu, 7 Oct 2010 14:10:34 +1000

> Why does it need to be bidirectional?

No, it does not *have* to be bidirectional, I was wondering why MEMBER can only be used in a Group vCard and not in an individual vCard.

For example, I wanted to say that I am a member of the IEEE Computer Society.

Cheers

Renato Iannella

---

From: Tantek Çelik <[email-masked]>
Date: Sun, 10 Oct 2010 08:53:34 -0700

Based on a thorough section by section review[1], the changes and
feedback I have for vCard4 draft 13 fall into a general outline as
follows.

1. Explicitly state as a goal to have vCard4 be reasonably backward
compatible (i.e. with current implementations) of vCard3, both
syntactically, and from a schema perspective (e.g. don't mess with
structure of properties like N). This kind of practical backward
compat enabled publishers to start posting vCard3 even when most
consuming applications still only supported vCard2.1. The presence of
vCard3 data then encouraged consuming applications over time to adopt
it as well. I'd like to see the same successful adoption occur for
vCard4.

2. Keep the vCard4 core set of properties down to a minimum that has
been well established either in:
* Popular address book programs (e.g. ANNIVERSARY)
* Current well adopted mature RFCs (e.g. IMPP)
* Common additions by OpenID / Portable Contacts that have seen
adoption (e.g. SEX/GENDER, LANGUAGE, ACCOUNTS)
I believe this too will encourage better vCard4 adoption.

3. Drop other new vCard4 properties from the core and if they seem to
make sense, move them to extension specifications instead where they
can prove themselves out, e.g.:
* KIND - vCard should not expand scope like this. For new kinds of
objects new vThings should be created, and can be, outside the vCard
spec.
* XML - bad idea. Don't violate DRY. This encourages breaking interop
by potentially allowing implementations to look only at the XML or at
the actual properties in a vCard. Same on the publishing side.

Potential Extensions:
* genealogy extension (BIRTH location, DEATH location, DDAY datetime
of death, maybe more from GEDCOM)
* social networking extension (MEMBER, RELATED, maybe more from PoCo)
* calendar contact extension (FBURL, CALADRURI, CALURI)

vCard4 Section by section critique/feedback/suggestions.

I've written up my section by section feedback for vCard4 draft 13
here with short descriptions of the specific and actionable issues and
alternate text to the current text as well:

[1] https://wiki.mozilla.org/VCard4#draft_13_section_by_section_review

If necessary, I can send an email per section (or per feedback item
per section) to the mailing list with a specific subject, however that
will result in a lot of emails, and I wanted to avoid overloading the
group with such email if possible.  But if that's the preference of
the group/list/editors, I'm willing to go along and do so.

Thanks for your consideration,

Tantek Çelik
Mozilla

On Fri, Oct 1, 2010 at 10:24 AM, Marc Blanchet
<[email-masked]> wrote:
> current charter specific deliverables, there is no place for a major change
> of vcard. And there is no place for delaying the process forever.
>
> However, if the NOs proponents can write a short description of the specific
> and actionable issues, then we can improve the specifications. Moreover, the
> best way to bring this input is to propose alternate text to the current
> text.
>
> Since we are approaching next IETF, the deadline is set to October 11th, in
> order to find resolution on the issues and to give the document editors
> enough time to incorporate WG consensus regarding technical issues before
> the document submission deadline on 2010-10-25

-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5

---

From: Kevin Marks <[email-masked]>
Date: Mon, 11 Oct 2010 16:15:41 -0700

I broadly concur with Tantek's analysis here.

I differ on KIND -
We do need a way to distinguish individuals from organisations and utility
addresses, but the current draft does not provide good examples of the
differnt kinds, and 'thing' is too vague. The point is to make functionally
useful distinctions, not arbitrary categories.

The value may be one of: "individual" for a single
      person, "group" for a group, "org" for an organization, "location"
      for a named geographical place, "thing" for an inanimate object
      (e.g. a device, a server, etc.), an x-name or an iana-token.  If
      this property is absent, "individual" MUST be assumed as default.

Replace 'individual' with 'person'.

Drop 'group' and add 'list' for mailing lists and similar addresses
that need different treatment by user-agents (eg gmail's category
error of insistently trying to invite mailing lists to gtalk).

Drop 'thing' and add 'automated' for the kinds of auto responder email
addresses that updates from social networks, banks and the like.

Giving:

The value may be one of: "person" for a single person, "list" for an
address corresponding to a list of people (eg a mailing list), "org"
for an organization, "location" for a named geographical place,
"automated" for an automated system (eg a social network notifier,
bank address), an x-name or an iana-token.  If this property is
absent, "person" MUST be assumed as default

On Sun, Oct 10, 2010 at 8:53 AM, Tantek Çelik <[email-masked]>wrote:

> change
> specific
> in

---

From: Simon Perreault <[email-masked]>
Date: Tue, 12 Oct 2010 08:55:03 -0400

> [1] https://wiki.mozilla.org/VCard4#draft_13_section_by_section_review

Thanks. I'll go through it and start a new thread for each suggestion.

Simon

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 12 Oct 2010 09:55:42 -0400

Hi Tantek,

> it as well. I'd like to see the same successful adoption occur for

I would not object to reverting N back to the v3 definition. However, I do 
want to see TEL kept as a URI - or at least have the uri be the preferred 
form. Given that the tel: URI provides a syntactically well-defined way to 
do things like intl prefixes, extensions, access codes, all of which are 
heavily used today, I think it is vital to make this change.

> I believe this too will encourage better vCard4 adoption.

I am not convinced that splitting the spec at this point makes sense, but I 
would not oppose that idea either. Frankly multiple specs adds significant 
processing overhead that we could do without.

> objects new vThings should be created, and can be, outside the vCard

I consider KIND a requirement. Even now most vCard clients try and make a 
distinction between a "individual" card and a "org" card. Most of the time 
clients have to invent their own way to figure out which is which. KIND 
fixes that and gives us some other key items ("location" is particularly 
important).

> the actual properties in a vCard. Same on the publishing side.

I consider XML to be a requirement too. There is a lot of effort going on 
to embed vCard (and also iCalendar) in XML and an XML format makes it much 
easier to manage and manipulate with standard XML tools.

> * social networking extension (MEMBER, RELATED, maybe more from PoCo)

MEMBER is not strictly a social networking property, but rather a 
"directory" property. Instead what you could use is 
RELATED;TYPE="affiliation" (new TYPE value or perhaps "social network").

Also, I do think RELATED should be a "core" property. It is not just 
"social" but also "business" and "family". Many apps today provide ways to 
identify and link to family member or co-worker cards.

> * calendar contact extension (FBURL, CALADRURI, CALURI)

Calendar information is becoming more and more important I would urge that 
these remain part of the "core".

> the group/list/editors, I'm willing to go along and do so.

I will take a look at your review and comment where I feel I need to. 
Thanks for taking the time to do this.

-- 
Cyrus Daboo

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 12 Oct 2010 11:53:57 -0400

Hi Tantek,

> [1] https://wiki.mozilla.org/VCard4#draft_13_section_by_section_review

Below are my comments on specific sections you commented on (not all of 
them but the ones I care about most):

Section 5.4 PREF: a preference for properties that appear multi times is 
vital. Many people nowadays have multiple email addresses, IMs etc. There 
needs to be a way to specify an order.

Section 5.8 CALSCALE: see my reply to Rohit's comment on this. I believe 
there is a valid use case for this and there are clients that allow 
entering dates in other calendar scales by virtue of OS locale changes.

Section 5.12: the need for VERSION is specific to the XML property. An 
alternative would be to call it XML-VERSION to clarify its only use is on 
that property.

Section 6.1.4 KIND: as noted in my reply to your general points, I believe 
this should be kept.

Section 6.1.5 XML: the XML property is required to allow XML data 
extensions (ones not in the vcard XML namespace) to be transported intact 
in vCard text format. I believe we should keep this.

Section 6.2.2 N: I would be OK with a change back to the original N format.

Section 6.2.6 DDAY: as I have mentioned previous, the anniversary of a 
person's death is an important date in some cultures. This is not strictly 
a "genealogy" use case. That said, I do like your idea of allowing a 
"checkbox" option. That could trivially be done by allowing a boolean value 
in addition to date-time and text. I think that would be better than 
placing some special meaning on a particular text value.

Section 6.3.1 ADR: I think your recommendations are fine.

Section 6.4.1 TEL: I believe it makes sense to keep this as-is. tel: URIs 
have so many benefits over "free form" text entry that we should mandate 
their use from now on.

Section 6.6.5 MEMBER: I disagree. Many contact apps have the concept of a 
"group" and it should be possible to represent those in vCard too.

Section 6.6.6 RELATED: I disagree - this should be part of the base spec. 
Many contact apps allow specifying relationships to cards of family 
members, co-workers etc.

new Property ACCOUNT: not convinced we should have this right now. There is 
work going on to define an acct URI for example, that could be used for 
this.

Section 6.9 calendar props: I disagree - calendar information, in 
particular freebusy URLs are commonly included in contact apps that are 
part of PIM systems (once that including email, contacts and calendar into 
one). As a big proponent of trying to make internet calendaring and 
scheduling more ubiquitous I would strongly urge that we keep these.

Section 7 Sync: the issue of whether this should be a separate document or 
not came up in the past and the WG decided to keep it in the core. This new 
feature is in fact one of the key requirements for the v4 update so I 
strongly urge we keep this.

-- 
Cyrus Daboo

---

From: Ciny Joy <[email-masked]>
Date: Tue, 12 Oct 2010 09:28:49 -0700

On Oct 11, 2010, at 4:15 PM, Kevin Marks wrote:

> We do need a way to distinguish individuals from organisations and utility addresses, but the current draft does not provide good examples of the differnt kinds, and 'thing' is too vague. The point is to make functionally useful distinctions, not arbitrary categories.
> 
> Drop 'group' and add 'list' for mailing lists and similar addresses that need different treatment by user-agents (eg gmail's category error of insistently trying to invite mailing lists to gtalk).
> Drop 'thing' and add 'automated' for the kinds of auto responder email addresses that updates from social networks, banks and the like.
But 'thing' could refer to the office Fax machine too. Would automated make sense in that case?

Thanks,
Ciny
>  Giving:
> 
> The value may be one of: "person" for a single person, "list" for an address corresponding to a list of people (eg a mailing list), "org" for an organization, "location" for a named geographical place, "automated" for an automated system (eg a social network notifier, bank address), an x-name or an iana-token.  If this property is absent, "person" MUST be assumed as default
> 
> 
> On Sun, Oct 10, 2010 at 8:53 AM, Tantek Çelik <[email-masked]> wrote:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Kevin Marks <[email-masked]>
Date: Tue, 12 Oct 2010 16:40:50 -0700

Oops, accidentally dropped the list from the reply.

On Tue, Oct 12, 2010 at 11:45 AM, Ciny Joy <[email-masked]> wrote:

> Hi,
>    I look at this from the calendaring angle and the fax machine would be a
> separate entity that I can schedule. I would have a separate directory entry
> for the fax machine itself with its different properties. I was using the
> KIND property to indicate the type of entity which in turn defined some of
> the scheduling aspects. Don't think having the FAX type in tel would work in
> my scenario.
>

I am very puzzled by the scenario of scheduling a meeting with a fax
machine. I think this is an over-theoretical case.

>
> Thanks,
> Ciny
>
> On Oct 12, 2010, at 9:59 AM, Kevin Marks wrote:
>
> We already have a FAX type in tel for that. Do you really care about the
> machine or the organization it is based in?
> On Oct 12, 2010 9:29 AM, "Ciny Joy" <[email-masked]> wrote:
> >
> >> We do need a way to distinguish individuals from organisations and
> utility addresses, but the current draft does not provide good examples of
> the differnt kinds, and 'thing' is too vague. The point is to make
> functionally useful distinctions, not arbitrary categories.
> >>
> >> Drop 'group' and add 'list' for mailing lists and similar addresses that
> need different treatment by user-agents (eg gmail's category error of
> insistently trying to invite mailing lists to gtalk).
> address corresponding to a list of people (eg a mailing list), "org" for an
> organization, "location" for a named geographical place, "automated" for an
> automated system (eg a social network notifier, bank address), an x-name or
> an iana-token. If this property is absent, "person" MUST be assumed as
> default
> >>
> >>

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 12 Oct 2010 20:16:06 -0400

Hi Kevin,

--On October 12, 2010 4:40:50 PM -0700 Kevin Marks <[email-masked]> 
wrote:

> Hi,
>    I look at this from the calendaring angle and the fax machine would
> be a separate entity that I can schedule. I would have a separate
> directory entry for the fax machine itself with its different properties.
> I was using the KIND property to indicate the type of entity which in
> turn defined some of the scheduling aspects. Don't think having the FAX
> type in tel would work in my scenario.
>
>
>
>

In a simple scenario that might seem to be the case. But consider a 
portable fax machine belonging to the sales team that has to be booked out 
when someone needs to take it on a trip.

There are plenty of examples of such "portable" resources that do need to 
be treated this way, and there are plenty of other examples that don't. 
Either way, resource scheduling is justified.

-- 
Cyrus Daboo