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

From: Pete Resnick <[email-masked]>
Date: Thu, 3 Oct 2013 00:56:15 -0500

On 9/12/13 9:43 AM, Cyrus Daboo wrote:
> Hi Gren,
>
> --On September 12, 2013 at 3:17:13 PM +0100 Gren Elliot 
> <[email-masked]> 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.
>>>
>>> PHONETIC-FULL-NAME;TYPE=IPA-X-SAMPA:/"sUSi/
>>> PHONETIC-FULL-NAME;TYPE=X-FURIGANA:sushi
>>>
>>
>> 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<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Barry Leiba <[email-masked]>
Date: Thu, 3 Oct 2013 10:00:51 -0400

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

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

Barry

On Thu, Oct 3, 2013 at 1:56 AM, Pete Resnick <[email-masked]> wrote:
>> media type associated with them (MIME type) and then the MEDIATYPE property
>> parameter would be a better choice:
>>
> 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.
>
> 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:
>
> But I am at a loss as to why MEDIATYPE makes any sense in this context. Can
> you explain?
>
> pr
>
> --
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 03 Oct 2013 11:14:34 -0400

Hi Pete,

> "text/plain". I don't understand what "text/ipa" or "text/x-furigana"

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

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