On Sat, Oct 16, 2010 at 5:53 PM, John Panzer <[email protected]> wrote:
> 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 > On 10/15/2010 2:02 PM, James Snell wrote: > > 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:[email protected] <acct%[email protected]></to> > <to>acct:[email protected] <acct%[email protected]></to> > <cc>acct:[email protected] <acct%[email protected]></cc> > <cc>acct:[email protected] <acct%[email protected]></cc> > <bcc>acct:[email protected] <acct%[email protected]></bcc> > <bcc>acct:[email protected] <acct%[email protected]></bcc> > ... > </entry> > > Comments are welcomed and requested. > > - James > > >
