Groupe de travail Réseau	T. Small, XpertSite.Com	
Request for Comments : 2739	D. Hennessy, ISOCOR	
Catégorie : Sur la voie de la normalisation	F. Dawson, Lotus	
Traduction Claude Brière de L'Isle	janvier 2000	

Attributs de calendrier pour vCard et LDAP

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

Résumé
Quand on programme une entité de calendrier, comme un événement, il y a un prérequis qu'un organisateur ait l'adresse du calendrier de chaque participant qui sera invité à l'événement. De plus, l'accès aux "heures occupées" actuelles d'un participant donne une indication a priori de si le participant sera libre pour participer à l'événement.

Afin de répondre à ces défis, un agent d'utilisateur de calendrier (CUA, Calendar User Agent) a besoin d'un mécanisme pour localiser (avec un URI) le calendrier d'un utilisateur individuel et ses heures libres/occupées.

Le présent mémoire définit trois mécanismes pour obtenir un URI du calendrier d'un utilisateur et ses heures libres/occupées. Cela inclut :
-	le transfert manuel des informations ; 
-	l'échange des données personnelles en utilisant le format vCard ; et 
-	la recherche dans un répertoire en utilisant le protocole LDAP
Table des matières
1. URI de calendrier et de programmation	1
1.1 URI Free/Busy (FBURL)	2
1.2 URI d'accès à un calendrier (CAPURI)	2
1.3 URI Calendar (CALURI)	2
1.4 URI par défaut	2
2. Distribution	3
2.1 Transfert manuel	3
2.2 Échange de données personnelles en utilisant une vCard	3
2.3 Extensions de schéma vCard	3
2.4 Recherche dans un répertoire en utilisant le protocole LDAP v3	5
3. Considérations relatives à l'IANA	7
4. Considérations sur la sécurité	7
5. Remerciements	8
6. Adresse des auteurs	8
7. Bibliographie	9
8. Déclaration complète de droits de reproduction	9

 	1.	URI de calendrier et de programmation

Le présent mémoire définit quatre classes d'URI. Les URI sont des plus utiles si on comprend sur quoi ils pointent. Voici une brève description :

 	1.1	URI Free/Busy (FBURL)
L'URI free/busy (libre/occupé) est défini comme une localisation indépendante du transport où un client peut obtenir des informations sur les heures d'occupations d'un utilisateur. À l'heure actuelle, cet URI pointe seulement sur les données d'heures occupées. De futures révisions de la présente spécification pourraient fournir des capacités étendues de publication des données d'heures libres.

Si un client de calendrier et de programmation (c'est-à-dire, un CUA) devait restituer des données à partir de sa localisation en utilisant FTP ou HTTP, il recevrait un objet iCalendar [RFC2445] contenant un ou plusieurs composants de calendrier "VFREEBUSY". Si un transport MIME est utilisé, la réponse sera contenue dans une partie de corps MIME "text/calendar" comme spécifié dans iCalendar [RFC2445]. Par exemple :

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
METHOD:PUBLISH
BEGIN:VFREEBUSY
ATTENDEE:MAILTO:jane_doe@host1.com
DTSTART:19971013T050000Z
DTEND:19971124T050000Z
DTSTAMP:19970901T083000Z
FREEBUSY:19971015T133000Z/19971015T180000Z
FREEBUSY:19971015T190000Z/19971015T220000Z
FBURL:http://www.host.com/calendar/busy/jdoe.ifb
END:VFREEBUSY
END:VCALENDAR

La quantité de données d'heures occupées pointées par le FBURL va généralement être pré-déterminée ; par exemple un mois de données d'heures occupées. Comme ligne directrice, il est recommandé que les six semaines précédantes de temps occupé soient publiées à la localisation associée au FBURL. Si cet URI pointe sur une ressource de fichier, il est recommandé que l'extension de fichier soit "ifb" pour la distinguer d'un objet iCalendar arbitraire (par exemple, avec l'extension de fichier "ics").

 	1.2	URI d'accès à un calendrier (CAPURI)
L'URI d'accès à un calendrier (CAPURI, Calendar Access URI) est défini comme une localisation indépendante du protocole à partir duquel un client de calendrier et de programmation (c'est-à-dire, un CUA) peut communiquer avec le calendrier entier d'un utilisateur.

La sémantique de l'utilisation de cet URI comme localisateur de protocole d'accès doit encore être définie par le groupe de travail CALSCH de l'IETF. Cela sera traité dans la spécification "Protocole d'accès au calendrier" [RFC4324].

 	1.3	URI Calendar (CALURI)
L'URI de calendrier (CALURI, Calendar URI) est défini comme une localisation indépendante du protocole à partir duquel un client de calendrier et de programmation (c'est-à-dire, un CUA) peut restituer une copie entière du calendrier d'un utilisateur. Restituer des données à partir de cet URI obtient une "photographie" publiée du calendrier de l'utilisateur.

URI HTTP – si l'URI est un URI HTTP, alors le contenu retourné avec une commande GET devrait être une partie de corps MIME "text/calendar" contenant un ou plusieurs objets iCalendar.

URI FTP – si l'URI est un URI FTP, alors la ressource pointée devrait être un fichier avec une extension "ics" contenant un ou plusieurs objets iCalendar.

 	1.4	URI par défaut
Dans de nombreux cas, un utilisateur peut avoir plus d'un calendrier. Dans ce cas, il peut avoir plusieurs URI, chacun pointant sur un calendrier de données libre/occupé.

Pour simplifier le cas de calendriers multiples pour les clients, on introduit le concept de calendrier par "défaut". Un calendrier "par défaut" est celui que l'utilisateur a désigné comme le calendrier que les autres utilisateurs devraient examiner quand ils accèdent au calendrier de l'utilisateur, ou qu'ils restituent les heures libres/occupées de l'utilisateur.

Le calendrier par défaut peut, en fait, inclure des informations prélevées sur tous les autres calendriers de l'utilisateur. Les autres calendriers peuvent n'exister que à des fins d'organisation.

 	2.	Distribution

Ces quatre URI fournissent des pointeurs précieux pour les données de calendrier et de programmation dont les autres utilisateurs ont besoin pour savoir quand programmer les réunions, etc. Il y a plusieurs possibilités pour la façon dont les utilisateurs peuvent communiquer ces URI aux autres utilisateurs. Les paragraphes qui suivent exposent comment ces URI peuvent être distribués aux autres utilisateurs.

 	2.1	Transfert manuel
La façon la plus simple d'obtenir ces URI est que l'utilisateur communique les URI en utilisant un mécanisme hors bande comme verbalement, ou dans un message électronique, ou en imprimant ces URI sur une carte de visite professionnelle.

Quand on utilise ce mécanisme, l'utilisateur obtient ces URI en utilisant un mécanisme hors bande et il entre manuellement ces URI dans son logiciel de calendrier.

 	2.2	Échange de données personnelles en utilisant une vCard
Une façon plus sophistiquée d'obtenir ces URI est que l'utilisateur publie des vCard contenant ces URI. L'objet vCard peut être transféré de l'un à l'autre. Comme beaucoup de clients de messagerie électronique permettent à un utilisateur d'inclure automatiquement une vCard dans chaque message qu'il envoie, cela donne un moyen simple et transparent de distribuer ses URI de calendrier et de programmation.

Du côté receveur, un client de messagerie électronique qui fournit une base de données intégrée de vCard peut fournir le moyen de chercher les URI de calendrier pour les utilisateurs dont les vCard sont mémorisées en local.

 	2.3	Extensions de schéma vCard
Comme la spécification de vCard [RFC2426] ne spécifie pas comment coder les URI de calendrier dans une vCard, ce paragraphe fournit une extension à vCard qui spécifie comment coder les URI de calendrier dans une vCard.

Dans un  objet vCard, quatre nouvelles propriétés sont définies : "CALURI", "CAPURI", "CALADRURI", et "FBURL", comme défini ci-dessus.

Toute vCard peut avoir une ou plusieurs de ces propriétés, représentant chacune un calendrier ou les heures libres/occupées qui sont associées à cet utilisateur.

Une de ces propriétés peut être désignée comme étant "par défaut" en ajoutant le paramètre "PREF".

Voici un exemple simple de vCard contenant un "FBURL" et un "CALURI".

BEGIN:VCARD
VERSION:3.0
N:Dun;Alec
FN:Alec Dun
ORG:Microsoft Corporation
ADR;WORK;POSTAL;PARCEL:;;One Microsoft Way;
Redmond;WA;98052-6399;USA
TEL;WORK;MSG:+1-206-936-4544
TEL;WORK;FAX:+1-206-936-7329
EMAIL;INTERNET:user@host1.com
CALADRURI;PREF:mailto:user@host1.com
CALURI;PREF:http://cal.host1.com/user/cal.ics
FBURL;PREF:http://cal.host1.com/user/fb.ifb
CALURI:http://cal.company.com/projectA/pjtA.ics
FBURL:http://cal.company.com/projectA/pjtAfb.ifb
END:VCARD

 	2.3.1	Enregistrement par l'IANA de la propriété FBURL
Pour : ietf-mime-directory@imc.org
Objet : Enregistrement du type FBURL pour le profil vCard de type MIME text/directory.
Nom de type : FBURL
Objet du type : spécifie l'URI pour les heures d'occupation d'un utilisateur dans un objet vCard.
Codage du type : 8bit
Valeur du type : une seule valeur d'URI.
Notes spéciales sur le type : lorsque plusieurs propriétes FBURL sont spécifiées, la propriété FBURL par défaut est indiquée avec le paramètre PREF. Le type FTP ou HTTP d'URI pointe sur un objet iCalendar associé à une photographie des six dernières semaines des données de temps d'occupation de l'utilisateur. Si l'objet iCalendar est représenté par un fichier ou un document, son type de cfichier devrait être "ifb".
Utilisation prévue : voir au paragraphe 1.1.

Exemples de type :
FBURL;PREF:http://www.host1.com/busy/janedoe
FBURL:FTP://ftp.host.com/busy/project-a.ifb

 	2.3.2	Enregistrement par l'IANA de la propriété CALADRURI
Pour : ietf-mime-directory@imc.org
Objet : Enregistrement du type CALADRURI pour le profil vCard de type MIME text/directory.
Nom de type : CALADRURI
Objet du type : spécifier la localisation à laquelle une demande d'événement devrait être envoyée pour l'utilisateur.
Codage du type : 8bit
Valeur du type : une valeur d'un seul URI.
Notes spéciales sur le type : Lorsque plusieurs propriétés CALADRURI sont spécifiées, la propriété CALADRURI par défaut est indiquée avec le paramètre PREF.
Utilisation prévue : commune
Exemple de type : CALADRURI;PREF:mailto:janedoe@host.com

 	2.3.3	Enregistrement par l'IANA de la propriété CAPURI
Pour : ietf-mime-directory@imc.org
Objet : Enregistrement du type CAPURI pour le profil vCard de type MIME text/directory.
Nom de type : CAPURI
Objet du type : spécifier une localisation indépendante du protocole à partir de laquelle un client de calendrier et de programmation (c'est-à-dire, un CUA) peut communiquer avec le calendrier entier d'un utilisateur.
Codage du type : 8bit
Valeur du type : une seule valeur d'URI.
Notes spéciales sur le type : Lorsque plusieurs propriétés CAPURI sont spécifiées, la propriété CAPURI par défaut est indiquée avec le paramètre PREF.
Utilisation prévue : voir au paragraphe 1.2.

 	2.3.4	Enregistrement par l'IANA de la propriété CALURI
Pour : ietf-mime-directory@imc.org
Objet : Enregistrement du type CALURI pour le profil vCard de type MIME text/directory.
Nom de type : CALURI
Objet du type : spécifier l'URI pour un calendrier d'utilisateur dans un objet vCard.
Codage du type : 8bit
Type value type: une seule valeur d'URI.
Notes spéciales sur le type : Lorsque plusieurs propriétés CALURI sont spécifiées, la propriété CALURI par défaut est indiquée avec le paramètre PREF. La propriété devrait contenir un URI pointant sur un objet iCalendar associé à une photographie de la mémorisation de calendrier de l'utilisateur. Si l'objet iCalendar est représenté par un fichier ou un document, son type de fichier devrait être "ics".
Utilisation prévue : voir au paragraphe 1.3.

Exemples de type :
CALURI;PREF:http://cal.host1.com/calA
CALURI:ftp://ftp.host1.com/calA.ics

 	2.4	Recherche dans un répertoire en utilisant le protocole LDAP v3
Une autre façon d'obtenir ces URI est de les charcher dans un répertoire en utilisant le protocole LDAP [RFC2251].

Si les URI d'un utilisateur peuvent être trouvés en utilisant une recherche dans un répertoire (c'est-à-dire, la recherche d'une des extensions de schéma LDAP définées ci-dessous) ils devraient, en général, être considérés comme "plus à jour" que les URI dans les vCard qui sont mémorisées localement.

 	2.4.1	Extensions de schéma LDAP
Afin de coder les URI de calendrier dans le répertoire, on définit ce qui suit :
-	Une classe d'objet :
	- calEntry
-	Huit attributs :
	- calCalURI
	- calFBURL
	- calCAPURI
	- calCalAdrURI
	- calOtherCalURIs
	- calOtherFBURLs
	- calOtherCAPURIs
	- calOtherCalAdrURIs

L'attribut calCalURI contient l'URI pour une photographie du calendrier par défaut entier de l'utilisateur. L'attribut calFBURL contient l'URI pour les données de temps d'occupation par défaut de l'utilisateur. L'attribut calCAPURI contient un URI qui peut être utilisé pour communiquer avec le calendrier de l'utilisateur. L'attribut calCalAdrURI contient un URI qui pointe sur la localisation à laquelle les demandes d'événement devraient être envoyées pour cet utilisateur.

L'attribut calOtherCalURIs est une propriété multi valeurs contenant les URI à photographier des autres calendriers que l'utilisateur peut avoir. L'attribut calOtherFBURLs est une propriété multi valeurs contenant les URIs surles autres données de temps libre/occupé que l'utilisateur peut avoir. L'attribut calOtherCAPURIs est une propriété multi valeurs contenant les URI sur les autres calendriers que l'utilisateur peut avoir. L'attribut calOtherCalAdrURIs est une propriété multi valeurs contenant les URI sur les autres localisations sur lesquelles un utilisateur peut vouloir que les demandes d'événement soient envoyées.

Il n'y a pas d'ordre prédéterminé pour les valeurs dans l'une ou l'autre propriété multi valeurs.

 	2.4.2	Notation
La notation utilisée dans le présent mémoire est la même que celle utilisée dans la [RFC2252].

 	2.4.3	Définitions d'objet
 	2.4.3.1	calEntry
L'entrée de calendrier calEntry est une classe dérivée de "TOP" [RFC2252], qui contient les quatre attributs de calendrier.

(1.2.840.113556.1.5.87
  NAME 'calEntry'
  TOP
  AUXILIARY
  MAY (calCalURI calFBURL calOtherCalURIs calOtherFBURLs calCAPURI
  calOtherCAPURLs)
)

 	2.4.4	Définitions d'attribut
 	2.4.4.1	calCalURI
(1.2.840.113556.1.4.478
NAME 'calCalURI'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
USAGE userApplications
)

 	2.4.4.2	calFBURL
(1.2.840.113556.1.4.479
NAME 'calFBURL'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
USAGE userApplications
)

 	2.4.4.3	calCAPURI
(1.2.840.113556.1.4.480
NAME 'calCAPURI'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
USAGE userApplications
)

 	2.4.4.4	calCalAdrURI
(1.2.840.113556.1.4.481
NAME 'calCalAdrURI'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
USAGE userApplications
)

 	2.4.4.5	calOtherCalURIs
(1.2.840.113556.1.4.482
NAME 'calOtherCalURIs'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
MULTI-VALUE
USAGE userApplications
)

 	2.4.4.6	calOtherFBURLs
(1.2.840.113556.1.4.483
NAME 'calOtherFBURLs'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
MULTI-VALUE
USAGE userApplications
)

 	2.4.4.7	calOtherCAPURIs
(1.2.840.113556.1.4.484
NAME 'calOtherCAPURIs'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
MULTI-VALUE
USAGE userApplications
)

 	2.4.4.8	calOtherCalAdrURIs
(1.2.840.113556.1.4.485
NAME 'calOtherCalAdrURIs'
EQUALITY caseIgnoreMatch
SUBSTRING caseIgnoreMatch
SYNTAX 'IA5String'
MULTI-VALUE
USAGE userApplications
)

 	3.	Considérations relatives à l'IANA

Le présent mémoire définit les extensions enregistrées par l'IANA aux attributs définis dans LDAP [RFC2251] et vCard [RFC2426].

Les propositions d'enregistrement par l'IANA pour vCard sont à envoyer par courier électronique à l'agent d'enregistrement pour le type de contenu MIME "text/directory"type, <MAILTO: ietf-mime-directory@imc.org> en utilisant le format défini dans la [RFC2426].

 	4.	Considérations sur la sécurité

Les règles standard de sécurité et de prise en charge de vCard et de LDAP s'appliquent pour les extensions décrites dans le présent document, et il n'y a pas de problème de sécurité particulier pour ces extensions.

Prière de noter cependant que les serveurs LDAP peuvent permettre à des clients anonymes de rafraîchir des entrées qu'ils n'ont pas créées. Il est aussi permis aux serveurs de contrôler un accès de rafraîchissement à une entrée en exigeant des clients qu'ils se lient avant de produire une demande de rafraîchissement RefreshRequest. Cela va avoir des implications sur les performances et l'adaptabilité du serveur.

Prière de noter aussi cependant, que les objets vCard peuvent avoir été créés par une autre entité que celle représentée par la vCard. Les receveurs devraient s'assurer de la source qui a généré la vCard.

On devrait aussi être prudent lors de l'utilisation d'informations obtenues de serveurs de répertoire qui ont été fournies par un client, car elles peuvent être maintenant périmées. Dans de nombreux réseaux, par exemple, les adresses IP sont allouées automatiquement quand un hôte se connecte au réseau, et peuvent être réallouées si cet hôte se déconnecte ultérieurement. Une adresse IP obtenue du répertoire peut n'être plus allouée à l'hôte qui a placé l'adresse dans le répertoire. Ce problème n'est pas spécifique de LDAP ou des répertoires dynamiques.

 	5.	Remerciements

Les auteurs tiennent à reconnaître le travail de Alec Dun, qui a été l'auteur des premiers projets du présent mémoire. Ce document a reçu des apports des divers participants aux discussions du groupe de travail CALSCH de l'IETF.

 	6.	Adresse des auteurs

Les informations d'adresse suivantes sont fournies dans le format vCard v3.0 [RFC2426] de carte d'affaire électronique.

BEGIN:VCARD
VERSION:3.0
N:Small;Tony
FN:Tony Small
ORG:XpertSite.Com
ADR;TYPE=WORK,POSTAL,PARCEL:;;4700 42nd Ave. SW, Suite 440;
Seattle;WA;98116;USA
TEL;TYPE=WORK,MSG:+1-206-937-9972
TEL;TYPE=WORK,FAX:+1-206-936-7329
EMAIL;TYPE=INTERNET:tony@xpertsite.com
CALADRURI:MAILTO:tony@xpertsite.com
END:VCARD

BEGIN:VCARD
VERSION:3.0
N:Hennessy;Denis
FN:Denis Hennessy
ORG:ISOCOR
ADR;TYPE=WORK,POSTAL,PARCEL:;;42-47 Lower Mount St;
 Dublin 2;Ireland
TEL;TYPE=WORK,MSG:+353-1-676-0366
TEL;TYPE=WORK,FAX:+353-1-676-0856
EMAIL;TYPE=INTERNET:denis.hennessy@isocor.com
CALADRURI:MAILTO:denis.hennessy@isocor.com
END:VCARD

BEGIN:VCARD
VERSION:3.0
N:Dawson;Frank
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;
Raleigh;NC;27613-3502;USA
TEL;TYPE=WORK,PREF:+1-617-693-8728
TEL;TYPE=WORK,MSG:+1-919-676-9515
TEL;TYPE=FAX:+1-617-693-8728
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
CALADRURI;TYPE=PREF:MAILTO:Frank_Dawson@Lotus.com
CALADRURI:MAILTO:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:VCARD

Le présent mémoire résulte du travail du groupe de travail Calendaring and scheduling de l'équipe d'ingénierie de l'Internet. Le président de ce groupe de travail est :

BEGIN:VCARD
VERSION:3.0
N:Egen;Pat
FN:Pat Egen
ORG:Engan Consulting
ADR;TYPE=WORK:;;803 Creek Overlook;Chattanooga;TN;37415;USA
TEL;TYPE=WORK,VOICE:423.875.2652
TEL;TYPE=WORK,FAX:423.875.2017
EMAIL:pregen@egenconsulting.com
URL:http://www.egenconsulting.com
CALADRURI:MAILTO:pregen@egenconsulting.com
END:VCARD

 	7.	Bibliographie
[RFC2251]	M. Wahl, T. Howes et S. Kille, "Protocole léger d’accès à un répertoire (v3)", décembre 1997.

[RFC2252]	M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Protocole léger d’accès à un répertoire (v3) : Définitions de syntaxe d'attribut", décembre 1997. (Obsolète, voir RFC4510, RFC4517, RFC4523, RFC4512) (MàJ par RFC3377) (P.S.)

[RFC2426]	F. Dawson, T. Howes, "Profil de répertoire MIME vCard", septembre 1998.  (Obsolète, voir RFC6350) (P.S.)

[RFC2445]	F. Dawson et D. Stenerson, "Spécification centrale des objets de calendrier et de programmation de l'Internet (iCalendar)", novembre 1998. (P.S., Obsolète, voir RFC5545)

[RFC2447]	F. Dawson, S. Mansour, S. Silverberg, "Protocole d'interopérabilité iCalendar fondé sur le message (iMIP)", novembre  1998. (P.S., Obsolète, voir RFC6047)

[RFC4324]	D. Royer et autres, "Protocole d'accès au calendrier (CAP)", décembre 2005. (Expérimentale)

 	8.	Déclaration complète de droits de reproduction
Copyright (C) The Internet Society (2000). Tous droits réservés.

Le présent document et ses traductions peuvent être copiés et fournis aux tiers, et les travaux dérivés qui les commentent ou les expliquent ou aident à leur mise en œuvre peuvent être préparés, copiés, publiés et distribués, en tout ou partie, sans restriction d’aucune sorte, pourvu que la déclaration de droits de reproduction ci-dessus et le présent paragraphe soient inclus dans toutes copies et travaux dérivés. Cependant, le présent document lui-même ne peut être modifié d’aucune façon, en particulier en retirant la notice de droits de reproduction ou les références à la Internet Society ou aux autres organisations Internet, excepté autant qu’il est nécessaire pour les besoins du développement des normes Internet, auquel cas les procédures de droits de reproduction définies dans les procédures des normes Internet doivent être suivies, ou pour les besoins de la traduction dans d’autres langues que l’anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Internet Society ou ses successeurs ou ayant droits.

Le présent document et les informations contenues sont fournis 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 encloses ne viole aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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