ICANN/DNSO
DNSO Mailling lists archives

[nc-idn]


<<< Chronological Index >>>    <<< Thread Index >>>

[nc-idn] Re: Minutes from the NC IDN call on 3 Dec


Elisabeth,
 some suggested corrections to the minutes. Corrections tagged with MB:. 
s/word1/word2/  means substitute word1 by word2.

Marc.

=======================================

          * It is an application based processing, the user will type in 
the language and script of his domain name, the application will process it 
and convert it into ASCII. This is sent to the DNS resolution for an answer 
and IP address.

MB: s/for an answer and IP address/for an answer, usually an IP address/

...
            Currently the WG is discussing additional steps - the 
actualisation for Asian languages and handling the Chinese language.

MB: s/the actualisation for Asian languages and handling the Chinese 
language/optimisations for Asian languages and some specifics about the 
Chinese language/


            Next step is to reach consensus on remaing items, likely to be 
at the ITF in Salt Lake City. A solution will be sought with either IDN or 
IDN +John Kleinsen's proposal.

MB: remove: /A solution will be sought with either IDN or IDN+John 
Klensin's proposal./

MB: add a new paragraph:
 John Klensin's proposal based on upper layers over DNS will be discussed 
in a Birds-of-a-Feather session (irnss) in Salt Lake City IETF. This bof 
could influence the way idn handle complex language issues that can't be 
done in DNS.

MB: add a new paragraph:
  If a consensus happens in Salt Lake City, then the following steps will 
happen:
          * Validate the consensus on mailing lists.

          * Send the documents to the ISC and receive comments.

MB: s/ISC/IESG/
            ISC will send these to IETF.

MB: s/ISC will send these to IETF/IESG will then do an IETF-wide last call/

 IETF process will take time even if a decision is reached in Salt Lake 
City.

MB:s/decision/wg consensus/

            Publishing as RFC will follow and it will become an IETF 
standard.
            Choose a prefix.

MB: At the time of the RFC publication, the prefix identifying the idn will 
be chosen.

          * In conclusion: the technical issues are converging, the work is 
not yet finished, there is no standard, deployment must wait until the work 
is finished and the RFC is published.
            The winter or spring are foreseen as the timeline for 
deployment.

MB: s/timeline for deployment/timeline for RFC publication, so deployment 
might start at that time/

          * Katoh asked about the two ways of thinking currently prevailing 
in ICANN, The John Kleinsen approach which implies layers over the DNS, so 
that there is more flexibilty in handling language issues and the IDN 
approach.

MB: s/Kleinsen/Klensin/

            Nothing can be said until the RFC comes out.

MB: s/Nothing can be said until the RFC comes out/The two approaches may be 
complementary. Work of the idn wg is currently related to the idn approach. 
John Klensin's proposal surely have more flexibility in handling language 
issues/


MB: final note about terminology: Verisign presentation identifies the 
internet-drafts the idn wg is working on, as IETF standards. This may be 
misleading to the reader, since an internet-draft is a work in progress 
document and is by no means an IETF standard.



------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------



<<< Chronological Index >>>    <<< Thread Index >>>