RFC: 959
Statut : Standard
Retour à l'index des normes : INDEX FRANCAIS

Remplace RFC: 765 (IEN 149)

File Transfer Protocol (FTP)

Spécification


Crédits : J. Postel, J. Reynolds / ISI
Traduction : Valéry G. FREMAUX Ingénieur Professeur / EISTI
Edition originale : Octobre 1985 / Version FR: Février 1997

Précédent - Suite - Retour au sommaire


3. FONCTIONS DE TRANSFERT DE DONNEES

Seul le canal de données permet le transfert effectif des fichiers. La canal de contrôle n'est utilisé que pour le contrôle des commandes, qui indiquent les fonctions qui doivent être exécutées, ainsi que les réponses à ces commandes (voir la Section traitant des Réponses FTP). Plusieurs commandes concernent le transfert de données entre hôtes. Ces commandes de transfert incluent la commande MODE qui spécifie comment les bits de données doivent être transmis, ainsi que les commandes STRUcture et TYPE, qui sont utilisées pour définir la manière avec laquelle sont représentées les données. La transmission et la représentation sont des notions indépendantes. Cependant le mode de transmission "Stream" reste dépendant des attributs de structure des fichiers et si le mode de transmission "Compressed" est utilisé, la nature des octets de remplissage dépendra de la représentation des données utilisée.

3.1. REPRESENTATION DES DONNEES ET STOCKAGE

Les données sont transférées à partir d'un espace de stockage dans l'hôte émetteur vers l'espace de stockage de l'hôte récepteur. Il est souvent nécessaire d'effectuer certaines transformations sur les données du fait de la différence de la représentation de ces dernières dans deux systèmes de nature différente. par exemple, le format NVT-ASCII est stocké sous diverses représentations selon le système. Les DEC TOPS-20 enregistrent généralement le format NVT-ASCII sous la forme de cinq caractères ASCII codées sur 7 bits, dans un mot de 36-bit calé sur la gauche. Les mainframes IBM enregistre ce même format sous forme de codes EBCDIC sur 8 bits. Le système Multics stocke le format NVT-ASCII sous la forme de quatre caractères sur 9-bits dans un mot de 36-bits. Il est souhaitable de convertir les caractères entre les diverses représentation du format NVT-ASCII lorsque des transmissions sont effectuées entre systèmes distincts, en passant par une représentation standard. Les sites émetteurs et récepteurs devront effectuer les transformations nécessaires entre la représentation standard commune et leur propre représentation interne.

Un autre problème de représentation apparaît lors du transfert de données binaires (codes non assimilables à du texte) entre deux systèmes travaillant avec des largeurs de mots distinctes. La façon dont l'émetteur envoie les données n'est pas toujours exprimée explicitement, pas plus que la façon dont le récepteur les stocke. Par exemple, lors de la transmission de "mots" de 32-bits à partir d'un système 32-bits vers un systèmes fonctionnant en 36-bits, il peut être souhaitable (pour des raisons de performance) de stocker les mots de 32-bits calés à droite du mot de 36-bits du système récepteur. Dans tous les cas, l'utilisateur doit avoir accès à l'option qui lui permettra de spécifier la représentation des données, et les transformations nécessaires. Il doit être noté que FTP n'admet qu'un nombre limité de formats de données. Les transformations en dehors du contexte limité proposé par FTP devront être prises en charge par l'utilisateur.

3.1.1. TYPES DE DONNEES

Les représentations de données sont gérées dans FTP par la spécification par l'utilisateur d'un type. Ce type peut être implicite (comme pour l'ASCII ou l'EBCDIC) ou explicite (comme le type Local), et définit une taille de mot dont l'interprétation correspond à celle de la "taille de mot logique". Notez que ceci n'a rien à voir avec la taille du mot utilisé dans la transmission dans le canal de données, appelée la "taille de transfert", la confusion entre les deux notions devant être soigneusement évitée. Par exemple, le format NVT-ASCII a une taille logique de 8 bits. Si le type est le type Local, alors la commande TYPE aura un deuxième paramètre obligatoire spécifiant cette taille logique. La taille de transfert est toujours égale à 8 bits.

3.1.1.1. TYPE ASCII

C'est le type par défaut et doit être reconnu par toutes les implémentations FTP. Il est à l'origine mis en place pour le transfert de fichiers texte, sauf lorsque les deux hôtes considéreront que le type EBCDIC convient mieux.

L'émetteur convertit les données depuis la représentation interne des caractères vers le format 8-bit NVT-ASCII standardisé (voir les spécifications Telnet). Le récepteur convertira cette représentation standard en sa propre représentation interne.

Conformément au standard NVT, la séquence <CRLF> doit être utilisée à chaque fois que nécessaire pour marquer une fin de ligne de texte. (Voir la discussion à propos des structures de fichiers à la fin de la Section traitant des Représentations de données et stockage). Le fait d'utiliser la représentation standard NVT-ASCII en 8 bits signifie que les données doivent être interprétées selon des "mots" de 8-bits. Les valeurs du paramètre Format pour les types ASCII et EBCDIC sont détaillées ci-après.

3.1.1.2. TYPE EBCDIC

Ce type est destiné à des transferts plus efficaces entre deux hôtes qui admettent l'EBCDIC comme standard de représentation interne des caractères de texte.

Pour la transmission, les données sont représentées comme des codes EBCDIC sous 8-bits. Le codage des caractères est la seule différence qui distingue les spécifications des types EBCDIC et de l'ASCII.

La fin de ligne (EOL équivalent à la séquence CRLF) (par opposition à la fin d'enregistrement (EOR)-voir la discussion sur les structures) sera rarement utilisée avec le type EBCDIC pour des raisons de reconnaissances de structure, mais lorsqu'une telle information est nécessaire, le caractère <NL> pourra être utilisé.

3.1.1.3. TYPE IMAGE

Les données sont transmises comme un champ de bits continu qui, pour le transfert, sont "empaquetés" dans des structures de transfert de 8-bits. Le site récepteur doit quant à lui enregistrer les données comme un champ continu de bits. La structure du système de stockage nécessite parfois l'utilisation de bits de "bourrage" pour le fichier (ou pour chaque enregistrement, dans le cas d'un fichier structuré sur une base d'enregistrements logiques) établissant ainsi un "calage" des données sur une frontière conventionnelle (octet, mot ou bloc). Ce bourrage doit toujours être fait par des bits nuls, peut intervenir à la fin d'un fichier (ou à la fin de chaque enregistrement) et il doit exister un moyen de les identifier afin qu'ils puissent être éliminés lorsque le fichier est récupéré. La transformation de bourrage devra faire l'objet d'une large et claire documentation pour permettre à tout utilisateur d'implémenter les traitements nécessaires à la reconstitution du fichier original dans le site récepteur.

Le type image est destiné à un transfert et un enregistrement optimal de fichiers binaires. Il est recommandé que ce type soit reconnu par toutes les implémentations FTP.

3.1.1.4. TYPE LOCAL

Les données sont transférées par mots logiques dont la taille est nécessairement spécifiée par un second paramètre obligatoire, "Byte size". La valeur du paramètre "Byte size" doit être un entier décimal; il n'existe pas de valeur par défaut. La taille de mot logique n'est pas nécessairement la même que celle du mot de transfert. Si les deux tailles sont différentes, alors les mots logiques devront être empaquetés selon une trame continue de bits, indépendamment des limites formées par le mot de transfert et avec le bourrage nécessaire ajouté à la fin.

Lorsque les données sont reçues sur l'hôte récepteur, elles seront transformées selon la taille des mots logiques du fichier transféré et la taille de la représentation interne du récepteur. Cette transformation doit être réversible (c-à-d, un fichier identique doit pouvoir être récupéré dans l'autre sens avec les mêmes paramètres) et devra faire l'objet d'une documentation précise et complète de la part des implémenteurs FTP.

Par exemple, un utilisateur envoyant des nombres à virgule flottante en 36-bits vers un hôte travaillant en 32-bits pourrait envoyer ces données sous le type Local selon une taille Locale de 36. L'hôte récepteur pourrait par exemple récupérer ces mots logiques et les enregistrer d'une façon à ce qu'ils puissent être manipulés facilement; dans notre exemple, une solution consiste à stocker les mots de 36-bits dans un double mot de 64-bits.

Autre exemple : le cas d'une paire d'hôtes travaillant sous 36-bits pourraient se communiquer des données en utilisant le TYPE L 36. Les données seraient alors transmises empaquetées dans le format 8-bits de la transmission, 9 octets transmis étant nécessaires pour transférer deux "mots" entre deux tels systèmes.

3.1.1.5. CONTROLE DE FORMAT

Les types ASCII et EBCDIC prennent un second paramètre (optionnel); il indique quel type de contrôle de format vertical , s'il existe, est associé à un fichier. Les types de représentation de données suivantes sont définis dans FTP:

Un fichier caractères peut être transféré vers un hôte dans l'un des trois buts suivants : pour impression, pour stockage et récupération ultérieure, ou pour traitement. Si un fichier est envoyé pour impression, l'hôte récepteur doit connaître comment le contrôle de format vertical format est représenté. Dans le second cas, il doit être possible d'enregistrer un fichier pour usage ultérieur dans sa forme originale. Enfin, il doit être possible de déplacer un fichier d'un hôte vers un autre, et de traiter ce fichier sur l'hôte récepteur sans ennui. Un format ASCII ou EBCDIC élémentaire ne satisfait pas à ces conditions. De ce fait, un second paramètre a été adjoint au paramètre de type, pour coder trois situations possibles :

3.1.1.5.1. NON PRINT

C'est le format par défaut à utiliser si le second paramètre (format) est omis. Le format NON-PRINT doit être accepté par toutes les implémentations de FTP.

Le fichier ne contient pas nécessairement des informations de contrôle vertical. Si un tel fichier est passé à un processus d'impression, ce dernier devra prendre des valeurs standard pour les espaces et les marges. Ce format sera usuellement utilisé pour des fichiers destinés à du traitement de données ou à être juste stockés.

3.1.1.5.2. TELNET FORMAT CONTROLS

Le fichier contient des codes ASCII/EBCDIC de contrôle de format vertical (c-à-d., <CR>, <LF>, <NL>, <VT>, <FF>) qu'un processus d'impression peut immédiatement interpréter. <CRLF>, dans cet ordre précis, signale une fin de ligne.

3.1.1.5.3. CARRIAGE CONTROL (ASA)

Le fichier contient des caractères de contrôle de format vertical conformes à l'ASA (FORTRAN). (Voir RFC 740 Appendice C; et "Communications of the ACM, Vol. 7, No. 10, p. 606, October 1964".) Dans une ligne, ou un enregistrement au format conforme au standard ASA, le premier caractère ne doit pas être imprimé. Au lieu de cela, il doit être utilisé pour déterminer le mouvement vertical du papier à effectuer avant que l'impression du reste de l'enregistrement ne soit effectué.

Le standard ASA spécifie les caractères de contrôle suivants :

Caractère

Espacement vertical

Espace

Avance le papier d'une ligne

0

Avance le papier de deux lignes

1

Avance le papier en début de la page suivante

+

Pas de mouvement (surimpression)

Il doit exister un moyen simple pour un processus d'impression de détecter la fin d'une entité structurale. Si un fichier est enregistré selon une structure d'enregistrement (voir ci-dessous), il n'y a aucun problème; les enregistrements seront explicitement marqués pendant le transfert et l'enregistrement. Si le fichier n'a aucune structure d'enregistrement sous-jacente, la séquence de fin de ligne <CRLF> est utilisée pour séparer les lignes d'impression, bien que l'effet produit par ces deux caractères soit masqué par la signification des contrôles ASA.

3.1.2. STRUCTURES DE DONNEES

En plus des différents types de représentation de données, FTP permet que la structure d'un fichier soit explicitée. Trois structures de fichiers sont connues de FTP:

Structure fichier, dans laquelle le fichier est considéré comme une séquence continue d'octets contigus, sans structure sous-jacente induite.

Structure-enregistrement, dans laquelle un fichier peut être vu comme une séquence d'enregistrements,

Structure-paginée, dans laquelle le fichier peut être considéré comme une suite de pages indépendantes indexées.

La "structure-fichier" est la structure par défaut et doit être considérée si la commande STRUcture n'a pas été utilisée, bien que les deux structures "fichier" et "enregistrement" dussent être acceptées pour les fichiers "texte" (c-à-d., fichiers affichant un TYPE ASCII ou EBCDIC) par toutes les implémentations FTP. La structure d'un fichier affectera à la fois la façon de transmettre le fichier (voir la Section traitant du Mode de Transmission) et l'interprétation de l'enregistrement sur le support de stockage.

La structure "naturelle" d'un fichier dépend de l'hôte qui l'enregistre. Du code source sera généralement enregistré sur un mainframe IBM comme une suite d'enregistrements de longueur fixe, et au contraire comme un flux de caractères séparé en lignes par une séquence <CRLF> par exemple, sur un DEC TOPS-20. Si le transfert de fichiers entre des sites aussi différents s'avère utile, il doit exister un moyen de différencier les stratégies de codage de chaque côté de la transaction.

Entre des sites naturellement orientés vers une structure "fichier" et d'autres utilisant naturellement une structure "enregistrements", on pourra rencontrer des problèmes à transférer un fichier basé sur une des deux structures vers un système s'appuyant sur l'autre. Si un fichier texte organisé en "enregistrements" est envoyé vers un hôte naturellement orienté "fichier", alors ce dernier devra appliquer une transformation interne pour l'enregistrer. Cette transformation est évidemment utile, mais doit être de plus totalement réversible pour assurer une récupération "à l'identique".

Dans le cas inverse de fichiers de type "fichier", vers un hôte travaillant en structures "enregistrement", se pose le problème de savoir quel sera le critère utilisé pour recomposer le fichier selon une structure d'enregistrements. Si cette division est nécessaire, l'implémentation FTP devrait utiliser la séquence fin-de-ligne, <CRLF> pour l'ASCII, ou <NL> pour les fichiers texte EBCDIC, comme délimiteur d'enregistrement. Si une implémentation FTP adopte cette technique, elle doit être prête à pouvoir procéder à la transformation inverse au cas où le fichier devrait être rapatrié vers son support original de type "fichier".

3.1.2.1. STRUCTURE FICHIER

La structure "fichier" est à considérer par défaut si la commande STRUcture n'est pas employée.

Dans une structure-fichier, il n'y a en fait aucune structure sous-jacente et le fichier doit être considéré comme une suite continue de caractères.

3.1.2.2. STRUCTURE ENREGISTREMENT

La structure-enregistrement doit être acceptée pour tout fichier "texte" (c-à-d., fichiers affichant un TYPE ASCII ou EBCDIC) par toutes les implémentations FTP.

Le fichier est alors reconnu comme une suite ordonnée d'enregistrements successifs.

3.1.2.3. STRUCTURE PAGINEE

Pour transmettre des fichiers discontinus, FTP définit une structure en pages. Les fichiers de ce type sont aussi connus comme des "fichiers à accès aléatoire" par opposition aux "fichiers à accès séquentiel". Dans ces fichiers, il existe souvent un certain nombre d'informations annexes, associées au fichier lui même (ex., un descripteur du fichier), ou à l'une de ses parties (ex., des contrôles d'accès aux différentes pages), ou les deux. Pour FTP, chaque section séquentielle d'un tel fichier est appelée page.

Afin d'exploiter des tailles et des attributs de page différents, chaque page est envoyée avec une en-tête. L'en-tête contient une sélection des paramètres suivants:

Header Length
(Longueur d'en-tte)
Le nombre d'octets logiques dans l'en-tte y compris lui-mme. La longueur minimale d'en-tte est de 4.
Page Index
(Index de page)
L'index de cette section du fichier (numéro de page logique). Ceci n'est pas le numéro de page transmise, mais plutôt l'index qui permet d'identifier cette page.
Data Length

(Longueur des données)

Le nombre d'octets logiques dans la page. La longueur de page peut être nulle.
Page Type

(Type de page)

Le type de page dont il s'agit. Sont définis les types qui suivent :
0 = Last Page
(Dernière page)
Utilisé pour indiquer la fin d'une transmission structurée en pages. La longueur d'en-tête de cette page est 4, et la longueur de page nécessairement 0.
1 = Simple Page
(Page simple)
Type d'une page normale du fichier ne disposant pas d'information de contrôle hiérarchique. La longueur d'en-tête doit être de 4.
2 = Descriptor Page
(Descripteur)
Type utilisé pour transmettre en un bloc toute la description externe du fichier.
3 = Access Controlled Page
(Page à accès contrôle)
Ce type inclut un paramètre supplémentaire destiné à l'accès à des pages organisées selon une structure hiérarchique à plusieurs niveaux. L'en-tête est de longueur 5.
Champs optionnels Des champs optionnels peuvent être ajoutés pour fournir une information spécifique sur la page elle-même, par exemple un contrôle d'accès individuel.

Tous les champs sont de longueur égale à un octet logique. La taille de l'octet logique est défini par le paramétrage de la commande TYPE. Voir l'Appendice I pour plus de détails.

Note d'avertissement concernant les paramètres : un fichier doit être téléchargé, enregistré et récupéré avec les mêmes paramètres si l'on souhaite récupérer une version identique à l'original. A l'inverse, les implémentations de FTP doivent renvoyer un fichier identique à l'original si les paramètres utilisés pour l'enregistrement et la récupération du fichier sont identiques.

3.2. ETABLISSEMENT DU CANAL DE DONNEES

Le mécanisme de transfert de données consiste en l'établissement d'un canal de données entre les ports appropriés et de ce fait en le choix des paramètres de transfert. Le USER et SERVER-DTP disposent tous deux d'un port de données par défaut. Le port "données" par défaut du processus utilisateur est identique à celui utilisé pour le contrôle de la connexion (c-à-d., U). Le port "données" par défaut du processus serveur est le port adjacent à celui utilisé pour le contrôle de la connexion (c-à-d., L-1).

La taille de l'octet transféré est toujours de 8-bits. Cette taille n'a de signification que pendant le processus effectif de transfert des données; elle ne présume en rien de la taille des unités logiques nécessaires pour représenter les données à l'intérieur du système.

Le processus de transfert de données à l'état passif (ceci peut être un USER-DTP ou un deuxième SERVER-DTP) devra "écouter" son port de données avant de pouvoir émettre une commande de requête de transfert. La commande FTP de requête de transfert détermine le sens du transfert de données. Le serveur, sur réception de la requête, établira la connexion au port "données". Lorsque cette dernière est établie, le transfert de données débute entre les deux DTP, et le SERVEUR-PI émet une confirmation à destination du USER-PI.

Toute implémentation FTP doit accepter l'utilisation des ports par défaut, et seul le USER-PI peut invoquer une migration de la connexion vers des ports non standards.

Le processus utilisateur peut demander l'usage d'un autre port "données" par l'intermédiaire de la commande PORT. Par exemple, un utilisateur demande l'impression d'un fichier sur une imprimante en ligne TAC lequel fichier doit être récupéré depuis un troisième hôte. Dans le dernier cas, le USER-PI établit un canal de contrôle avec les deux SERVER-PI. Il est alors demandé à un serveur (par une commande FTP) "d'écouter" une connexion qu'une troisième entité va initier. Le USER-PI émet à destination d'un des SERVER-PI une commande PORT indiquant le port "données" de l'autre connexion. Enfin, il est envoyé aux deux serveurs les commandes de transfert appropriées. La séquence exacte de commandes et de réponses envoyées entre le contrôleur de l'utilisateur et les serveurs est définie dans la Section traitant des Réponses FTP.

En général, il est de la responsabilité des serveurs de maintenir le canal de données actif-de l'initialiser et de le clore. L'exception à cette règle est lorsque le USER-DTP envoie des données dans un mode qui implique que la fin de fichier (EOF) correspond à la fermeture de la transmission. Le serveur DOIT fermer le canal de données sous les conditions suivantes :

  1. Le serveur à terminé la transmission de données dans un mode ou la fin de fichier est signalée par une fermeture du canal.
  2. Le serveur reçoit une commande ABORT de l'utilisateur.
  3. La spécification du port "données" est changée par une commande de l'utilisateur.
  4. Le canal de contrôle est fermé par une procédure normale ou pour toute autre raison.
  5. Une condition d'erreur irrécupérable est apparue.

Dans tous les autres cas la fermeture est une prérogative du serveur, l'exercice de la quelle doit être signalée au processus utilisateur par un code de réponse 250 ou 226 seulement.

3.3. GESTION DU CANAL DE DONNEES

Ports de données standard : Toute implémentation FTP doit accepter l'usage des ports de données standard, seul un USER-PI pouvant initialiser un canal sur un port autre que standard.

Négociation des ports autres que par défaut : Le USER-PI peut spécifier un port de données non standard à "viser" par le serveur via la commande PORT. Le USER-PI peut demander au serveur de s'identifier au serveur "cible" exprimé par ce port non standard via la commande PASV. La connexion étant définie comme une paire d'adresse, ces deux actions sont suffisantes pour obtenir à chaque fois un canal de données différent, bien qu'il soit admis de pouvoir déclencher deux fois ces commandes pour raccorder deux ports non standard à chaque extrémité d'un canal de données.

Réutilisation du canal de données : Lorsque le mode de transfert en "flux" est utilisé, la fin de fichier est indiquée implicitement par une fermeture du canal. Ceci pose un problème évident lorsque plusieurs fichiers doivent être transférés au cours de la même session, dans la mesure où TCP doit "bloquer" la connexion qui vient d'être utilisée pendant un certain temps fixé pour des raisons de fiabilité. De ce fait, une connexion ouverte sous ce mode ne peut pas être réutilisée immédiatement.

On donnera deux solutions à ce problème. La première est de négocier un autre canal sur des ports non standard. La première est de changer le mode de transfert.

Commentaire sur les modes de transfert. Le mode de transfert en "flux" est par nature non fiable, dans la mesure où il est impossible de déterminer si un canal est fermé normalement ou non. Les autres modes de transfert (Bloc, Compressé) ne ferment pas le canal après transmission du fichier. Le niveau d'encodage de FTP est suffisant pour que le canal puisse être "surveillé" et que la fin de fichier puisse être détectée. Ces modes sont donc tout à fait exploitables pour la transmission de multiples fichiers.

3.4. MODES DE TRANSMISSION

La considération suivante à prendre en compte pour transférer des fichiers est le choix d'un mode de transmission. FTP définit trois modes : un qui formate les données est permet de recommencer la transmission si nécessaire; une qui compresse en plus les données pour un transfert plus efficace; et un dernier mode qui laisse passer les données avec le moins d'encodage possible. Dans ce dernier cas, le mode interagit avec les attributs de structure pour déterminer le type de traitement. En mode compressé, le type de représentation détermine essentielDiscoteque - A Contribution to the Norvegia '99 Demo Competition - By Fadeout October 1999 Credits: Woody - Design, Music Loop - Code, Music Scuzzy - 3D Hellfire - Artwork It sure is no fun to compete with INF or Nocturnal. This demo doesn't look equal on any computers. If you're really unlucky, your display hardware doesn't support transparency on bitmaps, and you get blue boxes around some of the images (those who are hardware-blitted). Some 3D display cards also have some really fucked up polyfillers, which doesn't support all the features used in this demo, and you get ugly-looking effect. It's approx. 60% chance that the demo works perfectly on your machine. Due to all these compatibility problems, the demo has never crached.  {zy#497+(&,0/ ;PXUH7+! '/<BKOZfjwxxrrlpsy}|{}yuosrj`TIEFHORWZYXTXSPOLKKMQPMH@<822* yyyrq|$" &69;81) $%%#" '2@HMMGFFELW]`^ceu|wqjhb[PB1!!,/-%  |nVE55E]u~~~zurponmkklmljc\UUSX`decabbhfgfghlw !%,49<91'0BYrvrf\\YgryzfM/ +Mp{txtkjuz~ugSB5(#"'+6:81-")3>KLG9.! yv~o\Wczo`VX]l|vpjhgiruxvplhimuw""$"#'*(%',:GV\bbYPMJNWclu}}zusvw|plgmpvwvnkdb^\VPK@9/'yspqx|smjmknni^TD74;Kaw+?KRYaddaddju|}}}zmhgfaYK:( wrjifhkkkkgedcc_^ZUVYbq{|wroljkhggdb`XUPQSTOIC>AFRbt   #7CD4!!!%)5=GHF?<CL]ly|}ywyz|pdNECJ\huwwtpnptstmkkostrkfbeqzpV>7Hg|mbYWZVWQPMG?0 "5@HKPOPPPHD9." ## /AOWVME;89@INQURUZ_``ZTH?61)&!##&&'$%#" 1>IMKA7(%,674/&  vjeizueVV\j|zmlv{m\OLQ[adcc`cggnmqu{}wx{vgZQV_jsvxvpmfhkqv{wpdXY^gs{+4438>IT\ZM<(!+55037CLW\[\_`hp|njm}xh_]Y^acinqsuqprnrmfYK?95=HRUQB0}vnbUORbuzhYMIN]jv}yvrrv-?Uh~xg_WWTQKB5*" #6AC84-*,268764027:?A<4%   ,5?ANWcq|}sedZ\[^\ZZ\_^]XTTV\elprpmkmoqttm`P@534<CEICE92# }kYULPTZbfbVA--AV^`\TLD@>?>881*"  *=OY[WRNOW_m{xogdb^VND9/+',:FVaghmnu~(-6@ITcpz{ofb`fjikiec_XPKEBBIMRY]c_``cjp{~~}toqrv~|wqnigdcaWVRRRPLJ?4# *4:;80.+$%    ,:M\hry}}{xskf]ZUTVZalw}}{xusqof_ULGFJPVURH=2*"$-5?GE6#thchs{mcb_adjqx  *<KSTTSPSV\bffe`^X[TWVWWZ_hqutnd_ahqxooloj`YL?5/)'#|tknkge`_[USSNNRRTRPMMScu+/+#"(,'  $"'(28DMW\YQNMR`u~sljiqz{mc[XW[XTOF:1$ wniab]WXPIE??ADHB:1--2=AD@:3,!&08?CCDEO[ky '-59;=?DEILNQROKHDD@D@@81&#3GY`a^UPOOUZWVOIFKTblmna\NF?>62,*&+3<CECAAIRakogVC.##.<NUSPC8( )00( #+6552+*-07=BGG@3' 2EU^bcdfios{yujhfabegjkf`YNICCFED>6($!&2AQ]fjhe_baifaUF7/,-1243.(#    #   #%#"slx}pg`_eq %('"',,)!$('% %4BHGE=82(!,9=:4# %*1432-$(6FS^a`XO?912>GON>"Jitpe]Z[dfpu}ywolijinpjaP>/%&1?LU[Y\X[Z`enz~sh`ekqmj`WQKNKHHGIJOJE<5.,&$     ',*,-2;AF@5')7EKNHC?87;?ILT]hr}{qg\PH>9540/'  (++ {wyzzscVNKPUWQMC?:<5766:CDD;/  %E^ge[PJGILLRU\eqx|~  -5<A=>BGMPNKDB?B=;5.%#   %('!)589=92({|gdm3@DDCB?=7:<FNWXSH>1)'-5>FGFB:1%"-;Qcnsk_SHA<AINTWTSLIA=;;>A@DCDGAA<;AM[mthb`blwtcTD4,' sS>;Nj   /?DDD?93,% " }nic___dkssxutyyjq %29>@HQTWSH<427?GNTUTTTW^lv   .8=ACDGIICB76247;=@CC>@BBFIGC=72,-/9;=5&vleb^`[WM@/! paXVW]cb[M8  ;Qcdc_]XUKFADNYfprlgcffnsz~|xve]VTV]dmt} ")-867=CHOQSX_gnpwzy}xuroomnlljgbd`cefijklkge]WZ^gux{vi^TUPV\^dilgbSG0&&/320*((! i]SYfwvmorx}zukfb_eht|{vqjjju.:GPSW\ZYTQJKB;, #4>HLNORQQLMMMNLJB8*# !#" !%)1;ERWWVXSU]^clpv}}|vkcSKC@GMV_`]WRIKKQUV[VRHB<<DO\gkkcTE901;DKOJ>7168<7* &,&n[QMW`d`R?, %1:GR[aimvz$7FLKGGBA@CFOU`gklooqtz{xvzwyvofc^]^]`__aXSM@4'la^_fprtldZNIECADGMPSQTWTVW\_ddaZUQPY^nrupnorx}+267<AEFHE?;;AKXdgf`WSQZ`jqsurooqyyspkh`QJ>9::88.  |rkr  $-6=ADHIMKGA7539<<>6-%ri]et(&&!$+462"6GKD:2*/4?CGBEEFILOOTVVWYXUSQHJGFJGIJNPQZZcfe^[WZ`kt{xtqeaYWRQSYdiuruk`WOIDD>80'