Subject: Re: [VCARDDAV] Signed vCards

From: DataPacRat <[email-masked]>
Date: Tue, 20 Aug 2013 16:37:56 -0400

I know it's been a few weeks, but I'm still around, and working on an
upgrade to the vCard format in the time I have available for it.

I think I've figured out one last change worth discussing, before I
start putting everything together into a formal Internet Draft
submission: adjusting the URL property somewhat, to deal with multiple
URLs on different sites. (Or, put another way, to merge the existing
informal X-SOCIALPROFILE property into the URL property.)

An example: I am attached to the URLs of http://www.datapacrat.com/ ,
http://blog.datapacrat.com/ , http://blog.datapacrat.com/about/ ,
http://twitter.com/DataPacRat, and http://www.facebook.com/DataPacRat
, and www.facebook.com/profile.php?id=650281140 . To include them all
in a vCard, I might use:

URL:http://www.datapacrat.com/
URL:http://blog.datapacrat.com/
URL:http://blog.datapacrat.com/about/
URL:http://twitter.com/DataPacRat
URL:http://www.facebook.com/DataPacRat
URL:http://www.facebook.com/profile.php?id=650281140

Or, if I preferred them in a particular order, I might use:

URL;PREF=1:http://www.datapacrat.com/
URL;PREF=2:http://blog.datapacrat.com/
URL;PREF=3:http://blog.datapacrat.com/about/
URL;PREF=4:http://twitter.com/DataPacRat
URL;PREF=5:http://www.facebook.com/DataPacRat
URL;PREF=6:http://www.facebook.com/profile.php?id=650281140

While this gets the job done, it's not ideal, and I think there's a
fairly simple way to do better: allow the TYPE parameter to be used
for URL properties, the same way it can be for TEL. In RFC 6350,
section 6.4.1, some of the examples are:

     TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
     TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67

While "home" is explicitly described as one possibility for
type-param-tel , I would like TYPEs for URLs to be somewhat more
expandable, for future use as people keep coming up with creative
things to do online. For example:

URL;TYPE="homepage":http://www.datapacrat.com/
URL;TYPE="blog":http://blog.datapacrat.com/
URL;TYPE="profile":http://blog.datapacrat.com/about/
URL;TYPE="twitter,blog,im":http://twitter.com/DataPacRat
URL;TYPE="facebook,profile,blog,im";PREF=1:http://www.facebook.com/DataPacRat
URL;TYPE="facebook,profile,blog,im";PREF=2:http://www.facebook.com/profile.php?id=650281140

It seems like there should be some discussion about which values such
a set of TYPEs should initially be seeded with - "home" and "work" are
obvious and already part of RFC 6350, but "blog", "profile", "im",
"store", and "homepage" are simply the most obvious ones to me. And
I've seen a number of vCards which already use Type parameters with
site-names such as Twitter in their X-SOCIALPROFILE properties.

And, of course, it's possible I've ended up looking at this from
entirely the wrong angle, in which case I would really want to figure
that out now, instead of after I've started writing everything up
formally.

Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

---

From: Michael Angstadt <[email-masked]>
Date: Wed, 21 Aug 2013 09:12:00 -0400

I don't think "twitter" and "facebook" would be valid values for the TYPE
parameter.  The spec would have to be agnostic to any particular social
network.  Plus, you can easily tell that a URL points to a Facebook page or
Twitter profile by just looking at the domain name in the URL.

---

From: DataPacRat <[email-masked]>
Date: Wed, 21 Aug 2013 13:42:12 -0400

> Twitter profile by just looking at the domain name in the URL.

The point of including the servicename - if not as part of a TYPE
parameter, then as some other parameter - is to make it easy to have a
unique property-and-parameter set for every line in the vCard. This is
to allow for signed vCards which strongly authenticate a particular
set of lines rather than the whole vCard, identifying each line by its
particular property-and-parameter set. At present, the only way in
common usage to do that is with the PREF parameter, and that's not
exactly the job that parameter was designed to do - eg, I may not
actually prefer my Twitter account to my Facebook page, I just want
different p&p strings.

Perhaps in addition to allowing the URL property to accept TYPE
parameters, a new parameter could be defined, such as SOCIALMEDIA,
which allows for a relatively freeform text string as its value, to do
the job. (I'm picking that suggested name to ease the transition from
the current practice of using an X-SOCIALMEDIA property.)

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Sat, 24 Aug 2013 15:27:33 -0400

> the current practice of using an X-SOCIALMEDIA property.)

If no more feedback is forthcoming, then I'll go with the SOCIALMEDIA
parameter as a comma-separated list of values, which aren't limited to
a particular list, but can include "blog", "profile", "im", the names
of particular services, and so on.

Assuming that that's settled, I expect the next step will be for me to
put together a first draft of something to submit as an Internet
Draft. I'll start working on that next week. Once I have it fully
written out, should I post it here for further feedback, or just go
straight to the submission page at tools.ietf.org?

Thank you for your time,

---

From: Michael Angstadt <[email-masked]>
Date: Sat, 24 Aug 2013 17:25:47 -0400

Perhaps a whole new property could be created that's similar in nature to
the IMPP property.  IMPP allows for an instant messenger handle to be
specified in the form of a URI.  No individual IM protocols are mentioned
in the specs, so it is open-ended as to what its value can be.  For
example, the following defines an AOL Instant Messenger handle:

IMPP:aim:goim?screenname=JohnDoe

The SOCIALMEDIA property could be similarly open-ended.  Its TYPE parameter
could contain the categories that the particular property value adheres to.
 The default data type for the property would be a URI, but TEXT could also
be used specifying things like Twitter handles and Facebook names (shown
below).

SOCIALMEDIA;TYPE="homepage":http://www.datapacrat.com/
SOCIALMEDIA;TYPE="blog":http://blog.datapacrat.com/
SOCIALMEDIA;TYPE="profile":http://blog.datapacrat.com/about/
SOCIALMEDIA;TYPE="twitter,blog,im";VALUE=text:@DataPacRat
SOCIALMEDIA;TYPE="facebook,profile,blog,im";PREF=1;VALUE=text:DataPacRat
SOCIALMEDIA;TYPE="facebook,profile,blog,im";PREF=2:
http://www.facebook.com/profile.php?id=650281140

Just throwing ideas out there.

---

From: DataPacRat <[email-masked]>
Date: Sat, 24 Aug 2013 19:37:11 -0400

> specified in the form of a URI.  No individual IM protocols are mentioned in
> the specs, so it is open-ended as to what its value can be.  For example,
> the following defines an AOL Instant Messenger handle:
>
> SOCIALMEDIA;TYPE="facebook,profile,blog,im";PREF=2:http://www.facebook.com/profile.php?id=650281140
>

This approach has the advantage that it takes the current practice of
using X-SOCIALMEDIA, and regularizes and formalizes it.

I'm not /entirely/ sure that using VALUE=text is the best way to
signal a non-URI value, but I'm not yet sure what a better approach
might be. If I don't think of anything else, it has the advantage of
actually working. :)

I do wonder, though, whether this approach makes the URL property
practically irrelevant - and if so, whether that matters. Any
thoughts?

Thank you for your time,

---

From: Evert Pot <[email-masked]>
Date: Sun, 25 Aug 2013 00:53:30 +0100

> SOCIALMEDIA;TYPE="facebook,profile,blog,im";PREF=2:http://www.facebook.com/profile.php?id=650281140

This is a bit off-topic, but I want to point your attention to this:

http://www.rfc-editor.org/errata_search.php?rfc=6350&eid=3100

I don't know wether or not a recommendation has come from that errata, but my gut tells me that this:

SOCIALMEDIA;TYPE="twitter","blog","im";VALUE=text:@DataPacRat

Should be the correct syntax.

Alternatively, use the following unambiguous formats:

SOCIALMEDIA;TYPE=twitter,blog,im;VALUE=text:@DataPacRat
SOCIALMEDIA;TYPE="twitter";TYPE="blog";TYPE="im";VALUE=text:@DataPacRat

Aside from that, what I am personally curious about, is wether the intention of this spec is to provide an initial registry of values such as 'twitter' and 'facebook', or wether the intention is to leave it completely open.

In the former case, I wonder if it is proper to give certain companies an advantage in being added to that registry, whereas lesser known websites/businesses are put at a disadvantage. It's my belief that specific brands have to place in the vcard specification, but I realize that this is more an argument towards academic purity.

If the intention is to not include specific trademarks, but rather make this a free-form field. I'd want to point out that we already have a much better registry for this, namely: uri's.

Evert

---

From: DataPacRat <[email-masked]>
Date: Sat, 24 Aug 2013 20:16:50 -0400

> SOCIALMEDIA;TYPE="twitter";TYPE="blog";TYPE="im";VALUE=text:@DataPacRat

In RFC 6350, section 8, is a sample vCard, which contains the lines:

    TEL;VALUE=uri;TYPE="work,voice";PREF=1:tel:+1-418-656-9254;ext=102
    TEL;VALUE=uri;TYPE="work,cell,voice,video,text":tel:+1-418-262-6501

I was using this as my inspiration when I put the full social-media
lists in a single pair of quotes, instead of a pair of quotes for each
particular item.

> If the intention is to not include specific trademarks, but rather make this a free-form field. I'd want to point out that we already have a much better registry for this, namely: uri's.

My current plan is not to mention any particular service by name in
the formal draft's specifications; but to allow for a vCard writer to
use service names as they see fit, including services which have yet
to be invented. (Eg, Vine didn't exist a couple of years ago, but is
now gaining popularity.) I'm reasonably likely to include a couple of
the more popular services in examples, such as the above-shown Twitter
and Facebook, for illustrative purposes.

I just ran a quick Google search for 'vcard x-socialprofile', and the
top result was http://www.gagfactory.com/who/nathan_labhart.vcf . This
includes a few lines:

X-SOCIALPROFILE;type=twitter:http://twitter.com/shanghailecture
X-SOCIALPROFILE;type=twitter:http://twitter.com/nlabhart
X-SOCIALPROFILE;type=facebook:https://www.facebook.com/nlabhart

This suggests that, whatever any particular theory might say, there's
some use being made of having service-names as part of the
property-and-paramter strings, even if that information can be derived
from the value. I try to make it a habit to pave the sidewalks on the
trails people create when they walk, when such trails are available;
so, one way or another, I'd like to use the established habits of
people and programs who use X-SOCIALPROFILE, and use those as a guide
for this part of the Signed vCard spec.

Thank you for your time,

---

From: Cyrus Daboo <[email-masked]>
Date: Sat, 24 Aug 2013 20:45:18 -0400

Hi Michael,

> IMPP:aim:goim?screenname=JohnDoe

An earlier proposal to try and address that: 
<http://tools.ietf.org/id/draft-daboo-vcard-service-type-00.txt>. There was 
not much interest at the time so it never went anywhere.

-- 
Cyrus Daboo

---

From: DataPacRat <[email-masked]>
Date: Sun, 25 Aug 2013 14:11:00 -0400

> SOCIALMEDIA;TYPE="facebook,profile,blog,im";PREF=2:http://www.facebook.com/profile.php?id=650281140

I think I have an alternate approach that's somewhat easier to use:

If the value of the SOCIALMEDIA property is a URI, then that URI is
treated as any other URI.

If SOCIALMEDIA contains a TYPE of a social profile provider, and the
value isn't a well-formed URI, then that value is assumed to be some
form of personal identifier (such as a username) in whatever format
that social profile provider prefers. That is, all of these would be
valid:

SOCIALMEDIA;TYPE=twitter:http://twitter.com/DataPacRat
SOCIALMEDIA;TYPE=twitter:@DataPacRat
SOCIALMEDIA;TYPE=twitter:DataPacRat

Somewhat relatedly, I have a note jotted down that it's still an open
question whether to use SOCIALMEDIA or SOCIALPROFILE ...

Thank you for your time,

---

From: Kevin Marks <[email-masked]>
Date: Sun, 25 Aug 2013 11:11:23 -0700

It's worth looking at previous efforts here, in particular sgnodemapper,
which has empirical URL structure knowledeg fro multiple social networks:
https://code.google.com/p/google-sgnodemapper/
It defines these URL types:
https://code.google.com/p/google-sgnodemapper/source/browse/trunk/url_types.txt

You should implement "ident_to_<foo>" for the following URL types:

rss -- of content

atom -- of content

profile -- the "profile" page of the user, with their bio/pic/overview, etc

content -- the HTML content page of the user. may be their profile. whatever

the notable thing on this site normally is. for myspace, for instance,

this is the profile page, since blogs aren't commonly used/linked

on myspace.

blog -- url to their blog.

chat -- chat URL. likely "aim:" or "xmpp:" or "callto:", etc.

openid -- openid identity URL (either the actual identity for openid 1.x, or

the base site for openid 2.0 directed identity)

addfriend -- URL to add them

foaf -- URL to foaf document

'feed' -- tries first atom, then rss

site-specific info is recorded here:
https://code.google.com/p/google-sgnodemapper/source/browse/trunk/sites/Also,
Portable Contacts defines canonical values of 'blog' and 'profile' in
addition to home, work and other:
http://portablecontacts.net/draft-spec.html#anchor17 These are followed by
OpenSocial as well:
http://opensocial.github.io/spec/2.5/Social-Data.xml#Person

On Sat, Aug 24, 2013 at 4:53 PM, Evert Pot <[email-masked]>wrote:

> Aside from that, what I am personally curious about, is wether the
> intention of this spec is to provide an initial registry of values such as
> 'twitter' and 'facebook', or wether the intention is to leave it completely
> open.
>
> In the former case, I wonder if it is proper to give certain companies an
> advantage in being added to that registry, whereas lesser known
> websites/businesses are put at a disadvantage. It's my belief that specific
> brands have to place in the vcard specification, but I realize that this is
> more an argument towards academic purity.
>
> If the intention is to not include specific trademarks, but rather make
> this a free-form field. I'd want to point out that we already have a much
> better registry for this, namely: uri's.
>
> Evert
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Michael Angstadt <[email-masked]>
Date: Sun, 25 Aug 2013 14:28:01 -0400

> practically irrelevant - and if so, whether that matters. Any

To me, SOCIALPROFILE would only be applicable to those technologies which
are referred to as "social media."  To me, the term "social media"
encapsulates activities that involve the *high frequency*, *reciprocal*
sharing of information and ideas with *people of your choosing*, whether
this information is of a personal or professional nature.  For example, a
LinkedIn account would be considered "social media" because it revolves
around not only broadcasting your professional skills, but reading about
the professional skills of your colleagues and asking others to join your
network.  A company website or personal homepage, by contrast, does not
involve this reciprocal, "back-and-forth" sharing of information.  It is
more like publishing a book--people take information away, but give no
information back.  Other examples of services which I personally consider
to be social media are: Facebook, Twitter, LinkedIn, Vine, Instagram,
Flickr, MySpace, Reddit.

Blogs are a mixed bag--you don't ask people to "join your network" with a
blog.  But blogs do allow for readers to comment on postings, and bloggers
frequently respond to the blog posts of other bloggers, making the
information exchange fairly reciprocal in that regard.

TL;DR - Company websites and personal homepages should continue to use the
URL property, while (I guess) everything else should use the SOCIALPROFILE
property.

> Should be the correct syntax.

It is an error in the spec.  Putting double quotes around all values
technically makes it a single value (the quotes escape the comma
characters).  The following examples all use valid syntax:

SOCIALMEDIA;TYPE="twitter","blog","im";VALUE=text:@DataPacRat
SOCIALMEDIA;TYPE=twitter,blog,im;VALUE=text:@DataPacRat
SOCIALMEDIA;TYPE=twitter,"blog",im;VALUE=text:@DataPacRat
SOCIALMEDIA;TYPE="twitter";TYPE=blog;TYPE="im";VALUE=text:@DataPacRat

On Sat, Aug 24, 2013 at 8:45 PM, Cyrus Daboo <[email-masked]> wrote:

> An earlier proposal to try and address that: <http://tools.ietf.org/id/**
> draft-daboo-vcard-service-**type-00.txt<http://tools.ietf.org/id/draft-daboo-vcard-service-type-00.txt>>.
> There was not much interest at the time so it never went anywhere.
>
>
Having a SERVICE-TYPE parameter would be useful for IM protocols which are
used by a variety of service providers, such as "xmpp".  Fortunately, none
of these problems exist for email, as it has become a generic, widely
adopted protocol!

-Mike

On Sat, Aug 24, 2013 at 8:45 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi Michael,
>
>
> --On August 24, 2013 at 5:25:47 PM -0400 Michael Angstadt <
> [email-masked]> wrote:
>
>> IMPP:aim:goim?screenname=**JohnDoe
>>
>
> An earlier proposal to try and address that: <http://tools.ietf.org/id/**
> draft-daboo-vcard-service-**type-00.txt<http://tools.ietf.org/id/draft-daboo-vcard-service-type-00.txt>>.
> There was not much interest at the time so it never went anywhere.
>
> --
> Cyrus Daboo
>
>

---

From: DataPacRat <[email-masked]>
Date: Sun, 25 Aug 2013 17:30:17 -0400

> URL property, while (I guess) everything else should use the SOCIALPROFILE

I can certainly live with guidelines along those lines.

I'm going to try an experiment. I've assembled the rough notes on
signed vCards, mostly from these emails, on a Google Doc; and turned
on public commenting and editing, at
https://docs.google.com/document/d/1OnvQ6MsKUvCCdCdUqARLK2FbLuAsNMqq9ZbWQ-fvvi4/edit?usp=sharing
. I'm going to try using that to generate the text to submit to
Idnits. If that doesn't work out (such as due to trolls), then I'll
turn off public editing and/or start again from one of my backup
copies. No harm done if it doesn't work, and maybe something positive
will result.

(Looking at what I've noted down so far, it's actually not all that
big an expansion to vCard: 6 new properties, and 2 new parameters.)

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Thu, 29 Aug 2013 20:19:50 -0400

> big an expansion to vCard: 6 new properties, and 2 new parameters.)

As a text file, what I have written down so far passes the nit
checker, with one exception that I don't know how to do anything
about:

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == Couldn't figure out when the document was first submitted -- there may
     comments or warnings related to the use of a disclaimer for pre-RFC5378
     work that could not be issued because of this.  Please check the Legal
     Provisions document at http://trustee.ietf.org/license-info to determine
     if you need the pre-RFC5378 disclaimer.

I think I'm just about ready to submit it to
https://datatracker.ietf.org/submit/ ... but before I do, it seems
worthwhile to pause for a day or so, and see if anyone cares to point
out whatever embarrassing errors I might have left in. So - have I
done anything which really should be changed before I make the draft
submission official?

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Fri, 30 Aug 2013 03:35:04 -0400

> copies. No harm done if it doesn't work, and maybe something positive

Since there's been no feedback yet, I've gone ahead and submitted the
thing. What happens next, happens next.

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Sat, 31 Aug 2013 14:36:21 -0400

> thing. What happens next, happens next.

Someone mentioned to me offline that they wanted to see a fully-worked
example; so I've added one. I've also cleaned up a few small
formatting items. (
https://datatracker.ietf.org/doc/draft-boese-vcarddav-signedvcard/ )

Thank you for your time,

---

From: DataPacRat <[email-masked]>
Date: Sun, 1 Sep 2013 00:58:57 -0400

Would it be within reason for me to use the following as an example
for the DATE parameter?

N;DATE=1987-12-17/2013-08-22:Bradley
N;DATE=2013-08-22:Chelsea
GENDER;DATE=1987-12-17/2013-08-22::M
GENDER;DATE=2013-08-22:F

Thank you for your time,