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

Cyrus Daboo <cyrus@daboo.name> Thu, 03 October 2013 15:21 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: vcarddav@ietfa.amsl.com
Delivered-To: vcarddav@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07A121F8F97 for <vcarddav@ietfa.amsl.com>; Thu, 3 Oct 2013 08:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_83=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kx3bt6czyhbX for <vcarddav@ietfa.amsl.com>; Thu, 3 Oct 2013 08:21:24 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id E86FA21E805D for <vcarddav@ietf.org>; Thu, 3 Oct 2013 08:14:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 798A24D1E9CE; Thu, 3 Oct 2013 11:14:40 -0400 (EDT)
X-Virus-Scanned: amavisd-new at example.com
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJeGx40PEDpe; Thu, 3 Oct 2013 11:14:39 -0400 (EDT)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 8D6404D1E9C0; Thu, 3 Oct 2013 11:14:37 -0400 (EDT)
Date: Thu, 03 Oct 2013 11:14:34 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Pete Resnick <presnick@qti.qualcomm.com>
Message-ID: <2F302A65F71E81963ED1CC2F@caldav.corp.apple.com>
In-Reply-To: <524D06FF.2010102@qti.qualcomm.com>
References: <CAMQk0F-0GWfSmjuvDsUQXfAkJH8LSAqceW=DHXfaqVdG6jtafw@mail.gmail.com> <CAJNb_g3-pZpKOUyNEDP5+YNYWfxbtdjzPmRo7_yJJPX+_j+eGw@mail.gmail.com> <CAMQk0F-gCS8xYbziNzqESLndwSpzrhCqNjtcch0uFYTmBw8H6g@mail.gmail.com> <4FC4C0F22B22C92065B93CBD@caldav.corp.apple.com> <524D06FF.2010102@qti.qualcomm.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="3720"
Cc: vcarddav@ietf.org, fatkudu@gmail.com
Subject: Re: [VCARDDAV] Review of draft-fukuda-vcarddav-phonetic-transcription-00.txt
X-BeenThere: vcarddav@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <vcarddav.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vcarddav>
List-Post: <mailto:vcarddav@ietf.org>
List-Help: <mailto:vcarddav-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vcarddav>, <mailto:vcarddav-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Oct 2013 15:21:36 -0000

Hi Pete,

--On October 3, 2013 at 12:56:15 AM -0500 Pete Resnick 
<presnick@qti.qualcomm.com> wrote:

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

Barry pretty much made my point. There are other kinds of phonetic 
algorithms in place such as Soundex 
(<http://en.wikipedia.org/wiki/Soundex>) and Metaphone 
(<http://en.wikipedia.org/wiki/Metaphone>). Another example of alternatives 
to IPA: <http://en.wikipedia.org/wiki/English_phonetic_alphabet>.

The point here is that plain text (utf-8) can be used to encode various 
different types - not just IPA. If these are all likely to be used in the 
new vCard property then we do need a way to identify which one is in use 
and it struck me that a media type made sense as one might also want to be 
able to transport such data over other protocols (e.g., HTTP, as an email 
attachment, over IM etc).

> 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

FYI Contacts.app uses two separate properties:

X-PHONETIC-FIRST-NAME:speek
X-PHONETIC-LAST-NAME:owtlowd

I know there are also requests to have a phonetic company name. It does 
seem to me we may need to support phonetic equivalents to a bunch of 
properties: FN, N, NICKNAME, ORG etc. Having PHONETIC- equivalents for each 
of those (with the value structure matching that of the related property) 
is one way to go, using parameters another. One consideration is that some 
people like to be able to sort by phonetic name, in which case an 
equivalent sort-as parameter is needed for phonetic values. That would be 
easier to do if the phonetic values were properties rather than parameters, 
since the existing SORT-AS behavior could be re-used. It also looks like 
Exchange and directory (LDAP) schemas have these as separate "properties" 
(<http://msdn.microsoft.com/en-us/library/windows/desktop/ms677462(v=vs.85).aspx>) 
rather than attributes of the related property.

There is also another aspect to this: e.g. Siri on iOS has an option where 
you can tell it to change the pronunciation of your name. That information 
isn't encoded in vCard as far as I can tell. I might try and see what 
format they use - might be entirely proprietary.

Summary:

At this point I think we need more clarity in the spec as to what the 
purpose of the property is: can it be used for sorting, can it be used for 
"text-to-speech" pronunciation by devices.

I also think we need to support the additional properties I mentioned.

I think I prefer the use of separate properties rather than parameters.

If we expect this data to support different types, and we also expect this 
data to possibly be transported over other protocols, then I think a media 
type makes the most sense.

-- 
Cyrus Daboo