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

From: "Addison Phillips" <[email-masked]>
Date: Tue, 12 Apr 2005 15:12:34 -0700

Script is not useful if the charset is UTF-8 (for example). It is quite useful in certain cases with language.

I don't care if Content-Script is accepted or not. I suspect that no one will ever use it. And it does no good outside of the Internet protocol realm (as in an XML document, for example).

Is there a reason not to include script *anywhere* in a language tag?

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of McDonald, Ira
> Sent: mardi 12 avril 2005 14:15
> To: 'Randy Presuhn'; LTRU Working Group
> Subject: RE: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt
> 
> Hi,
> 
> In light of recent threads here on script, a question.
> 
> Are the RFC3066bis editors confident that 'Content-Script'
> will not be approved/adopted into HTTP/1.x and MIME headers?
> 
> Because _two_ methods in wide use for tagging script in the
> same content is a good deal worse than none, IMHO.
> 
> Frankly, Bruce Lilly's rationale for the separation looks sound
> to me.  Script is intimately related to charset and merely usefully
> related to language.
> 
> Cheers,
> - Ira
> 
> Ira McDonald (Musician / Software Architect)
> Blue Roof Music / High North Inc
> PO Box 221  Grand Marais, MI  49839
> phone: +1-906-494-2434
> email: [email-masked]
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On
> > Behalf Of Randy Presuhn
> > Sent: Friday, April 08, 2005 7:07 PM
> > To: LTRU Working Group
> > Subject: [Ltru] Fw: I-D ACTION:draft-lilly-content-script-01.txt
> >
> >
> > 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
> >
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 12 Apr 2005 15:41:14 -0700

Hi -

> From: "Addison Phillips" <[email-masked]>
> To: "McDonald, Ira" <[email-masked]>; "Randy Presuhn" <[email-masked]>; "LTRU Working Group"
<[email-masked]>
> Sent: Tuesday, April 12, 2005 3:12 PM

> Script is not useful if the charset is UTF-8 (for example). It is quite useful in certain cases with language.
...

I don't understand this comment.  I don't see
how the use of UTF-8 changes anything regarding the utility
of script tags.

Perhaps I'm reading too much into the proposal, but I thought
the heart of the idea was while that a script is not an intrinsic property
of a language, it is useful, in conjunction with language, in marking and
selecting content.  The question is whether it's better to represent these
two pieces of information in a single tag or two tags, with the arguments
pro and con being about interpretation of legacy data, tagging of new data,
behavior of legacy applications, impact on existing standards which don't
already provide for this kind of tagging, and evisioned future uses.

Randy