rfc2806.txt

<VC++网络游戏建摸与实现>源代码

   Also, when writing the phone number in the form described in this
   specification, the writer does not need to know which part of the
   number is the country code and which part is the area code. If a
   hierarchical URL would be used (with a "/" character separating the
   parts of the phone numbers), the writer of the URL would have to know
   which parts are which.





Vaha-Sipila                 Standards Track                    [Page 16]

RFC 2806                URLs for Telephone Calls              April 2000


   Finally, when phone numbers are written in the international form as
   specified here, they are unambiguous and can always be converted to
   the local dialing convention, given that the user agent has the
   knowledge of the local country and area codes.

2.7.4 Not everyone has the same equipment as you

   There are several ways for the subscriber to dial a phone number:

     - By pulse dialing. Typically old telephone exchanges. Usually this
     dialing method has only to be used to set up the call; after
     connecting to the remote entity, <post-dial> can be sent to the
     line using DTMF, because it will typically be processed by the
     remote entity, not the telephone network.

     - By DTMF. These are the 'beeps' that you hear when you dial on
     most phones.

     - By direct network signalling. ISDN subscribers and mobile phone
     users usually have this. There is no dial tone (or if there is, it
     is generated locally by the equipment), and the number of the
     called party is communicated to the telephone network using some
     network signalling method. After setting up the call, <post-dial>
     sequences are usually sent using DTMF codes.

2.7.5 Do not confuse numbers with how they are dialled

   As an example, [phone] will be dialled in many countries as
   00123456789, where the leading "00" is a prefix for international
   calls. However, if a URL contains a local phone number 00123456789,
   the user-agent MUST NOT assume that this number is equal to a global
   phone number [phone]. If a user-agent received a telephony URL
   with a local number in it, it MUST make sure that it knows the
   context in which the local phone number is to be processed, or else
   the number MUST NOT be used. Equally, anyone sending a telephony URL
   MUST take into consideration that the recipient may have insufficient
   information about the phone number's context.

3. Comments on usage

   These are examples of the recommended usage of this URL in HTML
   documents.

   First of all, the number SHOULD be visible to the end user, if it is
   conceivable that the user might not have a local entity which is able
   to use these URLs.

     Telephone: <a href="tel:[phone]">[phone]</a>



Vaha-Sipila                 Standards Track                    [Page 17]

RFC 2806                URLs for Telephone Calls              April 2000


   Second, on a public HTML page, the telephone number in the URL SHOULD
   always be in the international form, even if the text of the link
   uses some local format.

     Telephone: <a href="tel:[phone]">[phone]</a>

   or even

     For more info, call <a href="tel:[phone]">1-555-IETF-RULZ-
     OK</a>.

   Moreover, if the number is a <local-phone-number>, and the scope of
   the number is not clear from the context in which the URL is
   displayed, a human-readable explanation SHOULD be included.

     For customer service, dial <a href="tel:1234;phone-
     context=+358555">1234</a> (only from Terrific Telecom mobile
     phones).

4. References

   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
             Specification", STD 13, RFC 1035, November 1987.

   [RFC1738] Berners-Lee, T., et al., "Uniform Resource Locators (URL)",
             RFC 1738, December 1994.

   [RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language
             - 2.0", RFC 1866, November 1995.

   [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
             Internet Mail Extensions (MIME) Part Four: Registration
             Procedures", RFC 2048, November 1996.

   [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234] Crocker, D. and P. Overall, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234, November 1997.

   [RFC2303] Allocchio, C., "Minimal PSTN Address Format in Internet
             Mail", RFC 2303, March 1998.

   [RFC2304] Allocchio, C., "Minimal FAX Address Format in Internet
             Mail", RFC 2304, March 1998.






Vaha-Sipila                 Standards Track                    [Page 18]

RFC 2806                URLs for Telephone Calls              April 2000


   [RFC2396] Berners-Lee, T., R. Fielding and L. Manister, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

   [RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
             Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
             March 1999.

   [E.123]   ITU-T Recommendation E.123: Telephone Network and ISDN
             Operation, Numbering, Routing and Mobile Service: Notation
             for National and International Telephone Numbers. 1993.

   [E.164]   ITU-T Recommendation E.164/I.331 (05/97): The International
             Public Telecommunication Numbering Plan. 1997.

   [T.33]    ITU-T Recommendation T.33: Facsimile Routing Utilizing the
             Subaddress. 1996.

5. Security Considerations

   It should be noted that the local entity SHOULD NOT call out without
   the knowledge of the user because of associated risks, which include

   - call costs (including long calls, long distance calls,
     international calls and premium rate calls, or calls which do not
     terminate due to <post-dial> sequences that have been left out by
     the local entity)

   - wrong numbers inserted on web pages by malicious users, or sent via
     e-mail, perhaps in direct advertising

   - making the user's phone line unavailable (off-hook) for a malicious
     purpose

   - opening a data call to a remote host, thus possibly opening a back
     door to the user's computer

   - revealing the user's (possibly unlisted) phone number to the remote
     host in the caller identification data, and correlating the local
     entity's phone number with other information such as the e-mail or
     IP address

   - using the same local number in different contexts, in which the
     number may have a different meaning

   All of these risks MUST be taken into consideration when designing
   the local entity.




Vaha-Sipila                 Standards Track                    [Page 19]

RFC 2806                URLs for Telephone Calls              April 2000


   The local entity SHOULD have some mechanism that the user can use to
   filter out unwanted numbers. The local entity SHOULD NOT use rapid
   redialing of the number if it is busy to avoid the congestion of the
   (signaling) network. Also, the local entity SHOULD detect if the
   number is unavailable or if the call is terminated before the dialing
   string has been completely processed (for example, the call is
   terminated while waiting for user input) and not try to call again,
   unless instructed by the user.

6. Acknowledgements

   Writing this specification would not have been possible without
   extensive support from many people.

   Contributors include numerous people from IETF FAX, PINT, URI and
   URLREG mailing lists, as well as from World Wide Web Consortium and
   several companies, plus several individuals. Thanks to all people who
   offered criticism, corrections and feedback.

   All phone numbers and company names used in the examples of this
   specification are fictional. Any similarities to real entities are
   coincidental.

7. Author's Address

   Antti Vaha-Sipila
   (quoted-printable: Antti V=E4h=E4-Sipil=E4)
   Nokia Mobile Phones
   P. O. Box 68
   FIN-33721 Tampere
   Finland

   EMail: [e-mail]
          [e-mail]

















Vaha-Sipila                 Standards Track                    [Page 20]

RFC 2806                URLs for Telephone Calls              April 2000


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



















Vaha-Sipila                 Standards Track                    [Page 21]