Subject: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 8 Apr 2005 16:07:16 -0700

Hi -

I believe this may be of interest to many members of the ltru WG.

Randy

> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, April 08, 2005 7:25 AM
> Subject: I-D ACTION:draft-lilly-content-script-01.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Indicating and Negotiating Text Script
> Author(s) : B. Lilly
> Filename : draft-lilly-content-script-01.txt
> Pages : 14
> Date : 2005-4-7
>
> Some written text in some languages can be represented in multiple
>    scripts, or writing forms.  This memo proposes mechanisms for
>    identification and negotiation of script for written text.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lilly-content-script-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-lilly-content-script-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [email-masked].
> In the body type:
> "FILE /internet-drafts/draft-lilly-content-script-01.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce
>

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 12 Apr 2005 15:03:43 -0700

> From: [email-masked] [mailto:[email-masked]]
On Behalf Of
> McDonald, Ira

> Frankly, Bruce Lilly's rationale for the separation looks sound
> to me.  Script is intimately related to charset and merely usefully
> related to language.

Frankly, Bruce's proposal is IMO inadequate for many scenarios and for
other scenarios very problematic. Issues have been identified in recent
posts by Addison, by Ned and by me.

IMO, 'Content-Script' should not be approved.

Peter

---

From: "Peter Constable" <[email-masked]>
Date: Tue, 12 Apr 2005 17:27:55 -0700

On Behalf Of
> Randy Presuhn

> Not terribly useful to me, but I would like requests for Cantonese
> that did not specify a script to produce Cantonese documents
regardless of
> whether they were marked as traditional, simplified, IPA
transcription,
> or bore no script identifier at all.   Some of the alternatives
discussed do this
> with the various combinations of new and legacy apps with new and
legacy
> data, some don't.

What has been proposed in 3066bis should do this every bit as well as
separating script into a separate metadata element. 

The *only* scenarios in which there is any question about this are if
someone were asking for (say) documents in *Taiwan* Mandarin (as opposed
to Mandarin as used in PRC, HK, etc.) -- for such cases, we aim to
describe new approaches to matching that would always work, but in some
existing implementations this request would not match content tagged as
(e.g.) zh-Hant-TW. Note, though, that such scenarios are fairly limited
in number and commonness.

Peter Constable