idnits 2.17.1 draft-ietf-roamops-phonebook-xml-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2000) is 8617 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 1317, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1274 (ref. '3') (Obsoleted by RFC 4524) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 2434 (ref. '6') (Obsoleted by RFC 5226) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Riegel 3 Internet-Draft Siemens AG 4 Category: Standards Track G. Zorn 5 Cisco Systems 6 September 2000 8 XML DTD for Roaming Access Phone Book 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 The distribution of this memo is unlimited. It is filed as 30 , 31 and expires February 28, 2001. 32 Please send comments to the Roaming Operations Working Group mailing 33 list (roamops@tdmx.rutgers.edu) or to the editor of this draft 34 (maximilian.riegel@icn.siemens.de). 36 2. Abstract 38 This document defines the syntax as well as the semantics of the 39 information to be included in the phone book for roaming 40 applications. It comprises the information necessary to select the 41 most appropriate ISP and to configure the host to get access to the 42 network of the provider. The specification consists of a small set of 43 required information elements and a variety of possible extensions. 44 All data is specified in XML [5] (Extensible Markup Language) syntax 45 leading to a concise XML DTD (Document Type Declaration) for the 46 phone book. 48 3. Introduction 50 Roaming applications depend on the delivery of information about 51 provided services and the procedures to get connected to the network 52 from the roaming consortium to the individual users as well as from 53 the operators of the network access servers, normally the members of 54 the roaming consortium, and the roaming consortium. 56 "phone book" 57 +------+ +--+ 58 | | | ++ 59 | ISP1 | -- | | --+ 60 | | +---+ \ "phone book" 61 +------+ \ +------+ 62 +------+ +--+ \_ | | +--+ +------+ 63 | | | ++ | | | ++ | | 64 | ISP2 | -- | | -->>--- | | --- | | ->> | USER | 65 | | +---+ _ | | +---+ | | 66 +------+ / | | +------+ 67 +------+ +--+ / +------+ 68 | | | ++ / Roaming 69 | ISP# | -- | | --+ Consortium 70 | | +---+ 71 +------+ 73 The roaming consortium assembles from the individual contributions of 74 the providers belonging to the consortium a unified version of the 75 phone book for usage by the customers. Probably different groups of 76 users get different versions of a phone book adapted to their 77 particular needs. Even users might generate different subsets 78 especially suited to particular applications from the information 79 received from the roaming consortium, e.g. retrieving only entries 80 for a particular country or extracting all access points providing 81 wireless connectivity. 83 Therefore it is desirable to define a highly portable and well formed 84 structure of the phone book to enable easy generation and 85 postprocessing. Goals of this document include: 87 - Creating a flexible, extensible and robust framework 88 upon which to build a standard phone book; 89 - Promoting a standard phone book format, to enhance 90 interoperability between ISPs and roaming consortia as 91 well as to enable automatic extraction of configuration 92 data by a wide variety of devices; 93 - Defining a compact structure containing the essential 94 information for the roaming user, to allow for storage 95 and easy update even on small devices. 97 It is not intended by this document to create a plethoric solution, 98 with phone book elements to fit every condition on earth, neither to 99 define any kind of phone book update or transfer protocol. 101 4. Rationale for XML Usage 103 XML is rapidly becoming a standard format for data exchange between 104 different applications also taking into account the transfer and 105 access of data over the web. XML is used as syntax for expressing the 106 structure and content of a roaming phone book to enable widespread 107 usage and access to many different kind of media (e.g. paper, CDROM, 108 www) using a widespread selection of access devices. Furthermore XML 109 enables: 111 - Extensibility 112 - Flexibility 113 - Integration with directories 115 Extensibility is important because phone books are living documents; 116 as such, it is unlikely that all the semantic requirements of 117 arbitrary Internet service providers (ISPs) would be met by a fixed 118 scheme, no matter how well thought out. Phone book designers must be 119 free to create new attributes in a well-understood fashion to meet 120 changing business needs. 122 Flexibility is required of the attribute definition syntax for many 123 of the same reasons that semantic extensibility is necessary. If we 124 assume that phone book designers may need to define elements of 125 arbitrary type, the syntax chosen must be able to represent these 126 data objects cleanly. Using XML for describing the data content of 127 the phone book fits this bill nicely, since it can be used to 128 unambiguously describe virtually any data type. 130 Integration with directories: although it is unlikely that phone 131 books will be stored in the directory due to performance 132 considerations, the creation of a XML DTD describing phone book 133 content leaves that option open, with relatively little incremental 134 effort required to implement it. 136 5. Specification of Requirements 138 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 139 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 140 described in [1]. 142 6. Value type notations for 'stronger' typing 144 XML DTDs do not currently have capabilities for 'strong typing' of 145 the content of elements. The only type definition foreseen in the 146 base specification is "#PCDATA", 'parsable character data'. This 147 might be sufficient and is used throughout this document to define 148 elements containing information mainly aimed for interpretation by 149 human beings. 150 To enable a more concise description of the content of particular 151 elements several value type notations are introduced. This allows for 152 a more detailed type description of the content of elements in cases 153 where it seems to be desirable. 155 157 158 160 162 164 167 7. Container Element Definitions 169 7.1. PhoneBook 171 The phoneBook element is the basic container for phone book entries. 172 It has two attributes, a phone book name and a phone book version 173 number (applying to the phone book as a whole), and always contains 174 one or more pop elements. A phoneBook element may also contain 175 multiple Setup, Support and Provider elements, if they are referenced 176 to by more than one pop element. 178 Syntax: 179 184 188 phoneBook 189 +-----------------------------------+ 190 | phoneBookName (req)| 191 | phoneBookVersion (req)| 192 | +-----------------------+ | 193 | | pop |+ (req)| 194 | +-----------------------+| | 195 | + - - - - - - - - - - - + | 196 | | 197 | + - - - - - - - - - - - + | 198 | | setup |+ (opt)| 199 | + - - - - - - - - - - - +| | 200 | + - - - - - - - - - - - + | 201 | | 202 | + - - - - - - - - - - - + | 203 | | support |+ (opt)| 204 | + - - - - - - - - - - - +| | 205 | + - - - - - - - - - - - + | 206 | | 207 | + - - - - - - - - - - - + | 208 | | provider |+ (opt)| 209 | + - - - - - - - - - - - +| | 210 | + - - - - - - - - - - - + | 211 +-----------------------------------+ 213 7.1.1. phoneBook Attribute "name" 215 The phoneBook attribute "name" is an arbitrary string assigned as an 216 identifier for a phone book. 218 7.1.2. phoneBook Attribute "version" 220 The phoneBookVersion attribute is an integer representing the version 221 of the phone book; it is a monotonically increasing counter which 222 should be incremented each time the phone book is modified. 223 This element can be used by a server to help decide what (if any) 224 actions are required to bring a client's phone book up to date. For 225 example, the client can, at connect time, send an update request to 226 the server including in the request the version number of its current 227 phone book. If the client's phone book version is not the same as the 228 server's current phone book version, the server can easily take 229 appropriate action, e.g., reply with a URL pointing to a file 230 containing the differences between the client and server phone books. 232 7.2. POP 234 The pop element contains information elements relevant to individual 235 network points of presence (POPs). The required information elements 236 are addrFamily, address, media and entryVersion. The media element 237 represents the media types supported by the POP, while the 238 entryVersion element is a monotonically-increasing integer which 239 should be incremented whenever the object is modified. 241 The following information elements are currently defined for the pop 242 element. Additional information elements may be defined by IANA in 243 future. 245 POP 246 +-----------------------------------+ 247 | entryVersion (req)| 248 | +-------------------------+ | 249 | | address | (req)| 250 | +-------------------------+ | 251 | media (req)| 252 | minBitsPerSecond (opt)| 253 | maxBitsPerSecond (opt)| 254 | "popProperties" (opt)| 255 | "tunnelingProtocols" (opt)| 256 | dialScript (opt)| 257 | pricingInformation (opt)| 258 | + - - - - - - - - - - - - + | 259 | | "location" | (opt)| 260 | + - - - - - - - - - - - - + | 261 | + - - - - - - - - - - - - + | 262 | | "popSetup" | (opt)| 263 | + - - - - - - - - - - - - + | 264 | + - - - - - - - - - - - - + | 265 | | "popSupport" | (opt)| 266 | + - - - - - - - - - - - - + | 267 | + - - - - - - - - - - - - + | 268 | | "popProvider" | (opt)| 269 | + - - - - - - - - - - - - + | 270 +-----------------------------------+ 272 Syntax: 274 290 291 294 7.2.1. pop Attribute "entryVersion" 296 The entryVersion attribute is an integer representing the version of 297 the POP object; it is a monotonically increasing counter which should 298 be incremented each time the object is modified. This attribute may 299 be useful in merging and updating phone books. 301 7.3. Setup 303 The Setup element includes information elements which describe 304 services which may change from provider to provider or even from POP 305 to POP. Some of the values contained in these information elements 306 may be available by other means (e.g., DHCP), but others may not. 308 The following information elements are currently defined for the 309 Setup element. Additional information elements may be defined by IANA 310 in future. 312 Syntax: 314 327 328 331 7.4. Support 333 The Support element includes those information elements that are 334 pertinent to the provision of customer support for a POP or provider. 335 Languages spoken by the staff at the support center might be 336 specified by multiple entries for the attribute value language. 338 Additional information elements for the Support element may be 339 defined by IANA in future. 341 Syntax: 342 345 346 350 7.5. Provider 352 The Provider element contains information elements pertaining to the 353 general business operations of a given network service provider. The 354 information elements include such things as telephone number, mailing 355 address, etc., as well as URLs for e-mail and a World Wide Web site. 356 A Provider element may also contain a reference to support 357 information. 359 Currently the following information elements are defined for the 360 Provider element. Additional information elements may be defined by 361 IANA in future. 363 Syntax: 364 388 389 392 8. Information Element Definitions 394 8.1. Information elements defined for the POP element 396 8.1.1. Address 398 The address element provides the information representing the address 399 of the POP. For POPs offering dial-up network access, the address 400 element will at least contain an IA5 string representing a telephone 401 number, formatted in standard fashion [4] (e.g. "+ 1 234 5678"). More 402 detailed information may be available by optional attribute values. 404 Syntax: 406 407 409 8.1.1.1. address Attribute "family" 411 The attribute family of the element address defines the address 412 family to which the element value belongs. For POPs offering dial-up 413 network access, the addrFamily attribute will generally contain a 414 value for a telephone network based address family. Currently the 415 following attribute values are defined. Additional values may be 416 registered by IANA in future. 418 Value Description 419 ------ ------------------------------------------ 420 E164 ITU-T E.164 (PSTN, SMDS, Frame Relay, ATM) 421 X121 ITU-T X.121 (X.25, Frame Relay) 423 Syntax: 424 425 426 429 8.1.1.2. address Attribute "countryCode" 431 The countryCode attribute indicates the international dialing prefix 432 for the country in which the POP is located. 434 Syntax: 435 436 439 8.1.1.3. address Attribute "areaCode" 441 The areaCode attribute contains the area or city code component of 442 the telephone number in the 'address' element (if any) associated 443 with this POP. 445 447 450 8.1.2. Media 452 The media element is a container describing the types of media and 453 related protocols supported by this POP. 454 The following media types are currently defined. Additional types may 455 be registered by IANA in future. 457 Value Media Type 458 -------- ----------- 459 viaMODEM Modem 460 viaISDN ISDN 461 viaATM ATM 462 viaFR Frame Relay 463 viaX25 X.25 465 Syntax: 466 467 468 470 8.1.2.1. Modem Protocols 472 The viaMODEM element is an empty element representing by its optional 473 type attribute the modem protocol supported by the access devices 474 that can be reached at address. To define multiple available 475 protocols this element may be included repeatedly. 476 The initially defined modem protocol types are listed in the table 477 below. Additional values may be registered by IANA in future. 479 Value Duplex Speed Protocol 480 ----- ------ ----- ------------- 481 V21 Full 300 ITU-T V.21 482 V22 Full 1200 ITU-T V.22 483 V29 Half 9600 ITU-T V.29 484 V32 Full 9600 ITU-T V.32 485 V32B Full 14.4k ITU-T V.32bis 486 V34 Full 28.8k ITU-T V.34 487 V34B Full 33.6k ITU-T V.34bis 488 V90 Full 56k ITU-T V.90 490 Syntax 491 492 493 494 497 8.1.2.2. ISDN Protocols 499 The viaISDN element is an empty element representing by its optional 500 type attribute the ISDN protocol supported by the access devices that 501 can be reached at address. To define multiple available protocols 502 this element may be included repeatedly. 503 The initially defined ISDN protocol types are listed in the table 504 below. Additional values may be registered by IANA in future. 506 Value Speed Meaning 507 ----- ----- ----------- 508 V110L 19.2k ITU-T V.110 509 V110H 38.4k ITU-T V.110 510 V120L 56k ITU-T V.120 511 V120H 64k ITU-T V.120 512 X75 64k ITU-T X.75 513 HDLC 64k RFC 1618 515 Syntax: 516 517 518 519 522 8.1.2.3. ATM Protocols 524 The viaATM element is an empty element representing by its optional 525 type attribute a particular protocol supported by the access devices 526 that can be reached at address. To define multiple available 527 protocols this element may be included repeatedly. 528 Currently only one protocol is defined. Additional values may be 529 registered by IANA in future. 531 Syntax: 532 533 534 535 538 8.1.2.4. Frame Relay Protocols 540 The viaFR element is an empty element representing by its optional 541 type attribute the particular protocol supported by the access 542 devices that can be reached at address. To define multiple available 543 protocols this element may be included repeatedly. 544 Currently only one protocol is defined. Additional values may be 545 registered by IANA in future. 547 Syntax: 548 549 550 551 554 8.1.2.5. X.25 Protocols 556 The viaX25 element is an empty element representing by its optional 557 type attribute the particular protocol supported by the access 558 devices that can be reached at address. To define multiple available 559 protocols this element may be included repeatedly. 560 Currently only one protocol is defined. Additional values may be 561 registered by IANA in future. 563 Syntax: 564 565 566 567 570 8.1.3. Minimum Data Rate 572 The minBitsPerSecond element indicates the minimum data rate (in 573 bits/second) supported by the access devices at the POP. 575 Syntax: 576 577 579 8.1.4. Maximum Data Rate 581 The maxBitsPerSecond element indicates the maximum data rate (in 582 bits/second) supported by the access devices at the POP. 584 Syntax: 585 586 588 8.1.5. POP Properties 590 The popProperty element is an empty element representing by its 591 attribute value a particular property of this POP. To define multiple 592 available protocols this element might be included several times. 593 The initially defined properties are listed in the table below. 594 Additional values may be registered by IANA in future. 596 Value Property 597 ------ ---------------------- 598 MPPP Multilink PPP (RFC 1990) 599 MOBIP Mobile IP (RFC 2002) 600 MCRX Multicast Reception 601 MCTX Multicast Transmission 603 Syntax: 604 605 606 607 610 8.1.6. Tunneling Protocols 612 The tunnelProto element is an empty element representing by its 613 attribute a tunneling protocol supported by this POP. To define 614 multiple available protocols this element might be included several 615 times. 616 The initially defined values are listed in the table below. 617 Additional values may be registered by IANA in future. 619 Value Protocol 620 ------ ------------------ 621 L2TP RFC 2661 L2TP 622 PPTP RFC 2637 PPTP 623 L2F RFC 2341 L2F 624 ATMP RFC 2107 ATMP 625 AHT RFC 2402 IP AH Tunnel Mode 626 ESPT RFC 2406 IP ESP Tunnel Mode 627 IPIP RFC 1853 IP-IP 628 MIP RFC 2004 Minimal IP-IP 629 GRE RFC 1701 GRE 631 Syntax: 632 633 636 637 640 8.1.7. Dialing Script 642 The dialScript element contains the dialing script to be used when 643 connecting to this POP. 644 The attribute value type of dialScript defines the type of the script 645 that should be used when connecting to this POP. 647 Syntax: 648 649 650 653 8.1.8. Pricing Information 655 The pricingInformation element is a free-form string representing 656 pricing information for this POP. It may be anything from a simple 657 string indicating relative expense (e.g., "$$$$" for a very expensive 658 POP) to a paragraph describing time-of-day and other differential 659 pricing variables. 661 Syntax: 662 663 665 8.1.9. City 667 The city element contains the name of the city in which the POP is 668 located (not the city(s) from which it is accessible by a local 669 call). 671 Syntax: 672 673 675 8.1.10. Region 677 The region element contains the name of the region in which the POP 678 is located. In the United States, this would be the name of a state 679 or (for Washington, D.C.) administrative district. In other 680 countries, it might be the name of a province, parish or county. 682 Syntax: 683 684 686 8.1.11. Country 688 The country element contains the name of the country in which the POP 689 is located. The country name may be abbreviated (e.g., "USA" for the 690 United States of America or "UK" for the United Kingdom) but if 691 abbreviations are used the usage must be consistent within a given 692 phone book. 694 Syntax: 695 696 698 8.1.12. POP Setup 700 The popSetup element is either a setup element, if setup is specific 701 to this particular POP, or a reference to any of the setup elements 702 given in the outer scope of the phonebook element. 704 Syntax: 705 706 707 710 8.1.13. POP Support 712 The popSupport element is either a support element, if support is 713 specific to this particular POP, or a reference to any of the support 714 elements given in the outer scope of the phonebook element. 716 Syntax: 717 718 719 722 8.1.14. POP Provider 724 The popProvider element is either a provider element, if provider 725 information is specific to this particular POP, or a reference to any 726 of the provider elements given in the outer scope of the phonebook 727 element. 729 Syntax: 730 731 732 735 8.2. Information elements defined for the Setup element 737 8.2.1. DNS Server Address 739 The dnsServerAddress element represents the IP address of the Domain 740 Name Service (DNS) server which should be used when connected to this 741 POP. 742 The address is represented in the form of a string in dotted-decimal 743 notation (e.g., 192.168.101.1). 745 Syntax: 746 747 748 751 8.2.2. NNTP Server Name 753 The nntpServerName element contains the fully qualified domain name 754 (FQDN) of the Network News Transfer Protocol (NNTP) server which 755 should be used when connected to this POP. 757 Syntax: 758 759 760 763 8.2.3. SMTP Server Name 765 The smtpServerName element contains the FQDN of the Simple Mail 766 Transfer Protocol (SMTP) server which should be used when connected 767 to this POP. 769 Syntax: 770 771 772 775 8.2.4. POP3 Server Name 777 The popServerName element contains the FQDN of the Post Office 778 Protocol (POP) server which should be used when connected to this 779 POP. 781 Syntax: 782 783 784 787 8.2.5. IMAP Server Name 789 The imapServerName element contains the FQDN of the Internet Mail 790 Access Protocol (IMAP) server which should be used when connected to 791 this POP. 793 Syntax: 794 795 796 799 8.2.6. WWW Proxy 801 The wwwProxyServerName element contains the FQDN of the World Wide 802 Web (WWW) proxy server which should be used when connected to this 803 POP. 805 Syntax: 806 807 808 811 8.2.7. FTP Proxy 813 The ftpProxyServerName element contains the FQDN of the File Transfer 814 Protocol (FTP) proxy server which should be used when connected to 815 this POP. 817 Syntax: 818 819 820 823 8.2.8. Winsock Proxy 825 The winsockProxyServerName element contains the FQDN of the Windows 826 Socket (Winsock) proxy server which should be used when connected to 827 this POP. 829 Syntax: 830 831 832 835 8.2.9. Default Gateway Address 837 The defaulttGatewayAddress element represents the address of the 838 default gateway which should be used when connected to this POP. The 839 address is represented in the form of a string in dotted-decimal 840 notation (e.g., 192.168.101.1). 842 Syntax: 843 844 845 848 8.2.10. User Name Suffix 850 The userNameSuffix element represents a string which should be 851 concatenated to the base username. For example, if the base username 852 is "userA" and the value of this element is "@bigco.com", the 853 resulting augmented username would be "userA@bigco.com". An 854 intelligent dialer may concatenate the string automatically. 855 Note that both the userNameSuffix and the userNamePrefix (below) may 856 be applied to the same base username. 858 Syntax: 859 860 862 8.2.11. User Name Prefix 864 The userNamePrefix element represents a string to which the base 865 username should be concatenated. For example, if the base username is 866 "userB" and the value of this element is "BIGCO/" the resulting 867 augmented username would be "BIGCO/userB". An intelligent dialer may 868 perform the concatenation automatically. 869 Note that both the userNameSuffix (above) and the userNamePrefix may 870 be applied to the same base username. 872 Syntax: 873 874 876 8.3. Information elements defined for the support element 878 8.3.1. Support Telephone Number 880 The supportTelephoneNumber element contains a number that may be 881 called to reach the support center for a particular provider or POP. 882 This element is basically a string and should contain the entire 883 telephone number in international form, e.g., "+1 425 838 8080". 885 Syntax: 886 888 890 8.3.2. Support Email Address 892 The supportMailtoURL element contains a URL for the provider's 893 customer support email address, e.g. mailto:support@uu.net. 894 This URL could be used to contact customer support personnel 895 regarding non-urgent issues. 897 Syntax: 898 900 902 8.4. Information elements defined for the provider element 904 8.4.1. Provider Name 906 The providerName element is a string containing the name of the 907 provider (e.g., "BIGNET Corporation"). 909 Syntax: 910 911 913 8.4.2. Provider Icon 915 The providerIcon attribute contains a BASE64 encoded JPEG or GIF 916 image which may be used for 'branding' phone book entries or 917 displayed when dialing. 919 Syntax: 920 921 922 925 8.4.3. Provider's World Wide Web URL 927 The wwwURL element contains a Uniform Resource Locator (URL) for the 928 provider's Web site, for example, http://www.uu.net. 930 Syntax: 931 932 934 8.4.4. Provider's Main Email Address 936 The generalMailtoURL element contains a URL for the provider's main 937 email address, for example, mailto:contact@uu.net. This URL could be 938 used for general correspondence, complaints, etc. 940 Syntax: 941 943 945 8.4.5. Billing Inquiry Email Address 947 The billingMailtoURL element contains a URL for the provider's 948 billing support email address, for example, mailto:billing@uu.net. 949 This URL could be used to for correspondence regarding billing and 950 payment issues. 952 Syntax: 953 955 957 8.4.6. Further elements 959 The remainder of the information elements of the provider element are 960 described in principle in [3]. 962 9. Complete XML DTD for the roaming phone book 964 966 967 968 972 974 976 978 980 982 984 985 987 990 1006 1019 1022 1046 1048 1049 1051 1053 1055 1058 1059 1064 1068 1069 1072 1073 1076 1077 1081 1082 1085 1086 1087 1092 1094 1095 1098 1099 1102 1103 1106 1107 1110 1111 1114 1116 1118 1119 1122 1123 1126 1127 1130 1132 1134 1136 1138 1139 1142 1143 1146 1147 1150 1151 1152 1155 1156 1159 1160 1163 1164 1167 1168 1171 1172 1175 1176 1179 1180 1183 1184 1187 1189 1191 1192 1194 1196 1197 1199 1200 1203 1205 1207 1209 1211 1213 1215 1217 1219 1221 1223 1225 1226 1228 1230 1232 1234 1236 1238 1240 1242 1244 10. Security Considerations 1246 The secure distribution and transport of information of a phone book 1247 for roaming applications require a reliable authentication of the 1248 issuer of the information as well as means to preserve the integrity 1249 of the provided information. 1251 No specific elements for security requirements are provided by the 1252 phone book XML DTD itself. It is assumed that security of the roaming 1253 phone book is provided by means outside of the scope of this 1254 specification, such as signing the phone book using pgp. 1256 11. IANA Considerations 1258 This specification provides the possibility to define further 1259 attribute values for all information elements owning enumerated 1260 attribute lists as well as to extend the main structures 'pop', 1261 'setup', 'support' and 'provider' by additional information elements. 1262 Therefore the specification of the roaming phone book can be adopted 1263 to future requirements without changing this document. Extensions and 1264 refinements to this specification can be achieved by registration of 1265 new elements and attributes by IANA. 1267 Extending this specification with additional attributes or elements 1268 must not change the validity of documents based on an older version 1269 of the XML DTD. Therefore all added information elements must be 1270 optional, prohibiting the mandatory inclusion of newly defined 1271 information elements. Adding new values to enumerated attribute lists 1272 has no backward compatibility constraints because it does not harm 1273 the validity of attributes already defined. 1275 To facilitate the registration of new information elements and 1276 attribute values the DTD of the phone book has been separated in two 1277 parts, the extensible part containing only parameter entity 1278 declarations for ease inclusion of new values, and the fixed part 1279 containing the detailed specification of the content and structure of 1280 the phone book. By referencing the parameter entity declarations in 1281 the fixed part of the specification the whole phone book becomes 1282 extensible. 1284 The part containing the parameter entity declarations has to be 1285 maintained by the IANA. There are two different classes of 1286 declarations in this part requiring different policies for 1287 registering new values. 1289 11.1. Registration of new attribute values 1291 The entities 'addressFamily', 'modemProtocols', 'isdnProtocols', 1292 'atmProtocols', 'frProtocols', 'x25Protocols', 'popProperties' and 1293 'tunnelingProtocols' are describing enumerated attribute value lists. 1294 Because there is no limitation in the name space of these attribute 1295 values and newly defined attribute values can not harm the validity 1296 of existing values, new attribute values can be assigned by 1297 Specification Required [6]. 1299 11.2. Registration of new information elements 1301 The entities 'mediaTypes', 'popInformation', 'setupInformation', 1302 'supportInformation' and 'providerInformation' define the information 1303 elements probably included in the media, pop, setup, support and 1304 provider elements. Inserting new values into these lists extends the 1305 phone book by arbitrarily new information elements. Inappropriate use 1306 of the XML content model can destroy the backward compatibility of 1307 the DTD. Therefore the assignment of new information elements 1308 requires the approval of a Designated Expert [6]. In addition to the 1309 insertion of a new value into the list, the detailed definition of 1310 the information element has to be appended to the specification part 1311 maintained by the IANA. 1313 12. References 1314 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1315 Levels", BCP 14, RFC 2119, March 1997 1317 [2] Reynolds, J. and Postel, J., "ASSIGNED NUMBERS", STD 2, RFC 1700, 1318 October 1994 1320 [3] Barker, P. and Kille, S., "The COSINE and Internet X.500 Schema", 1321 RFC 1274, November 1991 1323 [4] ITU Rec. E.123, "Notation for national and international telephone 1324 numbers", 1988 1326 [5] "Extensible Markup Language (XML) 1.0" W3C Recommendation 1327 10-February-1998 http://www.w3org.org/TR/1998/REC-xml-19980210 1329 [6] Narten, T. and Alvestrand, H., "Guidelines for Writing an IANA 1330 Considerations Section in RFCs", RFC 2434, October 1998 1332 13. Appendix: Examples 1334 13.1. The most simple example 1336 1337 1338 1339 1340
+1 234 5678901
1341 1342 1343 1345 13.2. A more comprehensive example 1346 1347 1348 1349 1350
+49913130540
1351 1352 1353 1354 1355 1356 1357 192.168.147.5 1358 193.175.24.33 1359 1360 1361 1362 mailto:support@franken.de 1363 +499123968066 1364 1365 1367 14. Acknowledgments 1369 Thanks to 1370 Pat Calhoun (pcalhoun@eng.sun.com), 1371 Bernard Aboba (aboba@internaut.com), 1372 Jay Farhat (jfarhat@ipass.com), 1373 Butch Anton (butch@ipass.com), 1374 Quentin Miller (quentinm@microsoft.com), 1375 and Ken Crocker (kcrocker@microsoft.com) 1376 for salient input and review. 1378 15. Author's Addresses 1380 Questions about this memo can be directed to: 1382 Max Riegel 1383 Siemens AG 1384 Hofmannstr. 51 1385 Munich, 81359 1386 Germany 1388 Phone: +49 89 722 49557 1389 E-Mail: maximilian.riegel@icn.siemens.de 1390 Glen Zorn 1391 Cisco Systems, Inc. 1392 500 108th Avenue N.E., Suite 500 1393 Bellevue, WA 98004 1394 USA 1396 Phone: +1 425 438 8218 1397 E-Mail: gwz@cisco.com 1399 16. Expiration Date 1401 This memo is filed as draft-ietf-roamops-phonebook-xml-05.txt and 1402 expires on February 28, 2001.