Where to find vCard 2.0 and 1.0 specs?

Hello,

Could you please help me to find vCard 2.0 and 1.0 specifications?  I 
was trying to look up the Web Archive entries for imc.org/pdi, but the 
oldest copy contains vCard 2.1 spec 
(http://web.archive.org/web/19970620034923/http://www.imc.org/pdi/vcardwhite.html).

Thanks,
Mykyta Yevstifeyev

Proposed new field type: Working Hours

There seems to be demand for a dedicated Working Hours field. This
field would define hours and repetition in a manner similar to
vCalendar. Not only would this allow users to store the data in a
standard format for all their contacts, it would allow the data to be
queried, for instance like this:
1) See which pizza restaurant is open on Friday at 02:30 in the morning.
2) See which museums will be open when your old friend comes to visit.
3) Which pharmacy is open on Saturday when your child is sick.

If there is a better forum to file such a feature request, please
point me to it. Thank you.

--

-- 
Dotan Cohen

http://bido.com
http://what-is-what.com

Registration is now open for CalConnect Roundtable XI and IOP Test Event, February 4-8, 2008

Reminder: CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts

CalConnect vCard Workshop - September 18, 2007 - Cambridge, Massachusetts

email clients and NOTE

Hello,
I have some questions about the .vcf format:
Is there a list available with emailclients and mobile devices which works
with vcf files?
And when I generate a vcard with a script and fill in the NOTE value this
doesn't appear in Outlook 2000 / 2003. 
Is there a solution for this problem or is it just a Microsoft issue?

Thx in advance,

Jeroen

Fwd: RFC 4770 on vCard Extensions for Instant Messaging (IM)

>Date: Wed, 10 Jan 2007 14:07:34 -0800
>To: ietf-announce <at> ietf.org, rfc-dist <at> rfc-editor.org
>From: rfc-editor <at> rfc-editor.org
>X-Spam-Score: -14.8 (--------------)
>X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
>Cc: rfc-editor <at> rfc-editor.org
>Subject: RFC 4770 on vCard Extensions for Instant Messaging (IM)
>X-BeenThere: ietf-announce <at> ietf.org
>X-Mailman-Version: 2.1.5
>List-Id: ietf-announce.ietf.org
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request <at> ietf.org?subject=unsubscribe>
>List-Post: <mailto:ietf-announce <at> ietf.org>
>List-Help: <mailto:ietf-announce-request <at> ietf.org?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
>	<mailto:ietf-announce-request <at> ietf.org?subject=subscribe>
>
>
>A new Request for Comments is now available in online RFC libraries.
>
>        
>         RFC 4770
>
>         Title:      vCard Extensions for Instant Messaging
>                     (IM)
>         Author:     C. Jennings, J. Reschke, Ed.
>         Status:     Standards Track
>         Date:       January 2007
>         Mailbox:    fluffy <at> cisco.com,
>                     julian.reschke <at> greenbytes.de
>         Pages:      7
>         Characters: 11077
>         Updates/Obsoletes/SeeAlso:   None
>
>         I-D Tag:    draft-jennings-impp-vcard-08.txt
>
>         URL:        http://www.rfc-editor.org/rfc/rfc4770.txt
>
>This document describes an extension to vCard to support Instant
>Messaging (IM) and Presence Protocol (PP) applications.  IM and PP
>are becoming increasingly common ways of communicating, and users
>want to save this contact information in their address books.  It
>allows a URI that is associated with IM or PP to be specified inside
>a vCard.  [STANDARDS TRACK]
>
>This is now a Proposed Standard Protocol.
>
>STANDARDS TRACK: This document specifies an Internet standards track
>protocol for the Internet community,and requests discussion and
>suggestions for improvements.Please refer to the current edition of the
>Internet Official Protocol Standards (STD 1) for the standardization
>state and status of this protocol.  Distribution of this memo is
>unlimited.
>
>This announcement is sent to the IETF list and the RFC-DIST list.
>Requests to be added to or deleted from the IETF distribution list
>should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
>added to or deleted from the RFC-DIST distribution list should
>be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.
>
>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body
>
>help: ways_to_get_rfcs. For example:
>
>         To: rfc-info <at> RFC-EDITOR.ORG
>         Subject: getting rfcs
>
>         help: ways_to_get_rfcs
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.
>
>Submissions for Requests for Comments should be sent to
>RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
>Authors, for further information.
>
>
>The RFC Editor Team
>USC/Information Sciences Institute
>
>...
>
>
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce <at> ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce

Updating a calendar Event

hCard microformat; and related suggestions for changes to vCard

Hello,

My first post here!

Some of you may be interested in microformats:

        <http://microformats.org/>

which are a way of adding simple markup to human-readable data items
such as events, contact details or locations, on web pages, so that the
information in them can be extracted by software and indexed, searched
for, saved, cross-referenced or combined. More technically, they are
items of semantic markup, using just standard (X)HTML with a set of
common class-names. They are open and available, freely, for anyone to
use.

In particular, the hCard microformat:

        <http://microformats.org/wiki/hcard>

maps to vCard. there are a number of tools, listed via the above URL,
for extracting data which is marked up as an hCard, and saving it as a
vCard.

The microformat 'wiki' aslo has a vCard suggestions page:

        <http://microformats.org/wiki/vcard-suggestions>

where possible additions to hCard, which may require a corresponding
change to vCard, are listed.

Currently listed are requests for a gender identifier, a date-of-death
property, and a "textphone" type for telephone numbers.

--

-- 
Andy Mabbett

RE: about vcard encoding

Not quite correct.  UTF-8 represents the ASCII character 
repertoire using the same bit combinations as does ASCII.
For example, "A" is 41 hex.

This does *not* apply to the right-hand half of ISO 8859-1 /
Latin-1.  These characters are encoded using two bytes in 
UTF-8.  For example, the copyright sign is C2 A9 hex.

All of this is beatifully shown in:
   http://www.macchiato.com/unicode/chart/

Misha

-----Original Message-----
From: owner-imc-vcard <at> mail.imc.org [mailto:owner-imc-vcard <at> mail.imc.org]
On Behalf Of S. Isaac Dealey
Sent: 26 May 2006 16:46
To: imc-vcard <at> imc.org
Subject: Re: about vcard encoding

> Hi,dealey
>   About my question,I want to explain it again as follows:
> Because a vcard can describe as a line consisting of
> three parts:property name(for example ,"N","TEL","ADR")
> +property parameters(for example ,"ENCODING","CHARSET")
> +property values.My question is about the property name
> and property parameters.Because the property name and
> property parameters is used as a notation,so I think in
> all vcard,the two parts should be encoded in same
> character set and encoding so that different platform
> can communicate seamlessly.But in the formal definition
> of vcard2.1 and vcard3.0 which is written using the
> ABNF,I only know that the two parts are defined as
> terminal values(for example,name = "LOGO"/"PHOTO").
> I have checked the ABNF specification (RFC 2234).
> It say that the string using the us-ascii character set
> and the external encoding is not specified.

> Then my clear question is that if the two parts in a
> vcard line can be encoded in different format(for
> example,ASCII,UNICODE) or only encoded using ASCII and
> where can i find the document saying about it.

I'm not sure about how data is stored in memory, although my
understanding is that a file system will only allow a single character
set to be associated with any given file. That being the case, if the
file is stored as a UTF-8 file, then whatever character set might be
declared for an individual property would have to be stored in the
file in UTF-8 as a declaration of what character set that value should
be converted to after the file is read.

Conversely that would mean that if the file is stored using the
latin-1 or ISO-8859-1 character set, then any property values that
aren't within the ASCII character set would need to be encoded using
some format which can be represented entirely in that character set,
such as Quoted-Printable or Base64.

Probably this is the reason why the vCard 3.0 standard doesn't allow
the charset parameter for individual properties, because the file can
only be stored with a single character set, and presumably it would be
best (easiest?) to simply choose one character set that will support
most of the card's content than it would be to design an
implementation that can manage character sets for individual
properties.

Since the standard for vCard says the property names ("logo"/"photo")
must be stored in ASCII you might think that this would prevent us
from storing vCards with UTF-8 character set. I think UTF-8 gives us
something of a reprieve, however, because the UTF-8 character set
functions differently than some other character sets, containing first
the complete set of latin-1 characters and representing them as
single-byte characters instead of double-byte characters. As I
understand it, this means that unlike other character sets, any ASCII
characters represented in UTF-8 _are_ single-byte ASCII characters.
The end result of this would mean that you can store a vCard with the
UTF-8 character set and the file will still conform to the requirement
for the property names to be stored in ASCII.

My understanding of this may not be complete or completely accurate,
since it's not my area of expertise, but that's how I've come to
understand it.

s. isaac dealey     434.293.6201
new epoch : isn't it time for a change?

add features without fixtures with
the onTap open source framework

http://www.fusiontap.com
http://coldfusion.sys-con.com/author/4806Dealey.htm

To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender, except where the sender
specifically states them to be the views of Reuters Ltd.

about vcard encoding