RFC 3835: An Architecture for Open Pluggable Edge Services (OPES)
Date de publication du RFC : Août 2004
Auteur(s) du RFC : A. Barbir, R. Penno (Nortel Networks), R. Chen (AT&T Labs), M. Hofmann (Bell Labs/Lucent Technologies), H. Orman (Purple Streak Development)
Pour information
Première rédaction de cet article le 30 novembre 2005
Après le RFC 3752, qui décrit à quoi peut servir OPES, le cadre conceptuel des entités intermédiaires qui se mettent entre client et serveur pour modifier requêtes et/ou réponses, ce RFC décrit l'architecture d'OPES.
Notre RFC décrit donc le vocabulaire d'OPES (producteurs, consommateurs, flux, entités) et explique leur rôle. L'entité va, soit modifier un flux (en s'insérant entre producteur et consommateur), soit distribuer le travail à une autre entité OPES. Plusieurs entités OPES peuvent en effet transformer successivement le flot.
La communication avec ces "sous-traitants" se fera avec le futur OCP (OPES Callout Protocol), dont le cahier des charges est le RFC 3836 et qui est décrit dans le RFC 4037.
Le RFC décrit également les règles que suit un entité OPES et qu'il faut donc lui transmettre.
Comme OPES a suscité beaucoup de réserves, notamment de la part de l'IAB (dans le RFC 3238), notre RFC consacre toute sa section 4 à y répondre.
Tel qu'il est donc spécifié, le service OPES doit donc :
- Rendre obligatoire le consentement explicite du producteur ou du consommateur,
- Être accessible en IP, donc ne pas être totalement invisible,
- Révéler sa présence en marquant son intervention (par exemple, en HTTP, en ajoutant un en-tête),
- Permettre d'exprimer des préférences de protection des données, par exemple avec P3P.
- Et d'autres obligations.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)
