[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Email List Subscription Use Case
For reference on this week's TC call, the following is a plain text version of the Calendar Sharing use case (also posted at http://xrixdi.idcommons.net/moin.cgi/XdiUseCases_2fEmailListSubscriptions). == XDI Use Case :: Automated Email List Subscriptions == * '''Level:''' Sea === Description === Email lists are one of the most ubiquitous services on the net, and many heavy net users are subscribed to dozens of them. With the present state of email list technology, undergoing an email-change-of-address (ECOA) requires separate human-managed interactions with each email list. This use case describes the ability for a List Subscription Authority to automate this change-of-address task, and also to be able to add or delete subscriptions easily and automatically without any knowledge of the individual interface or authentication requirements of the specific lists. === Actors === * List Subscription Authority (Data Authority) * The individual or other subscription entity represented by the subscribed email address. * List Subscription XDI Service Provider (XSP). * An XSP that offers automated email subscripton services. === Pre-Conditions === 1. The List Subscription Authority has subscribed to one or more email lists. 1. The List Subscription XSP hosts the List Subscription Authority's list subscription data (i.e., the current email address and the addresses and authentication credentials required by the subscribed lists). In this capacity the List Subscription XSP is acting as a Delegated DA for the List Subscription Authority. 1. Each email list offers an XDI list subscription service (i.e., functions as an XSP). === Steps / Activities === 1. The List Subscription Authority authenticates to the List Subscription XSP. 1. The List Subscription Authority changes his/her email address or adds a new email address. 1. The List Subscription XSP prompts the user to verify which list subscriptions should be updated and the List Subscription Authority makes this selection. 1. The List Subscription XSP sends an automated change-of-address to all the affected email listbots and receives the acknowledgement. 1. If there are any failures, the List Subscription XSP notifies the List Subscription Authority. === Post-Conditions === * The List Subscription XSP's records are updated so that any future changes are ready to be made. === Variations === * The List Subscription Authority may also instruct the List Subscription XSP to add a new email list to his/her subscriptions, or to delete an existing subscription. In each case the List Subscription XSP sends the appropriate automated message to the email list. * In the case of adding a new subscription, the List Subscription XSP may need to query the email list to discover the necessary list subscription/change-of-address/unsubscription data requirements. === Issues / Key Requirements === * The List Subscription XSP can be either a server-side service or a client-side program - the architecture should be neutral. * Messages to the email lists should be able to be sent via either email or Web forms (many email lists support both interfaces). === Security Considerations === * Messages to listbots must include the credential(s) necessary to authenticate the List Subscription Authority to the email list, preventing automated attacks. === Privacy and Other Data Protection Considerations === * The List Subscription Authority's list subscription data is typically sensitive and should be protected by an applicable privacy policy. === Links and Resources === * ReturnPath offers several white papers on the [http://www.returnpath.biz/ ECOA problem]. * Although there is a wealth of software to automate email list management (i.e., publisher-side operations), I don't know of any to automate subscriber-side operations. === Contributors === * DrummondReed
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]