Bon d'échange XML : langage générique des bons d'échange

Statut de ce mémoire

Le présent mémoire donne des informations pour la communauté de l'Internet. Il ne spécifie aucune sorte de norme de l'Internet. La distribution du présent mémoire n'est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2005).

Résumé

Le présent document spécifie les règles de définition des propriétés d'un bon d'échange dans la syntaxe XML. Un bon d'échange est une entité logique qui représente un droit de réclamer des biens ou des services. Un bon d'échange peut être utilisé pour transférer une large gamme de valeurs électroniques, y compris des coupons, tickets, points de fidélité, et certificats de dons, qui doivent souvent être traités dans le cours d'un payement et/ou de transactions de livraison.

1. Introduction

Le présent document spécifie les règles pour définir les propriétés des bons d'échange dans la syntaxe XML. Les motivations et les fondements de la spécification sont décrits dans la [RFC3506].

Un bon d'échange est une entité logique qui représente un certain droit et il est géré logiquement par le système de circulation des bons d'échange (VTS, Voucher Trading System). Un bon d'échange (voucher) est généré par le producteur (issuer), diffusé aux utilisateurs, et finalement collecté par le collecteur qui utilise le VTS.

Le présent document définit la syntaxe et la sémantique du composant du bon d'échange, qui définit la signification et les règles de traitement des bons d'échange dans la syntaxe XML [XML]. Un composant de bon d'échange définit les propriétés qui doivent être satisfaites pour permettre au bon d'échange d'être traité par le VTS ou autre système commercial ; par exemple, un portefeuille ou un système d'échange. Les définitions et modèles de VTS sont aussi définis dans la [RFC3506].

Note: Le présent document utilise "bon d'échange" comme une "instance de bon d'échange", dont la signification est définie par le composant de bon d'échange. En d'autres termes, un composant de bon d'échange N'EST PAS un bon d'échange, et plusieurs bons d'échange peuvent être produits et gérés par le VTS en utilisant le même composant de bon d'échange.

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].

2. Modèle de traitement

Il y a plusieurs façons de mettre en œuvre le VTS et les technologies changent continuellement. Pour les coupons de réduction ou les tickets d'événements, par exemple, le VTS hors ligne fondé sur la carte de crédit est souvent préféré, tandis que pour les bonds ou titres, le VTS centralisé en ligne est préféré. Il n'est pas possible de définir pour l'instant des protocoles standard pour produire, transférer, ou rembourser des bons d'échange.

Pour assurer la souplesse de mise en œuvre, le présent document suppose une architecture modulaire de portefeuille qui permet à plusieurs VTS d'être ajoutés en batterie. Dans cette architecture, au lieu de spécifier un protocole standard de transfert de bons d'échange, deux spécifications, composant de bons d"échange et VTS-API, sont normalisées (Figure 1).

Après que l'envoyeur et le receveur se sont mis d'accord sur quels bons d'échange sont en affaires et quel VTS sera utilisé, le système producteur ou le système de portefeuille demande à la batterie de VTS correspondante de permettre que la production, le transfert, ou les transactions de remboursement soient effectuées via l'API de VTS. Le VTS retranscrit alors la propriété des bons d'échange en utilisant le protocole spécifique du VTS. Finalement, un événement d'achèvement est envoyé aux systèmes de portefeuille ou aux systèmes de production/collecte.

Le présent document décrit la spécification de composant de bon d'échange. La spécification d'API VTS est définie par la [RFC4154].

Syst. portef./prod. envoyeur Syst. portef./collecte receveur

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

| | | |

| | Composant Bon d'échange | |

| | (Spécifie le fournisseur et promesse de VTS) | |

| |-------------------------------------------------------->| |

| | | | | |

| | Intention de recevoir et payer (option) | |

| |<- - - - - - - - - - - - - - - - - - - - - - - - - - - - | |

| | | | | |

| | extension | | extension | |

| | Demande produc/ VTS | | VTS Enregistre | |

| | transfert/rembours | | écoutant(*1)| |

| |------------------>| | | |<------------------| |

| | (VTS-API) |<- - - - - - - ->| (VTS-API) | |

| | | VTS-specific | | |

| | | protocol if VTS | | |

| | | is distributed | | |

| | Résultat |<- - - - - - - ->| Notifie(*2) | |

| |<------------------| | | |------------------>| |

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

(*1) L'enregistrement est facultatif. Noter aussi que les extensions logicielles de VTS sont généralement pré enregistrées lors du démarrage du portefeuille ou système de collecte.

(*2) Si un écoutant est enregistré.

Figure 1 : Architecture de portefeuille avec extensions logicielles de VTS

3. Modèle de confiance

Un bon d'échange est de confiance si le fournisseur et le producteur du VTS sont de confiance, car le fournisseur est responsable du contenu du bon d'échange et le producteur de VTS est responsable d'empêcher que la propriété en soit attribuée à plusieurs utilisateurs.

Le niveau de confiance requis pour le fournisseur et le producteur du VTS dépend du type (ou des promesses) du bon d'échange. Pour fournir les informations nécessaires à la vérification, les conditions du fournisseur et du producteur du VTS sont spécifiées dans le composant du bon d'échange et sont données en entrée au vérificateur ; par exemple, un système de portefeuille ou autre logiciel. La confiance dans un bon d'échange est donc vérifiée au moyen du composant de bon d'échange. Ce modèle permet aux partenaires commerciaux de vérifier leur confiance dans le bon d'échange sans considération de leur confiance dans les partenaires.

Le présent document suppose que le composant de bon d'échange est la racine de la confiance. Si un utilisateur malveillant pouvait altérer le composant de bon d'échange, un bon d'échange falsifié pourrait être vérifié comme valide.

Quand un composant de bon d'échange est délivré du producteur de confiance de VTS, du fournisseur, ou d'un tiers de confiance, un canal de communication sûr (par exemple, [RFC2246], [RFC2411], ou la sécurité d'objet, comme dans la [RFC3275]) devrait être utilisé pour empêcher l'altération durant la livraison.

Note : le composant de bon d'échange n'a pas à être envoyé à partir de l'envoyeur du bon d'échange. Noter aussi qu'un ensemble de composants de bon d'échange de confiance peut être téléchargé avant la conduite d'une transaction.

4. Structure de composant

Le composant de bon d'échange apporte les informations nécessaires pour identifier la valeur monétaire ou marchande rendue quand le bon d'échange est remboursé. Il inclut :

o quelle valeur/éléments peuvent être réclamés en échange du bon d'échange, et

o les restrictions appliquées au bon d'échange

- participants (producteur de VTS, fournisseur, détenteur, et collecteur),

- objets (marchandise) à réclamer,

- période de validité,

- et autres.

Le composant de bon d'échange donne aussi les propriétés communes utiles pour afficher et manipuler le contenu des systèmes de portefeuille. Cela inclut le titre et la description de chaque bon d'échange.

Le composant de bon d'échange contient les composants suivants :

Titre du composant : donne le titre du bon d'échange. C'est principalement la liste des entités mémorisées dans un système de portefeuille.

Composant de description : donne une courte description du bon d'échange. C'est principalement pour faire la liste des entités mémorisées dans un système de portefeuille.

Composant producteur : donne les restrictions que met le producteur du VTS (ou module d'extension de VTS) à l'utilisation de la commercialisation du bon d'échange.

Composant fournisseur : donne les restrictions sur le fournisseur du bon d'échange.

Composant détenteur : donne les restrictions quant au détenteur du bon d'échange.

Composant collecteur : donne les restrictions quant au collecteur du bon d'échange.

Composant valeur : donne la valeur de chaque bon d'échange. Il y a deux types de valeurs : valeurs fixes et ratio. Pour une valeur fixe, la monnaie et son montant sont spécifiés. Pour un ratio, le taux de rabais de la marchandise correspondante est spécifié. Le composant valeur indique aussi le nombre de bons d'échange à rembourser pour réclamer la marchandise ou la valeur monétaire spécifiée dans le composant marchandise ou le composant Valeur. Si "n" (>0) est spécifié, la marchandise ou valeur monétaire peut être réclamée en échange pour "n feuilles de" bon d'échange. Si "0" est spécifié, il peut être utilisé de façon répétée.

Composant marchandise : donne des restrictions quant à l'objet à réclamer. La signification spécifique du domaine du bon d'échange (par exemple, numéro de référence de la marchandise ou numéro de siège pour un ticket d'événement) est spécifiée pour identifier la marchandise rendue quand le bon d'échange est remboursé.

Composant période de validité : donne des restrictions quant à la période de validité du bon d'échange ; c'est-à-dire la date de début et la date de fin.

Composant condition : donne toutes les autres restrictions applicables. C'est destiné à couvrir les contrats entre le fournisseur et le détenteur du bon d'échange sous forme de langage naturel.

En utilisant les composants ci-dessus, la sémantique des divers types de bons d'échange peut être définie comme le montre le Tableau 1.

Tableau 1 : Exemples de vouchers et leurs propriétés

5. Vue d'ensemble de la syntaxe et exemples

Cette section donne une vue d'ensemble et des exemples de composants de bon d'échange. La syntaxe formelle et la sémantique se trouvent aux Sections 6 et 7.

Les composants de bon d'échange sont représentés par l'élément <Voucher>, qui a la structure suivante (où "?" note zéro ou une occurrence) :

<Voucher>

(Titre)

(Description)?

(Producteur)

(Fournisseur)?

(Détenteur)?

(Collecteur)?

(Valeur)

(Marchandise)?

(Période de validité)?

(Conditions)?

</Voucher>

Un exemple d'un composant de bon d'échange est décrit ci-dessous. C'est l'exemple d'un coupon de rabais de cinq dollars pour une marchandise spécifique, un livre de numéro ISBN 0071355014. Le coupon est valide du 1er avril 2001 au 31 mars 2002. Pour réclamer cette offre, un bon d'échange doit être dépensé.

<?xml version="1.0" encoding="UTF-8"?>

<Voucher xmlns="urn:ietf:params:xml:ns:vts-lang"

xmlns:vts="http://www.exemple.com/vts">

<Titre>Coupon livre IOTP</Titre>

<Description>$5 sur le livre IOTP</Description>

<Nom producteur="Voucher Exchanger 2002">

<vts:Version>VE2.31</vts:Version>

</Producteur>

<Nom fournisseur="Alice Book Center, Ltd.">

<vts:KeyInfo>

1DA8DFCF95521014BBB7171B95545E8D61AE803F

</vts:KeyInfo>

</Fournisseur>

<Nom collecteur="Alice Book Center, Ltd."/>

<Type valeur="rabais" dépensé="1">

<Montant fixe="5" monnaie="USD"/>

</Valeur>

<Marchandise>

<bk:Book xmlns:bk="http://www.exemple.com/bk"

bk:isbn="0071355014"/>

</Marchandise>

<Début périodeValidité="2002-04-01" fin="2003-03-31"/>

<Conditions>

La valeur de ce coupon est soumise à l'impôt.

</Conditions>

</Voucher>

6. Syntaxe et sémantique

La structure générale d'un composant de bon d'échange XML est décrite à la Section 4. Cette section détaille les caractéristiques du composant de bon d'échange. Les caractéristiques décrites dans cette section DOIVENT être mises en œuvre sauf indication contraire. La syntaxe est définie via [XML-Schema-1], [XML-Schema-2]. On précise que les éléments non qualifiés dans les définitions de schémas sont dans l'espace de nom de schéma XML :

xmlns="http://www.w3.org/2001/XMLSchema"

Les références au schéma de bon d'échange XML défini ici utilisent le préfixe "gvl" et sont dans l'espace de noms :

xmlns:gvl="urn:ietf:params:xml:ns:vts-lang"

Cet URI d'espace de noms pour les éléments définis par le présent document est un URN [RFC2141] qui utilise l'identifiant d'espace de nom 'ietf', défini par la [RFC2648] et étendu par la [RFC3688].

Cet espace de noms est aussi utilisé pour des éléments non qualifiés dans les exemples de bon d'échange.

6.1 <Voucher>

L'élément <Voucher> contient les éléments <Titre>, <Producteur>, et <Valeur> et contient facultativement les éléments <Description>, <Fournisseur>, <Détenteur>, <Collecteur>, <PériodeValidité>, et <Condition>. Ces sous éléments sont définis dans les paragraphes qui suivent.

L'élément <Voucher> est défini par le schéma suivant :

<nom d'élément="Voucher" type="gvl:VoucherType"/>

<nom complexType="VoucherType">

<sequence> <element ref="gvl:Titre"/>

<element ref="gvl:Description" minOccurs="0"/>

<element ref="gvl:Producteur"/>

<element ref="gvl:Fournisseur" minOccurs="0"/>

<element ref="gvl:Détenteur" minOccurs="0"/>

<element ref="gvl:Collecteur" minOccurs="0"/>

<element ref="gvl:Valeur"/>

<element ref="gvl:Marchandise" minOccurs="0"/>

<element ref="gvl:PériodeValidité" minOccurs="0"/>

<element ref="gvl:Conditions" minOccurs="0"/>

</sequence>

</complexType>

6.2 <Titre>

L'élément <Titre> contient un titre en simple texte du bon d'échange. C'est principalement pour faire la liste des entités mémorisées dans un système de portefeuille.

L'élément <Titre> n'a pas d'attribut.

L'élément <Titre> est défini par le schéma suivant :

<nom d'élément="Titre" type="chaîne"/>

6.3 <Description>

L'élément <Description> contient une description en simple texte du bon d'échange. C'est principalement pour faire la liste des entités mémorisées dans un système de portefeuille.

L'élément <Description> n'a pas d'attribut.

L'élément <Description> est défini par le schéma suivant :

<nom d'élément="Description" type="chaîne"/>

6.4 <Producteur>

L'élément <Producteur> peut contenir tout élément utilisé pour spécifier ou restreindre le producteur de VTS du bon d'échange. Les sous éléments contenus dans cet élément dépendent de la mise en œuvre du VTS.

Une mise en œuvre d'un système de portefeuille peut utiliser ces informations pour identifier et/ou authentifier le producteur de VTS lorsque l'extension de VTS est enregistrée (voir la Section 7 de la [RFC4154]). Ces éléments spécifiques de la mise en œuvre du VTS peuvent être étendus en utilisant [XML-ns]. Un exemple d'une telle définition de schéma est décrite à la Section 8.

L'élément <Producteur> a un attribut "nom" de type chaîne qui est utilisé pour spécifier le nom du producteur de VTS.

L'élément <Producteur> est défini par le schéma suivant :

<nom d'élément="Producteur" type="gvl:RoleType"/>

<nom complexType="RoleType" mixte="vrai">

<sequence>

<tout espace de noms="##tout" minOccurs="0" maxOccurs="sans limite"/>

</sequence>

<nom d'attribut="nom" type="chaîne"/>

</complexType>

6.5 <fournisseur>

L'élément <fournisseur> peut contenir tout élément utilisé pour spécifier ou restreindre le fournisseur du bon d'échange.

Le fournisseur du bon d'échange est généralement géré par le VTS [RFC4154]. Il n'est pas nécessaire de spécifier le fournisseur du bon d'échange en utilisant cet élément si il n'y a pas de restriction sur le fournisseur.

Une mise en œuvre d'un VTS peut utiliser cet élément pour décrire les données d'authentification et/ou les informations de qualification du fournisseur. Ces informations spécifiques de la mise en œuvre peuvent être étendues par des sous éléments avec [XML-ns]. Un exemple d'une telle définition de schéma est décrit à la Section 8.

L'élément <fournisseur> a un attribut "nom" de type chaîne qui est utilisé pour spécifier le nom du fournisseur.

L'élément <fournisseur> est défini par le schéma suivant :

<nom d'élément="fournisseur" type="gvl:RoleType"/>

Le type d'élément <RoleType> est défini au paragraphe 6.4.

Si l'élément <Fournisseur> est omis, cela DOIT être interprété comme l'absence de restriction sur le fournisseur.

6.6 <Détenteur>

L'élément <Détenteur> peut contenir tout élément utilisé pour spécifier ou restreindre le détenteur du bon d'échange.

Le détenteur du bon d'échange est généralement géré par le VTS [RFC4154]. Il n'est pas nécessaire de spécifier le détenteur du bon d'échange en utilisant cet élément si il n'y a pas de restriction sur le détenteur.

Une mise en œuvre d'un VTS peut utiliser cet élément pour décrire les données d'authentification et/ou les informations de qualification du détenteur. Ces informations spécifiques de la mise en œuvre peuvent être étendues par des sous éléments avec [XML-ns].

L'élément <Détenteur> a un attribut "nom" de type chaîne qui est utilisé pour spécifier le nom du détenteur.

L'élément <Détenteur> est défini par le schéma suivant :

<nom d'élément ="Détenteur" type="gvl:RoleType"/>

Le type d'élément <RoleType> est défini au paragraphe 6.4.

Si l'élément <Détenteur> est omis, cela DOIT être interprété comme l'absence de restriction sur le détenteur.

6.7 <Collecteur>

L'élément <Collecteur> peut contenir tout élément utilisé pour spécifier ou restreindre le collecteur du bon d'échange. Il n'est pas nécessaire de spécifier le collecteur du bon d'échange avec cet élément si il n'y a pas de restriction sur le collecteur.

Une mise en œuvre de VTS peut utiliser cet élément pour décrire les données d'authentification et/ou les informations de qualification du collecteur. Ces informations spécifiques de la mise en œuvre peuvent être étendues par des sous éléments avec [XML-ns].

L'élément <Collecteur> a un attribut "nom" de type chaîne qui est utilisé pour spécifier le nom du collecteur.

L'élément <Collecteur> est défini par le schéma suivant:

<nom d'élément="Collecteur" type="gvl:RoleType"/>

Le type d'élément <RoleType> est défini au paragraphe 6.4.

Si l'élément <Collecteur> est omis, cela DOIT être interprété comme l'absence de restriction sur le collecteur.

6.8 <Valeur>

L'élément <Valeur> contient facultativement un élément <Fixe> ou <Ratio> mais pas les deux. Ces sous éléments sont définis dans les paragraphes qui suivent.

L'élément <Valeur> a un attribut "type" qui est utilisé pour spécifier le type de traitement de la valeur. Cet attribut est fourni pour calculer le montant payé lorsque les bons d'échange sont remboursés dans une boutique, etc.

Les identifiants suivants sont définis pour l'attribut "type".

Échange : les articles spécifiés dans l'élément <Marchandise> peuvent être réclamés en échange du bon d'échange. Si ce type est choisi, ni l'élément <Ratio> ni l'élément <Fixe> NE DOIVENT être spécifiés. Noter que ce type de traitement de valeur a la même signification que :

<Type de valeur="Rabais"><Pourcentage="100"/></Valeur>

Rabais : les articles spécifiés dans l'élément <Marchandise> peuvent être acquis au prix rabaissé calculé par l'élément <Ratio> ou <Fixe>.

Monétaire : les articles spécifiés dans l'élément <Marchandise> peuvent être acquis en utilisant la valeur du bon d'échange. (Note : si l'élément <Marchandise> n'est pas spécifié, le bon d'échange peut être utilisé pour tout achat.) Si ce type est choisi, l'élément <Fixe> DOIT être spécifié.

L'élément <Valeur> a aussi un attribut "dépensé" qui est utilisé pour spécifier le nombre de bons d'échange à restituer pour réclamer les biens, services, ou valeur monétaire spécifiée. Par exemple, si "n" (>0) est spécifié, les biens peuvent être réclamés dans l'échange de "n feuilles de" bon d'échange. (Note : plusieurs bons d'échange pour le même composant de bon d'échange doivent exister dans ce cas.) Si "0" est spécifié, il peut être utilisé de façon répétée.

Si l'attribut "dépensé" ou l'élément entier est omis, cela DOIT être interprété comme la spécification de "1" pour l'attribut "dépensé".

L'élément <Valeur> est défini par le schéma: suivant :

<nom d'élément="Valeur" type="gvl:ValueType"/>

<nom complexType="ValueType">

<sequence minOccurs="0">

<choix>

<nom d'élément="Ratio" type="gvl:RatioValueType"/>

<nom d'élément="Fixe" type="gvl:FixedValueType"/>

</choix>

</sequence>

<nom d'attribut="type" type="gvl:ValueProcessType" usage="exigé"/>

<nom d'attribut="dépensé" type="nonNegativeInteger" défaut="1"/>

</complexType>

Le type d'élément <ValueProcessType> est défini par le schéma suivant :

<simpleType name="ValueProcessType">

<restriction base="chaîne">

<valeur d'énumération="échange"/>

<valeur d'énumération="rabais"/>

<valeur d'énumération="monétaire"/>

</restriction>

</simpleType>

6.8.1 <Ratio>

L'élément <Ratio> n'a pas de contenu.

L'élément <Ratio> a un attribut "pourcentage" qui est utilisé pour spécifier le taux de rabais sur le prix de la marchandise correspondante en pourcentage.

Le type d'élément <RatioValueType> est défini par le schéma suivant :

<complexType name="RatioValueType">

<nom d'attribut="pourcentage" use="exigé">

<simpleType>

<restriction base="float">

<valeur maxInclusive="100"/>

</restriction>

</simpleType>

</attribut>

</complexType>

6.8.2 <Fixe>

L'élément <Fixe> n'a pas de contenu.

L'élément <Fixe> a des attributs "Devise" et "Montant" et facultativement un attribut "Nombredecimal" comme suit :

Devise : donne l'unité de la valeur monétaire dans le code des monnaies à trois lettres de l'ISO [ISO4217]. Par exemple, le dollar américain est "USD".

Montant : donne la quantité de la valeur monétaire par bon d'échange.

Nombredecimal : donne le nombre de chiffres de décimales après la virgule qui est appliqué à la base de l'attribut "Montant" ci-dessus. Si l'attribut "Nombredecimal" est omis, cela DOIT être interprété comme la spécification de "0" pour l'attribut "Nombredecimal".

Par exemple, avec une monnaie dollar désignée en cents, "1" est spécifié pour l'attribut "Montant" , et "-2" est spécifié pour l'attribut "Nombredecimal". Autrement, "0,01" est spécifié pour l'attribut "Montant", et l'attribut "Nombredecimal" est omis.

Le type <FixedValueType> est défini comme suit :

<nom complexType="FixedValueType">

<nom d'attribut="devise" type="chaîne" usage="exigé"/>

<nom d'attribut="montant" type="float" usage="exigé"/>

<nom d'attribut="NombreDecimal" type="court" defaut="0"/>

</complexType>

6.9 <Marchandise>

L'élément <Marchandise> peut contenir tout élément utilisé pour spécifier ou restreindre les biens ou services rendus lorsque le bon d'échange est restitué. Les sous éléments contenus dans cet élément dépendent de l'application de bon d'échange et relèvent des spécifications particulières d'autres domaines. Les éléments spécifiques du domaine peuvent être étendus par des sous éléments utilisant [XML-ns].

Cet élément est destiné à être interprété par un système de collecte. Une mise en œuvre d'un système de portefeuille n'a pas à utiliser cet élément. Toutes les restrictions appliquées devraient aussi être décrites dans l'élément <Description> ou <Conditions> en langage naturel pour permettre aux usagers de vérifier les restrictions.

L'élément <Marchandise> n'a aucun attribut.

L'élément <Marchandise> est défini par le schéma suivant :

<nom d'élément="Marchandise" type="gvl:MerchandiseType"/>

<nom complexType="MerchandiseType" mixte="vrai">

<sequence>

<any namespace="##any" minOccurs="0" maxOccurs="sans limite"/>

</sequence>

</complexType>

6.10 <PériodeValidité>

L'élément <PériodeValidité> n'a pas de contenu.

L'élément <PériodeValidité> a les attributs de type date et heure "début" et "fin" qui sont utilisés pour mettre des limites à la validité du bon d'échange.

L'élément <ValidPeriod> est défini par le schéma suivant :

<nom d'élément="ValidPeriod" type="gvl:ValidPeriodType"/>

<nom complexType="ValidPeriodType">

<nom d'attribut="début" type="dateHeure"/>

<nom d'attribut="fin" type="dateHeure"/>

</complexType>

Si l'attribut "début" est omis, cela DOIT être interprété comme signifiant que le bon d'échange est valide à tout moment jusqu'à celui spécifié par l'attribut de fin (inclus). Si l'attribut "fin" est omis, cela DOIT être interprété comme signifiant que le bon d'échange est valide à partir de d'attribut de début sans date d'expiration. Si aucun des deux attributs n'est spécifié ou si l'élément entier est omis, cela DOIT être interprété comme signifiant que le bon d'échange est tout le temps valide.

6.11 <Conditions>

L'élément <Conditions> contient toutes les autres restrictions ou conditions appliquées. Cela est destiné à couvrir les contrats entre le fournisseur et le détenteur du bon d'échange sous forme de langage naturel.

Une mise en œuvre d'un système de portefeuille DEVRAIT fournir un moyen d'affichage du texte de cet élément.

L'élément <Conditions> n'a pas d'attribut.

L'élément <Conditions> est défini par le schéma suivant :

<nom d'élément="Conditions" type="chaîne"/>

7. Considérations relatives à l'IANA

Le présent document utilise des URN pour décrire des espaces de noms XML et des schémas XML se conformant à un mécanisme de registre décrit dans la [RFC3688]. L'IANA a enregistré deux allocations d'URI.

Demande d'enregistrement pour l'espace de noms vts-lang :

URI : urn:ietf:params:xml:ns:vts-lang

Contact de l'enregistrant : voir la section "Adresse des auteurs" du présent document.

XML : aucun. Les URI d'espace de noms ne représentent pas une spécification XML.

Demande d'enregistrement pour le schéma XML vts-lang :

URI : urn:ietf:params:xml:schema:vts-lang

Contact de l'enregistrant : voir la section "Adresse des auteurs" du présent document.

XML:

DÉBUT

<?xml version="1.0" encoding="UTF-8"?>

<schema

targetNamespace="urn:ietf:params:xml:ns:vts-lang"

xmlns:gvl="urn:ietf:params:xml:ns:vts-lang"

xmlns="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<element name="Voucher" type="gvl:VoucherType"/>

<complexType name="VoucherType">

<sequence>

<element ref="gvl:Title"/>

<element ref="gvl:Description" minOccurs="0"/>

<element ref="gvl:Provider"/>

<element ref="gvl:Issuer" minOccurs="0"/>

<element ref="gvl:Holder" minOccurs="0"/>

<element ref="gvl:Collector" minOccurs="0"/>

<element ref="gvl:Value"/>

<element ref="gvl:Merchandise" minOccurs="0"/>

<element ref="gvl:ValidPeriod" minOccurs="0"/>

<element ref="gvl:Conditions" minOccurs="0"/>

</sequence>

</complexType>

<element name="Title" type="string"/>

<element name="Description" type="string"/>

<element name="Provider" type="gvl:RoleType"/>

<element name="Issuer" type="gvl:RoleType"/>

<element name="Holder" type="gvl:RoleType"/>

<element name="Collector" type="gvl:RoleType"/>

<complexType name="RoleType" mixed="true">

<sequence>

<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</sequence>

<attribute name="name" type="string"/>

</complexType>

<element name="Value" type="gvl:ValueType"/>

<complexType name="ValueType">

<sequence minOccurs="0">

<choice>

<element name="Ratio" type="gvl:RatioValueType"/>

<element name="Fixed" type="gvl:FixedValueType"/>

</choice>

</sequence>

<attribute name="type" type="gvl:ValueProcessType" use="required"/>

<attribute name="spend" type="nonNegativeInteger" default="1"/>

</complexType>

<simpleType name="ValueProcessType">

<restriction base="string">

<enumeration value="exchange"/>

<enumeration value="discount"/>

<enumeration value="monetary"/>

</restriction>

</simpleType>

<complexType name="RatioValueType">

<attribute name="percentage" use="required">

<simpleType>

<restriction base="float">

<maxInclusive value="100"/>

</restriction>

</simpleType>

</attribute>

</complexType>

<complexType name="FixedValueType">

<attribute name="currency" type="string" use="required"/>

<attribute name="amount" type="float" use="required"/>

<attribute name="decimalPower" type="short" default="0"/> </complexType>

<element name="Merchandise" type="gvl:MerchandiseType"/>

<complexType name="MerchandiseType" mixed="true">

<sequence>

<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>

</sequence>

</complexType>

<element name="ValidPeriod" type="gvl:ValidPeriodType"/>

<complexType name="ValidPeriodType">

<attribute name="start" type="dateTime"/>

<attribute name="end" type="dateTime"/>

</complexType>

<element name="Conditions" type="string"/>

</schema>

FIN

8. Exemple de schéma VTS

Un exemple de définition de schéma pour une mise en œuvre de VTS est décrit ci-dessous.

<?xml version="1.0"?>

<schema

targetNamespace="http://www.exemple.com/vts"

xmlns:vts="http://www.exemple.com/vts"

xmlns="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<element name="Version" type="string"/>

<element name="KeyInfo" type="hexBinary"/>

</schema>

Avec cette définition de schéma, le <vts:Version> peut être utilisé pour spécifier le numéro de version de VTS, et l'élément <vts:KeyInfo> peut être utilisé pour spécifier le fournisseur dans le composant de bon d'échange, comme indiqué Section 5.

9. Considérations pour la sécurité

Le VTS doit fournir des moyens pour empêcher la falsification, l'altération, la restitution dupliquée, la reproduction d'un bon d'échange, et la non répudiation des transactions, comme décrit au paragraphe 3.2 de la [RFC3506]. Cela va généralement exiger la présence d'un numéro de série univoque ou équivalent dans chaque instance de bon d'échange, généralement en dehors du composant de bon d'échange. Ces exigences de sécurité suivent cependant principalement les extensions logicielles de VTS et leurs protocoles. Le présent document suppose que les extensions logicielles de VTS sont de confiance et qu'elles sont installées par des moyens (par exemple, manuellement) qui sont vérifiés comme les autres applications téléchargées.

Cependant le composant de bon d'échange définit des restrictions sur le fournisseur de VTS (ou sur les extensions logicielles de VTS) et si ces informations sont altérées, des extensions logicielles incorrectes de VTS non acceptées par le producteur pourraient être utilisées, permettant qu'un bon d'échange falsifié soit vérifié comme si il était valide. Pour empêcher cette situation, le composant de bon d'échange devrait être mémorisé et acquis de façon sûre ; par exemple, téléchargé d'un tiers de confiance en utilisant un canal de communication sécurisé, comme selon la [RFC2246] ou la [RFC2411], ou sécurisé par la signature numérique d'une personne de confiance [RFC3275].

10. Remerciements

Les personnes suivantes, par ordre alphabétique, ont contribué de façon substantielle au présent document : Ian Grigg, Renato Iannella, Yoshiaki Nakajima.

11. Références normatives

[ISO4217] "Codes pour la représentation des monnaies", ISO 4217, 1995.

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

[RFC2141] R. Moats, "Syntaxe des URN", mai 1997. (Obsolète, voir RFC8141)

[RFC2648] R. Moats, "Espace de nom d'URN pour les documents de l'IETF", août 1999. (Information)

[RFC3688] M. Mealling, "Registre XML de l'IETF", BCP 81, janvier 2004.

[XML] "Extensible Mark Up Language (XML) 1.0 (Second Edition)", Recommandation W3C, octobre 2000. <http://www.w3.org/TR/REC-xml >

[XML-ns] "Namespaces in XML", Recommandation W3C, janvier 1999. < http://www.w3.org/TR/REC-xml-names >

[XML-Schema-1] Thompson, H., Beech, D., Maloney, M., et N. Mendelsohn, "XML Schema Part 1: Structures", Recommandation W3C, mai 2001. < http://www.w3.org/TR/xmlschema-1/ >

[XML-Schema-2] Biron, P. et A. Malhotra, "XML Schema Part 2: Datatypes", Recommandation W3C, mai 2001. <http://www.w3.org/TR/xmlschema-2/ >

12. Références pour information

[RFC2246] T. Dierks et C. Allen, "Protocole TLS version 1.0", janvier 1999. (P.S. ; MàJ par RFC7919)

[RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "Feuille de route pour la sécurité sur IP", novembre 1998. (Obs., voir RFC6071)

[RFC3275] D. Eastlake 3^rd , J. Reagle, D. Solo, "Syntaxe et traitement de signature en langage de balisage extensible (XML)", mars 2002. (D.S.)

[RFC3506] K. Fujimura, D. Eastlake, "Conceptions et exigences pour le système de circulation des bons d'échange (VTS)", mars 2003. (Info.)

[RFC4154] M. Terada, K. Fujimura, "Interface de programmation d'application du système de circulation des bons d'échange (VTS-API)", septembre 2005. (Information)

Adresse des auteurs

Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2005).

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 y contenues sont fournies sur une base "EN L’ÉTAT" et le contributeur, l’organisation qu’il ou elle représente ou qui le/la finance (s’il en est), la INTERNET SOCIETY et la INTERNET ENGINEERING TASK FORCE déclinent toutes garanties, exprimées ou implicites, y compris mais non limitées à toute garantie que l’utilisation des informations ci-encloses ne violent aucun droit ou aucune garantie implicite de commercialisation ou d’aptitude à un objet particulier.

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 actuellement fourni par la Internet Society.