Subject: [VCARDDAV] portable contacts

From: "Joseph Smarr" <[email-masked]>
Date: Tue, 2 Dec 2008 17:36:29 -0800

Hi everyone, I wanted to make you aware of a community effort called
Portable Contacts (http://portablecontacts.net) that shares many of the same
goals as this group and has already had some promising initial success in
gaining traction.

Portable Contacts was created in the context of related grass-roots
standards like OpenID and OAuth to provide a common, vendor-neutral schema,
protocol, and workflow for letting users access their address book and
friends-list info from any service, with a focus on ease of implementation
and interoperability with existing standards. Our first draft spec was
published in May 2008, and we've since gone through a few revisions, with
active participation from individuals in the grass-roots community and from
many companies including Google, Yahoo, Microsoft, MySpace, Plaxo, AOL, Sony
Ericsson, and others. We've also worked with the OpenSocial community to
wire-align the "accessing people data" part of the OpenSocial RESTful
Protocol, so any OpenSocial container supporting those APIs is also by
definition a Portable Contacts Provider (and several already are).

More information about Portable Contacts (including the current rev of the
draft spec) can be found at http://portablecontacts.net as well as on our
mailing list http://groups.google.com/group/portablecontacts. I've also now
published Portable Contacts as an IETF I-D (
http://www.ietf.org/internet-drafts/draft-smarr-vcarddav-portable-contacts-00.txt)
to facilitate communication here.

I recently came across the I-D to provide an XML schema for vCard as part of
the vcarddav working group (
http://tools.ietf.org/id/draft-perreault-vcarddav-vcardxml-00.txt) and
realized that the vcarddav community is also working on many of these same
challenges. Since I think we both share the goal of creating a widespread
standard for accessing contact information online, I'm sure we will both
benefit from talking together and learning from the work we've each done so
far. In fact, looking at the charter for vcarddav, the Portable Contacts
community shares your goal of creating "An address book access protocol
leveraging the vCard data format" and "An XML schema which is semantically
identical to vCard in all ways and can be mechanically translated to and
from vCard format without loss of data", and I think we've made great
progress on both of those goals.

We started with the vCard schema as the core of Portable Contacts, but
expressed in JSON and XML bindings to take advantage of those
developer-friendly and widely used formats, while preserving the semantic
definitions of vCard. We've also added in additional contact fields to more
fully represent the types of data typically describing people on modern
social networking sites, thus spanning the gap between traditional address
books and "social graphs". And we've specified an end-to-end workflow for
discovery, authentication, and access of contact information (drawing on
XRDS-Simple, HTTP Basic and/or OAuth, and a simple REST-like protocol,
respectively), so that a would-be consumer of contact info can "walk up and
use" any compliant provider their user wishes.

I've chatted briefly so far with Marc Blanchet and Lisa Dusseault so far,
but I'd love to hear from the rest of the group on how Portable Contacts
does or doesn't meet the goals of this working group, and where you see
opportunities for our two communities to work together, perhaps even
combining some or all of our specs. I will also do my homework and learn
more about the current state of CardDAV, and please send any
questions/feedback you have on Portable Contacts to this list and/or the
Portable Contacts mailing list, which any of you are free to join.

Thanks! It's great to meet more people that are "fighting the good fight"
for portable contact information! :) js

--
Joseph Smarr
Chief Platform Architect, Plaxo
http://josephsmarr.com
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: Helge Hess <[email-masked]>
Date: Thu, 4 Dec 2008 00:28:31 +0100

On 03.12.2008, at 02:36, Joseph Smarr wrote:
> Portable Contacts (http://portablecontacts.net) that shares many of  
> the same goals as this group
...
> I've chatted briefly so far with Marc Blanchet and Lisa Dusseault so  
> far, but I'd love to hear from the rest of the group on how Portable  
> Contacts does or doesn't meet the goals of this working group,

Since a core aspect/idea of CardDAV is using WebDAV/HTTP as the core  
layer, I'm not entirely sure how that "PortableContacts" thing fits in  
at all.

> and where you see opportunities for our two communities to work  
> together, perhaps even combining some or all of our specs.

The only thing which looks somewhat common is the "vCard schema as the  
core of Portable Contacts, but expressed in JSON and XML".
It would be good to have standardized JSON and XML representations for  
vCards (and HTTP server could deliver them if requested via Accept).

Personally I would love to see more XML vCards, but to be realistic -  
parsing/generating (valid) vCards is rather trivial too and there are  
plenty of FOSS libraries for that task.

Besides that I'm not sure. I guess from my perspective Portable  
Contacts should just use CardDAV instead of working on yet another  
contact sharing protocol? :-)

Greets,
   Helge
-- 
http://zideone.com/

---

From: Andy Mabbett <[email-masked]>
Date: Thu, 4 Dec 2008 00:38:26 +0000

In message <[email-masked]>,
Helge Hess <[email-masked]> writes

>I guess from my perspective Portable  Contacts should just use CardDAV
>instead of working on yet another  contact sharing protocol?

I haven't checked (it's late here, I'm tired, and my web connection is
flaky), but I suspect the devil is in this detail:

        In message
        <[email-masked]>,
        Joseph Smarr <[email-masked]> writes

        >We've also added in additional contact fields to more fully
        >represent the types of data typically describing people on
        >modern social networking sites

Perhaps an annotated list of these additional "contact fields" could be
provided?

-- 
Andy Mabbett
            says  "NO! to compulsory UK ID Cards":  <http://www.no2id.net/>
            and:  "Free Our Data":  <http://www.freeourdata.org.uk>
                   (both also on Facebook)
_______________________________________________
VCARDDAV mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vcarddav

---

From: "Joseph Smarr" <[email-masked]>
Date: Wed, 3 Dec 2008 17:36:59 -0800

Helge-thanks for your feedback! As I read the charter of this WG, the only
thing explicitly mentioning the use of DAV is the following deliverable:

"An address book access protocol leveraging the vCard data format. The
Internet-draft draft-daboo-carddav will be the starting point."

I absolutely agree that "An address book access protocol leveraging the
vCard data format" is an important goal for the web, and I'm proposing
Portable Contacts as a solution to that goal. It's true that it's not using
daboo-carddav as a starting point, but I believe it's consistent with the
goals of this WG, and it provides a contrast with the DAV approach in that
it's lighter-weight and more in keeping with the latest best practices in
API and protocol design, at least in the consumer internet world (e.g. use
of flexible bindings to JSON or simple XML, minimal toolchain requirements
for developers, ability to "try it out in a web browser", etc.) So I would
like this WG to consider the tradeoffs in these approaches to determine how
they can influence one another, and/or how they can at least play well
together.

I certainly agree with you that common XML/JSON representation of vCard is a
good place to start--no need for more than one answer to this important
problem, for sure! And I strongly disagree with you that parsing/generating
(valid) vCards is rather trivial"--with all due respect, the syntax is
archaic, anachronistic, picky, and poorly supported, certainly when compared
with JSON or XML. I work at Plaxo where we've done address book sync with
nearly every major software and online address book, often using vCard as
the interchange format (e.g. as the SyncML payload), and I can't tell you
the number of bugs, headaches, and interop problems it's casued along the
way for everyone, just because of its syntax. The FOSS support is uneven at
best, whereas every popular language can easily work with JSON and
XML--indeed, the reason for these latter specs was to solve the "wire-format
for simple structured data" problem once and for all.

I strongly believe that vCard would be more widely adopted if there were a
commonly recognized JSON and XML rendering of that data, with easy
transformers to and from the old vCard syntax. And that's exactly what we've
done with Portable Contacts. We took the vCard spec directly, and took pains
to maintain a robust one-to-one mapping with our JSON/XML
representation--just modernized some of the spellings (e.g. "adr" -->
"addresses") and picked an easily extensible representation, e.g. "emails":
[ { "value": "[email-masked]", "type": "work"}, { ... } ] that clearly
dileneates singular vs. plural fields, provides room to invent new fields
and new meta-data, and can trivially be transformed to and from actual
vCards. This is similar to the approach taken by hCard in the microformats
community, and confers similar benefits--for instance, we can easily turn
any web page with hCard markup into a vCard, then use that vCard as the
"backing store" for a Portable Contacts endpoint, and thus e.g. allow
consumers to query a user's twitter followers using the rich
filteting/paging/etc features of Portable Contacts, but with no additional
work on twitter's part (for a demo of this, see http://bit.ly/longpipe,
where the JSON output is put thru a final filter to render it as an HTML
outline). We can do the same in reverse, and pipe any Portable Contact
output into a vCard converter that lets a user download those contacts
easily into their address book.

So I think and hope that we're more aligned than it might seem at first
given our different historical/technical legacy, and I'm optimistic that we
can at least agree on a good common schema, and perhaps go further by making
the "address book access" portion of CardDAV compatible with Portable
Contacts, or at least trivial to add in front of CardDAV as a thin adapter.

Thanks, js

On Wed, Dec 3, 2008 at 3:28 PM, Helge Hess <[email-masked]>wrote:

>> Portable Contacts (http://portablecontacts.net) that shares many of the
>> same goals as this group
>>
> ...
>
>> does or doesn't meet the goals of this working group,
>>
>
> Since a core aspect/idea of CardDAV is using WebDAV/HTTP as the core layer,
> I'm not entirely sure how that "PortableContacts" thing fits in at all.
>
>  and where you see opportunities for our two communities to work together,
>> perhaps even combining some or all of our specs.
>>
>
> The only thing which looks somewhat common is the "vCard schema as the core
> of Portable Contacts, but expressed in JSON and XML".
> parsing/generating (valid) vCards is rather trivial too and there are plenty
> of FOSS libraries for that task.
>
>
> Besides that I'm not sure. I guess from my perspective Portable Contacts
> should just use CardDAV instead of working on yet another contact sharing
> protocol? :-)
>
> Greets,
>  Helge
> --
> http://zideone.com/

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Dec 2008 21:11:12 -0500

Hi Joseph,

--On December 3, 2008 5:36:59 PM -0800 Joseph Smarr <[email-masked]> 
wrote:

> Portable Contacts as a solution to that goal. It's true that it's not
> using daboo-carddav as a starting point, but I believe it's consistent
> with the goals of this WG, and it provides a contrast with the DAV
> approach in that it's lighter-weight and more in keeping with the latest
> best practices in API and protocol design, at least in the consumer
> internet world (e.g. use of flexible bindings to JSON or simple XML,
> minimal toolchain requirements for developers, ability to "try it out in
> a web browser", etc.) So I would like this WG to consider the tradeoffs
> in these approaches to determine how they can influence one another,
> and/or how they can at least play well together.

The key thing is "play well together". Several groups have already invested 
time and effort in CardDAV implementations - certainly if this WG choose 
not to proceed with the spec at this point, I would end up re-submitting it 
as an individual submissions so that existing implementers have a stable 
specification to implement off.

That said, without having read your spec in detail, there is no reason why 
the two cannot co-exist. The debate of WebDAV vs Atom vs Restful HTTP vs 
"the latest fancy way of using HTTP" protocol will go on forever - its just 
the natural progression of the evolution of the web as a whole. At the end 
of the day all these are simply an HTTP-based protocol to access data - 
what is more important is the nature and semantics of the data itself.

-- 
Cyrus Daboo

---

From: "Joseph Smarr" <[email-masked]>
Date: Wed, 3 Dec 2008 18:15:33 -0800

Sure, it's listed in the Portable Contacts spec (
http://portablecontacts.net/draft_spec.html starting at section 7.2.1) and
happy to provide a "crib sheet" here. :)

First of all, I think the way we represent vCard in JSON and XML is worth
looking at--it's different than the I-D for an XML schema first put to this
WG, and we've thought a lot about how to make it maximally easy and
predictable to comprehend and parse, while also being maximally extensible.
For instance, all the Singular Fields are spelled in singular form, and have
string/object values (e.g. "birthday": "1981-02-24") whereas all the Plural
Fields are spelled in plural form, and always have array values (e.g.
"emails": [ { "value": "[email-masked]", "type": "work"}, { ... } ]), even
if there happens to only be one value present. This way, someone looking at
sample output can immediately tell how to structure their code, without
having to read the spec in detail, and they will never get a rude surprise
of a field changing from an array to an object, etc. Also, we never use XML
attributes, since this way the core schema is just simple key-value pairs,
arrays, and dictionaries, which can be easily and unambiguously represented
in both JSON and XML, as well as in dynamic-typed languages like PHP,
Python, Ruby, etc. whose native data structures have the same limitations.
Thus there is virtually no "parsing/generating code" needed--just build your
object the way you'd want to work with it in your code, and then just
serialize it to JSON or XML using the built-in tools you already have.

We also took the step of "modernizing" some of the field-name spellings
(sorry the slight redundancy with the previous email reply I sent, but just
to be clear I'll repeat it here), e.g. "adr" --> "addresses" and "tel" -->
"phoneNumbers", which we think will further ease comprehension and
adoptability. We considered keeping the strict vCard names, but many
developers find them confusing and unintuitive, and since we were already
modernizing the syntax, and keeping a strict one-to-one mapping with vCard,
we felt it was worthwhile and a good choice to also update the spellings. So
that also differs from the proposals so far in this WG.

In terms of additional fields we added, there are two classes: additional
"core contact info" and "social networking fields" that you probably won't
find in Outlook, but will certainly find in MySpace and Facebook (the latter
of which, clearly also maintain some core contact info). Part of our goal
with Portable Contacts was to bridge the gap between "traditional address
book" and "modern social network" since in reality the set of fields overlap
quite a bit, and they're both metatadata about people you know, so it really
makes sense to have a common, encompassing standard. So with that in mind,
here are the changes and additions we made:

Singular fields:

 - id (renamed from uid)
 - displayName (renamed from fn)
 - name (renamed from n, contains the broken-out name pieces as sub-fields:
familyName, givenName, middleName, honorificPrefix, honorificSuffix)
 - published (created time of this record, name taken from AtomPub)
 - updated (last-modified time of this record, name taken from AtomPub)
 - birthday (updated from bday, and specifying "YYYY-MM-DD" or "0000-MM-DD"
if year is ommitted)
 - anniversary (added, same format as bday)
 - gender (added, with canonical values "male" or "female" but other values
allowed)
 - preferredUsername (online nickname preferred by user on most sites, e.g.
"jsmarr")
 - utcOffset (simple representation of "current timezone", e.g. to know when
to call someone, specified to use the offset portion of XSD DateTime, e.g.
"-07:00")
 - connected (boolean indicating whether the owner of the address book and
this contact have established a bi-directional connection on this site, vs.
this contact just being in the owner's address book)
 ...and we also imported the additional Singular Fields from OpenSocial,
which itself surveyed the common fields on most social networks: aboutMe,
bodyType, currentLocation, drinker, ethnicity, fashion, happiestWhen, humor,
livingArrangement, lookingFor, profileSong, profileVideo,
relationshipStatus, religion, romance, scaredOf, sexualOrientation, smoker,
and status

Plural fields:

- emails (renamed from email)
 - urls (renamed from url)
 - phoneNumbers (renamed from tel)
 - ims (added, with canonical "type" values specified for aim, gtalk, icq,
xmpp, msn, skype, qq, and yahoo.)
 - photos (added, with URL values, tho I believe vCard has a Singular photo
property with inline data as the value)
 - tags (renamed from categories)
 - relationships (added, specifying bi-directionally agreed-upon
relationships made on the social network, e.g. "family", "co-worker", etc.
and drawn from XFN where possible)
 - addresses (renamed from adr)
 - organizations (added, merging in both the traditional "job title" and
"company" with additional "work history" fields like startDate, endDate,
location, etc.)
 - accounts (added, describing the other accounts the user has around the
web, specified as domain name and either userid or username)
... and we also imported the OpenSocial plural fields: activities, books,
cars, children, food, heroes, interests, jobInterests, languages,
languagesSpoken, movies, music, pets, politicalViews, quotes, sports,
turnOffs, turnOns, and tvShows.

I realize this looks like a lot, but it all fits very well with vCard and
the evolution of contact information on the web, and I hope it's clear that
we've put a lot of thought and care into this spec and the detailed choices
we made. :)

Thanks, js

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 03 Dec 2008 21:21:07 -0500

Hi Joseph,

--On December 3, 2008 6:15:33 PM -0800 Joseph Smarr <[email-masked]> 
wrote:

> the evolution of contact information on the web, and I hope it's clear
> that we've put a lot of thought and care into this spec and the detailed
> choices we made. :)

Is it an exact one-to-one map with vCard, or are there specific differences 
you are aware of?

-- 
Cyrus Daboo

---

From: Dan Brickley <[email-masked]>
Date: Thu, 04 Dec 2008 02:24:36 +0000

Cyrus Daboo wrote:

> That said, without having read your spec in detail, there is no reason 
> why the two cannot co-exist. The debate of WebDAV vs Atom vs Restful 
> HTTP vs "the latest fancy way of using HTTP" protocol will go on forever 
> - its just the natural progression of the evolution of the web as a 
> whole. At the end of the day all these are simply an HTTP-based protocol 
> to access data - what is more important is the nature and semantics of 
> the data itself.

Well said. This is my only big reservation w.r.t. Portable Contacts: the 
current spec does several things all bundled together. It defines a 
schema; both for vCard-ish properties, but also for much of the 
social-networking vocabulary created by the Open Social project. This is 
a major piece of work. It also defines bindings into JSON and XML, with 
perhaps a slight bias towards the JSON flavour. And then it gives us a 
network access protocol too; although apparently not yet an updates 
spec. I'd feel a little more comfortable if the schema and protocol were 
more separate, so that other (eg. extension) vocabularies could also be 
accessed via essentially the same mechanism, or so that the schema and 
its inevitable extensions could be re-used in other protocol contexts 
such as CardDAV and SPARQL/RDF.

For my part, I intend to make some fixes to the FOAF RDF vocabulary to 
bring it closer to the Portable Contacts design in its treatment of 
contact/addressbook data. I doubt we can use exactly the same names 
(since RDF conventions around plural fields would make this seem odd), 
but (like Joseph) I'll do my best to ensure 1:1 relationships to the 
names used in PC, so that data in FOAF/RDF form can be transformed back 
into PC and vCard more easily.

cheers,

Dan

--
http://danbri.org/

---

From: "Joseph Smarr" <[email-masked]>
Date: Wed, 3 Dec 2008 18:35:16 -0800

The only thing we did that would cause a "lossy transform" with vCard is we
dropped support for the "po box" and "extended address" sub-fields of
address, favoring instead a possibly multi-line "street address" sub-field.
We did this because in our experience, few if any major address book tools
support those fields, and their semantics are also somewhat unclear, whereas
it's common to store the full street address as a single field (or as
"street address line 1", "street address line 2", etc. which can be easily
composed into a multi-line street address). None of the major address book
providers objected to this (in fact many welcomed it as a needed
"modernization" of vCard), but it is a slight breaking of vCard, though of
course one could include those fields in valid Portable Contacts output if
one wanted, since it permits providing additional fields that are up to the
consumer to interpret or ignore.

We also chose to drop standard defined values for some vCard fields that we
felt empirically did not get much use, and/or caused more confusion in terms
of their use and semantics than the value they provided (all in the name of
"ease of adoptability"). Those fields were: LABEL (our "addresses" has a
"formatted" sub-field that can hold a fully-formatted address, which I
believe is the intended semantics and common use of LABEL), MAILER, TZ (we
use utcOffset, which I believe confers most of the value while avoiding the
hornets-nest of full timezone representation/support), GEO, ROLE, LOGO,
AGENT, PRODID, REV, SORT-STRING, SOUND, CLASS, KEY. If people here feel
strongly about some of these fields (i.e. that developers will clamor for a
way to represent these in XML), it's of course easy to add them back in,
provided the semantics are clear and sensible (for instance, I think
location-based services are on the rise, so I could see putting GEO back in
now).

Thanks, js

---

From: Dan Brickley <[email-masked]>
Date: Thu, 04 Dec 2008 02:46:24 +0000

Joseph Smarr wrote:
> Sure, it's listed in the Portable Contacts spec 
> (http://portablecontacts.net/draft_spec.html starting at section 7.2.1) 
> and happy to provide a "crib sheet" here. :)
> 
> First of all, I think the way we represent vCard in JSON and XML is 
> worth looking at--it's different than the I-D for an XML schema first 
> put to this WG, and we've thought a lot about how to make it maximally 
> easy and predictable to comprehend and parse, while also being maximally 
> extensible. 

Re extensibility hooks, it would be great if you could define a 
namespace URI for the core XML vocabulary. It will help with versioning, 
but also with defining a mapping into RDF (whether FOAF or your own RDF 
vocabulary), which in turn helps (I'd argue) with mixing this data with 
data in other independently managed namespaces.

> In terms of additional fields we added, there are two classes: 
> additional "core contact info" and "social networking fields" that you 
> probably won't find in Outlook, but will certainly find in MySpace and 
> Facebook (the latter of which, clearly also maintain some core contact 
> info). Part of our goal with Portable Contacts was to bridge the gap 
> between "traditional address book" and "modern social network" since in 
> reality the set of fields overlap quite a bit, and they're both 
> metatadata about people you know, so it really makes sense to have a 
> common, encompassing standard. 

I agree and disagree :) I think it makes sense for us to have a common 
framework and common *protocols*, query systems etc for all this data.

Putting it all into one flat namespace scares me though. The social 
networking space is so rich, and varied, that the varieties of data 
you'll encounter and want to represent are going to eclipse those of 
'core addressbooks' massively. It will be very hard to know where to 
stop w.r.t. expanding the core.

eg. how much resume information do we want in this core? We can describe 
where people work. Perhaps also where they worked before. Their roles 
there? Their skills, expertise, qualifications? Who their line manager 
was? How much dating information do we want in this core? We can 
describe gender, plain text 'looking for' preferences, ... but some 
sites will want to store and exchange and query and filter on much more 
than this. How much geographic precision do we want?  etc etc

 > which itself surveyed the common fields on most social networks:
 > aboutMe, bodyType, currentLocation, drinker, ethnicity, fashion,
 > happiestWhen, humor, livingArrangement, lookingFor, profileSong,
 > profileVideo, relationshipStatus, religion, romance, scaredOf,
 > sexualOrientation, smoker, and status

Each of these fields dips a toe into an ocean of complexity, especially 
when developing a standard for global use. I've been watching and 
admiring the way OpenSocial's schema has been developing, pretty 
bottom-up from the deployed practice of social network sites. But the 
fact remains that on each of these topics, there is always going to be a 
lot more to say. And different parties will want various extensions, 
qualifications and so on in different places. Putting it all in the core 
seems impossible but I don't think I fully understand the extensibility 
model / plan yet.

>  - gender (added, with canonical values "male" or "female" but other 
> values allowed)

(This is the same design as FOAF; last time I looked, vCard was simple 
binary M/F.)

> relationships made on the social network, e.g. "family", "co-worker", 
> etc. and drawn from XFN where possible)

This is interesting. The bi-directionality aspect suggests that the 
values of this field need to be confirmed by the party being described, 
or rather by the relevant account holder on some social site. So if I 
have my sister tagged as my sister in MacOSX addressbook somehow, would 
I be breaking the semantics of these relationship fields by exporting 
this information without her (or an accountholder claiming to be her) 
explicit confirmation?  This seems to mix some critical provenance and 
trust issues directly into the schema design. Did you consider a more 
dictionary-like approach: simply define what 'co-worker' means and leave 
confirmation/validation as a seperate aspect of all fields.

> I realize this looks like a lot, but it all fits very well with vCard 
> and the evolution of contact information on the web, and I hope it's 
> clear that we've put a lot of thought and care into this spec and the 
> detailed choices we made. :)

You have indeed, and I'm sorry not to have made time to comment sooner. 
Even if I seem grumbly here I'm very glad to see this effort taking off. 
  It plugs some gaps we have in the FOAF world quite nicely, and also 
begins the larger conversation about bridging addressbook and 
social-network-site datasets...

cheers,

Dan

---

From: "Joseph Smarr" <[email-masked]>
Date: Wed, 3 Dec 2008 18:47:14 -0800

I agree that Portable Contacts is trying to do several things at once, and I
also agree that it might make sense to separate some of these pieces
out--e.g. separating the schema from the access protocol--to maximize
adoption of those pieces. But we feel it's very important to solve the
"end-to-end problem" of a user being able to tell a web site or application
"I already have a profile, address book, and/or friends-list over on site X,
go use it please", which involves discovery, authentication, an access API,
and a common data format. If you drop any one of these pieces, you force
developers to do one-off vendor-specific implementations of whatever piece
in this chain they did differently, at which point you've really lowered the
value of having a common schema in the first place.

Just as OpenID lets you use any complaint site as your provider, Portable
Contacts lets you use any compliant site as your address book provider--it
could be a consumer web site, it could be your own blog, it could be your
CardDAV-uploaded vCard file from your local address book, which exposes a
PortableContacts endpoint or goes through a PortableContacts proxy. But
issues like authentication are critical--most people's address books aren't
public--and HTTP Basic alone is insufficient in a world where everyone is
trying to convince users to stop entering their raw credentials on other
sites. This has led to a flurry of one-off / reinvented "delegated
authorization" methods, which have done little to stop the problem because
it's just too hard for developers to build against each one. OAuth seems
like a promising solution here, since it solves the pattern once and
everyone can use it, and that's why we prescribe OAuth as required for any
Portable Contacts provider that wants to do delegated authorzation. The
flavor of most of the requirements in Portable Contacts is: "you don't have
to do this at all, but if you do, here's the standard way to do it". That's
why we've tried to be comprehensive, even though it means doing a few
different jobs at the same time.

Thanks, js

On Wed, Dec 3, 2008 at 6:24 PM, Dan Brickley <[email-masked]> wrote:

>> of the day all these are simply an HTTP-based protocol to access data - what
>> is more important is the nature and semantics of the data itself.
>>
>
> current spec does several things all bundled together. It defines a schema;
> both for vCard-ish properties, but also for much of the social-networking
> vocabulary created by the Open Social project. This is a major piece of
> work. It also defines bindings into JSON and XML, with perhaps a slight bias
> towards the JSON flavour. And then it gives us a network access protocol
> too; although apparently not yet an updates spec. I'd feel a little more
> comfortable if the schema and protocol were more separate, so that other
> (eg. extension) vocabularies could also be accessed via essentially the same
> mechanism, or so that the schema and its inevitable extensions could be
> re-used in other protocol contexts such as CardDAV and SPARQL/RDF.
>
> contact/addressbook data. I doubt we can use exactly the same names (since
> RDF conventions around plural fields would make this seem odd), but (like
> Joseph) I'll do my best to ensure 1:1 relationships to the names used in PC,
> so that data in FOAF/RDF form can be transformed back into PC and vCard more
> easily.
>
> cheers,
>
> Dan
>
> --
> http://danbri.org/
>
>
>
>

---

From: "Joseph Smarr" <[email-masked]>
Date: Wed, 3 Dec 2008 18:55:32 -0800

I'm ambivalent about the call for separate namespaces for everything. I
certainly understand the theoretical argument, but I'm not sure it causes as
much practical pain as some people fear to have a flat namespace--HTML seems
to do fine without it, and lots of people stick extra tags in RSS feeds
without a separate namespace. The policy of "ignore it if you don't
recognize it" seems to work well in practice, and the amount of times
multiple different authors come up with different semantics for the same
field name seems low, and if/when it does happen, they quickly reach a
resolution in a somewhat darwinian fashion. :) And I worry about the
downside of namespaces--they're notoriously problematic and unevenly
supported in XML libraries and by developers (e.g. many look for common
prefix names, and don't start by looking for the URI and assuming it could
in theory be bound to any prefix name), not to mention the fact that there
isn't a clear way to do namespaces in JSON, and that's a feature-not-a-bug
in the eyes of many people. :)

As for the provenance of relationships, the idea in Portable Contacts is to
have two parallel sets of descriptors: "tags" is authored solely by the
owner of the address book, and can be whatever the author wants, whereas
"relationships" is defined to be only mutually-confirmed relationships made
on a site. So if you tag your sister as "family" in your own address book,
that's a tag, but if she connected to you as family in Pulse, that's a
relationship. Different applications will care differently about whether the
descriptor is bi-directional--e.g. for just categorizing your address book
in a quick widget with checkboxes for sharing a story with people you know,
the difference doesn't matter, whereas say if Plaxo wanted to build a
feature that let users connect up their LinkedIn account and say "anyone I'm
connected to on LinkedIn as a business connection automatically has my
permission to connect as Business with me on Plaxo", we definitely would
want LinkedIn to make that distinction clear.

Thanks, js

On Wed, Dec 3, 2008 at 6:46 PM, Dan Brickley <[email-masked]> wrote:

>> http://portablecontacts.net/draft_spec.html starting at section 7.2.1)
> Re extensibility hooks, it would be great if you could define a namespace
> URI for the core XML vocabulary. It will help with versioning, but also with
> defining a mapping into RDF (whether FOAF or your own RDF vocabulary), which
> in turn helps (I'd argue) with mixing this data with data in other
> independently managed namespaces.
>
>
>> makes sense to have a common, encompassing standard.
>>
>
> networking space is so rich, and varied, that the varieties of data you'll
> encounter and want to represent are going to eclipse those of 'core
> addressbooks' massively. It will be very hard to know where to stop w.r.t.
> expanding the core.
>
> where people work. Perhaps also where they worked before. Their roles there?
> Their skills, expertise, qualifications? Who their line manager was? How
> much dating information do we want in this core? We can describe gender,
> plain text 'looking for' preferences, ... but some sites will want to store
> and exchange and query and filter on much more than this. How much
> geographic precision do we want?  etc etc
>
> when developing a standard for global use. I've been watching and admiring
> the way OpenSocial's schema has been developing, pretty bottom-up from the
> deployed practice of social network sites. But the fact remains that on each
> of these topics, there is always going to be a lot more to say. And
> different parties will want various extensions, qualifications and so on in
> different places. Putting it all in the core seems impossible but I don't
> think I fully understand the extensibility model / plan yet.
>
> This is interesting. The bi-directionality aspect suggests that the values
> of this field need to be confirmed by the party being described, or rather
> by the relevant account holder on some social site. So if I have my sister
> tagged as my sister in MacOSX addressbook somehow, would I be breaking the
> semantics of these relationship fields by exporting this information without
> her (or an accountholder claiming to be her) explicit confirmation?  This
> seems to mix some critical provenance and trust issues directly into the
> schema design. Did you consider a more dictionary-like approach: simply
> define what 'co-worker' means and leave confirmation/validation as a
> seperate aspect of all fields.
>
> Even if I seem grumbly here I'm very glad to see this effort taking off.  It
> plugs some gaps we have in the FOAF world quite nicely, and also begins the
> larger conversation about bridging addressbook and social-network-site
> datasets...
>
>
> cheers,
>
> Dan
>
> --
> http://danbri.org/
>
>
>

---

From: Dan Brickley <[email-masked]>
Date: Thu, 04 Dec 2008 03:17:19 +0000

Joseph Smarr wrote:
> I agree that Portable Contacts is trying to do several things at once, 
> and I also agree that it might make sense to separate some of these 
> pieces out--e.g. separating the schema from the access protocol--to 
> maximize adoption of those pieces.

That'd be nice but might not even be necessary. I think having some 
principles of independence is much more important than whether the 
pieces are all defined in the same spec.

 > But we feel it's very important to
> solve the "end-to-end problem" of a user being able to tell a web site 
> or application "I already have a profile, address book, and/or 
> friends-list over on site X, go use it please", which involves 
> discovery, authentication, an access API, and a common data format. 

Agreed. The acronym soup we have right now confuses everyone...

 > If you drop any one of these pieces, you force developers to do one-off
> vendor-specific implementations of whatever piece in this chain they did 
> differently, at which point you've really lowered the value of having a 
> common schema in the first place.

I think a key goal here is for the protocol pieces of the puzzle to work 
with independently developed extensions, without need for central 
blessing. This is a lot easier for read-only protocols than for 
read-write, in my experience. How far into addressbook update/edit is 
Portable Contacts expecting to go?

> Just as OpenID lets you use any complaint site as your provider, 
> Portable Contacts lets you use any compliant site as your address book 
> provider--it could be a consumer web site, it could be your own blog, it 
> could be your CardDAV-uploaded vCard file from your local address book, 
> which exposes a PortableContacts endpoint or goes through a 
> PortableContacts proxy. But issues like authentication are 
> critical--most people's address books aren't public--and HTTP Basic 
> alone is insufficient in a world where everyone is trying to convince 
> users to stop entering their raw credentials on other sites. This has 
> led to a flurry of one-off / reinvented "delegated authorization" 
> methods, which have done little to stop the problem because it's just 
> too hard for developers to build against each one. OAuth seems like a 
> promising solution here, since it solves the pattern once and everyone 
> can use it, and that's why we prescribe OAuth as required for any 
> flavor of most of the requirements in Portable Contacts is: "you don't 
> have to do this at all, but if you do, here's the standard way to do 
> it". That's why we've tried to be comprehensive, even though it means 
> doing a few different jobs at the same time.

I'm with you 100% on the OAuth story, and baking that into the spec is 
fine. I would love to see some test case examples of how the data 
payload can be extended though, and how to express those extensions in 
both XML and JSON. Having a clean story about independent extension is 
one way to have a pressure valve, so that not everything has to be 
standardised through the portablecontacts project in future versions of 
the spec. I reckon if you can do this, the risks of having a 
"big-fat-everything" spec are somewhat reduced, since people won't keep 
pressuring you to add in new vocabulary, revving the core spec.

Following your point in the message that just arrived as I wrote this, 
re namespaces I'm not proposing that everything be in different 
namespaces within the Portable Contacts universe. Rather that you 
associate at least a single agreed 
http://portablecontacts.net/something# URI with your unified flat 
namespace. This will allow tools and systems that *are* namespace-aware 
to have some agreed way of identifying stuff from your schema.

In other words, the wider Web environment can have data from multiple 
namespaces floating around, even if an individual document format (or 
protocol) uses a single flat namespace.

Use case: I might for example want to load up all the DOAP files (which 
describe opensource software projects) from http://projects.apache.org/ 
http://pypi.python.org/pypi etc and mix them with data from Portable 
Contacts, my mail archives, project wikis etc. This is fairly 
straightforward, but currently there's no URI to associate PC properties 
with. DOAP has an evolving set of property and class names for 
describing opensource software projects; but I have no desire to 
maintain eternal watch on whether those names clash with usage from the 
evolving Portable Contacts namespace. I just want to put all the data in 
a common db and run queries like "give me the names and IM details of my 
friends who work on Python-based software projects". Or 'give me the 
blog and twitter URLs for anyone who is a committer on an opensource 
project I'm a member of". These kinds of scenario don't require DOAP or 
Portable Contacts to impose multiple namespaces on *their* adopters; 
merely that each set of names has an associated URI, for when the data 
flows into a larger melting pot...

cheers,

Dan

--
http://danbri.org/