RFC 4287

Network Working Group                                 M. Nottingham, Ed.
Document RFC : 4287 (errata)                               R. Sayre, Ed.
Catégorie    : Standards Track                             Décembre 2005

Le format d'agrégation Atom

Statut de ce mémoire

Ce document définit un protocole du circuit des standards Internet de la communauté Internet, et il appelle le débat et des suggestions d'amélioration. Veuillez consulter l'édition courante du document Internet Official Protocol Standards (STD 1) pour l'état de standardisation et le statut de ce protocole. La distribution de ce mémoire est libre.

Notice de droits d'auteur

Copyright © The Internet Society (2005).

Résumé

Ce document spécifie le format Atom d'agrégation de contenus et de métadonnées web fondé sur XML.

Table des matières

1. 1. Introduction
   1. 1.1. Exemples
   2. 1.2. Espace de noms et version
   3. 1.3. Conventions d'écriture
2. 2. Documents Atom
3. 3. Structures Atom communes
   1. 3.1. Structures de texte
      1. 3.1.1. L'attribut type
   2. 3.2. Structures de personne
      1. 3.2.1. L'élément atom:name
      2. 3.2.2. L'élément atom:uri
      3. 3.2.3. L'élément atom:email
   3. 3.3. Structures de date
4. 4. Définitions des éléments Atom
   1. 4.1. Éléments conteneurs
      1. 4.1.1. L'élément atom:feed
      2. 4.1.2. L'élément atom:entry
      3. 4.1.3. L'élément atom:content
   2. 4.2. Éléments de métadonnées
      1. 4.2.1. L'élément atom:author
      2. 4.2.2. L'élément atom:category
      3. 4.2.3. L'élément atom:contributor
      4. 4.2.4. L'élément atom:generator
      5. 4.2.5. L'élément atom:icon
      6. 4.2.6. L'élément atom:id
      7. 4.2.7. L'élément atom:link
      8. 4.2.8. L'élément atom:logo
      9. 4.2.9. L'élément atom:published
      10. 4.2.10. L'élément atom:rights
      11. 4.2.11. L'élément atom:source
      12. 4.2.12. L'élément atom:subtitle
      13. 4.2.13. L'élément atom:summary
      14. 4.2.14. L'élément atom:title
      15. 4.2.15. L'élément atom:updated
5. 5. Sécurisation des documents Atom
   1. 5.1. Signatures numériques
   2. 5.2. Chiffrement
   3. 5.3. Signature et chiffrement
6. 6. Extension d'Atom
   1. 6.1. Extensions à partir de vocabulaires non-Atom
   2. 6.2. Extensions du vocabulaire Atom
   3. 6.3. Traitement du balisage étranger
   4. 6.4. Éléments d'extension
      1. 6.4.1. Éléments d'extension simples
      2. 6.4.2. Éléments d'extension structurés
7. 7. Observations concernant l'IANA
   1. 7.1. Registre des relations de lien
8. 8. Observations sur la sécurité
   1. 8.1. Contenu HTML et XHTML
   2. 8.2. Adresses URI
   3. 8.3. Adresses IRI
   4. 8.4. Usurpation
   5. 8.5. Chiffrement et signature
9. 9. Références
   1. 9.1. Références normatives
   2. 9.2. Références informatives
10. Appendix A. Contributeurs
11. Appendix B. Schéma RELAX NG Compact

1. Introduction

Atom est un format de document fondé sur XML qui décrit des listes d'informations liées, connues sous le nom de « fils » (feeds). Les fils se composent d'un certain nombre d'articles, appelés des « entrées » (entries), chacune avec un ensemble extensible de métadonnées jointes. Par exemple, chaque entrée a un titre.

Le cas d'utilisation principal auquel Atom répond est l'agrégation (syndication) de contenus web tels que blogues et gros titres de l'actualité vers des sites web ou directement vers des agents utilisateurs.

1.1. Exemples

Voici un document de fil Atom (Atom feed document) court avec une seule entrée :

   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://www.w3.org/2005/Atom">

     <title>Example Feed</title>
     <link href="http://example.org/"/>
     <updated>2003-12-13T18:30:02Z</updated>
     <author>
       <name>John Doe</name>
     </author>
     <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

     <entry>
       <title>Atom-Powered Robots Run Amok</title>
       <link href="http://example.org/2003/12/13/atom03"/>
       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text.</summary>
     </entry>

   </feed>

Un document de fil Atom plus complet avec une seule entrée :

   <?xml version="1.0" encoding="utf-8"?>
   <feed xmlns="http://www.w3.org/2005/Atom">
     <title type="text">dive into mark</title>
     <subtitle type="html">
       A &lt;em&gt;lot&lt;/em&gt; of effort
       went into making this effortless
     </subtitle>
     <updated>2005-07-31T12:29:29Z</updated>
     <id>tag:example.org,2003:3</id>
     <link rel="alternate" type="text/html"
      hreflang="en" href="http://example.org/"/>
     <link rel="self" type="application/atom+xml"
      href="http://example.org/feed.atom"/>
     <rights>Copyright (c) 2003, Mark Pilgrim</rights>
     <generator uri="http://www.example.com/" version="1.0">
       Example Toolkit
     </generator>
     <entry>
       <title>Atom draft-07 snapshot</title>
       <link rel="alternate" type="text/html"
        href="http://example.org/2005/04/02/atom"/>
       <link rel="enclosure" type="audio/mpeg" length="1337"
        href="http://example.org/audio/ph34r_my_podcast.mp3"/>
       <id>tag:example.org,2003:3.2397</id>
       <updated>2005-07-31T12:29:29Z</updated>
       <published>2003-12-13T08:29:29-04:00</published>
       <author>
         <name>Mark Pilgrim</name>
         <uri>http://example.org/</uri>
         <email>f8dy@example.com</email>
       </author>
       <contributor>
         <name>Sam Ruby</name>
       </contributor>
       <contributor>
         <name>Joe Gregorio</name>
       </contributor>
       <content type="xhtml" xml:lang="en"
        xml:base="http://diveintomark.org/">
         <div xmlns="http://www.w3.org/1999/xhtml">
           <p><i>[Update: The Atom draft is finished.]</i></p>
         </div>
       </content>
     </entry>
   </feed>

1.2. Espace de noms et version

L'adresse URI d'espace de noms XML [W3C.REC-xml-names-19990114] du format de données XML décrit dans cette spécification est le suivant :

   http://www.w3.org/2005/Atom

Par commodité, on peut désigner ce format de données par « Atom 1.0 ». En interne, cette spécification emploie « Atom ».

1.3. Conventions d'écriture

Cette spécification décrit la conformité en fonction de deux artéfacts : les documents de fil Atom et les documents d'entrée Atom (Atom entry documents). Elle définit en outre quelques contraintes sur les processeurs Atom.

Cette spécification emploie le préfixe d'espace de noms « atom: » pour l'adresse URI de l'espace de noms identifié précédemment à la section 1.2. Notez que le choix du préfixe d'espace de noms est arbitraire et sans importance sémantique.

Le format Atom est spécifié à l'aide de termes de l'ensemble d'information XML (XML Infoset) [W3C.REC-xml-infoset-20040204]. Toutefois, cette spécification abrège deux termes courants : la phrase « item d'information » est omise pour le nommage des items d'information d'élément (element information items) et des items d'information d'attribut (attribute information items). Ainsi, lorsque cette spécification emploie le terme « élément », elle se réfère à un item d'information d'élément dans la terminologie Infoset. De même, pour « attribut », qui se réfère à un item d'information d'attribut.

Certaines sections de cette spécification sont illustrées par des fragments d'un schéma RELAX NG Compact non normatif [RELAX-NG]. En revanche, le texte de cette spécification fournit la définition de conformité. Un schéma complet est disponible en annexe B.

Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » dans cette spécification doivent s'interpréter comme décrit dans le document BCP 14, [RFC2119], selon les objectifs de conformité.

2. Documents Atom

Cette spécification décrit deux types de documents Atom : les documents de fil Atom et les documents d'entrée Atom.

Un document de fil Atom (Atom feed document) est une représentation d'un fil Atom, contenant des métadonnées à propos du fil et certaines ou toutes les entrées qui lui sont associées. Sa racine est l'élément atom:feed.

Un document d'entrée Atom (Atom entry document) représente exactement une seule entrée Atom, hors du contexte d'un fil Atom. Sa racine est l'élément atom:entry.

   namespace atom = "http://www.w3.org/2005/Atom"
   start = atomFeed | atomEntry

Les deux types de documents Atom sont spécifiés en fonction de l'ensemble d'information XML, sérialisés en XML 1.0 [W3C.REC-xml-20040204] et identifiés par le type de média "application/atom+xml". Les documents Atom DOIVENT être du XML bien formé. Cette spécification n'établit pas de définition DTD pour les documents Atom, et n'exige donc pas qu'ils soient valides (au sens de XML).

Atom autorise l'utilisation d'adresses IRI [RFC3987]. Toute adresse URI [RFC3986] est aussi une adresse IRI, et une adresse URI peut donc être utilisée partout subordonnée à une adresse IRI nommée. Deux règles particulières sont à observer :

1. 1. Lorsqu'une adresse IRI, qui n'est pas aussi une adresse URI, est donnée à résoudre, on DOIT l'associer (mapped) à une adresse URI en suivant les étapes de la section 3.1 du document [RFC3987], et ;
2. 2. Lorsqu'une adresse IRI sert de valeur à un élément atom:id, on NE DOIT PAS l'associer ainsi, afin que la comparaison décrite à la section 4.2.6.1 fonctionne.

Tout élément défini par cette spécification PEUT avoir un attribut xml:base [W3C.REC-xmlbase-20010627]. Lorsque l'attribut xml:base est utilisé dans un document Atom, sa fonction est celle décrite à la section 5.1.1 du document [RFC3986], qui est d'établir l'adresse URI (ou IRI) de base pour la résolution des références relatives trouvées dans la portée effective de l'attribut xml:base.

Tout élément défini par cette spécification PEUT avoir un attribut xml:lang, dont le contenu indique le langage naturel de l'élément et ses descendants. Le contexte de langue n'a d'importance que pour les éléments et attributs signalés comme « sensibles à la langue » (language sensitive) par cette spécicification. Les exigences concernant le contenu et l'interprétation de l'attribut xml:lang sont définies à la section 2.12 de la spécification XML 1.0 [W3C.REC-xml-20040204].

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      undefinedAttribute*

Atom est un format extensible. Cf. la section 6 de ce document pour une description complète de la façon d'étendre les documents Atom.

Les processeurs Atom PEUVENT maintenir un état alimenté par (sourced from) des documents de fil Atom et les combiner à d'autres documents de fil Atom, afin de faciliter une vue contiguë des contenus d'un fil. La façon de combiner les documents de fil Atom pour reconstruire un fil (par exemple, la mise à jour d'entrées et de métadonnées, la prise en charge d'entrées manquantes) n'est pas traitée par cette spécification.

3. Structures Atom communes

Nombre d'éléments Atom partagent quelques structures communes. Cette section définit ces structures et leurs exigences pour une référence pratique par les définitions d'élément appropriées.

Lorsqu'un élément est identifié comme étant un type particulier de structure, il hérite des exigences correspondantes de la définition de cette structure dans cette section.

Notez qu'il NE DOIT PAS y avoir de caractères blancs (white space) dans une structure de date ou dans une adresse IRI. Certaines mises en œuvre générant du XML insèrent par erreur systématiquement (default) des caractères blancs autour des valeurs, et celles-ci produiront des documents Atom invalides.

3.1. Structures de texte

Une structure de texte contient du texte intelligible (human-readable), habituellement en petites quantités. Le contenu des structures de texte est sensible à la langue.

   atomPlainTextConstruct =
      atomCommonAttributes,
      attribute type { "text" | "html" }?,
      text

   atomXHTMLTextConstruct =
      atomCommonAttributes,
      attribute type { "xhtml" },
      xhtmlDiv

   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

3.1.1. L'attribut type

Les structures de texte PEUVENT avoir un attribut type. Si présent, sa valeur DOIT être l'une parmi "text", "html" et "xhtml". Si l'attribut type est absent, les processeurs Atom DOIVENT se comporter comme s'il était présent avec une valeur de "text". Contrairement à l'élément atom:content défini à la section 4.1.3, on NE DOIT PAS utiliser de types de média MIME [MIMEREG] comme valeurs de l'attribut type sur les structures de texte.

3.1.1.1. text

Exemple d'élément atom:title avec du contenu textuel :

   ...
   <title type="text">
     Less: &lt;
   </title>
   ...

Si la valeur est "text", le contenu de la structure de texte NE DOIT PAS contenir de sous-éléments (child elements). Un tel texte est prévu pour être présenté à des humains de manière intelligible. Les processeurs Atom PEUVENT donc réduire (collapse) les caractères blancs (y compris les sauts de ligne) et afficher le texte en utilisant des techniques typographiques telles que justification et fontes proportionnelles.

3.1.1.2. html

Exemple d'élément atom:title avec du contenu HTML :

   ...
   <title type="html">
     Less: &lt;em&gt; &lt; &lt;/em&gt;
   </title>
   ...

Si la valeur de type est "html", la structure de texte NE DOIT PAS contenir de sous-éléments et son contenu DEVRAIT être adapté à un traitement en tant que HTML [HTML]. Tout balisage contenu DOIT subir un codage d'échappement (escaped), par exemple <BR> en <BR>. Le balisage HTML contenu DEVRAIT être tel qu'il pourrait apparaître directement dans un élément HTML <DIV>, après décodage d'échappement (unescaping). Les processeurs Atom affichant un tel contenu PEUVENT utiliser ce balisage pour aider à son affichage.

3.1.1.3. xhtml

Exemple d'élément atom:title avec du contenu XHTML :

   ...
   <title type="xhtml" xmlns:xhtml="http://www.w3.org/1999/xhtml">
     <xhtml:div>
       Less: <xhtml:em> &lt; </xhtml:em>
     </xhtml:div>
   </title>
   ...

Si la valeur de type est "xhtml", le contenu DOIT être un seul élément XHTML div [XHTML] et DEVRAIT être adapté à un traitement en tant que XHTML. L'élément XHTML div lui-même NE DOIT PAS être considéré comme faisant partie du contenu. Les processeurs Atom affichant le contenu PEUVENT utiliser le balisage pour aider à son affichage. Les versions codées de caractères tels que & et > (N.d.T. codés en & et >) représentent ces caractères, et non du balisage.

Exemples de contenu XHTML valide :

   ...
   <summary type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
         This is <b>XHTML</b> content.
      </div>
   </summary>
   ...
   <summary type="xhtml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
         This is <xhtml:b>XHTML</xhtml:b> content.
      </xhtml:div>
   </summary>
   ...

L'exemple suivant suppose une liaison de l'espace de noms XHTML au préfixe « xh » plus tôt dans le document :

   ...
   <summary type="xhtml">
      <xh:div>
         This is <xh:b>XHTML</xh:b> content.
      </xh:div>
   </summary>
   ...

3.2. Structures de personne

Une structure de personne est un élément qui décrit une personne, une entreprise ou une entité similaire (ci-après une « personne »).

   atomPersonConstruct =
      atomCommonAttributes,
      (element atom:name { text }
       & element atom:uri { atomUri }?
       & element atom:email { atomEmailAddress }?
       & extensionElement*)

Cette spécification n'attribue aucune signification à l'ordre d'apparition des sous-éléments dans une structure de personne. Les structures de personne autorisent l'extension des éléments de métadonnées (cf. la section 6.4).

3.2.1. L'élément atom:name

Le contenu de l'élément atom:name communique un nom intelligible pour la personne. Le contenu de atom:name est sensible à la langue. Les structures de personne DOIVENT contenir exactement un seul élément atom:name.

3.2.2. L'élément atom:uri

Le contenu de l'élément atom:uri communique une adresse IRI associée à la personne. Les structures de personne PEUVENT contenir un élément atom:uri mais NE DOIVENT PAS en contenir plus d'un. Le contenu de atom:uri dans une structure de personne DOIT être une référence IRI (IRI reference) [RFC3987].

3.2.3. L'élément atom:email

Le contenu de l'élément atom:email communique une adresse électronique associée à la personne. Les structures de personne PEUVENT contenir un élément atom:email mais NE DOIVENT PAS en contenir plus d'un. Son contenu DOIT être conforme à la production "addr-spec" dans le document [RFC2822].

3.3. Structures de date

Une structure de date est un élément dont le contenu DOIT être conforme à la production "date-time" dans le document [RFC3339]. En outre, on DOIT utiliser un caractère LETTRE LATINE T MAJUSCULE pour séparer la date et l'heure, et on DOIT utiliser un caractère LETTRE LATINE Z MAJUSCULE en l'absence d'un décalage de fuseau horaire numérique.

   atomDateConstruct =
      atomCommonAttributes,
      xsd:dateTime

De telles valeurs de date sont compatibles avec les spécifications suivantes : [ISO.8601.1988], [W3C.NOTE-datetime-19980827] et [W3C.REC-xmlschema-2-20041028].

Exemple de structures de date :

   <updated>2003-12-13T18:30:02Z</updated>
   <updated>2003-12-13T18:30:02.25Z</updated>
   <updated>2003-12-13T18:30:02+01:00</updated>
   <updated>2003-12-13T18:30:02.25+01:00</updated>

Les valeurs de date DEVRAIENT être aussi précises que possibles. Par exemple, il ne serait pas approprié en général pour un système de publication d'appliquer la même estampille (timestamp) à plusieurs entrées publiées le même jour.

4. Définitions des éléments Atom

4.1. Éléments conteneurs

4.1.1. L'élément atom:feed

L'élément atom:feed est l'élément de document (c'est-à-dire de niveau supérieur) d'un document de fil Atom, agissant comme un conteneur des métadonnées et données associées au fil. Ses sous-éléments consistent en éléments de métadonnées suivis de zéro ou plus sous-éléments atom:entry.

   atomFeed =
      element atom:feed {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle
          & atomUpdated
          & extensionElement*),
         atomEntry*
      }

Cette spécification n'attribue aucune signification à l'ordre des éléments atom:entry dans le fil.

Les sous-éléments suivants sont définis par cette spécification (notez que la présence de certains éléments est obligatoire) :

• Les éléments atom:feed DOIVENT contenir un ou plusieurs éléments atom:author, à moins que tous les sous-éléments atom:entry de l'élément atom:feed ne contiennent au moins un élément atom:author ;
• Les éléments atom:feed PEUVENT contenir un nombre quelconque d'éléments atom:category ;
• Les éléments atom:feed PEUVENT contenir un nombre quelconque d'éléments atom:contributor ;
• Les éléments atom:feed NE DOIVENT PAS contenir plus d'un élément atom:generator ;
• Les éléments atom:feed NE DOIVENT PAS contenir plus d'un élément atom:icon ;
• Les éléments atom:feed NE DOIVENT PAS contenir plus d'un élément atom:logo ;
• Les éléments atom:feed DOIVENT contenir exactement un seul élément atom:id ;
• Les éléments atom:feed DEVRAIENT contenir un élément atom:link dont la valeur de l'attribut rel est "self". C'est adresse URI préférée pour récupérer les documents de fil Atom représentant ce fil Atom ;
• Les éléments atom:feed NE DOIVENT PAS contenir plus d'un élément atom:link dont la valeur de l'attribut rel est "alternate" avec la même combinaison de valeurs d'attribut type et hreflang ;
• Les éléments atom:feed PEUVENT contenir d'autres éléments atom:link hormis ceux décrits ci-dessus ;
• Les éléments atom:feed NE DOIVENT PAS contenir plus d'un élément atom:rights ;
• Les éléments atom:feed NE DOIVENT PAS contenir plus d'un élément atom:subtitle ;
• Les éléments atom:feed DOIVENT contenir exactement un seul élément atom:title ;
• Les éléments atom:feed DOIVENT contenir exactement un seul élément atom:updated.

Si plusieurs éléments atom:entry avec la même valeur de atom:id apparaissent dans un document de fil Atom, ils représentent la même entrée. Leurs estampilles atom:updated DEVRAIENT être différentes. Si un document de fil Atom contient plusieurs entrées avec le même atom:id, les processeurs Atom PEUVENT choisir de tous les afficher ou d'en afficher un sous-ensemble. Un comportement typique serait d'afficher seulement l'entrée avec l'estampille atom:updated la plus récente.

4.1.1.1. Fournir un contenu textuel

L'expérience montre que les fils avec un contenu textuel sont généralement plus utiles que ceux qui n'ont en pas. Certaines applications (un exemple serait celui des indexeurs en texte intégral (full-text indexers)) nécessitent une quantité minimale de texte ou de (X)HTML pour fonctionner de manière fiable et prévisible. Les créateurs de fils devraient être conscients de ces questions. Il est souhaitable que chaque élément atom:entry contienne un élément atom:title non vide, un élément atom:content non vide, si présent, et un élément atom:summary non vide lorsque l'entrée ne contient pas d'élément atom:content. Toutefois, l'absence de atom:summary n'est pas une erreur et les processeurs Atom NE DOIVENT PAS fonctionner incorrectement (fail to function correctly) du fait de cette absence.

4.1.2. L'élément atom:entry

L'élement atom:entry représente une entrée individuelle, agissant comme un conteneur des métadonnées et données associées à l'entrée. Cet élément peut apparaître comme sous-élément de atom:feed, ou comme l'élément de document (c'est-à-dire de niveau supérieur) d'un document d'entrée Atom autonome (stand-alone).

   atomEntry =
      element atom:entry {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContent?
          & atomContributor*
          & atomId
          & atomLink*
          & atomPublished?
          & atomRights?
          & atomSource?
          & atomSummary?
          & atomTitle
          & atomUpdated
          & extensionElement*)
      }

Cette spécification n'attribue acune signification à l'ordre d'apparition des sous-éléments de atom:entry.

Les sous-éléments suivants sont définis par cette spécification (notez qu'elle impose la présence de certains éléments) :

• Les éléments atom:entry DOIVENT contenir un ou plusieurs éléments atom:author, à moins que l'élément atom:entry ne contienne un élément atom:source contenant un élément atom:author, ou dans un document de fil Atom, que l'élément atom:feed ne contienne lui-même un élément atom:author ;
• Les éléments atom:entry PEUVENT contenir un nombre quelconque d'éléments atom:category ;
• Les éléments atom:entry NE DOIVENT PAS contenir plus d'un élément atom:content ;
• Les éléments atom:entry PEUVENT contenir un nombre quelconque d'éléments atom:contributor ;
• Les éléments atom:entry DOIVENT contenir exeactement un seul élément atom:id ;
• Les éléments atom:entry n'ayant pas de sous-élément atom:content DOIVENT contenir au moins un élément atom:link dont la valeur de l'attribut rel est "alternate" ;
• Les éléments atom:entry NE DOIVENT PAS contenir plus d'un élément atom:link dont la valeur de l'attribut rel est "alternate" avec la même combinaison de valeurs d'attribut type et hreflang ;
• Les éléments atom:entry PEUVENT contenir d'autres éléments atom:link hormis ceux décrits ci-dessus ;
• Les éléments atom:entry NE DOIVENT PAS contenir plus d'un élément atom:published ;
• Les éléments atom:entry NE DOIVENT PAS contenir plus d'un élément atom:rights ;
• Les éléments atom:entry NE DOIVENT PAS contenir plus d'un élément atom:source ;
• Les éléments atom:entry DOIVENT contenir un élément atom:summary dans l'un des cas suivants :
  • l'élément atom:entry contient un élément atom:content avec un attribut src (il est donc vide) ;
  • l'élément atom:entry a un contenu codé en Base64, c'est-à-dire que l'attribut type de l'élément atom:content est un type de média MIME [MIMEREG], mais n'est pas un type de média XML [RFC3023], ne commence pas par « text/ » et ne finit pas par « /xml » ou « +xml ».
• Les éléments atom:entry NE DOIVENT PAS contenir plus d'un élément atom:summary ;
• Les éléments atom:entry DOIVENT contenir exactement un seul élément atom:title ;
• Les éléments atom:entry DOIVENT contenir exactement un seul élément atom:updated.

4.1.3. L'élément atom:content

L'élément atom:content contient ou bien lie au contenu de l'entrée. Le contenu de atom:content est sensible à la langue.

   atomInlineTextContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "text" | "html" }?,
         (text)*
      }

   atomInlineXHTMLContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "xhtml" },
         xhtmlDiv
      }

   atomInlineOtherContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         (text|anyElement)*
      }

   atomOutOfLineContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         attribute src { atomUri },
         empty
      }

   atomContent = atomInlineTextContent
    | atomInlineXHTMLContent
    | atomInlineOtherContent
    | atomOutOfLineContent

4.1.3.1. L'attribut type

Sur l'élément atom:content, l'attribut type PEUT avoir l'une des valeurs "text", "html" ou "xhtml". Si ce n'est pas le cas, sa valeur DOIT être conforme à la syntaxe d'un type de média MIME, mais elle NE DOIT PAS être d'un type composite (cf. la section 4.2.6 du document [MIMEREG]). Si ni l'attribut type ni l'attribut src ne sont présents, les processeurs Atom DOIVENT agir comme si l'attribut type l'était avec une valeur de "text".

4.1.3.2. L'attribut src

L'élément atom:content PEUT avoir un attribut src dont la valeur DOIT être une référence IRI [RFC3987]. Si l'attribut src est présent, l'élément atom:content DOIT être vide. Les processeurs Atom PEUVENT utiliser l'adresse IRI pour récupérer le contenu et PEUVENT choisir d'ignorer le contenu distant ou de le présenter d'une manière différente du contenu local.

Si l'attribut src est présent, l'attribut type DEVRAIT être fourni et DOIT être un type de média MIME [MIMEREG], au lieu des valeurs "text", "html" ou "xhtml". La valeur est consultative, c'est-à-dire que, lors de la résolution de l'adresse URI correspondante (convertie depuis (mapped from) une adresse IRI au besoin), si le serveur fournissant ce contenu fournit aussi un type de média, le type de média du serveur est autoritaire.

4.1.3.3. Modèle de traitement

Les documents Atom DOIVENT être conformes aux règles suivantes. Les processeurs Atom DOIVENT interpréter l'élément atom:content selon la première règle applicable.

1. 1. Si la valeur de l'attribut type est "text", l'élément atom:content NE DOIT PAS contenir de sous-éléments. Ce texte doit être présenté pour lecture à des humains. Ainsi, les processeurs Atom PEUVENT réduire (collapse) les caractères blancs (y compris les sauts de ligne) et afficher le texte en utilisant des techniques typographiques telles que justification et fontes proportionnelles ;
2. 2. Si la valeur de l'attribut type est "html", l'élément atom:content NE DOIT PAS contenir de sous-éléments et DEVRAIT convenir à un traitement HTML [HTML]. Le balisage HTML DOIT avoir un codage d'échappement, par exemple <br> en <br>. Le balisage HTML DEVRAIT être tel qu'il pourrait apparaître directement au sein d'un élément HTML <DIV>. Les processeurs Atom interprétant le contenu PEUVENT utiliser le balisage pour aider à l'afficher ;
3. 3. Si la valeur de l'attribut type est "xhtml", le contenu de l'élément atom:content DOIT être un seul élément XHTML div [XHTML] et DEVRAIT convenir à un traitement XHTML. L'élément XHTML div lui-même NE DOIT PAS être considéré comme faisant partie du contenu. Les processeurs Atom interprétant le contenu PEUVENT utiliser le balisage pour aider à l'afficher. Les versions codées des caractères, tels que « & » et « > » codés en « &amp; » et « &gt; », représentent ces caractères et non du balisage ;
4. 4. Si la valeur de l'attribut type est un type de média XML [RFC3023], ou se termine par « +xml » ou « /xml » (casse non significative), l'élément atom:content PEUT contenir des sous-éléments et son contenu DEVRAIT convenir à un traitement selon le type de média indiqué. Si l'attribut src n'est pas présent, cela voudrait normalement dire que l'élément atom:content contiendrait un seul sous-élément qui servirait d'élément racine du document XML du type indiqué ;
5. 5. Si la valeur de l'attribut type commence par « text/ » (casse non significative), l'élément atom:content NE DOIT PAS contenir de sous-éléments ;
6. 6. Pour toutes les autres valeurs de l'attribut type, le contenu de l'élément atom:content DOIT être du codage Base64 valide, comme décrit à la section 3 du document [RFC3548]. Une fois décodé, il DEVRAIT convenir à un traitement selon le type de média indiqué. Auquel cas, les caractères codés en Base64 PEUVENT être précédés et suivis de caractères blancs dans l'élément atom:content, et les lignes sont séparés par un seul caractère SAUT DE LIGNE (U+000A).

4.1.3.4. Exemples

Du XHTML dans la ligne :

   ...
   <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
         This is <b>XHTML</b> content.
      </div>
   </content>
   ...
   <content type="xhtml">
      <xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
         This is <xhtml:b>XHTML</xhtml:b> content.
      </xhtml:div>
   </content>
   ...

L'exemple suivant suppose une liaison de l'espace de noms XHTML au préfixe « xh » plus tôt dans le document :

   ...
   <content type="xhtml">
      <xh:div>
         This is <xh:b>XHTML</xh:b> content.
      </xh:div>
   </content>
   ...

4.2. Éléments de métadonnées

4.2.1. L'élément atom:author

L'élément atom:author est une structure de personne qui indique l'auteur de l'entrée ou du fil.

   atomAuthor = element atom:author { atomPersonConstruct }

Si un élément atom:entry ne contient pas d'élément atom:author, alors les éléments atom:author de l'élément atom:source contenu sont censés s'appliquer. Dans un document de fil Atom, les éléments atom:author de l'élément atom:feed conteneur sont censés s'appliquer à l'entrée, s'il n'y a pas d'éléments atom:author aux endroits décrits ci-dessus.

4.2.2. L'élément atom:category

L'élément atom:category communique des informations à propos d'une catégorie associée à une entrée ou à un fil. Cette spécificaiton n'attribue aucune signification au contenu (le cas échéant) de cet élément.

   atomCategory =
      element atom:category {
         atomCommonAttributes,
         attribute term { text },
         attribute scheme { atomUri }?,
         attribute label { text }?,
         undefinedContent
      }

4.2.2.1. L'attribut term

L'atribut term est une chaîne qui identifie la catégorie à laquelle appartient l'entrée ou le fil. Les éléments de catégorie DOIVENT avoir un attribut term.

4.2.2.2. L'attribut scheme

L'attribut scheme est une adresse IRI qui identifie un schéma de catégorisation. Les éléments de catégorie PEUVENT avoir un attribut scheme.

4.2.2.3. L'attribut label

L'attribut label fournit un label intelligible à afficher dans les applications d'utilisateur final. Le contenu de l'attribut label est sensible à la langue. Les entités telles que « &amp; » et « &lt; » représentent leurs caractères correspondants (« & » et « < » respectivement) et non du balisage. Les éléments de catégorie PEUVENT avoir un attribut label.

4.2.3. L'élément atom:contributor

L'élément atom:contributor est une structure de personne qui indique une personne ou une autre entité ayant participé à l'entrée ou au fil.

   atomContributor = element atom:contributor { atomPersonConstruct }

4.2.4. L'élément atom:generator

Le contenu de l'élément atom:generator identifie l'agent utilisé pour générer le fil, pour un débogage ou d'autres buts.

   atomGenerator = element atom:generator {
      atomCommonAttributes,
      attribute uri { atomUri }?,
      attribute version { text }?,
      text
   }

Le contenu de cet élément, si présent, DOIT être une chaîne qui est le nom intelligible de l'agent générateur. Les entités telles que « &amp; » et « &lt; » représentent leurs caractères correspondants (« & » et « < » respectivement) et non du balisage.

L'élément atom:generator PEUT avoir un attribut uri dont la valeur DOIT être une référence IRI [RFC3987]. Une fois résolue, l'adresse URI résultante (convertie depuis une adresse IRI si nécessaire) DEVRAIT produire une représentation qui est pertinente à cet agent.

L'élément atom:generator PEUT avoir une attribut version qui indique la version de l'agent générateur.

4.2.5. L'élément atom:icon

Le contenu de l'élément atom:icon est une référence IRI [RFC3987] qui identifie une image fournissant une identification visuelle imagée du fil.

   atomIcon = element atom:icon {
      atomCommonAttributes,
      (atomUri)
   }

L'image DEVRAIT avoir des proportions (aspect ratio) d'un (dans l'horizontale) par un (dans la verticale) et DEVRAIT convenir à une représentation à échelle réduite.

4.2.6. L'élément atom:id

L'élément atom:id communique un identificateur permanent, unique et universel pour une entrée ou un fil.

   atomId = element atom:id {
      atomCommonAttributes,
      (atomUri)
   }

Son contenu DOIT être une adresse IRI, comme défini par le document [RFC3987]. Notez que la définition d'une adresse IRI exclut les références relatives. Bien qu'une adresse IRI soit susceptible d'utiliser un schéma de résolution (dereferencable scheme), les processeurs Atom NE DOIVENT PAS supposer qu'elle est résolvable.

Lorsqu'un document Atom est translaté (relocated), déplacé (migrated), agrégé (syndicated), republié, exporté ou importé, le contenu de son élément atom:id NE DOIT PAS changer. Dit autrement, un élément atom:id se rattache à toutes les instantiations. On suggère de stocker l'élément atom:id avec la ressource associée.

Le contenu d'un élément atom:id DOIT être créé de manière à garantir son unicité.

À cause du risque de confusion entre des adresses IRI qui seraient équivalentes si elles étaient mises en correspondance à des adresses URI et résolues, la stratégie de normalisation suivante DEVRAIT être observée lors de la génération des éléments atom:id :

• Fournir le schéma en lettres minuscules ;
• Fournir l'hôte, le cas échéant, en lettres minuscules ;
• Effectuer un codage en pourcentage (percent-encoding) seulement là où c'est nécessaire ;
• Utiliser des caractères A à F en majuscules pour le codage en pourcentage ;
• Empêcher l'apparition de segments à point (dot-segments) dans les chemins ;
• Pour les schémas qui définissent une autorité par défaut, utiliser une autorité vide si on veut la valeur par défaut ;
• Pour les schémas qui définissent un chemin vide comme étant équivalent à un chemin de "/", utiliser "/" ;
• Pour les schémas qui définissent un port, utiliser un port vide si on veut la valeur par défaut ;
• Préserver les identificateurs de fragment (fragment identifiers) et requêtes (queries) vides ;
• S'assurer que tous les caractères des composants de l'adresse IRI sont correctement normalisés, par exemple en utilisant les formes NFC ou NFKC.

4.2.6.1. Comparaison des atom:id

Les instances des éléments atom:id peuvent être comparées pour déterminer si une entrée ou un fil sont les mêmes que l'une ou l'un vus auparavant. Les processeurs DOIVENT comparer les éléments atom:id caractère par caractère (la casse étant significative). Les opérations de comparaison DOIVENT se fonder uniquement sur les chaînes de caractères IRI et NE DOIVENT PAS compter sur la résolution des adresses IRI ou des adresses URI converties depuis celles-ci.

En conséquence, deux adresses IRI qui se résolvent vers la même ressource mais ne sont pas identiques caractère pour caractère seront considérées comme étant différentes pour les besoins de la comparaison des identificateurs.

Par exemple, voici quatre identificateurs distincts, bien qu'ils ne diffèrent que par la casse :

      http://www.example.org/thing
      http://www.example.org/Thing
      http://www.EXAMPLE.org/thing
      HTTP://www.example.org/thing

De même, voici trois identificateurs distincts, pace que le codage d'échappement en pourcentage de l'adresse IRI importe pour les besoins de la comparaison :

      http://www.example.com/~bob
      http://www.example.com/%7ebob
      http://www.example.com/%7Ebob

4.2.7. L'élément atom:link

L'élément atom:link définit une référence depuis une entrée ou un fil vers une ressource web. Cette spécification n'attribue aucune signification au contenu (le cas échéant) de cet élément.

   atomLink =
      element atom:link {
         atomCommonAttributes,
         attribute href { atomUri },
         attribute rel { atomNCName | atomUri }?,
         attribute type { atomMediaType }?,
         attribute hreflang { atomLanguageTag }?,
         attribute title { text }?,
         attribute length { text }?,
         undefinedContent
      }

4.2.7.1. L'attribut href

L'attribut href contient l'adresse IRI du lien. Les éléments atom:link DOIVENT avoir un attribut href dont la valeur DOIT être une référence IRI [RFC3987].

4.2.7.2. L'attribut rel

Les éléments atom:link PEUVENT avoir un attribut rel qui indique le type de la relation de lien. Si l'attribut rel n'est pas présent, l'élément de lien DOIT être interprété comme si le type de la relation de lien est "alternate".

La valeur de l'attribut rel DOIT être une chaîne non vide, qui correspond à la production "isegment-nz-nc" ou bien à la production "IRI" dans le document [RFC3987]. Notez que l'utilisation d'une référence relative autre qu'un nom simple n'est pas permise. Si un nom est donné, les mises en œuvre DOIVENT considérer le type de relation de lien comme étant équivalent au même nom enregistré dans le registre des relations de lien de l'IANA (IANA Registry of Link Relations) (section 7), et donc à l'adresse IRI qui aurait été obtenue en ajoutant la valeur de l'attribut rel à la fin de la chaîne "http://www.iana.org/assignments/relation/". La valeur de rel décrit la signification du lien mais n'impose aucune condition de comportement sur les processeurs Atom.

Ce document définit cinq valeurs initiales pour le registre des relations de lien :

1. 1. La valeur "alternate" signifie que l'adresse IRI dans la valeur de l'attribut href identifie une autre version de la ressource décrite par l'élément conteneur ;
2. 2. La valeur "related" signifie que l'adresse IRI dans la valeur de l'attribut href identifie une ressource liée à la ressource décrite par l'élément conteneur. Par exemple, le fil d'un site qui discute des performance du moteur de recherche à "http://search.example.com" pourrait contenir, en sous-élément de atom:feed :

   <link rel="related" href="http://search.example.com/"/>

   Un lien identique pourrait apparaître comme sous-élément de tout élément atom:entry dont le contenu inclurait une discussion à propos de ce même moteur de recherche.

3. 3. La valeur "self" signifie que l'adresse IRI dans la valeur de l'attribut href identifie une ressource équivalente à l'élément conteneur ;
4. 4. La valeur "enclosure" signifie que l'adresse IRI dans la valeur de l'attribut href identifie une ressource liée, qui est potentiellement de grande dimension et pourrait nécessiter un traitement spécial. Pour les éléments atom:link avec rel="enclosure", l'attribut length DEVRAIT être fourni.
5. 5. La valeur "via" signifie que l'adresse IRI dans la valeur de l'attribut href identifie une ressource qui est la source de l'information fournie dans l'élément conteneur.

4.2.7.3. L'attribut type

Sur l'élément atom:link, la valeur de l'attribut type est un type de média consultatif : c'est un indice à propos du type de la représentation qui est censée être retournée lorsque la valeur de l'attribut href est résolue. Notez que l'attribut type ne surclasse pas (override) le type de média réel retourné avec la représentation. Les éléments de lien PEUVENT avoir un attribut type dont la valeur DOIT être conforme à la syntaxe d'un type de média MIME [MIMEREG].

4.2.7.4. L'attribut hreflang

Le contenu de l'attribut hreflang décrit la langue de la ressource désignée par l'attribut href. Utilisé avec rel="alternate", il implique une version traduite de l'entrée. Les éléments de lien PEUVENT avoir un attribut hreflang dont la valeur DOIT être une étiquette de langue (language tag) [RFC3066].

4.2.7.5. L'attribut title

L'attribut title communique une information intelligible à propos du lien. Le contenu de l'attribut title est sensible à la langue. Les entités telles que « &amp; » et « &lt; » représentent leurs caractères correspondants (« & » et « < » respectivement) et non du balisage. Les éléments de lien PEUVENT avoir un attribut title.

4.2.7.6. L'attribut length

L'attribut length indique une dimension consultative du contenu lié en octets ; c'est un indice à propos de la longueur de contenu de la représentation retournée lorsque l'adresse IRI dans l'attribut href est convertie en adresse URI et résolue. Notez que l'attribut length ne surclasse pas la longueur de contenu réelle de la représentation telle qu'elle est rapportée par le protocole sous-jacent. Les éléments de lien PEUVENT avoir un attribut length.

4.2.8. L'élément atom:logo

Le contenu de l'élément atom:logo est une référence IRI [RFC3987] qui identifie une image fournissant une représentation visuelle d'un fil.

   atomLogo = element atom:logo {
      atomCommonAttributes,
      (atomUri)
   }

L'image DEVRAIT avoir des proportions de deux (dans l'horizontale) par un (dans la verticale).

4.2.9. L'élément atom:published

L'élément atom:published est une structure de date indiquant un instant dans le temps associé à un événement tôt dans le cycle de vie de l'entrée.

   atomPublished = element atom:published { atomDateConstruct }

L'élément atom:published sera typiquement associé à la création initiale ou à la première disponibilité de la ressource.

4.2.10. L'élément atom:rights

L'élément atom:rights est une structure de texte qui communique une information à propos des droits contenus ou détenus sur une entrée ou un fil.

   atomRights = element atom:rights { atomTextConstruct }

L'élément atom:rights NE DEVRAIT PAS servir à communiquer une information de licence (licensing information) interprétable par une machine.

Si un élément atom:entry ne contient pas d'élément atom:rights, l'élément atom:rights de l'élément atom:feed conteneur, si présent, est réputé s'appliquer à l'entrée.

4.2.11. L'élément atom:source

Si un élément atom:entry est copié d'un fil à un autre, alors les métadonnées de l'élément atom:feed d'origine (c'est-à-dire tous les sous-éléments de atom:feed hormis les éléments atom:entry) PEUVENT être conservées au sein de l'entrée copiée en ajoutant un sous-élément atom:source, si celui-ci n'est pas déjà présent dans l'entrée, et en incluant une partie ou la totalité des éléments de métadonnées du fil d'origine comme sous-éléments de l'élément atom:source. De telles métadonnées DEVRAIENT être conservées si l'élément atom:feed d'origine contient des sous-éléments atom:author, atom:contributor, atom:rights ou atom:category, et que ces sous-éléments ne sont pas présents dans l'élément atom:entry d'origine.

   atomSource =
      element atom:source {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId?
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle?
          & atomUpdated?
          & extensionElement*)
      }

L'élément atom:source est conçu afin de permettre l'agrégation d'entrées provenant de fils différents tout en conservant les informations à propos du fil d'origine d'une entrée. Pour cette raison, les processuers Atom réalisant une telle agrégation DEVRAIENT au moins inclure les éléments de métadonnées de niveau fil obligatoires (atom:id, atom:title et atom:updated) dans l'élément atom:source.

4.2.12. L'élément atom:subtitle

L'élément atom:subtitle est une structure de texte qui communique une description ou un sous-titre intelligibles pour un fil.

   atomSubtitle = element atom:subtitle { atomTextConstruct }

4.2.13. L'élément atom:summary

L'élément atom:summary est une structure de texte qui communique un récapitulatif, un résumé ou un extrait d'une entrée.

   atomSummary = element atom:summary { atomTextConstruct }

Il est déconseillé de recopier le contenu des éléments atom:title ou atom:content dans l'élément atom:summary car les processeurs Atom pourraient supposer l'existence d'un résumé utile là où il n'y en a pas.

4.2.14. L'élément atom:title

L'élément atom:title est une structure de texte qui communique un titre intelligible pour une entrée ou un fil.

   atomTitle = element atom:title { atomTextConstruct }

4.2.15. L'élément atom:updated

L'élément atom:updated est une structure de données indiquant l'instant dans le temps le plus récent où une entrée ou un fil ont été modifiés d'une façon estimée significative par l'éditeur. Toutes les modifications n'aboutissent donc pas nécessairement à une valeur de atom:updated changée.

   atomUpdated = element atom:updated { atomDateConstruct }

Les éditeurs PEUVENT changer la valeur de cet élément dans le temps.

5. Sécurisation des documents Atom

Puisqu'Atom est un format fondé sur XML, les mécanismes de sécurité XML existants peuvent être utilisés pour en sécuriser le contenu.

Les créateurs de fils ou d'entrées, et les intermédiaires qui agrègent les fils ou les entrées, peuvent avoir de bonnes raisons de signer ou de chiffrer un contenu non protégé par ailleurs. Par exemple, un marchand pourrait signer numériquement un message qui contient un coupon de réduction pour ses produits. Une banque qui utilise Atom pour envoyer des relevés de clients voudra certainement signer et chiffrer ces messages afin de protéger les informations financières de leurs clients et pour en assurer l'authenticité auprès d'eux. Des intermédiaires peuvent vouloir chiffrer des fils agrégés de sorte qu'un observateur passif ne puisse pas dire quels sujets intéressent le destinataire. Bien sûr, beaucoup d'autres exemples existent encore.

Les exigences algorithmiques dans cette section concernent le processeur Atom. Elles nécessitent qu'un destinataire au minimum soit capable de traiter les messages utilisant les algorithmes de chiffrement spécifiés. Ces exigences ne limitent pas les algorithmes que l'émetteur peut choisir.

5.1. Signatures numériques

La racine d'un document Atom (c'est-à-dire l'élément atom:feed dans un document de fil Atom et l'élément atom:entry dans un document d'entrée Atom) ou tout élément atom:entry PEUT avoir une signature enveloppée (envelopped signature), comme décrit par la spécification Syntaxe et traitement XML Signature [W3C.REC-xmldsig-core-20020212].

Les processeurs Atom NE DOIVENT PAS rejeter un document Atom contenant une telle signature au motif d'être incapable de la vérifier ; ils DOIVENT poursuivre le traitement et PEUVENT informer l'utilisateur de leur incapacité à valider la signature.

En d'autres termes, la présence d'un élément ayant l'adresse URI d'espace de noms "http://www.w3.org/2000/09/xmldsig#" et un nom local de "Signature" en sous-élément de l'élément de document NE DOIT PAS provoquer l'arrêt (fail) d'un processeur Atom du fait de sa simple présence.

Les autres éléments dans un document Atom NE DOIVENT PAS être signés à moins que leurs définitions n'indiquent explicitement cette possibilité.

La section 6.5.1 de [W3C.REC-xmldsig-core-20020212] impose la gestion du XML canonique [W3C.REC-xml-c14n-20010315]. Quoiqu'il en soit, beaucoup d'implémenteurs (implementers) ne l'utilisent pas car les documents XML signés inclus dans d'autres documents XML voient leurs signatures invalidées (broken). De ce fait, les processeurs Atom qui vérifient les documents Atom signés DOIVENT être capables de canoniser selon la méthode de la canonisation XML exclusive identifiée par l'adresse URI "http://www.w3.org/2001/10/xml-exc-c14n#", comme défini dans la spécification Canonisation XML exclusive [W3C.REC-xml-exc-c14n-20020718].

Les intermédiaires tels que les agrégateurs peuvent avoir besoin d'ajouter un élément atom:source à une entrée qui ne contient pas d'élément atom:source propre. Si une telle entrée est signée, l'ajout invalidera la signature. C'est pourquoi, un éditeur d'entrées signées individuellement devrait fortement envisager d'ajouter un élément atom:source à ces entrées avant de les signer. Les implémenteurs devraient également avoir conscience des problèmes concernant l'utilisation d'un balisage dans l'espace de noms « xml: » car il interagit avec la canonisation.

La section 4.4.2 de [W3C.REC-xmldsig-core-20020212] impose la gestion des signatures DSA et recommande la gestion des signatures RSA. Néanmoins, en raison de la plus grande popularité sur le marché de RSA par rapport à DSA, les processeurs Atom qui vérifient les documents Atom signés DOIVENT être capables de vérifier les signatures RSA mais ne sont pas tenus de l'être pour les signatures DSA. À cause des problèmes de sécurité qui peuvent survenir en cas de manipulation incorrecte du matériel de chiffrement (keying material) pour l'authentification MAC (Message Authentication Code), les documents Atom NE DEVRAIENT PAS utiliser de codes MAC pour les signatures.

5.2. Chiffrement

La racine d'un document Atom (c'est-à-dire l'élément atom:feed dans un document de fil Atom et l'élément atom:entry dans un document d'entrée Atom) PEUT être chiffrée en utilisant les mécanismes décrits dans la spécification Syntaxe et traitement XML Encryption [W3C.REC-xmlenc-core-20021210].

La section 5.1 de [W3C.REC-xmlenc-core-20021210] impose la gestion des algorithmes TripleDES, AES-128 et AES-256. Les processeurs Atom qui déchiffrent les documents Atom DOIVENT être capables de déchiffrer avec AES-128 en mode CBC (Cipher Block Chaining).

Le chiffrement fondé sur [W3C.REC-xmlenc-core-20021210] ne garantit pas l'intégrité du document original. Il existe des attaques cryptographiques où quelqu'un qui ne peut pas déchiffrer un message peut encore en changer des bits de telle façon qu'une partie ou la totalité du message déchiffrédoes ait un sens mais une signification différente. Par conséquent, les processeurs Atom qui déchiffrent les documents Atom DEVRAIENT contrôler l'intégrité du document déchiffré en vérifiant le condensé (hash) dans la signature (s'il y en a un) ou en vérifiant un condensé du document au sein du document (s'il y en a un).

5.3. Signature et chiffrement

Lorsque l'on doit à la fois signer et chiffer un document Atom, il est en général préférable de d'abord signer le document puis de chiffrer le document signé. Cela donne une intégrité au document de base tout en chiffrant la totalité de l'information, y compris l'identité de l'entité ayant signé le document. Notez que, si on avait utilisé des codes MAC pour l'authentification, la séquence DOIT être telle que le document soit signé puis chiffré, et pas l'inverse.

6. Extension d'Atom

6.1. Extensions à partir de vocabulaires non-Atom

Cette spécification décrit le vocabulaire de balisage XML d'Atom. On peut utiliser le balisage d'autres vocabulaires (du « balisage étranger ») dans un document Atom. Notez que l'élément atom:content est conçu pour accueillir du balisage étranger arbitraire.

6.2. Extensions du vocabulaire Atom

L'espace de noms Atom est réservé pour des révisions futures d'Atom avec compatibilité ascendante. Les futures versions de cette spécification pourraient ajouter de nouveaux éléments et attributs au vocabulaire de balisage Atom. Les logiciels écrits en conformité avec cette version de la spécification seront incapables de traiter correctement ce balisage et, en fait, ne seront pas capables de le distingueur d'une erreur de balisage. Pour les besoins de cette discussion, le balisage non reconnu du vocabulaire Atom sera considéré comme du « balisage étranger ».

6.3. Traitement du balisage étranger

Les processeurs Atom qui rencontrent du balisage étranger à un endroit légal conformément à cette spécification NE DOIVENT PAS interrompre le traitement ou signaler une erreur. Il se peut que le processeur Atom puisse traiter correctement le balisage étranger et le fasse. Sinon, un tel balisage est dit « balisage étranger inconnu ».

Lorsqu'ils rencontrent un balisage étranger inconnu en sous-élément de atom:entry, atom:feed ou d'une structure de personne, les processeurs Atom PEUVENT passer outre (bypass) le balisage et tout contenu textuel et NE DOIVENT PAS changer leur comportement du fait de la présence du balisage.

Lorsqu'un balisage étranger inconnu est rencontré dans une structure de texte ou dans un élément atom:content, le logiciel DEVRAIT ignorer le balisage et traiter le contenu textuel des éléments étrangers comme si le balisage environnant n'existait pas.

6.4. Éléments d'extension

Atom admet du balisage étranger partout dans un document Atom, sauf interdiction explicite. Les sous-éléments de atom:entry, atom:feed, atom:source et des structures de personne sont considérés comme étant des éléments de métadonnées et sont décrits ci-dessous. Les sous-éléments des structures de personne sont considérés s'appliquer à la structure. Le rôle d'un autre balisage étranger n'est pas défini par cette spécification.

6.4.1. Éléments d'extension simples

Un élément d'extension simple NE DOIT PAS avoir d'attributs ou de sous-éléments. L'élément PEUT contenir des données textuelles (character data) ou être vide. Les éléments d'extension simples ne sont pas sensibles à la langue.

   simpleExtensionElement =
      element * - atom:* {
         text
      }

L'élément peut être interprété comme étant une propriété simple (ou un couple nom-valeur) de l'élément parent qui le contient. Le couple constitué de l'adresse URI d'espace de noms de l'élément et du nom local de l'élément peut être interprété comme étant le nom de la propriété. Le contenu de données textuelles de l'élément peut être interprété comme étant la valeur de la propriété. Si l'élément est vide, la valeur de propriété peut alors être interprétée comme étant une chaîne vide.

6.4.2. Éléments d'extension structurés

L'élément racine d'un élément d'extension structuré DOIT avoir au moins un attribut ou sous-élément. Il PEUT avoir des attributs, il PEUT avoir un contenu XML bien formé (y compris des données textuelles), ou il PEUT être vide. Les éléments d'extension structurés sont sensibles à la langue.

   structuredExtensionElement =
      element * - atom:* {
         (attribute * { text }+,
            (text|anyElement)*)
       | (attribute * { text }*,
          (text?, anyElement+, (text|anyElement)*))
      }

La structure d'un élément d'extension structuré, y compris l'ordre de ses sous-éléments, pourrait être significatif.

Cette spécification ne fournit aucune interprétation d'un élément d'extension structuré. La syntaxe du contenu XML de l'élément (et l'interprétation des relations de l'élément à son élément conteneur) est définie par la spécification de l'extension Atom.

7. Observations concernant l'IANA

Un document Atom, sérialisé comme XML 1.0, peut être identifié par le type de média suivant :

Nom de type de média MIME :

application

Nom de sous-type MIME :

atom+xml

Paramètres obligatoires :

néant

Paramètres optionnels :

"charset" : La sémantique de ce paramètre est identique à celle du paramètre charset du type de média "application/xml" comme spécifié dans [RFC3023].

Observations sur le codage :

Identiques à celles de "application/xml" comme décrit à la section 3.2 de [RFC3023].

Observations sur la sécurité :

Comme défini dans cette spécification. En outre, puisque ce type de média emploie la convention "+xml", il partage les mêmes considérations de sécurité que celles décrites à la section 10 de [RFC3023].

Observations sur l'interopérabilité :

Aucun problème d'interopérabilité connu.

Spécification publiée :

Cette spécification.

Applications utilisant ce type de média :

Aucune application connue n'utilise actuellement ce type de média.

Informations supplémentaires :

Magic number(s) :

Comme spécifié pour "application/xml" à la section 3.2 de [RFC3023].

Extension de fichier :

.atom

Identificateurs de fragment :

Comme spécifié pour "application/xml" à la section 5 de [RFC3023].

Adresse URI de base :

Comme spécifié à la section 6 de [RFC3023].

Code de type de fichier Macintosh :

TEXT

Coordonnées des personnes à contacter pour d'autres renseignements :

Mark Nottingham <mnot@pobox.com>

Utilisation prévue :

COMMON

Auteur/contrôleur des changements :

IESG

7.1. Registre des relations de lien

Ce registre est tenu par l'IANA et il contient cinq valeurs initiales : "alternate", "related", "self", "enclosure" et "via". Les nouvelles attributions sont soumises à l'approbation de l'IANA, comme prévu dans [RFC2434]. La demande devrait être envoyée par courrier électronique à l'IANA qui la transmettra ensuite à l'IESG pour y être approuvée. La demande devrait utiliser le gabarit suivant :

Attribute Value:

(une valeur de l'attribut rel conforme à la règle syntaxique donnée à la section 4.2.7.2)

Description:

Expected display characteristics:

Security considerations:

8. Observations sur la sécurité

8.1. Contenu HTML et XHTML

Les structures de texte et l'élément atom:content permettent l'emploi de HTML et XHTML. Beaucoup d'éléments dans ces langages sont considérés comme étant « dangereux » (unsafe) en cela qu'ils ouvrent les clients à un ou plusieurs types d'attaque. Les implémenteurs de logiciels compatibles Atom devraient examiner avec attention leur prise en charge de chaque type d'élément lors du traitement du (X)HTML entrant (incoming) dans les documents Atom. Cf. les sections concernant la sécurité de [RFC2854] et [HTML] pour des conseils.

Les processeurs Atom devraiet prêter une attention particulière à la sécurité des éléments IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META et LINK, mais d'autres éléments sont également susceptibles d'avoir des propriétés négatives pour la sécurité.

(X)HTML peut contenir directement ou appeler indirectement un contenu exécutable.

8.2. Adresses URI

Les processeurs Atom traitent les adresses URI. Cf. la section 7 du document [RFC3986].

8.3. Adresses IRI

Les processeurs Atom traitent les adresses IRI. Cf. la section 8 du document [RFC3987].

8.4. Usurpation

Les processeurs Atom devraient avoir connaissance du potentiel d'attaques par usurpation (spoofing attacks) où l'attaquant publie un atom:entry avec la valeur atom:id d'une entrée d'un autre fil, qui a peut-être un élément atom:source copiant la valeur atom:id de l'autre fil. Par exemple, un processeur Atom pourrait supprimer l'affichage des entrées en double en n'affichant qu'une seule entrée dans un ensemble d'entrées avec des valeurs atom:id identiques. Dans cette situation, le processeur Atom pourrait également entreprendre de déterminer si les entrées proviennent du même éditeur avant de considérer qu'elles sont des copies.

8.5. Chiffrement et signature

Les documents Atom peuvent être chiffrés et signés, en utilisant respectivement les spécifications [W3C.REC-xmlenc-core-20021210] et [W3C.REC-xmldsig-core-20020212], et sont soumis aux considérations de sécurité impliquées par leur utilisation.

Les signatures numériques apportent l'authentification, l'intégrité du message et la non-répudiation avec preuve d'origine. Le chiffrement apporte la confidentialité des données.

9. Références

9.1. Références normatives

[HTML]

Raggett, D., Hors, A., and I. Jacobs, HTML 4.01 Specification, W3C REC REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.

[MIMEREG]

Freed, N. and J. Klensin, Media Type Specifications and Registration Procedures, BCP 13, RFC 4288, December 2005.

[RFC2119]

Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997.

[RFC2822]

Resnick, P., Internet Message Format, RFC 2822, April 2001.

[RFC2854]

Connolly, D. and L. Masinter, The 'text/html' Media Type, RFC 2854, June 2000.

[RFC3023]

Murata, M., St. Laurent, S., and D. Kohn, XML Media Types, RFC 3023, January 2001.

[RFC3066]

Alvestrand, H., Tags for the Identification of Languages, BCP 47, RFC 3066, January 2001.

[RFC3339]

Klyne, G. and C. Newman, Date and Time on the Internet: Timestamps, RFC 3339, July 2002.

[RFC3548]

Josefsson, S., The Base16, Base32, and Base64 Data Encodings, RFC 3548, July 2003.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, Uniform Resource Identifier (URI): Generic Syntax, STD 66, RFC 3986, January 2005.

[RFC3987]

Duerst, M. and M. Suignard, Internationalized Resource Identifiers (IRIs), RFC 3987, January 2005.

[W3C.REC-xml-20040204]

Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, Extensible Markup Language (XML) 1.0 (Third Edition), W3C REC REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.

[W3C.REC-xml-c14n-20010315]

Boyer, J., Canonical XML Version 1.0, W3C REC REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.

[W3C.REC-xml-exc-c14n-20020718]

Eastlake, D., Boyer, J., and J. Reagle, Exclusive XML Canonicalization Version 1.0, W3C REC REC-xml-exc-c14n-20020718, July 2002, <http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718>.

[W3C.REC-xml-infoset-20040204]

Cowan, J. and R. Tobin, XML Information Set (Second Edition), W3C REC REC-xml-infoset-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-infoset-20040204>.

[W3C.REC-xml-names-19990114]

Hollander, D., Bray, T., and A. Layman, Namespaces in XML, W3C REC REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

[W3C.REC-xmlbase-20010627]

Marsh, J., XML Base, W3C REC REC-xmlbase-20010627, June 2001, <http://www.w3.org/TR/2001/REC-xmlbase-20010627>.

[W3C.REC-xmldsig-core-20020212]

Solo, D., Reagle, J., and D. Eastlake, XML Signature Syntax and Processing, W3C REC REC-xmldsig-core-20020212, February 2002, <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.

[W3C.REC-xmlenc-core-20021210]

Reagle, J. and D. Eastlake, XML Encryption Syntax and Processing, W3C REC REC-xmlenc-core-20021210, December 2002, <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.

[XHTML]

Altheim, M., Boumphrey, F., McCarron, S., Dooley, S., Schnitzenbaumer, S., and T. Wugofski, Modularization of XHTML™, W3C REC REC-xhtml-modularization-20010410, April 2001, <http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410>.

9.2. Références informatives

[ISO.8601.1988]

International Organization for Standardization, Data elements and interchange formats - Information interchange - Representation of dates and times, ISO Standard 8601, June 1988.

[RELAX-NG]

Clark, J., RELAX NG Compact Syntax, December 2001, <http://www.oasis-open.org/committees/relax-ng/compact-20021121.html>.

[RFC2434]

Narten, T. and H. Alvestrand, Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998.

[W3C.NOTE-datetime-19980827]

Wolf, M. and C. Wicksteed, Date and Time Formats, W3C NOTE NOTE-datetime-19980827, August 1998, <http://www.w3.org/TR/1998/NOTE-datetime-19980827>.

[W3C.REC-xmlschema-2-20041028]

Malhotra, A. and P. Biron, XML Schema Part 2: Datatypes Second Edition, W3C REC REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

Annexe A. Contributeurs

Les personnes suivantes ont contribué aux versions préliminaires de ce document : Tim Bray, Mark Pilgrim et Sam Ruby. Norman Walsh a fourni le schéma Relax NG. Le contenu et les concepts qui s'y trouvent sont le produit de la communauté Atom et du groupe de travail Atompub.

Le groupe de travail Atompub se compose de dizaines de contributeurs très actifs qui ont proposé les idées et la formulation de ce document. Ce sont :

Danny Ayers, James Aylett, Roger Benningfield, Arve Bersvendsen, Tim Bray, Dan Brickley, Thomas Broyer, Robin Cover, Bill de hOra, Martin Duerst, Roy Fielding, Joe Gregorio, Bjoern Hoehrmann, Paul Hoffman, Anne van Kesteren, Brett Lindsley, Dare Obasanjo, David Orchard, Aristotle Pagaltzis, John Panzer, Graham Parks, Dave Pawson, Mark Pilgrim, David Powell, Julian Reschke, Phil Ringnalda, Antone Roundy, Sam Ruby, Eric Scheid, Brent Simmons, Henri Sivonen, Ray Slakinski, James Snell, Henry Story, Asbjorn Ulsberg, Walter Underwood, Norman Walsh, Dave Winer et Bob Wyman.

Annexe B. Schéma RELAX NG Compact

Cette annexe est informative.

Le schéma Relax NG exclut explicitement les éléments dans l'espace de noms Atom qui n'ont pas été définis dans cette révision de la spécification. Les exigences pour les processeurs Atom rencontrant un tel balisage sont indiquées à la section 6.2 et à la section 6.3.

   # -*- rnc -*-
   # RELAX NG Compact Syntax Grammar for the
   # Atom Format Specification Version 11

   namespace atom = "http://www.w3.org/2005/Atom"
   namespace xhtml = "http://www.w3.org/1999/xhtml"
   namespace s = "http://www.ascc.net/xml/schematron"
   namespace local = ""

   start = atomFeed | atomEntry

   # Common attributes

   atomCommonAttributes =
      attribute xml:base { atomUri }?,
      attribute xml:lang { atomLanguageTag }?,
      undefinedAttribute*

   # Text Constructs

   atomPlainTextConstruct =
      atomCommonAttributes,
      attribute type { "text" | "html" }?,
      text

   atomXHTMLTextConstruct =
      atomCommonAttributes,
      attribute type { "xhtml" },
      xhtmlDiv

   atomTextConstruct = atomPlainTextConstruct | atomXHTMLTextConstruct

   # Person Construct

   atomPersonConstruct =
      atomCommonAttributes,
      (element atom:name { text }
       & element atom:uri { atomUri }?
       & element atom:email { atomEmailAddress }?
       & extensionElement*)

   # Date Construct

   atomDateConstruct =
      atomCommonAttributes,
      xsd:dateTime

   # atom:feed

   atomFeed =
      [
         s:rule [
            context = "atom:feed"
            s:assert [
               test = "atom:author or not(atom:entry[not(atom:author)])"
               "An atom:feed must have an atom:author unless all "
               ~ "of its atom:entry children have an atom:author."
            ]
         ]
      ]
      element atom:feed {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle
          & atomUpdated
          & extensionElement*),
         atomEntry*
      }

   # atom:entry

   atomEntry =
      [
         s:rule [
            context = "atom:entry"
            s:assert [
               test = "atom:link[@rel='alternate'] "
               ~ "or atom:link[not(@rel)] "
               ~ "or atom:content"
               "An atom:entry must have at least one atom:link element "
               ~ "with a rel attribute of 'alternate' "
               ~ "or an atom:content."
            ]
         ]
         s:rule [
            context = "atom:entry"
            s:assert [
               test = "atom:author or "
               ~ "../atom:author or atom:source/atom:author"
               "An atom:entry must have an atom:author "
               ~ "if its feed does not."
            ]
         ]
      ]
      element atom:entry {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContent?
          & atomContributor*
          & atomId
          & atomLink*
          & atomPublished?
          & atomRights?
          & atomSource?
          & atomSummary?
          & atomTitle
          & atomUpdated
          & extensionElement*)
      }

   # atom:content

   atomInlineTextContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "text" | "html" }?,
         (text)*
      }

   atomInlineXHTMLContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { "xhtml" },
         xhtmlDiv
      }

   atomInlineOtherContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         (text|anyElement)*
      }

   atomOutOfLineContent =
      element atom:content {
         atomCommonAttributes,
         attribute type { atomMediaType }?,
         attribute src { atomUri },
         empty
      }

   atomContent = atomInlineTextContent
    | atomInlineXHTMLContent
    | atomInlineOtherContent
    | atomOutOfLineContent

   # atom:author

   atomAuthor = element atom:author { atomPersonConstruct }

   # atom:category

   atomCategory =
      element atom:category {
         atomCommonAttributes,
         attribute term { text },
         attribute scheme { atomUri }?,
         attribute label { text }?,
         undefinedContent
      }

   # atom:contributor

   atomContributor = element atom:contributor { atomPersonConstruct }

   # atom:generator

   atomGenerator = element atom:generator {
      atomCommonAttributes,
      attribute uri { atomUri }?,
      attribute version { text }?,
      text
   }

   # atom:icon

   atomIcon = element atom:icon {
      atomCommonAttributes,
      (atomUri)
   }

   # atom:id

   atomId = element atom:id {
      atomCommonAttributes,
      (atomUri)
   }

   # atom:logo

   atomLogo = element atom:logo {
      atomCommonAttributes,
      (atomUri)
   }

   # atom:link

   atomLink =
      element atom:link {
         atomCommonAttributes,
         attribute href { atomUri },
         attribute rel { atomNCName | atomUri }?,
         attribute type { atomMediaType }?,
         attribute hreflang { atomLanguageTag }?,
         attribute title { text }?,
         attribute length { text }?,
         undefinedContent
      }

   # atom:published

   atomPublished = element atom:published { atomDateConstruct }

   # atom:rights

   atomRights = element atom:rights { atomTextConstruct }

   # atom:source

   atomSource =
      element atom:source {
         atomCommonAttributes,
         (atomAuthor*
          & atomCategory*
          & atomContributor*
          & atomGenerator?
          & atomIcon?
          & atomId?
          & atomLink*
          & atomLogo?
          & atomRights?
          & atomSubtitle?
          & atomTitle?
          & atomUpdated?
          & extensionElement*)
      }

   # atom:subtitle

   atomSubtitle = element atom:subtitle { atomTextConstruct }

   # atom:summary

   atomSummary = element atom:summary { atomTextConstruct }

   # atom:title

   atomTitle = element atom:title { atomTextConstruct }

   # atom:updated

   atomUpdated = element atom:updated { atomDateConstruct }

   # Low-level simple types

   atomNCName = xsd:string { minLength = "1" pattern = "[^:]*" }

   # Whatever a media type is, it contains at least one slash
   atomMediaType = xsd:string { pattern = ".+/.+" }

   # As defined in RFC 3066
   atomLanguageTag = xsd:string {
      pattern = "[A-Za-z]{1,8}(-[A-Za-z0-9]{1,8})*"
   }

   # Unconstrained; it's not entirely clear how IRI fit into
   # xsd:anyURI so let's not try to constrain it here
   atomUri = text

   # Whatever an email address is, it contains at least one @
   atomEmailAddress = xsd:string { pattern = ".+@.+" }

   # Simple Extension

   simpleExtensionElement =
      element * - atom:* {
         text
      }

   # Structured Extension

   structuredExtensionElement =
      element * - atom:* {
         (attribute * { text }+,
            (text|anyElement)*)
       | (attribute * { text }*,
          (text?, anyElement+, (text|anyElement)*))
      }

   # Other Extensibility

   extensionElement =
      simpleExtensionElement | structuredExtensionElement

   undefinedAttribute =
     attribute * - (xml:base | xml:lang | local:*) { text }

   undefinedContent = (text|anyForeignElement)*

   anyElement =
      element * {
         (attribute * { text }
          | text
          | anyElement)*
      }

   anyForeignElement =
      element * - atom:* {
         (attribute * { text }
          | text
          | anyElement)*
      }

   # XHTML

   anyXHTML = element xhtml:* {
      (attribute * { text }
       | text
       | anyXHTML)*
   }

   xhtmlDiv = element xhtml:div {
      (attribute * { text }
       | text
       | anyXHTML)*
   }

   # EOF

Coordonnées des auteurs

Remerciements

Le fonctionnement du RFC Editor est financé actuellement par l'Internet Society.