Subject: [VCARDDAV] Past ORGs?

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

Hi all - is it possible to put a Date Range on the ORG field?

That is, I want to say I worked at Acme Inc from 2000 to 2005 ?

Cheers

Renato Iannella
http://renato.iannella.it

---

From: Markus Lorenz <[email-masked]>
Date: Tue, 05 Oct 2010 13:56:54 +0200

Hey Renato,

it seems to me that you are trying to put a whole CV into a vCard. I
don't think that's what it should be used for. I think supporting the
data of a CV would be much more complex.

If you start adding a date range for the ORG field, why not adding it
for ADR, TEL, EMAIL, IMAPP, TZ and GEO? I've actually the problem that
when someone changes their phone number, I want to store the old number
for being able to reconstruct communication like calls or text messages
later. So it would be useful to have a date range for all these fields
as well.

I think if vcard should provide features for tracking someone's whole
life in terms of available communication channels, past employers,
education, etc., the format had to be much more complex. Adding just
some of those features wouldn't be enough. And then, who would support
all these features? Even today most of the implementations I've seen
only support the very basic features. Like only one personal and one
working address.

In my opinion that would be the wrong way to go with vCard.

Regards,

Markus

Am 05.10.2010 03:11, schrieb Renato Iannella:
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 05 Oct 2010 08:40:29 -0400

Hi Markus,

> later. So it would be useful to have a date range for all these fields

One option here would be to use the group prefix with a new DATE-RANGE 
property, so:

date1.ORG:...
date1.ADR:...
date1.EMAIL:...
date1.DATE-RANGE:20050101/20070601
date2.ORG:...
date2.ADR:...
date2.EMAIL:...
date2.DATE-RANGE:20070701/20100601

However, we do have to be careful with overloading the group prefix too 
much given that there is only one level of hierarchy in the prefix.

That said I have heard from some people that being able to maintain 
biographical information in a vCard would be very useful. Of course an 
alternative is to define a "BIO" property with a URL value pointing to 
where the bio information is stored. So the first question is does it need 
to be "by value" or "by reference"?

-- 
Cyrus Daboo

---

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

> That is, I want to say I worked at Acme Inc from 2000 to 2005 ?

Sure, and it might take the form of a generic parameter applicable to
many properties.

But I think it would be better to use this as an extension. Since I've
seen this parameter used on social network sites (e.g. LinkedIn), maybe
it would be a good fit for the social networking extension draft?

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

---

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

On 2010-10-05 08:41, Simon Perreault wrote:
> But I think it would be better to use this as an extension.

s/use/define/

Simon

---

From: Joseph Smarr <[email-masked]>
Date: Tue, 5 Oct 2010 07:55:46 -0700

FYI, we allow this in PoCo (see
http://portablecontacts.net/draft-spec.html#organization_element), since
it's quite common these days. Essentially, if you just have one org with no
dates, it's considered to be your current title/company/etc, but you can
also put in past ones with date ranges. It also lets you put in a few extra
fields that vCard omits (like type/location/description) and groups them
together, unlike org and title which one has to assume refer to the same
thing. I think this is an improvement and worth considering for vCard core.

Thanks, js

On Tue, Oct 5, 2010 at 5:42 AM, Simon Perreault <[email-masked]
> wrote:

---

From: Renato Iannella <[email-masked]>
Date: Fri, 8 Oct 2010 21:50:44 +1000

On 5 Oct 2010, at 21:56, Markus Lorenz wrote:

> it seems to me that you are trying to put a whole CV into a vCard. 

I am (trying) to propose ways to make vcard more functionally ready for "web online directories".

So, adding an optional date-range field to some key fields, that sees the adoption of vCard grow.
is my aim!

BTW, since we have both BIRTH date and place, and DEATH date and place - describing what happens in-between makes sense ;-)

Cheers

Renato Iannella

---

From: Simon Perreault <[email-masked]>
Date: Fri, 08 Oct 2010 08:55:18 -0400

> I am (trying) to propose ways to make vcard more functionally ready for "web online directories".

It definitely is a common use-case for the "social" stuff.

Maybe if you sent to this list a proposal containing new text to be
added to the draft, the working group could come to consensus on it?

Thanks,
Simon

---

From: Renato Iannella <[email-masked]>
Date: Wed, 13 Oct 2010 14:03:13 +1000

I am proposing to add a new EFFECTIVE-DATES Property Parameter to vCard to support the need to indicate that some vCard Properties were effective over a certain fixed time period. (Otherwise, all properties are considered to be current).

STEP 1 - Add new DATE-RANGE Property Value Data Type
===========================

4.3.6.  DATE-RANGE

 A complete representations of time intervals identified by start and end as specified in [ISO.8601.2004] section 4.4.4.

 Representations (for Date and Time) with reduced accuracy are allowed.

 Examples for "date-range":

    2000-01-25T12:30:00/2005-02-25T12:30:00
    2000-01-25/2005-02-25
    2000-01/2005-02
    2000/2005

STEP 2 - Add new EFFECTIVE-DATES Property Parameters
===========================

5.14.  EFFECTIVE-DATES

   The EFFECTIVE-DATES parameter is optional, and is used to indicate that the
   corresponding instance of a property was effective (or valid) over the specified
   time period.

   When the parameter is absent, the default MUST be to interpret the
   property instance as being current.

   This parameter MAY be applied to any property that allows multiple
   instances.

   ABNF:

           effective-dates-param = "EFFECTIVE-DATES=" date-range

STEP 3 - Add EFFECTIVE-DATES Property Parameters to the following Properties:
===========================

- All Delivery Addressing Properties
- All Communications Properties
- All Geographical Properties
- All Organizational Properties
- All Explanatory Properties

Cheers

Renato Iannella

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 13 Oct 2010 09:53:39 -0400

Hi Renato,

--On October 13, 2010 2:03:13 PM +1000 Renato Iannella <[email-masked]> 
wrote:

>  A complete representations of time intervals identified by start and end
> as specified in [ISO.8601.2004] section 4.4.4.
>

We need to allow for open-ended ranges, i.e., ones where the start or end 
are not specified. I am not sure that ISO8601 provides for that, so we may 
need to adjust the syntax for our needs (e.g. use a single "*" to indicate 
open ended - so 2001/* means from 2001 onwards).

We need to be clear about whether the start and end represent "inclusive" 
or "exclusive" values. In iCalendar the DTSTART value is inclusive, but 
DTEND is exclusive (i.e. the end time is actually the first instant of time 
after the event, not the last instant of time in the event). For example, 
if I have two telephone numbers active over different but adjacent time 
periods, with the second one starting in 2003, do I specify:

TEL;EFFECTIVE-DATES=*/2003:xyz
TEL;EFFECTIVE-DATES=2003/*:abc

or

TEL;EFFECTIVE-DATES=*/2002:xyz
TEL;EFFECTIVE-DATES=2003/*:abc

The former assumes an exclusive end, the later an inclusive end.

I would prefer the value type name to be "PERIOD" to align it with 
iCalendar.

>    The EFFECTIVE-DATES parameter is optional, and is used to indicate
> that the    corresponding instance of a property was effective (or valid)
> over the specified    time period.
>

The value should be a list of date-ranges to allow for specifying multiple 
non-contiguous ranges on a single property.

We could probably shorten the name to just "EFFECTIVE".

-- 
Cyrus Daboo

---

From: Renato Iannella <[email-masked]>
Date: Thu, 14 Oct 2010 14:53:49 +1000

On 13 Oct 2010, at 23:53, Cyrus Daboo wrote:

> We need to allow for open-ended ranges, i.e., ones where the start or end are not specified. I am not sure that ISO8601 provides for that, so we may need to adjust the syntax for our needs (e.g. use a single "*" to indicate open ended - so 2001/* means from 2001 onwards).

Sure, or just "2001/" will do.

> We need to be clear about whether the start and end represent "inclusive" or "exclusive" values.
> In iCalendar the DTSTART value is inclusive, but DTEND is exclusive

Being consistent with iCal is good idea.

> I would prefer the value type name to be "PERIOD" to align it with iCalendar.

Sure

> We could probably shorten the name to just "EFFECTIVE".

Sure

Cheers

Renato Iannella

---

From: Markus Lorenz <[email-masked]>
Date: Thu, 14 Oct 2010 09:34:39 +0200

> STEP 1 - Add new DATE-RANGE Property Value Data Type

What about a formal description like:

   date-range = date-and-or-time "/" date-and-or-time

   date-range-list = date-range *("," date-range)

I'm not sure if "date-and-or-time" is the best solution, as it would
allow values with only time and no date. But at the moment I couldn't
think of a reason not to allow that. It shouldn't be the problem of the
vCard format whether or not a given date-range is meaningful.

With "date-range-list" we're quite near to being able to define business
hours for work phone numbers. We'd only have to introduce weekdays.
Don't know if anyone would like that. I guess this information could
already be included in the iCalendar to which FBURL points. At least for
the whole vCard and not a specific communications property.

Please use examples that show that both values don't have to have the
same date-and-or-time format. The examples should show a possible
difference between the first and the second value:

     2000-01-25T12:30:00/2005-02-25T12:30:00
     2000-01-25T123000+0200/2005-02-25            ; <==
     2000-01-25/2005-02-25
     2000/2005-02-25                              ; <==
     2000-01/2005-02
     2000/2005

Another thing I just saw: The examples for TIME, DATE-TIME,
DATE-AND-OR-TIME and TIMESTAMP in sections 4.3.2 to 4.3.5 never use
colons. I don't have access to ISO 8601:2004, but doesn't it allow
colons in time values?

Regards

Markus

---

From: Renato Iannella <[email-masked]>
Date: Thu, 14 Oct 2010 18:29:27 +1000

On 14 Oct 2010, at 17:34, Markus Lorenz wrote:

> I don't have access to ISO 8601:2004, but doesn't it allow
> colons in time values?

Yes, in ISO8601 "extended format", it allows colons in Time and dashes in Dates

Cheers

Renato Iannella

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 14 Oct 2010 09:15:28 -0400

Hi Markus,

> the whole vCard and not a specific communications property.

Well that is a slippery slope because if you want to refer to recurring 
times then you need to take timezones (Daylight Saving Time rules) into 
account. I really don't think we should go there. If we do stick with a 
full date-time option here then we need to be clear about the timezone - 
either we pick UTC always, or allow a TZID parameter to be encoded somehow, 
but that would be awkward given that this item is itself a parameter.

What I would prefer is to drop the time component altogether and just go 
with dates only - I think that covers the majority of use cases and is 
sufficient level of granularity. If you want to specify something like work 
hours etc then that should be done by a pointer to an iCalendar object (or 
we define a way to embed an iCalendar object directly in the vCard - which 
is interesting because we also want to have iCalendar objects that 
reference vCards).

-- 
Cyrus Daboo

---

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

On 14 Oct 2010, at 23:15, Cyrus Daboo wrote:

> What I would prefer is to drop the time component altogether and just go with dates only - I think that covers the majority of use cases and is sufficient level of granularity.

+1

Cheers

Renato Iannella

---

From: Markus Lorenz <[email-masked]>
Date: Thu, 14 Oct 2010 16:51:55 +0200

Am 14.10.2010 15:15, schrieb Cyrus Daboo:
> either we pick UTC always, or allow a TZID parameter to be encoded
> somehow, but that would be awkward given that this item is itself a
> parameter.

You're right. It would become much to complex. I was just venting my
thoughts. :)

> sufficient level of granularity. If you want to specify something like
> work hours etc then that should be done by a pointer to an iCalendar
> object (or we define a way to embed an iCalendar object directly in the
> vCard - which is interesting because we also want to have iCalendar
> objects that reference vCards).

+1