Groupe de travail Réseau |
D. McWalter, Ed. |
Request for Comments : 5017 |
Data Connection Ltd |
Catégorie : En cours de normalisation |
septembre 2007 |
Traduction Claude Brière de L’Isle
Statut du présent mémoire
Le présent document spécifie un protocole de normalisation Internet pour la communauté Internet, et appelle à discussion et suggestions en vue de son amélioration. Prière de se rapporter à l’édition en cours des "Internet Official Protocol Standards" (normes officielles du protocole Internet) (STD 1) pour connaître l’état de la normalisation et le statut du présent protocole. La distribution du présent mémo n’est pas soumise à restrictions.
Résumé
Le présent module de MIB définit les conventions textuelles pour représenter les identifiants de ressource universels (URI, Uniform Resource Identifier) du STD 66. L’intention est que ces conventions textuelles soient importées et utilisées dans les modules de MIB qui devraient autrement définir leur propres représentations.
Le présent mémoire définit une portion de la base d’informations de gestion (MIB, Management Information Base) à utiliser avec les protocoles de gestion de réseau dans la communauté de l’Internet. Il définit des conventions textuelles pour représenter les URI du STD 66 [RFC3986], qui sont décrits plus avant par la [RFC3305].
Trois conventions textuelles sont définies : une de longueur non restreinte, et deux de longueurs restreintes différentes. La longueur qui est appropriée dépendra de compromis faits dans les modules de MIB particiliers. La raison de la dourniture de conventions textuelles standard de longueur restreinte est d’améliorer la compatibilité entre les modules de MIB qui exigent des URI de longueur restréinte.
Si un URI doit être utilisé comme un objet d’index, la CONVENTION TEXTUELLE 'Uri' DEVRAIT être mise en sous-type à une longueur appropriée pour l’identifiant d’objet (OID) dont il fait partie. La description de cette CONVENTION TEXTUELLE 'Uri' expose ce cas.
Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans la RFC 2119 [RFC2119].
Pour une vue détaillée des documents qui décrivent le cadre actuel de la gestion standard de l’Internet, prière de se reporter à la section 7 de la RFC 3410 [RFC3410].
On accède aux objets gérés via un registre d’informations virtuel, appelé base d’informations de gestion ou MIB. On accède généralement aux objets MIB au moyen du protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Les objets dans la MIB sont définis en utilisant les mécanismes définis dans la structure des informations de gestion (SMI, Structure of Management Information). Le présent mémoire spécifie un module de MIB conforme à SMIv2, qui est décrit dans le STD 58, RFC 2578 [RFC2578], le STD 58, RFC 2579 [RFC2579] et le STD 58, RFC 2580 [RFC2580].
URI-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2 |
FROM SNMPv2-SMI |
-- [RFC2578] |
TEXTUAL-CONVENTION |
FROM SNMPv2-TC; |
-- [RFC2579] |
uriTcMIB MODULE-IDENTITY
LAST-UPDATED "200709100000Z" -- 10 September 2007
ORGANIZATION "IETF Operations and Management (OPS) Area"
CONTACT-INFO "EMail: ops-area@ietf.org
Home page: http://www.ops.ietf.org/"
DESCRIPTION
"Le présent module de MIB définit des conventions textuelles pour représenter les URI, tels que définis par la RFC 3986 STD 66."
REVISION "200709100000Z" -- 10 September 2007
DESCRIPTION
"Révision initiale, publiée comme RFC 5017.
Copyright (C) The IETF Trust (2007). Cette version de ce module de MIB fait partie de la RFC 5017 ; voir dans la RFC elle-même les notices légales complètes."
::= { mib-2 164 }
Uri ::= CONVENTION-TEXTUELLE
DISPLAY-HINT "1a"
STATUT actuel
DESCRIPTION
"Un Identifiant de ressource uniforme (URI) tel que défini par la STD 66.
Les objets qui utilisent cette CONVENTION-TEXTUELLE DOIVENT être codés en US-ASCII, et DOIVENT être normalisés comme décrit par les paragraphes 6.2.1, 6.2.2.1, et 6.2.2.2 de la RFC 3986. Tous les codages en pourcentage non nécessaires sont retirés, et tous les caractères insensibles à la casse sont mis en minuscules à l’exception des chiffres hexadécimaux, qui sont normalisés en majuscules comme décrit au paragraphe 6.2.2.1.
L’objet de cette normalisation est d’aider à fournir des URI uniques. Note que cette normalisation n’est pas suffisante pour assurer l’inicité. Deux URI qui sont textuellement distincts après cette normalisation peuvent être encore équivalents.
Les objets qui utilisent cette CONVENTION-TEXTUELLE PEUVENT restreindre les schémas qu’ils permettent. Par exemple, les schéma 'data:' et 'urn:' pourraient n’être pas appropriés.
Un URI de longueur zéro n’est pas un URI valide. Ceci peut être utilisé pour exprimer 'URI absent' en cas de besoin, par exemple lorsque utilisé comme champ d’index.
Lorsque cette CONVENTION-TEXTUELLE est utilisée pour un champ d’index, elle DOIT être divisée en sous-types pour restreindre sa longueur. Il y a une limite absolue de 128 sous-identifiants pour un OID, et il n’est pas efficace d’avoir des OID dont la longueur approche cette limite."
REFERENCE "RFC 3986 STD 66 et RFC 3305"
SYNTAXE CHAINE D’OCTETS
Uri255 ::= CONVENTION-TEXTUELLE
DISPLAY-HINT "255a"
STATUT actuel
DESCRIPTION
"Un identifiant de ressource uniforme (URI) comme défini par le STD 66.
Les objets qui utilisent cette CONVENTION-TEXTUELLE DOIVENT être codés en US-ASCII, et DOIVENT être normalisés comme décrit pas les paragraphes 6.2.1, 6.2.2.1, et 6.2.2.2 de la RFC 3986. Tous les codages en pourcentage non nécessaires sont retirés, et tous les caractères insensibles à la casse sont mis en minuscules sauf les chiffres hexadécimaux, qui sont normalisés en majuscules comme décrit au paragraphe 6.2.2.1.
L’objet de cette normalisation est d’aider à fournir des URI uniques. Noter que cette normalisation n’est pas suffisante pour assurer l’unicité. Deux URIqui sont textuellement distincts après cette normalisation peuvent être encore équivalents.
Les objets qui utilisent cette CONVENTION-TEXTUELLE PEUVENT restreindre les schémas qu’ils ne permettent pas. Par exemple, les schémas 'data:' et 'urn:' pourraient n’être pas appropriés.
Un URi de longueur zéro n’est pas un URI valide. Cela peut être utilisé pour exprimer 'URI absent' en cas de besoin, par exemple lorsqu’utilisé comme un champ d’index.
Les URI du STD 66 ne sont pas limités en longueur. Les objets qui utilisent cette CONVENTION-TEXTUELLE imposent une longueur limité aux URI qu’ils peuvent représenter. Lorsqu’aucune restriction de longueur n’est exigée, les objets DEVRAIENT utiliser la CONVENTION-TEXTUELLE 'Uri' à la place. Les objets utilisés comme indices DEVRAIENT diviser la CONVENTION-TEXTUELLE 'Uri' en sous-types."
REFERENCE "RFC 3986 STD 66 et RFC 3305"
SYNTAXE CHAINE D’OCTETS (TAILLE (0 à 255))
Uri1024 ::= CONVENTION-TEXTUELLE
DISPLAY-HINT "1024a"
STATUT actuel
DESCRIPTION
"Un identifiant de ressopurce niforme (URI) comme défini par le STD 66.
Les objets qui utilisent cette CONVENTION-TEXTUELLE DOIVENT être codés en US-ASCII, et DOIVENT être normalisés comme décrit aux paragraphes 6.2.1, 6.2.2.1, et 6.2.2.2 de la RFC 3986. Tous les codages en pourcentage non nécessaires sont supprimés, et tous les caractères insensibles à la casse sont mis en minuscules excepté les chiffres hexadécimaux, qui sont normalisés en majuscules comme décrit au paragraphe 6.2.2.1.
L’objet de cette normalisation est d’aider à fournir des URI uniques. Noter que cette normalisation n’est pas suffisante pour fournir l’unicité. Deux URI qui sont textuellement distincts après cette normalisation peuvent être encore équivalents.
Les objets qui utilisent cette CONVENTION-TEXTUELLE PEUVENT restreindre les schémas qu’ils permettent. Par exemple, les schémas 'data:' et 'urn:' pourraient n’être pas appropriés.
Un URi de longueur zéro n’est pas un URI valide. Cela peut être utilisé pour exprimer 'URI absent' en cas de besoin, par exemple lorsque utilisé comme champ d’index.
Les URI du STD 66 sont de longueur illimitée. Les objets qui utilisent cette CONVENTION-TEXTUELLE imposent une limite de longueur aux URI qu’ils peuvent représenter. Lorsque aucune restriction de longueur n’est exigée, les objets DEVRAIENT utiliser à la place la CONVENTION-TEXTUELLE 'Uri'. Les objets utilisé comme indices DEVRAIENT diviser la CONVENTION-TEXTUELLE 'Uri' en sous-types."
REFERENCE "RFC 3986 STD 66 et RFC 3305"
SYNTAXE CHAINE D’OCTETS (TAILLE (0 à 1024))
FIN
Voir aussi les Considérations pour la sécurité du STD 66 [RFC3986].
Le présent module de MIB ne définit aucun objet de gestion. Il définit plutôt une convention textuelle qui peut être importée par d’autres modules de MIB et utilisée pour les définitions d’objet.
Des considérations significatives sur la sécurité ne peuvent être rédigées que dans les modules de MIB qui définissent des objets de gestion. Le présent document n’a donc pas d’impact sur la sécurité de l’Internet.
URI-TC-MIB a sa racine sous le sous-arbre mib-2. L’IANA a alloué { mib-2 164 } au module URI-TC-MIB spécifié dans le présent document.
Le présent module a été généré en éditant ensemble les contributions de Randy Presuhn, Dan Romascanu, Bill Fenner, Juergen Schoenwaelder, et d’autres.
[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d’exigence", BCP 14, RFC 2119, mars 1997.
[RFC2578] K. McCloghrie, éd., D. Perkins, éd., et J. Schoenwaelder, éd., "Structure des informations de gestion, version 2 (SMIv2)", STD 58, RFC 2578, avril 1999.
[RFC2579] K. McCloghrie, éd., D. Perkins, éd., et J. Schoenwaelder, éd., "Conventions textuelles pour SMIv2", STD 58, RFC 2579, avril 1999.
[RFC2580] K. McCloghrie, D. Perkins et J. Schoenwaelder, "Déclarations de conformité pour SMIv2", STD 58, RFC 2580, avril 1999.
[RFC3986] T. Berners-Lee, R. Fielding et L. Masinter, "Identifiant de ressource uniforme (URI) : Syntaxe générique", STD 66, RFC 3986, janvier 2005.
[RFC3305] M. Mealling et R. Denenberg, "Rapport du groupe d’intérêt conjoint W3C/IETF de planification d’URI : Identifients de ressource uniformes (URI), URL, et noms de ressource uniformes (URN) : Précisions et recommandations", RFC 3305, août 2002.
[RFC3410] J. Case, R. Mundy, D. Partain et B. Stewart, "Introduction et déclarations d’applicabilité pour le cadre de gestion standard de l’Internet", RFC 3410, décembre 2002.
Adresse de l’auteur
David McWalter (editor)
Data Connection Ltd
100 Church Street
Enfield EN2 6BQ
United Kingdom
mél : dmcw@dataconnection.com
Déclaration de copyright
Copyright (C) The IETF Trust (2007).
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.