rfc3859 common profile for presence (cpp).txt

有关IMS SIP及Presence应用的RFC文档包

RFC 3859              Common Profile for Presence            August 2004


   [8]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
        (S/MIME) Version 3.1 Message Specification", RFC 3851, July
        2004.

   [9]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
        July 2004.

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

7.2.  Informative References

   [11] Schaad, J., "Use of the Advanced Encryption Standard (AES)
        Encryption Algorithm and in Cryptographic Message Syntax (CMS)",
        RFC 3565, July 2003.



































Peterson                    Standards Track                    [Page 11]

RFC 3859              Common Profile for Presence            August 2004


Appendix A.  PRES URI IANA Registration Template

   This section provides the information to register the pres: presence
   URI .

A.1.  URI Scheme Name

   pres

A.2.  URI Scheme Syntax

   The syntax follows the existing mailto: URI syntax specified in RFC
   2368.  The ABNF is:

   PRES-URI         = "pres:" [ to ] [ headers ]
   to             =  mailbox
   headers        =  "?" header *( "&" header )
   header         =  hname "=" hvalue
   hname          =  *uric
   hvalue         =  *uric

   Here the symbol "mailbox" represents an encoded mailbox name as
   defined in RFC 2822 [3], and the symbol "uric" denotes any character
   that is valid in a URL (defined in RFC 2396 [10]).

A.3.  Character Encoding Considerations

   Representation of non-ASCII character sets in local-part strings is
   limited to the standard methods provided as extensions to RFC 2822
   [3].

A.4.  Intended Usage

   Use of the pres: URI follows closely usage of the mailto: URI.  That
   is, invocation of an PRES URI will cause the user's instant messaging
   application to start, with destination address and message headers
   fill-in according to the information supplied in the URI.

A.5.  Applications and/or Protocols which use this URI Scheme Name

   It is anticipated that protocols compliant with RFC 2779, and meeting
   the interoperability requirements specified here, will make use of
   this URI scheme name.








Peterson                    Standards Track                    [Page 12]

RFC 3859              Common Profile for Presence            August 2004


A.6.  Interoperability Considerations

   The underlying exchange protocol used to send an instant message may
   vary from service to service.  Therefore complete, Internet-scale
   interoperability cannot be guaranteed.  However, a service conforming
   to this specification permits gateways to achieve interoperability
   sufficient to the requirements of RFC 2779.

A.7.  Security Considerations

   See Section 4.

A.8.  Relevant Publications

   RFC 2779, RFC 2778

A.9.  Person & Email Address to Contact for Further Information

   Jon Peterson [mailto:[e-mail]]

A.10.  Author/Change Controller

   This scheme is registered under the IETF tree.  As such, IETF
   maintains change control.

A.11.  Applications and/or Protocols which use this URI Scheme Name

   Instant messaging service; presence service

Appendix B.  Issues of Interest

   This appendix briefly discusses issues that may be of interest when
   designing an interoperation gateway.

B.1.  Address Mapping

   When mapping the service described in this memo, mappings that place
   special information into the im: address local-part MUST use the
   meta-syntax defined in RFC2846 [7].

B.2.  Source-Route Mapping

   The easiest mapping technique is a form of source-routing and usually
   is the least friendly to humans having to type the string.  Source-
   routing also has a history of operational problems.






Peterson                    Standards Track                    [Page 13]

RFC 3859              Common Profile for Presence            August 2004


   Use of source-routing for exchanges between different services is by
   a transformation that places the entire, original address string into
   the im: address local part and names the gateway in the domain part.

   For example, if the destination INSTANT INBOX is "pepp://example.com/
   fred", then, after performing the necessary character conversions,
   the resulting mapping is:

             im:pepp=example.com/fred@relay-domain

   where "relay-domain" is derived from local configuration information.

   Experience shows that it is vastly preferable to hide this mapping
   from end-users - if possible, the underlying software should perform
   the mapping automatically.

Appendix C.  Acknowledgments

   The author would like to acknowledge John Ramsdell for his comments,
   suggestions and enthusiasm.  Thanks to Derek Atkins for editorial
   fixes.

Author's Address

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520
   US

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


















Peterson                    Standards Track                    [Page 14]

RFC 3859              Common Profile for Presence            August 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Peterson                    Standards Track                    [Page 15]