The specification is here: http://portablecontacts.net/draft-spec.html. My overall observation is that it's a good idea, but the spec needs a lot work. Herein my initial observations
I'm surprised that a data format spec is tied to XRDS and Oauth. This seems unneccasary and brittle, apart from my opinions, which are XRDS is complex, even when it's called "simple", and Oauth is not a general purpose auth protocol (it excludes user agents). I'm not sure how the "intended goal of widespread adoption" is met by depending on Oauth.
It doesn't define a posting variant. Dear format designers, please learn one lesson from Atom - think about how a resource exposing your format can be created, don't just assume a singularity. This is valid criticism as there is a design intent to be a protocol - "This API defines a language- and platform- neutral protocol for
Consumers to request address book, profile, and friends-list
information from Service Providers. As a protocol, it is intended to be easy to understand and implement,
either as a Service Provider or Consumer, using any language or
platform of choice."
The XML root element is "response". Why not "result"? Or "foo"? If it's a protocol, shouldn't there be a symmetric "request" format?
It doesn't have a schema. There are two formats, but no model. How will we add new formats , or will there only ever be two? It doesn't define a procesing model for the JSON result. or the XML. It refers to xs:string, but doesn't reference WXS.
For any address/contacts spec, I always want to know how it maps (or
does not map), to vcard. It's a goal, but not explained how it's been
achieved - the vcard mappings need to be stated.
The last time I looked, none of these were standards - OpenSocial, OAuth, XRDS-Simple, or, etc.
The "password anti-pattern" is referred to, but not referenced. Why is this a goal anyway? As with subsetting methods, this seems like a layer violation. What a format spec needs to do is state security issues known to be introduced by the format.
"We started with a review of all the major existing contacts APIs and targeted common capabilities that they all share and provide." Which ones? References?
It's clearly tied to HTTP, so more layering problems. It refers to methods - "All requests to the Service Provider are made
as HTTP GET operations on a URL deriving from the Base URL specified in
Section 5 (Discovery)." This is dubious as it breaks protocol layering
and subsets HTTP, while being utterly dependent on HTTP. It subsets the response codes - "Service Providers MAY return additional codes to indicate additional
information, but are discouraged from doing so and should instead
augment the reason text with existing codes, if possible" - that's not good technical advice. Don't even start me on the path mappings. Also, any serious attempt at unifying contacts formats needs to work over phones, and in/out of directory/mail services.
Previous Topic
