[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] IDNA text presentation (was Document Status?)
Dear Seng,
you read me wrong since we probably agree on most. My intent was not to
start a dispute but to see completed a job well done, while the question is
"is the text describing it OK?" and my position is "no".
On 16:48 04/09/02, James Seng said:
Your thread, however is the only one I seen (or heard) from all who has
read the draft to say they dont understand it.
I dont say that. I say it is not properly worded to serve its purpose, at
least the way I personally see such a purpose from my own needs. Thats all.
That alone would be a reason to discuss the wording. But I also see
disagreements in this WG that partly match my own disagreements. And I see
that a response to most is to put that text into a global wording
perspective. Only this will permit this work to foster innovation as a
basic building block at a well identified place. Rather than to be
considered by most as a transition and to lead to endless sterile and
absurd conceptual disputes over wording misunderstandings and usage
duration. This work is well done, has a definitive purpose and will be with
us for a long. But it will be built coherently on top and aside: it must
not prevent or harm such a development process due to a standalone word use.
I plan to extensively develop network system solutions based upon that RFC.
The current wording and lack of insertion into a global architecture
description will make it extremely difficult for human reasons. This will
also make it extremely difficult for every other Registry, Industry,
developer, governance body, other IETF WG, only because we will all talk
about the same things but in using our own layer's words - different from
the words (even apparently opposing) used to described the core of our system.
This will lead many gurus, trolls, politician, ignorant etc. to make us
fight, then try to concert over a common wording, etc.. until someone
rewrite that RFC in our common words. ie waste years and efforts for nothing.
All this can be prevented in the simple way I document: this WG has solved
a problem; now it is to say the people going to use the solution and build
for it, on top or around what it does, what it does not, from where to
where. In using the same words that the people producing its inputs and
that the people using its outputs use, so they all understand clearly each
other.
So either the draft is really hard to understand and all those who are
read it (including non-english speaker) have either somehow able to
understand it or keep silent, or there might some other problem with the
only one who fails to understand it.
I do not think you need to be personal. All the more than I certainly
proposed that my position could be wrong and did joke about my Frenglish
and low IQ. And apologized for that.
I think that those who read it either did not dare to comment because the
matter is complex and they feared to be responded as you does. The
difference with me is that I am one of the probably very few who wait for
the RFC. To build on top of it, with systems and users waiting for that.
For me the product of this WG is not its solutions - I take for granted
they are good ones - but the very text of the RFC. This is what we will use.
If I gather developers, meet customers, lobby politicians and tell them "we
are going to use the RFC solutions which is perfect, but in a global
perspective they missed", I will have to convince them I am right. If I
succeed, I will then have to convince them that I however right to use such
a solution.
Therefore, I think we should drop this thread as I do not seen any rough
consensus that there is anything unclear about the specification.
If you mean the way the process is technically described and the way the
process works, you are right. This is my premise.
If you mean the way its description can be used to describe a key building
block in the global Internet architecture, as far as my own developments
are concerned, I disagree.
jfc