Re: Comments on <draft-ietf-acap-mlsf-00.txt>?

From: Pete Resnick (presnick@qualcomm.com)
Date: Tue Jun 03 1997 - 17:56:06 EDT


On 6/3/97 at 2:33 PM -0500, Rick McGowan wrote:

>I looked at...
>
>>> draft-ietf-acap-mlsf-00.txt
>
>The mechanism appears to me bizarre, inadequate, and pointless.
>
>The paper also answers none of my questions, like:
> What is the purpose of this?
> What is the intended audience?

I think it's utterly ridiculous to say in the same breath that the
mechanism is "inadequate" and then say that you don't understand the
purpose. If you don't understand it's purpose, how can you make claims
about whether or not it is adequate to acheive that purpose.

That aside, I think it makes it's purpose perfectly clear: 16-bit Unicode
unifies the Han characters. In some instances, like using text-to-speech or
even displaying in nice fonts, the ability to distinguish between languages
of these characters is important. This is simply a language tagging
mechanism.

The intended audience, as you can tell from the name of the document, is
the IETF ACAP working group. ACAP uses UTF-8 encoded strings to transmit
certain kinds of data. It was evidently deemed desireable to language tag
some of that data.

> Why mess with a perfectly standard format like UTF-8?

Here you may have a reasonable objection, but you certainly haven't
explained what your objection is. Personally, I would prefer to see them
use a set of corporate zone characters as language tagging info instead of
using specifically illegal UTF-8 characters: I'm afraid that illegal UTF-8
characters will make more work for people who have stock UTF-8 parsers than
would some corporate use characters, but I'm not sure if that has other
implications. In any event, I will discuss that with the author of the
document and see if it improves things or not.

> Why cannot other mechanisms be used?

I'm sure we could come up with 20 different mechanisms. They chose one.
Perhaps it's not the best. But unless you can show that it fails to work
(more to the point, if they can't show there is running code), then in the
eyes of the IETF, it's good enough. Unlike the ISO, the only requirement to
become a standard in the IETF is rough consensus among the participants of
the working group mailing list (which is open to anyone) and two
independently written interoperable examples of running code. There's no
voting, and no nonsense about coming up with the theoretically best
solution; if it works for it's designed purpose, it's good enough.

>And it says nothing of the adequacy of the language tags; and the draft
>(rfc1766) of the language tags paper itself doesn't actually define any tags.

RFC 1766 refers to the ISO 639 and 3166 standards. For purposes of
distinguishing Chinese, Japanese and Korean, these language tags are
perfectly adequate.

>I sincerely hope that something like this is not adopted.

You have given absolutely no reasoning whatsoever which would support not
adopting this as a standard. If you have some real objections, state them
clearly and send them to the document author, as well as the ACAP mailing
list if you wish to have your peers review your comments. Discussing this
topic on this list is fine, but it generally won't affect the outcome of
the ACAP working group discussions.

For the record, I do not participate in the ACAP working group, but I am a
participant in several other IETF working groups.

pr

--
Pete Resnick <mailto:presnick@qualcomm.com>
QUALCOMM Incorporated
Work: (217)337-6377 / Fax: (217)337-1980



This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:34 EDT