Protocole de mise en antémémoire Hypertexte (HTCP/0.0)

Statut de ce mémoire

Le présent mémoire définit un protocole expérimental pour la communauté de l'Internet. Il ne définie aucune norme de l'Internet. Les discussions et suggestions pour son amélioration sont les bienvenues. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

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

Résumé

Le présent document décrit HTCP, un protocole pour découvrir les antémémoires HTTP et les données en antémémoire, les ensembles de gestion des antémémoires HTTP, et la surveillance des activités des antémémoires. C'est un protocole expérimental, une proposition parmi plusieurs autres pour effectuer ces fonctions.

1.   Définitions, raisons et domaine d'application

1.1.   HTTP/1.1 (voir la [RFC2616]) permet le transfert d'objets de la Toile à partir de "serveurs d'origine," éventuellement via des "mandataires" (à qui il est permis dans certaines circonstances de "mettre en antémémoire" de tels objets pour une réutilisation ultérieure) chez des "clients" qui consomment les objets d'une certaine façon, habituellement en les affichant au titre d'une "page de la Toile". HTTP/1.0 et les version postérieures permettent d'inclure des "en-têtes" dans une demande et/ou une réponse, développant ainsi sur le comportement de HTTP/0.9 (et antérieures) de ne spécifier un URI que dans la demande et de n'offrir qu'un corps dans la réponse.

1.2.   ICP (voir la [RFC2186]) permets aux antémémoires d'être interrogées quant à leur contenu, habituellement par d'autres antémémoires qui espèrent éviter une coûteuse recherche sur un serveur d'origine distant. ICP a été conçu en pensant à HTTP/0.9, de sorte que seul l'URI (sans aucun en-tête) est utilisé lors de la description du contenu en antémémoire, et la possibilité de plusieurs corps compatibles pour le même URI n'avait pas encore été imaginée.

1.3   Le présent document spécifie un protocole de mise en antémémoire Hypertexte (HTCP, Hyper Text Caching Protocol) qui permet d'utiliser des en-têtes complets de demande et de réponse dans la gestion des antémémoires, et étend le domaine de la gestion des antémémoires pour inclure la surveillance à distance des ajouts et suppressions dans les antémémoires, la demande de suppressions immédiates, et l'envoi d'indications sur les objets de la Toile, telles que les localisations par des tiers d'objets mettables en antémémoire ou la mesure de l'inaccessibilité ou de l'indisponibilité des objets de la Toile.

2.   Protocole HTCP

2.1.   Tous les éléments de protocole HTCP multi octets sont transmis dans l'ordre des octets du réseau. Tous les champs Réservé devraient être réglés à zéro binaire par les envoyeurs et laissés sans examen par les receveurs. Les en-têtes doivent être présentés avec la terminaison de ligne par un CRLF, comme dans HTTP.

2.2.   Tous les noms d'hôte spécifiés devraient être compatibles entre envoyeur et receveur, de telle sorte que si un schéma de dénomination privatif (tels que HOSTS.TXT ou NIS) est utilisé, les noms dépendant de tels schémas ne seront envoyés qu'aux voisins HTCP qui sont connus pour participer aux dits schémas. Les adresses brutes (à quatre chiffres séparés par des points pour IPv4, ou en format séparé par deux points pour IPv6) sont universelles, comme le sont les noms du DNS public. L'utilisation de noms ou d'adresses privés exigera un soin tout particulier dans le fonctionnement.

2.3.   Les messages HTCP peuvent être envoyés comme datagrammes UDP, ou sur des connexions TCP. UDP doit être accepté. Les agents HTCP ne doivent pas être isolés des défaillances et retards du réseau. Un agent HTCP devait être prêt à agir de façon utile lorsque aucune réponse n'est renvoyée, ou lorsque les réponses sont retardées ou déclassées ou endommagées. TCP est facultatif et il est prévu qu'il ne soit utilisé que pour le débogage du protocole. L'IANA a alloué l'accès 4827 comme numéro d'accès standard TCP et UDP pour HTCP.

2.4.   Un ensemble de variables de configuration concernant les caractéristiques de transport devrait être entretenu pour chaque agent qui est capable d'initialiser des transactions HTCP, peut-être avec un ensemble global par défaut par agent. Ces variables sont :

Nombre maximum de transactions non acquittées avant de déclarer une "défaillance".

Intervalle maximum sans réponse à une transaction avant de déclarer une "défaillance".

Intervalle minimum avant d'essayer une nouvelle transaction après une défaillance.

2.5.   Un message HTCP a le format général suivant :

+---------------------+

|      En-tête        | donne la longueur du message et la version du protocole

+---------------------+

|      Données        | le message HTCP (varie selon le numéro de version majeur)

+---------------------+

|   Authentification  | authentification facultative pour la transaction

+---------------------+

2.6.   Un en-tête HTCP/*.* a le format suivant :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                               Longueur                        |

   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +

2: |                               Longueur                        |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

2: |             Majeur            |              Mineur           |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Longueur est la longueur du message, y compris tous les octets d'en-tête et de données, y compris le champ Longueur lui-même. Ce champ sera égal à la taille de la charge utile du datagramme ("longueur d'enregistrement") si un protocole de datagrammes est utilisé, et peut inclure du bourrage, c'est-à-dire que tous les octets du message ne sont pas nécessairement utilisés dans les sections Données et Authentification.

Majeur est le numéro de version majeure (0 pour la présente spécification). La section Données d'un message HTCP n'a pas besoin d'être rétrocompatible avec les différents numéros de version majeure.

Mineur est le numéro de version mineure (0 pour la présente spécification). Les niveaux des caractéristiques et les règles d'interprétation peuvent varier selon ce champ, en particulier les champs marqués Réservé peuvent prendre une nouvelle (mais facultative) signification dans les numéros de version mineure successifs au sein du même numéro de version majeure.

2.6.1.   Il est prévu qu'un initiateur de HTCP connaisse le numéro de version d'un répondant HTCP prospectif, ou que l'initiateur puisse le vérifier en utilisant des valeurs décroissantes pour Mineur et Majeur (en commençant par la valeur la plus forte prise en charge localement) et va mettre en antémémoire locale le numéro de version vérifié du répondant.

2.6.2.   Les numéros Majeurs supérieurs sont à préférer, comme le sont les numéros Mineurs au sein d'un numéro Majeur particulier.

2.7.   Un champ Données HTCP/0.* a la structure suivante :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                             Longueur                          |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

2: |     Opcode    |    Réponse    |        Réservé        |F1 |RR |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

4: |                              Trans-ID                         |

   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +

6: |                              Trans-ID                         |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

8: |                                                               |

   /                             Op-données                        /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Longueur est le nombre d'octets du message qui sont réservés pour la section Données, y compris le champ Longueur lui-même. Ce nombre peut inclure du bourrage, c'est-à-dire que tous les octets réservés par Longueur ne sont pas obligatoirement utilisés dans Op-données.

Opcode est le code de fonctionnement d'une transaction HTCP. Une transaction HTCP peut consister en plusieurs messages HTCP, par exemple, une demande (envoyée par l'initiateur) ou une réponse (envoyée par le répondant).

Réponse est un code numérique qui indique le succès ou l'échec d'une transaction. Il devrait être réglé à zéro (0) par les demandeurs et ignoré par les répondeurs. Chaque opération a son propre ensemble de codes de réponse, qui sont décrits plus loin. Le message globale a un ensemble de codes de réponse qui sont les suivants :

Les codes de réponse ci-dessus indiquent tous des erreurs et dépendent pour leur visibilité de MO=1 (comme spécifié ci-dessous).

RR est un fanion qui indique si ce message est une demande (0) ou une réponse (1).

F1 est surchargé de sorte qu'il est utilisé différemment par les demandeurs et les répondants. Si RR=0, F1 est défini comme RD. Si RR=1, F1 est alors défini comme MO.

RD est une fanion qui signifie lorsque il est mis à 1 qu'une réponse est désirée. Certains Opcodes exigent que RD soit à 1 pour qu'ils soient significatifs.

MO (em-oh) est un fanion qui indique si le code Réponse est à interpréter comme une réponse au message global (champs fixes dans Données ou tout autre champ de Authentification) [MO=1] ou comme une réponse aux champs dans Op-données [MO=0].

Trans-ID est une valeur de 32 bits qui lorsque elle est combinée avec l'adresse réseau de l'initiateur identifie de façon univoque cette transaction HTCP. Il faut veiller à ne pas réutiliser les Trans-ID au sein de la durée de vie d'un datagramme UDP.

Op-données dépend de l'Opcode et est défini ci-dessous, en fonction de l'opcode.

2.8.   Un champ Authentification HTCP/0.0 a la structure suivante :

                +0 (MSB)                            +1 (LSB)

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0:  |                             Longueur                          |

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

2:  |                        Heure-de-signature                     |

    +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +

4:  |                       Heure-de-signature                      |

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

6:  |                     Expiration-de-signature                   |

    +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +   +

8:  |                     Expiration-de-signature                   |

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

10: |                                                               |

    /                           Nom-de-clé                          /

    /                                                               /

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

n:  |                                                               |

    /                            Signature                          /

    /                                                               /

    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Longueur est le nombre d'octets utilisés par le champ Authentification, y compris par le champ Longueur lui-même. Si le champ facultatif Authentification n'est pas à transmettre, ce champ devrait être réglé à 2 (deux). Longueur peut inclure du bourrage, ce qui signifie que tous les octets réservés par le champ Longueur ne seront pas nécessairement consommés par le champ Signature.

Heure-de-signature est un compte binaire non signé (arithmétique) du nombre de secondes écoulées depuis le 1 er janvier 1970 à 00:00:00 UTC au moment où Signature est généré.

Expiration-de-signature est un compte binaire non signé (arithmétique) du nombre de secondes écoulées depuis le 1 er janvier 1970 à 00:00:00 UTC au moment où Signature est considéré comme arrivé à expiration.

Nom-de-clé est une COUNTSTR [3.1] qui spécifie le nom d'un secret partagé. (Chaque mise en œuvre de HTCP est supposée permettre la configuration de plusieurs secrets partagés, dont chacun porte un nom.)

Signature est une COUNTSTR [3.1] qui détient le résumé HMAC-MD5 (voir la [RFC 2104]) avec une valeur binaire de 64, des éléments suivants, dont chacun est résumé dans son format de transmission sur le réseau, incluant le bourrage transmis s'il en est qui est couvert par la longueur associée à un champ :

2.8.1.   Les secrets partagés devraient être générés par chiffrement aléatoire et devraient être au moins de quelques centaines d'octets.

3.   Types de données

Les types de données HTCP/0.* sont définis comme suit :

3.1   COUNTSTR est une chaîne comptée dont le format est :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                              Longueur                         |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

2: |                                                               |

   /                               Texte                           /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Longueur est le nombre d'octets qui vont suivre dans Texte. Ce champ n'est *pas* auto inclusif comme dans le cas des autres champs Longueur de HTCP.

Texte est un flux d'octets non interprétés, habituellement de caractères ISO8859-1.

3.2.   Spécificateur est utilisé avec les messages de demande TST et CLR, définis plus loin. Son format est :

Méthode (comme HTCP retourne seulement des en-têtes, les méthodes GET et HEAD sont équivalentes.)

URI (si l'URI est un URL, il devrait toujours inclure un spécificateur<accès> ":", mais en son absence, l'accès 80 devrait être imputé par le receveur.)

Version est une chaîne entière de version HTTP telle que " HTTP/1.1". Les chaînes Version avec des préfixes autres que "HTTP/" ou avec des numéros de version inférieurs à "1.1" sont en dehors du domaine de cette spécification.

En-tête-de-demande est l'ensemble des en-têtes présentés par un initiateur de HTTP. Ces en-têtes devraient inclure les en-têtes de bout en bout mais PAS les en-têtes bond par bond, et ils peuvent être mis en forme canonique (par exemple, l'agrégation de "Accept:" est permise.)

3.3.   Détail est utilisé avec le message de réponse TST, défini plus loin. Son format est :

3.4.   Identité est utilisé avec le message de demande MON et de réponse SET, définis plus loin. Son format est :

4.   En-tête d'antémémoire

Les en-têtes d'antémémoire HTCP/0.0 consistent en zéro, un ou plusieurs des en-têtes suivants :

Cache-Vary: <nom-d'en-tête> ...

L'envoyeur de cet en-tête a appris que le contenu varie sur un ensemble d'en-têtes différent de l'ensemble donné dans l'en-tête Vary: de l'objet. Cache-Vary:, s'il est présent, subroge l'en-tête Vary: de l'objet.

Cache-Location: <nom-d'hôte-d'antémémoire>:<accès> ...

L'envoyeur de cet en-tête a appris l'existence d'un ou de plusieurs mandataires d'antémémoire qui détiennent une copie de cet objet. La vérification de ces antémémoires avec HTCP peut résulter en la découverte de nouveaux voisins HTCP proches (de préférence à des voisins actuels).

Cache-Policy: [no-cache] [no-share] [no-cache-cookie]

L'envoyeur de cet en-tête a appris que la politique de mise en antémémoire de l'objet est plus détaillée que ce qui est donné dans ses en-têtes de réponse.

no-cache   signifie qu'il n'est pas mettable en antémémoire (aucune raison n'est donnée), mais qu'il est partageable entre des demandeurs simultanés.

no-share   signifie qu'il n'est pas partageable (aucune raison n'est donnée), et que le tunnelage par demandeur est toujours exigé).

no-cache-cookie   signifie que le contenu pourrait changer par suite de l'inclusion de différents mouchards, de leur absence ou même de leur présence aléatoire dans les en-têtes de demande, et que leur mise en antémémoire n'est pas conseillée.

Cache-Flags: [incomplet]

L'envoyeur de cet en-tête a modifié localement la politique de mise en antémémoire de l'objet, de telle sorte que les demandeurs peuvent avoir besoin de faire un traitement spécial pour cette réponse, c'est à dire, pas nécessairement conforme à la politique réelle de l'objet. Incomplet signifie que les en-têtes de réponse et/ou les en-têtes d'entité donnés dans cette réponse ne sont pas connus comme étant complets, et peuvent ne pas convenir pour être utilisés comme clé d'antémémoire.

Cache-Expiry: <date>

L'envoyeur de cet en-tête a appris que cet objet devrait être considéré comme étant arrivé à expiration à un moment différent de celui indiqué par ses en-têtes de réponse. Le format est le même que celui de Expires: de HTTP/1.1.

Cache-MD5: <contenu MD5 découvert>

L'envoyeur de cet en-tête a calculé une somme de contrôle MD5 pour cet objet qui est différente de celle donnée dans l'en-tête Content-MD5: de l'objet, ou qui est fournie parce que l'objet na pas d'en-tête Content-MD5:. Le format est le même que celui du Content- MD5: de HTTP/1.1.

Cache-to-Origin: <origine> <rtt> <échantillons> <bonds>

L'envoyeur de cet en-tête a mesuré le délai d'aller-retour avec un serveur d'origine (étant donné un nom d'hôte ou une adresse littérale). Le <rtt> est le nombre moyen de secondes, exprimé en ASCII décimal avec une précision arbitraire et sans exposant. <échantillons> est le nombre d'échantillons de RTT qui ont contribué au calcul de cette moyenne. <bonds> est le nombre de routeurs entre l'antémémoire et l'origine, exprimé en ASCII décimal avec une précision arbitraire et pas d'exposant, ou 0 si l'antémémoire ne sait pas.

6.   Fonctionnement de HTCP

Les opcodes de HTCP/0.* et leurs Op-données respectives sont définies ici :

6.1   NOP (opcode 0) :

C'est un "ping" de niveau HTCP. Le répondant est invité à traiter les NOP sans retard car le demandeur peut utiliser le délai d'aller-retour (RTT, round trip time) du NOP pour des besoins de configuration ou de transposition. Le code de réponse pour un NOP est toujours zéro (0). Il n'y a pas de Op-données pour un NOP. Les demandes NOP avec RD=0 ne causent aucun traitement du tout.

6.2   TST (opcode 1) :

Essai pour la présence d'une entité de contenu spécifié dans un mandataire d'antémémoire. Les demandes TST avec RD=0 ne causent aucun traitement.

Les demandes TST ont les Op-données suivantes :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                                                               |

   /                          Spécificateur                        /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Les codes de réponse pour TST sont les suivants :

0   l'entité est présent dans l'antémémoire de celui qui répond

1   l'entité n'est pas présente dans l'antémémoire de celui qui répond

Les réponses TST ont les Op-données suivantes, si la réponse est zéro (0) :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                                                               |

   /                            Détail                             /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Note : Les en-têtes de réponse retournés par un TST positif peuvent être un objet périmé. Les demandeurs devraient être prêts à traiter cette condition, soit en utilisant celui qui répond comme source de cet objet (ce qui pourrait amener celui qui répond à simplement le rafraîchir) ou en choisissant un répondant différent.

Les réponses TST ont les Op-données suivantes, si la réponse est un (1) :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                                                               |

   /                       En-tête-d'antémémoire                   /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

6.3   MON (opcode 2) :

Ce sont les activités de surveillance dans la mémoire d'objet locale d'un mandataire d'antémémoire (ajouts, suppressions, remplacements, etc.). Comme l'entrelacement des transactions HTCP sur une seule paire de points d'extrémité UDP n'est pas prise en charge, il est recommandé qu'un point d'extrémité UDP unique soit alloué par le demandeur pour chaque demande MON concurrente. Les demandes MON avec RD=0 sont équivalentes à celles avec RD=1 et TIME=0 ; c'est-à-dire qu'elle vont annuler toute transaction MON en instance.

Les demandes MON ont la structure de Op-données suivante :

               +0 (MSB)

   +---+---+---+---+---+---+---+---+

0: |              Heure            |

   +---+---+---+---+---+---+---+---+

Heure est le nombre de secondes de résultat de surveillance désiré par l'initiateur. Des demandes MON ultérieures provenant du même initiateur avec le même Trans-ID devraient mettre à jour l'heure sur une transaction MON sortante. C'est ce qu'on appelle un "renouvellement en chevauchement".

Les codes de réponse pour MON sont les suivants :

0   accepté, Op-données est présent et valide

1   refusé (erreur de quota-- trop de MON sont actives)

Les réponses MON ont la structure de Op-données suivante, si Réponse est zéro (0) :

               +0 (MSB)                            +1 (LSB)

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |            Heure              |     Action    |    Raison     |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

2: |                                                               |

   /                            Identité                           /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Heure est le nombre de secondes restantes pour cette transaction MON.

ACTION est un code numérique qui indique une action de remplissage d'antémémoire. Les codes sont :

0   une entité a été ajoutée à l'antémémoire

1   une entité de l'antémémoire a été rafraîchie

2   une entité de l'antémémoire a été remplacée

3   une entité a été supprimée dans l'antémémoire

Raison est un code numérique qui indique la raison d'une Action. Les codes sont :

0   certaine raison non couverte par les autres codes de Raison

1   un client mandataire est allé chercher cette entité

2   un client mandataire est allé la chercher alors que la mise en antémémoire n'est pas autorisée

3   le serveur mandataire préférait cette entité

4   l'entité est arrivée à expiration, selon ses en-têtes

5   l'entité a été purgée du fait de limites de stockage de l'antémémoire

6.4   SET (opcode 3) :

Informe une antémémoire de l'identité d'un objet. C'est une transaction "poussée", par laquelle les antémémoires coopérantes peuvent partager des informations telles que des en-têtes mis à jour de Age/Date/Expire (qui peuvent résulter d'une réponse d'origine HTTP "304 Non modifiée") ou des en-têtes d'antémémoire mis à jour (qui peuvent résulter de la découverte de conditions "vary" qui ne sont pas d'autorité ou de l'acquisition de localisations d'antémémoire autre ou tierce pour cette entité. RD est honoré.

Les demandes SET ont la structure de Op-données suivante :

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                                                               |

   /                           Identité                            /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Les codes de réponse sont les suivants :

0   identité acceptée, merci

1   identité ignorée, pas de raison donnée, merci

Les réponses SET n'ont pas de Op-données.

6.5   CLR (opcode 4) :

Dit à une antémémoire d'oublier complètement une entité. RD est honoré.

Les demandes CLR ont la structure de Op-données suivante :

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

0: |                  Réservé                      |    Raison     |

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

2: |                                                               |

   /                        Spécificateur                          /

   /                                                               /

   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Raison est un code numérique qui indique la raison pour laquelle le demandeur veut que cette entité soit retirée. Les codes sont les suivants :

0   quelque raison qui n'est pas mieux spécifiée par un autre code

1   le serveur d'origine me dit que cette entité n'existe pas

Les codes de réponse sont les suivants :

0   je l'avais, je ne l'ai plus

1   je l'ai, je le garde, aucune raison n'est donnée.

2   je ne l'ai jamais eu

Les réponses CLR n'ont pas de Op-données.

L'élimination d'un URI sans spécifier la réponse, l'entité, ou les en-têtes d'antémémoire signifie d'éliminer toutes les entités qui utilisent cet URI.

7.   Considérations pour la sécurité

Si l'élément facultatif Authentification n'est pas utilisé, il est possible que des tiers non autorisés voient et modifient une antémémoire en utilisant le protocole HTCP.

8.   Remerciements

Mattias Wingstedt de Idonex a fait des apports clés pour le développement de ce protocole. David Hankins a aidé à préciser ce document.

9   Références

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

[RFC2104]   H. Krawczyk, M. Bellare et R. Canetti, "HMAC : Hachage de clés pour l'authentification de message", février 1997.

[RFC2186]   D. Wessels, K. Claffy, "Protocole des antémémoires de l'Internet (ICP), version 2", septembre 1997. (Info.)

10   Adresse des auteurs

11.   Déclaration de copyright

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

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.

Remerciement

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