Re: [iucg] UTF-8

[jefsey <[e-mail]>]

At 21:12 23/06/2010, Russ Housley wrote:
>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

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



>On 6/22/2010 7:39 PM, Nicolas Williams wrote:
> > 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>
> >
> > Whereas the definition of "informative" is:
> >
> > Main Entry: in-for-ma-tive
> > Function: adjective
> > : imparting knowledge : instructive
> >
> > 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.
> >
> >>> 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?
> >
> >>> 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.
> >
> >> 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.  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.
> >
> > Nico
>_______________________________________________
>iucg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/iucg