Re: [VCARDDAV] Review of draft-fukuda-vcarddav-phonetic-transcription-00.txt

Barry Leiba <> Thu, 03 October 2013 14:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA3FF21F853A for <>; Thu, 3 Oct 2013 07:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.891
X-Spam-Status: No, score=-101.891 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PLh3esgHYnQE for <>; Thu, 3 Oct 2013 07:08:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::22e]) by (Postfix) with ESMTP id A8F5821E8097 for <>; Thu, 3 Oct 2013 07:00:52 -0700 (PDT)
Received: by with SMTP id eh20so1954176lab.5 for <>; Thu, 03 Oct 2013 07:00:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6Y7GBQWfDddEXVnrk94x1MXoM1Vg8AAvX46kiUfx2dk=; b=NBYKzSsrXv7C9ndsHAGmCuaVWiUFHJwED2Ave7S/S9UHaQn7O7huNZTLZNfdvYuDMf Wbw0rf3E8l7NnrFzIla7Kj+yWEYfqKLVVSJWq8UNf3ppel7MZc/dLZszST0U5QW7Cei+ gwyxjegDILOVrlHEDKmMf0GH0Hvmz0FVTE6bqvuo7nFtNZ21u7uYkNy0WUQ2JH2zhn08 fLue3eUMV+DDBfCjTc/VoKRXjl2pNpAQ+895/a3eyZhg23NevPCUZAUYMd1sOS7D40Ti 4rDCtJjltaju5Zzc3xm0I0FFkR1etw4mJC+CuHxzSW4uuUcycxQtdaNVO9mNoobvQZh9 Dtcw==
MIME-Version: 1.0
X-Received: by with SMTP id la9mr7012003lab.3.1380808851483; Thu, 03 Oct 2013 07:00:51 -0700 (PDT)
Received: by with HTTP; Thu, 3 Oct 2013 07:00:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 03 Oct 2013 10:00:51 -0400
X-Google-Sender-Auth: eR4UuodEKxhtUpcXlL7RwG9WzCo
Message-ID: <>
From: Barry Leiba <>
To: Pete Resnick <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc:, CardDAV <>
Subject: Re: [VCARDDAV] Review of draft-fukuda-vcarddav-phonetic-transcription-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Oct 2013 14:08:30 -0000

The only thing Cyrus was addressing was how to convey how the phonetic
representation is rendered.  It was in response to the idea of minting
new TYPE values to say "this isn't text, it's IPA".  Cyrus was saying
that, no, it's actually "text/ipa", and we should use MEDIATYPE to
convey that.

I gather that you're saying we should use a CHARSET parameter to convey that.

It's arguable which is right here.  US-ASCII vs UTF-8 vs ISO-8859
vs... are charsets.  I'd say that IPA is more than a charset.  It's a
pronunciation language that's represented in UTF-8... but it's *use*
isn't the same as text/plain, regardless of the charset.  It has a
distinct usage that arguably does merit a separate text subtype.

> And I
> think I agree with Simon that this should really be a property like
> "SORT-AS" that is added to a name property and simply contains the
> pronunciation, for example:
>    FN;PHONETIC-NAME="<<blahblah>>:Rene van der Harten

You mean "should really be a parameter", surely.

I think I agree with that, because different properties might need
different pronunciation guidance, and doing that with separate
properties will be very cumbersome.  Arguably anything that has
human-readable text might benefit from phonetic guidance (consider an
ADR property that contains "Greenwich" or "Leicester"), and could use
such a parameter.

But if we're going to do that, then we have to agree on how the
phonetic guidance (I suggest just "PHONETIC" for the parameter name)
is represented, because parameters don't have parameters to modify


On Thu, Oct 3, 2013 at 1:56 AM, Pete Resnick <> wrote:
> On 9/12/13 9:43 AM, Cyrus Daboo wrote:
>> Hi Gren,
>> --On September 12, 2013 at 3:17:13 PM +0100 Gren Elliot
>> <> wrote:
>>>> Using TYPE instead of VALUE might be better.  VALUE represents a data
>>>> type, which can be applied to other properties.  These settings are
>>>> specific to this property alone.
>>> I agree.  I think that makes more sense.
>> Actually I would argue that the values should all have a corresponding
>> media type associated with them (MIME type) and then the MEDIATYPE property
>> parameter would be a better choice:
>> PHONETIC-FULL-NAME;MEDIATYPE=text/ipa; option=x-sampa:/"sUSi/
>> PHONETIC-FULL-NAME;MEDIATYPE=text/x-furigana:sushi
>> Ideally we want these "types" registered for interoperability.
> Cyrus,
> Fukuda-san asked whether Barry or I would be interested in sponsoring this
> document, so I had a read of it. I noticed the use of MEDIATYPE and found
> your message in the archive.
> Please explain how MEDIATYPE is in any way correct for this. 6350 says:
>    The MEDIATYPE parameter is used with properties whose value is a URI.
>    Its use is OPTIONAL.  It provides a hint to the vCard consumer
>    application about the media type [RFC2046] of the resource identified
>    by the URI.
> That's not even close to what this is. PHONETIC-NAME (as it currently is
> called) is a string that represents the phonetic pronunciation of the name.
> The string might be in a particular charset, but the string is certainly not
> going to change media type; it's always going to be "text/plain". I don't
> understand what "text/ipa" or "text/x-furigana" could possibly mean.
> Now, I don't really understand why this thing needs a "type" anyway. If the
> string contains characters from the Hiragana range, it's Hirigana, and if it
> has characters from the IPA symbols range, it's IPA. In fact, adding a type
> that might disagree with the contents of the string seems problematic. And I
> think I agree with Simon that this should really be a property like
> "SORT-AS" that is added to a name property and simply contains the
> pronunciation, for example:
>    FN;PHONETIC-NAME="<<blahblah>>:Rene van der Harten
> But I am at a loss as to why MEDIATYPE makes any sense in this context. Can
> you explain?
> pr
> --
> Pete Resnick<>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> _______________________________________________
> VCARDDAV mailing list