to/cc/bcc extension

[James Snell]

Wanted to draw attention to this:

http://tools.ietf.org/html/draft-norris-atompub-audience-00.html

It introduces to/cc/bcc elements to an Atom entry.

<entry>
...
<to>acct:john.doe-***@public.gmane.org <acct%3Ajohn.doe-***@public.gmane.org></to>
<to>acct:bob-***@public.gmane.org <acct%3Abob-***@public.gmane.org></to>
<cc>acct:jane.doe-***@public.gmane.org <acct%3Ajane.doe-***@public.gmane.org></cc>
<cc>acct:jane-***@public.gmane.org <acct%3Ajane-***@public.gmane.org></cc>
<bcc>acct:jean.deux-***@public.gmane.org <acct%3Ajean.deux-***@public.gmane.org></bcc>
<bcc>acct:max-***@public.gmane.org <acct%3Amax-***@public.gmane.org></bcc>
...
</entry>

Comments are welcomed and requested.

- James

[Ernest N. Prabhakar, Ph.D.]

HI James,

Given our previous discussion about icons: why aren't these link relations with mailto URLs?

-- Ernie P.

Post by James Snell
http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.
- James

[Alexander Johannesen]

*grumble*

Post by Ernest N. Prabhakar, Ph.D.
Given our previous discussion about icons: why aren't these link relations
with mailto URLs?

Not meant to fixate this on the follow-up'er, but everything you ever
wanted and extend Atom with is just conceptual things. There is no
difference between a defined ontology with all the entities and
relationships of Atom, and in fact you can define the whole shebang in
any ontological language. It just so happens that Atom is a short-list
of ontological expression defined in a format of sorts.

Where do the data model, format it's defined in and the ontology stop and start?

At some point the Atom model becomes so complex that it loses its easy
applicability, and perhaps should enter the realm of ontological work.
Anyone done any mappings of this so far?


Kind regards,

Alex

[James Snell]

link certainly could be used but just doesn't seem like a good fit. Things
like type, length, hreflang, nor ANY of the proposed link extensions would
apply.


On Fri, Oct 15, 2010 at 3:41 PM, Ernest N. Prabhakar, Ph.D. <

Post by Ernest N. Prabhakar, Ph.D.
HI James,
Given our previous discussion about icons: why aren't these link relations
with mailto URLs?
-- Ernie P.
http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.
- James

[John Panzer]

I like the concept and this may be a reasonable implementation.
There's related work done on this for OStatus and Salmon which might be
worth looking at.

My big question though is what the semantics of this are supposed to be;
the names are suggestive of email, clearly intentionally, but the spec
doesn't state this. Are there suggested semantics? Or is intended to
inherit semantics from email (which inherited from business snail mail...)?

(Also, bcc is untenable for use with signed content.)

Post by James Snell
http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.
- James

[Sam Johnston]

I like the concept and this may be a reasonable implementation. There's
related work done on this for OStatus and Salmon which might be worth
looking at.
My big question though is what the semantics of this are supposed to be;
the names are suggestive of email, clearly intentionally, but the spec
doesn't state this. Are there suggested semantics? Or is intended to
inherit semantics from email (which inherited from business snail mail...)?
(Also, bcc is untenable for use with signed content.)

I'd be inclined to include a scheme - eg mailto: - in which case the <link>
element makes the most sense to me even if hreflang et al don't apply. Could
also have a generic "recipient" relationship with an extensible type (to,
cc, bcc).

The bar to extend the basic Atom metamodel should be very high - if anything
we should be looking at *removing* things like author (e.g. making them
optional) as they often don't make sense in today's applications (eg GData).

Sam

http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.
- James

[Bob Wyman]

To, cc, and bcc are said to include the atomCommonAttributes which are base,
lang and undefined... I'm not sure I understand how either base or lang
really make sense for these elements. If they do make sense, could you
provide some examples that motivated their being included?

bob wyman

Post by James Snell
http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.
- James

[Aristotle Pagaltzis]

Post by James Snell
http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.

First: your example XML is broken. (Unescaped angle brackets in
content.)

Next: microparsing, and of text content no less (as opposed to
attribute values)? How hideous.

I will suggest something like

<audience rel="to"
address="acct:john.doe-***@public.gmane.org"
label="acct:john.doe-***@public.gmane.org" />

The label should be optional of course.

Now you have something tractable to XML tools, eg. you can write
reasonable XPath queries across these elements.

Regards,

[James Snell]

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)

- James

Post by Aristotle Pagaltzis

Post by James Snell
http://tools.ietf.org/html/draft-norris-atompub-audience-00.html
It introduces to/cc/bcc elements to an Atom entry.
<entry>
...
...
</entry>
Comments are welcomed and requested.

First: your example XML is broken. (Unescaped angle brackets in
content.)
Next: microparsing, and of text content no less (as opposed to
attribute values)? How hideous.
I will suggest something like
<audience rel="to"
The label should be optional of course.
Now you have something tractable to XML tools, eg. you can write
reasonable XPath queries across these elements.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

[Aristotle Pagaltzis]

Post by James Snell
Aristotle, the email application messed up the markup... it's
supposed to be just...
(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,

[James Snell]

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.

Post by James Snell
Aristotle, the email application messed up the markup... it's
supposed to be just...
(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/>

[John Panzer]

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.

Post by James Snell
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.

Post by James Snell
Aristotle, the email application messed up the markup... it's
supposed to be just...
(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/>

[Aristotle Pagaltzis]

Post by John Panzer
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,