RE: [Ltru] RFC 2277 - considerations

[Misha Wolf <[e-mail]>]

-> no, let's not go down that path (*please*)

and (modifying your 3rd option):

-> I'd *not* like to hear more discussion of his proposal

and a suggestion:

Could we set up a separate list called, say, ltru-jfc, 
where Jefsey could talk to himself?

Thanks,
Misha


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Randy Presuhn
Sent: 14 May 2005 18:55
To: LTRU Working Group
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



-----------------------------------------------------------------
        Visit our Internet site at http://www.reuters.com

To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo 

Any views expressed in this message are those of  the  individual
sender,  except  where  the sender specifically states them to be
the views of Reuters Ltd.


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