Standards Committee Teleconference 2008 06 18: Difference between revisions

From Project VRM
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 26: Line 26:


==Notes==
==Notes==
===Action Items===
===Address-enabled Discoverable Services===
Distinctions about AddressRequester v AddressUtilizer. AddressUtilizer is, in Joe's words, perhaps always providing (or managing) a specific service that uses the address; and the AddressRequester is using that service.  For example, the Amazon use case implies that Amazon is the AddressRequester and FedEx or UPS is the AddrssUtilizer. This seems generalizable with the AddressUtilizer is really a discoverable Delivery Service that just happens to use the PAM.
 
So... how do we talk about that in the PAM?
 
Another potential general AddressUtilizer is a Direct Marketing Service, which is empowered by the user to arbitrate direct mail promotional campaigns. Steve Gail has a business that helps people stop junk mail and it turns out that everyone has a different definition of junk. So an DMS would let the user specify on a moment-to-moment basis what they are actually willing to receive junk mail about, e.g., coupons or global warming fundraisers or whatever.
 
===Discovery, Compliance, and adoption===
It seems there are three levels of compliance that make sense to be supported architecturally. At Amazon, they query me/my IdP for a delivery service.  That can be resolved three ways
# automatch: I have one or more services Amazon is willing to use, either the options are presented to the user or the cheapest one is presented for confirmation, or they just use the cheapest, or whatever; perhaps this is Amazon's choice.
# new service provisioning request: Amazon may want to use a different service than one of the ones I have available (I may have none). So Amazon asks if I want to use that service and we do a provisioning in real-time of that new Delivery Service so Amazon can use it.
# fallback to POD, plain old data. If all else fails, the vendor can always just have the address data itself.
 
===Future Agenda Items===
#Discuss the differences between one-night-stands and long term relationships with service providers and vendors.
#Discuss the distinctions between a Service Endpoint and a Service Manager.


==Action Items==
==Action Items==
Line 32: Line 47:
# Flower Power Scenario Diagrams - Asa - Before July 2
# Flower Power Scenario Diagrams - Asa - Before July 2
# Write up notes from call into wiki - Joe - By Monday
# Write up notes from call into wiki - Joe - By Monday
# Send blog post seeds to Drummond re: r-cards - Joe - Today
# Blog about current state of r-cards - Drummond - Next Week


==Next Meeting==
==Next Meeting==
[[Standards Committee Teleconference 2008 06 18]]
[[Standards Committee Teleconference 2008 06 18]]

Latest revision as of 13:47, 18 June 2008

Standards Committee Teleconference Call Notes

Drafted by Joe Andrieu, June 18, 2008

Other Calls

Category:Standards Committee Teleconferences

Attendees

  • Joe Andrieu
  • Asa Hardcastle
  • Eve Maler
  • Drummond Reed

Previous Action Items

  1. Customer journey for PAM on wiki -- Iain -- by next Friday
  2. Queue up email post on r-card blog -- Joe -- by Friday
  3. Blog post follow on -- Eve -- by Monday
  4. PAM review & diagram integration meeting -- Asa -- by next Friday

Agenda

  1. Set Agenda
  2. Review previous Action Items
  3. PAM conversation (Asa)
  4. Boston
  5. Review Action Items

Notes

Address-enabled Discoverable Services

Distinctions about AddressRequester v AddressUtilizer. AddressUtilizer is, in Joe's words, perhaps always providing (or managing) a specific service that uses the address; and the AddressRequester is using that service. For example, the Amazon use case implies that Amazon is the AddressRequester and FedEx or UPS is the AddrssUtilizer. This seems generalizable with the AddressUtilizer is really a discoverable Delivery Service that just happens to use the PAM.

So... how do we talk about that in the PAM?

Another potential general AddressUtilizer is a Direct Marketing Service, which is empowered by the user to arbitrate direct mail promotional campaigns. Steve Gail has a business that helps people stop junk mail and it turns out that everyone has a different definition of junk. So an DMS would let the user specify on a moment-to-moment basis what they are actually willing to receive junk mail about, e.g., coupons or global warming fundraisers or whatever.

Discovery, Compliance, and adoption

It seems there are three levels of compliance that make sense to be supported architecturally. At Amazon, they query me/my IdP for a delivery service. That can be resolved three ways

  1. automatch: I have one or more services Amazon is willing to use, either the options are presented to the user or the cheapest one is presented for confirmation, or they just use the cheapest, or whatever; perhaps this is Amazon's choice.
  2. new service provisioning request: Amazon may want to use a different service than one of the ones I have available (I may have none). So Amazon asks if I want to use that service and we do a provisioning in real-time of that new Delivery Service so Amazon can use it.
  3. fallback to POD, plain old data. If all else fails, the vendor can always just have the address data itself.

Future Agenda Items

  1. Discuss the differences between one-night-stands and long term relationships with service providers and vendors.
  2. Discuss the distinctions between a Service Endpoint and a Service Manager.

Action Items

  1. One Night Stand Use Cases - Eve - Before July 2
  2. Flower Power Scenario Diagrams - Asa - Before July 2
  3. Write up notes from call into wiki - Joe - By Monday
  4. Send blog post seeds to Drummond re: r-cards - Joe - Today
  5. Blog about current state of r-cards - Drummond - Next Week

Next Meeting

Standards Committee Teleconference 2008 06 18