Groupe de travail Réseau	B. Korver, Network Resonance	
Request for Comments : 4331	L. Dusseault, OSAF	
Catégorie : Sur la voie de la normalisation	février 2006	
Traduction Claude Brière de L'Isle		

Propriétés de quota et de taille pour les collections réparties d'auteurs et de versions (DAV)

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 (2004).

Résumé
Les serveurs de collections réparties d'auteurs et de versions sur la Toile (WebDAV, Web Distributed Authoring and Versioning) sont fréquemment déployés avec des limitations de taille (quota). Le présent document discute les propriétés et les comportements mineurs nécessaires pour que les clients inter-opèrent avec des mises en œuvre de quota (limitations de taille) sur les répertoires WebDAV
Table des matières
1. Introduction	1
1.1 Conventions de notation	1
1.2 Exigences pour les quotas	2
2. Vue d'ensemble de la solution	2
3. DAV:quota-available-bytes	2
4. DAV:quota-used-bytes	3
5. Exemple de demande et réponse PROPFIND	3
6. Rapport d'erreur	4
7. Notes	4
8. Considérations sur la sécurité	5
9. Considérations d'internationalisation	5
10. Remerciements	5
11. Références	6
11.1 Références normatives	6
11.2 Références pour information	6
Adresse des auteurs	6
Déclaration complète de droits de reproduction	6

 	1.	Introduction
 	1.1	Conventions de notation
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].

La définition de propriété vivante est fournie à la Section 3 de la [RFC2518]. La définition de propriété protégée et de propriété calculée est donnée au paragraphe 1.4 de la [RFC3253].

 	1.2	Exigences pour les quotas
Les serveurs WebDAV fondés sur la [RFC2518] ont été mis en œuvre et déployés avec des quotas de restrictions sur les collections et les utilisateurs, de sorte qu'il y a un sens à normaliser cette fonctionnalité pour améliorer le ressenti de l'utilisateur et l'interopérabilité des clients.

Les raisons pour lesquelles les serveurs WebDAV appliquent fréquemment des quotas sont les mêmes que celles qui font que tout système de mémorisation a des quotas :
o	Parfois le service de mémorisation a une tarification en fonction des quotas.
o	Parfois le service de mémorisation est gratuit, mais le fournisseur du service de mémorisation a un espace de mémorisation limité (par exemple, les comptes d'étudiants fournis par une université).
o	Même dans les cas où la mémorisation peut être mise à niveau, les gestionnaires de la mémorisation peuvent choisir des quotas de limite afin d'encourager les utilisateurs à limiter la taille des fichiers qu'ils mémorisent sur le système et à éliminer les fichiers obsolètes (par exemple, les départements de technologies de l'information dans les entreprises).

Afin de travailler au mieux avec les répertoires qui prennent en charge des quotas, le logiciel client devrait être capable de déterminer et afficher le "DAV:quota-available-bytes" (défini à la Section 3) sur les collections. De plus, le logiciel client devrait avoir un moyen de déterminer de façon très fiable combien d'espace de mémorisation est déjà consommé eu égard à ce quota.

La prise en charge des propriétés définies dans le présent document améliore le ressenti du client, parce que le client a une chance de gérer ses fichiers de façon à éviter d'épuiser l'espace de mémorisation alloué. Les clients peuvent n'être pas capables de calculer d'eux-mêmes la valeur précisément, selon la façon dont l'espace total utilisé est calculé par le serveur.

 	2.	Vue d'ensemble de la solution

L'approche pour satisfaire les exigences et scénarios mentionnés ci-dessus est de définir deux propriétés vivantes. La présente spécification peut être satisfaite sur un serveur en mettant en œuvre à la fois "DAV:quota-available-bytes" et "DAV:quota-used-bytes" sur les collections seulement.

Une demande PROPFIND  <DAV:allprop> NE DEVRAIT PAS retourner une des propriétés définies par le présent document. Cependant, ces noms de propriété DOIVENT être retournés dans une demande <DAV:propname> pour une ressource qui prend en charge les propriétés, sauf dans le cas de limites infinies, ce qui est expliqué ci-dessous.

Les définitions de DAV:quota-available-bytes et de DAV:quota-used-bytes ci-dessous empruntent beaucoup aux définitions de quota de la spécification du système de fichier réseau (NFS, Network File System) [RFC3530].

 	3.	DAV:quota-available-bytes

Nom : quota-available-bytes (octets de quota disponibles)

Espace de noms : DAV:

Objet : indique la quantité maximum de mémorisation supplémentaire disponible à allouer à une ressource.

DTD : <!ELEMENT quota-available-bytes (#PCDATA) >

La valeur de la propriété DAV:quota-available-bytes est la valeur en octets qui représente la quantité d'espace de disque supplémentaire au delà de l'allocation actuelle qui peut être allouée à cette ressource avant que d'autres allocations soient refusées. On comprend que cet espace peut être consommé par des allocations à d'autres ressources.

La prise en charge de cette propriété est EXIGÉE sur les collections, et FACULTATIVE sur les autres ressources. Un serveur DEVRAIT mettre en œuvre cette propriété pour chaque ressource qui a la propriété DAV:quota-used-bytes.

Les clients DEVRAIENT s'attendre à ce que lorsque le DAV:quota-available-bytes sur une ressource approche de 0, d'autres allocations à cette ressource puissent être refusées. Une valeur de 0 indique que les utilisateurs ne seront probablement pas capables d'effectuer des opérations qui écrivent des informations supplémentaires (par exemple, un PUT dans une collection) mais peuvent être capables de remplacer par un écrasement une ressource existante de taille égale.

Noter qu'il peut y avoir un certain nombre de limites distinctes mais qui se chevauchent, qui peuvent même inclure des limites de supports physiques. Quand il rapporte DAV:quota-available-bytes, le serveur a toute liberté de choisir une de ces limites mais DEVRAIT le faire d'une façon reproductible. La règle peut être configurée par répertoire, ou peut être de "choisir le plus petit nombre".

Si une ressource n'a pas de quota ou a une mémorisation sans limite ("limites infinies") le serveur PEUT choisir de ne pas retourner cette propriété (réponse 404 Non trouvé dans Multi-Status) bien que la présente spécification RECOMMANDE que les serveurs retournent une valeur appropriée (par exemple, la quantité d'espace disque libre). Un client ne peut pas entièrement supposer qu'il n'y a pas de quota appliqué sur une ressource qui n'a pas cette propriété, mais pourrait aussi bien agir comme si il n'y avait pas de quota.

La valeur de cette propriété est protégée (voir au paragraphe 1.4.2 de la [RFC3253] la définition des propriétés protégées). Une réponse 403 Interdit est RECOMMANDÉE pour les tentatives d'écriture sur une propriété protégée, et le serveur DEVRAIT inclure un corps d'erreur XML comme défini par DeltaV [RFC3253] avec l'étiquette de pré condition <DAV:cannot-modify-protected-property/> (on ne peut pas modifier une propriété protégée).

 	4.	DAV:quota-used-bytes

Nom : quota-used-bytes (quota d'octets utilisé)
Espace de noms : DAV:
Objet : contient la quantité de mémorisation par rapport au quota d'une ressource.
DTD : <!ELEMENT quota d'octets utilisés (#PCDATA) >

La valeur DAV:quota-used-bytes est la valeur en octets représentant la quantité d'espace utilisé par cette ressource et éventuellement un certain nombre d'autres ressources similaires, où l'ensemble de "similaires" satisfait au moins le critère que l'allocation d'espace à toute ressource dans l'ensemble va compter par rapport à DAV:quota-available-bytes. Elle DOIT inclure le compte total incluant l'usage déduit de sous ressources si c'est approprié. Elle DEVRAIT inclure la taille des métadonnées de mémorisation si la mémorisation de métadonnées est comptée par rapport à DAV:quota-available-bytes.

Noter qu'il peut y avoir un certain nombre d'ensembles distincts mais se chevauchant de ressources pour lesquelles un DAV:quota-used-bytes est maintenu (par exemple, "tous les fichiers d'un certain propriétaire", "tous les fichiers d'un certain groupe propriétaire", etc.). Le serveur a toute liberté de choisir un de ces ensembles mais DEVRAIT le faire d'une façon reproductible. La règle peut être configurée par répertoire.

La prise en charge de cette propriété est EXIGÉE sur les collections, et FACULTATIVE sur les autres ressources. Un serveur DEVRAIT mettre en œuvre cette propriété pour chaque ressource qui a la propriété DAV:quota-available-bytes.

La valeur de cette propriété est calculée (voir le paragraphe 1.4.3 de la [RFC3253] pour la définition de la propriété calculée). Une réponse 403 Interdit est RECOMMANDÉE pour les tentatives d'écrire une propriété protégée, et le serveur DEVRAIT inclure un corps d'erreur XML comme défini par DeltaV [RFC3253] avec l'étiquette de pré-condition <DAV: ne peut pas modifier une propriété protégée/>.

 	5.	Exemple de demande et réponse PROPFIND

Demande :

PROPFIND /~milele/public/ HTTP/1.1
Depth: 0
Host: www.example.com
Content-Type: text/xml
Content-Length: xxx

         <?xml version="1.0" ?>
         <D:propfind xmlns:D="DAV:">
           <D:prop>
             <D:quota-available-bytes/>
             <D:quota-used-bytes/>
           </D:prop>
         </D:propfind>

Réponse :

HTTP/1.1 207 Multi-Status
Date: Tue, 16 Oct 2001 22:13:39 GMT
Content-Length: xxx
Content-Type: text/xml; charset=UTF-8

         <?xml version="1.0" encoding="utf-8" ?>
         <D:multistatus xmlns:D="DAV:">
         <D:response>
           <D:href>http://www.example.com/~milele/public/</D:href>
           <D:propstat>
             <D:prop>
               <D:quota-available-bytes>596650</D:quota-available-bytes>
               <D:quota-used-bytes>403350</D:quota-used-bytes>
             </D:prop>
             <D:status>HTTP/1.1 200 OK</D:status>
           </D:propstat>
         </D:response>
         </D:multistatus>

 	6.	Rapport d'erreur

WebDAV [RFC2518] définit le code d'état 507 (Mémorisation insuffisante). Ce code d'état DEVRAIT être utilisé quand une demande de client (par exemple, PUT, PROPFIND, MKCOL, MOVE, ou COPY) échoue parce que elle excéderait son quota ou  les limites physiques de mémorisation. Afin de différencier la réponse des autres problèmes de mémorisation, le serveur DEVRAIT inclure un corps d'erreur XML comme défini par DeltaV [RFC3253] avec l'étiquette de pré-condition appropriée.

Pré-conditions :
(DAV:quota-not-exceeded) : la demande NE DOIT PAS causer le dépassement du quota alloué.
(DAV:sufficient-disk-space) : il y a un espace physique suffisant pour exécuter la demande.

Exemple de réponse d'erreur :

HTTP/1.1 507 Mémorisation insuffisante
Content-Length: xxx
Content-Type: text/xml

      <?xml version="1.0">
      <error xmlns="DAV:">
        <quota-not-exceeded/>
      </error>

Note de mise en œuvre : certains clients peuvent être capables de tirer parti des différents codes de précondition lors de la transposition en codes d'état du système d'exploitation, comme E_NOSPC et E_DQUOT dans NFS (voir la [RFC3530], Section 12).

 	7.	Notes

Les mises en œuvre de serveur mémorisent et comptabilisent leurs données de nombreuses façons différentes. En voici quelques une :
o	Certaines mises en œuvre de serveur interdisent de compter la mémorisation utilisée pour les métadonnées ; d'autres peuvent choisir de le faire pour une meilleure comptabilité.
o	D'anciennes versions des ressources peuvent être aussi mémorisées.
o 	Des variantes d'une ressource peuvent exister avec des longueurs de compte différentes.
o	Le contenu peut être généré de façon dynamique.
o	Les corps de ressource peuvent être compressés.
o	Certaines ressources peuvent être mémorisées "gratuitement", ne comptant pas par rapport au quota.

Comme la comptabilité de la mémorisation au serveur peut autant varier, les clients devraient s'attendre à ce que :
o 	La taille d'un fichier dans le système de fichiers d'un client, ou dans un message PUT, puisse ne pas correspondre à la quantité de mémorisation requise par le serveur pour mémoriser la ressource. Donc, le client ne peut pas prédire avec une précision de 100 % si un certain fichier va être permis par le quota de mémorisation.

o	Supprimer ou écraser une ressource peut ne pas libérer la même quantité de mémorisation qu'indiqué par la propriété DAV:getcontentlength définie dans la [RFC2518] pour la ressource. Si la suppression d'une ressource ne libère aucun espace, le fichier peut avoir été déplacé dans un dossier "poubelle" ou "boîte de recyclage", ou conservé comme dans les systèmes de "versionnage" ([RFC3253]).

o	Comme il y a de nombreux facteurs qui affectent la mémorisation utilisée par un ensemble de ressources, incluant la compression automatique, la taille des métadonnées associées, et le contenu inséré par le serveur (comme celui créé par le code PHP) dans la représentation de ressources sur le réseau, il est conseillé aux clients de ne pas dépendre de ce que la valeur de DAV: quota-used-bytes est la somme des propriétés DAV:getcontentlength pour les ressources contenues par une collection.

o	De plus, parce qu'il peut y avoir un certain nombre d'ensembles de ressources distincts mais se chevauchant pour lesquels un DAV:quota-used-bytes est maintenu (Section 4) il peut n'y avoir pas de corrélation entre la taille des ressources dans une collection et DAV:quota-used-bytes. Par exemple, pour un serveur qui met en œuvre des quotas par utilisateur, DAV:quota-used-bytes va généralement être le même pour une collection et ses membres.

o	Sur certains systèmes où le quota est compté par collection et non par utilisateur, un quota sur une sous collection peut être plus grand que le quota sur la collection parente qui la contient. Par exemple, le quota sur /~milele/ peut être de 100  M octets, mais le quota sur /~milele/public/ peut être illimité. Cela permet que l'espace utilisé par /~milele/public/ soit aussi grand que le permet le quota sur /~milele/ (selon les autres contenus de /~milele/) même si le quota sur /~milele/ est changé. Donc, même quand le quota sur une collection parente est changé, il n'est pas nécessairement exigé de changer le quota sur chaque collection fille ou descendante.

 	8.	Considérations sur la sécurité

Un pirate peut préférer mémoriser les fichiers dans des collections avec de grands quotas. Cela ne pose pas un strict problème de sécurité parce que cela ne rend pas plus facile de mémoriser des fichiers. Par ailleurs, la propriété DAV:quota-used-bytes peut rendre plus facile de détecter les altérations ou les mauvaises utilisations

 	9.	Considérations d'internationalisation

Le quota est compté en chiffres arabes exprimés dans des chaînes. Il n'y a pas de considérations d'internationalisation.

 	10.	Remerciements

Stefan Eissing, Geoff Clemm, Jim Luther, Julian Reschke, et Jim Whitehead, entre autres, ont fourni de précieux commentaires sur le présent document.

 	11.	Références
 	11.1	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)

[RFC2518]	Y. Goland, E. Whitehead, A. Faizi, S. Carter et D. Jensen, "Extensions HTTP pour la création répartie -- WEBDAV", février 1999. (Obsolète, voir la RFC 4918)

[RFC3253]	G. Clemm et autres, "Extensions de versions à WebDAV (Protocole de collecte ordonnée des auteurs et des versions distribuée sur la Toile)", mars 2002. (P.S.)

 	11.2	Références pour information

[RFC3530]	S. Shepler et autres, "Protocole de système de fichiers réseau (NFS) version 4", avril 2003. (Obsolète, voir RFC7530) (P.S.)

 	Adresse des auteurs

Brian Korver	Lisa Dusseault	
Network Resonance, Inc.	Open Source Applications Foundation	
2483 E. Bayshore Road	543 Howard Street	
Suite 212	5th Floor	
Palo Alto, CA  94303 US	San Francisco, CA  94105 US	
téléphone : +1 650 812-7705	téléphone : +1 415 946-3040	
mél : briank@networkresonance.com 	mél : lisa@osafoundation.org 	

 	Déclaration complète de droits de reproduction

Copyright (C) The IETF Trust (2006).

Le présent document est soumis aux droits, licences et restrictions contenus dans le BCP 78, et à www.rfc-editor.org, 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 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 pourrait ê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 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.

Remerciement 
Le financement de la fonction d’édition des RFC est fourni par l'activité de soutien administratif (IASA) de l'IETF.