Subject: [VCARDDAV] text/vcard encoding default

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Mar 2009 15:56:11 +0100

Hi,

<http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-06#section-3> says:

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

On the other hand, HTTP/1.1 
(<http://tools.ietf.org/html/rfc2616#section-3.7.1>):

    The "charset" parameter is used with some media types to define the
    character set (section 3.4) of the data. When no explicit charset
    parameter is provided by the sender, media subtypes of the "text"
    type are defined to have a default charset value of "ISO-8859-1" when
    received via HTTP. Data in character sets other than "ISO-8859-1" or
    its subsets MUST be labeled with an appropriate charset value. See
    section 3.4.1 for compatibility problems.

As with other text based formats, the question which of these is "more" 
normative will come up eventually.

I have no answer to that, but did you consider using application/vcard 
instead?

BR, Julian

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Mar 2009 11:07:04 -0400

>    section 3.4.1 for compatibility problems.

How about making "charset=UTF-8" mandatory?

I'd really like to hear from Pete on this...

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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Mar 2009 16:09:43 +0000

>       default encoding is UTF-8 as defined in [RFC3629].

Right. So I would prefer saying "if omitted, then then the default 
encoding is US-ASCII.", i.e. if UTF-8 is used, then the charset 
parameter is required.
This is similar to what was done in the Calsify WG with iCalendar format.

> As with other text based formats, the question which of these is 
> "more" normative will come up eventually.
>

This would render the vcard unreadable in email clients that don't 
support vcards. I think this is a rather nice property.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Mar 2009 17:21:40 +0100

> This is similar to what was done in the Calsify WG with iCalendar format.

And, depending how one reads RFC 2046 (*), it would be consistent with 
<http://tools.ietf.org/html/rfc2046#section-4.1.2>:

    Unlike some other parameter values, the values of the charset
    parameter are NOT case sensitive.  The default character set, which
    must be assumed in the absence of a charset parameter, is US-ASCII.

(*) It could be argued this applies only to text/plain.

> support vcards. I think this is a rather nice property.

Understood. Q: "unreadable" in general, or until the clients learn about 
the new mime type?

BR, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Mar 2009 18:15:54 +0000

Julian Reschke wrote:

>>> I have no answer to that, but did you consider using 
>>> application/vcard instead?
>>
> Understood. Q: "unreadable" in general, or until the clients learn 
> about the new mime type?

The latter.
Speaking as a user: I personally find the ability to see any text/<foo> 
part in a MIME-compliant email client as just text/plain to be of 
benefit, as I can then cut & paste different bits of the vcard.
For applicate/<foo> it means saving the attachment to a file and using 
an editor for doing that. Slightly less convenient.