Subject: [VCARDDAV] Related Changes?

From: Renato Iannella <[email-masked]>
Date: Fri, 10 Dec 2010 11:10:43 +1000

I now see that the TYPE list for RELATED has been removed and replaced with the list from XFN.

A consequence of this is that the removal of AGENT (from V3) was supposed to be replaced with RELATED with TYPE=agent.

XFN has no "agent" semantics.

Another (ironic) consequence of this is that we now have even more "social network" semantics!! (ie sweetheart, crush, and a strange thing called muse)

I suggest the TYPE list for RELATED becomes a URI.

This will then allow values like:
    http://gmpg.org/xfn/11/friend
    http://purl.org/vocab/bio/0.1/agent  

Cheers

Renato Iannella
http://renato.iannella.it

---

From: Simon Perreault <[email-masked]>
Date: Fri, 10 Dec 2010 10:17:49 -0500

> XFN has no "agent" semantics.

Yes, I'm very worried about this.

Another important thing we lost is the "emergency" type.

Note also that all the business relationships are gone (e.g. "manager",
"assistant", etc.). I think that the people who use vCards in business
settings will not like this.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 10 Dec 2010 07:46:22 -0800

one way to solve this would be to setup an IANA registry where its 
initial content would be XFN and additional types we wanted such as 
manager, assistant, ...

Marc.

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

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 10 Dec 2010 10:50:38 -0500

Hi Marc,

> initial content would be XFN and additional types we wanted such as

I think that is the logical way to proceed assuming there is no objection 
from XFN folks.

-- 
Cyrus Daboo

---

From: Marc Blanchet <[email-masked]>
Date: Fri, 10 Dec 2010 08:09:06 -0800

Le 10-12-10 07:50, Cyrus Daboo a écrit :
> I think that is the logical way to proceed assuming there is no
> objection from XFN folks.

well, they could continue their XFN registry and the IANA one may not be 
fully synchronized at a given date. We can have a IANA registration 
policy that have expert review which would enable easy sync of the two 
registries.

Marc.

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 12 Dec 2010 21:47:01 -0700

> policy that have expert review which would enable easy sync of the two

Yes, that seems reasonable.

Peter

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

---

From: Andy Mabbett <[email-masked]>
Date: Mon, 13 Dec 2010 16:16:26 +0000

We'd also need to consider types for vCards about organisations, as
well as individuals; and relationships between them (treasurer-of,
employer, employee, etc.)

On 10 December 2010 15:50, Cyrus Daboo <[email-masked]> wrote:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Dec 2010 14:39:11 -0700

On 12/13/10 9:16 AM, Andy Mabbett wrote:
> We'd also need to consider types for vCards about organisations, 

Isn't that KIND?

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-15#section-6.1.4

###

6.1.4. KIND

   Purpose:  To specify the kind of object the vCard represents.

   Value type:  A single text value.

   Cardinality:  *1

   Special notes:  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, an x-name or an iana-token.  If
      this property is absent, "individual" MUST be assumed as default.

      Additional values may be registered from IANA (see
      Section 10.3.4).  A new value's specification document MUST
      specify which properties make sense for that new kind of vCard,
      and which do not.

   ABNF:

     KIND-param = "VALUE=text" / any-param
     KIND-value = "individual" / "group" / "org" / "location"
                / iana-token / x-name

###

> as

Relationships between vCards, or relationships between individuals? That
is, do you want the individual who is a treasurer for an organization to
be able to (1) place a pointer in her vCard to the vCard for her
organization (with some kind of unique identifier for each vCard), or
(2) place a notation in her vCard that she is a treasurer for her
organization? Whichever it is, I think this sounds like an extension,
not part of the core.

Peter

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

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 14 Dec 2010 22:08:26 +0000

>> We'd also need to consider types for vCards about organisations,

We're discussing "the TYPE list for RELATED".

> organization? Whichever it is, I think this sounds like an extension,

The latter already exists, surely?

In either case, if the facility exists for individual-individual
relationships; and for organisation-organisation relationships; then
it should be available for individual-organisation relationships.