Groupe de travail Réseau	C. Daboo, Apple, Inc.
Request for Comments : 5464	février 2009
Catégorie : Sur la voie de la normalisation	Traduction Claude Brière de L'Isle

Extension IMAP METADATA

Statut du présent mémoire
Le présent document spécifie un protocole de l’Internet sur la voie de la 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.

Résumé
L'extension METADATA au protocole d'accès au message Internet (IMAP, Internet Message Access Protocol) permet aux clients et serveurs de conserver des "annotations" ou "métadonnées" sur les serveurs IMAP. Il est possible d'avoir des annotations sur la base de la boîte aux lettres ou du serveur dans son ensemble. Par exemple, cela permettrait des commentaires sur la raison du rattachement d'une boîte aux lettres particulière à cette boîte aux lettres, ou un "message du jour" contenant des informations sur l'état du serveur à mettre à la disposition de quiconque s'inscrit sur le serveur.
Table des matières
1. Introduction et vue d'ensemble	1
2. Conventions utilisées dans ce document	2
3. Modèle de données	2
3.1 Vue d'ensemble	2
3.2 Espace de noms des entrées	2
3.3 Privé ou partagé et contrôle d'accès	4
4. Changements au protocole IMAP	4
4.1 Considérations générales	4
4.2 Commande GETMETADATA	5
4.3 Commande SETMETADATA	6
4.4 Réponse METADATA	7
5. Syntaxe formelle	9
6. Considérations relatives à l’IANA	9
6.1 Gabarit d'enregistrement d'entrée et d'attribut	10
6.2 Enregistrements d'entrée de serveur	10
6.3 Enregistrements d'entrée de boîte aux lettres	10
7. Considérations sur la sécurité	11
8. Références normatives	11
Appendice A. Remerciements	11
Adresse de l'auteur	12
Déclaration complète de droits de reproduction	12

 	1.	Introduction et vue d'ensemble

Le but de l'extension METADATA est de fournir un moyen pour que les clients établissent et restituent des "annotations" ou "métadonnées" sur un serveur IMAP. Les annotations peuvent être associées à des boîtes aux lettres spécifiques ou au serveur comme un tout. Le serveur peut choisir de prendre en charge seulement les annotations de serveur ou les deux annotations de serveur et de boîte aux lettres.

Un serveur qui prend en charge les deux annotations de serveur et de boîte aux lettres indique la présence de cette extension en retournant "METADATA" comme une des capacités prises en charge dans la réponse à la commande CAPABILITY.

Un serveur qui prend en charge seulement les annotations de serveur indique la présence de cette extension en retournant "METADATA-SERVER" comme une des capacités prises en charge dans la réponse à la commande CAPABILITY.

Un serveur qui prend en charge les réponses de changement d'annotation non sollicitées DOIT prendre en charge l'extension "ENABLE" [RFC5161] pour permettre aux clients d'activer cette caractéristique.

L'extension METADATA ajoute deux nouvelles commandes et une nouvelle réponse non étiquetée au protocole IMAP de base.

Cette extension fait les changements suivants au protocole IMAP :
o	ajoute une nouvelle commande SETMETADATA
o	ajoute une nouvelle commande GETMETADATA
o	ajoute une nouvelle réponse METADATA non étiquetée
o	ajoute un nouveau code de réponse METADATA

Le reste de ce document décrit plus précisément le modèle de données et les changements du protocole.

 	2.	Conventions utilisées dans ce document

Dans les exemples, "C:" et "S:" indiquent les lignes envoyées respectivement par le client et le serveur.

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

Des espaces et des sauts à la ligne ont été ajoutés aux exemples dans ce document pour améliorer la lisibilité.

 	3.	Modèle de données
 	3.1	Vue d'ensemble
Les boîtes aux lettres, ou le serveur comme un tout, peuvent avoir zéro, une, ou plusieurs annotations associées. Une annotation contient une entrée nommée de façon univoque, qui a une valeur. Les annotations peuvent être ajoutées aux boî+tes aux lettres quand un nom de boîte aux lettres est fourni comme premier argument de la commande SETMETADATA, ou au serveur comme un tout quand la chaîne vide est fournie comme premier argument de la commande.

Par exemple, un commentaire général ajouté à une boîte aux lettres peut avoir un nom d'entrée de "/comment" et une valeur de "boîte aux lettres réellement utile".

Les changements de protocole à IMAP décrits ci-dessous permettent à un client d'accéder ou de changer les valeurs de toute entrée d'annotation, en supposant qu'il ait des droits d'accès suffisants pour le faire.

 	3.2	Espace de noms des entrées
Chaque annotation est une entrée qui a un nom hiérarchique, dont chaque composant du nom est séparé par une barre oblique ("/"). Un nom d'entrée NE DOIT PAS contenir deux caractères "/" consécutifs et NE DOIT PAS se terminer par un caractère "/".

La valeur d'une entrée est NIL (n'a pas de valeur) ou une chaîne ou données binaires de zéro, un ou plusieurs octets. Une chaîne PEUT contenir plusieurs lignes de texte. Les clients DOIVENT utiliser la séquence d'octets CRLF (0x0D 0x0A) pour représenter les fins de ligne dans une valeur de chaîne multi-lignes.

Les noms d'entrée NE DOIVENT PAS contenir de caractères astérisque ("*") ou pourcentage ("%") et NE DOIVENT PAS contenir de caractères non ASCII ou de caractères avec des valeurs d'octet dans la gamme 0x00 à 0x19. Les noms d'entrée invalides résultent en une réponse BAD dans toute commande IMAP dans laquelle ils sont utilisés.

Les noms d'entrée sont insensibles à la casse.

L'utilisation de caractères de contrôle ou de ponctuation dans les noms d'entrée est fortement déconseillée.

La présente spécification définit un ensemble initial de noms d'entrée disponibles pour être utilisés avec des annotations de boîte aux lettres et de serveur. De plus, un mécanisme d'extension est décrit pour permettre que des noms supplémentaires soient ajoutés pour l'extensibilité.

Le premier composant des noms d'entrée définit la portée de l'annotation. Actuellement, seuls les préfixes "/private" ou "/shared" sont définis. Ces préfixes sont utilisés pour indiquer si une annotation est mémorisée par utilisateur ("/private") et non visible aux autres utilisateurs, ou si une annotation est partagée entre des utilisateurs autorisés ("/shared") avec une seule valeur qui peut être lue et changée par les utilisateurs autorisés avec l'accès approprié (voir les détails au paragraphe  3.3).

Les noms d'entrée peuvent avoir un nombre quelconque de composants à partir de 2, sauf si il rentrent dans les espaces de noms de fabricants (c'est-à-dire, ont un préfixe /shared/vendor/<vendor-token> ou /private/vendor/<vendor-token> comme décrit ci-dessous) auquel cas ils doivent avoir au moins 4 composants.

 	3.2.1	Noms d'entrées
Les noms d'entrée DOIVENT être spécifiés dans des RFC sur la voie de la normalisation ou des RFC expérimentales approuvées par l'IESG, ou entrer dans l'espace de noms de fabricant. Voir au paragraphe 6.1 le gabarit d'enregistrement.

 	3.2.1.1	Entrées de serveur
Ces entrées sont établies ou restituées quand l'argument de nom de boîte aux lettres à la nouvelle commande SETMETADATA ou GETMETADATA est la chaîne vide.

/shared/comment : définit un commentaire ou note associé au serveur et partagé avec les utilisateurs autorisés du serveur.

/shared/admin : indique une méthode pour contacter l'administrateur du serveur. La valeur DOIT être un URI (par exemple, un URI mailto: ou tel:). Cette entrée est toujours en lecture seule -- les clients ne peuvent pas la changer. Elle est visible aux utilisateurs autorisés du système.

/shared/vendor/<vendor-token> : définit le niveau supérieur des entrées partagées associées au serveur, telles que créées par un produit particulier d'un fabricant. Cette entrée peut être utilisée par les fabricants pour fournir des annotations spécifiques du serveur ou du client. Le jeton de fabricant (vendor-token) DOIT être enregistré par l'IANA, en utilisant le registre de sous arborescence de fabricant du protocole d'accès à la configuration d'application (ACAP, Application Configuration Access Protocol) [RFC2244].

/private/vendor/<vendor-token> : définit le niveau supérieur des entrées privées associées au serveur, telles que créées par un produit particulier d'un fabricant. Cette entrée peut être utilisée par les fabricants pour fournir des annotations spécifiques du serveur ou du client. Le jeton de fabricant (vendor-token) DOIT être enregistré par l'IANA, en utilisant le registre de sous arborescence de fabricant du protocole d'accès à la configuration d'application (ACAP, Application Configuration Access Protocol) [RFC2244].

 	3.2.1.2	Entrées de boîte aux lettres
Ces entrées sont établies ou restituées quand l'argument de nom de boîte aux lettres à la nouvelle commande SETMETADATA ou GETMETADATA n'est pas la chaîne vide.

/shared/comment : définit un commentaire ou note partagé associé à une boîte aux lettres.

/private/comment : définit un commentaire ou note privé (par utilisateur) associé à une boîte aux lettres.

/shared/vendor/<vendor-token> : définit le niveau supérieur des entrées partagées associées à une boîte aux lettres spécifique, comme créée par un produit particulier d'un fabricant. Cette entrée peut être utilisée par les fabricants pour fournir des annotations spécifiques du client. Le jeton de fabricant (vendor-token) DOIT être enregistré par l'IANA, en utilisant le registre ACAP de sous arborescence de fabricant [RFC2244].

/private/vendor/<vendor-token> : définit le niveau supérieur des entrées privées associées à une boîte aux lettres spécifique, comme créée par un produit particulier d'un fabricant. Cette entrée peut être utilisée par les fabricants pour fournir des annotations spécifiques du client. Le jeton de fabricant DOIT être enregistré par l'IANA, en utilisant le registre ACAP de sous arborescence de fabricant [RFC2244].

 	3.3	Privé ou partagé et contrôle d'accès
En l'absence de l'extension de liste de contrôle d'accès (ACL, Access Control List) [RFC4314], les utilisateurs peuvent seulement établir et restituer des annotations privées ou partagées de boîte aux lettres sur une boîte aux lettres qui existe et  leur sont retournées via une commande LIST ou LSUB, et sur laquelle ils ont un accès en lecture ou écriture au contenu réel de message de la boîte aux lettres (comme déterminé par les codes de réponse READ-ONLY et READ-WRITE décrits au paragraphe 5.2 de la [RFC4314]).

Quand l'extension ACL [RFC4314] est présente, les utilisateurs peuvent seulement établir et restituer les annotations privées ou partagées de boîte aux lettres sur une boîte aux lettres sur laquelle ils ont le droit "l" et un des autres droits "r", "s", "w", "i", ou "p".

Si un client tente d'établir ou restituer des annotations sur des boîtes aux lettres qui ne satisfont pas les conditions ci-dessus, le serveur DOIT répondre par "NO".

Les utilisateurs peuvent toujours restituer des annotations privées ou partagées de serveur si elles existent. Les serveurs PEUVENT restreindre comme approprié la création d'annotations privées ou partagées de serveur. Quand c'est interdit, le serveur DOIT retourner une réponse "NO" quand la commande SETMETADATA est utilisée pour essayer de créer une annotation de serveur.

Si l'extension METADATA est présente, la prise en charge des annotations partagées est EXIGÉE, tandis que la prise en charge des annotations privées est FACULTATIVE. Cela reconnaît le fait que la prise en charge des annotations privées peut introduire significativement plus de complexité au serveur en termes de traçage de la propriété des annotations, de comment les quotas sont déterminés pour les utilisateurs sur la base de leurs propres annotations, etc.

 	4.	Changements au protocole IMAP
 	4.1	Considérations générales
La nouvelle commande SETMETADATA et la réponse METADATA ont chacune un argument de nom de boîte aux lettres. Une chaîne vide est utilisée pour le nom de boîte aux lettres pour signifier des annotations de serveur. Une chaîne non vide est utilisée pour signifier des annotations de boîte aux lettres attachées à la boîte aux lettres correspondante.

Les serveurs DEVRAIENT s'assurer que les annotations de boîte aux lettres sont automatiquement déplacées quand la boîte aux lettres à laquelle elles se réfèrent est renommée, c'est-à-dire, les annotations suivent la boîte aux lettres. Cela s'applique à un renommage de la INBOX, avec le comportement supplémentaire que les annotations sont copiées de la INBOX originale à la boîte aux lettres renommée, c'est-à-dire, les annotations de boîte aux lettres sont préservée sur la INBOX quand elle est renommée.

Les serveurs DEVRAIENT supprimer les annotations pour une boîte aux lettres quand la boîte aux lettres est supprimée, afin qu'une boîte aux lettres créée avec le même nom qu'une boîte aux lettres existant précédemment n'hérite pas des annotations de la vieille boîte aux lettres.

Les serveurs DEVRAIENT permettre des annotations sur tous les "types" de boîtes aux lettres, incluant celles qui rapportent \Noselect pour leur réponse LIST. Les serveurs peuvent implicitement supprimer les boîtes aux lettres \Noselect quand toutes  les boîtes aux lettres filles sont supprimées, et, à ce moment toutes les annotations associées à la boîte aux lettres \Noselect DEVRAIENT être supprimées.

Il est permis au serveur d'imposer des limitations sur la taille de toute annotation ou sur le nombre total des annotations pour une seule boîte aux lettres ou pour le serveur comme un tout. Cependant, le serveur DOIT accepter une taille de données d'annotation d'au moins 1024 octets, et un compte d'annotations par serveur ou boîte aux lettres d'au moins 10.

Certaines annotations peuvent être "en lecture seule" -- c'est-à-dire, elles sont établies pa	r le serveur et ne peuvent pas être changées par le client. Aussi, de telles annotations peuvent être "calculées" -- c'est-à-dire, leur valeur change sur la base de propriétés sous-jacentes de la boîte aux lettres ou du serveur. Par exemple, une annotation rapportant la taille totale de tous les messages dans la boîte aux lettres va changer lorsque des messages sont ajoutés ou supprimés. Ou, une annotation contenant un URL IMAP pour la boîte aux lettres va changer si la boîte aux lettres est renommée.

Les serveurs PEUVENT prendre en charge l'envoi de réponses non sollicitées à utiliser quand les annotations sont changées par un "tiers" (voir le paragraphe 4.4). Afin de le faire, les serveurs DOIVENT prendre en charge la commande ENABLE [RFC5161] et DOIVENT seulement envoyer des réponses non sollicitées si le client a utilisé l'extension à la commande ENABLE [RFC5161] avec la chaîne de capacité "METADATA" ou "METADATA-SERVER" plus tôt dans la session, selon laquelle de ces capacités est supportée par le serveur.

 	4.2	Commande GETMETADATA
Cette extension ajoute la commande GETMETADATA. Elle permet aux clients de restituer les annotations de serveur ou de boîte aux lettres.

Cette commande est seulement disponible à l'état authentifié ou choisi [RFC3501].

Arguments : nom de boîte aux lettres
                    options
                    spécificateur d'entrée

Réponses : réponse METADATA exigée

Résultat : OK - commande terminée
                NO - échec de commande : ne peut pas accéder aux annotations sur le serveur
                BAD - commande inconnue ou arguments invalides

Quand le nom de boîte aux lettres est la chaîne vide, cette commande restitue les annotations du serveur. Quand le nom de boîte aux lettres n'est pas vide, cette commande restitue les annotations sur la boîte aux lettres spécifiée.

Des options PEUVENT être incluses avec cette commande et sont définies ci-dessous.

Exemple :

C : a GETMETADATA "" /shared/comment
S : * METADATA "" (/shared/comment "commentaire partagé")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, le contenu de la valeur de l'entrée de serveur "/shared/comment" est demandé par le client et retourné par le serveur.

Exemple :

C : a GETMETADATA "INBOX" /private/comment
S : * METADATA "INBOX" (/private/comment "Mon propre commentaire")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, le contenu de la valeur de l'entrée de boîte aux lettres "/private/comment" pour la boîte aux lettres "INBOX" est demandé par le client et retourné par le serveur.

Des spécificateurs d'entrée peuvent être des listes de spécificateurs atomiques, afin que plusieurs annotations puissent être retournées dans une seule commande GETMETADATA.

Exemple :

C : a GETMETADATA "INBOX" (/shared/comment /private/comment)
S : * METADATA "INBOX" (/shared/comment "commentaire partagé" /private/comment "Mon propre commentaire")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, les valeurs des deux entrées de serveur "/shared/comment" et "/private/comment" sur la boîte aux lettres "INBOX" sont demandées par le client et retournées par le serveur.

 	4.2.1	Option de commande MAXSIZE GETMETADATA
Quand l'option MAXSIZE est spécifiée avec la commande GETMETADATA, elle restreint les valeurs d'entrées qui sont retournées par le serveur. Seules les valeurs d'entrées qui sont inférieures ou égales en taille d'octets à la limite spécifiée de MAXSIZE sont retournées. Si il y a des entrées dont la valeur est supérieure à la limite de MAXSIZE, le serveur DOIT inclure le code de réponse METADATA LONGENTRIES dans la réponse OK étiquetée pour la commande GETMETADATA. Le code de réponse METADATA LONGENTRIES retourne la taille de la plus grande valeur d'entrée demandée par le client qui excédait la limite MAXSIZE.

Exemple :

C : a GETMETADATA "INBOX" (MAXSIZE 1024) (/shared/comment /private/comment)
S : * METADATA "INBOX" (/private/comment "Mon propre commentaire")
S : a OK [METADATA LONGENTRIES 2199] GETMETADATA complete

Dans l'exemple ci-dessus, les valeurs des deux entrées de serveur "/shared/comment" et "/private/comment" sur la boîte aux lettres "INBOX" sont demandées par le client, qui veut restreindre la taille des valeurs retournées à 1024 octets. Dans ce cas, la valeur d'entrée "/shared/comment" est de 2199 octets et n'est pas retournée.

 	4.2.2	Option de commande DEPTH GETMETADATA
Quand l'option DEPTH est spécifiée avec la commande GETMETADATA, elle étend la liste des valeurs d'entrées retournées par le serveur. Pour chaque nom d'entrée spécifié dans la commande GETMETADATA, le serveur retourne la valeur du nom d'entrée spécifié (si il existe) plus toutes les entrées en-dessous du nom d'entrée jusqu'à la profondeur spécifiée (DEPTH). Trois valeurs sont permises pour DEPTH :

"0" : aucune entrée en dessous de l'entrée spécifiée n'est retournée.
"1" : seules les entrées immédiatement en dessous de l'entrée spécifiée sont retournées.
"infini" : toutes les entrées en dessous de l'entrée spécifiée sont retournées.

Donc, "depth 1" pour une entrée "/a" va correspondre à "/a" ainsi que ses entrées filles (par exemple, "/a/b") mais ne va pas correspondre pour les entrées "petites-filles" (par exemple, "/a/b/c").

Si l'option DEPTH n'est pas spécifiée, c'est la même chose que de spécifier "DEPTH 0".

Exemple :

C : a GETMETADATA "INBOX" (DEPTH 1) (/private/filters/values)
S : * METADATA "INBOX" (/private/filters/values/small "SMALLER 5000" /private/filters/values/boss "FROM \"boss@example.com\"")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, deux entrées en-dessous de l'entrée /private/filters/values existent sur la boîte aux lettres "INBOX": "/private/filters/values/small" et "/private/filters/values/boss".

 	4.3	Commande SETMETADATA
Cette extension ajoute la commande SETMETADATA. Cela permet aux clients d'établir des annotations.
Cette commande est seulement disponible dans l'état authentifié ou choisi [RFC3501].

Arguments : nom de boîte aux lettres
                    entrée
                    valeur
                    liste d'entrées, valeurs

Réponses : pas de réponse spécifique pour cette commande.

Résultat : OK - commande terminée
                NO - échec de commande : ne peut pas établir d'annotations, ou annotation trop grosse ou trop nombreuses.
                BAD - commande inconnue ou arguments invalides

Cette commande établit la liste spécifiée des entrées en ajoutant ou remplaçant les valeurs spécifiées fournies, sur les boîtes aux lettres spécifiées existantes ou sur le serveur (si l'argument de boîte aux lettres est la chaîne vide). Les clients peuvent utiliser NIL comme valeur des entrées qu'ils veulent supprimer. Le serveur NE DEVRAIT PAS retourner une réponse METADATA contenant les données d'annotation mises à jour. Les clients NE DOIVENT PAS supposer qu'une réponse METADATA va être envoyée, et DOIVENT supposer que si la commande réussit, alors l'annotation a été changée.

Si le serveur est incapable d'établir une annotation parce que la taille de sa valeur est trop grande, le serveur DOIT retourner une réponse NO étiquetée avec un code de réponse "[METADATA MAXSIZE NNN]" quand NNN est le compte maximum d'octets qu'il veut accepter.

Si le serveur est incapable d'établir une nouvelle annotation parce que le nombre maximum d'annotations permises a déjà été atteint, le serveur DOIT retourner une réponse NO étiquetée avec un code de réponse "[METADATA TOOMANY]".

Si le serveur est incapable d'établir une nouvelle annotation parce qu'il ne prend pas en charge les annotations privées sur une des boîtes aux lettres spécifiées, le serveur DOIT retourner une réponse NO étiquetée avec un code de réponse "[METADATA NOPRIVATE]".

Quand l'établissement d'une annotation échoue, résultant en une réponse NO étiquetée du serveur, alors le serveur NE DOIT PAS changer les valeurs pour les autres annotations spécifiées dans la commande SETMETADATA.

Exemple :

C : a SETMETADATA INBOX (/private/comment {33}
S : + prêt pour les données
           Mon nouveau commentaire sur
           deux lignes.
           )
S : a OK SETMETADATA complete

Dans l'exemple ci-dessus, l'entrée "/private/comment" pour la boîte aux lettres "INBOX" est créée (si elle n'est pas déjà présente) et la valeur est réglée à une chaîne multi-lignes.

Exemple :

C: a SETMETADATA INBOX (/private/comment NIL)
S: a OK SETMETADATA complete

Dans l'exemple ci-dessus, l'entrée "/private/comment" est supprimée de la boîte aux lettres "INBOX".

Plusieurs entrées peuvent être établies dans une seule commande SETMETADATA en faisant la liste des paires d'entrée-valeur dans la liste.

Exemple :

C : a SETMETADATA INBOX (/private/comment "Mon nouveau commentaire" /shared/comment "Celui-ci est pour toi !")
S : a OK SETMETADATA complete

Dans l'exemple ci-dessus, les entrées "/private/comment" et "/shared/ comment" pour la boîte aux lettres "INBOX" sont créées (si elles ne sont pas déjà présentes) et les valeurs réglées comme spécifié.

Exemple :

C : a SETMETADATA INBOX (/private/comment "Mon nouveau commentaire")
S : a NO [METADATA TOOMANY] SETMETADATA failed

Dans l'exemple ci-dessus, le serveur est incapable d'établir l'annotation demandée (nouvelle) car il a atteint la limite de nombre d'annotations qu'il peut prendre en charge sur la boîte aux lettres spécifiée.

 	4.4	Réponse METADATA
La réponse METADATA affiche les résultats d'une commande GETMETADATA, ou peut être retournée comme réponse non sollicitée à tout moment par le serveur en réponse à un changement dans une annotation de serveur ou boîte aux lettres.

Quand des réponses non sollicitées sont activées par la commande ENABLE [RFC5161] pour cette extension, les serveurs DOIVENT envoyer des réponses METADATA non sollicitées si les annotations de serveur ou boîte aux lettres sont changées par un tiers, permettant aux serveurs de tenir les clients à jour des changements.

Les réponses METADATA non sollicitées DOIVENT seulement contenir les noms d'entrée, pas les valeurs. Si le client veut mettre à jour des valeurs mises en antémémoire, il doit explicitement les restituer en utilisant une commande GETMETADATA.

La réponse METADATA peut contenir plusieurs entrées dans une seule réponse, mais le serveur est libre de retourner plusieurs réponses pour chaque entrée ou groupe d'entrées, si il le désire.

Cette réponse est seulement disponible dans l'état authentifié ou choisi [RFC3501].

 	4.4.1	Réponse METADATA avec valeurs
La réponse consiste en une liste de paires d'entrée-valeur.

Exemple :

C : a GETMETADATA "" /shared/comment
S : * METADATA "" (/shared/comment "Mon commentaire")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, une seule entrée avec sa valeur est retournée par le serveur.

Exemple :

C : a GETMETADATA "INBOX" /private/comment /shared/comment
S : * METADATA "INBOX" (/private/comment "Mon commentaire" /shared/comment "Il fait beau dehors !")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, deux entrées et leur valeur sont retournées par le serveur.

Exemple :

C : a GETMETADATA "INBOX" /private/comment /shared/comment
S : * METADATA "INBOX" (/private/comment "Mon commentaire")
S : * METADATA "INBOX" (/shared/comment "Il fait beau dehors !")
S : a OK GETMETADATA complete

Dans l'exemple ci-dessus, le serveur retourne deux réponses séparées pour chacune des deux entrées demandées.

 	4.4.2	Réponse METADATA non sollicitée sans valeur
La réponse consiste en une liste d'entrées, dont chacune a changé sur le serveur ou boîte aux lettres.

Exemple :

C : a NOOP
S : * METADATA "" /shared/comment
S : a OK NOOP complete

Dans l'exemple ci-dessus, le serveur indique que l'entrée de serveur "/shared/comment" a été changée.

Exemple :

C : a NOOP
S : * METADATA "INBOX" /shared/comment /private/comment
S : a OK NOOP complete

Dans l'exemple ci-dessus, le serveur indique un changement aux deux entrées de boîte aux lettres.

 	5.	Syntaxe formelle

La spécification de syntaxe suivante utilise la notation de forme Backus-Naur augmenté (ABNF) comme spécifiée dans la [RFC5234].

Les non terminaux référencés mais non définis ci-dessous sont comme défini dans la [RFC3501], avec les nouvelles définitions de la [RFC4466] qui subrogent celles de la [RFC3501].

Sauf notation contraire, tous les caractères alphabétiques sont insensibles à la casse. L'utilisation de caractères majuscules ou minuscules pour définir des chaînes de jetons est seulement pour faciliter la lecture. Les mises en œuvre DOIVENT accepter ces chaînes de façon insensible à la casse.

capability =/ "METADATA" / "METADATA-SERVER" 	; définit les capacités pour cette extension.

command-auth =/ setmetadata / getmetadata	; s'ajoute à la commande IMAP originale

entries = entry / "(" entry *(SP entry) ")"	; spécificateurs d'entrée

entry = astring	; chemin séparé par des barres obliques pour l'entrée ; NE DOIT PAS contenir "*" ou "%"

entry-value = entry SP value

entry-values = "(" entry-value *(SP entry-value) ")"

entry-list = entry *(SP entry)	; liste des entrées utilisées dans la réponse METADATA non sollicitée

getmetadata = "GETMETADATA" [SP getmetadata-options] SP boîte aux lettres SP entries
; une chaîne vide pour la boîte aux lettres implique une annotation de serveur.

getmetadata-options = "(" getmetadata-option *(SP getmetadata-option) ")"

getmetadata-option = tagged-ext-label [SP tagged-ext-val]
; tagged-ext-label et tagged-ext-val sont définies dans la [RFC4466].

maxsize-opt = "MAXSIZE" SP nombre	; utilisé comme une getmetadata-option

metadata-resp = "METADATA" SP boîte aux lettres SP (entry-values / entry-list)
; une chaîne vide pour la boîte aux lettres implique une annotation de serveur.

response-payload  =/ metadata-resp	; s'ajoute aux réponses de données originales IMAP

resp-text-code =/ "METADATA" SP "LONGENTRIES" SP nombre
; nouveaux codes de réponse pour GETMETADATA

resp-text-code =/ "METADATA" SP ("MAXSIZE" SP nombre / "TOOMANY" / "NOPRIVATE")
; nouveaux codes de réponse pour les échecs de SETMETADATA.

scope-opt =  "DEPTH" SP ("0" / "1" / "infini")	; utilisé comme une getmetadata-option

setmetadata = "SETMETADATA" SP boîte aux lettres SP entry-values
; une chaîne vide pour la boîte aux lettres implique une annotation de serveur.

value  = nstring / literal8

 	6.	Considérations relatives à l’IANA

Toutes les entrées DOIVENT avoir "/shared" ou "/private" comme préfixe. Les noms d'entrées DOIVENT être spécifiés dans une RFC sur la voie de la normalisation ou une RFC expérimentale approuvée par l'IESG, ou tomber dans l'espace de noms de fabricant (c'est-à-dire, utiliser /shared/vendor/<vendor-token> ou /private/vendor/<vendor-token> comme préfixe).

Chaque enregistrement d'entrée DOIT inclure un type de contenu qui est utilisé pour indiquer la nature de la valeur de l'annotation. Lorsque applicable, un paramètre jeu de caractères DOIT être inclus avec le type de contenu.

 	6.1	Gabarit d'enregistrement d'entrée et d'attribut
Pour : iana@iana.org
Objet : Enregistrement d'entrée IMAP METADATA
Type : ["Boîte aux lettres" ou "Serveur"]
Nom : [nom de l'entrée]
Description : [description de l'objet de l'entrée]
Type de contenu : [Type de Contenu MIME et jeu de caractères pour la valeur d'entrée]
Numéro de RFC : [pour les entrées publiées par des RFC]
Contact : [adresse de messagerie et/ou physique à contacter pour des informations supplémentaires]

 	6.2	Enregistrements d'entrée de serveur
Les gabarits suivants spécifient les enregistrements par l'IANA des entrées d'annotation spécifiées dans ce document.

 	6.2.1	/shared/comment
Pour : iana@iana.org
Objet : Enregistrement d'entrée IMAP METADATA
Type : Serveur
Nom : /shared/comment
Description : définit un commentaire ou note associé au serveur et partagé avec les utilisateurs autorisés du serveur.
Type de contenu : text/plain ; charset=utf-8
Numéro de RFC : RFC 5464
Contact : Extensions IMAP  mailto:ietf-imapext@imc.org

 	6.2.2	/shared/admin
Pour : iana@iana.org
Objet : Enregistrement d'entrée IMAP METADATA
Type : Serveur
Nom : /shared/admin
Description : indique une méthode pour contacter l'administrateur du serveur. La valeur DOIT être un URI (par exemple, un URL mailto: ou tel:). Cette entrée est toujours en lecture seule -- les clients ne peuvent pas la changer. Elle est visible aux utilisateurs autorisés du système.
Type de contenu : text/plain ; charset=utf-8
Numéro de RFC : RFC 5464
Contact : Extensions IMAP  mailto:ietf-imapext@imc.org

 	6.3	Enregistrements d'entrée de boîte aux lettres
Les gabarits suivants spécifient les enregistrements par l'IANA des entrées d'annotation spécifiées dans ce document.

 	6.3.1	/shared/comment
Pour : iana@iana.org
Objet : Enregistrement d'entrée IMAP METADATA
Type : Boîte aux lettres
Nom : /shared/comment
Description : définit un commentaire ou note partagé associé à une boîte aux lettres.
Type de contenu : text/plain ; charset=utf-8
Numéro de RFC : RFC 5464
Contact : Extensions IMAP  mailto:ietf-imapext@imc.org

 	6.3.2	/private/comment
Pour : iana@iana.org
Objet : Enregistrement d'entrée IMAP METADATA
Type : boîte aux lettres
Nom : /private/comment
Description : définit un commentaire ou note privé associé à une boîte aux lettres.
Type de contenu : text/plain ; charset=utf-8
Numéro de RFC : RFC 5464
Contact : Extensions IMAP  mailto:ietf-imapext@imc.org

 	7.	Considérations sur la sécurité

Les considérations sur la sécurité de la Section 11 de la [RFC3501] s'appliquent ici à l'égard de la protection des annotations contre l'espionnage. Les serveurs PEUVENT choisir de prendre seulement en charge les extensions METADATA et/ou METADATA-SERVER après la négociation d'une couche de confidentialité par le client.

Les annotations peuvent contenir des données arbitraires de taille variable. À ce titre, les serveurs DOIVENT s'assurer que des limites de taille sont appliquées pour empêcher un utilisateur d'utiliser tout l'espace disponible sur un serveur et d'empêcher son utilisation par les autres. Les clients DOIVENT traiter les valeurs de données d'annotation comme des source de données "non fiables" car il est possible qu'elles contiennent un contenu malveillant.

Les annotations dont les valeurs sont destinées à rester privées DOIVENT être mémorisées seulement dans les entrées qui ont le préfixe "/private" sur le nom d'entrée.

En dehors des problèmes ci-dessus, l'extension METADATA ne soulève pas de problème de sécurité qui ne soit déjà présent dans le protocole IMAP de base, et ces problèmes sont discutés dans la [RFC3501].

 	8.	Références normatives

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

[RFC2244]	C. Newman, J. G. Myers,"ACAP – Protocole d'accès à la configuration d'application", novembre 1997. (P.S.)

[RFC3501]	M. Crispin, "Protocole d'accès au message Internet - version 4rev1", mars 2003. (P.S. ; MàJ par RFC4466, 4469, 4551, 5032, 5182, 7817, 8314, 8437, 8474 ; remplacée par la 9051

[RFC4314]	A. Melnikov, "Extension IMAP4 de liste de contrôle d'accès (ACL)", décembre 2005. (Remplace RFC2086) (P.S.)

[RFC4466]	A. Melnikov, C. Daboo, "Récapitulation des extensions à l'ABNF pour IMAP4", avril 2006. (P.S.)

[RFC5161]	A. Gulbrandsen et A. Melnikov,"Extension ENABLE à IMAP", mars 2008. (P.S.)

[RFC5234]	D. Crocker, P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", janvier 2008. (STD0068)

 	Appendice A.	Remerciements

Les idées exprimées dans ce document se fondent sur le document d'annotation de message qui a été co-rédigé par Randall Gellens. L'auteur tient à remercier les personnes suivantes pour leurs contributions par leurs idées et leur soutien pour la rédaction de la présente spécification : Dave Cridland, Arnt Gulbrandsen, Dan Karp, Alexey Melnikov, Ken Murchison, Chris Newman, et Michael Wener.

 	Adresse de l'auteur

Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
USA

mél : cyrus@daboo.name
URI : http://www.apple.com/

 	Déclaration complète de droits de reproduction
Copyright (C) The IETF Trust (2009).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et sauf pour ce qui est mentionné ci-après, les auteurs conservent tous leurs 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, le IETF TRUST 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.

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 pourraient ê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 le 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.