Subject: [VCARDDAV] Default charset

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Feb 2010 09:58:22 -0500

Hi folks,
I just came across the following link: 
<http://microformats.org/wiki/vcard-errata>. This claims that RFC2426 was 
wrong to remove the CHARSET parameter on properties (which I personally do 
not believe - and no formal IETF errata has ever been posted for that). 
Apparently some clients require CHARSET parameters on properties for 
VERSION:3.0 too: 
<http://help.wugnet.com/office/Outlook-vCard-UTF-ftopict1163209.html>.

Clearly we need to clean up this mess. Now, the current 4.0 draft does 
state clearly that for a MIME object with a Content-Type header, the 
default charset is UTF-8 (Section 10.1) for the newly registered media type 
text/vcard. What it does not do is explain what charset to use for a 
"standalone" file (dealing with the microformats issue). iCalendar is 
explicit in stating that the default charset for an iCalendar object is 
UTF-8 (<http://tools.ietf.org/html/rfc5545> Section 3.1.4). I believe the 
4.0 specification should be just as explicit about this.

Proposed changes:

- Add a new Section 3.4 with text matching that in RFC5545 Section 3.1.4:

    3.4.  Character Set

       There is not a property parameter to declare the charset used in a
       property value.  The default charset for vCard data is UTF-8
       as defined in [RFC3629].

       The "charset" Content-Type parameter MUST be used in MIME transports
       to specify the charset being used.

- First paragraph of Section 4.1 needs to be adjusted to remove reference 
to charset given the addition of Section 3.4 as above.

- Add an "Internationalization Considerations" with text matching that in 
RFC5545 (note this may be stronger than we want in that it mandates use of 
utf-8 only):

    XX.  Internationalization Considerations

       Applications MUST generate vCard data in the UTF-8 charset and
       MUST accept vCard data in the UTF-8 or US-ASCII charset.

-- 
Cyrus Daboo

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 22 Feb 2010 10:02:43 -0500

>       MUST accept vCard data in the UTF-8 or US-ASCII charset.

Why should we not stick with UTF-8 only?

Marc.

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN news service: http://reeves.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Feb 2010 08:05:03 -0700

On 2/22/10 7:58 AM, Cyrus Daboo wrote:
> <http://microformats.org/wiki/vcard-errata>. This claims that RFC2426
> was wrong to remove the CHARSET parameter on properties (which I
> personally do not believe - and no formal IETF errata has ever been
> posted for that). Apparently some clients require CHARSET parameters on
> properties for VERSION:3.0 too:
> default charset is UTF-8 (Section 10.1) for the newly registered media
> type text/vcard. What it does not do is explain what charset to use for
> a "standalone" file (dealing with the microformats issue). iCalendar is
> UTF-8 (<http://tools.ietf.org/html/rfc5545> Section 3.1.4). I believe
> the 4.0 specification should be just as explicit about this.

+1

>       property value.  The default charset for vCard data is UTF-8

The term "default" might be taken to imply that one can override the
default, but that seems not to be the case.

>       to specify the charset being used.

Which is always UTF-8?

> - First paragraph of Section 4.1 needs to be adjusted to remove
> reference to charset given the addition of Section 3.4 as above.
> 
> - Add an "Internationalization Considerations" with text matching that
> in RFC5545 (note this may be stronger than we want in that it mandates
> use of utf-8 only):
> 

Is this indeed stronger than we want? That is, do we ever want any
charset other than UTF-8? I don't think so.

Peter

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 22 Feb 2010 10:06:27 -0500

On 2010-02-22 09:58, Cyrus Daboo wrote:
> Now, the current 4.0 draft does
> a "standalone" file (dealing with the microformats issue).

It doesn't?

10.1. MIME Type Registration

    Encoding considerations:  The "charset" MIME parameter is interpreted
       as defined in [RFC2046], section 4.1.2.  If it is omitted, the
       default encoding is UTF-8 as defined in [RFC3629].

Hmmm... not very explicitly, you're right.

> iCalendar is

+1

Since this is just reinforcing what is already specified, I see no 
problem in adding this text. Unless somebody objects, it will be added 
verbatim.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 22 Feb 2010 15:07:39 +0000

> Why should we not stick with UTF-8 only?

I think accepting US-ASCII is Ok, as it is a proper subset of UTF-8. I 
suspect lots of stuff is using it now.

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 22 Feb 2010 10:13:08 -0500

> suspect lots of stuff is using it now.

right, but vcard4 will require some rewrite anyway. and for the same 
reason (us-ascii is subset of utf-8), it would be no effort for writers 
to tag their us-ascii as utf-8. I have a hard time thinking of a new 
application in 2010 that would not be able to push US-ASCII data tagged 
with utf-8.

Marc.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Feb 2010 16:15:06 +0100

+1

"...MUST accept vCard data in the UTF-8 or US-ASCII charset..."

	is the same thing as

"...MUST accept vCard data in the UTF-8 charset"

...because any recipient that accepts UTF-8 *by definition* also accepts 
US-ASCII.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Feb 2010 08:24:24 -0700

> ...because any recipient that accepts UTF-8 *by definition* also accepts

But is it OK to accept vCard data only in the US-ASCII charset?

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 22 Feb 2010 10:24:49 -0500

Hi Marc,

> Why should we not stick with UTF-8 only?

I would be perfectly happy requiring UTF-8 always. My only concern is 
whether we might have missed some issue wrt v3 vs v4 compatibility that 
might be easier dealt with if we allowed other charsets. Right now I can't 
think of any but we should get more input from other implementers.

-- 
Cyrus Daboo