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

From: [email-masked]
Date: Mon, 3 Nov 2008 12:45:01 -0800 (PST)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the vCard and CardDAV Working Group of the IETF.

	Title           : vCard Format Specification
	Author(s)       : S. Perreault, P. Resnick
	Filename        : draft-ietf-vcarddav-vcardrev-04.txt
	Pages           : 66
	Date            : 2008-11-03

This document defines the vCard data format for representing and
exchanging a variety of information about an individual (e.g.,
formatted and structured name and delivery addresses, email address,
multiple telephone numbers, photograph, logo, audio clips, etc.).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Simon Perreault <[email-masked]>
Date: Mon, 03 Nov 2008 15:51:46 -0500

Fairly minor stuff this time. As you know, the big tree that has yet to
fall is synchronization.

Issues are tracked at http://www.vcarddav.org/issues.xhtml.

Here's the change log:

   o  Added "location" value for KIND property.

   o  Some fixes to ABNF.

   o  Moved "pref" from being a TYPE value to a parameter in its own
      right.

   o  Removed the "work" and "home" TYPE values.

   o  Reintroduced the group construct.

   o  Assigned meaning to WORK and HOME groups.

   o  Restricted the TEL TYPE parameter value set.

   o  In N property, removed additional names, and replaced with
      multiple given names.

   o  Removed TYPE parameter from EMAIL and IMPP properties.

   o  Replaced AGENT with a type of RELATED.

   o  Use example.org domain in URL example.

   o  Created initial IANA table of values.

   o  Defined meaning of PUBLIC, PRIVATE, CONFIDENTIAL.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 4 Nov 2008 01:08:29 +0000

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

>draft-ietf-vcarddav-vcardrev-04.txt

 >7.3.1.  ADR

Where are the additional properties (vessel, continent, body)?

 >7.5.2.  GEO

Where is the "schema" property (for non-WGS84 coordinates on earth, and 
those on other bodies)?

In both cases, I refer readers to my 'vcarddav list' e-mail of 27 July 
2008 (18:05:48 +0100):

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

to which I saw no responses.

-- 
Andy Mabbett

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Nov 2008 08:59:10 -0500

> Where are the additional properties (vessel, continent, body)?

See http://www.vcarddav.org/issues.xhtml#155.

This is left for a future extension. For an explanation of what an
extension is, see Section 12.1.

> Where is the "schema" property (for non-WGS84 coordinates on earth, and

Same explanation as above.

> In both cases, I refer readers to my 'vcarddav list' e-mail of 27 July

What I understood of the discussions that followed these posts was that
we should reserve those features for extensions. In case I'm wrong,
please discuss. I always try to follow what seems to be general
consensus in the working group. Sometimes it's hard to get that feeling
right from mailing list discussions.

---

From: Andy Mabbett <[email-masked]>
Date: Tue, 4 Nov 2008 18:31:00 +0000

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

>See http://www.vcarddav.org/issues.xhtml#155.

In which you conclude:

        Discussed on mailing list. Not part of core vCard, left for
        future extensions. Closing without action.

>extension is, see Section 12.1.

Thank you. I understand that from one of our previous exchanges, and
reluctantly accept that that's where some of my other proposals (e.g.
"flourished" & "baptised" dates) may lie; but I don't believe that's the
case - or at least that there is not yet consensus that that is the case
- for these particular points (ADR & GEO).

>we should reserve those features for extensions.

Could you provide the URL(s) of any repl(y/ies) to the above post
(msg00531)? I can't see any.

>In case I'm wrong, please discuss. I always try to follow what seems to
>be general consensus in the working group. Sometimes it's hard to get
>that feeling right from mailing list discussions.

My point is that there was (virtually) no discussion (especially on the
former, ADR, point). Perhaps that indicates lack of interest; perhaps
lack of dissent with my proposed wording.

I'm not sufficiently familiar with this process to know how such lack of
response is usually interpreted, but it seems to be a pity to miss this
opportunity to make improvements just because a relatively small number
of people might have been too busy to comment. After all, you did say,
on 26 July this year, that:

        ...many people who agree will simply not write anything, while
        those in disagreement will probably say so.

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

and in the same e-mail, invited me:

        If you have propositions for changes to be brought to the
        current text, please write them to this mailing list

which I did, in msg00531 (linked above), and in msg00532:

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

although my initial reply, which again received no follow-up, was:

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

If I need to do yet more to move this forward, some indication of how I
might do so would be appreciated, please.

On a separate, but related, note: I have concerns that there is a
failure to mesh hCard and vCard; with a disconnect in the following
process (which is what I have experienced):

        The hCard microformat is /based on/ vCard.

        hCards are used for living people, but also long-dead people,
        organisations (including companies, bands, sports teams etc.),
        vessels, places (including some off-Earth), etc.

        Suggestions to amend (by adding properties to) hCard to enhance
        and facilitate such uses are referred here (presumably so that
        hCard doesn't "fork" from vCard)

        People here reject such proposals because "vcard is not used for
        such purposes" (I paraphrase)

I realise that we mustn't let the tail wag the dog. but I'd be
interested to see whether, and how, a happy medium can be arrived at.
After all, work with microformats has generated some of the
currently-agreed changes, to the benefit of the vCard community.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Nov 2008 14:25:20 -0500

> lack of dissent with my proposed wording.

I think you're making a valid point.

> of people might have been too busy to comment.

I humbly confess that I do not have the necessary process experience
either. Could the experienced ones here (and we're lucky to have plenty
of them!) please voice their opinion on the way to handle this recurring
problem?

> currently-agreed changes, to the benefit of the vCard community.

You're right, and we definitely want you on board!

I think I should step aside at this point and let the other WG members
speak up on the issue of extensions.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 05 Nov 2008 14:23:14 -0500

> of them!) please voice their opinion on the way to handle this recurring

- ietf works with concensus...
- the vcarddav charter says:

"Other extensions shall be considered either in the base specification
or in additional documents."

and

"Once the primary outputs are complete, the WG will consider the
following secondary outputs:
(4) Identifying useful deployed vCard vendor extensions and creating
standards track versions of those extensions.

Therefore, we shall agree:
- first on what are the extensions
- then which ones are to be in the standard document
- and which ones are to be on separate documents.

Maybe start with a strawman proposal and see what concensus we can build
on it?

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca
Stun/Turn server: http://numb.viagenie.ca