DTD XML pour carnet d'adresses en accès itinérant

Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé

Le présent document définit la syntaxe et la sémantique des informations à inclure dans l’annuaire des applications d’itinérance. Il comporte les informations nécessaires pour choisir le FAI le plus approprié et pour configurer l’hôte auquel accéder dans le réseau du fournisseur. La spécification consiste en un petit ensemble d’éléments d’information exigés et de diverses extensions possibles. Toutes les données sont spécifiées dans la syntaxe du langage de balisage extensible (XML, Extensible Markup Language) [XML] conduisant à de concises déclarations de type de document (DTD, Document Type Declaration) XML pour l’annuaire.

1. Introduction

Les applications d’itinérance dépendent de la livraison des informations sur les services fournis et les procédures pour connecter le réseau du consortium d’itinérance aux utilisateurs individuels ainsi que des opérateurs des serveurs d’accès réseau, normalement membres du consortium d’itinérance, et le consortium d’itinérance.

"annuaire"

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

| | | ++

| FAI1 | -- | | --+

| | +---+ \ "annuaire"

+------+ \ +------+

+------+ +--+ \_ | | +--+ +------+

| | | ++ | | | ++ | |

| FAI2 | -- | | -->>--- | | --- | | ->> |USAGER|

| | +---+ _ | | +---+ | |

+------+ / | | +------+

+------+ +--+ / +------+

| | | ++ / Consortium

| FAI# | -- | | --+ d’itinérance

| | +---+

+------+

Le consortium d’itinérance assemble à partir des contributions individuelles des fournisseurs qui appartiennent au consortium une version unifiée de l’annuaire pour l’usage des consommateurs. Il est probable que les différents groupes d’utilisateurs obtiennent des versions différentes d’un annuaire adapté à leurs besoins particuliers. Mêmes les usagers peuvent générer des sous-ensembles différents particulièrement adaptés à leurs applications particulières à partir des informations reçues du consortium d’itinérance, par exemple, en restituant seulement les entrées pour un certain pays ou en extrayant tous les points d’accès qui fournissent une connexité sans fil.

Il est donc désirable de définir une structure très portable et bien formée de l’annuaire pour permettre une génération et un post traitement faciles. Les objectifs du présent document incluent :

- de créer un cadre souple, extensible et robuste sur lequel construire un annuaire standard ;

- de promouvoir un format standard d’annuaire, pour améliorer l’interopérabilité entre les FAI et les consortiums d’itinérance ainsi que pour permettre une extraction automatique des données de configuration par une grande diversité d’appareils ;

- de définir une structure compacte contenant les informations essentielles pour l’utilisateur de l’itinérance, pour permettre la mémorisation et une mise à jour facile même sur les petits appareils.

Le présent document n’est pas destiné à créer une solution pléthorique, avec des éléments d’annuaire correspondants à toutes les conditions possibles, ni de définir toutes les sortes de mises à jour d’annuaire ou de protocoles de transfert.

2. Raisons de l’utilisation de XML

XML est rapidement en train de devenir un format standard pour les échanges de données entre applications différentes en prenant aussi en compte le transfert et l’accès aux données sur la Toile. XML est utilisé comme syntaxe pour exprimer la structure et le contenu d’un annuaire de l’itinérance pour permettre un usage et un accès étendus à de nombreuses sortes de supports différents (par exemple, papier, CDROM, www) en utilisant un choix étendu d’appareils d’accès. De plus, XML permet :

- l’extensibilité,

- la souplesse,

- l’intégration dans les annuaires.

L’extensibilité est importante parce que les annuaires sont des documents vivants ; à ce titre, il est improbable que toutes les exigences sémantiques des fournisseurs d’accès Internet (FAI) arbitraires soient satisfaites par un schéma fixe, si bien pensé soit-il. Les concepteurs d’annuaires téléphoniques doivent être libres de créer de nouveaux attributs d’une façon bien comprise pour satisfaire les besoins changeants du monde des affaires.

La souplesse est requise dans la syntaxe de définition d’attribut pour beaucoup des mêmes raisons qu’est nécessaire l’extensibilité de la sémantique. Si on suppose que les concepteurs d’annuaires téléphoniques peuvent avoir besoin de définir des éléments de type arbitraire, la syntaxe choisie doit être capable de représenter de façon propre ces objets de données. Utiliser XML pour décrire le contenu de données de l’annuaire répond bien à cette attente car il peut être utilisé pour décrire sans ambiguïté virtuellement tout type de données.

L’intégration dans les annuaires : bien qu’il soit improbable que les répertoires téléphoniques soient mémorisés dans l’annuaire, pour des considérations de performances, la création de DTD XML décrivant le contenu de répertoires téléphoniques laisse cette option ouverte, avec relativement peu d’efforts supplémentaires nécessaires pour la mettre en œuvre.

3. Spécification des exigences

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

4. Notations de type de valeur pour une frappe plus 'forte'

Les DTD XML n’ont actuellement pas de capacités de 'frappe forte' du contenu des éléments. La seule définition de type prévue dans la spécification de base est "#PCDATA", 'données de caractère analysable'. Cela pourrait être suffisant et est utilisé tout au long du présent document pour définir les éléments qui contiennent les informations principalement destinées à être interprétées par les humains.

Pour permettre une description plus concise du contenu d’un élément particulier, plusieurs notations de type de valeur sont introduites. Cela permet une description de type plus détaillée du contenu des éléments dans les cas où cela semble souhaitable.

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

<!--déclarations de notation de type de valeur de Phone book -->

<!NOTATION FQDN PUBLIC "-//IETF/roamPhoneBook/NOTATIONvalue Type Fully_qualified_domain_name">

<!NOTATION IPADR PUBLIC "-//IETF/roamPhoneBook/NOTATIONvalue Type IP_address">

<!NOTATION B64JPG PUBLIC "-//IETF/roamPhoneBook/NOTATIONvalue Type Base64_encoded_jpeg_image">

<!NOTATION B64GIF PUBLIC "-//IETF/roamPhoneBook/NOTATIONvalue Type Base64_encoded_gif_image">

5. Définitions d’élément conteneur

1. 5.1 PhoneBook

L’élément phoneBook est le conteneur de base des entrées de répertoire téléphonique. Il a deux attributs, un nom de répertoire téléphonique et un numéro de version de répertoire téléphonique (qui s’applique au répertoire téléphonique pris comme un tout) et contient toujours un ou plusieurs éléments pop. Un élément phoneBook peut seulement contenir plusieurs éléments Setup, Support et Provider, si il est référencé qu’il y a plus d’un élément pop.

Syntaxe :

<!ELEMENT phoneBook (

pop+,

setup*,

support*,

provider*)>

<!ATTLIST phoneBook

name CDATA #REQUIRED

version CDATA #REQUIRED >

phoneBook

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

| phoneBookName (req)|

| phoneBookVersion (req)|

| +-----------------------+ |

| | pop |+ (req)|

| +-----------------------+| |

| + - - - - - - - - - - - + |

| |

| + - - - - - - - - - - - + |

| | setup |+ (opt)|

| + - - - - - - - - - - - +| |

| + - - - - - - - - - - - + |

| |

| + - - - - - - - - - - - + |

| | support |+ (opt)|

| + - - - - - - - - - - - +| |

| + - - - - - - - - - - - + |

| |

| + - - - - - - - - - - - + |

| | provider |+ (opt)|

| + - - - - - - - - - - - +| |

| + - - - - - - - - - - - + |

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

1. 5.1.1 Attribut phoneBook "name"

L’attribut phoneBook "name" est une chaîne arbitraire allouée comme identifiant d’un répertoire téléphonique.

2. 5.1.2 Attribut phoneBook "version"

L’attribut phoneBookVersion est un entier qui représente la version du répertoire téléphonique ; c’est un compteur à accroissement monotone qui devrait être incrémenté chaque fois que le répertoire téléphonique est modifié. Cet élément peut être utilisé par un serveur pour aider à décider quelles actions (si il en est) sont nécessaires pour mettre à jour le répertoire téléphonique d’un client. Par exemple, le client peut, au moment de la connexion, envoyer une demande de mise à jour au serveur en incluant dans la demande le numéro de version de son répertoire téléphonique actuel. Si la version du répertoire téléphonique du client n'est pas la même que celle du serveur, celui-ci peut facilement prendre la mesure appropriée, par exemple, répondre par un URL pointant sur un fichier contenant les différences entre les répertoires téléphoniques du client et du serveur.

2. 5.2. POP

L’élément pop contient des éléments d’information qui relèvent des points de présence (POP, point of presence) de réseau individuels. Les éléments d’information requis sont addrFamily, address, media et entryVersion. L’élément media représente les types de supports pris en charge par le POP, tandis que l’élément entryVersion est un entier à croissance monotone qui devrait être incrémenté chaque fois que l’objet est modifié.

Les éléments d’information suivants sont actuellement définis pour l’élément pop. Des éléments d’information supplémentaires pourront être définis par l’IANA à l’avenir.

POP

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

| entryVersion (req)|

| +-------------------------+ |

| | address | (req)|

| +-------------------------+ |

| media (req)|

| minBitsPerSecond (opt)|

| maxBitsPerSecond (opt)|

| "popProperties" (opt)|

| "tunnelingProtocols" (opt)|

| dialScript (opt)|

| pricingInformation (opt)|

| + - - - - - - - - - - - - + |

| | "location" | (opt)|

| + - - - - - - - - - - - - + |

| + - - - - - - - - - - - - + |

| | "popSetup" | (opt)|

| + - - - - - - - - - - - - + |

| + - - - - - - - - - - - - + |

| | "popSupport" | (opt)|

| + - - - - - - - - - - - - + |

| + - - - - - - - - - - - - + |

| | "popProvider" | (opt)|

| + - - - - - - - - - - - - + |

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

Syntaxe :

<!ENTITY % popInformation

"address,

media+,

minBitsPerSecond?,

maxBitsPerSecond?,

popProperty*,

tunnelProto*,

dialScript?,

pricingInformation?,

city?,

region?,

country?,

(setup | setupPtr)?,

(support | supportPtr)?,

(provider |providerPtr)?">

<!ELEMENT pop ( %popInformation; )>

<!ATTLIST pop entryVersion CDATA #REQUIRED>

1. 5.2.1 Attribut pop "entryVersion"

L’attribut entryVersion est un entier qui représente la version de l’objet POP ; c’est un compteur à accroissement monotone qui devrait être incrémenté chaque fois que l’objet est modifié. Cet attribut peut être utile pour fusionner et mettre à jour les répertoires téléphoniques.

3. 5.3 Setup

L’élément Setup comporte des éléments d’information qui décrivent les services qui peuvent changer d’un fournisseur à l’autre ou même d’un POP à l’autre. Certaines des valeurs contenues dans ces éléments d’information peuvent être disponibles par d’autres moyens (par exemple, DHCP) mais peuvent ne pas l’être.

Les éléments d’information suivants sont actuellement définis pour l’élément Setup. Des éléments d’information supplémentaires pourront être définis par l’IANA à l’avenir.

Syntaxe :

<!ENTITY % setupInformation

"dnsServerAddress*,

nntpServerName*,

smtpServerName*,

popServerName*,

imapServerName*,

wwwProxyServerName*,

ftpProxyServerName*,

winsockProxyServerName*,

defaultGatewayAddress?,

userNamePrefix?,

userNameSuffix?">

<!ELEMENT setup ( %setupInformation; )>

<!ATTLIST setup id ID #REQUIRED>

4. 5.4 Support

L’élément Support comporte les éléments d’information qui sont pertinents pour la fourniture de la prise en charge par un usager d’un POP ou d’un fournisseur. Les langages parlés par le personnel du centre de soutien peuvent être spécifiés par plusieurs entrées pour l’attribut valeur de langage.

Des éléments d’information supplémentaires pour l’élément Support pourront être définis par l’IANA à l’avenir.

Syntaxe :

<!ENTITY % supportInformation "(supportTelephoneNumber | supportMailtoURL)+">

<!ELEMENT support %supportInformation; >

<!ATTLIST support id ID #REQUIRED language NMTOKENS #IMPLIED >

5. 5.5 Provider

L’élément Provider contient des éléments d’information relevant des opérations générales d’affaires d’un certain fournisseur de service réseau. Les éléments d’information incluent des choses comme le numéro de téléphone, l’adresse de messagerie, etc., ainsi que les URL pour la messagerie électronique et un site de la Toile mondiale. Un élément Provider peut aussi contenir une référence pour la prise en charge des informations.

Les éléments d’information suivants sont actuellement définis pour l’élément Provider. Des éléments d’information supplémentaires pourront être définis par l’IANA à l’avenir.

Syntaxe :

<!ENTITY % providerInformation

"providerName?,

providerIcon?,

wwwURL?,

generalMailtoURL?,

billingMailtoURL?,

businessCategory?,

x121Address?,

registeredAddress?,

destinationIndicator?,

preferredDeliveryMethod?,

telexNumber?,

teletexTerminalIdentifier?,

telephoneNumber?,

internationalISDNNumber?,

facsimileTelephoneNumber?,

street?,

postOfficeBox?,

postalCode?,

postalAddress?,

physicalDeliveryOfficeName?,

description?,

supportPtr*">

<!ELEMENT provider ( %providerInformation; )>

<!ATTLIST provider id ID #REQUIRED>

6. Définitions des éléments d’information

6. 6.1 Éléments d’information définis pour l’élément POP

   1. 6.1.1 Address

L'élément address donne les informations qui représentent l'adresse du POP. Pour les POP qui offrent accès au réseau téléphonique commuté, l'élément address va au moins contenir une chaîne IA5 qui représente un numéro de téléphone, formaté de façon standard [E.123] (par exemple, "+ 1 234 5678"). Des informations plus détaillées peuvent être disponibles avec des valeurs d'attribut facultatives.

Syntaxe :

<!-- Adresse réseau pour ce POP -->

<!ELEMENT address (#PCDATA)>

1. 6.1.1.1 "Famille" d'attribut address

La famille d'attribut de l'adresse d'élément définit la famille d'adresses à laquelle appartient la valeur d'élément. Pour les POP qui offrent un accès numéroté au réseau, l'attribut addrFamily va généralement contenir une valeur de famille d'adresses fondée sur un réseau téléphonique. Les valeurs d'attribut suivantes sont actuellement définies. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Valeur Description

E164 ITU-T E.164 (PSTN, SMDS, relais de trame, ATM)

X121 ITU-T X.121 (X.25, relais de trame)

Syntaxe :

<!-- Valeurs d'attribut pour famille d'adresses -->

<!ENTITY % addressFamily "(E164|X121)" >

<!ATTLIST address family %addressFamily; #REQUIRED >

2. 6.1.1.2 Attribut d'adresse "countryCode"

L'attribut countryCode indique le préfixe de numéro international du pays dans lequel le POP est situé.

Syntaxe :

<!-- Code UIT de numérotation pour le pays dans lequel ce POP est situé -->

<!ATTLIST address countryCode CDATA #IMPLIED >

3. 6.1.1.3 Attribut d'adresse "areaCode"

L'attribut areaCode contient le composant de code de zone ou de ville du numéro de téléphone dans l'élément 'address' (si il en est un) associé à ce POP.

Syntaxe :

<!-- Code de zone ou de ville du numéro de téléphone dans l'élément accessTelephoneNumber associé à ce POP -->

<!ATTLIST address areaCode CDATA #IMPLIED >

2. 6.1.2 Media

L'élément media est un conteneur qui décrit les types de supports et protocoles en rapport pris en charge par ce POP. Les types de supports suivants sont actuellement définis. Des types supplémentaires pourront être enregistrés par l'IANA à l'avenir.

Valeur Type de support

viaMODEM Modem

viaISDN ISDN

viaATM ATM

viaFR relais de trame

viaX25 X.25

Syntaxe :

<!-- Types de supports acceptés par ce POP -->

<!ENTITY % mediaTypes "(viaMODEM|viaISDN|viaATM|viaFR|viaX25)+" >

<!ELEMENT media %mediaTypes; >

1. 6.1.2.1 Protocoles de modem

L'élément viaMODEM est un élément vide qui représente par son attribut de type facultatif le protocole de modem pris en charge par les appareils d'accès qui peuvent être joints à l'adresse. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus de façon répétée. Les types de protocoles de modem définis initialement sont énumérés dans le tableau ci-dessous. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Valeur Duplex Vitesse Protocole

V21 Full 300 UIT-T V.21

V22 Full 1200 UIT-T V.22

V29 Semi 9600 UIT-T V.29

V32 Full 9600 UIT-T V.32

V32B Full 14,4 k UIT-T V.32bis

V34 Full 28,8 k UIT-T V.34

V34B Full 33,6 k UIT-T V.34bis

V90 Full 56 k UIT-T V.90

Syntaxe :

<!-- Élément type de support modem -->

<!ENTITY % modemProtocols "(V21|V22|V29|V32|V32B|V34|V34B|V90)" >

<!ELEMENT viaMODEM EMPTY>

<!ATTLIST viaMODEM type %modemProtocols; #IMPLIED >

2. 6.1.2.2 Protocoles RNIS

L'élément viaISDN est un élément vide qui représente par son attribut de type facultatif le protocole RNIS pris en charge par les appareils d'accès qui peuvent être joints à cette adresse. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus de façon répétée. Les types de protocoles RNIS définis initialement sont énumérés dans le tableau ci-dessous. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Valeur Vitesse Signification

V110L 19,2 k UIT-T V.110

V110H 38,4 k UIT-T V.110

V120L 56 k UIT-T V.120

V120H 64 k UIT-T V.120

X75 64 k UIT-T X.75

HDLC 64 k RFC 1618

Syntaxe :

<!-- Élément type de support RNIS -->

<!ENTITY % isdnProtocols "(V110L|V110H|V120L|V120H|X75|HDLC)">

<!ELEMENT viaISDN EMPTY>

<!ATTLIST viaISDN type %isdnProtocols; #IMPLIED >

3. 6.1.2.3 Protocoles ATM

L' élément viaATM est un élément vide qui représente par son attribut de type facultatif un protocole particulier accepté par les appareils d'accès qui peuvent être joints à cette adresse. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus de façon répétée. Un seul protocole est défini actuellement. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Syntaxe :

<!-- un élément de type de support ATM -->

<!ENTITY % atmProtocols "(RFC2364)">

<!ELEMENT viaATM EMPTY>

<!ATTLIST viaATM type %atmProtocols; #IMPLIED >

4. 6.1.2.4 Protocoles de relais de trame

L'élément viaFR est un élément vide qui représente par son attribut de type le protocole particulier qui est pris en charge par les appareils d'accès qui peuvent être joints à cette adresse. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus de façon répétée. Un seul protocole est défini actuellement. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Syntaxe :

<!-- un élément de type de support de relais de trame -->

<!ENTITY % frProtocols "(RFC1973)">

<!ELEMENT viaFR EMPTY>

<!ATTLIST viaFR type %frProtocols; #IMPLIED >

5. 6.1.2.5 Protocoles X.25

L'élément viaX.25 est un élément vide qui représente par son attribut de type le protocole particulier qui est pris en charge par les appareils d'accès qui peuvent être joints à cette adresse. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus de façon répétée. Un seul protocole est défini actuellement. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Syntaxe :

<!-- élément de type de support X.25 -->

<!ENTITY % x25Protocols "(RFC1598)">

<!ELEMENT viaX25 EMPTY>

<!ATTLIST viaX25 type %x25Protocols; #IMPLIED >

3. 6.1.3 Taux de données minimum

L'élément minBitsPerSecond indique le taux de données minimum (en bits/seconde) accepté par les appareils d'accès à ce POP.

Syntaxe :

<!-- Taux minimum de données accepté par ce POP en bits/seconde -->

<!ELEMENT minBitsPerSecond (#PCDATA)>

4. 6.1.4 Taux de données maximum

L'élément maxBitsPerSecond indique le taux de données maximum (en bits/seconde) accepté par les appareils d'accès à ce POP.

Syntaxe :

<!-- Taux maximum de données accepté par ce POP en bits/seconde -->

<!ELEMENT maxBitsPerSecond (#PCDATA)>

5. 6.1.5 Propriétés du POP

L'élément popProperty est un élément vide qui représente par sa valeur d'attribut une propriété particulière de ce POP. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus plusieurs fois. Les propriétés définies initialement figurent dans le tableau ci-dessous. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Valeur Propriété

MPPP PPP multi liaisons (RFC1990)

MOBIP IP mobile (RFC2002)

MCRX Réception en diffusion groupée

MCTX Émission en diffusion groupée

Syntaxe :

<!-- Propriété qui caractérise ce POP -->

<!ENTITY % popProperties "(MPPP|MOBIP|MCRX|MCTX)" >

<!ELEMENT popProperty EMPTY>

<!ATTLIST popProperty type %popProperties; #REQUIRED>

6. 6.1.6 Protocoles de tunnelage

L'élément tunnelProto est un élément vide qui représente par son attribut un protocole de tunnelage accepté par ce POP. Pour définir plusieurs protocoles disponibles, cet élément peut être inclus plusieurs fois. Les valeurs définies initialement figurent dans le tableau ci-dessous. Des valeurs supplémentaires pourront être enregistrées par l'IANA à l'avenir.

Valeur Protocole

L2TP RFC 2661 L2TP

PPTP RFC 2637 PPTP

L2F RFC 2341 L2F

ATMP RFC 2107 ATMP

AHT RFC 2402 IP AH en mode tunnel

ESPT RFC 2406 IP ESP en mode tunnel

IPIP RFC 1853 IP-IP

MIP RFC 2004 IP-IP minimal

GRE RFC 1701 GRE

Syntaxe :

<!-- Protocole de tunnelage accepté par ce POP -->

<!ENTITY % tunnelingProtocols "(L2TP|PPTP|L2F|ATMP|AHT|ESPT|IPIP|MIP|GRE)" >

<!ELEMENT tunnelProto EMPTY>

<!ATTLIST tunnelProto type %tunnelingProtocols; #REQUIRED>

7. 6.1.7 Schéma de numérotation

L'élément dialScript contient le schéma de numérotation à utiliser lors de la connexion à ce POP. Le type de valeur d'attribut de dialScript définit le type du schéma qui devrait être utilisé lors de la connexion à ce POP.

Syntaxe :

<!-- Schéma de numérotation à utiliser -->

<!ELEMENT dialScript (#PCDATA)>

<!ATTLIST dialScript type CDATA #IMPLIED >

8. 6.1.8 Informations de tarification

L'élément pricingInformation est une chaîne de forme libre qui représente les informations de tarification pour ce POP. Cela peut être n'importe quoi allant d'une simple chaîne indiquant une dépense relative (par exemple, "$$$$" pour un POP très cher) à un paragraphe décrivant les variables selon l'heure et autres tarifs différenciés.

Syntaxe :

<!-- Informations de tarification pour ce POP -->

<!ELEMENT pricing (#PCDATA)>

9. 6.1.9 City

L'élément city contient le nom de la ville dans laquelle est situé ce POP (et non la ou les villes à partir desquelles il est accessible par un appel local).

Syntaxe :

<!-- Nom de la ville dans laquelle est situé ce POP -->

<!ELEMENT city (#PCDATA)>

10. 6.1.10 Région

L'élément region contient le nom de la région dans laquelle le POP est situé. Aux États Unis, cela serait le nom d'un état ou (pour Washington, D.C.) un district administratif. Dans d'autres pays, cela peut être le nom d'une région, d'une paroisse ou d'un comté.

Syntaxe :

<!-- Nom de la région où est situé ce POP -->

<!ELEMENT region (#PCDATA)>

11. 6.1.11 Pays

L'élément country contient le nom du pays dans lequel est situé le POP. Le nom du pays peut être abrégé (par exemple, "USA" pour les États-Unis d'Amérique ou "UK" pour le Royaume Uni de Grande Bretagne et d'Irlande du Nord) mais si des abréviations sont utilisées, l'usage doit être cohérent au sein du répertoire téléphonique considéré.

Syntaxe :

<!-- Nom du pays dans lequel est situé ce POP -->

<!ELEMENT country (#PCDATA)>

12. 6.1.12 POP Setup

L'élément popSetup est soit un élément d'établissement, si l'établissement est spécifique de ce POP particulier, soit une référence à un des éléments d'établissement donnés dans la portée externe de l'élément phonebook.

Syntaxe :

<!-- Référence des informations d'établissement pour ce POP -->

<!ELEMENT setupPtr EMPTY>

<!ATTLIST setupPtr setupID IDREFS #IMPLIED>

13. 6.1.13 Soutien de POP

L'élément popSupport est soit un élément de soutien, si le soutien est spécifique de ce POP particulier, soit une référence à un des éléments de soutien donnés dans la portée externe de l'élément phonebook.

Syntaxe :

<!-- Référence des informations de soutien pour ce POP -->

<!ELEMENT supportPtr EMPTY>

<!ATTLIST supportPtr supportID IDREFS #IMPLIED>

14. 6.1.14 Fournisseur de POP

L'élément popProvider est soit un élément d'un fournisseur, si les informations de fournisseur sont spécifiques de ce POP particulier, soit une référence à un des éléments de fournisseur donnés dans la portée externe de l'élément phonebook.

Syntaxe :

<!-- Référence des informations de fournisseur pour ce POP -->

<!ELEMENT providerPtr EMPTY>

<!ATTLIST providerPtr providerID IDREFS #IMPLIED>

7. 6.2 Éléments d'information définis pour l'élément Setup

   1. 6.2.1 Adresse du serveur DNS

L'élément dnsServerAddress représente l'adresse IP du serveur du service des noms de domaines (DNS, Domain Name Service) qui devrait être utilisée lors de la connexion à ce POP. L'adresse est représentée sous forme d'une chaîne en notation décimale séparée par des points (par exemple, 192.168.101.1).

Syntaxe :

<!-- Adresse IP du serveur de noms de domaines -->

<!ELEMENT dnsServerAddress (#PCDATA)>

<!ATTLIST dnsServerAddress value NOTATION (IPADR) #IMPLIED>

2. 6.2.2 Nom de serveur NNTP

L'élément nntpServerName contient le nom de domaine pleinement qualifié (FQDN, fully qualified domain name) du serveur du protocole de transfert de nouvelles du réseau (NNTP, Network News Transfer Protocol) qui devrait être utilisé lors d'une connexion à ce POP.

Syntaxe :

<!-- Nom d'un serveur NNTP -->

<!ELEMENT nntpServerName (#PCDATA)>

<!ATTLIST nntpServerName value NOTATION (FQDN) #IMPLIED>

3. 6.2.3 Nom de serveur SMTP

L'élément smtpServerName contient le FQDN d'un serveur du protocole simple de transfert de messagerie (SMTP, Simple Mail Transfer Protocol) qui devrait être utilisé lors d'une connexion à ce POP.

Syntaxe :

<!-- Nom d'un serveur de messagerie SMTP -->

<!ELEMENT smtpServerName (#PCDATA)>

<!ATTLIST smtpServerName value NOTATION (FQDN) #IMPLIED>

4. 6.2.4 Nom de serveur POP3

L'élément popServerName contient le FQDN du serveur du protocole de bureau de poste (POP, Post Office Protocol) qui devrait être utilisé pour une connexion à ce POP.

Syntaxe :

<!-- Nom d'un serveur de messagerie POP3 -->

<!ELEMENT popServerName (#PCDATA)>

<!ATTLIST popServerName value NOTATION (FQDN) #IMPLIED>

5. 6.2.5 Nom de serveur IMAP

L'élément imapServerName contient le FQDN du serveur du protocole d'accès à la messagerie Internet (IMAP, Internet Mail Access Protocol) qui devrait être utilisé pour se connecter à ce POP.

Syntaxe :

<!-- Nom d'un serveur IMAP4 ->

<!ELEMENT imapServerName (#PCDATA)>

<!ATLIST imapServerName value NOTATION (FQDN) #IMPLIED>

6. 6.2.6 Mandataire WWW

L'élément wwwProxyServerName contient le FQDN du serveur mandataire de la Toile mondiale (WWW, World Wide Web) qui devrait être utilisé pour se connecter à ce POP.

Syntaxe :

<!-- Nom d'un mandataire WWW -->

<!ELEMENT wwwProxyServerName (#PCDATA)>

<!ATTLIST wwwProxyServerName value NOTATION (FQDN) #IMPLIED>

7. 6.2.7 Mandataire FTP

L'élément ftpProxyServerName contient le FQDN du serveur mandataire du protocole de transfert de fichier (FTP, File Transfer Protocol) qui devrait être utilisé pour se connecter à ce POP.

Syntaxe :

<!-- Nom d'un mandataire FTP -->

<!ELEMENT ftpProxyServerName (#PCDATA)>

<!ATTLIST ftpProxyServerName value NOTATION (FQDN) #IMPLIED>

8. 6.2.8 Mandataire Winsock

L'élément winsockProxyServerName contient le FQDN du serveur mandataire Windows Socket (Winsock) qui devrait être utilisé pour se connecter à ce POP.

Syntaxe :

<!-- Nom d'un mandataire Winsock-->

<!ELEMENT winsockProxyServerName (#PCDATA)>

<!ATTLIST winsockProxyServerName value NOTATION (FQDN) #IMPLIED>

9. 6.2.9 Adresse de passerelle par défaut

L'élément defaulttGatewayAddress représente l'adresse de la passerelle par défaut qui devrait être utilisée pour se connecter à ce POP. L'adresse est représentée sous forme d'une chaîne en notation décimale séparée par des points (par exemple, 192.168.101.1).

Syntaxe :

<!-- Adresse de passerelle IP par défaut (en notation décimale séparé par des points) -->

<!ELEMENT defaultGatewayAddress (#PCDATA)>

<!ATTLIST defaultGatewayAddress value NOTATION (IPADR) #IMPLIED>

10. 6.2.10 Suffixe de nom d'utilisateur

L'élément userNameSuffix représente une chaîne qui devrait être rattachée au nom d'utilisateur de base. Par exemple, si le nom d'utilisateur de base est "usagerA" et si la valeur de cet élément est "@bigco.com", le nom d'utilisateur augmenté résultant serait "usagerA@bigco.com". Un numéroteur intelligent peut enchaîner automatiquement les éléments de la chaîne. Noter que userNameSuffix et userNamePrefix (ci-dessous) peuvent tous deux être appliqués au même nom d'utilisateur de base.

Syntaxe :

<!-- Suffixe de nom d'utilisateur -->

<!ELEMENT userNameSuffix (#PCDATA)>

11. 6.2.11 Préfixe de nom d'utilisateur

L'élément userNamePrefix représente une chaîne à laquelle devrait être concaténé le nom d'utilisateur. Par exemple, si le nom d'utilisateur de base est "usagerB" et si la valeur de cet élément est "BIGCO/", le nom d'utilisateur augmenté résultant serait "BIGCO/usagerB". Un numéroteur intelligent peut effectuer automatiquement l'enchaînement. Noter que les deux éléments userNameSuffix (ci-dessus) et userNamePrefix peuvent être appliqués au même nom d'utilisateur de base.

Syntaxe :

<!-- Préfixe de nom d'utilisateur -->

<!ELEMENT userNamePrefix (#PCDATA)>

8. 6.3 Éléments d'information définis pour l'élément de soutien

   1. 6.3.1 Numéro de téléphone de soutien

L'élément supportTelephoneNumber contient un numéro qui peut être appelé pour joindre le centre de soutien d'un fournisseur ou POP particulier. Cet élément est essentiellement une chaîne et devrait contenir le numéro de téléphone entier en forme internationale, par exemple, "+1 425 838 8080".

Syntaxe :

<!-- Numéro à taper pour contacter le service client pour ce POP ou fournisseur -->

<!ELEMENT supportTelephoneNumber (#PCDATA)>

2. 6.3.2 Adresse de messagerie électronique de soutien

L'élément supportMailtoURL contient un URL de l'adresse de messagerie électronique de soutien des clients du fournisseur, par exemple, mailto:support@uu.net. Cet URL pourrait être utilisé pour contacter les personnel de soutien à la clientèle concernant des sujets non urgents.

Syntaxe :

<!-- Localisateur de ressource universel de l'adresse de messagerie électronique de soutien à la clientèle du fournisseur -->

<!ELEMENT supportMailtoURL (#PCDATA)>

9. 6.4 Éléments d'information définis pour l'élément provider

   1. 6.4.1. Nom de fournisseur

L'élément providerName est une chaîne qui contient le nom du fournisseur (par exemple, "BIGNET Corporation").

Syntaxe :

<!-- Nom du fournisseur -->

<!ELEMENT providerName (#PCDATA)>

2. 6.4.2 Image du fournisseur

L'élément providerIcon contient une image JPEG ou GIF codée en BASE64 qui peut être utilisée pour identifier les entrées du répertoire téléphonique ou à afficher lors de la numérotation.

Syntaxe :

<!-- Image en format JPEG ou GIF codée en BASE64 -->

<!ELEMENT providerIcon (#PCDATA)>

<!ATTLIST providerIcon value NOTATION (B64JPG | B64GIF) #IMPLIED>

3. 6.4.3 URL de la Toile mondiale du fournisseur

L'élément wwwURL contient un localisateur de ressource universel (URL, Uniform Resource Locator) pour le site de la Toile du fournisseur, par exemple, http://www.uu.net.

Syntaxe :

<!-- Localisateur de ressource universel pour la page d'accueil du fournisseur -->

<!ELEMENT wwwURL (#PCDATA)>

4. 6.4.4 Principale adresse de messagerie électronique du fournisseur

L'élément generalMailtoURL contient un URL de l'adresse principale de messagerie électronique du fournisseur, par exemple, mailto:contact@uu.net. Cet URL pourrait être utilisé pour la correspondance générale, les réclamations, etc.

Syntaxe :

<!-- Localisateur de ressource universel pour l'adresse de messagerie électronique du fournisseur -->

<!ELEMENT generalMailtoURL (#PCDATA)>

5. 6.4.5 Adresse de messagerie électronique pour les demandes concernant la facturation

L'élément billingMailtoURL contient un URL pour l'adresse de messagerie électronique pour les problèmes de facturation du fournisseur, par exemple, mailto:billing@uu.net. Cet URL pourrait être utilisé pour la correspondance concernant les questions de facturation et de payement.

Syntaxe :

<!-- Localisateur de ressource uniforme pour l'adresse de messagerie électronique à utiliser pour les demandes concernant la facturation -->

<!ELEMENT billingMailtoURL (#PCDATA)>

6. 6.4.6 Autres éléments

Le reste des éléments d'information de l'élément provider est décrit en principe dans la [RFC1274].

7. DTD XML complet pour l’annuaire de l’itinérance

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

<!-- Déclaration d'entité de paramètre -->

<!-- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->

<!-- Cette section sera entretenue par l'IANA et peut être directement référencée parla spécification de DTD au moyen d'une entité de paramètre externe. -->

<!ENTITY % addressFamily "(E164|X121)" >

<!ENTITY % mediaTypes "(viaMODEM|viaISDN|viaATM|viaFR|viaX25)+" >

<!ENTITY % modemProtocols "(V21|V22|V29|V32|V32B|V34|V34B|V90)" >

<!ENTITY % isdnProtocols "(V110L|V110H|V120L|V120H|X75|HDLC)">

<!ENTITY % atmProtocols "(RFC2364)">

<!ENTITY % frProtocols "(RFC1973)">

<!ENTITY % x25Protocols "(RFC1598)">

<!ENTITY % popProperties "(MPPP|MOBIP|MCRX|MCTX)" >

<!ENTITY % tunnelingProtocols "(L2TP|PPTP|L2F|ATMP|AHT|ESPT|IPIP|MIP|GRE)" >

<!ENTITY % popInformation

"address,

media+,

minBitsPerSecond?,

maxBitsPerSecond?,

popProperty*,

tunnelProto*,

dialScript?,

pricingInformation?,

city?,

region?,

country?,

(setup|setupPtr)?,

(support|supportPtr)?,

(provider|providerPtr)?">

<!ENTITY % setupInformation

"dnsServerAddress*,

nntpServerName*,

smtpServerName*,

popServerName*,

imapServerName*,

wwwProxyServerName*,

ftpProxyServerName*,

winsockProxyServerName*,

defaultGatewayAddress?,

userNamePrefix?,

userNameSuffix?">

<!ENTITY % supportInformation "(supportTelephoneNumber|supportMailtoURL)+">

<!ENTITY % providerInformation

"providerName?,

providerIcon?,

wwwURL?,

generalMailtoURL?,

billingMailtoURL?,

businessCategory?,

x121Address?,

registeredAddress?,

destinationIndicator?,

preferredDeliveryMethod?,

telexNumber?,

teletexTerminalIdentifier?,

telephoneNumber?,

internationalISDNNumber?,

facsimileTelephoneNumber?,

street?,

postOfficeBox?,

postalCode?,

postalAddress?,

physicalDeliveryOfficeName?,

description?,

supportPtr*">

<!-- ++++++++++++++ Fin de la section tenue par l'IANA ++++++++++ -->

<!-- Déclarations de notation de type de valeur de répertoire téléphonique -->

<!NOTATION FQDN PUBLIC "-//IETF/roamPhoneBook/NOTATION value Type Fully_qualified_domain_name">

<!NOTATION IPADR PUBLIC "-//IETF/roamPhoneBook/NOTATION value Type IP_address">

<!NOTATION B64JPG PUBLIC "-//IETF/roamPhoneBook/NOTATION value Type Base64_encoded_jpeg_image">

<!NOTATION B64GIF PUBLIC "-//IETF/roamPhoneBook/NOTATION value Type Base64_encoded_gif_image">

<!-- Déclarations d'éléments du répertoire téléphonique -->

<!ELEMENT phoneBook (

pop+,

setup*,

support*,

provider*) >

<!ATTLIST phoneBook

name CDATA #REQUIRED

version CDATA #REQUIRED >

<!ELEMENT pop ( %popInformation; )>

<!ATTLIST pop entryVersion CDATA #REQUIRED>

<!ELEMENT setup ( %setupInformation; )>

<!ATTLIST setup id ID #REQUIRED>

<!ELEMENT support ( %supportInformation; )>

<!ATTLIST support id ID #REQUIRED language NMTOKENS #IMPLIED >

<!ELEMENT provider ( %providerInformation; )>

<!ATTLIST provider id ID #REQUIRED>

<!-- Éléments d'information pour pop -->

<!ELEMENT address (#PCDATA)>

<!ATTLIST address

family %addressFamily; #REQUIRED

countryCode CDATA #IMPLIED

areaCode CDATA #IMPLIED >

<!ELEMENT media %mediaTypes; >

<!ELEMENT viaMODEM EMPTY>

<!ATTLIST viaMODEM type %modemProtocols; #IMPLIED >

<!ELEMENT viaISDN EMPTY>

<!ATTLIST viaISDN type %isdnProtocols; #IMPLIED >

<!ELEMENT viaATM EMPTY>

<!ATTLIST viaATM type %atmProtocols; #IMPLIED >

<!ELEMENT viaFR EMPTY>

<!ATTLIST viaFR type %frProtocols; #IMPLIED >

<!ELEMENT viaX25 EMPTY>

<!ATTLIST viaX25 type %x25Protocols; #IMPLIED >

<!ELEMENT minBitsPerSecond (#PCDATA)>

<!ELEMENT maxBitsPerSecond (#PCDATA)>

<!ELEMENT popProperty EMPTY>

<!ATTLIST popProperty type %popProperties; #REQUIRED >

<!ELEMENT tunnelProto EMPTY>

<!ATTLIST tunnelProto type %tunnelingProtocols; #REQUIRED >

<!ELEMENT dialScript (#PCDATA)>

<!ATTLIST dialScript type CDATA #IMPLIED >

<!ELEMENT pricing (#PCDATA)>

<!ELEMENT city (#PCDATA)>

<!ELEMENT region (#PCDATA)>

<!ELEMENT country (#PCDATA)>

<!ELEMENT setupPtr EMPTY>

<!ATTLIST setupPtr setupID IDREFS #IMPLIED>

<!ELEMENT supportPtr EMPTY>

<!ATTLIST supportPtr supportID IDREFS #IMPLIED>

<!ELEMENT providerPtr EMPTY>

<!ATTLIST providerPtr providerID IDREFS #IMPLIED>

<!-- Éléments d'information pour setup -->

<!ELEMENT dnsServerAddress (#PCDATA)>

<!ATTLIST dnsServerAddress value NOTATION (IPADR) #IMPLIED>

<!ELEMENT nntpServerName (#PCDATA)>

<!ATTLIST nntpServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT smtpServerName (#PCDATA)>

<!ATTLIST smtpServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT popServerName (#PCDATA)>

<!ATTLIST popServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT imapServerName (#PCDATA)>

<!ATTLIST imapServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT wwwProxyServerName (#PCDATA)>

<!ATTLIST wwwProxyServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT ftpProxyServerName (#PCDATA)>

<!ATTLIST ftpProxyServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT winsockProxyServerName (#PCDATA)>

<!ATTLIST winsockProxyServerName value NOTATION (FQDN) #IMPLIED>

<!ELEMENT defaultGatewayAddress (#PCDATA)>

<!ATTLIST defaultGatewayAddress value NOTATION (IPADR) #IMPLIED>

<!ELEMENT userNameSuffix (#PCDATA)>

<!ELEMENT userNamePrefix (#PCDATA)>

<!-- Éléments d'information pour support -->

<!ELEMENT supportTelephoneNumber (#PCDATA)>

<!ELEMENT supportMailtoURL (#PCDATA)>

<!-- Éléments d'information pour provider -->

<!ELEMENT providerName (#PCDATA)>

<!ELEMENT providerIcon (#PCDATA)>

<!ATTLIST providerIcon value NOTATION (B64JPG|B64GIF) #IMPLIED>

<!ELEMENT wwwURL (#PCDATA)>

<!ELEMENT generalMailtoURL (#PCDATA)>

<!ELEMENT billingMailtoURL (#PCDATA)>

<!-- Autres éléments d'information pour provider selon la RFC1274 -->

<!ELEMENT businessCategory (#PCDATA)>

<!ELEMENT x121Address (#PCDATA)>

<!ELEMENT registeredAddress (#PCDATA)>

<!ELEMENT destinationIndicator (#PCDATA)>

<!ELEMENT preferredDeliveryMethod (#PCDATA)>

<!ELEMENT telexNumber (#PCDATA)>

<!ELEMENT teletexTerminalIdentifier (#PCDATA)>

<!ELEMENT telephoneNumber (#PCDATA)>

<!ELEMENT internationalISDNNumber (#PCDATA)>

<!ELEMENT facsimileTelephoneNumber (#PCDATA)>

<!ELEMENT street (#PCDATA)>

<!ELEMENT postOfficeBox (#PCDATA)>

<!ELEMENT postalCode (#PCDATA)>

<!ELEMENT postalAddress (#PCDATA)>

<!ELEMENT physicalDeliveryOfficeName (#PCDATA)>

<!ELEMENT description (#PCDATA)>

<!-- Fin du dtd -->

8. Considérations pour la sécurité

La distribution et le transport sécurisés des informations d'un répertoire téléphonique pour les applications d'itinérance exigent une authentification fiable du producteur des informations ainsi que des moyens de préserver l'intégrité des informations fournies.

Le répertoire téléphonique de DTD XML ne fournit pas par lui-même d'éléments spécifiques pour les exigences de sécurité. On suppose que la sécurité du répertoire de l'itinérance est fournie par des moyens qui sortent du domaine d'application de la présente spécification, tels que de signer le répertoire téléphonique en utilisant PGP.

9. Considérations relatives à l’IANA

La présente spécification donne la possibilité de définir d'autres valeurs d'attribut pour tous les éléments d'information qui possèdent des listes d'attributs énumérés ainsi que d'étendre les structures principales 'pop', 'setup', 'support' et 'provider' par des éléments d'information supplémentaires. La spécification du répertoire téléphonique de l'itinérance peut donc être adaptée à de futures exigences sans changer le présent document. Les extensions et améliorations à la présente spécification peuvent être réalisées par l'enregistrement de nouveaux éléments et attributs par l'IANA.

L'extension de la présente spécification par des attributs ou éléments supplémentaires ne doit pas changer la validité des documents qui se fondent sur une version plus ancienne du DTD XML. Donc, tous les éléments d'information ajoutés doivent être facultatifs, prohibant l'inclusion obligatoire d'éléments d'information nouvellement définis. L'ajout de nouvelles valeurs aux listes d'attributs énumérés n'implique pas de contraintes sur la rétro compatibilité parce qu'elle ne porte pas atteinte à la validité des attributs déjà définis.

Pour faciliter l'enregistrement de nouveaux éléments d'information et de nouvelles valeurs d'attribut, le DTD du répertoire téléphonique a été séparé en deux parties, la partie extensible contenant seulement les déclarations des entités de paramètres pour faciliter l'inclusion de nouvelles valeurs, et la partie fixe contenant la spécification détaillée du contenu et de la structure du répertoire téléphonique. En faisant référence aux déclarations d'entités de paramètre dans la partie fixe de la spécification, c'est le répertoire téléphonique dans son entier qui devient extensible.

La partie qui contient les déclarations d'entités de paramètre doit être entretenue par l'IANA. Il y a deux différentes classes de déclarations dans cette partie qui exigent des politiques différentes pour l'enregistrement des nouvelles valeurs.

10. 9.1 Enregistrement des valeurs de nouveaux attributs

Les entités 'addressFamily', 'modemProtocols', 'isdnProtocols', 'atmProtocols', 'frProtocols', 'x25Protocols', 'popProperties' et 'tunnelingProtocols' décrivent des listes de valeurs d'attribut énumérées. Comme il n'y a pas de limitation à l'espace de noms de ces valeurs d'attribut et que les valeurs d'attribut nouvellement définies ne peuvent pas causer de dommages à la validité des valeurs existantes, de nouvelles valeurs d'attribut peuvent être allouées par une spécification exigée selon la [RFC2434].

11. 9.2. Enregistrement des nouveaux éléments d’information

Les entités 'mediaTypes', 'popInformation', 'setupInformation', ' supportInformation' et 'providerInformation' définissent les éléments d'information probablement inclus dans les éléments media, pop, setup, support et provider. Insérer de nouvelles valeurs dans ces listes étend le répertoire téléphonique avec des éléments d'informations nouveaux arbitraires. Une utilisation inappropriée du modèle de contenu XML peut détruire la rétro compatibilité du DTD. Donc, l'allocation de nouveaux éléments d'information exige l'approbation d'un expert désigné [RFC2434]. En plus de l'insertion d'une nouvelle valeur dans la liste, la définition détaillée de l'élément d'information doit être ajoutée à la partie spécification entretenue par l'IANA.

10. Références

[E.123] Recommandation UIT-T E.123, "Notation des numéros de téléphone nationaux et internationaux", 1988.

[RFC1274] P. Barker et S. Kille, "Schéma X.500 COSINE et Internet", novembre 1991. (Remplacée par RFC4524)

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

[RFC1700] J. Reynolds et J. Postel, "Numéros alloués", STD 2, octobre 1994. (Historique, voir www.iana.org))

[RFC2434] T. Narten et H. Alvestrand, "Lignes directrices pour la rédaction d'une section Considérations relatives à l'IANA dans les RFC", BCP 26, octobre, 1998. (Rendue obsolète par la RFC5226)

[XML] W3C Recommendation 10 "Extensible Markup Language (XML) 1.0" - février1998 : http://www.w3.org/TR/1998/REC-xml-19980210

11. Appendice : Exemples

12. 11.1 L’exemple le plus simple

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

<!DOCTYPE phoneBook SYSTEM "roamPhoneBook.dtd">

<phoneBook name="minimalExample" version="1">

<pop entryVersion="1">

<address family="E164">+1 234 5678901</address>

<media><viaMODEM/></media>

</pop>

</phoneBook>

13. 11.2 Exemple plus complet

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

<!DOCTYPE phoneBook SYSTEM "roamPhoneBook.dtd">

<phoneBook name="KNF_simple" version="1">

<pop entryVersion="1">

<address family="E164" countryCode="49">+49913130540</address>

<media>

<viaMODEM type="V90"/>

<viaMODEM type="V34B"/>

<viaISDN type="HDLC"/>

</media>

<setup>

<dnsServerAddress>192.168.147.5</dnsServerAddress>

<dnsServerAddress>193.175.24.33</dnsServerAddress>

</setup>

</pop>

<support id="KNF_main" language="EN DE">

<supportMailtoURL>mailto:support@franken.de</supportMailtoURL>

<supportTelephoneNumber>+499123968066</supportTelephoneNumber>

</support>

</phoneBook>

12. Remerciements

Merci à Pat Calhoun, Bernard Aboba, Jay Farhat, Butch Anton, Quentin Miller, et Ken Crocker pour leurs contributions et leur relecture.

13. Adresse des auteurs

Les questions sur le présent mémoire peuvent être adressées à :

14. Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (2000). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement

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