Re: [iucg] [workon] UTF-8

[Elisabeth Blanconil <[e-mail]>]

Dear Nicolas,
all of us are in agreement.

You just use words in a meaning that is inappropriate in a situation the
WG/IDNABIS qualified as "unusual", something the IESG killed, JFC appeal
calls to be clarified, the IAB has notified its intent to document as an
RFC, and JFC appeal should lead them to further document on precise points.

You and IDNA2010 (embodiement of IDNA2008 on the use side) are individually
discussing issues that we consider as intrinsicaly architectural and even
fundamental. Let clarify: IDNA broke the legacy internet, and IAB is to
provide guidance on the way they want to benefit or not of the resulting
situation.

Le 23 juin 2010 01:39, Nicolas Williams <[e-mail]> a
écrit :

> On Wed, Jun 23, 2010 at 01:08:02AM +0200, Stéphane Lancel wrote:
> > Nicolas,
> > Jean-Michel only explained you our Internet User position. The MUSTs you
> > refer to are actually "IS/ARE". They document the way the existing DNS IS
> > behaving. IF you want it to work properly you MUST do this, because this
> is
> > the way the Internet IS.
>
> I'm afraid we're failing to communicate even though we might actually be
> saying the same thing.  See below.
>
> > 2010/6/22 Nicolas Williams <[e-mail]>
> > > And by my reading these are very strong normative requirements.  That
> > > very first one requirement that I quote above is the most important
> one.
> > > It captures the essense of IDNA.
> >
> > There a major difference between "normative" (the way normality is) and
> > standardizing (the way things must be). This is a global difficulty borne
> > from the size of the systems we consider. This is what IDNA2008
> addresses.
> > Four us, this is the RFC195/RFC3439/IDNA2008 Internet architecture.
>
> I'm afraid you're confused as to what "normative" and "informative" mean
> in English.  "Normative" means "this is how things should be"; it does
> not mean "normal".  "Informative" means "this is how things are".  In
> fact, Webster's dictionary says:
>
> nor-ma-tive
> Function: adjective
> Etymology: French normatif, from norme norm, from Latin norma
> Date: 1878
>
> 1 : of, relating to, or determining norms or standards <normative tests>
> 2 : conforming to or based on norms <normative behavior> <normative
> judgments>
> 3 : prescribing norms <normative rules of ethics> <normative grammar>
>

French norme, latin norma stands for what is "normal", average behaviour.
The usual "greedy algorithm" use to make the terms standard and norm
synonyms. Globalisation and very large system (cf. RFC 3439) do not. This is
the core of the problem which started, and is know, as
"internationalization" and often associated with US domination. This is
because IETF, W3C, Unicode, IEEE, etc. standards  are meant to replace or
dominate local, trade, national standards: this is an over simplified form
of interoperability. IDNA2008 has acknowledged that internationalization was
not an adequate global interoperability solution. Across the language
diversity, as well as across the protocol and application diversity.


> Whereas the definition of "informative" is:
> Main Entry: in-for-ma-tive
> Function: adjective
> : imparting knowledge : instructive
>

This has nothing to do with the mandatory nature of "ARE/IS".

>
> IDNA2008 has plenty of normative language.
>
> > > Now, what isn't specified in as much detail is: just what is an
> > > "IDN-unaware domain name slot".  Yes, a definition is given in
> > > draft-ietf-idnabis-defs-13, but there is no exhaustive list.
> >
> > This IS the key point.
>
> OK, so perhaps we are saying more or less the same thing.
>

YES, modulo what IAB will answer to JFC.


>
> > > If anyone
> > > is going to complain about lack of normative language in IDNA2008, they
> > > should complain about the lack of an exhaustive list of IDN-aware and
> > > -unaware domainname slots.
> >
> > Here is the IDNA2008 break through. It is not a lack but an architectural
> > dramatic progress. IDNA2008 confirms the way domainname slots ARE on the
> > Internet (i.e. use of ASCII DNS). It _decided_ NOT to decide about the
> way
> > domainname slots MUST be on the user side. This belong to the Internet
> use.
>
> I'm not sure I follow.  What is "the user side"?  The user interface?
> The user interface should definitely use Unicode (converted to the
> user's locale's codeset, if it's not Unicode).  Isn't this patently
> obvious?
>

No. IDNA2008 has precisely defined otherwise.  Its charter was to uncouple
IDNA from Unicode. In _relating_with_the_internet_ (in the IDNA context)
only IDNA2008 codeset will work.


> > > For example, in the NFSv4 WG we're discussing what to do about NFSv4's
> > > domainname slots.  First we need to establish how they are handled by
> > > existing implementations.  For at least some, if not all
> > > implementations, NFSv4's domainname slots are handled in an IDN-unaware
> > > fashion right now.  But that's not entirely dispositive: we could
> > > consider a) the cost and likelihood of fixing the deployed base, and b)
> > > interoperability options when "legacy" deployments exist, and we could
> > > conclude that we'd rather have these slots be declared IDN-aware in
> > > spite of their current treatment.  (We're still working this out in the
> > > NFSv4 WG; we've not made any decisions yet.)
> >
> > You are in the situation of every protocol designer having to use IDNs.
> This
> > is why there is a missing IAB guidance, so we speak of the same thing
> > (currently we do not). There is no definition given so far of what an IDN
> > is. The one we use is "Internet Domain Name", because  they are supported
> by
>
> Sure there is: "IDN" == Internationalized Domain Name.  See
> draft-ietf-idnabis-defs, section 2.3.2.3.
>

We just do not know/oppose on what "internationalization" may mean.
Internationalization means that something is internationalized by someone.
International means something which is shared among everyone, i.e. like the
Internet.


>
> > the Internet. But there are many other kind of names in use that are or
> > could be used on the Internet and interoperably outside of the Internet.
> >
> > IDNA2008 has documented that/how the Internet supports IDNs under their
> > A-label "xn--" form. Thats all. The "Mapping" document went further,
> outside
> > of the WG/IETF existing scope (making the internet work better). Here we
> > discuss making the Internet used better.
> >
> > > I have initiated the [e-mail] mailing list to discuss that
> > > > "MUST"s and their relations with IDNA2008 "IS/ARE"s, and we reserved
> > >
> > > Your claims regarding IDNA2008 and lack of normative language in it are
> > > clearly incorrect. Your invitation to join yet-another mailing list
> > > isn't exactly winning me over.
> >
> > No one is interested in discussing the issue (being already on that list
> or
> > not) before IAB says where the standardizing language you/we call for is
> to
> > be discussed and how.
>
> It's absolutely clear to me where to standardize the treatment of the
> Internet's many domainname slots: in the fora that are appropriate for
> each protocol.


Probably inparts yes.But the common background?
Let wait for the IAB to respond.


> So, to standardize the IDNA handling of NFSv4's
> domainname slots you must go to the NFSv4 WG.  For many protocols there
> is no currently open WG; for those individual submission I-Ds is the way
> to go.
>

This is precisely the way we do not want to venture too early. This is
because our user understanding of the RFC1958/RFC3439/IDNA2008 Internet
architecture seems quite different from the current IETF RFC 3539 Internet
IETF values and missions.

Once IAB has answered we will know how our (you included) Internet Users
vision (you have difficulties to locate us in your Internet model) is to be
documented either consistently (internal extension) or in continuity
(external continuations).

Elizabeth - with the help of JFC's comments