Subject: Re: to/cc/bcc extension

From: Aristotle Pagaltzis <[email-masked]>
Date: Wed, 3 Nov 2010 15:33:31 +0100

* James Snell <[email-masked]> [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/>

---

From: James Snell <[email-masked]>
Date: Wed, 3 Nov 2010 07:54:18 -0700

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.

---

From: John Panzer <[email-masked]>
Date: Wed, 3 Nov 2010 09:47:16 -0700

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.

---

From: Aristotle Pagaltzis <[email-masked]>
Date: Wed, 3 Nov 2010 21:11:12 +0100

* John Panzer <[email-masked]> [2010-11-03 17:50]:
> 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.

Ah, that makes sense.

Regards,