NB: If these are IRIs, we can then use them to bootstrap additional data retrieval via mechanisms such as Webfinger. (Which is currently public information but with authentication can be extended to private information as well.) This would allow for rich, up to date, and extensible content -- name, profile photo, contact mechanisms, etc. -- without burdening this proposal with the additional metadata.
In particular I hope to use these types of mechanisms with http: and acct: URIs that are not necessarily deliverable email addresses. On Wed, Nov 3, 2010 at 7:54 AM, James Snell <[email protected]> wrote: > The value of the to/cc/bcc elements is any valid IRI. It can be an email > address or it can be anything else really. We could add an optional label > attribute to each of the elements but I'm not certain it's necessary. > > > On Wed, Nov 3, 2010 at 7:33 AM, Aristotle Pagaltzis <[email protected]>wrote: > >> >> * James Snell <[email protected]> [2010-10-25 22:10]: >> > Aristotle, the email application messed up the markup... it's >> > supposed to be just... >> > >> > <to> acct: john.doe @ example.org </to> >> > >> > (I added some spaces to try to keep the example from being >> > messed up again) >> >> I see; my “ick” reaction to micro-parsing is hereby withdrawn. >> >> Still it doesn’t change my counterproposal. Are you sure you will >> under no circumstances ever want display name to show a user? And >> that email is the pinnacle of, the one true form of, electronic >> identity? >> >> Regards, >> -- >> Aristotle Pagaltzis // <http://plasmasturm.org/> >> >> >
