Message-Id: <6.1.2.0.2.20050323130745.049410a0@mail.jefsey.com>
Date: Wed, 23 Mar 2005 17:33:46 +0100
To: "Mark Davis" <mark.davis@jtcsv.com>,
	"Addison Phillips" <addison.phillips@quest.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Ltru] Getting back on track
In-Reply-To: <047f01c52f47$e0f519f0$727d3009@sanjose.ibm.com>
References: <634978A7DF025A40BFEF33EB191E13BC0AB82644@irvmbxw01.quest.com>
	<047f01c52f47$e0f519f0$727d3009@sanjose.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Cc: ltru@ietf.org
Precedence: list
Sender: ltru-bounces@lists.ietf.org
Errors-To: ltru-bounces@lists.ietf.org

On 02:30 23/03/2005, Mark Davis said:
>I agree entirely with what Addison said, and want to emphasize that none=
 of
>this has any dependence on CLDR whatsoever.

I respond to both authors one shot.
I understand nothing of your responses.

1. I only note that Mark's proposed agenda will permit us to match the=20
Charter agenda.
2. I note that after having asked a long work, Addison's responses are in=
=20
the records.
3. I remind that the Charter specifies that: "The RFC 3066 standard for=20
language tags has been widely adopted in various protocols and text=20
formats, including HTML, XML, and CLDR, as the best means of identifying=20
languages and language preferences.". So, I will only quote your response=
s=20
on CLDR and Unicode copyrigths in a waiver about the support of CLDR. Up =
to=20
the IESG to decide if they maintain their Charter consideration on CLDR.

>Addison and I have been working on the current draft for quite a while, =
and
>have benefited from feedback from a wide variety of people. If you want =
to
>write your own document, you are of course free to, but I have the feeli=
ng
>that the direction that you are headed is far outside of the scope of th=
e
>current working group's charter.

What we all want is a consensus, not a conflict. The conflict comes from=20
you desire of exclusiveness when we all want inclusion. Everyone will be=20
more that happy to include your propositions to address your needs in a=20
general resolution. There will be no consensus otherwise.

>He and I will be focusing on comments on the current draft.

We all expect that.

But it happens that you both are the authoritative experts in closed=20
consortia applications the WG Charter makes us to consider (HTML and XML=20
for Addison as W3C, and CLDR for Mark as Unicode). It also happens that t=
he=20
matter discussed for a standardization in this WG is also subject to a=20
current normalization work, and active international thinking, in various=
=20
international technical, academical, societal, economical, political and=20
governmental fora we must first evangelize the participants about your wo=
rk=20
(hence the footing of my WG-ltru mails, and the delay in preparing a=20
framework). This obviously delays us.

jfc




>=E2=80=8EMark
>
>----- Original Message -----
>From: "Addison Phillips" <addison.phillips@quest.com>
>To: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>; "Mark Davis"
><mark.davis@jtcsv.com>
>Cc: <ltru@ietf.org>
>Sent: Tuesday, March 22, 2005 15:37
>Subject: RE: [Ltru] Getting back on track
>
>
>JFC,
>
>You have not presented a list of comments about the current draft. Neith=
er
>have you proposed an alternate design. Why should the WG wait for many w=
eeks
>while you write an individual submission Internet-Draft if you can't be
>bothered to debate the existing design or propose a new design?
>
>You'll note that before Mark and I wrote the very first draft of what is
>today the registry document we discussed the design in public. In my
>opinion, you should do the same thing. If there is a consensus favoring =
your
>design, then it can be incorporated into the working group's draft as
>appropriate.
>
>With regard to your question about my schedule: how about 'never'? I don=
't
>have time to help you write your document. I'm busy editing the official
>draft and engaging in necessary debate on this list. If you want to writ=
e a
>document, you're on your own. Both Mark and I have numerous publicly
>available documents describing our view of the requirements and our
>intentions. No doubt if we have objections to your proposal we will
>enumerate them in the proper way and at the proper time.
>
>With regard to CLDR, which is really Mark's area rather than mine, I wil=
l
>note that the current registry draft has *no* dependency on CLDR, nor sh=
ould
>it. Copyright issues in your individual submission are your problem,
>although I can't imagine any that would arise from referencing an extern=
al
>standard.
>
>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: ltru-bounces@lists.ietf.org [mailto:ltru-bounces@lists.ietf.org=
] On
> > Behalf Of JFC (Jefsey) Morfin
> > Sent: mardi 22 mars 2005 14:16
> > To: Mark Davis
> > Cc: ltru@ietf.org
> > Subject: Re: [Ltru] Getting back on track
> >
> > On 22:38 22/03/2005, Mark Davis said:
> > >The discussion has meandered around a bit: I'd like to see us get ba=
ck on
> > >track. Here is how I suggest we proceed.
> >
> > >Within the next week, anyone who has any issues with the text of the
> > current
> > >draft does the following:
> > >
> > >a. Composes a separate message on each issue, with a meaningful titl=
e.
> > >b. Suggests exact replacement text, with clear instructions on where=
 to
> > make
> > >the change.
> > >c. Describes the pros and cons of making the change.
> > >
> > >We review by email each request. If there is consensus for if, then =
we
> > >record that. If not, we leave it alone. Once we have processed all t=
he
> > >issues, we issue a new draft that incorporates all the changes. We
> > circulate
> > >that, and if there are no problems with the incorporation of all the
> > >changes, then we advance the document.
> >
> > As indicated we will not be in a position to issue a draft before at =
least
> > two weeks. It will certainly substantially differ from the current dr=
aft.
> > And will probably be amended during its further international review.=
 But
> > the support of your propositions should be as much possible included =
in
>it.
> > So this schedule seems OK if the Chairs agree. We should have your
> > elements
> > in time.
> >
> > I have however two missing information:
> > - when do you/Addison intend to comment the inputs he required from m=
e, so
> > I can organize our schedule?
> > - we have discussed nothing on the CLDR aspect. You are the best suit=
ed to
> > tell us what are the requirements of the CLDR project in the RFC 3066
> > context and how we can best address them? I am also obviously concern=
ed
> > about the copyright issue as the RFC should indicate that the CLDR is
> > public domain. Or we would have to investigate a public domain
>alternative.
> >
> > Thank you for your cooperation.
> > jfc
> >
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > Standardizing Tags for the Identification of Languages should not be =
a way
> > to standardize languages and to unify the world under a dominant cult=
ure.
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > For your convenience:
> > RFC 3066: http://www.ietf.org/rfc/rfc3066.txt?number=3D3066
> > Draft: http://www.ietf.org/internet-drafts/draft-ietf-ltru-registry-
> > 00.txt
> > Charter: http://ietf.org/html.charters/ltru-charter.html
> > gmane: http://dir.gmane.org/gmane.ietf.ltru
> > If you were Bcced for information and not familliar with the IETF pro=
cess:
> > http://www.ietf.org/rfc/rfc2026.txt
> > http://www.ietf.org/rfc/rfc2418.txt
> > http://www.ietf.org/rfc/rfc3934.txt
> > http://www.ietf.org/rfc/rfc3669.txt
> > http://www.ietf.org/rfc/rfc3160.txt
> > http://www.ietf.org/internet-drafts/draft-hoffman-taobis-02.txt
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > Jon Postel (RFC 1591): "The IANA is not in the business of deciding
> > what is and what is not a country. The selection of the ISO 3166 list
> >   as a basis for country code top-level domain names was made with
> >   the knowledge that ISO has a procedure for determining which
> > entities should be and should not be on that list."
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > Brian Carpenter (RFC 1958/3.2): "If there are several ways of doing t=
he
> > same thing, choose one. If a previous design, in the Internet context
> > or elsewhere, has successfully solved the same problem, choose the
> > same solution unless there is a good technical reason not to.
> > Duplication of the same protocol functionality should be avoided as f=
ar as
> > possible, without of course using this argument to reject improvement=
s."
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> > It seems that what works for countries and ISO 3166 since 1978, shoul=
d
> > apply to languages and to ISO 693.
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru


_______________________________________________
Ltru mailing list
Ltru@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/ltru