RFC 6473

vCard KIND:application

📅 published December 2011, from ietf

RFC 6473: vCard KIND:application 💖

okay bestie, this one's from the IETF and it's a Standards Track doc, so it's the real deal 🫶 It was written by Peter Saint-Andre at Cisco and dated December 2011. It's ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so there's nothing to flag there ✨

Abstract 🌸

this doc defines an application value for the vCard KIND property, so vCards can be used to represent software applications 💻✨

Status of This Memo 📋

this is an Internet Standards Track document 🎀

it's a product of the IETF, it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. more info on Internet Standards is in Section 2 of RFC 5741.

info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6473 🔗

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. please actually read these, they spell out your rights and restrictions for this doc 🙈

any Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come without warranty, as described in the Simplified BSD License.

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 ✨

okay so version 4 of the vCard spec [RFC6350] adds a new KIND property that says what type of entity a vCard represents 🧚

while the VCARDDAV Working Group was building the base vCard4 spec, they defined "individual", "organization", "group", and "location" as KIND values. they also considered a "thing" value for any physical entity, machine, software application, and so on 🤔 they took it out, expecting that an extension might define it later.

this doc doesn't define that generic "thing" value. instead it defines a narrower "application" value, so vCards can represent software applications 💅

2. Meaning 🦋

when KIND is "application", the vCard represents a software application, like a server, an online service (for example, a chat room), or an automated software bot 🤖

more formally, "application" is functionally equivalent to the applicationProcess object class in the Lightweight Directory Access Protocol [RFC4519], which is derived from the Open Systems Interconnection model [X.521] [X.200]. one example: vCards are already used in the Extensible Messaging and Presence Protocol [RFC6120] to represent instant messaging servers deployed on the network 💬

the properties in an application's vCard can apply to any of these:

  • the application itself. for example, FN could be the friendly name of a service, URL could point to a site with more info, and ADR, GEO, and TZ could be the physical address, location, and time zone of the machine hosting it 🖥️
  • an organization or person that makes the application available on the network. for example, LOGO could be the corporate logo of a service provider 🏢
  • a person or role that maintains the application. for example, TEL, EMAIL, and IMPP could be ways to reach a server admin 📞
when a property is about the application itself, using the "work" and "home" values of the TYPE parameter makes no sense, since software applications don't have work places or personal lives 💀 (see the definition of the TYPE parameter in Section 5.6 of [RFC6350]). but when a property is about an individual tied to the application, like a specific service admin instead of a generic admin role or an associated org, including "work" and "home" can be appropriate.

these base properties make sense for vCards that represent software applications. this list isn't exhaustive, and other properties might fit too:

  • ADR
  • EMAIL
  • FN
  • GEO
  • IMPP
  • KEY
  • KIND
  • LANG
  • LOGO
  • NOTE
  • ORG
  • PHOTO
  • REV
  • SOURCE
  • TEL
  • TZ
  • URL

a more fine-grained taxonomy of applications could be nice, like a KIND of "application" with a subtype of "server" or "IM server". but that kind of taxonomy is out of scope for this doc 🙃

3. Example 🍓

this example of an XMPP server is borrowed from [XEP-0292] 💜 the XML form of the vCard is described in [RFC6351], which lets you use the new "application" value via the "iana-token" production from [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 🌈 following Section 10.2.6 of [RFC6350], the registration looks like this, with the reference pointing 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 🔐

okay this part is serious, bestie 😭 the doc says using vCards to represent software applications isn't expected to bring in any security considerations beyond the ones already specified for vCards in general, as described in [RFC6350]. so go check out [RFC6350] for the full security story 🛡️

6. Acknowledgements 🫶

huge 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

that's the whole RFC, bestie! 🌈✨👑

📦 where this page comes from