Subject: Re: [VCARDDAV] I-D Action:draft-ietf-vcarddav-vcardrev-07.txt

From: Simon Perreault <[email-masked]>
Date: Mon, 01 Jun 2009 08:33:45 -0400

Andy Mabbett wrote, on 2009-05-29 16:50:
> My last post on the subject was:
> 
>   <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00669.html>
> 
> and the only reply was:
> 
>   <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00670.html>

There was also this one:

http://www.ietf.org/mail-archive/web/vcarddav/current/msg00675.html

> Some may recall that I'd earlier provided a "Straw-man" and listed
> issues as I saw them in July 2008:
> 
>   <http://www.ietf.org/mail-archive/web/vcarddav/current/msg00531.html>

This is not the proposal that was asked for.

You see, the problem with adding stuff is where do we stop?

In the current draft we have devised a mechanism for future extensions (see
Section 11.2). Once vCard 4 is published, anyone can write an RFC for new vCard
"objects" (i.e. properties, parameters, value types, etc.) and register it from
IANA. This is one option that could be possible with the numerous hCard extensions.

Another option is including the extensions in the vCard 4 base draft. Good
reasons for doing so, IMHO, would be:
- The extension provides functionality that was present in vCard 3 or earlier.
- It provides functionality that is necessary for extensions to build upon.
- It is needed by a majority of vCard implementations.

In my opinion, the "vessel", "continent", and "body" extensions do not fit any
of these criteria and thus should go into a separate RFC.

As for the extensions to GEO for non-WGS84 reference systems, they must be
considered separately, in the context of the geo URI scheme draft
(draft-mayrhofer-geopriv-geo-uri) since this is what vCard 4 is now using.

Thanks,
Simon
-- 
STUN/TURN server    --> http://numb.viagenie.ca
Interplanetary news --> http://reeves.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Jun 2009 07:56:55 -0600

> - It is needed by a majority of vCard implementations.

Those seem like reasonable criteria.

> of these criteria and thus should go into a separate RFC.

Agreed.

> (draft-mayrhofer-geopriv-geo-uri) since this is what vCard 4 is now using.

Agreed.

Peter

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

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 2 Jun 2009 22:23:41 +0100

In message <[email-masked]>, Simon Perreault
<[email-masked]> writes

>http://www.ietf.org/mail-archive/web/vcarddav/current/msg00675.html

Thank you. I'd missed that.

>This is not the proposal that was asked for.

I'm not clear what you mean - asked for where?

>You see, the problem with adding stuff is where do we stop?

No; that's the problem with adding stuff *for no good reason*. I believe
that there are good reasons to add the things I've suggested.

[...]
>of these criteria and thus should go into a separate RFC.

Then we have a difference of opinion.

At the very least, I know people who cannot correctly encode the address
of their living place at present. Consider (a real address, with values
changed to protect privacy; "NB" is short for "narrow boat")

        NB "Pendragon", Greenfinch Wharf, Canal Street, Birmingham,
        England B1 1BB

which should map to:

        NB "Pendragon"          =       vessel
        Greenfinch Wharf        =       extended-address
        Canal Street            =       street-address
        Birmingham              =       locality
        England                 =       country-name
        B1 1BB                  =       postal-code

>(draft-mayrhofer-geopriv-geo-uri) since this is what vCard 4 is now using.

As you will have seen, this discussion is progressing, and has moved to
the GEOPRIV list.

-- 
Andy Mabbett

---

From: Simon Perreault <[email-masked]>
Date: Tue, 02 Jun 2009 19:04:48 -0400

>         NB "Pendragon", Greenfinch Wharf, Canal Street, Birmingham,

1. Here's one naive attempt:

ADR:;NB "Pendragon";Greenfinch Wharf, Canal Street;Birmingham;;
  B1 1BB;England

Could you please explain what's wrong with it?

2. We *know* that the ADR model is incomplete. However, it is based on 
the well-established X.520 model and thus is useful for many current 
applications. For all other cases we also have LABEL.

I don't think we should extend the ADR model, otherwise we will lose the 
1-to-1 mapping with X.520 (and all other file formats based on it).

Instead it would be interesting to see a proposal for a new property 
(ADR2?) based on a different model (hCard? GML? PIDF-LO?).

Thanks,
Simon

---

From: Andy Mabbett <[email-masked]>
Date: Wed, 3 Jun 2009 00:37:13 +0100

In message <[email-masked]>, Simon Perreault 
<[email-masked]> writes

>Could you please explain what's wrong with it?

I refer you to the mapping in my previous mail, which you have excised 
from the quoted material in yours; in part:

         NB "Pendragon"          =       vessel

-- 
Andy Mabbett

---

From: Simon Perreault <[email-masked]>
Date: Tue, 02 Jun 2009 20:04:15 -0400

>         Canal Street            =       street-address

Why do you insist in this particular mapping?

Simon