Re: [Ltru] RFC 2277 - considerations

["Mark Davis" <[e-mail]>]

> Should we adopt the general course of action outlined below by
> Jefsey?

Absolutely not.

‎Mark

----- Original Message ----- 
From: "Randy Presuhn" <[e-mail]>
To: "LTRU Working Group" <[e-mail]>
Sent: Saturday, May 14, 2005 10:55
Subject: Re: [Ltru] RFC 2277 - considerations


> Hi -
>
> Rather than addressing the numerous points and assertions
> individually, I'd like to get a hum from the working group:
>
> Should we adopt the general course of action outlined below by
> Jefsey?  I'm not looking for point-by-point responses at this time,
> just a succinct "yes, let's adopt the general approach Jefsey
> proposed," "no, let's not go down that path," or  "I'd like to hear
> more discussion of his proposal before deciding."
>
> Randy, ltru co-chair
>
> > From: "JFC (Jefsey) Morfin" <[e-mail]>
> > To: "Randy Presuhn" <[e-mail]>; "LTRU Working Group"
<[e-mail]>
> > Sent: Tuesday, May 10, 2005 7:02 AM
> > Subject: Re: [Ltru] RFC 2277 - considerations
> >
>
> > Dear Randy,
> > it is always a pleasure to repeat the same thing to you. So I will do it
again.
> >
> > At 04:05 14/05/2005, Randy Presuhn wrote:
> > >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.
> >
> > Never thought a WG was a resume contest, but I suppose I have no problem
> > with that.
> >
> > Now, it would be surprising that people who came for a purpose (which
will
> > never be globally consensual, two negative Last Calls), would be
confused
> > on what they want to achieve. Those who disagreed but me gave up.
> >
> > >Could you *please* identify the *specific* text in the draft you would
> > >like to add / remove / replace?
> >
> > I thought it was clear to you, since end of December.
> >
> > Remove: the whole draft.
> >
> > Add: the XML oriented parts of the Draft in the second document where
they
> > belong, together with a consistent documentation of its filters and
working
> > tools (you oddily have no problem to add them to langtag libraries but
you
> > cannot add them to charset libraries?), a good explanation of the
charset
> > violation needs, a clear assessment/commitment of the resources required
> > from IANA
> >
> > Replace: make BCP 47 an Internet technology (RFC 1591, 1958, 2277, 2301,
> > 3066, etc., etc.) consistent framework for the support of language
context
> > identification as one of the Multilingual Internet building blocks,
> > together with others works such: within IETF (OPES, IDN, LDAP, PPP,
SNMP,
> > etc.), outside (for the time being) the IETF (those I know of: classes,
> > groups, externets, CRC, ISO 639-X, UNITAG). And let document a
consistent
> > IANA external tables and values management consistent or aggregating the
> > current registries.
> >
> > >The IESG reviewed our charter before approving it.
> >
> > IESG will also review the deliverables of this WG before accepting them
for
> > a Last Call and then after the Last Call. And during an appeal if they
> > approved it. So would IAB after that if they confirmed.
> >
> > What is the interest to have something which pleases a small score of
> > supporters and is defeated by lack of global consensus? If the problem
is a
> > IANA registry conflict please tell us. If the problem is to ascertain
the
> > Unicode table vs. ISO 10646 please tell us. If the problem is to make
ISO
> > 15924 the center of the world please tell us. If the problem are W3C
> > analysis difficulties please tell us. If the problem is rooted in the
CLDR
> > structures please tell us.
> >
> > Your problem is neither to produce a Draft, nor to shut my mouth. Your
> > target is to address a problem. Either it is the one written in the
Charter
> > and IMHO its is partly erroneously worded the way you seem to read it.
Or
> > it is another one, and I doubt you can solve it if you do not spell it.
If
> > it is part of both, let sort it out first.
> >
> > >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.
> >
> > I commented positively on your proposition to have a WG. This is what I
> > asked for early January. I had proposed the creation of a WG-TAGs
because
> > this is what I am working on in a much broader scope. I was not opposed
on
> > a WG on language and I detailed my conditions a minima. These conditions
> > are not spelled out in the Charter, but since the Charter has been
> > submitted/reviewed to/by the IESG it is mostly consistent with the whole
> > Internet architecture (all the more that it MUST be read in its
perspective).
> >
> > >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.
> >
> > May be I am the only one with a very low IQ? Did you forget one thing, I
am
> > also the only one who does not to speak English. That alone should be an
> > alarm for you when addressing a multilingual issue. I am also the only
one
> > in various areas of importance to this topic (a ccTLD registry, the
founder
> > of the oldest user/operator structure, a former @large panelist, an
active
> > contributor to the WSIS process where multilingualism is a priority,
etc.).
> >
> > I only think there is a qui pro quo you should have resolved first. You
> > proposed a text with a W3C/Unicode culture, it was read by the IESG with
an
> > Internet culture. I read it with another more global network culture.
All
> > this makes the Internet, but one has to accept to have a limited
> > methodology. This starts with reviewing what all the participants have
read
> > and accept in your text, not  to end with it when everyone is gone.
> >
> > You said there were thorny points in the charter. There are. I am not
sure
> > you saw them all. I just waited for the list to be calm enough to rise
the
> > charset issue.
> >
> > Please understand, as I mentioned it in my response to the Chairs and
ADs,
> > I am as everyone else entitled to a Charter review by the WG to make
sure I
> > am not wrong, before producing my own Draft. Having a fragmented review
of
> > the Charter while most of the people disappointed with the Draft are
gone,
> > only delays the whole process and does not help. Neither me, nor the
> > current Draft.
> >
> > >No one else on this mailing list has expressed any confusion as to what
> > >our deliverables are.
> >
> > This is precisely the problem. On such a matter, there should have been
> > much more. This only means they are not here.
> >
> > Language tags, the way authors see them, are a deep change in the
Internet
> > architecture. This has lead to the opposition met during the first two
last
> > calls. This WG should have started in assessing that change. Its
reasons,
> > its implications. debreifing the opposition, not just jumping at an 11th
> > and 12th version of the same proposition with the same text.
> >
> > - They want a change which affects/opposes a consistent corpus RFC.
> > - I see one of the seeds of the response to an urgent market and
political
> > demand not addressed until now.
> >
> > Both have to be discussed. Better here than on the general list during
the
> > third Last Call, all the more if it is opposed by a short Draft of mine.
> >
> > You just start listing some of the points of my last month review (delay
is
> > not on my side) on the management system you chose. Thank you: this will
> > save me the time of listing during the Last Calls all the points I rose
> > which have not been discussed - what would have been poor (I am not sure
> > however you will list them all?). Now they have to be addressed. But not
> > all them are listed and most are listed in a way no one can understand
what
> > it refers to without accessing the whole review each time and to figure
out
> > where it is. I gave each point a "#" number (there are 55 of them). Why
not
> > just to paste them into your system before commenting them? Also, in the
> > follow-up, why to assume people agree with you (and not me) because they
> > did not comment?
> >
> > Think that my draft would use the Charter framework and quotes the
> > concerned RFCs, documenting how to support the XML, DNS, IDNA, OPES,
LDAP,
> > PPP, etc. etc. needs (even the non documented ones of CLDR) in the
scalable
> > way the Internet has always supported them with success up to
> > now.  Discussing the reducing ways others may have proposed over time
which
> > have been opposed with that success. Scalable, simple, robust, stable,
> > secure will be the keywords. I could also propose a F2F meeting before
the
> > Paris meeting. I would propose people from the MINC, UNESCO, WSIS,
> > Francophonie, etc. to attend.
> >
> > I accept there will be lacks in such a document of mine as I lack inputs
> > from the WG debate on the charter, and I have not the time, the
expertise
> > and the interest to became a specialist of all the IETF oddities it
should
> > aggregate and consolidate, such as the RFC of Ira McDonnald, and all the
> > times the internationalisation of the ASCII Internet is considered in
RFCs.
> > IMHO what you miss is that what you made at stake is the transition from
> > internationalisation to multilingualisation (actually to
vernacularisation)
> > - user to user relations, over brain to brain, over end to end. I accept
> > this is beyond what this WG is able to discuss, but this This is _your_
> > decision in wanting to replace BCP 47.
> >
> > I frankly prefer focusing on the Multilingual Global Network (MGN) - as
it
> > should progressively result from our current work, the WSIS, the dialog
> > between ITU, WSIS and the operators efforts (currently engaged). Let be
> > candid: if this WG does not produce a Draft along that lines, the Draft
(or
> > eventually an RFC) and the IANA registry will only be a problem to
forget.
> > Is that what you really want?
> >
> > Here is what I propose for a serious review of the topic:
> >
> > 1. what I had not time to do it yet: a dump of the whole IETF corpus and
a
> > grep on "international" and "lingual" to know which RFC can be affected
and
> > which experience has been gathered in there. There are more than you
> > thought in preparing the Charter.
> >
> > 2. to seriously review the problems, starting with those quoted by the
> > charter. What they really mean. What are the architectural implications
> > they may have in an MGN framework. They are not perfect, but they will
lead
> > to most of them.
> >
> > 3. what architectural responses they may call for and what this implies
on
> > the structures of the contents' containers.
> >
> > 4. _IF_ there are architectural changes (I doubt there are much, as the
MGN
> > IMHO concerns higher layers than the end to end architecture) what are
> > they? IMHO they concerns mainly the way to use IPv6, OPES and the DNS
due
> > to current implication of the DNS in the architecture of usage and
hyperlinks.
> >
> > 5. what is the stable, simple, robust framework the IETF technology
should
> > provide to the applications designers.
> >
> > 6. to seriously review the way this can be made supported by IANA and
CRCs.
> > And let implement test applications.
> >
> > 7. let discuss how to address the evolutions/trasnsitions possibly
implied
> > at a network level.
> >
> > This makes the first document.
> >
> >
> > Then a second document should use that stable foundations to write the
> > specific solution called by the documentation of the charset in the W3C
> > containers and the stabilisation of the XML langtag, its filtering,
sorting
> > etc. Another document could be proposed by Unicode (if free of IPRs) to
> > document the CLDR approach, propositions and specific own usage (if any)
of
> > this framework.
> >
> > I accept that the expertise of this WG is more oriented towards the
second
> > document and I am more interested in the first one. There are two
possible
> > responses to that:
> >
> > 1. either to follow my proposition above and make the general list aware
of
> > what we plan to discuss. I bet there will be new comers with depth and
> > breadth of expertise in the concerned areas (even if IETF, IAB and IESG
is
> > not much aware/motivated in the lingual areas).
> >
> > 2. or to follow the recommendations received on the general list during
the
> > Last Call. Let us stop pretending changing BCP 47: let consolidate RFC
3066
> > as it is today, with its relations to RFC 2277 and 2301, and publish a
> > specific solution for XML. I do not think anyone will oppose this. Only
> > some people will find it odd if you document IETF values violation they
may
> > want the IETF/W3C liaison committee to approve. This is the RFC 3066
> > bis/ter option. The real work will be carried afterward. And your
problem
> > will be quickly fixed. This is what I proposed the day we started the WG
> > and to work with the Authors on that. We could be done for a long.
Actually
> > the WG was even not necessary.
> >
> > I fully understand this is does not make things simple for you. But you
> > decided that the most complex issue Internet is to face since its
> > inception, and delayed for 20 years, was something simple. It is not.
> > All the best.
> > jfc
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> _______________________________________________
> Ltru mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ltru
>
>



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