📄 rfc3017.txt
字号:
<!ELEMENT maxBitsPerSecond (#PCDATA)> <!ELEMENT popProperty EMPTY> <!ATTLIST popProperty type %popProperties; #REQUIRED > <!ELEMENT tunnelProto EMPTY> <!ATTLIST tunnelProto type %tunnelingProtocols; #REQUIRED >Riegel & Zorn Standards Track [Page 25]RFC 3017 Roaming Access Phone Book XML DTD December 2000 <!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> <!-- Information elements for 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>Riegel & Zorn Standards Track [Page 26]RFC 3017 Roaming Access Phone Book XML DTD December 2000 <!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)> <!-- Information elements for support --> <!ELEMENT supportTelephoneNumber (#PCDATA)> <!ELEMENT supportMailtoURL (#PCDATA)> <!-- Information elements for provider --> <!ELEMENT providerName (#PCDATA)> <!ELEMENT providerIcon (#PCDATA)> <!ATTLIST providerIcon value NOTATION (B64JPG|B64GIF) #IMPLIED> <!ELEMENT wwwURL (#PCDATA)> <!ELEMENT generalMailtoURL (#PCDATA)> <!ELEMENT billingMailtoURL (#PCDATA)> <!-- Further provider elements according to RFC1274 --> <!ELEMENT businessCategory (#PCDATA)> <!ELEMENT x121Address (#PCDATA)> <!ELEMENT registeredAddress (#PCDATA)> <!ELEMENT destinationIndicator (#PCDATA)> <!ELEMENT preferredDeliveryMethod (#PCDATA)> <!ELEMENT telexNumber (#PCDATA)>Riegel & Zorn Standards Track [Page 27]RFC 3017 Roaming Access Phone Book XML DTD December 2000 <!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)> <!-- end of dtd -->8. Security Considerations The secure distribution and transport of information of a phone book for roaming applications require a reliable authentication of the issuer of the information as well as means to preserve the integrity of the provided information. No specific elements for security requirements are provided by the phone book XML DTD itself. It is assumed that security of the roaming phone book is provided by means outside of the scope of this specification, such as signing the phone book using pgp.9. IANA Considerations This specification provides the possibility to define further attribute values for all information elements owning enumerated attribute lists as well as to extend the main structures 'pop', 'setup', 'support' and 'provider' by additional information elements. Therefore the specification of the roaming phone book can be adopted to future requirements without changing this document. Extensions and refinements to this specification can be achieved by registration of new elements and attributes by IANA. Extending this specification with additional attributes or elements must not change the validity of documents based on an older version of the XML DTD. Therefore all added information elements must beRiegel & Zorn Standards Track [Page 28]RFC 3017 Roaming Access Phone Book XML DTD December 2000 optional, prohibiting the mandatory inclusion of newly defined information elements. Adding new values to enumerated attribute lists has no backward compatibility constraints because it does not harm the validity of attributes already defined. To facilitate the registration of new information elements and attribute values the DTD of the phone book has been separated in two parts, the extensible part containing only parameter entity declarations for ease inclusion of new values, and the fixed part containing the detailed specification of the content and structure of the phone book. By referencing the parameter entity declarations in the fixed part of the specification the whole phone book becomes extensible. The part containing the parameter entity declarations has to be maintained by the IANA. There are two different classes of declarations in this part requiring different policies for registering new values.9.1. Registration of new attribute values The entities 'addressFamily', 'modemProtocols', 'isdnProtocols', 'atmProtocols', 'frProtocols', 'x25Protocols', 'popProperties' and 'tunnelingProtocols' are describing enumerated attribute value lists. Because there is no limitation in the name space of these attribute values and newly defined attribute values can not harm the validity of existing values, new attribute values can be assigned by Specification Required [6].9.2. Registration of new information elements The entities 'mediaTypes', 'popInformation', 'setupInformation', ' supportInformation' and 'providerInformation' define the information elements probably included in the media, pop, setup, support and provider elements. Inserting new values into these lists extends the phone book by arbitrarily new information elements. Inappropriate use of the XML content model can destroy the backward compatibility of the DTD. Therefore the assignment of new information elements requires the approval of a Designated Expert [6]. In addition to the insertion of a new value into the list, the detailed definition of the information element has to be appended to the specification part maintained by the IANA.Riegel & Zorn Standards Track [Page 29]RFC 3017 Roaming Access Phone Book XML DTD December 200010. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. [3] Barker, P. and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991. [4] ITU Rec. E.123, "Notation for national and international telephone numbers", 1988. [5] "Extensible Markup Language (XML) 1.0" W3C Recommendation 10- February-1998 http://www.w3.org/TR/1998/REC-xml-19980210 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.Riegel & Zorn Standards Track [Page 30]RFC 3017 Roaming Access Phone Book XML DTD December 200011. Appendix: Examples11.1. The most simple example <?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>11.2. A more comprehensive example <?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. Acknowledgments Thanks to Pat Calhoun, Bernard Aboba, Jay Farhat, Butch Anton, Quentin Miller, and Ken Crocker for salient input and review.Riegel & Zorn Standards Track [Page 31]RFC 3017 Roaming Access Phone Book XML DTD December 200013. Authors' Addresses Questions about this memo can be directed to: Max Riegel Siemens AG Hofmannstr. 51 Munich, 81359 Germany Phone: +49 89 722 49557 EMail: maximilian.riegel@icn.siemens.de Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA Phone: +1 425 438 8218 EMail: gwz@cisco.comRiegel & Zorn Standards Track [Page 32]RFC 3017 Roaming Access Phone Book XML DTD December 200014. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.Riegel & Zorn Standards Track [Page 33]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -