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

From: [email-masked]
Date: Wed, 6 May 2009 05:00:01 -0700 (PDT)

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-07.txt
	Pages           : 73
	Date            : 2009-05-06

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-07.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.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 06 May 2009 08:04:25 -0400

> 	Filename        : draft-ietf-vcarddav-vcardrev-07.txt

Here's the change log:

   o  PREF is now bounded. 100 is the maximum value.

   o  Added the "emergency" RELATED type.

   o  Made GEO a URI.

   o  Added GEO and TZ parameters to ADR.

   o  Changed wording of "default" use of SOUND property.

   o  Completely reworked the date, time, and date-time grammars.

   o  Added the timestamp value type.

   o  REV now has the timestamp value type.

   o  Rewrote ABNF.

   o  ORG can now have a single level.

Only one known issue is left: the infamous TZ!

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

---

From: Markus Lorenz <[email-masked]>
Date: Thu, 07 May 2009 15:13:33 +0200

Hey Simon,

great work! I love to see the ABNF definitions within the sections of
its properties.

I also have a few comments on draft 07:

Section 5 "Property Value Data Types" defines
    zone   = "Z" / utc-offset
This allows a time value like
    102200Z
What does the "Z" indicate? I didn't find this information. Does it
stand for "+0000"?

Section 5.3.1 "Date" gives the example for "date":
    1985
but as I understand, section 5 does not allow just the year:
    date          = year     month  day
                  / year "-" month
                  / "--"     month [day]
                  / "--"      "-"   day

The special notes of section 7.3.1 "ADR" say:
    "When a component value is missing, the associated component
    separator MUST still be specified."
The last two component value are "postal code" and "country name".
Therefore, if you leave the country name, there has to be a semicolon at
the end of the value. The "example" does not observe this rule as it is:
    Example: In this example the post office box and the extended
        address are absent.
    ADR;GEO="geo:12.3457,78.910":;;123 Main Street;Any Town;CA
        ;91921-1234
The country name is missing. There has to be a semicolon at the end and
the example text only mentions "post office box" and "extended address".

Where can I find the correct unique uri-prefixes of the instant
messaging service, which I have to use in the IMPP property? "xmpp:" is
given in the example. But what about Skype, ICQ, AIM, etc.? For example,
Jabber could have had the prefix "jabber:". Where can I find the
definition that it has to be "xmpp:"?

Regards

Markus

---

From: Simon Perreault <[email-masked]>
Date: Thu, 07 May 2009 09:31:48 -0400

> great work! I love to see the ABNF definitions within the sections of

Thanks!

> What does the "Z" indicate? I didn't find this information. Does it

Yes it does. It's defined in ISO 8601.

> but as I understand, section 5 does not allow just the year:

Hmmm, I forgot that in the ABNF. Consider it fixed.

>     ADR;GEO="geo:12.3457,78.910":;;123 Main Street;Any Town;CA

Good catch! This bug has been present for a long time. I will add "USA" as the
country name.

> definition that it has to be "xmpp:"?

You're free to use any URI scheme. IANA maintains a registry of them:
http://www.iana.org/assignments/uri-schemes.html

Thanks,
Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 May 2009 09:26:57 -0600

> definition that it has to be "xmpp:"?

The "xmpp:" URI scheme is defined in RFC 5122:

http://tools.ietf.org/html/rfc5122

As far as I know, companies like Skype, AOL, and Microsoft have not
bothered to define URI schemes for their IM technologies. Perhaps
they're waiting until they implement XMPP. ;-)

Peter

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

---

From: Dan Brickley <[email-masked]>
Date: Thu, 07 May 2009 17:31:47 +0200

On 7/5/09 17:26, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

The longform workaround we have in FOAF for this is we model the pairing 
of a service provider homepage with an accountname. Verbose but works 
for most sites (flickr is a pain as they have several notions of 
username, though).

cheers,

Dan

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 May 2009 20:28:38 +0200

[email-masked] wrote:
> ...

Hi,

I just went through the exercise of running the ABNF through Bill 
Fenner's ABNF parser...

Recipe:

- in the XML version, annotate the figures containing ABNF with @type="abnf"

- extract ABNF using 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#extract-artwork>

Findings:

(1) there are a few prose rules containing line ends, these are not 
allowed in ABNF

(2) the structure of the draft, defining "param" and "value" for each 
protocol element, causes lots of rule name collisions

Recommendations:

(1) Should probably fixed.

(2) You may want to consider assigning unique rule names, such as 
"BEGIN-param" and "BEGIN-value" instead of "param" and "value" (in 
Section 7.1.1); if this is felt to be too intrusive, I'd recommend to 
leave the spec text as is, but to create an extraction tool that renames 
the rules so that there are no collision; in which case automated 
checking will still be possible.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 May 2009 12:26:36 +0200

Hi.

Unused references:

WARNING: unused reference 'CCITT.E163.1988' (at line 3)
WARNING: unused reference 'CCITT.X121.1988' (at line 3)
WARNING: unused reference 'CCITT.X520.1988' (at line 3)
WARNING: unused reference 'CCITT.X521.1988' (at line 3)
WARNING: unused reference 'RFC2978' (at line 3)

Broken reference:

    [oldreference_VCARD]     Internet Mail Consortium, "vCard - The
                             Electronic Business Card Version 2.1",
                             September September.

Besides the broken date, I'd also recommend renaming it to something 
shorter.

Wrong classification:

Several of the normative references by definition can't be normative, 
for instance these to RFCs that are getting obsoleted.

The others probably should be double-checked as well...

BR, Julian

---

From: Andy Mabbett <[email-masked]>
Date: Fri, 29 May 2009 21:50:33 +0100

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

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

>http://www.ietf.org/internet-drafts/draft-ietf-vcarddav-vcardrev-07.txt

I apologise that I've been absent from this list for too long; and beg
your indulgence as I catch up.

What happened to my suggestions for additional ADR sub- properties:

   *    vessel ("HMS Victory", "narrowboat Skylark", "ISS")

                ADR;TYPE=home:;Cabin 4b;RMS Queen Elizabeth 2;;;;;;

   *    continent:

                ADR;TYPE=work:;;;;;Utsteinen;;;;Antarctica;

   *    body (Moon, Mars) :

                ADR;TYPE=work:;;Moonbase Alpha;;Plato;;;Moon

last discussed after draft 4?

Likewise the extensions to GEO for non-WGS84 reference systems (which I
referred to in an earlier e-mail this evening)?

There was a suggestion that these be shifted to extensions, but when
asked for my opinion, I said that I thought they should be part of the
core.

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>

So far as I am aware (and I may well be wrong) there has been no
subsequent discussion of the matter on this list.

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>

-- 
Andy Mabbett