rfc3017.txt

RFC 的详细文档！

   <!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 be



Riegel & 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 2000


10.  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 2000


11.  Appendix: Examples

11.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">[phone]</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">[phone]</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:[e-mail]</supportMailtoURL>
         <supportTelephoneNumber>[phone]</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 2000


13.  Authors' Addresses

   Questions about this memo can be directed to:

   Max Riegel
   Siemens AG
   Hofmannstr. 51
   Munich, 81359
   Germany

   Phone:  [phone]
   EMail: [e-mail]


   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, WA 98004
   USA

   Phone:  [phone]
   EMail:  [e-mail]





























Riegel & Zorn               Standards Track                    [Page 32]

RFC 3017           Roaming Access Phone Book XML DTD       December 2000


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