Re: [Ltru] RFC 2277 - considerations

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

Could you *please* identify the *specific* text in the draft
you would like to add / remove / replace?

The IESG reviewed our charter before approving it.  You even
commented on the proposed charter while the IESG was reviewing
it, so if anything was unclear, you certainly had opportunity to make
your view heard at that time.

This working group's job is to produce two documents, as
spelled out in the charter.  You are the only participant who seems
to have any difficulty understanding the charter.  No one else on
this mailing list has expressed any confusion as to what our
deliverables are.  Given the depth and breadth of expertise
of the participants, I'm willing to take their lack of confusion as
a sign that we know what we need to do.

Randy

> From: "JFC (Jefsey) Morfin" <jefsey at jefsey.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU Working Group" <ltru at ietf.org>
> Cc: <ned.freed at mrochek.com>; "Martin Duerst" <duerst at it.aoyama.ac.jp>
> Sent: Monday, May 09, 2005 6:27 PM
> Subject: Re: [Ltru] RFC 2277 - considerations
>

> At 01:40 14/05/2005, Randy Presuhn wrote:
> >Hi -
> >
> > > From: "JFC (Jefsey) Morfin" <jefsey at jefsey.com>
> > > To: <ned.freed at mrochek.com>; "Martin Duerst" <duerst at it.aoyama.ac.jp>
> > > Cc: "LTRU Working Group" <ltru at ietf.org>
> > > Sent: Monday, May 09, 2005 3:53 PM
> > > Subject: Re: [Ltru] RFC 2277 - considerations
> >...
> > > This is because scripts do not belong to RFC 3066 but to RFC 2277.
> >...
> >
> >Our charter clearly directs us to address the question of script
> >identification
> >in our update to 3066.
>
> Hi! Randy,
> Glad you noted that, since the review of the Charter has not been carried yet!
>
> The Charter says:
> "- For extensibility, it is expected that the document will describe how
> generative mechanisms could use ISO 15924 and UN M.49 codes without
> explicit registration of all combinations. The current registry contains
> pairs like uz-Cyrl/uz-Latn and sr-Cyrl/sr-Latn, but RFC 3066 contains no
> general mechanism or guidance for how scripts should be incorporated into
> language tags; this replacement document is expected to provide such a
> mechanism."
>
> 1. "extensibility" is a W3C key requirement, where IETF uses more usually
> "scalability". From what the authors have documented  (their initial Draft
> being the Bible of this WG) they are interested in a single need (other
> concerns [DNS, Java, OPES, LDAP, etc.] being out of scope) which is a
> problem of the W3C about XML Addison fully documented. This problem was
> presented as resulting from the langtag libraries limitations. There may be
> tens of existing or future applications. IETF being mainly interested in
> network architecture, I did not pay a special attention, trusting Addison;
> and trusting Mark when he said CLDR has no problem (but never addressed my
> questions). My interest is in a multilingual framework, which can be
> adapted to particular needs, as per the Charter.
>
> 2. I now see that that quoted particular problem is not related to the
> langtags librairies, but to the limitations of the charsets librairies. And
> that the idea is to use the langtag to carry a payload which does not
> belong to it, as specified by a previous RFC.
>
> This does not change much in terms of architectural framework, since the
> langtag can be used as a data base for everything missing elsewhere. But it
> changes the way we are to study and address the Charter request. This is an
> RFC 2130 violation and an absurd request. Full stop. But it is necessary to
> address if to an absurd need.
>
> This must be made clear to all, if to reach a consensus, and why it is not
> possible to do in the normal way. Otherwise no one will ever understand
> why, when the charset, the language, the region, the referent and the style
> are at least necessary to document the linguistic aspects of a document
> (together with a reference to the date of generation to know the used
> ersion of the standard), you want to have two possibly different or even
> conflicting charsets defined and no referent and no style.
>
> Very interesting.
> jfc
>




_______________________________________________
Ltru mailing list
Ltru at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru