Re: [iucg] UTF-8

[Russ Housley <[e-mail]>]

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

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