Re: to/cc/bcc extension
Sam Johnston <samj@samj.net> Sun, 17 October 2010 00:39 UTC
Return-Path: <owner-atom-syntax@mail.imc.org>
X-Original-To: ietfarch-atompub-archive@core3.amsl.com
Delivered-To: ietfarch-atompub-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 71DBB3A6B19 for <ietfarch-atompub-archive@core3.amsl.com>;
Sat, 16 Oct 2010 17:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.705
X-Spam-Level:
X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=-0.282,
BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_COM=0.553,
HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPQNO0tLwfq1 for
<ietfarch-atompub-archive@core3.amsl.com>;
Sat, 16 Oct 2010 17:39:40 -0700 (PDT)
Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by
core3.amsl.com (Postfix) with ESMTP id 5B71B3A68F3 for
<atompub-archive@ietf.org>; Sat, 16 Oct 2010 17:39:40 -0700 (PDT)
Received: from hoffman.proper.com (localhost [127.0.0.1]) by
hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o9H0ZSTe028471
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Sat, 16 Oct 2010 17:35:28 -0700 (MST) (envelope-from
owner-atom-syntax@mail.imc.org)
Received: (from majordom@localhost) by hoffman.proper.com
(8.14.4/8.13.5/Submit) id o9H0ZSoI028470;
Sat, 16 Oct 2010 17:35:28 -0700 (MST) (envelope-from
owner-atom-syntax@mail.imc.org)
X-Authentication-Warning: hoffman.proper.com: majordom set sender to
owner-atom-syntax@mail.imc.org using -f
Received: from eu1sys200aog101.obsmtp.com (eu1sys200aog101.obsmtp.com
[207.126.144.111]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id
o9H0ZPWQ028465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256
verify=NO) for <atom-syntax@imc.org>;
Sat, 16 Oct 2010 17:35:26 -0700 (MST) (envelope-from samj@samj.net)
Received: from source ([209.85.213.170]) by eu1sys200aob101.postini.com
([207.126.147.11]) with SMTP ID
DSNKTLpEzN9ujip8GYmx+ibAamc4QWYbTVbh@postini.com;
Sun, 17 Oct 2010 00:35:27 UTC
Received: by yxn22 with SMTP id 22so1024247yxn.29 for <atom-syntax@imc.org>;
Sat, 16 Oct 2010 17:35:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.69.15 with SMTP id w15mr1353463ank.39.1287275722049;
Sat, 16 Oct 2010 17:35:22 -0700 (PDT)
Received: by 10.100.8.7 with HTTP; Sat, 16 Oct 2010 17:35:22 -0700 (PDT)
In-Reply-To: <4CBA1ED3.4040208@acm.org>
References: <AANLkTi=P5k0LpVxB-Q4HqeM+zZsHfoXrDuEbGZxX7PSU@mail.gmail.com>
<4CBA1ED3.4040208@acm.org>
Date: Sat, 16 Oct 2010 20:35:22 -0400
Message-ID: <AANLkTi=LFxFAtHH_uTAG_sgpdHQNOLXF+Po41eVOyg2=@mail.gmail.com>
Subject: Re: to/cc/bcc extension
From: Sam Johnston <samj@samj.net>
To: jpanzer@acm.org
Cc: James Snell <jasnell@gmail.com>, Atom-Syntax <atom-syntax@imc.org>
Content-Type: multipart/alternative; boundary=0016368e1b6e2408b20492c53c08
Sender: owner-atom-syntax@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/atom-syntax/mail-archive/>
List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe>
List-ID: <atom-syntax.imc.org>
On Sat, Oct 16, 2010 at 5:53 PM, John Panzer <jpanzer@acm.org> 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:john.doe@example.org <acct%3Ajohn.doe@example.org></to> > <to>acct:bob@example.org <acct%3Abob@example.org></to> > <cc>acct:jane.doe@example.org <acct%3Ajane.doe@example.org></cc> > <cc>acct:jane@example.org <acct%3Ajane@example.org></cc> > <bcc>acct:jean.deux@example.org <acct%3Ajean.deux@example.org></bcc> > <bcc>acct:max@example.org <acct%3Amax@example.org></bcc> > ... > </entry> > > Comments are welcomed and requested. > > - James > > >
- to/cc/bcc extension James Snell
- Re: to/cc/bcc extension Ernest N. Prabhakar, Ph.D.
- Re: to/cc/bcc extension Alexander Johannesen
- Re: to/cc/bcc extension James Snell
- Re: to/cc/bcc extension John Panzer
- Re: to/cc/bcc extension Bob Wyman
- Re: to/cc/bcc extension Sam Johnston
- Re: to/cc/bcc extension Aristotle Pagaltzis
- Re: to/cc/bcc extension James Snell
- Re: to/cc/bcc extension Aristotle Pagaltzis
- Re: to/cc/bcc extension James Snell
- Re: to/cc/bcc extension John Panzer
- Re: to/cc/bcc extension Aristotle Pagaltzis