idnits 2.17.1 draft-ietf-vcarddav-social-networks-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-03) exists of draft-ietf-vcarddav-oma-cab-extensions-00 -- Obsolete informational reference (is this intentional?): RFC 2425 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 4770 (Obsoleted by RFC 6350) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 vcarddav R. George 3 Internet-Draft B. Leiba 4 Intended status: Standards Track K. Li 5 Expires: April 26, 2012 Huawei Technologies 6 A. Melnikov 7 Isode Limited 8 October 24, 2011 10 vCard Format Extension : To Represent the Social Network Information of 11 an Individual 12 draft-ietf-vcarddav-social-networks-00 14 Abstract 16 This document defines an extension to the vCard data format for 17 representing and exchanging a variety of social network information. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 26, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Terminology Used in This Document . . . . . . . . . . . . . 3 56 2. Social Network Properties . . . . . . . . . . . . . . . . . 3 57 2.1. Property: OPENID . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Property: SOCIALPROFILE . . . . . . . . . . . . . . . . . . 5 59 2.3. Property: ALBUM . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Property: DEPICTION . . . . . . . . . . . . . . . . . . . . 6 61 2.5. Property: SOCIALCODE . . . . . . . . . . . . . . . . . . . . 8 62 2.6. Property: INTEREST . . . . . . . . . . . . . . . . . . . . . 9 63 2.7. Property: XX . . . . . . . . . . . . . . . . . . . . . . . . 10 65 3. Security Considerations . . . . . . . . . . . . . . . . . . 10 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 69 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 5.1. Normative References . . . . . . . . . . . . . . . . . . . . 11 71 5.2. Informative References . . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 [[anchor1: Barry: This version is still very incomplete. I have 78 included some comments in the appropriate places with the XML "cref" 79 element, so they will show up within "[[ ]]", as this one does. I am 80 still working on these, and I also want to put in a lot more 81 properties (see Peter's comment, below).]] 83 As social networking has become common, it has become clear that 84 users would like to include information in their vCards [RFC6350] 85 about their social networks. Well organized social network 86 information allows the vCard owner to share his profile information 87 and to import or subscribe to profile information of others on 88 joining a new network. 90 This extension takes some property definitions from the vCard OMA CAB 91 Extensions [I-D.ietf-vcarddav-oma-cab-extensions], and that document 92 should be considered as a prerequisite to this one. 94 1.1. Terminology Used in This Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. These 99 terms take their normative meaning only when presented in ALL CAPS. 101 Syntax specifications shown here use the augmented Backus-Naur Form 102 (ABNF) as described in [RFC5234], and are specified as in the base 103 vcard specification [RFC6350]. 105 2. Social Network Properties 107 These properties are related to sharing social-network information. 108 The basis for some of these properties came from the "Friend of a 109 Friend" specification [FOAF], and we thank the authors of that 110 document for their work. 112 [[anchor2: Barry: Are there more FoaF items we want to include?]] 114 [[anchor3: Peter StA: There are many "social networking" properties 115 outside of FOAF, so using only what's currently in FOAF is somewhat 116 limiting. Borrowing from http://xmpp.org/extensions/xep-0154.html 117 I'd mention at least the following...]] 119 [[anchor4: a. URLs for avatar (or actual avatar data), biography, 120 online status or presence, publication list, photo site, resume / CV, 121 weblog, wishlist]] 123 [[anchor5: b. personal attributes like eye color, hair color, height, 124 weight, marital status, smoker / non-smoker, zodiac sign (both 125 Chinese and Western), psychological profile (e.g., Myers-Briggs Type 126 Indicator)]] 128 [[anchor6: c. other interesting facts such as areas of expertise, 129 clubs of which the object is a member, charitable organizations 130 supported, dietary preferences, hobbies, interests, profession, 131 religious affiliation]] 133 [[anchor7: d. various favorite things, such as activities, authors, 134 individual athletes as well as sports teams, beverages, charitable 135 organizations, chatrooms / IRC channels / forums, foods, games, 136 movies, music, places, quotes, TV shows, weblogs, websites]] 138 [[anchor8: e. places lived, schools attended, conferences attended 139 (complete list of all IETF meetings you've been to?), etc.]] 141 [[anchor9: The list goes on!]] 143 [[anchor10: Clearly there is a *lot* of information that one could 144 include under the "social networking" umbrella. I don't know how 145 much of that possible universe the authors wish to represent here.]] 147 [[anchor11: (Personally I'd be willing to help define a broader set 148 of properties than the few already included here, since I did quite a 149 bit of thinking about the topic several years ago when working on 150 XEP-0154.)]] 152 2.1. Property: OPENID 154 [[anchor12: Barry: Maybe this should be something like 155 "authentication;type=openid:" instead? That would allow for other 156 authentication types.]] 158 Namespace: 160 Property name: OPENID 162 Purpose: OpenID is an open, decentralized user identification 163 standard, allowing users to log onto many services with the same 164 digital identity. Inclusion of an OpenID URI in a vCard lets 165 others add the vCard owner's ID to their authorization lists. 166 [[anchor13: Barry: We should add an informative reference to 167 OpenID.]] 169 Value type: A single URI value. 171 Cardinality: * 173 Property parameters: (none) 175 Description: 177 Format definition: 178 OPENID-param = pid-param / pref-param / 179 any-param 180 OPENID-value = uri 182 Example: 184 OPENID:http://www.alice.openid.example.org 186 2.2. Property: SOCIALPROFILE 188 [[anchor14: Dany: SERVICE in OMA-CAB and SOCIALPROFILE here seem very 189 similar and both need more details on LABEL for SERVICE or on TYPE 190 for SOCIALPROFILE. To me, SERVICE (in OMA-CAB) is more complete.]] 192 [[anchor15: Simon: I see significant overlap among the following: 193 SOCIALPROFILE (from here), SERVICE (from OMA-CAB), SERVICE-TYPE (from 194 draft-daboo-vcard-service-type). I would expect the authors to work 195 amongst themselves on merging those proposals, or at least 196 eliminating the overlap (e.g. reusing parts defined in another 197 draft).]] 199 Namespace: 201 Property name: SOCIALPROFILE 203 Purpose: Designates the vCard owner's profile page on a particular 204 social network. 206 Value type: A single URI value. 208 Cardinality: * 210 Property parameters: TYPE 212 Description: This property SHOULD include the parameter "TYPE" to 213 specify the name of the social network that it refers to. 214 Usually, that will also be discernible from the URI, which is why 215 it's optional. But it can be helpful to have it specified 216 explicitly. 218 Format definition: 219 SOCIALPROFILE-param = pid-param / pref-param / 220 any-param 221 SOCIALPROFILE-value = uri 223 Examples: 225 SOCIALPROFILE;type=linkedin:http://www.linkedin.com/in/barryleiba 227 SOCIALPROFILE;type=facebook:http://www.facebook.com/barackobama 229 2.3. Property: ALBUM 231 Namespace: 233 Property name: ALBUM 235 Purpose: Designates an online album, such as a photo album or video 236 album. 238 Value type: A single URI value. 240 Cardinality: * 242 Property parameters: TYPE 244 Description: This property SHOULD include the parameter "TYPE" to 245 specify the type of album that it refers to. Usually, that will 246 also be discernible from the URI, which is why it's optional. 247 But it can be helpful to have it specified explicitly. 249 Format definition: 250 ALBUM-param = pid-param / pref-param / 251 any-param 252 ALBUM-value = uri 254 Example: 256 ALBUM;type=photo:http://picasaweb.google.com/barryleiba 257 ALBUM;type=video:http://www.youtube.com/user/barryleiba 259 2.4. Property: DEPICTION 261 [[anchor16: Barry: After reading the FoaF description of "depiction", 262 I get the point now, I think. I've re-written this to take a stab at 263 it. I've included a reference to a corporate logo, but Simon points 264 out that we also have LOGO in the base, so maybe that part shouldn't 265 be here.]] 266 Namespace: 268 Property name: DEPICTION 270 Purpose: To note that the referenced URI depicts, in come way, the 271 entity represented by this vCard. 273 Value type: A single URI value. 275 Cardinality: * 277 Property parameters: 279 Description: DEPICTION can be used to point to images in online 280 photo galleries, specifying which ones include the subject of 281 this vCard (perhaps in addition to other people or things). 283 DEPICTION might also be used to refer to videos, icons, avatars, 284 or the like. Consider someone's avatars in virtual worlds, or 285 one or more corporate logos in a vCard representing a company. 287 This is distinct from the PHOTO property, in that the latter is 288 meant to define a specific representation of the vCard subject (a 289 "profile photo", or a publicity headshot, say), while DEPICTION 290 might often be used to say that the subject appears in a group 291 photo or in a photo that is primarily a picture of something or 292 someone else. 294 Format definition: 295 DEPICTION-param = pid-param / pref-param / 296 any-param 297 DEPICTION-value = uri 299 Example: Suppose a gallery contains the following photos: 300 IMG_001.jpg: Alexey and Barry at a reception. 301 IMG_002.jpg: Alexey, Chris, and Dave having a conversation. 302 IMG_003.jpg: Barry making a comment in the plenary session. 303 IMG_004.jpg: A meeting session that Alexey, Barry, Chris, 304 Dave, and Eric are all attending. 306 Barry's vCard might include the following: 308 DEPICTION:http://www.example.com/pub/photos/IMG_001.jpg 309 DEPICTION:http://www.example.com/pub/photos/IMG_003.jpg 310 DEPICTION:http://www.example.com/pub/photos/IMG_004.jpg 312 2.5. Property: SOCIALCODE 314 [[anchor17: Simon: The use of the TYPE parameter here is 315 underspecified. It isn't clear whether the TYPE value is a free-form 316 string of if it needs to be registered somewhere. Will it be 317 displayed to the user?]] 319 Namespace: 321 Property name: SOCIALCODE 323 Purpose: Description of the vCard owner, in the form of a "social 324 code", such as the "geek code" (see 325 http://en.wikipedia.org/wiki/Geek_code). Social codes are 326 popularly used to exchange a large amount of social information 327 in a compact way, and provide a somewhat frivolous and willfully 328 obscure "fun" mechanism for characterizing technical expertise, 329 interests, and habits. 331 Value type: A single text value. 333 Cardinality: * 335 Property parameters: TYPE 337 Description: This property MUST include the parameter "TYPE" to 338 specify the type of social network code being used. There are no 339 predefined values for "TYPE", here -- the types will be 340 understood (or not) by the vCard users. 342 Implementations need to be especially careful with character 343 quoting in this property, because these codes tend to use odd 344 characters, and many might require quoting [RFC6350]. 346 Format definition: 347 SOCIALCODE-param = pid-param / pref-param / 348 any-param 349 SOCIALCODE-value = text 351 Example: 353 SOCIALCODE;type=geek:"s: a--" 355 [Which means "I'm average size, and my age is 20-24."] 357 2.6. Property: INTEREST 359 [[anchor18: Dany: INTEREST is defined both here and in OMA-CAB. Both 360 definitions have interesting parameters (INDEX and LEVEL in OMA-CAB 361 and TYPE here). To me, these 2 definitions may be combined.]] 363 Namespace: 365 Property name: INTEREST 367 Purpose: Lists the vCard owner's interests (social, recreational, 368 technical, etc.). This allows users to identify others with 369 common interests. 371 Value type: A string value consisting of one or more text values 372 separated by a COMMA character (ASCII decimal 44). 374 Cardinality: * 376 Property parameters: TYPE, LANGUAGE 378 Description: This property MAY include the parameter "TYPE" to group 379 interests in categories. TYPE might be used to separate 380 "business" interests from "social" interests, for example. There 381 are no predefined values for "TYPE", here -- the types will be 382 understood (or not) by the vCard users, and it's likely that an 383 ad hoc taxonomy will develop, as has happened with social 384 tagging. 386 [[anchor19: Simon: I think this is fine, but please specify 387 whether this string is intended to be displayed to the user or 388 not. (In the base spec, it is not intended to be displayed 389 as-is. Instead, we expect the vCard app to understand the TYPE 390 value and show something appropriate (either text or an icon). 391 This is made possible because there is a registry of allowed 392 values that defines their semantics.)]] 394 Format definition: 395 INTEREST-param = pid-param / pref-param / 396 any-param 397 INTEREST-value = text 399 Example: 401 INTEREST;type=business:Internet standards,consulting,job offers 402 INTEREST;type=social:friends and family,new friends 403 INTEREST;type=hobby:model trains,reading Sci Fi,travel 404 INTEREST;type=music:classical,jazz,folk,opera 406 2.7. Property: XX 408 [[anchor20: Template for adding another property, because we expect 409 to add more properties here. Remove this section before 410 publishing.]] (This will also hold some references for the time 411 being: [RFC2425] [RFC2426] [RFC2739] [RFC4770] ) 413 Namespace: 415 Property name: 417 Purpose: 419 Value type: A single text value. 421 Cardinality: * 423 Property parameters: VALUE, LANGUAGE 425 Description: 427 Format definition: 428 XX-param = pid-param / pref-param / 429 any-param 430 XX-value = text 432 Example: 434 xx:zz 436 3. Security Considerations 438 This presents no security considerations beyond those in section 9 of 439 the base vcard specification [RFC6350]. 441 [[anchor21: Barry: I'm quite sure there's more to say here, and that 442 there are some real security (and privacy) considerations, so this is 443 just a placeholder. We need to think about this seriously before 444 we're done.]] 446 4. IANA Considerations 448 The IANA is requested to add the following entries to the vCard 449 Properties registry, defined in [RFC6350] section 10.3.1. 451 +-----------+---------------+------------------------+ 452 | Namespace | Property | Reference | 453 +-----------+---------------+------------------------+ 454 | | OPENID | RFCXXXX, section 2.1 | 455 | | SOCIALPROFILE | RFCXXXX, section 2.2 | 456 | | ALBUM | RFCXXXX, section 2.3 | 457 | | DEPICTION | RFCXXXX, section 2.4 | 458 | | SOCIALCODE | RFCXXXX, section 2.5 | 459 | | INTEREST | RFCXXXX, section 2.6 | 460 +-----------+---------------+------------------------+ 462 5. References 464 5.1. Normative References 466 [I-D.ietf-vcarddav-oma-cab-extensions] 467 Cauchie, D., Leiba, B., and K. Li, "vCard Format extension 468 : represent vCard extensions defined by the Open Mobile 469 Alliance (OMA) Converged Address Book (CAB) group", 470 draft-ietf-vcarddav-oma-cab-extensions-00 (work in 471 progress), October 2011. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 477 Specifications: ABNF", STD 68, RFC 5234, January 2008. 479 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 480 August 2011. 482 5.2. Informative References 484 [FOAF] Brickley, D. and L. Miller, "FOAF Vocabulary Specification 485 0.98", August 2010, . 487 Namespace Document, Marco Polo Edition 489 [RFC2425] Howes, T., Smith, M., and F. Dawson, "A MIME Content-Type 490 for Directory Information", RFC 2425, September 1998. 492 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 493 RFC 2426, September 1998. 495 [RFC2739] Small, T., Hennessy, D., and F. Dawson, "Calendar 496 Attributes for vCard and LDAP", RFC 2739, January 2000. 498 [RFC4770] Jennings, C. and J. Reschke, Ed., "vCard Extensions for 499 Instant Messaging (IM)", RFC 4770, January 2007. 501 Authors' Addresses 503 Robins George 504 Huawei Technologies 505 Bangalore, Karnataka 560071 506 India 508 Phone: +91-080-41117676 509 Email: robinsgv@gmail.com 511 Barry Leiba 512 Huawei Technologies 514 Phone: +1 646 827 0648 515 Email: barryleiba@computer.org 516 URI: http://internetmessagingtechnology.org/ 518 Kepeng Li 519 Huawei Technologies 520 Huawei Base, Bantian, Longgang District 521 Shenzhen, Guangdong 518129 522 P. R. China 524 Phone: +86-755-28974289 525 Email: likepeng@huawei.com 527 Alexey Melnikov 528 Isode Limited 529 5 Castle Business Village 530 36 Station Road, Hampton Middlesex TW12 2BX 531 UK 533 Email: Alexey.Melnikov@isode.com 534 URI: http://www.melnikov.ca/