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

From: Gren Elliot <[email-masked]>
Date: Thu, 12 Sep 2013 11:18:22 +0100

Hi,

The draft talks about the Japanese specific Katakana and Hiragana.
It would be nice if these phonetic transcriptions were more generally useful.
I believe the International Phonetic Alphabet (IPA) (see
http://www.langsci.ucl.ac.uk/ipa/) seems to me to be the most sensible
default.
There are some clear issues with this though.  I can't read it and I
suspect most people can't.  Producing values in IPA would be limited
to the people who do understand it.
One other possibility would be for address book software that would
listen to someone saying a name and produce the appropriate VCARD
properties (and also play it back if wanted).

For Japanese people, using Katakana and/or Hiragana is more
convenient, because they can write and understand it.  However, many
non-Japanese people would not understand it and it would be more
useful for Japanese name phonetic information to be provided in
another form, perhaps IPA or in a phonetic script that they are
familiar with.

To address one concern DataPacRat had regarding the variability of
names, I believe it would be useful to have a new property for the
whole name, say - PHONETIC-FULL-NAME.

A simple example (I'm sure others can do better):
For the Japanese food stuff "Sushi", the VCARD could contain the 2
properties, one useful to English students studying Japanese who
haven't mastered Hiragana or Katakana yet and use the simple phonetic
system called Furigana and one which is hopefully universally useful
and could be used by generic international software to produce audio
for one proper way (according to http://en.wiktionary.org/wiki/sushi)
to say the word.

PHONETIC-FULL-NAME;VALUE=IPA-X-SAMPA:/"sUSi/
PHONETIC-FULL-NAME;VALUE=X-FURIGANA:sushi

We would need new IANA tokens for acceptable VALUE settings.  I suggest:
IPA - The International Phonetic Alphabet (IPA).  Unicode supports IPA
symbols, so this should be usable.
IPA-X-SAMPA - The Extended Speech Assessment Methods Phonetic Alphabet
(X-SAMPA).  Using IPA-X-SAMPA rather than X-SAMPA because the latter
begins with "X-" and thus can't be used as a registered token.
FURIGANA - Japanese phonetic alphabet
HIRAGANA - Japanese phonetic alphabet

I don't propose that we actually register FURIGANA as an accepted IANA
token - I'm using it here because it is ASCII.

Regards,
Gren Elliot

---

From: Michael Angstadt <[email-masked]>
Date: Thu, 12 Sep 2013 07:08:58 -0400

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

On Thursday, September 12, 2013, Gren Elliot wrote:

> _______________________________________________
> VCARDDAV mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: DataPacRat <[email-masked]>
Date: Thu, 12 Sep 2013 07:38:23 -0400

> token - I'm using it here because it is ASCII.

There's already a well-developed set of language and script tags at
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry
- it may be possible to mine that namespace instead of coming up with
new tags. There's jp-Hira and jp-Kana , plus jp-Hrkt is "Japanese
syllabaries (alias for Hiragana + Katakana)" and jp-Jpan "Japanese
(alias for Han + Hiragana + Katakana)". jp-fonipa for direct IPA
characters, and jp-fonxsamp for X-SAMPA ones.

RFC5646, https://tools.ietf.org/html/rfc5646 , is the reference for
such tags, and user-created tags for private use are in section 2.2.7,
https://tools.ietf.org/html/rfc5646#section-2.2.7 . I'm not sure if
it's a good idea to write an RFC which depends on the use of such
tags. If furigana isn't listed in the IANA registry under another
name, then perhaps a good first step would be to submit it there?

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Gren Elliot <[email-masked]>
Date: Thu, 12 Sep 2013 15:17:13 +0100

> PHONETIC-FULL-NAME;TYPE=X-FURIGANA:sushi

I agree.  I think that makes more sense.

Thanks,
Gren

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 12 Sep 2013 10:43:18 -0400

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

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 Daboo

---

From: Gren Elliot <[email-masked]>
Date: Fri, 13 Sep 2013 12:08:41 +0100

Hi,

Personally, I don't have a strong opinion and haven't done significant
research on whether TYPE or MEDIATYPE are more sensible.  The
important thing from my point of view is that it should be clear what
the value is and also that it would be great if this was applicable
generally rather than just being a solution for Japanese names.

Regards,
Gren

On 12 September 2013 15:43, Cyrus Daboo <[email-masked]> wrote:
> Actually I would argue that the values should all have a corresponding media
> type associated with them (MIME type) and then the MEDIATYPE property