Groupe de travail Réseau	E. Guttman, Sun Microsystems	
Request for Comments : 3059	février 2001	
Catégorie : En cours de normalisation	Traduction Claude Brière de L’Isle	

Extension de la liste des attributs 
pour le protocole de localisation de service

Statut de ce mémoire
Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" 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 (2001). Tous droits réservés.

Résumé
Le protocole de localisation de service, version 2  (SLPv2, Service Location Protocol, version 2) fournit un mécanisme pour qu’un service soit découvert par un seul échange de messages. Cet échange de messages n’inclut actuellement aucun des attributs du service. Le présent document spécifie une extension à SLPv2 qui permet à un agent d’utilisateur (UA, User Agent) de demander que les attributs d’un service soient inclus comme extension au message de réponse du service. Cela éliminera le besoin de multiples allers-retours de messages pour qu’un UA acquière toutes les informations sur le service.
Table des Matières
1. Introduction	1
1.1 Terminologie	2
1.2 Conventions de notation	2
2. Extension de la liste des attributs	2
3. Considérations relatives à l’IANA	3
4. Considérations d’internationalisation	3
5. Considérations pour la sécurité	3
6. Remerciements	3
Références	3
Adresse de l’auteur	3
Déclaration complète de droits de reproduction	4

1.	Introduction

Le protocole de localisation de service version 2 [RFC2608] fournit un mécanisme pour qu’un service soit découvert par un seul échange de messages. L’UA envoie un message Demande de service et le DA ou le SA (selon ce qui est approprié) envoie un message de réponse de service.

Il est clairement avantageux d’être capable d’obtenir en une seule fois toutes les informations de service. Le protocole de localisation de service sépare les messages qui obtiennent des classes différentes d’informations. Cette extension permet une optimisation de l’échange basique de messages, qui n’inclut pas actuellement les attributs de service dans les messages de réponse de service.

Le présent document spécifie une extension à SLPv2 qui permet à un UA de demander que les attributs d’un service soient inclus dans les messages de réponse de service. Cela va éliminer le besoin de plusieurs allers-retours de messages pour qu’un UA acquière toutes les informations de service.

Si le DA ou SA ne prend pas en charge l’extension Attrlist, il va simplement retourner une réponse de service (sans l’extension). La prise en charge de cette extension est FACULTATIVE. Les mises en œuvre existantes vont ignorer l’extension Attrlist car il lui a été alloué un numéro d’identifiant dans la gamme qui indique que le receveur DOIT ignorer l’extension si elle n’est pas reconnue. Voir la [RFC2608].

Si l’UA reçoit un message de réponse de service sans une extension Attrlist, il doit supposer que le SA ou DA ne prend pas en charge l’extension. Dans ce cas, l’UA doit envoyer une demande d’attribut pour chaque URL qu’il obtient dans le message de réponse de service afin d’obtenir les attributs pour ces services.

1.1	Terminologie

Agent d’utilisateur (UA, User Agent)
Processus qui fonctionne au nom de l’utilisateur pour établir le contact avec un service. L’UA restitue les informations de service provenant des agents de service ou des agents de répertoire.

Agent de service (SA, Service Agent)
Processus qui fonctionne au nom d’un ou plusieurs services pour annoncer les services.

Agent de répertoire (DA, Directory Agent)
Processus qui collecte les annonces de service. Il ne peut y avoir qu’un seul DA présent sur un hôte.

1.2	Conventions de notation

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 le BCP 14, [RFC2119].

2.	Extension de la liste des attributs

Le format de l’extension Liste d’attributs est le suivant :

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   ID d’extension  = 0x0002    |Décalage de prochaine extension|
  +---------------+---------------+---------------+---------------+
  |décalage, suite|  Longueur URL de service      | URL de service/
  +---------------+---------------+---------------+---------------+
  | Longueur de liste d’attributs |   Liste d’attributs           /
  +---------------+---------------+---------------+---------------+
  |nb de AttrAuth |(si présent) blocs d’authentif. d’attribut  .../
  +---------------+---------------+---------------+---------------+

L’identifiant d’extension est 0x0002.

La valeur du décalage de prochaine extension indique la position de la prochaine extension comme décalage à partir du début du message SLP. Si la valeur du décalage de prochaine extension est 0, il n’y a plus d’extensions dans le message.

Un UA envoie une extension Liste d’attributs avec une demande de service. La longueur de l’URL de service et la longueur de liste d’attribut sont réglées à 0 et les champs URL de service et Liste d’attribut sont omis dans ce cas. L’UA demande par là que le SA ou DA inclue une extension Liste d’attribut dans sa réponse de service en incluant une telle extension de liste d’attribut "vide" dans la demande de service.

Un SA ou DA qui prend en charge l’extension Liste d’attribut retourne une extension Liste d’attribut pour chaque entrée d’URL dans le message de réponse de service. L’ordre des extensions Liste d’attribut DEVRAIT être le même que celui des entrées d’URL dans la réponse de service.

L’URL de service [RFC2609] identifie l’entrée d’URL correspondante.

Le champ Liste d’attribut est la liste entière des attributs du service. Ces attributs doivent être dans le même langage que celui indiqué dans le message de demande de service.

Si le message de demande de service comporte une chaîne d’indices de paramètres de sécurité SLP (SPI, Security Parameter Index) l’extension Liste d’attributs DOIT inclure un bloc d’authentification. Si le SA ou DA ne prend pas charge ou est incapable de retourner un bloc d’authentification pour le SPI SLP inclus dans la demande de service, le SA ou DA NE DOIT PAS alors retourner une extension Liste d’attributs. Le format du ou des blocs d’authentification est exactement le même que celui qui serait inclus dans un message de réponse d’attribut ou d’enregistrement de service.

3.	Considérations relatives à l’IANA

L’IANA a alloué un numéro d’identifiant d’extension de 0x0002 pour l’extension Liste d’attributs.

4.	Considérations d’internationalisation

Le protocole de localisation de service, version 2, a des mécanismes pour permettre que des attributs soient transmis avec un étiquetage explicite de langage [RFC3066]. Les mêmes mécanismes sont utilisés pour cette extension du protocole.

5.	Considérations pour la sécurité

Le protocole de localisation de service, version 2, a des mécanismes pour permettre que des authentifiants soient retournés avec les listes d’attributs afin que les UA soient capables de vérifier une signature numérique sur les attributs qu’ils obtiennent. Ce même mécanisme est utilisé pour cette extension du protocole. L’extension Liste d’attributs utilisée en conjonction avec SLPv2 n’est pas moins sûre que SLPv2 sans l’extension.

6.	Remerciements

L’auteur a bénéficié de conversations préliminaires sur cette extension avec Charlie Perkins.

Références

[RFC2026]	S. Bradner, "Le processus de normalisation de l'Internet -- Révision 3", (BCP0009) octobre 1996. (MàJ par RFC3667, RFC3668, RFC3932, RFC3979, RFC3978, RFC5378, RFC6410)

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

[RFC2434]	T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[RFC2608]	E. Guttman et autres, "Protocole de localisation de service, version 2", juin 1999. (MàJ par RFC3224) (P.S.)

[RFC2609]	E. Guttman, C. Perkins, J. Kempf, "Schémas service: et gabarits de service", juin 1999. (P.S.)

[RFC3066]	H. Alvestrand, "Étiquettes pour l'identification des langues", BCP 47, janvier 2001. (Rendue obsolète par la RFC4646.)

Adresse de l’auteur

Erik Guttman
Sun Microsystems
Eichhoelzelstr. 7
74915 Waibstadt
Germany
téléphone :  +49 6227 356 202
mél :    Erik.Guttman@sun.com 

Déclaration complète de droits de reproduction

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

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

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