Profil de chaîne pour les noms d’interface Internet
de systèmes de petits ordinateurs (iSCSI)

Statut du présent mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l'Internet. Il appelle à la discussion et à des suggestions pour son amélioration. Prière de se référer à l'édition actuelle des "Normes officielles des protocoles de l'Internet" (STD 1) pour connaître l'état de normalisation et le statut de ce protocole. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de Copyright

Copyright (C) The Internet Society (2004). Tous droits réservés.

Résumé

Le présent document décrit comment préparer les noms iSCSI internationalisés pour augmenter la probabilité que l’entrée de nom et la comparaison fonctionnent d’une façon sensée pour les utilisateurs normaux dans le monde entier.

Le protocole d’interface Internet de systèmes de petit ordinateur (iSCSI) donne un moyen pour que les hôtes accèdent aux appareils SCSI sur un réseau IP. Les points d’extrémité iSCSI, appelés initiateurs et cibles, ont chacun un nom unique au monde qui doit être transcriptible, ainsi que facilement comparé.

1. Introduction

Le protocole iSCSI [RFC3720] donne aux hôtes un moyen pour accéder aux appareils SCSI [SAM2] sur un réseau IP. Les points d’extrémité iSCSI, appelés initiateurs et cibles, ont chacun un nom unique au monde, défini dans la [RFC3721].

Un nom iSCSI est une chaîne de caractères UTF-8 [RFC3629] qui comporte une désignation de type, une autorité de désignation fondée sur les noms de domaines, et une partie unique au sein de l’autorité de désignation. La partie unique peut être générée sur la base de tout ce que l’autorité de désignation estime utile, et peut inclure une entrée d’utilisateur.

Ces noms peuvent devoir être transcrits (envoyés entre deux administrateurs via un message électronique, la voix, le papier, etc.) de sorte qu’une comparaison insensible à la casse serait souhaitable. Cependant, ces noms doivent souvent être comparés par des mises en œuvre d’initiateur et de cible, dont la plupart sont faites dans un logiciel simple, incorporé. Cela rend une comparaison insensible à la casse très souhaitable pour ces mises en œuvre.

Cependant, une mise en œuvre complètement sensible à la casse aboutirait à ce que des identifiants tels que "exemple-nom" et "Exemple-Nom" soient différents, ce qui pourrait entraîner une confusion car ces noms sont transcrits.

Le but est alors de générer des noms iSCSI qui puissent être transcrits et entrés par les usagers, et aussi comparés octet par octet, avec une confusion minimale. Pour atteindre ces objectifs, les noms iSCSI sont généralisés en utilisant un jeu de caractères normalisé (converti en minuscules ou équivalent) sans espaces blanches admises, et une ponctuation très limitée.

Pour ceux qui n’utilisent que les caractères ASCII (U+0000 à U+007F) les caractères suivants sont admis :

- caractère tiré SCII ('-' = U+002d)

- caractère point SCII ('.' = U+002e)

- caractère deux-points SCII (':' = U+003a)

- caractères minuscules SCII ('a'..'z' = U+0061..U+007a)

- caractères SCII de chiffres ('0'..'9' = U+0030..U+0039)

De plus, toute entrée de caractère majuscule via une interface d’utilisateur DOIT être transposée en son équivalent minuscule.

Le présent document spécifie le jeu de caractères valide pour les noms iSCSI, ainsi que les règles pour normaliser et générer des noms iSCSI sur la base des entrées d’utilisateur ou autres informations qui contiennent des caractères internationaux.

En particulier, il définit ce qui suit, comme exigé par la [RFC3454] :

- L’applicabilité prévue du profil : noms iSCSI internationalisés.

- Le répertoire de caractères qui est l’entrée et la sortie de stringprep : Unicode 3.2, spécifié à la section 3.

- Les transpositions utilisées : spécifiées à la section 4.

- La normalisation Unicode utilisée : spécifiée à la section 5.

- Les caractères prohibés en sortie : spécifié à la section 6.

Ce profil DOIT être utilisé avec le protocole iSCSI.

2. Terminologie

Dans le présent document, les mots clés "PEUT", "DOIT, "NE DOIT PAS", "FACULTATIF", "RECOMMANDÉ", "DEVRA", "NE DEVRA PAS", "DEVRAIT", et "NE DEVRAIT PAS", sont à interpréter comme décrit dans la [RFC2119].

Dans le présent document, les exemples utilisent la notation pour les codets et noms provenant de la norme Unicode [Unicode3.2] et ISO/CEI 10646 [ISO10646]. Par exemple, la lettre "a" peut être représentée soit par "U+0061", soit par "LATIN SMALL LETTER A". Dans les listes de caractères prohibés, le "U+" est laissé de côté pour rendre la lecture des listes plus facile. Les commentaires sur les gammes de caractères sont données entre crochets (comme "[SYMBOLS]") et ne viennent pas des normes.

3. Répertoire de caractères

Le présent profil utilise Unicode 3.2, comme défini dans l’Appendice A de la [RFC3454].

4. Transposition

Le présent profil spécifie une transposition utilisant les tableaux suivants de la [RFC3454]. Les tableaux de transposition suivants DOIVENT être utilisés pour générer des noms iSCSI à partir de caractères Unicode.

Tableau B.1

Tableau B.2

5. Normalisation

La forme KC de normalisation Unicode DOIT être utilisée avec ce profil, comme décrit dans la [RFC3454].

6. Résultats prohibés

Le présent profil spécifie l’interdiction d’utiliser les tableaux suivants tirés de la [RFC3454]. les caractères qui apparaissent dans ces tableaux NE DOIVENT PAS être utilisés dans un nom iSCSI.

Tableau C.1.1

Tableau C.1.2

Tableau C.2.1

Tableau C.2.2

Tableau C.3

Tableau C.4

Tableau C.5

Tableau C.6

Tableau C.7

Tableau C.8

Tableau C.9

Note importante : Ce profil DOIT être utilisé avec le protocole iSCSI. Le protocole iSCSI a des règles de désignation supplémentaires qui sont en dehors de ce profil.

De plus, ce profil ajoute les interdictions suivantes. L’ensemble complet des caractères interdits est composé des caractères des tableaux ci-dessus plus de ceux énumérés individuellement ci-dessous.

6.1 Caractères inappropriés provenant de mécanismes d’entrée courants

u+3002 est utilisé comme si c’était u+002e dans de nombreux mécanismes d’entrée de nom de domaine utilisés par les applications, en particulier en Asie. Le caractère u+3002 NE DOIT PAS être utilisé dans un nom iSCSI.

3002 ; point idéographique

6.2 Caractères ASCII actuellement prohibés

Certains des caractères ASCII qui sont actuellement interdits dans les noms iSCSI par la [RFC3721] sont aussi utilisés dans des éléments de protocole tels que les URI. Des exemples sont donnés dans les [RFC2396] et [RFC2732]. Noter qu’il y a bien d’autres RFC qui définissent des schémas d’URI supplémentaires.

Les autres caractères dans la gamme de U+0000 à U+007F qui ne sont pas actuellement permis sont interdits dans les noms iSCSI pour les réserver pour utilisation future dans les éléments de protocole. Noter que le tiret (U+002D), le point (U+002E), et deux-points (U+003A) ne sont pas interdits.

Les caractères suivants NE DOIVENT PAS être utilisés dans les noms iSCSI :

0000-002C ; [de CARACTERES DE CONTROLE ASCII et ESPACE jusqu’à ,]

002F ; [ASCII /]

003B-0040 ; [ASCII ; jusqu’à @]

005B-0060 ; [ASCII [ jusqu’à `]

007B-007F ; [ASCII { jusqu’à DEL]

7. Caractères bidirectionnels

Ce profil spécifie de vérifier les chaînes bidirectionnelles comme décrit dans la [RFC3454] section 6.

8. Codets non alloués dans les noms de domaine internationalisés

Si le traitement dans la [RFC3720] spécifie qu’une liste de codets non alloués est utilisée, le système utilise le tableau A.1 de la [RFC3454] comme sa liste de codets non alloués.

9. Considérations pour la sécurité

La norme ISO/CEI 10646 comporte de nombreux caractères qui semblent similaires. Dans de nombreux cas, les utilisateurs des protocoles de sécurité doivent faire des correspondances visuelles, comme de comparer les noms des tiers de confiance. Le présent profil ne fait rien pour faire correspondre les caractères qui paraissent similaires.

Les noms iSCSI peuvent être utilisés par un initiateur pour vérifier qu’une cible qu’il a découverte est bien la bonne, et par une cible pour vérifier qu’un initiateur doit se voir accorder l’accès. Si ces noms sont interprétés et comparés différemment par différentes mises en œuvre iSCSI, un initiateur pourrait obtenir l’accès à une mauvaise cible, ou pourrait se voir refuser l’accès à une cible légitime.

10. Considérations relatives à l’IANA

Ceci est un profil de stringprep. Il a été enregistré dans le registre "Stringprep Profiles" de l’IANA. Ce processus est décrit dans la section Considérations relatives à l’IANA de la [RFC3454].

11. Résumé

Le présent document décrit un profil stringprep à utiliser avec les programmes qui génèrent les noms des initiateurs et cibles pour iSCSI.

12. Remerciements

Le présent document a été produit à la suite de discussions sur les formats de noms iSCSI avec Joe Czap, Jim Hafner, Howard Hall, Jack Harwood, John Hufferd, Marjorie Krueger, Lawrence Lamers, Todd Sperry, Joshua Tseng, et Kaladhar Voruganti, ainsi que de discussions sur la normalisation des noms dans les identifiants avec Paul Hoffman et Marc Blanchet.

Merci aussi à Bob Snively pour sa suggestion d’utiliser le processus nameprep pour la normalisation des noms iSCSI.

La plus grande partie de ce document a été copiée du profil stringprep pour les noms de domaines internationalisés [RFC3491], écrite par Paul Hoffman et Marc Blanchet.

13. Références

13.1 Références normatives

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC3454] P. Hoffman et M. Blanchet, "Préparation de chaînes internationalisées ("stringprep")", décembre 2002. (P.S.)

[RFC3720] J. Satran et autres, "Interface Internet des systèmes de petits ordinateurs (iSCSI)", avril 2004. (MàJ par RFC3980, RFC4850, RFC5048) (P.S.)

13.2 Références pour information

[RFC2396] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiants de ressource uniformes (URI) : Syntaxe générique", août 1998. (Obsolète, voir RFC3986)

[RFC2732] R. Hinden, B. Carpenter et L. Masinter, "Format pour les adresses littérales IPv6 dans les URL", décembre 1999.

[RFC3491] P. Hoffman et M. Blanchet, "Nameprep : Profil Stringprep pour les noms de domaine internationalisés (IDN)", mars 2003.

[RFC3629] F. Yergeau, "UTF-8, un format de transformation de la norme ISO 10646", STD 63, novembre 2003.

[RFC3721] M. Bakke et autres, "Interface Internet des systèmes de petits ordinateurs (iSCSI) : dénomination et découverte", avril 2004. (Information)

[SAM2] ANSI T10. "SCSI Architectural Model 2", mars 2000.

[Unicode3.2] The Unicode Standard, Version 3.2.0: The Unicode Consortium. La norme Unicode, version 3.2.0 est définie par le Unicode Standard, Version 3.0 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5) telle qu’amendée par le Unicode Standard Annex #27: Unicode 3.1 (http://www.unicode.org/unicode/reports/tr27/) et par le Unicode Standard Annex #28: Unicode 3.2 (http://www.unicode.org/unicode/reports/tr28/).

[ISO10646] ISO/CEI 10646-1:2000. Norme internationale – "Technologies de l’information – Jeu de caractères universel codé sur plusieurs octets (UCS) – Partie 1 : Architecture et plan de base multilingue".

14. Adresse de l’auteur

Mark Bakke

Cisco Systems, Inc.

6450 Wedgwood Road

Maple Grove, MN

USA 55311

Téléphone : +1 763-398-1000

mél : mbakke@cisco.com

15. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2004).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org , et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs droits.

Le présent document et les informations y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

Propriété intellectuelle

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr .

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf- ipr@ietf.org.

Remerciement

Le financement de la fonction d’édition des RFC est actuellement fourni par l’Internet Society.