Standards Committee Teleconference 2008 09 10
Standards Committee Teleconference Call Notes
Drafted by Joe Andrieu, August 13, 2008
- Joe Andrieu
- Iain Henderson
- Asa Hardcastle
- Eve Maler
Previous Action Items
- Additional thoughts to one night stand notes to VRM wiki. Eve. By next Wednesday.
- Close loop with and Doc and finalize Oct mtg date. Joe. By next Wednesday.
- Set Agenda
- Review previous Action Items
- October Face to Face
- Radio Event
- November One Day Meeting after IIW (November 13)
- Review Action Items
Does the change from rel-button to r-button imply r-card is the selected technology.
r-card is technology agnostic, but there are some implicit links.
More details? When, where?
2 Days in Boston October 13/14 or 14/15th 1/2 day PAM 1/2 day r-button 1 day implementation details r-button
Standards Track check-in
Developing standards/specification framework, Moving PAM forward, getting r-button into challenges.
Is r-button trying to do too much? Is it a solution to everything?
But unless and until you have a customer who has achieved becoming a platform, all the asymmetries of the current system belie the symmetry of the r-button. Which means that the icon risks becoming a marketing (mythical) solution.
r-button as iconic for VRM is ok... as an entry point to the VRM world. We should probably explore that (not "we" the standards committee, but "we" VRM).
This relates in a bit back to relationship management interface points raised by Eve. You should be able to manage your relationships without having to go to that site, just as you can manage your real-world travel visas without visiting those countries. If you just need to change your policies, or your address, at multiple sites, that implies a control point which should be at your own point of control, not just by visiting the vendor's site.
This links to peer-to-peer/centralized conversation. You could have a very simple implementation of this with hosted solutions that did look-up. Discovery. So, when the icon shows up, it only shows up in the browser (the vendor server need not know of it). Clicking on that icon takes you to your service.
So, let's build a simple back-end that exists in the cloud, that users have total control over, that manages relationships on behalf of the user.
The key requirement is that we always reserve the right to run your own server in your own basement.
The guarantee is that the consumer of the information has only the authorized level of access. Setting up the relationship rigorously controls the flow of information.
The entry point is starting to supply services that make sense for vendors.
Mailing list example. Where you send email out to VRM subscribers, who are linked via a relationship management service.
For the email recipients, it also provides one single place where email addresses/subscriptions are managed.
Email Address updates Email "vacation" status Email opt-in/subscribe/unsubscribe
- Close loop with Doc regarding week in October
- Send rbutton meeting information
Future Agenda Topics
- Discuss the distinctions between a Service Endpoint and a Service Manager.