Subject: Re: [iucg] UTF-8

From: jean-michel bernier de portzamparc <[email-masked]>
Date: Sat, 19 Jun 2010 10:22:36 +0200

Dear Nicolas,
The points you raise from your perspective are those we raise from our
Internet Users' perspective. I am not familiar with your area but for two
years we met the same problem we analysed in terms of "IS/ARE, MUST, SHOULD,
MAY" interoperation. The major IDNA2008 is the switch of the MUST from the
Internet system, to the internet use interface (we named "internet peritem"
to get a clear difference) that itself is related to the User Inteface of
applications of the present/future "internet exotem".

You join us in calling for "MUST"s that permit interoperability and you call
for someone issuing these MUSTs. There is no MUST in IDNA2008, there only
are "IS/ARE". IDNA2008 says the way the Internet System is (DNS), period
(IS/ARE). Now, we need someone to tell/some place to discuss how we MUST
relate with these "IS/ARE" for the things to work. Then developpers will be
able to adapt in using the SHOULDs that Andrews describes: they will
interface these MUSTs (on the peritem side) and the users MAYs on the
external side, i.e. the Internet exotem.

This is for IETF an "unusual" case ("unusual" is the core word of the
WG/IDNABIS "Mapping" consensual document killed by the IESG): the IETF meets
the new "IS/ARE" level and has to get MUSTs defined _outside_ of its usual
scope/area.

I have initiated the [email-masked] mailing list to discuss that
"MUST"s and their relations with IDNA2008 "IS/ARE"s, and we reserved
"IDNA2012.org" to the further discussion of the SHOULD between the Internet
use MUST (how one external system MUST use the Internet) and what users MAY
want to do. We used the 2008/2010/2012 sequence to underline that this is
not an IDNA versioning (as ccNSO started to imply) but a layer continuity.

Debates with the WG/IDNABIS Chair, however shown that this
[email-masked] work was premature as long as there was not a community
agreement on what you ask: who is to discuss, and where, that MUST part,
along which lines. This is why JFC Morfin introduced his appeal, as an
operational user missing an answer, like you.

This is because, if from the very begining we have a response we work on
(ML-DNS - multi-layer DNS which matches the IAB I_D demand), if we have
commited that it will come atop of IDNA2008, and we have been consensual
with IDNA2008 because it enforces no MUST that would conflict with ours, we
do not want to introduce a super "NAT-like" problem without prior IAB
guidance.

Along our scheme, your threads do not belong to the IDNABIS mailing list
which has completed its work (cf. Charter) but to our  http://IDNA2010.org
[email-masked] mailing list - _once_ its context has been commented by
IAB. You discuss interop with your Internet area needs. As users we also
have concerns of interoperability with the so called "ICANN domain name
industry" and its adminance, with other digital technologies, and with what
really interests us: the Intersem (semiotic Internet of subjects). Interop
with Microsoft Kinect is what is of prime interest. UTF-8 and IDN is just an
analogy for the "Natale-codeset" by Microsoft or IETF and image domain names
(IDNs).

There is still a long way to go. From the rock solid basis of IDNA2008 which
has no MUST and has split the Internet from the Unicode limitations without
repudiating its huge contribution.

Portzamparc

2010/6/19 Nicolas Williams <[email-masked]>

> On Fri, Jun 18, 2010 at 05:33:00PM -0400, Andrew Sullivan wrote:
>  > > In this context I don't care what "longtime IETF participants" think.
> > > I care what the middleboxes do.
> >
> > Never mind middleboxes (because yes, they make life complicated).
> > Think just about applications that think they're doing reasonable DNS
> > sanity-checking.  There are _still_ places I can't put my .info email
> > addresses, because of some heuristic that no TLD is longer than 3
> > characters.  We're not even into the interesting problems, and we're
> > already broken.
>
> I don't care to broaden the scope of what we should concern ourselves
> with to include Joe Sixpack's website's user registration form that
> "validates" domainnames.
>
> > If I've read you right, you want to say what people MUST do.  I think
> > that's a mistake.  I think the best advice is to say that certain
> > practices maximize interop, that using either of A-label or U-label
>
> Of course we must say what implementors MUST do if we want interop!  In
> fact, we couldn't have interop if we didn't.  (Well, we can always
> interop with non-IDNs, but interop with IDNs is exactly the point here.)
>
> If there's any place where we can't decide what an implementor MUST do
> to achieve IDN interop then it must be the case that either we don't
> have enough information or we can't reach consensus on one approach or
> another because there is no common approach that wouldn't be costly to
> some significant part of the deployed base's users.  And even then
> nothing stops us from reaching consensus on some requirement eventually.
>
> > (with adequate type checking) will work, and that it would probably be
> > best to settle on [pick one.  I prefer A-label, but I don't care that
> > much because they're freely convertible].  If the latter is what
> > you've been saying, I am sorry that I so badly misunderstood.
>
> I think every domainname slot has to be taken on a case-by-case basis.
> We already have IDNA rules for a number of domainname slots.  Some slots
> we'll be able to declare as IDN-aware and we'll be able to allow
> U-labels and even raw Unicode in them (because the receipient will be
> able to apply ToASCII() and/or ToASCII(ToUnicode()) as necessary.  Some
> slots we'll have to declare as IDNA-unaware and restrict them to
> A-labels [if we want IDN interop].
>
> Nico
> --
> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>

---

From: Stéphane Lancel <[email-masked]>
Date: Wed, 23 Jun 2010 01:08:02 +0200

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.

2010/6/22 Nicolas Williams <[email-masked]>

> 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.

> 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.

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.

 Of course, there's a reason such a list is
> missing: we need to consider all domainname slots on a case-by-cases
> basis, and the IDNAbis WG couldn't have tackled that job.
>
> I think the lack of an even of small subset of these slots is a problem
> -- not a huge problem, but it is a problem.  I also think that more
> guidance to protocol designers, and to developers, would be nice -- if
> it weren't so late, I might insist on it.  However, I think there's
> enough for us to get by, and any guidance that could be given couldn't
> be normative.
>

Yeap. Internet side designers can normalize (IS/ARE) or standardize (MUST)
what is inside the Internet system, not what is outside.

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
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.

> 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.

Best.

Stephane Lancel

---

From: Elisabeth Blanconil <[email-masked]>
Date: Wed, 23 Jun 2010 15:49:43 +0200

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 <[email-masked]> a
écrit :

> On Wed, Jun 23, 2010 at 01:08:02AM +0200, Stéphane Lancel wrote:
> > Nicolas,
> I'm afraid we're failing to communicate even though we might actually be
> saying the same thing.  See below.
>
> 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.
>
> OK, so perhaps we are saying more or less the same thing.
>

YES, modulo what IAB will answer to JFC.

> 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.

> 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.

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jun 2010 16:27:37 -0500

> (IS/ARE). Now, we need someone to tell/some place to discuss how we MUST

Well, a quick check of draft-ietf-idnabis-protocol-18 shows plenty of
normative language in use:

"
3.1. Requirements

   IDNA makes the following requirements:

   1.  Whenever a domain name is put into an IDN-unaware domain name
       slot (see Section 2 and [IDNA2008-Defs]), it MUST contain only
       ASCII characters (i.e., its labels must be either A-labels or NR-
       LDH-labels), unless the DNS application is not subject to
       historical recommendations for "hostname"-style names (see
       [RFC1034] and Section 3.2.1).
"

There are five more MUSTs just in that section (3.1).

I count 28 (28!) MUSTs and MUST NOTs altogether in that one I-D.

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.  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.  Of course, there's a reason such a list is
missing: we need to consider all domainname slots on a case-by-cases
basis, and the IDNAbis WG couldn't have tackled that job.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 22 Jun 2010 18:39:12 -0500

nor-ma-tive
Function: adjective

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>

each protocol.  So, to standardize the IDNA handling of NFSv4's

Nico
--

---

From: Russ Housley <[email-masked]>
Date: Wed, 23 Jun 2010 15:12:46 -0400

http://www.ietf.org/iesg/statement/normative-informative.html

I think the definitions of these words are pretty clear from this
statement made in 2006.

Russ

---

From: jefsey <[email-masked]>
Date: Thu, 24 Jun 2010 01:58:12 +0200

>I think the definitions of these words are pretty clear from this

Unfortunately no: this is pure IETF internal.

This terminology problem is a fundamental issue that we meet all 
over, in particular at ISO. Until globalisation (with an English or 
French "s" as in distributed, not an American "z" as in 
decentralized) norms and standards were accepted as roughly 
equivalent (norm being of latin origin, and standard being of saxon 
origin). The reason why was the local cultural loop : what people 
want, progressevely becomes what they do.

This is not the same when people do what they do (norma) which is 
diverse throughout the world, and are to do (standard)  what one 
culture wants to do and "internationalizes" its standard  This 
becomes a synonym for e-colonization. This is what IDNA2008 addresses 
through an unique plug, everyone can interface the way the want and 
still has to be study (please let not start an RFC 4646 battle again :-))

IDNA2003 stringprep is internationalization and cannot work. IDNA2008 
is not, it IS the way Internet (not Unicode) supports external 
diversity. So, seen from the Internet Use Interface; IDNA2008 is not 
a standard, is it the way things ARE.

However, it is not Informative, it is more stringent than normative 
(in the actual meaning of "standardizing"). You can write all the 
MUSTs you want, if they conflict with an IS/ARE there is no way your 
standard can work. Userside's MUSTs will say how the users wants to 
interface it.

The semantic confusion coming from the opposition between American, 
English, French (Latin) semantics - sometimes English being on the 
Latin other times on the American side - on the opposing concepts of 
globalization vs. globalisation, norms vs norms, standards, 
concertation,language, confederal vs. federal, etc. is a thinking and 
translation nightmare - more over when words tend to change meanings 
like concertation in English joining the Brussels European English sense.

This is why there is a need for a post-IDNA framework that IAB is to 
publish, either by themselves (they start very low key with John's 
I_D) or in response to my appeal or that we will have to publish. 
Whatever this response is, I had just to put in the records that I 
gave IESG and IAB a full notice and all the elements to set-up their 
mind - otherwise it would be a conflict instead of an extension in continuity.

Then experimentation should be of the essence, raising difficult 
questions and getting technical objections and architectural 
explanations. IETF is seeing the Internet from the inside and says 
MUSTs, we see it from the outside and see what it actually IS (many 
of the MUSTs never resulted in an IS).  IAB to say if they want the 
IETF to extend its perspective and how.

Best
jfc

>iucg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/iucg