summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6473.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6473.txt')
-rw-r--r--doc/rfc/rfc6473.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc6473.txt b/doc/rfc/rfc6473.txt
new file mode 100644
index 0000000..813def1
--- /dev/null
+++ b/doc/rfc/rfc6473.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) P. Saint-Andre
+Request for Comments: 6473 Cisco
+Category: Standards Track December 2011
+ISSN: 2070-1721
+
+
+ vCard KIND:application
+
+Abstract
+
+ This document defines a value of "application" for the vCard KIND
+ property so that vCards can be used to represent software
+ applications.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6473.
+
+Copyright Notice
+
+ Copyright (c) 2011 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 1]
+
+RFC 6473 vCard KIND:application December 2011
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Meaning .........................................................2
+ 3. Example .........................................................4
+ 4. IANA Considerations .............................................4
+ 5. Security Considerations .........................................4
+ 6. Acknowledgements ................................................5
+ 7. References ......................................................5
+ 7.1. Normative References .......................................5
+ 7.2. Informative References .....................................5
+
+1. Introduction
+
+ Version 4 of the vCard specification [RFC6350] defines a new KIND
+ property to specify the type of entity that a vCard represents.
+ During its work on the base vCard4 specification, the VCARDDAV
+ Working Group defined values of "individual", "organization",
+ "group", and "location" for the KIND property. The working group
+ considered but then removed a value of "thing" to represent any type
+ of physical entity, machine, software application, etc., with the
+ expectation that such a value might be defined in a vCard extension.
+ This document does not define a generic "thing" value but instead
+ defines a more narrow "application" value so that vCards can be used
+ to represent software applications.
+
+2. Meaning
+
+ When the KIND property has a value of "application", the vCard
+ represents a software application such as a server, an online service
+ (e.g., a chat room), or an automated software bot. More formally, an
+ "application" is functionally equivalent to the 'applicationProcess'
+ object class used in the Lightweight Directory Access Protocol
+ [RFC4519] as derived from the Open Systems Interconnection model
+ [X.521] [X.200]. As one example of the "application" KIND, vCards
+ are currently used in the Extensible Messaging and Presence Protocol
+ [RFC6120] to represent instant messaging servers that are deployed on
+ the network.
+
+ The properties included in an application's vCard apply to one of the
+ following:
+
+ o The application itself (e.g., the FN property might represent the
+ friendly name of an application service, the URL property might
+ represent a website that contains further information about the
+ service, and the ADR, GEO, and TZ properties might represent the
+ physical address, geographical location, and time zone of the
+ machine where the service is hosted).
+
+
+
+Saint-Andre Standards Track [Page 2]
+
+RFC 6473 vCard KIND:application December 2011
+
+
+ o An organization or person that makes the application available on
+ the network (e.g., the LOGO property might represent the corporate
+ logo of a service provider).
+
+ o A person or role that maintains the application (e.g., the TEL,
+ EMAIL, and IMPP properties might represent ways to contact a
+ server administrator).
+
+ When a property represents some aspect of the application itself, it
+ makes no sense to include the "work" and "home" values of the TYPE
+ parameter since software applications do not have work places and
+ personal lives (see the definition of the TYPE parameter in Section
+ 5.6 of [RFC6350]). When a property represents information about an
+ individual associated with the application (e.g., an individual
+ service administrator as opposed to a generic service administrator
+ role or an associated organization), inclusion of the "work" and
+ "home" values can be appropriate.
+
+ The following base properties make sense for vCards that represent
+ software applications (this list is not exhaustive, and other
+ properties might be applicable as well):
+
+ o ADR
+ o EMAIL
+ o FN
+ o GEO
+ o IMPP
+ o KEY
+ o KIND
+ o LANG
+ o LOGO
+ o NOTE
+ o ORG
+ o PHOTO
+ o REV
+ o SOURCE
+ o TEL
+ o TZ
+ o URL
+
+ Although it might be desirable to define a more fine-grained taxonomy
+ of applications (e.g., a KIND of "application" with a subtype of
+ "server" or "IM server"), such a taxonomy is out of the scope of this
+ document.
+
+
+
+
+
+
+
+Saint-Andre Standards Track [Page 3]
+
+RFC 6473 vCard KIND:application December 2011
+
+
+3. Example
+
+ The following example of an Extensible Messaging and Presence
+ Protocol (XMPP) server is borrowed from [XEP-0292]. The XML
+ representation of the vCard is described in [RFC6351], which allows
+ for the use of the new "application" value using the "iana-token"
+ production defined in [RFC6350].
+
+ <vcard xmlns="urn:ietf:params:xml:ns:vcard-4.0">
+ <fn><text>jabber.org IM service</text></fn>
+ <url><uri>http://www.jabber.org/</uri></url>
+ <lang>
+ <parameters><pref><integer>1</integer></pref></parameters>
+ <language-tag>en</language-tag>
+ </lang>
+ <email><text>xmpp@jabber.org</text></email>
+ <impp><uri>xmpp:jabber.org</uri></impp>
+ <logo><uri>http://www.jabber.org/images/logo.png</uri></logo>
+ <geo><uri>geo:42.25,-91.05</uri></geo>
+ <tz><text>America/Chicago</text></tz>
+ <source><uri>xmpp:jabber.org?vcard</uri></source>
+ <rev><timestamp>19990104T122100Z</timestamp></rev>
+ <kind><text>application</text></kind>
+ </vcard>
+
+4. IANA Considerations
+
+ IANA has added "application" to the registry of property values for
+ vCard4. In conformance with Section 10.2.6 of [RFC6350], the
+ registration is as follows, where the reference is to RFC 6473.
+
+ Value: application
+
+ Purpose: The entity represented by the vCard is a software
+ application (e.g., a server, an online service such as a chat
+ room, or an automated software bot).
+
+ Conformance: This value can be used with the KIND property.
+
+ Example: See Section 3 of RFC 6473.
+
+5. Security Considerations
+
+ Use of vCards to represent software applications is not envisioned to
+ introduce security considerations beyond those specified for vCards
+ in general as described in [RFC6350].
+
+
+
+
+
+Saint-Andre Standards Track [Page 4]
+
+RFC 6473 vCard KIND:application December 2011
+
+
+6. Acknowledgements
+
+ Thanks to Cyrus Daboo, Barry Leiba, Kepeng Li, and Simon Perreault
+ for their feedback.
+
+7. References
+
+7.1. Normative References
+
+ [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
+ August 2011.
+
+7.2. Informative References
+
+ [RFC4519] Sciberras, A., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519,
+ June 2006.
+
+ [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
+ Protocol (XMPP): Core", RFC 6120, March 2011.
+
+ [RFC6351] Perreault, S., "xCard: vCard XML Representation",
+ RFC 6351, August 2011.
+
+ [X.200] International Telecommunications Union, "Information
+ Technology - Open Systems Interconnection - Basic
+ Reference Model: The Basic Model", ITU-T Recommendation
+ X.200, ISO Standard 7498-1, July 1994.
+
+ [X.521] International Telecommunications Union, "Information
+ Technology - Open Systems Interconnection - The
+ Directory: Selected Object Classes", ITU-T Recommendation
+ X.521, ISO Standard 9594-7, November 2008.
+
+ [XEP-0292] Saint-Andre, P. and S. Mizzi, "vCard4 over XMPP", XSF
+ XEP 0292, October 2011.
+
+Author's Address
+
+ Peter Saint-Andre
+ Cisco
+ 1899 Wynkoop Street, Suite 600
+ Denver, CO 80202
+ USA
+
+ Phone: +1-303-308-3282
+ EMail: psaintan@cisco.com
+
+
+
+
+Saint-Andre Standards Track [Page 5]
+