Re: RFC 2434 term "IESG approval" (Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option)

["JFC (Jefsey) Morfin" <[e-mail]>]

I am quite glad we cooperate to the outreach of the WG-ltru.

At 06:16 29/06/2005, Randy Presuhn wrote:
> > Yes. But we are missing experts in networking, Internet standard process,
> > multilingualism, national cultures, LDAP, standard document witing. This is
> > a actually complex issue (mix of lingual subjective and
> > networking/standardisation precise issues).
>
>More untruths.  The working group's members include Harald Alvestrand, and
>John Klensin, to name a few who know something about the Internet standard
>process.  I think working group member Kurt Zeilenga is adequately 
>qualified on
>LDAP issues.  Both of the co-chairs have served as editors of multiple RFCs,
>as have several of the WG members.  Some of us also have experience editing
>ISO and ITU standards, and some members have experience in the W3C or the
>Unicode Consortium, to name just a few.  I suppose WG members like
>James Seng might have something to say on "multilingualism" and "national
>cultures" as would both co-chairs (both living in multi-cultural, 
>multi-lingual
>households), if those discussions were relevant to the mechanics of
>the syntax and registration of tags for the identification of languages.

I did not yet any contribution of the quoted persons. I am glad they 
joined: their contributions will certainly help the work of the WG. The 
issue is complex and as important as the creation of the name space or IP 
addressing. It is the naming structure of the Multilingual Global NGN.

Opposition is between the vision of an "application/author" oriented 
W3C/Unicode affinity group, focusing on the writing of a document, and the 
experimentation effort I represent which is interested in its multiple 
"networked usage" architecture. This is "what for" question the Draft does 
not document yet (Martin Düerst just introduced an interesting suggestion 
to permit that: if the scope of the Draft is clearly defined, what is not 
addressed if not blocked, but reserved for further study. This idea is a 
good idea which should probably investigated in other cases).

The problem is the same as in the HBH case (Harald was right to quote it in 
unwillingly supporting Dr. Roberts). We are in a gigantic change period for 
the Internet, from an architecture which started with four machines to a 
global multi-everything architecture. It is normal that tensions exist. 
What is not normal is that they result in ad hominems and in stubborn 
denials of dialog and cooperation (usually a demonstration of weakness: 
this is not good, we are not here to oppose but to build together - but it 
has to make sense).

Dr. Roberts, myself and many others, starting with ICANN (ICP-3 document), 
call for the need to experiment and not to be blocked by outdated legacies. 
Others try to oppose for many good (stability, experience, etc.) and less 
good reasons (I know better, this is the way it is). John Klensin started 
discussing that well. The good reasons of both sides must be considered, 
the poor ones filtered out. In the case of RFC 3066 Harald introduced a 
possibility which should be present everywhere, and which has been quoted 
here: "x-tags" are for free private use. This permits experimentation and 
specialised applications. (Except that to comply with some possible old 
experimentations the free, private x-tags should be restricted to 8 
hexatridecimals :-) !!!). HBH would be up and running/faling, no one 
knowing it, no one being hurt, no one having wasted time.

-->

The list of WG-ltru "angels" Randy quoted, shows the interest of the 
WG-ltru. If John Klensin, Harald Alvestrand, Kurt Zeilenga and James Seng, 
etc. contribute, with  Randy and Martin Düerst as co-chairs, contributors 
of same stature will certainly have the occasion of interesting exchanges.

> > >The ltru WG consensus was to not delay our work in order to align with ISO
> > >11179.
> >
> > This is unfortunately a self-evaluation of the WG  current consensus
> > process  ... I say this because the WG charter says "[the Dratf/WG] is also
> > expected to provide mechanisms to support the evolution of the underlying
> > ISO standards". The ISO 639-6 and ISO 639-4 persons (present on the list)
> > explained these two standards will comply with ISO 11179. ISO 639-4 defines
> > the guidelines for all the language standards used by the WG. This
> > consensus therefore opposes the charter (but if the Draft does not want to
> > be BCP 47, this is IMHO acceptable, but must be discussed).
>...
>
>Providing support for the evolution of the underlying standards does not
>require conformance (whatever that might mean)

con·for·mance    ( P )  Pronunciation Key  (kn-fôrmns)
n.
Conformity.

Source: The American Heritage® Dictionary of the English Language, Fourth 
Edition
Copyright © 2000 by Houghton Mifflin Company.

>to ISO 11179, any more than it means we should use the same word processor 
>used to edit the ISO documents.

Non-Members should understand that when Randy refers to the script, 
language and country parameters of the word processor being used. This 
calls for two comments:

1. the word processor also uses two other parameters: the referent of the 
used language (ex. dictionary) and the context in which it is used (ex. 
style) as everyone using Word for example can check. The current RFC 3066 
langtags are informal and open. They can accommodate much flexibility. The 
RFC 3066 bis langtags are structured and rigid: in refusing to include the 
referent and the context they become totally out of scope.. Like if you 
were prevented to tell the vegetable and the dressing when ordering a McDo 
cold salad.

2. ISO 639 -1 and -2 have been defined before their experience (and many 
other standards) lead to the ISO 11179 convergence work. ISO 639-4 wants 
the ISO 639 to conform to ISO 11179, so ISO 639-3 will (what has low 
impact) and ISO 639-6 will extend that. The impact is that the proposed 
Internet langtags will conflict with the ISO langtags, the way they are 
going to be used in Industry, marketing, consumer goods, networking, 
international documents and standards, administration and immigration, 
UNESCO, WTO, WIPO, etc. etc. outside of the XML pages respecting the 
currently proposed Draft. Introducing confusion and loss of credibility and 
delays for the IETF.

Where the issue is quite worrying is that all this could root into
- the protection of a vision of the locales management (named CLDR) by the 
Members of the Unicode consortium
- against a generalised ISO 11179 lingual model including the locale, the 
multimedia convergence, the multimode aspects (writing is a seldom used way 
to use language, when compared to others).

No more than for HBH I think IETF should support one technical approach 
against another. And if it does it should not be by acrimony and harassment.

jfc












_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf