\include{parameters}
\usetheme{AFNIC}
\usepackage[french]{babel}
\usepackage[latin1]{inputenc}
\usepackage{bortzmeyer-utils}

\title{IDNAbis}
\author{Stéphane Bortzmeyer\\AFNIC\\\texttt{bortzmeyer@nic.fr}}
\date{2 novembre 2010}

%\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex} 
% \setlength{\parskip}{15pt} 
\setlength{\parskip}{15pt plus 10pt minus 10pt} 

\begin{document}

\maketitle

\begin{frame}
  \titlepage
\end{frame}

\begin{frame}
\frametitle{Rappel : motivations pour IDN}
Permettre d'exprimer des noms de domaine dans toutes les écritures du
monde.

« L'usage de l'Internet doit être exactement aussi facile pour un
chinois que pour un états-unien. » (Ted Hardie)
\end{frame}

\begin{frame}
\frametitle{Rappel : fonctionnement d'IDN version 1}
\begin{enumerate}
\item Canonicalisation (normalisation) du terme Unicode par nameprep
\item Encodage en Punycode (ACE) : \computer{xn--pgbs0dh}.
\item Utilisation de l'ACE entre les serveurs de noms
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{Insatisfactions avec IDNA 1}
\begin{enumerate}
\item Dépendance par rapport à Unicode 3.2 (cas du Tifinagh)
\item Étape de normalisation qui en faisait trop ou trop peu
\item Erreurs BIDI pour des écritures comme le Thaana
\item Réglements de compte
\item Désir de l'ICANN de retarder les IDN
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{La légende du hameçonnage}
En pratique, le hameçonnage dans le monde réel ne dépend quasiment
jamais d'une confusion entre homographes. 

Les messages de hameçonnage
réels utilisent des adresses IP, des noms vaguement similaires
(\computer{secure-societegenerale.com}
vs. \computer{secure.societe-generale.com}) et ne cherchent pas à
tromper M. Ali : celui-ci ne lit pas les URL\ldots

\end{frame}

\begin{frame}
\frametitle{Cinq nouveaux RFC}
\begin{itemize}
\item RFC 5890 « Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework »,  donne les définitions des termes essentiels comme les nouveaux U-label (forme Unicode d'un nom légal) et A-label (forme Punycode d'un nom légal),
\item RFC 5894 « Internationalized Domain Names for Applications (IDNA):
Background, Explanation, and Rationale », explique et justifie, le
projet IDNAbis et ses concepts ; ce RFC n'est pas une norme, il n'est
là que pour information,
\end{itemize}
\end{frame}

\begin{Cinq nouveaux RFC, suite}
\begin{itemize}
\item RFC 5891 « Internationalized Domain Names in Applications (IDNA):
Protocol  », est le c\oe{}ur de la nouvelle norme, il décrit le
protocole utilisé,
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Cinq nouveaux RFC, fin}
\begin{itemize}
\item RFC 5892 « The Unicode code points and IDNA  », spécifie l'algorithme utilisé pour déterminer si un caractère est légal en IDNAbis, illégale ou bien si sa légalité dépend du contexte,
\item RFC 5893 « Right-to-left scripts for IDNA », expose les règles pour les noms de domaine dont une partie s'écrit de droite à gauche (par exemple en hébreu),
\item RFC 3492, « Punycode: A Bootstring encoding of Unicode for
Internationalized Domain Names in Applications (IDNA) », est maintenu.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Les nouveautés en un transparent}
\begin{itemize}
\item Le protocole est désormais indépendant de la version d'Unicode : tout changement dans Unicode est automatiquement disponible.
\item Les caractères de ponctuation et les symboles sont désormais presque tous exclus.
 \item Il n'y a plus d'étape de normalisation standard.
 \item Le modèle de sélection des caractères autorisés est passé de « entièrement manuel, caractère par caractère » à « essentiellement algorithmique, fondé sur les propriétés Unicode ».
\end{itemize}
\end{frame}

\frametitle{Nouveautés : indépendance de la version d'Unicode}
La liste des caractères autorisés est désormais \emph{calculée} à
partir d'un algorithme (et non plus faite à la main). RFC 5892 pour
les détails.

À chaque nouvelle version d'Unicode, il suffit de refaire tourner
l'algorithme et on obtient les nouvelles tables.

Un peu d'exceptions ont été manuellement ajoutées.

Pas d'implémentation publique du RFC 5892 (l'IANA utilise un code de
Patrik Fältström, non distribué). J'ai une implémentation de 50 \% de l'algorithme.

\end{frame}

\begin{frame}
\frametitle{Nouveautés : définition en intension des caractères légaux}
Désormais, un caractère est interdit s'il n'est pas explicitement autorisé.
\end{frame}

\begin{frame}
\frametitle{Nouveautés : plus de canonicalisation standard}
Le RFC 3491 (nameprep) n'est plus utilisé. Chaque application est
désormais libre d'effectuer la correspondance entre ce qu'a tapé ou
sélectionné l'utilisateur et l'IDN envoyé sur le réseau.

Cela permet à l'application de tenir compte du contexte, par exemple
de la langue.

Il existe des canonicalisations possibles (mais non obligatoires) :
RFC 5895, « Mapping Characters for Internationalized Domain Names in
Applications » ou comme le TR \#46 d'Unicode.
\end{frame}

\begin{frame}[fragile]
\frametitle{Migration}
Beaucoup de noms légaux (mais peu utilisés en pratique) sont devenus
illégaux. Nécessité d'une période de transition.

Des noms identiques sont devenus différentes (\texttt{strasse.de}
et \texttt{straße.de}). DENIC fera un lever de soleil avec priorité à
l'ancien titulaire \url{http://www.denic.de/en/denic-in-dialogue/news/2985.html}.

\end{frame}

\begin{frame}
\frametitle{Premiers problèmes}
La sortie de Unicode 6.0 le 11 octobre a été le premier test du nouvel
algorithme.

Deux caractères voyagent des Interdits vers les Autorisés. OK.

Un caractère, U+19DA, le zéro du Tai Lue, voyage en sens
inverse. Faut-il l'ajouter aux exceptions manuelles, pour qu'il reste
autorisé ?

Donner la priorité à la stabilité ou bien à la fidélité à Unicode ?
\end{frame}

\begin{frame}
\frametitle{Déploiement}
RFC tout nouveaux, profonds changements en interne.

Mais, en pratique, peu de changements pour les registres. 
Même préfixe, la plupart des noms légaux restent légaux et
les illégaux le restent.

Encore très peu d'implémentations.

\url{http://www.bortzmeyer.org/idnabis.html}

\end{frame}

        
\end{document}
